The problem

The default path for most LLM deployments is: prototype with a frontier model, then hit a wall — it’s too expensive, too slow, or can’t be self-hosted for compliance reasons (finance, healthcare, anything with data-residency rules). Most teams respond by either eating the cost or shipping a degraded product. What’s missing is a diagnostic step: is the model failing because it lacks knowledge, or because it doesn’t know how to behave in your specific environment — wrong tool sequencing, no self-correction, hallucinating when a query comes back empty? Those are two very different problems with two very different fixes, and conflating them is what pushes teams toward the expensive one by default.

The approach

I built this as a methodology study, not a piece of software — a structured research project (tracked in CogitOS under proj_2865ce38) that pulls apart a concrete case and turns it into a repeatable process. The anchor case is a Snorkel/RLLM study: a 235B quantized model asked a financial question submitted SQL to tables that didn’t exist and hallucinated an answer, while a 4B model fine-tuned with GRPO on a $500, 21-hour run first called get_table_names to check what was actually available, hit a column-name error, self-corrected, and got the right answer — roughly doubling pass@1 against a model 60x its size.

The methodology I extracted from that case, and from five other talks I pulled in and cross-referenced against it, is a four-step loop: run rubric-based evals (not just pass/fail) to find the exact broken behavior — did it call the discovery tool, inspect the schema, self-correct on error; build a small, expert-curated dataset that targets that specific gap instead of a generic broad one; train with RL (GRPO) using a scalar reward; re-run the rubric evals to confirm the gap actually closed. I also captured the failure modes that qualify or limit the approach: RLHF’s structural bias toward confident-sounding wrongness over honest uncertainty, why teacher-model choice for generating training data has to be validated empirically rather than assumed (a stronger model isn’t always a better data source), and where single-node simulation environments hit a ceiling for infrastructure-scale training data. Each finding is captured as a standalone, sourced idea with its origin video and timestamp, so the reasoning chain is traceable back to the original talk rather than asserted from memory.

What I learned

The sharpest thing I took from this: rubric evals are a diagnostic tool, not a reporting tool. A binary pass/fail score is fine as a reward signal for RL, but it tells you nothing about why the model failed — and if you skip straight to generating more training data without that diagnosis, you’ll aim the fix at the wrong target. The second lesson was more of a gut-check: “use the best model available” is not a safe default for generating training data. In the Open Thoughts work, Qwen-family models produced better training trajectories than Claude for certain agent tasks despite being the weaker general reasoner — the capability gap between teacher and student, and how close the teacher’s output distribution sits to what the student can actually represent, matters more than raw benchmark scores.

Where this could go

The economics here generalize directly to any enterprise evaluating a self-host-vs-API tradeoff for a compliance-constrained workload. If a team can afford $500 and a day of compute to close a behavioral gap, the “we’re locked into the frontier API because our small model underperforms” argument gets a lot weaker — and that argument is exactly what’s currently keeping a lot of finance and healthcare teams paying premium API rates for tasks a fine-tuned small model could handle in-house. The natural next step is turning the four-step loop (rubric eval, targeted data, GRPO, re-eval) into a checklist a platform team could run against their own agent failures before signing another frontier API contract, and building out the rubric-eval tooling as the reusable piece — it’s the part of the methodology that’s domain-agnostic.