000%
ホームに戻る
AI Evaluation

How to Evaluate AI Systems Without Lying to Yourself

2024-12-2012 min read

Why vibes-based testing kills AI projects and what to do instead

Most AI projects fail because of bad evaluation. Teams test by vibe: 'it feels like it's working.' They cherry-pick examples that look good. They confuse fluency with correctness. They deploy without measuring anything meaningful—and then wonder why production performance is terrible. Evaluation is not optional. It's the difference between guessing and knowing.

Why Vibes-Based Testing Fails

Vibes-based testing means running a few hand-picked examples, looking at outputs, and deciding if they 'seem right.' This is how most teams test LLMs, RAG systems, and agents. It doesn't work.

Problems: (1) Humans are bad at unbiased sampling—we pick easy examples or examples we know work. (2) Fluent outputs feel correct even when they're wrong. (3) You can't track performance over time or compare approaches without metrics. (4) When something breaks in production, you have no baseline to debug against.

What Good Evaluation Looks Like

Good evaluation is systematic: a fixed test set, clear metrics, automated scoring, and version tracking. You run evals on every change. You know if performance improved, degraded, or stayed flat. You can debug failures because you have structured data, not vibes.

This applies to all AI systems: LLMs, RAG, vision models, agents. The specifics differ, but the principle is the same: measure, don't guess.

Building a Golden Test Set

A golden test set is a collection of inputs with known correct outputs. For an LLM system, it's queries with expected responses. For RAG, it's questions with correct answers and source citations. For vision, it's images with ground-truth labels.

Start small: 50-100 examples covering common cases, edge cases, and known failure modes. Grow over time by adding production examples where the system failed.

Quality matters more than quantity. A well-curated 100-example test set beats a noisy 10,000-example set. Each example should be unambiguous: given this input, the correct output is clearly defined.

Metrics That Actually Matter

For LLMs and agents: task completion rate (did it solve the problem?), accuracy (is the output factually correct?), refusal rate (did it correctly refuse unanswerable questions?), and cost (tokens per task).

For RAG: retrieval precision (are the right documents in the top-k?), answer accuracy (is the final response correct?), citation accuracy (do citations match claims?), and hallucination rate (unsourced claims).

For vision: mAP, per-class recall/precision, false positive rate (critical for production), inference latency, and confidence distributions.

Avoid vanity metrics. 'The model sounds smart' is not a metric. 'It answered 87 out of 100 test questions correctly' is.

Automating Evaluation

Manual evaluation doesn't scale. You need automated scoring. For structured outputs (classification, extraction), this is straightforward: compare predicted vs ground truth.

For open-ended outputs (LLM responses), use LLM-as-judge: another LLM scores outputs for correctness, relevance, or quality. This is imperfect but better than nothing. Validate LLM-as-judge scores against human labels periodically.

For agents, measure task completion: did the agent achieve the goal? This often requires simulation or sandbox environments where success is programmatically verifiable.

Regression Testing for AI

Every time you change a prompt, model, or retrieval strategy, run your test set. Track performance over time. Treat it like regression testing in software: if accuracy drops, don't deploy.

Version everything: prompts, model versions, test sets, and eval results. When performance degrades, you can diff versions and identify what changed.

This prevents the common failure mode where you 'improve' the prompt for one case but break five others without realizing it.

Eval Sets Are Living Artifacts

Your test set should evolve. When users find failures in production, add those cases to your test set. This turns production bugs into regression tests.

Periodically review test set quality: are examples still relevant? Are labels correct? Is the set representative of production distribution?

Test sets decay over time as your system and user behavior change. Treat them as living artifacts that need maintenance.

The Bottom Line

You can't improve what you don't measure. AI systems are non-deterministic and hard to debug—which makes systematic evaluation even more critical, not less.

Build golden test sets. Define clear metrics. Automate evaluation. Run evals on every change. Track performance over time. This is how you go from guessing to knowing—and from demos to production systems that actually work.