Меня зовут Алёна, и я более пяти лет занимаюсь оценкой языковых моделей: участвовала в создании таких русскоязычных бенчмарков как Russian SuperGLUE, ruMTEB, куратор проекта Альянса в сфере искусственного интеллекта «MERA» (бенчмарка для оценки русскоязычных LLM), и создатель множества других проектов в области тестирования генеративных моделей. На конференциях, встречах с командами и обсуждениях LLM-продуктов я часто слышу один и тот же вопрос: «А как вообще правильно оценивать LLM на практике?», и почти всегда за этим вопросом стоит один и тот же разрыв.

С одной стороны, есть академический мир. В нём бенчмарк — это методология, датасеты, метрики, контроль качества, проверка утечек, воспроизводимость, анализ ошибок и месяцы работы. Хороший академический тест должен быть достаточно строгим, чтобы его результатам можно было доверять.

С другой стороны, есть индустриальная практика. Команде нужно выбрать модель, проверить новую версию промпта, сравнить два пайплайна, выкатить RAG-систему, оценить агентную систему или понять, не стало ли хуже после очередного изменения. И всё это не через полгода, а, желательно, к следующему релизу.

На этом месте и возникает типовая развилка. Часть команд не оценивает почти ничего: несколько ручных примеров перед демо, быстрый просмотр ответов глазами — и решение «вроде, работает». Другая часть пытается сделать «минимально нормальную» оценку: 10–20 запросов, LLM-судья, средний балл, табличка для отчёта. Проблема в том, что второй вариант часто выглядит как контроль качества, но им не является. Более того, он может быть опасен, потому что создаёт уверенность там, где на самом деле есть только очень слабый сигнал. При этом я хорошо понимаю, почему так происходит. Дело не в том, что команды ленятся или не понимают важности оценки. Скорее, наоборот: они работают в темпе, для которого классический академический подход часто является слишком тяжеловесным.

Скорости разработки выросли. Модели обновляются. API меняют поведение. Пользовательские сценарии появляются быстрее, чем под них успевают собрать полноценный тест. Бенчмарк, который полгода аккуратно готовили, к моменту публикации уже может частично устареть, или утечь при публикации.

Но если ждать идеальной оценки нельзя, это не значит, что нужно соглашаться на её имитацию.
Здесь я хочу разобрать несколько типовых сценариев из практики: маленькая корзина примеров, LLM-судья, невоспроизводимые результаты, синтетические тесты «из ChatGPT» и выбор модели по одному числу. И на каждом примере показать, как можно улучшить оценку минимальными инженерными действиями, без превращения процесса в академический проект на полгода.

Почему индустрия часто оценивает LLM «на минималках»

«Как выбирают модель под задачу?»

По данным исследования «Как реально выбирают LLM для своего кейса в 2025 году?» наших коллег из LLM Arena, 26,7% команд вообще не используют бенчмарки перед вводом LLM в эксплуатацию. Не «используют недостаточно хорошие бенчмарки», не «используют тесты с пробелами», а именно не используют никаких.

Остальные тоже не всегда находятся в сильно лучшей позиции. Да, многие команды проводят собственные проверки или смотрят на готовые бенчмарки, но на практике результаты бенчмарков редко становятся финальным ответом на вопрос «какую модель брать в продукт». Чаще это один из вспомогательных сигналов. Это видно и по ответам в исследовании LLM Arena: среди используемых источников упоминаются lmarena.ai, llmarena.ru, MERA, Open LLM Leaderboard, MTEB, MMLU/MMLU‑Pro, количество использований на OpenRouter и другие публичные индикаторы. То есть команды не столько ищут «один правильный тест», сколько собирают картину из разных сигналов.

При этом внутренняя оценка в компаниях часто всё равно сводится к небольшой ручной корзине примеров под конкретный рабочий сценарий, субъективному сравнению ответов или LLM-as-a-Judge без отдельной проверки устойчивости такого подхода.

На первый взгляд, это выглядит странно: LLM уже внедряют в поддержку, поиск по документам, аналитику, кодогенерацию, ассистенты и агентные сценарии — а системной оценки качества часто всё ещё нет. Но я бы не стала объяснять это ленью или некомпетентностью команд. Скорее, это симптом структурной проблемы: скорость разработки LLM-продуктов выросла быстрее, чем культура их оценки.

Хороший бенчмаркинг всегда был дорогим занятием. Если посмотреть на академическую практику, то нормальная оценка — это не «прогнали модель на датасете и получили число». Это довольно длительный и кропотливый процесс.

• Нужно чётко определить объект оценки: мы измеряем модель, систему, агент, отдельный навык или конкретный сценарий? Например, «качество ответов» — плохое определение объекта оценки. Оно слишком общее. А вот «точность извлечения реквизитов из договоров поставки», «способность агента корректно вызвать нужный инструмент в многошаговом сценарии» или «качество ответа на вопросы по внутренней базе знаний с обязательной ссылкой на источник» — уже гораздо ближе к инженерной постановке.

• Нужно определить метрики. Для классификации это может быть accuracy, F1 или ROC-AUC. Для извлечения сущностей — precision, recall, F1 по типам сущностей. Для RAG-системы — отдельно качество поиска (retrieval), обоснованность (groundedness) ответа, его полнота, отсутствие неподтверждённых утверждений. Для агента — доля успешных прохождений (success rate) сценария, точность использования инструментов (tool-call accuracy), количество лишних шагов, стоимость выполнения и доля завершённых без вмешательства человека задач.

• Нужно описать структуру и дизайн теста: какие типы задач в него входят, почему выбраны именно они, какие домены и уровни сложности покрыты, какие выводы по результатам делать можно, а какие нельзя. Например, если бенчмарк проверяет только фактологию на коротких текстах (factual QA), то по нему нельзя делать вывод, что модель хорошо работает с длинными документами, многошаговыми инструкциями или агентным применением инструментов (tool use). Если тест состоит только из задач на русском языке из общего домена, то по нему нельзя уверенно судить о качестве модели при работе с юридическими, медицинскими или внутренними корпоративными документами.

• Дальше начинается работа с данными: сбор, разметка, контроль качества, поиск дублей, шума и неоднозначных примеров, проверка разбиения на обучающую и тестовую выборки, а также возможных утечек. После этого нужно обеспечить воспроизводимость: зафиксировать данные, промпты, параметры запуска, версию модели и сам конвейер оценки. Результат должен быть не просто «полученным однажды», а проверяемым и воспроизводимым. Другая команда должна понимать, как его повторить, какие артефакты для этого нужны и где проходят границы применимости вывода.

В академии это считается базовым минимумом. Например, если вы делаете бенчмарк уровня NeurIPS, то недостаточно просто сказать: «Мы измеряем качество ответов модели». Нужно объяснить, какую способность вы проверяете, на каких данных, каким способом и в каких границах применимы полученные результаты.

Хорошая точка входа в такие требования — NeurIPS Paper Checklist. В нём явно поднимаются вопросы воспроизводимости, прозрачности, ограничений работы, данных, кода, параметров экспериментов и корректности заявленных выводов. Для датасетов и бенчмарков можно отдельно посмотреть NeurIPS 2025 Datasets & Benchmarks Track Call for Papers. Там хорошо видно, что к бенчмаркам предъявляются не только требования «дать датасет и score», но и требования к доступности данных и кода, документации, метаданным, воспроизводимости и корректному описанию области применимости. Актуальная эволюция этого подхода видна в NeurIPS 2026 Evaluations & Datasets Track. Само переименование трека из Datasets & Benchmarks в Evaluations & Datasets хорошо отражает сдвиг: оценка становится отдельным объектом научного анализа. Важно уже не только то, какой датасет собран, но и какие утверждения он позволяет делать, при каких предположениях, с какими ограничениями и для каких сценариев.

Для индустрии такой подход часто выглядит слишком медленным. И это тоже понятно.
Раньше цикл разработки был длиннее: релизы раз в квартал, код проходил проверку, QA успевал встроиться в процесс. Сейчас LLM-инструменты и агентные системы ускоряют разработку настолько, что за то же время появляется кратно больше прототипов, фич и изменений. Ждать полгода, пока появится идеальный тест, нельзя: к моменту готовности он уже может частично устареть.

Более того, быстро меняется сама предметная область. Модели обновляются, API меняют поведение, появляются новые паттерны использования, пользователи начинают применять систему не так, как предполагала команда. Бенчмарк, который хорошо описывал задачу три месяца назад, сегодня может покрывать только часть реальных сценариев.

Отсюда и возникает соблазн: «Давайте не будем усложнять. Возьмём несколько примеров, проверим глазами, добавим LLM-судью — и поедем дальше». Проблема не в том, что быстрая оценка сама по себе плохая. В эксплуатации быстрые проверки нужны. Проблема начинается тогда, когда слабый сигнал начинают воспринимать как полноценное подтверждение качества. Такая оценка не помогает управлять системой — она просто создаёт отчётность и ощущение контроля.

Это хорошо видно и по международной практике. Отдельных результатов на бенчмарках уже недостаточно, поэтому команды всё чаще смотрят не на один тест, а на агрегированные аналитические ресурсы вроде Artificial Analysis или llm-stats.com, где рядом собираются разные параметры: качество, цена, скорость генерации, latency, стоимость токенов, размер контекста и другие характеристики. Потому что выбор модели в реальном продукте почти никогда не строится только на академическом качестве. Обычно это баланс нескольких критериев:

• качество на релевантных задачах;

• цена инференса;

• latency и throughput;

• риск галлюцинаций;

• стабильность поведения;

• возможность развернуть модель в нужном контуре;

• совместимость с текущей инфраструктурой;

• поддержка нужного языка, домена и формата работы.

Пример: модель может быть сильнее на MMLU, но проигрывать по latency и стоимости. Или хорошо отвечать в диалоге, но хуже работать с извлечением фактов из внутренних документов. Или показывать приличный общий score, но нестабильно вызывать инструменты в агентном сценарии. В каждом из этих случаев «лучшая модель» будет разной.

Предлагаю далее разобрать несколько типовых случаев, где оценка вроде бы есть, но на практике почти не снижает риски (маленькая корзина примеров, LLM-судья, невоспроизводимые score, синтетические тесты и выбор модели по одному числу), и на примере этих классических антипримеров посмотреть, как минимально улучшить оценку без превращения процесса в академический проект на полгода.

Сценарий 1. Корзина из двадцати примеров и LLM-судья

Типичный процесс выглядит так:

1. Команда собирает 10–20 «типичных» запросов.

2. Прогоняет их через систему.

3. Просит GPT-4, Claude, GigaChat или другую модель оценить ответы по шкале от 1 до 5.

4. Считает средний score.

5. Делает вывод: «Стало лучше» или «релизить можно».

На первый взгляд это уже лучше, чем ничего. На практике у такого подхода есть несколько проблем.

Проблема 1. Статистическая незначимость

На 20 примерах нельзя надёжно измерить изменение качества. Если новая версия получила 4,3 вместо 4,1, это может быть реальное улучшение, а может быть обычный шум.

Особенно плохо это работает, когда система должна покрывать много разных типов запросов: короткие вопросы, длинные инструкции, неаккуратные пользовательские формулировки, документы с неоднозначностями, запросы на отказ, многошаговые сценарии.

Двадцать примеров почти никогда не покрывают это разнообразие.

Проблема 2. Нерепрезентативность

Такие корзины часто собирают «из головы». Команда берёт примеры, которые кажутся ей типичными, но реальные пользователи почти всегда ведут себя иначе. Они формулируют запросы неполно, смешивают несколько задач в одном сообщении, используют внутренний жаргон, прикладывают грязные документы, меняют условия по ходу диалога. Именно на таких сценариях LLM-системы часто и падают.

Проблема 3. Смещение LLM-судьи

LLM-as-a-Judge — полезный инструмент, но не магия. Если судья плохо откалиброван, нестабилен или похож на оцениваемую модель, то он может систематически завышать или занижать оценки.

Например, если модель одного семейства оценивает ответы модели того же семейства, то легко получить self-bias: судья предпочитает стиль, структуру или рассуждения, похожие на собственные.

Кроме того, API больших закрытых моделей меняются. Сегодня один и тот же промпт модели-судьи ( judge prompt) даёт одну оценку, через месяц — другую. Для продуктовой аналитики это проблема: вы уже не понимаете, изменилась ваша система или судья.

Что минимально можно сделать 

Не нужно сразу создавать идеальный бенчмарк, но можно сделать несколько простых шагов.

1. Увеличить корзину хотя бы до сотен примеров

Минимально рабочий ориентир — сотни примеров, а не десятки. Если система уже в эксплуатации, то лучше брать данные из реальных логов: обезличивать, чистить, кластеризовать и собирать покрытие по типам запросов.

Важно не просто набрать 500 случайных сообщений, а разложить их по категориям:

• частые сценарии;

• редкие, но критичные сценарии;

• граничные случаи;

• негативные сценарии;

• запросы с неполной информацией;

• запросы, где система должна отказаться отвечать;

• длинный контекст;

• нестандартные форматы входа.

Такой набор всё ещё не будет идеальным, но он уже начнёт отражать реальное поведение пользователей.

2. Разделить первичная проверка (smoke test) и тестовый сет 

Не стоит одним и тем же маленьким набором проверять всё. Полезно иметь:

• smoke test или sanity check — 10-30 примеров для быстрой проверки, что система вообще не сломалась;

• основной тестовый set — сотни или тысячи примеров для сравнения версий;

• regression set — сценарии, на которых система уже ошибалась раньше;

• adversarial, edge cases — специально сложные случаи.

Тогда быстрые проверки остаются быстрыми, но не подменяют собой оценку качества.

3. Использовать LLM-судью аккуратно

Если нужен LLM-as-a-Judge, то лучше не ограничиваться промптом «поставь оценку от 1 до 5». В таком виде судья быстро превращается в генератор красивых, но плохо интерпретируемых чисел.

Минимально нужны:

• понятная рубрика оценки;

• критерии, по которым судья принимает решение;

• примеры хороших и плохих ответов, желательно из конкретного домена;

• проверка согласованности с человеческой разметкой хотя бы на небольшой части данных;

• фиксация версии модели-судьи, judge-промпта и параметров запуска;

• хранение не только итогового score, но и артефактов оценки: исходного запроса, ответа модели, решения судьи и комментария к оценке.

Важно помнить, что LLM-судья тоже является моделью, а значит, наследует типовые смещения. Он может предпочитать более длинные ответы, более уверенный стиль, ответы в определённой структуре или ответы моделей, похожих на него самого. При попарном сравнении может проявляться position bias: ответ, показанный первым или вторым, получает преимущество просто из-за позиции. Поэтому судью нужно не просто «подключить», а хотя бы минимально откалибровать.

Есть три варианта:

• Первый — большая модель из коробки: GPT-4, Claude, Gemini и другие. Это хороший способ быстро начать: не нужно ничего обучать, можно за день собрать первичный конвейер оценки и посмотреть, где система явно ошибается. Но для регулярной оценки в эксплуатации у этого подхода есть ограничения. API обновляется, поведение модели может меняться, стоимость на больших объёмах становится заметной, а воспроизводимость хуже контролируется. Такой судья подходит для быстрой проверки гипотез, но его рискованно делать единственным источником истины.

• Второй — обучать судью с нуля под свою задачу. Это даёт максимальный контроль, но требует данных, разметки, ML-экспертизы и времени. Такой путь оправдан, если у вас очень специфическая предметная область, высокая стоимость ошибки и готовых решений действительно недостаточно. Например, если нужно оценивать ответы в узкой юридической, медицинской или промышленной области, где общая модель-судья регулярно ошибается в критериях качества.

• Третий — использовать готового специализированного судью и при необходимости донастроить его под свою область. Это часто самый прагматичный путь: вы не начинаете с нуля, но получаете больше контроля, чем при использовании внешнего API «как есть». Например, для русскоязычных задач можно рассматривать Pollux Judge: базовая модель Qwen-3, дообученная на синтетических примерах и выровненная с человеческими оценками. Доступны версии на 4, 7 и 32 млрд параметров — можно выбрать вариант под свои ограничения по качеству, скорости и ресурсам. Такого судью можно встроить в конвейер оценки и использовать как более стабильный компонент.

Смысл не в том, что специализированный судья автоматически решает все проблемы. Его всё равно нужно проверять на ваших данных, но если у модели-судьи уже есть проверка на согласованность с человеческими оценками, то это лучше, чем каждый раз полагаться на закрытую модель без контроля версии и без понимания, насколько её оценки соответствуют вашей задаче. Подробнее про Pollux Judge и пример сравнения judge-моделей мы рассказывали в отдельном Хабре.

И главное: LLM-as-a-Judge не должен полностью заменять человеческую оценку. Хорошая практическая схема — держать небольшой откалиброванный людьми набор, периодически прогонять на нём судью и проверять, не разъехалась ли его логика с экспертной разметкой. Тогда LLM-судья становится не «оракулом», а полезным инструментом масштабирования оценки.

---

Сценарий 2. «Я точно помню, что было 87%»

Второй распространённый случай — невоспроизводимая оценка.

Команда один раз получила красивое число: accuracy 87%, средний score 4,2, F1 0,71. Через неделю пытается повторить прогон — и получает другое значение. Иногда немного другое. Иногда сильно другое. Иногда запуск вообще не воспроизводится.

Причины обычно типовые:

• изменилась версия модели;

• поправили шаблон промпта;

• обновился evaluation harness;

• поменялась версия датасета;

• не зафиксировали параметры генерации;

• изменилась обработка ответа модели;

• не сохранили сырые выходы моедли;

• забыли seed;

• запускали через другую инфраструктуру;

• поменялась версия библиотеки, токенизатора или бэкенд-инференса.

В классическом ML такие вещи тоже важны, но в LLM-оценке они становятся критичными. Здесь итоговая оценка зависит не только от самой модели, но и от того, как именно вы задали инструкцию, в каком формате подали варианты ответа, как обработали вывод, где обрезали генерацию и каким кодом посчитали метрику.

Хороший публичный пример — история с LLaMA и MMLU в Open LLM Leaderboard. После выхода LLaMA в 2023 году сообщество стало прогонять модели через публичные списки лидеров, и оказалось, что MMLU-результаты LLaMA, полученные через EleutherAI LM Evaluation Harness на Hugging Face Open LLM Leaderboard, заметно отличаются от чисел, опубликованных в статье LLaMA.

На первый взгляд, это выглядит как классическая проблема: «в статье одно, на лидерборде другое». Но при разборе выяснилось, что дело не обязательно в модели. Важны подробности реализации оценки.

У MMLU на тот момент фактически было несколько разных реализаций: оригинальная от авторов бенчмарка, реализация Stanford HELM и реализация EleutherAI LM Evaluation Harness. Они по-разному работали с форматированием промптов, выбором ответа, вероятностями токенов и парсингом результата. Формально все запускали «MMLU на LLaMA», но на практике это были разные конвейеры оценки. Поэтому и числа расходились. Разбор можно посмотреть здесь. Полезные ссылки для контекста: статья LLaMA, EleutherAI LM Evaluation Harness, Stanford HELM.

Это хороший пример не потому, что «кто-то плохо посчитал», а потому что он показывает саму природу проблемы. Одно и то же название бенчмарка ещё не означает один и тот же тест. Если отличаются промпты, few-shot примеры, формат ответа, способ выбора варианта, парсер или версия harness, то сравнивать итоговые числа напрямую уже рискованно.

Для внутренней продуктовой оценки это означает простую вещь: если вы не фиксируете конвейер оценки, то вы не измеряете качество системы во времени. Вы каждый раз запускаете немного другой эксперимент.

С агентными системами эта проблема становится ещё заметнее.

В обычном LLM-бенчмарке мы чаще всего оцениваем модель в относительно простом контуре: подали промпт, получили ответ, применили парсер, посчитали метрику. В агентном сценарии мы оцениваем уже не «голую» LLM, а систему: модель плюс agent harness, инструменты, память, планировщик, правила вызова инструментов, ограничения по шагам, обработку ошибок, sandbox, budget и оценщик.

Здесь важно не смешивать три разных слоя:

• evaluation framework — то, чем мы измеряем результат: бенчмарк, датасет, тестовое окружение, оценщик, логика подсчёта баллов;

• agent harness — то, во что обёрнута LLM: планировщик, исполнитель, инструментарий, память, повторы, разрешения, трассировка, логика восстановления;

• model/backend configuration — сама модель и параметры её запуска: версия модели, температура, максимальное количество токенов, инфраструктура для инференса, токенизатор, контекстное окно, системный промпт.

Если поменять любой из этих слоёв, то итоговый результат может измениться, хотя формально «модель» осталась той же.

Например, в coding-agent задачах результат зависит не только от способности модели написать корректный патч. Он зависит и от того, как agent harness работает с репозиторием: какие файлы видит агент, может ли запускать тесты, как применяет дифф, сколько попыток разрешено, есть ли доступ к оболочке, какой таймаут на задачу и как обрабатываются ошибки.

Именно поэтому в агентных бенчмарках вроде SWE-bench, WebArena, τ-bench или AgentLab всё больше внимания уделяется не только финальному ответу, но и окружению выполнения, траекториям, логам инструментов и оценщикам.

Для агентов фраза «одна и та же модель на одном и том же бенчмарке» ещё не означает «один и тот же эксперимент». Один запуск мог идти через простой ReAct-harness без памяти, другой — через полноценную агентную обвязку с планировщиком, перевызовом инструментов и восстановлением после ошибок. Результат будет разным, но это уже не только разница в качестве модели.

Поэтому в агентной оценке корректнее писать не просто: «Model X получила 43%», а лучше так: «Model X в harness Y, с таким набором инструментов, таким бюджетом, такой политикой и таким оценщиком получила 43%».

Если оценка используется только внутри команды, то невоспроизводимость мешает инженерной работе: нельзя понять, стало лучше или хуже после изменения промпта, модели, ретривера, политики агентов, конфигурации инструментов или фреймворка оценки. Если результаты показываются клиентам, партнёрам, регулятору или публикуются в статье, то невоспроизводимость становится уже внешним риском. В какой-то момент вас могут попросить объяснить, почему заявленное «87%» больше не получается повторить.

Практическое правило здесь простое: если результат нельзя воспроизвести, считайте, что его не было. Минимально нужно фиксировать:

Сценарий 3. «ChatGPT, сгенерируй мне тест»

Третий антипример особенно соблазнителен, потому что выглядит продуктивно. Команде нужен датасет для оценки, например, в области юридических документов, поддержки клиентов или внутренней базы знаний. Кто-то предлагает: «Давайте попросим LLM сгенерировать 500 вопросов и эталонных ответов».
Через час есть таблица. В ней вопросы, ответы, категории, сложность. Выглядит как готовый набор для оценки. Проблема в том, что такой тест часто измеряет не то, что нужно.

Проблема 1. Однотипность

LLM хорошо генерирует то, что легко генерировать: прямые вопросы, очевидные ответы, аккуратные формулировки. Реальные пользовательские запросы обычно грязнее и разнообразнее. В результате датасет только из синтетических примеров переоценивает качество системы.

Проблема 2. Ошибки в эталонных ответах

В узких предметных областях LLM может уверенно ошибаться. Особенно если речь идёт о юридических, медицинских, финансовых, инженерных или внутренних корпоративных данных.

Тест с неправильным эталонным ответом не просто бесполезен. Он вреден: система может получить высокий результат за неправильное поведение.

Проблема 3. Утечки и переобучение на стиль

Если синтетические данные сгенерированы моделью, похожей на ту, которую вы потом оцениваете, то можно начать измерять не качество решения задачи, а соответствие стилю генератора.

В худшем случае возникает утечка данных: модель уже видела похожие формулировки, шаблоны или ответы в обучении/дообучении.

Что минимально можно сделать 

Синтетические данные можно использовать, но не как единственный источник правды. Более безопасная схема:

1. Взять реальные запросы из логов или экспертно собранные сценарии.

2. Разложить их по типам задач.

3. Синтетикой добалансировать редкие классы.

4. Проверить эталонные ответы человеком или предметным экспертом.

5. Отдельно пометить синтетические примеры, чтобы не смешивать их с реальным трафиком.

6. Хранить версию генератора и промпта, которым создавались данные.

Синтетика хорошо подходит для расширения покрытия. Но если весь тест состоит только из синтетики, то он почти наверняка будет иметь слепые зоны.

Минимальный набор правил, который уже работает

В завершение давайте соберём минимальный чек-лист действий — набор практик, который помогает аккуратнее оценивать LLM-системы и не обманываться красивыми, но слабо обоснованными числами.

1. Не начинайте с нуля, если уже есть готовый бенчмарк. Для общих способностей можно использовать MMLU, MT-Bench, HELM, lm-evaluation-harness. Для русского языка — MERA и другие русскоязычные наборы. Готовый бенчмарк не ответит на все вопросы про вашу эксплуатацию, но даст базовую точку отсчёта и позволит не изобретать каждую метрику заново.

2. Соберите свой эксплуатационный набор для оценки. Открытые бенчмарки полезны, но они не знают ваших пользователей, документов, ограничений и типовых ошибок. Поэтому я бы обязательно собирала отдельный набор из реальных или максимально близких к реальным сценариев: логов, обращений пользователей, типовых документов, ошибок прошлых релизов и критичных бизнес-сценариев. Именно он должен отвечать на вопрос: «Работает ли система в нашей задаче?»

3. Разделяйте быстрые проверки и настоящую оценку. Тесты sanity check нужны, чтобы понять, что система не развалилась после изменения; регрессионный набор — чтобы не вернулись старые ошибки; основной оценочный — чтобы сравнивать версии и принимать продуктовые решения. Я бы не пыталась одним маленьким набором из 20 примеров закрыть все эти задачи сразу.

4. Фиксируйте воспроизводимость. Каждый запуск должен оставлять след: версия модели, данные, промпты, параметры генерации, версия harness, сырые выходные данные, метрики, логи и даты запуска. Для агентов дополнительно — agent harness, инструменты, политика, бюджет, песочница и трассировки. Без этого оценка быстро превращается в разговор: «кажется, на прошлой неделе было 87%».

5. Не верьте одному числу. Один результат почти всегда слишком хорошо выглядит и слишком мало объясняет. Я бы смотрела не только на среднее значение, но и на разрезы: типы задач, сложность, длину контекста, домены, критичные ошибки, стоимость, latency, стабильность. Часто важнее не то, что средний результат вырос на 2%, а то, что система перестала ломаться на конкретном классе запросов.

6. Используйте LLM-судью как инструмент, а не как источник истины. LLM-as-a-Judge может сильно ускорить оценку открытых ответов. Но его тоже нужно проверять: сравнивать с человеческой разметкой, фиксировать промпт судьи и версию модели, смотреть устойчивость оценок и хранить объяснения, если они нужны для анализа ошибок.

Главная мысль простая: плохая оценка не нейтральна. Она создаёт ощущение, что качество под контролем, хотя на самом деле вы могли просто получить красивое число на слабом тесте. Честное «мы пока не знаем» лучше, чем уверенное «у нас 4,2 из 5», если за этим числом стоят двадцать примеров, нестабильный судья и невоспроизводимый запуск.

Нормальная production-оценка начинается не с идеальной науки, а с инженерной дисциплины: реальные сценарии, воспроизводимые запуски, понятные метрики, разбор ошибок и осторожное отношение к любому красивому результату.

Удачи на вашем пути к честной и воспроизводимой оценке =)