EvalVitals
00 / thesis

A self-improving loop that repairs open models automatically — and verifies every fix.

Your eval says the model failed. It won't say why, or whether your fix worked. A score is a temperature reading; what you actually need is model health — where the model is failing, what mechanism drives it, how deep a repair has to cut, and whether it held. EvalVitals probes the model, finds the structure behind its failures, proposes a mechanism, tests it on cases the analysis never saw, then builds a repair and validates it against the unmodified baseline. A repair that fails escalates to a more invasive class of fix and tries again — so each pass either improves the model's health against a measured baseline, or returns an honest account of why it couldn't.

01 / loop

How one pass works

Five stages, and no hand-off between them. The agent writes and runs its own analysis code, selects the statistical tools, proposes the hypotheses, generates the repair candidates and works out which tier a given mechanism needs. Two stages can send the loop backwards — a refuted hypothesis returns to probing, and a repair that fails to beat the baseline escalates a rung instead of shipping.

You supply the question and the ceiling. Everything between is unattended.

The EvalVitals investigation loop Probe, Explore, Diagnose, and Held-out verify run in sequence. A refuted hypothesis returns to Probe. A supported one reaches Repair, which either produces a validated fix or escalates one tier and retries. Probe surface failures Explore find structure Diagnose propose mechanism Verify on held-out cases Repair vs. baseline Validated fix or inconclusive supported beats baseline refuted — probe again fails — escalate one tier
The held-out split is taken before Explore runs, so Verify always scores on rows the analysis never touched.
What you provide
  • A model or its logs. An open-weight checkpoint to probe, or existing eval output as JSON, JSONL, CSV or Parquet.
  • A question, in plain language. “What predicts the failures here?”
  • A ceiling. How invasive a repair may get, from L1 to L4.
What comes back
  • Verdicts, not vibes. Each candidate signal marked confirmed or refuted on held-out cases, corrected for how many were tried.
  • An audit trail. analysis.py as it ran, the normalised records, every figure and table, and the run's event log.
  • A repaired model, or the reason there isn't one. A validated fix measured against the untouched baseline — or a recipe and the tier it needs.
02 / example

What a full pass looks like

simulated run

        
Above the divider: the system's real control flow, including the halt at L4. Below it, in violet: a projection of one escalated investigation — strategy choice, cost at the published H200 rate, and the outcome a repair would have to demonstrate.
03 / ladder

“Fix it” is not one action

Repairs are ordered by how deeply they cut into the model. Each rung buys causal reach and costs deployability. The ceiling is yours to set — escalation is recommended, never automatic.

L1
Input space. Prompt and instruction rewrites.
Built
L2
Scaffold space. Multi-call pipelines, external tools, aggregation around an unchanged model.
Built
L3a
Internals, read. Attention-guided cropping, contrastive decoding, confidence routing.
Built
L3b
Internals, write. Attention reweighting, sink suppression, activation steering.
Built
L4
Parameter space. Build a dataset, fine-tune, re-test. The system writes the recipe and decides when one is needed — it cannot yet run it.
In progress

Inside L4: the parameter-space strategies

The confirmed mode decides which repair is worth paying for. In the worked example — hallucinations show over-concentrated attention — that points at grounding, not more data. Ordered by cost:

P1
Attention-grounding LoRA. Cross-attention adapters with a loss penalising attention mass outside the queried region.
cheapest
P2
Contrastive preference tuning. DPO over hallucinated “yes” against correct rejection — the decision boundary, not the content.
low
P3
Counterfactual SFT. Absent-object negatives mined from high-co-occurrence scenes.
medium
P4
Full fine-tune or projector retrain. For modes that survive every cheaper repair.
highest

Design space, not shipped code.

04 / trust

From hypothesis to verdict

EvalVitals verifies a diagnosis before it becomes a repair. A senior researcher can list ten plausible mechanisms for a failure; an agent will list fifty. Fluent explanations are easy to produce, and the loop tells you which of them hold on your data.

Against current practice

Approach How the hypothesis is formed How it is tested What the conclusion rests on
Hire an experimentalist Experience and intuition, a handful of candidates at a time An ablation designed after seeing the data, weeks of senior time per model The analyst — one researcher's reading of the data, and the ablation they chose to run
Let an agent enumerate Dozens of plausible candidates at once A full fine-tune for each one you can afford The budget — whichever candidates you could afford to test
EvalVitals Drawn from published repair results and the memory of past runs Cross-validated while exploring, then decided once on a separate sealed set The data — a measured effect on reserved cases, reproducible from the run log

A run can end with a question rather than a repair — on the committed example, one signal of four survived adjudication, and every candidate below L4 finished level with the baseline. Learning that a mechanism remains open, before a cluster pays for it, is the cheapest result the loop returns.

05 / market

Who needs this, and when it is sellable

The buyer is anyone who ships or depends on an open-weight model and cannot currently answer “why did it fail, and did the fix work?”

Model release QA

Before you publish a checkpoint

Find and repair the failure modes your benchmark score hides, and ship the evidence bundle alongside the model card.

Regulated deployment

When “it got better” is not enough

Clinical, financial and safety-critical settings need a documented mechanism and a verified repair, not a moved metric.

Fine-tune debugging

Your tune made it worse, somewhere

The aggregate barely moved but a slice regressed. Locate the slice, identify the mechanism, and test whether reverting or retraining fixes it.

Model selection

Which open checkpoint for your failure

Compare candidates on the failure modes that matter to your product rather than on a public leaderboard.

Post-incident

A production failure needs a cause

Turn a customer-visible incident into a diagnosed mechanism and a repair that is measured against the model you were already running.

Independent verification

Does that published fix generalise?

Re-test a reported mechanism and its intervention on held-out cases and across model scales, before adopting it.

Forward-deployed engineering

The engagement, minus week three

You staff senior engineers to sit inside each customer's failures. Run the loop first and the engagement opens with a diagnosed mechanism instead of spending three weeks arriving at one.

06 / research

The work underneath

The loop is a productised version of what we do as research: find the mechanism behind a model's failure, then intervene on it and check the intervention held.

Coevoskills: Self-evolving agent skills via co-evolutionary verification
COLM 2026
Directional alignment mitigates reward hacking in reinforcement learning for language models
ICML 2026
TextResNet: Decoupling and routing optimization signals in compound AI systems via deep residual tuning
ICML 2026
When RAG hurts: Diagnosing and mitigating attention distraction in retrieval-augmented LVLMs
ICML 2026
On GRPO collapse in Search-R1: The lazy likelihood-displacement death spiral
ICML 2026
When single-agent with skills replace multi-agent systems, and when they fail
Agent Skills 2026
UltraVR: A diagnostic ultra-resolution image-VQA benchmark for evidence-grounded reasoning
Preprint
07 / team

Founders

UBC Professor · Google

CIFAR AI Chair and Canada Research Chair at UBC, IC at Google GenAI. Research spans trustworthy machine learning, optimization, large language models and AI agents.

UBC · AWS & Google

Graduate student at UBC. Internships at AWS and Google on customer-facing projects, which is where the gap between a benchmark score and a shipped system becomes obvious.

UBC · Alibaba

Graduate student at UBC. Former Alibaba researcher, building Alibaba’s top-ranked open-source model Ovis and developing on Qwen.