Как собрать контрольную выборку до дообучения модели

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

Шаг 1. Опишите рабочее решение

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

Запишите критическую ошибку отдельно. Перепутанная тема обращения неприятна, но исправима. Неверная сумма возврата или вызов функции удаления могут быть недопустимы даже при высоком среднем балле. Порог остановки задаётся до просмотра кандидатов.

Шаг 2. Берите случаи из работы

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

Для первого пилота часто достаточно 100–300 примеров. Меньший набор годится для отладки формата, но плохо показывает устойчивость. Огромная выборка не спасает, если она состоит из почти одинаковых строк. Разнообразие источников, форматов и сложностей важнее круглого числа.

Шаг 3. Напишите инструкцию разметчикам

Каждое поле должно иметь определение, положительный пример, пограничный случай и правило «неизвестно». Если два специалиста по-разному понимают класс «срочно», модель не исправит разногласие. Дайте двадцать примеров двум людям независимо и сравните. Несовпадения обсуждаются, а инструкция уточняется до основной разметки.

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

Шаг 4. Разделите данные до эксперимента

Обучающая часть используется для изменения весов. Валидационная помогает выбирать параметры. Закрытая контрольная часть открывается только для итогового сравнения. Похожие сообщения одного клиента, версии одного документа или кадры одного ролика должны попадать в одну часть, иначе модель увидит почти тот же пример во время обучения.

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

Шаг 5. Выберите несколько метрик

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

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

Шаг 6. Сделайте базовую линию

Прогоните текущий процесс: старую модель, простое правило или ручную работу. Запишите не только качество, но и время, цену запроса и длительность проверки. Новая модель сравнивается с реальной альтернативой, а не с нулём. Иногда простой классификатор уступает универсальному API на два процента, но работает локально, быстрее и стабильнее — для бизнеса это может быть лучшим результатом.

Шаг 7. Разбирайте ошибки по причинам

После прогона создайте категории: недостаточно данных, неверная инструкция, ошибка разметки, потеря формата, выдуманный факт, сбой инструмента. Не исправляйте всё новым промптом. Если исходник противоречив, нужен процесс уточнения; если разметчики расходятся, нужна новая инструкция; если модель не держит редкий класс, возможно, требуется балансировка.

Сохраняйте примеры регрессии: новая версия исправила одно, но сломала другое. Такой архив становится постоянным набором для регламента смены моделей.

Шаг 8. Назначьте правило принятия

Решение записывается формулой до финального теста. Например: ни одной критической ошибки, точность обязательных полей не ниже 98%, медианное время проверки меньше текущего на 20%, стоимость принятого ответа укладывается в лимит. Отдельный владелец подтверждает, что риск допустим.

Если кандидат не прошёл, не нужно объявлять пилот провалом. Вы получили карту ошибок и понимаете, где поможет больше данных, изменение задачи или обычный RAG вместо fine-tuning. Это полезный результат.

Шаг 9. Сохраните паспорт теста

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

Частые вопросы

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

Сколько примеров нужно? Для первого решения важнее покрытие сценариев. Начните со 100–300 и расширяйте после анализа неопределённости.

Когда обновлять контрольный набор? При появлении новых форматов, процессов и реальных ошибок. Старую версию сохраняют для сравнимости.