Back to all work 01 — Case study

Intelligent Technical Knowledge & Support Automation Platform

Technical support teams were answering the same questions over and over, digging through thousands of pages of manuals and SOPs to find answers that already existed. I built a Retrieval-Augmented Generation platform that finds those answers itself — and cut ticket volume by more than a third.

Company
Teledyne Technologies Inc
Role
AI/ML Engineer
Timeline
Jul 2025 — Present
Domain
Enterprise support automation
35%
Reduction in support ticket volume
30%
Improvement in search relevance
18%
Gain in response accuracy
40%
Faster deployment cycles
The problem

Institutional knowledge existed — nobody could find it.

Product knowledge lived across technical manuals, standard operating procedures, and years of accumulated support documentation. The information was there. Retrieving the right passage, for the right question, at the right moment was the bottleneck.

Keyword search returned documents, not answers. Engineers re-derived solutions that had already been written down. Every repeated question consumed specialist time that should have gone to genuinely novel problems.

Teledyne runs four business segments, and the documentation reflects that spread — detector arrays and optics in one manual, sonar and water-quality instruments in the next, MIL-spec interconnects in a third. Those domains share almost no vocabulary. A term like "drift" means sensor calibration in imaging, signal baseline in test equipment, and vessel positioning in marine. Keyword search cannot tell them apart.

Four Teledyne business segments feeding the retrieval layer: digital imaging across UV, visible, infrared and X-ray spectra at 51.7% of FY2025 net sales; instrumentation covering marine sonar and oscilloscopes at 23.8%; aerospace and defense electronics at 17.3%; and engineered systems at 7.1%.
Segment mix from Teledyne's FY2025 net sales. Digital imaging alone is more than half the business — and the largest share of the documentation corpus.

The goal was not a chatbot. It was a system that could ground its answers in the company's own documentation and be trusted in a technical context where a confidently wrong answer is worse than no answer.

The approach

Retrieval first, generation second.

The architecture treats the language model as a synthesizer over retrieved evidence rather than a source of truth. Everything upstream of generation exists to put the right context in front of it.

Architecture diagram: knowledge sources feed ingestion and chunking, then embeddings into Pinecone, FAISS and ChromaDB. Queries pass through a fine-tuned BERT intent classifier, retrieval and reranking, an agent layer, and finally grounded generation.
End-to-end flow. The agent layer only engages when a single retrieval pass cannot resolve the request.
01
Ingestion & chunking
Technical manuals, SOPs, and support documentation parsed and segmented into semantically coherent chunks that preserve procedural context.
02
Embedding & indexing
Vector embeddings generated and managed across Pinecone and ChromaDB, tuned for the vocabulary of technical documentation rather than general prose.
03
Intent classification
Fine-tuned BERT models classify incoming queries so retrieval strategy adapts to what is actually being asked — a troubleshooting request routes differently than a spec lookup.
04
Retrieval & reranking
FAISS and Pinecone retrieve candidate passages; a reranking pass promotes the segments most likely to contain the answer before anything reaches the model.
05
Agentic orchestration
LangGraph and LlamaIndex coordinate multi-step reasoning and tool execution for requests a single retrieval pass cannot resolve.
06
Grounded generation
Reusable prompt-engineering frameworks constrain the OpenAI-backed generation step to the retrieved context.
Shipping it

A model that only runs in a notebook isn't a solution.

Getting to production meant treating the AI services like any other piece of infrastructure. Every component was containerized with Docker and deployed as scalable inference workloads on Kubernetes and AWS SageMaker — which brought deployment time down 40% and let capacity follow demand.

Training, deployment, and version management run through GitHub Actions and CI/CD, with MLflow handling experiment tracking and model registry. Continuous monitoring watches for data drift and triggers proactive retraining rather than waiting for quality complaints.

Alongside the engineering, I worked with product teams and domain experts to fold these capabilities into existing enterprise applications, and mentored junior engineers through code review and technical guidance.

Stack
Generative AI
  • LangChain
  • OpenAI API
  • LangGraph
  • LlamaIndex
  • Prompt engineering
Models & NLP
  • Hugging Face Transformers
  • BERT fine-tuning
  • Intent classification
  • Embedding models
Retrieval
  • Pinecone
  • FAISS
  • ChromaDB
  • Semantic search
Infrastructure
  • Docker
  • Kubernetes
  • AWS SageMaker
  • MLflow
  • GitHub Actions
Outcome

Fewer tickets, faster answers, less repeated work.

Support ticket volume fell 35% as the platform absorbed the recurring questions. Semantic search relevance improved 30% with lower retrieval latency, and fine-tuned intent classification lifted response accuracy 18%.

The broader result is structural: knowledge that used to depend on whoever happened to remember it is now retrievable by anyone who asks — and the pipeline keeps improving as new documentation lands.

Next case study
Customer Retention Intelligence
Get in touch
© Sai Kumar Reddy
AI/ML Engineer · Generative AI · MLOps