AI Research Engineer, SuperLabs
About SuperLabs
We've had more than 20 million conversations on SuperLiving, and the thing that keeps coming back is how little AI actually knows about the person on the other side of it. It can pass a medical exam. It has no idea that you skip breakfast on days you've got an early meeting, that your mother's diabetes runs in the family, or that you've joined a gym four times and quit four times.
SuperLabs is our research wing. It exists to build AI that knows someone well enough to actually change their health. Everyone is racing to make AI smarter. We're trying to make it deeper.
What research means here
This isn't one project. SuperLabs is set up as a standing research function, and the questions we're working through sit roughly in these areas:
- What a system needs to know about a person before its advice is worth anything, and how that gets learned, held and recalled across years rather than sessions.
- How much of someone's health behaviour is predictable from the people who came before them, and how honestly we can say it.
- How Indian households actually make health decisions, which is not the population most published work is written about.
- How to tell whether any of it worked. Measuring real outcomes in real people is much harder than measuring model quality, and it's the one we care about.
Some of this turns into product. Some of it won't. Part of the job is having a strong view on which.
What you'd spend your time on
Reading properly, then testing it against our own data. Both halves matter and most people are only good at one of them.
Designing systems, not only studying them. Research that stops at a notebook doesn't help us, so you'd be writing production Python and watching your work run in front of real users.
Building the measurement before the thing being measured. We don't ship changes we can't read the result of, and setting up a read you can defend is often the harder half of the work.
What we're looking for
On the technical side
- Fundamental Python and SQL to Claude your way into it.
- Real working knowledge of embeddings and retrieval. Vector search, chunking and indexing tradeoffs, and how to evaluate retrieval quality properly instead of eyeballing a few results.
- Experience building with LLMs using Structured outputs, context construction, retrieval-augmented systems, and using models as evaluators without fooling yourself.
- Evaluation treated as a discipline. Building harnesses and benchmarks, deciding what a good result looks like before you run anything, and knowing which questions should be settled by deterministic code rather than by a model.
- Enough statistics to know when a result is noise. Sample size, confounding, base rates, what makes a comparison group valid. Comfort with experiment design, cohort and survival analysis, and the usual tooling around it.
- The engineering habits that keep research honest. Version control, reproducible pipelines, tracked experiments, and shipping your own work rather than handing it over.
Everything else
- You read the literature and then check whether it holds in our data. Both halves matter and most people are only good at one of them.
- You can hold an open question for a few weeks without collapsing it into the first answer that fits. Most of the interesting ones here don't resolve quickly.
- You argue from evidence, and you change your mind when it points the other way.
In practice this usually looks like three or more years of applied research or ML engineering, or a research degree alongside real shipping experience. We care far more about what you've built and what you concluded from it than about either number.
Helpful, not required: exposure to clinical research or epidemiology, longitudinal or panel data, personalisation and recommender systems at scale, fine-tuning or distilling smaller models, working with noisy multilingual text.
This role is hosted on the company's careers site.