Оценка качества дообученной модели: почему метрики врут
Отложенная выборка и живой трафик расходятся почти всегда. На фиксированном наборе модель отвечает по шаблону, который мы сами заложили в него при разметке, а в продакшене приходят короткие запросы без контекста, опечатки, смешанные языки и многоходовые диалоги. Метрика на отложенном наборе показывает, насколько модель повторила разметчика, а не насколько она полезна пользователю.
После дообучения расхождение усиливается. Модель переучивается на формат ответа из обучающих примеров и теряет часть базовых умений: падает качество на редких сценариях, растут отказы и обрывы генерации, ломается следование системной инструкции. В отчёте при этом всё зелёное — набор тот же, шаблон тот же, а цена ошибки — откат релиза и потерянное доверие к отчётности.
Мы смотрим на качество по слоям: автоматические метрики на отложенном наборе, оценка LLM-as-judge с размеченными эталонами, ручная экспертиза на спорных примерах. Дополнительно гоняем модель в теневом режиме на реальном потоке и сравниваем с текущим релизом по сегментам — по сценариям, длине диалога, доле отказов и обрывов.
Приёмка релиза модели строится как набор порогов, а не как одно число. Релиз не проходит, если деградация после дообучения задевает защищённые сценарии, даже когда средняя метрика выросла. Такой подход описан в открытых наборах метрик вроде Ragas и дополняется нашими эталонами под задачу.
Что меняется, когда оценка идёт на каждом релизе
Срок проверки перед выпуском — дни вместо недель
Когда набор проверок и метрик зафиксирован, он не собирается заново под каждый релиз. Прогон идёт по одному сценарию на одних данных, а расхождение с предыдущей версией видно в отчёте сразу. Срок проверки перед выпуском сокращается с недель до одного-двух дней — одинаково для дообученной модели и для правки инструкций к ней.
Доля ложных выпусков падает
Метрика на отложенной выборке, оценка моделью-судьёй и слепая проверка экспертами дают три независимых сигнала. Если хотя бы один не проходит порог, релиз не уходит к пользователям — решение становится числовым, а не «вроде стало лучше». Откатов после выката становится кратно меньше: регрессии ловятся до выпуска, а не по жалобам в поддержку.
Единые правила приёмки вместо договорённостей на словах
Порог приёмки фиксируется заранее: какая метрика, на какой выборке, с каким допуском. Единые правила приёмки снимают зависимость от того, кто сегодня проверяет и насколько оптимистичен его отчёт. Спор о вкусах заменяется разбором отклонений по цифрам.
Регулярная оценка релизов накапливает историю
Каждый прогон оставляет срез: версия модели, состав данных, значения метрик. Через несколько релизов видно, какие правки реально двигают качество, а какие — шум. Следующий цикл оценки идёт быстрее, потому что проверяем то, что уже показало эффект.
Варианты проверки релиза: автотесты, эталонный набор, эксперты
Три способа проверки отвечают на разные вопросы и не заменяют друг друга. Автоматические метрики ловят регрессии там, где ответ проверяем формально, но слепы к смысловым сдвигам при верной форме. Судья-контур закрывает свободные ответы, зато наследует смещения той же модели. Экспертная разметка даёт эталон, но её ресурс ограничен и не масштабируется на каждый прогон.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Автоматические метрики (точное совпадение, формат, F1) | Извлечение полей, классификация, вызов инструментов, проверка схемы ответа | Не видит смысловых ошибок при корректной форме; на открытых ответах почти неинформативны |
| Судья-контур на языковой модели | Свободные ответы: тон, полнота, следование инструкции; прогон на сотнях кейсов | Наследует смещения и слепые зоны модели; требует калибровки по экспертным оценкам |
| Экспертная разметка | Эталон для спорных случаев, калибровка судьи, ответы с высокой ценой ошибки | Медленно, зависит от согласия между экспертами, тяжело покрыть весь объём |
| Комбинация слоёв | Релизный контроль: дешёвый слой на каждое изменение, дорогой — на границах | Нужны хранение эталонов, инфраструктура прогонов и разбор расхождений |
Как слои сочетаются
Разделяем их по частоте запуска: формальные проверки идут на каждое изменение и отсекают явные поломки; судья-контур — на расширенной выборке перед релизом, где важно увидеть деградацию смысла; эксперты подключаются на пограничных кейсах и для калибровки судьи. Такой порядок даёт быструю обратную связь и при этом опирается на человеческий эталон там, где он действительно нужен.
От аудита до передачи: как строится контур проверки
Контур проверки собирается так, чтобы решение о приёмке опиралось на повторяемое измерение, а не на впечатление от удачного демо. Порядок работ одинаков для любой задачи — меняются метрики, рубрики и пороги, но последовательность сохраняется: сначала описываем, как качество оценивают сейчас, потом фиксируем эталон и только затем автоматизируем.
- Аудит процесса. Разбираем, как принимаются решения о качестве сегодня: где оценка идёт глазами, где по одному показанному примеру, какие дефекты не фиксируются вообще. На выходе — карта мест, где вердикт не воспроизводится.
- Эталонный набор. Собираем выборку, покрывающую частые сценарии, редкие и пограничные случаи. Набор версионируется вместе с моделью — без него сравнение релизов между собой невозможно.
- Разметка и согласование экспертов. Два-три профильных специалиста размечают примеры независимо, спорные случаи разбираются отдельно, доля совпадений считается до старта работ. Если эксперты не сходятся между собой, автоматическая оценка не даст опоры.
- Автоматическая проверка. Добавляем детерминированные правила и проверку второй моделью: судья получает эталон ответа, рубрику и требования к формату. Судья калибруется на разметке экспертов, и при расхождении выше заданного уровня рубрика переписывается, а не подгоняется результат.
- Калибровка порогов. Для каждого класса ошибок задаём предел отдельно: пропуск критичного дефекта не компенсируется ростом средней оценки. Пороги фиксируются до прогона.
- Регрессионный прогон. Дообученная и базовая модели прогоняются на одном наборе, разница считается по каждой метрике отдельно. Улучшением считается только то, что подтверждено на эталоне.
- Регламент приёмки и передача. Отдаём документ с составом набора, рубриками, порогами и процедурой их пересмотра, а также права на прогоны.
После передачи заказчик запускает проверку сам и видит отклонение до выката. Объём эталона и пороги пересматриваются по мере появления новых сценариев.
Набор метрик, эталонные данные и регламент приёмки
Мы сдаём не только дообученную модель, но и контур её оценки: после передачи команда заказчика может прогнать новую версию на своих данных и получить тот же вердикт, что и мы. Все определения, конфигурации и правила доступа фиксируются в документах, которые не нужно восстанавливать по переписке — их достаточно открыть и выполнить.
- Реестр метрик — таблица, где для каждой метрики указаны определение, способ расчёта, срез данных, порог приёмки и владелец. Расхождения в трактовке закрываются до старта оценки, а не после спорного релиза.
- Размеченный эталонный набор — стратифицированная отложенная выборка: редкие классы и пограничные случаи представлены явно, каждый пример размечен двумя экспертами, спорные разобраны арбитром, согласие разметчиков зафиксировано числом.
- Отчёт о калибровке автоматического судьи — насколько машинная оценка совпадает с экспертной: согласие по классам, доля расхождений, систематическое смещение в пользу длинных или уверенных ответов.
- Политика доступа к данным — кто и на каком основании видит эталон, что обезличивается, как ведётся журнал обращений. Отдельно закрываем риск обучения на проверочной выборке.
- Регламент приёмки — какие метрики и на каких порогах должны сойтись, что делаем при провале одной из них и в каких случаях версия отклоняется целиком.
- Документация контура — схема прогона, словарь метрик, инструкция разметчика и чек-лист запуска: оценку воспроизводит инженер, не участвовавший в разработке.
- Конфигурации и запуск оценки — единый прогон на обезличенном срезе даёт отчёт в фиксированном формате, поэтому результаты двух версий сравниваются построчно.
Кейс: метрики релиза до и после внедрения
Клиент — служба поддержки с базой знаний на несколько тысяч статей, поверх которой работает дообученная модель. Отвечает она не «вообще», а по конкретным документам, и каждый релиз — новая ветка дообучения. Оценивать качество приходилось выборочно и уже после выката: воспроизводимого набора проверок не было.
До внедрения эксперт разбирал вручную около двухсот диалогов на релиз — это два рабочих дня и меньше пяти процентов покрытия. Остальное проверялось по ощущению, спорные ответы оценивались «на глаз», и четыре релиза из десяти возвращались на доработку уже после запуска, когда ошибку видели пользователи.
Как построили замеры
Собрали эталонный набор из шести сотен размеченных диалогов: вопрос, правильный ответ по базе, чего в ответе быть не должно. На нём считаем три вещи — попадание в факт из документа, отсутствие выдуманных деталей, полноту ответа. Прогон автоматизировали через Ragas, а первичную разметку спорных случаев отдали LLM-as-judge: эксперт разбирает не весь релиз, а только расхождения с оценкой модели, их остаётся около десяти процентов.
Что стало: проверка релиза занимает три-четыре часа вместо двух дней, покрытие — все сто процентов диалогов из эталонного набора. Возвраты на доработку сократились с четырёх релизов до одного из десяти, а регресс по прошлым сценариям видно ещё до выката. Набор версионируется вместе с моделью, поэтому две ветки дообучения сравниваются на одних и тех же примерах.
Чем отличается онлайн-контроль от проверки на эталонном наборе?
Эталонный набор — это зафиксированный срез запросов с разметкой, который прогоняют до выкатки. Он отвечает на вопрос «не сломали ли то, что уже работало», и даёт сравнивать версии модели между собой на неизменных данных. Онлайн-контроль отвечает на другой вопрос: после релиза и поведение пользователей, и входные данные уже не те, что были при подготовке дообучения.
| Контур | На что отвечает | Чего не ловит |
|---|---|---|
| Эталонный набор | Регресс: сломалось ли то, что работало | Сдвиг входных данных после выкатки |
| Онлайн-контроль | Дрейф: распределение запросов, отказы, формат ответа | Причинность — сигнал есть, причина неясна |
Онлайн-контроль считает долю отказов, полноту и длину ответов, обращение к внешним источникам и распределение оценок судьи. Когда метрика выходит за заданный коридор, включается отслеживание дрейфа, а спорные ответы уходят в ручной разбор выборки.
Дальше контуры стыкуются: разобранные случаи после экспертной разметки пополняют эталонный набор, поэтому он растёт вместе с продуктом, а не устаревает. Первую линию оценки держит LLM-as-judge на попарном сравнении версий, вторую — эксперты на выборке; расчёт метрик и хранение прогонов закрывает Ragas.
Если оставить только один контур, получаются два предсказуемых сбоя: набор незаметно превращается в музей прошлого продукта, а онлайн-сигнал — в поток жалоб, который не к чему привязать.
Частые технические вопросы о контуре проверки
Контур проверки собираем до запуска дообучения — иначе метрики невольно подгоняются под уже полученный результат. На согласовании обычно всплывают одни и те же вопросы: объём эталонного набора, разметка без профильных экспертов, шум в выборке и перенос метрик между итерациями.
Какой объём эталонного набора считаем достаточным?
Ориентир — от 30-50 примеров на каждый значимый сценарий, редкие классы добираем отдельно, иначе метрика по ним скачет от итерации к итерации. Набор версионируем и фиксируем контрольной суммой, чтобы сравнение прогонов оставалось корректным.
Можно ли разметить выборку без профильных экспертов?
Формальные критерии — да: письменная инструкция, два разметчика и третий голос при расхождении. Предметные требования так не закрыть — небольшая экспертная калибровка задаёт эталон, дальше объём добирает модель-судья под контролем согласия с экспертом.
Что делать с шумом в выборке?
Стратифицируем набор по сценариям и убираем почти одинаковые примеры — они перекашивают долю успеха. Пограничные случаи выносим в отдельный слой: усреднённая метрика без разброса по подгруппам не показывает, где модель ломается.
Можно ли переиспользовать метрики из других проектов?
Каркас переносится: проверки формата, полноты ответа и отказов от предметной области не зависят. Пересобираем эталонные примеры, критерии и порог срабатывания под конкретную задачу.
Как в проверке участвует заказчик?
Владелец продукта согласует критерии и принимает результат на закрытом эталонном наборе. Нужны несколько часов профильного эксперта на калибровку — дальше прогоны идут без его участия.
Обсудим задачу: что прислать, чтобы мы вернулись с планом
Чтобы обсудить задачу предметно и вернуться с планом работ, а не с общими соображениями, нужен минимум входных данных для оценки — то, что уже есть у вас на руках. По логам пилота видно, где модель ошибается чаще всего, а по эталонным ответам — какой уровень качества считается приемлемым. Опишите задачу в свободной форме: этого достаточно, чтобы начать.
- эталонный набор: 200–500 реальных запросов с ответами и разметкой «верно / неверно» — на нём калибруем автоматическую оценку второй моделью и меряем точность дообучения;
- логи пилота: сырые диалоги, версии подсказок и ответы модели в том виде, в котором их видели пользователи;
- критерии приёмки: какие ошибки критичны, какие допустимы и в какой доле случаев;
- описание домена и сценариев: кому отвечает модель, на какие вопросы и что в ответах запрещено;
- ориентир для сравнения: метрики базовой модели или предыдущей версии дообучения;
- ограничения по данным и доступам: где лежат данные, нужна ли обезличка, можно ли привлекать внешних экспертов-разметчиков;
- примеры спорных ответов: 10–20 случаев без единого мнения — они задают границу разметки.
Дальше присылаем план работ: состав этапов от сборки эталонного набора до приёмки, точки контроля на каждом шаге, роли в команде. Если чего-то из перечня нет под рукой — скажите прямо: часть входных данных мы собираем и размечаем сами, отдельным этапом.
