Indra Prakash Gottipati — AI / Platform Engineer
Most RAG systems fail on precision, not recall. So I build the evaluation harness first and the architecture second. On a production search service for a US state government agency that took answered-accuracy from 40% to 88% — and cut confidently-wrong answers from 46 to 2.
01 Now
I joined in January 2025 as an intern and now lead the AI work. Day to day that means retrieval quality, the evaluation apparatus that proves it, self-hosted LLM serving, and the multi-cloud machinery that lets a customer deploy the whole thing into their own account without an engineer on the call.
The through-line is refusing to ship a number I can't defend. A search system that answers 90% of questions with 40% accuracy is worse than one that answers half and is honest about the rest — especially in government work, where a confident wrong answer is a compliance problem.
02 Selected work
Rebuilt retrieval as a confidence-ordered cascade where the model selects catalog rows rather than free-writing SQL, and abstains below both a confidence floor and an absolute lexical floor. Five measured rounds: 9% → 17% → 38% → 77% → 88%.
Curated gold set, p@1/p@3, facet-F1 and abstain-recall scoring, pooled candidates, LLM adjudication, frozen corpus manifests. Then compared four retrieval strategies on one corpus to find out which part of the pipeline was actually earning its keep — see Figure 1.
A walkthrough service plus a Terraform-driven worker that stands up a customer's search project inside their own GCP, AWS or Azure account, over whichever of SQL Server, PostgreSQL or MySQL they already run. Dry-run mode rehearses a deployment before touching real infrastructure.
Document, audio, image, video and web pipelines on RabbitMQ with dead-letter recovery and worker supervision — a 100-file batch went from ~5 hours to 45–90 minutes. Served Qwen models across a 5-node exo/MLX cluster behind an OpenAI-compatible endpoint, with a per-call spend ledger.
03 Figure 1
Same database, same queries, one build — only the retrieval layer differs. The bar is accuracy on answers the system chose to commit to; the right column is how many of those commitments were wrong. The gate is simple: ship nothing that commits a confident falsehood.
The catch: vector was the best retriever in the set — it could reach 97% of the corpus, where the hand-curated catalog reached only 35%. Curation buys precision and caps recall; embeddings buy recall and drift into confident error. Recall and precision were living in different components, so I stopped picking a lane and composed them: retrieve wide with vectors, then make the evidence clear a bar before committing — otherwise abstain and say so.
04 Negative results
I keep these because the reverts are what stop a team re-litigating the same idea in six months — and because an engineer who only reports wins hasn't measured anything.
Ranked all sections through a catalog prefilter before retrieval. Common tokens drowned the distinctive ones.
recall 0.695 → 0.431Injected generated questions into catalog cards, expecting better query matching. Questions turned out to be a query-side asset, not an index-side one.
recall 0.705 → 0.537Parallelised translation across threads instead of one batched call.
5× slowerSwept the BM25 b parameter looking for better length normalisation.
monotonically worseRan BGE-M3 embeddings and a Qdrant vector store in the live ingest and search path. The embedding cost bought reachability the system couldn't safely commit on, so it moved out of the commit path.
removed after measuring05 Stack
06 Contact
Open to new roles
Based in India and happy to relocate — customer travel is fine too. If you're working on retrieval quality, evaluation infrastructure, or getting AI systems to run inside someone else's cloud, I'd like to hear about it.