AI / ML Engineer
I work on the boundary between people and machines, making each legible to the other.
About
A model produces an answer; a person has to decide whether to trust it. My research proposed one way in: instead of asking which features mattered, ask which training examples were responsible. Inspect the process, not the output. It became a thesis and two papers.
Then I went to industry. Now the work is putting AI in the hands of energy engineers, people who have no use for a confident wrong answer.
Which makes it production work more than modelling work. An inference service other products depend on. Model choice and provider routing behind a versioned interface, so what's underneath can change without anyone downstream noticing. Retrieval that returns the right passage rather than a plausible one. Output validated before a human ever sees it. Evaluation offline, quality monitoring online, latency and cost tracked like any other budget. Prompts in version control, because they're code.
All of it in a startup, where you own a product rather than a ticket. I own the platform and the conversational assistant inside it, from the argument about what to build, through architecture and code review, to whatever happens after it ships.
None of that is glamorous. It's the difference between a model that works in a notebook and one someone trusts at three in the morning.
Research
Work
A technician photographs the nameplate on a device in bad light; a utility bill turns up as a scan of a table; a spreadsheet carries six years of one person's private conventions. None of it was written for a machine. Character recognition, the part people assume is hard, is the part that already works; the hard part is judgment, because a model asked for an answer it cannot see will produce a well-formed, convincing, wrong one. So the work is making abstention a first-class output, and then designing an interface that assembles itself around whatever was actually found, showing a person what was read, what was inferred, and what to check first.
Most explainability asks which parts of an input a model looked at. My research asked a different question: which training examples were responsible for the decision. Recording how a prediction moves during training, rather than discarding that history, lets you name the examples present at the moments the behaviour settled. What comes back is not a heatmap but a precedent: this is classified this way because of these forty images, which is much closer to how people actually justify a judgment to each other.
The demo works is the least informative fact available about a system. For generative output there is no accuracy to compute, so the first real work is not modelling. It is building the ruler: examples with answers you actually believe, argued over, and worth more than any model that will be scored against them. Offline scores describe yesterday, so the ruler has to run against live traffic, with latency and cost on the same dashboard as quality because they trade against each other. And prompts are code: one edited in a web console at eleven at night is an undocumented deploy.