A retrieval recipe that wins on a few thousand curated documents is not a system. Making it hold over tens of millions of Indian legal documents, in twelve languages, at a cost we can afford and a latency a lawyer will tolerate, is a different job. That job is yours. Our ML Research Scientist owns the recipe and the eval set. You own everything between that and a lawyer's screen, including the number once it ships. You will write the code, run the campaigns, and be the person paged when search quality drops.
YOU WILL OWN
- The production form of the retrieval stack: chunking, embedding, reranking, hybrid retrieval, query understanding. Not on a sample, on the whole corpus.
- The extraction models that turn raw judgments into structured legal knowledge, and their accuracy and throughput in production.
- The eval gate. The eval suite runs against what we serve, so a regression is caught by us and not by a lawyer.
- Model change campaigns. When a model improves, you rebuild the derived corpus reproducibly and reversibly, while search keeps serving.
- Cost and latency per query and per document, as design constraints rather than things we measure afterwards.
THE HARD PROBLEMS
- Quality that survives the long tail. A recipe tuned on clean data behaves differently on a barely legible Marathi order, a 400 page judgment, or a document kind nobody anticipated. Finding where it breaks before a user does is most of the work.
- Changing a model without breaking the corpus. Every model change invalidates derived artifacts across the whole corpus. Rebuilding them at scale, keeping old and new comparable, while the product stays live, is the recurring systems problem here.
- Measuring the thing that matters. Offline retrieval metrics can improve while the answer a lawyer reads gets worse. Tying a real production failure back to a concrete eval case, in a domain where correctness is argued rather than given, is not solved anywhere.
WE ARE LOOKING FOR
- You have taken ML from experiment to production and stayed accountable for it there. Retrieval or extraction systems, serving real traffic, over a large corpus.
- Real command of modern retrieval: dense and sparse embeddings, hybrid search, rerankers, and ANN index tuning, including the recall and latency tradeoffs you accepted and why.
- Model inference at volume: batching, quantisation, and throughput tuning on GPU and CPU. You can look at a corpus size and tell us roughly what embedding it will cost.
- Information extraction from messy documents: NER, structured extraction with LLMs, and the evaluation that tells you when it is wrong.
- Eval-driven in practice. You build harnesses, curate datasets, and set regression gates. You know which metrics lie.
- Strong Python and real production engineering: idempotent jobs, versioned artifacts, reproducible reruns, observability.
- 4+ years, including time shipping ML into a product people depended on.
NICE TO HAVE
- Fine-tuning embedders or rerankers on domain data.
- Multilingual or Indic NLP.
THIS ISN'T THE ROLE IF
- You want to stay in notebooks. This role is judged on what runs in production.
- You want research handed to you finished. Half the job is working out what a research result means at scale, and saying so when it does not survive contact with the corpus.
- You want someone else to own the number. When retrieval quality drops, it is yours.