I’m a Senior ML Engineer based in India, currently at EXL Services. Ten years in, my work sits at the seam between data engineering and machine learning: building the pipelines that produce training data, and the inference infrastructure that has to keep a model fast and affordable once real traffic arrives.

How I got here

I started at Mindtree in 2016 doing backend and product engineering — Flask microservices, query optimisation, internal tooling. The piece of that work I keep coming back to was a small thing: a tool that watched product test failures, generated a regex for each failure signature, and filed the bug itself. It wasn’t sophisticated, but it removed a recurring tax on everyone’s week, and it taught me that most engineering value hides in the boring, repetitive parts of a system.

That job also produced my first production model — a classifier deployed behind a Flask API on AWS. Getting it working took a fortnight. Getting it deployed took considerably longer, and that ratio has been the shape of my career ever since.

Tiger Analytics moved me fully into data engineering: a PySpark framework fusing first-party and third-party sources into model-ready datasets. Working across many vendors at once is a fast education in how data actually arrives — late, reshaped, and without warning.

At EXL I’ve moved back toward models, but from the infrastructure side. GPU inference for aerial imagery used in insurance risk and claims. ONNX exports to get the serving footprint down. End-to-end RAG pipelines — ingestion, embeddings, vector search, inference — for enterprise document corpora.

What I care about

The unglamorous questions. Why does inference cost what it does. Why did a pipeline silently produce a number that was wrong rather than failing outright. Why does a retrieval system confidently return the superseded version of the right document. These are rarely the interesting part of a demo and almost always the reason a system does or doesn’t survive.

Failing loudly. A job that dies at 02:00 is an operational problem. A job that succeeds with wrong numbers is a credibility problem, and it costs far more to recover from. I’d rather build the pipeline that stops.

Working across the seam. Most of what I’ve shipped required coordinating with data scientists on one side and IT on the other. The translation work between those two groups is real engineering, and treating it as overhead is how projects stall.

Currently

Deepening the generative-AI side — retrieval quality, evaluation, and the economics of serving these systems at enterprise scale rather than demo scale. Recent certifications reflect that direction: Claude Certified Architect (Foundations), NVIDIA Generative AI LLMs, and Databricks Generative AI Engineer.

I’m also more interested than I used to be in evaluation. It’s straightforward to make a RAG system that impresses in a demo and genuinely hard to know whether you’ve made it better. That gap seems worth closing.

Elsewhere

• Experience — full role history
• Projects — what I’ve built
• Articles — notes on pipelines, inference and retrieval
• Contact — how to reach me