Alena from Sber: why evaluating an LLM on 20 examples is more dangerous than not evaluating it at all

Alena, curator of the MERA benchmark and creator of Russian SuperGLUE, describes a systemic gap between academic rigor in evaluation and real development pace — and explains why "quick testing" on 10 examples is more dangerous than its complete absence.

Academia versus industry

In the academic world, a benchmark is serious methodological work. You need datasets with annotations, justified metrics, data leakage checks, result reproducibility, error analysis. A good test can take months and requires a dedicated team. But the results can be trusted.

Industrial practice operates on different time equations. A team needs to choose a model by end of sprint, test a new prompt version, compare two RAG pipelines, understand if quality dropped after update — and preferably not six months later, but by the next release.

The academic approach simply doesn't fit into such a pace. It's from this gap that two polar scenarios are born.

First — minimal evaluation without system: a few examples before demo, quick eyeball review of answers, "seems to work."

Second — the appearance of quality control: 10–20 requests, LLM judge, average score, chart in report.

Why 10 examples are worse than zero

The author draws a counterintuitive conclusion: the second scenario is worse than the first. The standard "evaluation on twenty examples" looks like a process — but generates false confidence based on a statistically weak signal.

Specific problems with this approach:

• Sample is too small — 10–20 examples don't provide reproducible results, a different set will show different numbers
• Uncalibrated LLM judge is biased — it systematically prefers long, confident, well-structured answers, regardless of actual accuracy
• Average score hides failures — a model can get high average score while completely breaking on a specific task type
• No baseline — without a fixed reference point it's impossible to understand if things got better or worse after changes
• Data leakage is not checked — the model might have seen test examples during training, in which case the evaluation measures nothing real

"The problem is that the second option often looks like quality control, but it is not.

It can be dangerous because it creates confidence where there is actually only a very weak signal."

Where does this pattern come from

Alena emphasizes: this is not about laziness or misunderstanding. Teams know perfectly well that evaluation matters. It's just that the classical academic approach is too heavyweight an instrument for real development pace. What's needed is a middle path: rigorous enough to make decisions, and lightweight enough to actually do.

Alena is curator of the "MERA" project of the AI Alliance, a benchmark for evaluating Russian-language LLMs, and also participated in creating Russian SuperGLUE and ruMTEB. Over five years of working with language models, she has observed the same gap in teams of different scales — from startups to large corporations.

What this means

LLM evaluation is not a one-time procedure before a demo, it's production infrastructure. Teams that build it systematically save time on regression diagnosis and make fewer costly mistakes in production. The article offers practical guidance for those stuck between academic rigor and dangerous illusion of control.