AI / Senior AI Engineer

The role

Most companies that say they "build AI" are wiring API calls to somebody else's model. We do that too, where it makes sense. But the interesting problems at Innovaccer are the ones a general-purpose model cannot solve: reasoning over a patient record that spans eleven systems and thirty years, deciding whether a prior authorization meets a payer policy that changed last Tuesday, extracting a diagnosis code with an accuracy bar where being wrong has consequences.

Those problems need models we train, evaluate, and own.

This team builds them. You will work on post-training and domain adaptation of language models from a few billion parameters up to the hundreds of billions, agent architectures that hold up over long horizons, evaluation systems that tell the truth, and the inference infrastructure that gets all of it running under real latency and cost budgets. You will read papers on Monday and have something running by Friday. You will also be the person who takes it to production, because we do not have a research group that throws prototypes over a wall.

Innovaccer is committing $250M over three years to its agentic AI platform. This team is where a meaningful share of that goes.

What you will work on

Nobody does all of this. You go deep on one or two areas and stay conversant in the rest.

Building the model systems behind entire products

Our products are not one model with a prompt in front of it. Flow, our revenue cycle platform, runs document understanding, policy retrieval and reasoning, code assignment, denial prediction, and drafting, each with different accuracy, latency, and cost requirements. Somebody has to design the whole thing and make the pieces work together.

That is a core part of this job. You will own the model portfolio behind a product surface, which means:

• Fine-tuning across the full size range. Small language models in the 1B to 8B range for high-volume, latency-sensitive, cost-constrained tasks. Medium models in the 8B to 70B range where the reasoning gets harder. Large open-weight models from 100B into the hundreds of billions where the task genuinely demands frontier capability. Knowing which tier a task actually needs is a judgment call worth a lot of money, and getting it wrong in either direction is expensive.
• Composing them into a system. Routing and cascades, small models handling the common case with escalation to larger ones, retrieval and tool layers, structured decoding, verifier models checking generator output, and the fallback paths for when a component fails.
• Owning it in production. Versioning across a model fleet, shadow deployment, staged rollout, drift detection, retraining triggers, and the regression suite that runs before anything ships.
• Holding a product-level accuracy bar, not a per-model benchmark score. A pipeline of individually good models can still produce a bad product, and finding out why is your problem.

Post-training at scale

Domain adaptation of open-weight models to clinical, claims, and payer-policy data, across the full size range described above.

• Supervised fine-tuning, preference optimization (DPO, GRPO, and what replaces them), and RL with verifiable rewards on tasks where correctness is machine-checkable.
• Continued pretraining and domain-adaptive pretraining where the vocabulary and distribution shift enough to justify it.
• Parameter-efficient methods where they suffice, full fine-tuning where they do not, and the experimental discipline to know which case you are in.
• Distillation from large teachers into small models that hold the accuracy bar at a fraction of the serving cost.
• Reward modeling, and the harder problem of specifying reward on tasks where clinical correctness is contested.

Running these jobs is its own discipline. You will work with multi-node training on hundreds of GPUs: FSDP and DeepSpeed, tensor and pipeline and sequence parallelism, activation checkpointing, mixed precision and its failure modes, checkpoint and resume strategy, throughput and MFU tuning, and diagnosing the loss spike at hour 40 of a run that cost real money. Experience keeping a large distributed run healthy is a specific skill and we are hiring for it explicitly.

Data: raw to training-ready

This is where most of the actual gain comes from, and it is the part most candidates undersell.

Healthcare data does not arrive as a dataset. It arrives as HL7 feeds, FHIR bundles, claims files, PDFs, scanned faxes, free-text notes with inconsistent structure, and payer policy documents that change without notice. Turning that into a training corpus is a research problem in its own right.

• Building the pipelines that take raw, messy, multi-format healthcare data to deduplicated, decontaminated, quality-filtered, PHI-safe training data.
• Data mixture design and the experiments that justify it. Ablations on what to include, at what ratio, and at what stage of training.
• Synthetic data generation, self-instruct and teacher-model pipelines, rejection sampling, and the quality controls that keep synthetic data from quietly poisoning a run.
• Annotation strategy with clinical and coding experts on staff: what to label, how to measure inter-annotator agreement, and when expert disagreement means your task definition is wrong rather than your labelers.
• Decontamination against your own eval sets, done properly, before someone else finds the leak.

Agents and reasoning systems

Multi-step agents that complete real operational work rather than producing suggestions: submitting an authorization, closing a care gap, resolving a denial. Tool use, planning, memory, and recovery from failure. Research questions here are open: how to train agentic behavior rather than prompt it, how to do credit assignment over long trajectories, how to make an agent recognize it is failing and stop. The hard part is reliability over long horizons when every intermediate step can go wrong, and the failure modes are not amusing.

Evaluation, safety, and guardrails

Eval is a research function here, not a QA step.

• Designing task-specific benchmarks where no public benchmark exists, which in clinical operations is most of the time.
• LLM-as-judge calibration against clinical expert labels, and knowing when the judge is the thing that is broken.
• Statistical rigor: confidence intervals on eval results, sample size, and resisting the pull of a number that looks good.
• PHI detection and redaction, output guardrails, and the audit trails that let a health system trust an autonomous workflow. Every agent we ship keeps a human in the loop somewhere, and part of this work is deciding where.

Inference and production ML

Serving small and large models efficiently: quantization, speculative decoding, continuous batching, KV-cache strategy, GPU utilization. Latency and cost budgets are real constraints, not afterthoughts. Building the training and deployment pipelines that let the team go from a notebook to a production endpoint in days.

What we expect from everyone in this role

• You take an idea from paper to prototype to production. If you have only ever done one of those three, this role will stretch you, and we are fine with that if the rest is strong.
• You can build the model layer of a real product, not just a model. That means choosing model sizes, composing several models into a working system, and holding a product-level accuracy bar.
• You write real code. Python fluently, PyTorch fluently, and enough systems sense to know why your training run is slow.
• You design experiments. You state the hypothesis, run the ablation, and report the result that disagrees with you.
• You measure things. You are suspicious of results that look good, and you build the eval before you build the model.
• You read current research and can tell the difference between a technique that will hold up and one that will not.
• You explain your work to people who are not AI engineers, including clinicians and operators who will tell you when your output is wrong.

Qualifications by level

AI Engineer / AI Researcher

• MS or PhD in Computer Science, Machine Learning, or a related quantitative field. Exceptional BS candidates with substantial research or open-source work will be considered.
• Depth beyond coursework: first-author publications at NeurIPS, ICML, ICLR, ACL, EMNLP, or similar; meaningful open-source ML contributions; a research internship at an AI lab; or models you trained and shipped that people actually used.
• You have fine-tuned an open-weight model yourself, understand the difference between parameter-efficient and full fine-tuning, and can explain why you chose one.
• Strong Python and PyTorch. Familiarity with the current training and serving stack (HuggingFace, FSDP or DeepSpeed, vLLM or SGLang, or equivalents).
• Some exposure to multi-GPU training, even at lab scale. You should know what a sharding strategy is and why it matters.
• Evidence you can finish things.

Senior AI Engineer / Senior AI Researcher

Everything above, plus:

• You have post-trained models that ran in production and you know what broke.
• You have built the model layer behind a real product feature, including fine-tuning at more than one model size and composing multiple models into a system that met a production accuracy and latency bar.
• Hands-on multi-node training experience, tens of GPUs at minimum, on models in the tens of billions of parameters or larger.
• You have built or substantially owned a data pipeline that fed a real training run, including the unglamorous parts: dedup, filtering, decontamination, format normalization.
• You can scope an ambiguous problem into a plan and tell the difference between a research question and an engineering task.
• Mentoring or setting direction for other engineers is a plus and will matter more as the team grows.

Things that stand out

• Public artifacts: papers, repos, model weights, technical reports, benchmark contributions.
• You have shipped a product where intelligence was the product, and can walk through every model decision you made and what you would do differently.
• Reinforcement learning applied to language models, done rather than read about.
• Work on evaluation methodology, which is underrated and hard to hire for.
• Data-centric research: you can point to a gain that came from the corpus rather than the architecture.
• Systems background: CUDA, NCCL and collective communication tuning, distributed training frameworks, compiler or kernel work.
• You have built something in a regulated or high-stakes domain and understand why "usually right" is not a spec.

Why this team

Model quality is not the bottleneck in healthcare AI. Context is. Innovaccer has spent over a decade building the data foundation underneath American healthcare: clinical, claims, financial, and operational data unified across Millions of patient lives. That foundation is Gravity, our Healthcare Autonomy Platform™, and it is what our agent families run on across revenue cycle, population health, payer risk and quality, and patient access.

What that means for you concretely:

• Training data most labs cannot get. Real longitudinal clinical and claims data at scale, under strict governance, for training and evaluation.
• Compute for real runs. Budgeted for multi-hundred-GPU post-training, not just inference.
• Ground truth on tap. Clinical and coding experts on staff who will label your data and tell you when your model is wrong.
• Products waiting for your models. Four agent families already in production at enterprise health systems and payers. What you train ships into, not into a demo environment.
• A team is being built now. This group defines the in-house modeling function. You will shape what it becomes rather than inherit it.

Innovaccer is an equal opportunity employer. We evaluate candidates on the quality of their thinking and their work.