Проверочный набор — зафиксированная выборка задач с эталонными ответами, по которой систему оценивают при каждой смене конфигурации; бенчмарк — набор плюс процедура прогона плюс метрики. Без них «стало лучше» и «кажется, стало лучше» неотличимы, а решения принимаются по впечатлению от отдельных удачных ответов.
Зачем нужен проверочный набор
Настройка без набора — блуждание. У ИИ-системы десятки степеней свободы: нарезка документов, эмбеддинг, гибридность поиска, k, промпт, модель. Без фиксированной меры после каждой итерации невозможно отличить улучшение от регрессии, а команде нечего предъявить заказчику, кроме анекдотов про удачные ответы.
Набор — это фиксация распределения. Он кодирует, какие вопросы считать типичными: доли тем, формулировок, вопросов без ответа. Все версии системы сравниваются на одном распределении; смена набора обнуляет историю сравнений — прошлые и новые цифры несопоставимы.
Набор экономит деньги. Прогон 100–200 вопросов автоматикой — минуты и центы; обнаружение той же регрессии в эксплуатации — недели и жалобы пользователей. Набор окупается первой же пойманной перед релизом деградацией.
Как строить набор
Источник — реальные обращения. Вопросы берут из журналов поддержки, переписки, поисковых запросов к базе знаний. Вопросы, придуманные разработчиком системы, систематически «чище» боевых — без опечаток, сленга и пересечения тем; набор из них переоценивает систему на 10–20 пунктов (иллюстративно).
Размер — 50–200 вопросов. Меньше 50 — разницу в пять пунктов не отличить от шума; больше 200 — затраты на поддержание растут быстрее точности вывода. Для сравнения версий рабочий диапазон — 100–200, для быстрой прикидки изменений — 50.
Пятая часть — вопросы без ответа. Если в данных ответа нет, эталон — «не нашлось». Без таких вопросов не измерить корректность отказа, а система, которая не умеет отказывать, выдумывает на каждом незнакомом вопросе.
Покрытие важнее объёма. В наборе представляют типы документов и тем, формы вопроса — короткий, развёрнутый, с опечаткой, с пересечением тем — и два-три перефразирования одного факта для проверки чувствительности к формулировке. Восемьдесят стратифицированных вопросов информативнее трёхсот однотипных.
Разметка — главная статья затрат. Вопрос с эталонным фрагментом и каноническим ответом занимает 5–15 минут эксперта; набор в 150 вопросов — два-четыре дня работы. Эталоны формулируют до настройки системы, чтобы не подгонять их под её ответы; о самой процедуре — в статье про разметку данных.
Бенчмарк: набор плюс процедура плюс метрики
Набор — необходимая, но не достаточная часть. Бенчмарк воспроизводим, когда зафиксированы: версия набора, конфигурация системы — модель, промпт, k, пороги, — параметры генерации, метрики и способ их подсчёта, судья и его промпт, если оценка автоматическая. Изменение любого элемента — новый эксперимент, а не сравнимый прогон.
Прогон — по протоколу. Один набор, одна конфигурация, судья с температурой 0, повторные прогоны для стохастики. Результаты и конфигурации регистрируют в трекере экспериментов; без записи сравнение существует только в памяти участника.
Метрики выбирают под решения. Для RAG это связка «поиск плюс ответ» — recall@k, faithfulness и другие, см. метрики качества RAG; для классификации — матрица ошибок и её производные. Общий принцип: метрика должна соответствовать решению, которое по ней принимают, иначе это украшение отчёта.
Дрейф набора и его обновление
Набор стареет вместе с базой знаний и потоком. Меняются документы, тарифы, продукты; вопросы прошлых кварталов перестают отражать текущие обращения. Классический симптом: система «стоит на месте» по бенчмарку и деградирует в эксплуатации.
Обновление — регулярный процесс. Вопросы из ошибок эксплуатации добавляют постоянно; эталоны пересматривают при заметных изменениях базы знаний; долю «боевых» вопросов держат не выше трети, иначе набор выродится в коллекцию трудных случаев и средние цифры уйдут вниз без реальной деградации. Версии набора нумеруют и сравнивают конфигурации на одной версии.
Пересборка versus накопление. Каждые один–три месяца полезно пересобрать стратификацию заново по свежему журналу обращений и сверить, не сместились ли доли тем; о причинах смещения — в статье про дрейф данных. Регулярные прогоны бенчмарка в проде — часть мониторинга ИИ-систем.
Публичные бенчмарки: зачем и почему не переносятся
Зачем. Публичные наборы дают первичный отсев: сравнение моделей на общих задачах сужает шорт-лист из десятков кандидатов до двух-трёх для проверки на своих данных. Это дёшево и быстро; этап отсева по публичным лидербордам при выборе модели оправдан.
Почему не переносятся. Публичный бенчмарк измеряет качество на своём распределении: другой домен, другой язык вопросов, другая доля вопросов «без ответа», другая разметка эталонов. Модель из топа лидерборда на вашей базе знаний может проиграть модели на две позиции ниже; расхождение в 10–20 пунктов между публичной и внутренней оценкой — обычное дело (иллюстративно).
Опасность натаскивания. Публичные вопросы попадают в обучающие данные и промпты разработчиков моделей; рост на бенчмарке частично отражает знакомство с ним, а не общий уровень. Собственный набор защищён от этого по построению — его никто не видел до вас.
Типичные ошибки
Строить набор после настройки системы. Эталоны, написанные под ответы готовой системы, закрепляют её текущее поведение как норму; набор теряет способность находить ошибки. Эталоны фиксируют до настройки или независимо от неё.
Оценивать на наборе, по которому настраивали. Это утечка: цифры завышены, решение о внедрении принимается по иллюзии. Настройка и контроль разделяются; подробно — в статье про кросс-валидацию.
Хранить протокол в голове исполнителя. Неписаные договорённости о том, «как правильно считать», делают прогоны невоспроизводимыми; протокол и версии набора — часть репозитория проекта наравне с кодом.
Гнаться за размером вместо покрытия. Тысяча однотипных вопросов даёт узкую уверенность; провалы на редких, но дорогих категориях остаются невидимыми до эксплуатации.
Частые вопросы
Кто должен размечать набор?
Те, кто знает правильные ответы: эксперты поддержки для обращений, юристы для договоров, аналитики для регламентов. Разработчик системы не должен размечать сам: у него конфликт интересов и готовность угадывать намерение эталона под поведение системы.
Как часто пересматривать эталоны?
При каждом заметном изменении базы знаний — новых регламентах, смене тарифов, удалении документов. Вопросы с эталонами на удалённые документы автоматически становятся вопросами «без ответа»; это отслеживают явно, а не обнаруживают по упавшей метрике.
Можно ли купить готовый набор?
Для типовых задач — частично: стандартные наборы для тональности или распознавания сущностей годятся для смежных компонентов. Для доменных вопросов — вашей базы знаний, ваших обращений — готового набора не существует по построению; его можно только собрать у себя.
Что делать, если на наборе улучшение, а в эксплуатации нет?
Набор перестал отражать поток. Сверьте распределение вопросов набора с журналом обращений за последний месяц по темам и форме; добавьте 10–20 свежих боевых вопросов с эталонами и перепрогоните обе версии — обычно расхождение снимается.
Нужен ли бенчмарк, если система уже в проде?
Нужен сильнее, чем до запуска: каждое обновление модели, промпта или базы знаний — регрессионный риск. Прогон набора перед релизом стоит минуты; одна незамеченная деградация в проде стоит дороже всего набора.