Research Scientist, Deterministic ML

About Serve AI

• Serve AI is building the next generation of enterprise intelligence infrastructure for organizations that cannot afford hallucinations, inconsistent outputs, or black box AI. Our deterministic intelligence platform delivers fast, traceable, and auditable answers that organizations can trust across regulated, security conscious, and mission critical environments.
• Unlike traditional AI systems that generate probabilistic responses, Serve AI is designed around deterministic execution. Every answer is grounded in verified enterprise knowledge, providing organizations with consistent, explainable, and repeatable results while maintaining complete control over their data and deployment.
• We are backed by JAM Fund and a network of investors and executives from leading technology companies including Google, Microsoft, Meta, NVIDIA, OpenAI, Anthropic, DoorDash, Toast, Tesla, CAA, and Major League Baseball.
• As an early stage company, every employee has the opportunity to make a meaningful impact. We move quickly, value ownership over bureaucracy, and look for people who enjoy solving difficult problems, building systems from scratch, and helping define the future of enterprise AI. If you thrive in environments where your work directly influences customers, products, and company growth, you'll fit right in.

• The role
• Our answer path is deterministic by design: learned components route, plan, and verify, but a symbolic assembler not a model produces the final output, and every step has to be reproducible and explainable. Your job is to push what that architecture can do closing known accuracy gaps, testing new representation techniques, validating claimed results before anyone trusts them without ever trading the determinism guarantee for a marginal accuracy gain. This is a research role with teeth: findings have to survive reproduction before they change anything downstream.
• What you'll own
• Design and run experiments that improve routing, grounding, or composition accuracy while keeping the served answer path fully deterministic sophistication belongs in training and evaluation, not in what actually executes.
• Independently reproduce and validate any externally reported or claimed result before it influences a roadmap or adoption decision a promising ablation or benchmark number doesn't get acted on until it holds up on your own instrumentation.
• Take the team's already diagnosed open problems (accuracy frontiers that don't yet clear the ratified bar, model components that generalize poorly beyond their training corpus) from "we know what's wrong" to "we have a validated fix."
• Operating strictly inside the platform's nonnegotiable method constraints, the deterministic design is licensed IP, not a starting point for redesign. Your research explores the space inside those constraints, not around them.
• Propose and evaluate new representation or embedding techniques, held to the same noregression, crosscustomerevidence discipline as any other production model change.
• Write up findings including negative and inconclusive ones with enough precision and reproducibility detail that someone else could rerun the experiment without asking you a followup question.
• Hand off validated methods to the engineers who own production execution; your job ends at "this is true and this works," not at shipping it yourself.

• What success looks like
• Every claimed accuracy gain survives independent reproduction before anyone builds on it.
• At least one longstanding open research problem moves from diagnosed to solved and validated, not rediagnosed for a third time.
• New methods respect the determinism guarantee with zero exceptions.
• Research findings are usable by the applied engineering team without a second research pass to make them actionable.
• What you'll bring
• Research experience in embeddings, metric learning, or representation learning, with genuine comfort working inside hard architectural constraints rather than having open model choice.
• Rigor with small sample statistics, confidence intervals, statistical power, and the discipline to report "not yet proven" instead of overclaiming a promising result.
• A track record of treating a design constraint as the problem to solve inside, not an obstacle to negotiate around.
• Strong technical writing: your findings need to be usable by people who didn't run the experiment.
• Helpful experience
• Deterministic or interpretable ML, as distinct from purely probabilistic or generative systems.
• Distance metric learning, prototype based classification, or nearest neighbor routing systems.
• Reproducing and auditing another team's or another researcher's published results before adoption.