Все решения в работе с моделями — выбор, смена, сжатие, правка промпта — упираются в один вопрос: стало лучше или хуже? Без набора проверочных случаев ответить на него нельзя, и вся работа превращается в перебор наугад.
Набор — самая недооценённая часть проекта. Он собирается за день-два, используется годами и окупается на первом же изменении.
Из чего состоит набор
Реальные случаи. Из обращений, документов, переписки. Не придуманные — это главное правило.
Придуманный пример формулируется удобно: чётко, полными предложениями, с явно названными сущностями. Реальный содержит опечатки, обрывки, лишнее, две темы сразу и отсутствующие данные. Модель, отлично работающая на первых, может проваливаться на вторых — а в работе будут вторые.
Известный правильный результат. Категория, извлечённые поля, эталонный ответ — в зависимости от задачи.
Разбиение по классам. Не единый список, а группы: типовые случаи, сложные, с обозначениями, нестандартные, мусорные. Это позволяет видеть, где именно проседает модель.
Случаи, где правильный ответ — отказ. Обязательно. Без них нельзя проверить, умеет ли система говорить «не знаю» вместо выдумывания.
Размер. 50–100 для начала, 200–300 для устоявшейся системы. Больше не всегда лучше: важнее покрытие разных классов, чем количество однотипных.
Как собрать
Шаг 1. Возьмите поток за период. Обращения за месяц, документы за квартал.
Шаг 2. Отберите разнообразно, а не случайно. Чистая случайная выборка даст в основном типовые случаи, а интересны как раз края. Разумно: половина случайных, половина осознанно отобранных сложных.
Шаг 3. Разметьте. Правильный результат по каждому случаю.
Шаг 4. Проверьте согласие разметчиков. Пусть двое разметят одни и те же 30 случаев независимо. Расхождение между людьми — верхняя планка того, что можно требовать от модели.
Этот шаг пропускают, а он самый информативный: если два сотрудника размечают по-разному в 25% случаев, задача поставлена неоднозначно, и чинить надо постановку, а не модель.
Шаг 5. Держите набор отдельно и не правьте под текущее поведение системы. Набор, подогнанный под ответы модели, перестаёт что-либо показывать.
Что мерить
Одной доли верных ответов недостаточно. Минимальный набор:
| Метрика | Что показывает |
|---|---|
| Доля верных по каждому классу | где именно проседает |
| Соблюдение формата | критично для конвейеров |
| Корректность отказа | врёт ли система при нехватке данных |
| Стоимость операции | на реальных текстах |
| Время ответа | среднее и худшее |
| Устойчивость | одинаков ли результат при повторе |
Про формат и отказ. Эти две метрики регулярно расходятся с общей долей верных ответов. Модель может отвечать не хуже, но чаще нарушать схему — в конвейере это означает рост ручной работы.
Про устойчивость. Модель вероятностна. Прогон одного и того же случая дважды может дать разные результаты. Если разброс велик, среднее по одному прогону обманчиво.
Правила честного сравнения
Ошибки в методике встречаются чаще, чем различия между моделями.
Одинаковый промпт для всех. Иначе сравниваются формулировки.
Соблюдение шаблона диалога для каждой модели. У открытых моделей он свой, и его нарушение молча снижает качество — самая частая причина ложных выводов — «Открытые модели для русского».
Одинаковые параметры генерации или рекомендованные для каждой модели — но осознанно, а не как получилось.
Несколько прогонов. Хотя бы три на случай, с усреднением. Один прогон при вероятностной системе — это лотерея.
Разбор провалов вручную. Числа показывают, что стало хуже; чтение конкретных провалов показывает почему.
Разбор: сравнение, которое обмануло
Задача. Выбор модели для извлечения данных из документов.
Первый заход. Три кандидата, набор из 60 документов, один прогон. Победитель определился явно: одна модель дала заметно лучший результат.
Что насторожило. Разрыв был слишком велик для моделей близкого класса.
Что нашли при проверке методики.
Первое: один прогон. Повторили трижды — разброс внутри одной модели оказался сопоставим с разницей между моделями. Мнимый победитель был победителем случайно.
Второе: разные параметры генерации. Для одной модели использовались настройки по умолчанию среды запуска, для другой — заданные явно. Модели работали в разных режимах.
Третье: набор был нерепрезентативен. 60 документов отобрали случайно, и в выборку попали почти одни типовые. Различия между моделями проявляются на сложных случаях, которых в наборе почти не было.
Что сделали. Пересобрали набор: 120 документов, из них 40 осознанно отобранных сложных — плохие сканы, нестандартные формы, документы с отсутствующими полями. Уравняли параметры. Прогнали трижды.
Результат изменился. Прежний победитель оказался вторым. Выигравшая модель была устойчивее на сложных случаях — том самом классе, ради которого и делалось сравнение.
Что стоит забрать. Прежде чем делать вывод о моделях, стоит проверить методику. В моей практике ошибки в организации сравнения дают расхождения больше, чем реальные различия между близкими моделями.
Когда прогонять набор
При выборе модели — очевидно.
После любого изменения промпта. Правка, улучшившая один класс случаев, регулярно ломает другой. Без прогона это обнаруживается в эксплуатации — «Версионирование промптов».
При смене версии модели. Поставщик обновил модель — поведение изменилось, даже если название прежнее.
При изменении сжатия или среды запуска.
Регулярно в эксплуатации. Отличает «изменился поток» от «испортилась система».
Последнее особенно важно: без контрольного набора эти два случая выглядят одинаково, а лечатся противоположно.
Частые вопросы
Сколько случаев нужно в проверочном наборе?
Для начала 50–100, для устоявшейся системы 200–300. Важнее количества покрытие разных классов: типовые случаи, сложные, нестандартные, мусорные и обязательно те, где правильный ответ — отказ. Сто разнообразных случаев полезнее пятисот однотипных.
Почему нельзя использовать придуманные примеры?
Потому что они формулируются удобно: чётко, без опечаток, с явно названными данными. Реальные обращения содержат обрывки, две темы сразу и отсутствующие сведения. Модель, отличная на придуманных примерах, может проваливаться на настоящих — а в работе будут настоящие.
Достаточно ли считать долю верных ответов?
Нет. Отдельно нужно считать соблюдение строгого формата и корректность отказа при нехватке данных: эти метрики регулярно расходятся с общей долей верных ответов. Модель может отвечать не хуже, но чаще нарушать схему, что в конвейере означает рост ручной работы.
Почему одного прогона мало?
Модель вероятностна: один и тот же случай при повторе может дать разный результат. Разброс внутри одной модели бывает сопоставим с разницей между разными моделями, и вывод по одному прогону оказывается случайным. Минимум — три прогона с усреднением.
Что делать, если разметчики не согласны между собой?
Чинить постановку задачи, а не модель. Расхождение между людьми — верхняя планка того, что можно требовать от системы: если двое размечают по-разному в четверти случаев, задача сформулирована неоднозначно, и настраивать модель бесполезно.
Как часто прогонять набор?
После каждого изменения промпта, модели, сжатия или среды запуска — это единственный способ отличить улучшение от ухудшения. Плюс регулярно в эксплуатации: набор отличает «изменился характер обращений» от «испортилась система», а эти два случая лечатся противоположно.
Что дальше
Как выбирать модель — «Выбор модели под задачу». Что мерить в системах поиска по документам — «Метрики RAG». Проверка под нагрузкой — «Нагрузочное тестирование». Как не сломать работающее при правках — «Версионирование промптов».
Построение проверочных наборов и регулярная оценка качества входят в работу по разработке и внедрению ИИ.