You probably don't need an eval platform

Every few weeks someone asks me which eval platform they should buy, and my answer keeps disappointing them: at your size, probably none of them.

I say that as someone who builds an AI detection product. Scoring text for AI involvement is close to a worst-case eval problem, because the thing you’re measuring is fuzzy, the models underneath keep shifting, and a regression doesn’t throw an exception. It just quietly starts giving wrong answers with the same confident tone as before. If eval tooling were going to save anyone, it would save me. What actually saved me was embarrassingly small, and I want to describe it concretely, because I wasted real time believing it had to be bigger.

The trap looks like diligence

When your model-backed feature misbehaves, the industry’s default advice is to stand up an evaluation pipeline. Dataset management, scoring dashboards, experiment tracking, a vendor for each. I went partway down that road, and I can report what’s at the end of it for a small team: another system to maintain, sitting between you and the product, whose own configuration becomes a source of bugs.

These platforms are built for teams where ten people share one model pipeline and need to coordinate. On a team of one or three, the coordination problem they solve doesn’t exist yet, and the ceremony they add lands on the same person who was supposed to be shipping. It’s the same instinct I wrote about in the orchestration trap: when the core problem is hard, building scaffolding around it feels like progress and postpones the hard part indefinitely.

What a regression actually looks like

Here’s the moment that converted me to minimalism. A dependency bump changed how my pipeline chunked long documents. No test failed. The API returned 200s. Scores still looked score-shaped. But long submissions were now being judged mostly on their opening sections, and accuracy on exactly one category of input fell off a cliff.

I caught it days later than I should have, and what finally exposed it was diffing two stored traces of the same document, one from before the bump and one from after, and seeing that the second one processed a third as much text. That experience set my priorities permanently. Everything I now consider essential is whatever would have caught that bug on day zero.

The whole system, honestly

Three pieces. All of them live in the repo next to the code.

Traces you can diff. Every scoring run writes a structured record: model, version, input hash, intermediate outputs, final score, latency. Plain JSON lines. When something feels off, I pull the trace for the same input from last week and diff them. Ninety percent of “the model got worse” investigations end here, and about half of them turn out to be my code, the chunking, the prompt template, a truncation, and never the model at all.

A golden set of about twenty inputs. Real documents, chosen because each one nearly fooled the system in a different way. Human-written text that looks AI-ish, AI text that’s been hand-edited, mixed authorship, one document in the category that burned me above. Twenty is a deliberate number. I can read every failure by hand over a coffee, and I actually do, which is precisely what nobody does with a two-thousand-row eval suite. When a new failure mode shows up in production, one example of it earns a place in the set, and something redundant leaves.

A CI gate with documented tolerance. The golden set runs on every pull request. Scores can drift within a written-down band before the build fails, because model-backed systems wobble and a zero-tolerance gate just trains you to ignore red builds. The tolerances live in a comment right above the numbers, with a sentence explaining each one, so future me knows whether a violation is alarming or expected.

Total cost: a few files, no vendors, no dashboard. It has caught every regression that mattered since, including two more that arrived the same way as the first one, through innocent-looking dependency changes rather than through anything I did to prompts.

The uncomfortable part

The reason this works is that the golden set is small enough that a human still reads the failures. The moment evaluation output exceeds what you’ll personally look at, you’ve replaced judgment with a metric, and fuzzy problems eat metrics for breakfast. A number moving from 0.91 to 0.89 tells you nothing. Reading the two documents that flipped tells you everything.

So my advice to small teams stays the same. Store traces from day one, curate twenty examples you genuinely understand, gate CI with tolerances you wrote down on purpose, and spend the money you didn’t give an eval vendor on more coffee while you read your own failures. When you’re big enough to genuinely outgrow this, you’ll know, because the limiting factor will be coordinating people rather than catching regressions.