Вы построили оценочный набор. Он зелёный. Вы выкатываете релиз. Пользователи тут же жалуются на регрессии, которые ваша оценка не поймала.
Это один из самых частых — и самых деморализующих — сценариев в работе с LLM в продакшене. Оценочные наборы, которые выглядят внушительно, но пропускают значимые регрессии. Они дают ложную уверенность. Команда им доверяет, выкатывает изменения, портящие качество, и узнаёт о проблеме, только когда на неё жалуются пользователи.
Построить оценки, которые действительно ловят регрессии, сложнее, чем кажется. Основы (датасет, ожидаемые ответы, выставление баллов) просты. Превратить их в надёжный сигнал — вот где настоящая работа.
Эта статья — о том, что мы поняли про построение оценок, которые не подводят, для команд, серьёзно относящихся к качеству ИИ в продакшене.
Что делают хорошие оценки
Хороший оценочный набор, прогнанный на проверяемом изменении, даёт уверенный ответ на вопрос: «это изменение лучше, хуже или такое же, как текущая версия?»
Разберём по пунктам:
- Ловит регрессии. Когда качество падает на реальных сценариях, балл оценки падает.
- Обнаруживает улучшения. Когда качество растёт, балл это отражает (а не только на специально отобранных случаях).
- Стабилен, когда ничего не менялось. Когда по сути ничего не изменилось, балл остаётся тем же.
- На него можно опираться в решениях. Решения, принятые по баллам оценки, коррелируют с реальными исходами для пользователей.
Каждое из этих свойств сложнее, чем звучит.
Проблема датасета
Ваша оценка хороша ровно настолько, насколько хорош ваш датасет. Большинство неработающих оценочных наборов проваливается именно здесь.
Типичные проблемы датасета
Проблема 1: специально отобранные лёгкие случаи. Датасет собирали, когда система работала, — часто тот же инженер, который её строил. Он выбирал случаи, которые «имели смысл», — чёткие примеры каждого поведения. Реальный трафик в продакшене грязнее. Сложные, неоднозначные, граничные случаи преобладают среди сбоев, но недопредставлены в датасете.
Проблема 2: устаревший датасет. Датасет собрали полгода назад. С тех пор поведение пользователей сместилось, появились новые области функциональности, вышли новые возможности продукта. Датасет проверяет устаревшую версию мира.
Проблема 3: нет покрытия зон, где случаются регрессии. Оценка тщательно покрывает идеальный сценарий, но не прощупывает границы, где регрессии и происходят.
Проблема 4: загрязнение датасета. Примеры из оценки попадают ещё и в промпт или в данные для дообучения. Модель их «запоминает». Тестовые баллы завышены; реальное качество хуже.
Проблема 5: несбалансированное распределение. 80% датасета — один тип входных данных; 5% — длинный хвост. Регрессия в длинном хвосте едва двигает балл, хотя это настоящая регрессия.
Как собрать сильный датасет
Несколько принципов, дающих сильные датасеты:
Берите из реального трафика в продакшене. Лучшие примеры — реальные пользовательские запросы (с удалёнными персональными данными). В них та самая грязь, с которой системе нужно справляться.
Практический рабочий процесс:
- Снимите выборку боевых вызовов (с надлежащими мерами приватности).
- Разметьте ожидаемые ответы вручную (или разметьте с помощью LLM, а затем проверьте вручную).
- Добавьте случай в оценочный датасет.
- Регулярно обновляйте датасет (раз в месяц — хорошая периодичность).
Включайте разнообразные режимы отказа. Отдельно включайте случаи, которые раньше приводили к сбоям в продакшене. Они становятся регрессионными тестами: если вы починили баг, добавьте сбойный случай, чтобы он и дальше оставался починенным.
Стратифицируйте датасет. Разбейте случаи на категории (лёгкие/средние/сложные, по теме, по типу пользователя, по длине). Обеспечьте осмысленное покрытие каждой категории. Отслеживайте баллы по категориям, а не только общий.
Смешивайте сложность. Немного лёгких случаев (чтобы обнаруживать катастрофические регрессии). Побольше средних (основная масса реального трафика). Немного сложных (граничные случаи). Датасет только из сложных случаев дико скачет при малых изменениях; датасет только из лёгких не сдвинется на реальной регрессии.
Подбирайте размер под задачу. Слишком мало — статистика шумит. Слишком много — прогоны становятся медленными и дорогими. Типичные размеры:
- Классификация: 200–500 случаев.
- Генерация: 50–200 случаев.
- Сложные агентные сценарии: 20–50 случаев.
Всегда можно начать с меньшего и расти.
Дисциплина обновления. Запланируйте ежемесячный пересмотр датасета. Добавляйте новые режимы отказа. Выводите из обихода устаревшие случаи. Обновляйте ожидаемые ответы, если желаемое поведение изменилось.
Проблема метрики
То, что вы измеряете, определяет то, под что вы оптимизируетесь. Плохой выбор метрик — вторая по частоте причина провала оценок.
Типичные проблемы метрик
Проблема 1: сводка одним числом прячет проблемы. Общая точность 90% может скрывать, что одна важная категория просела с 95% до 70%, пока другие выросли. Среднее выглядит нормально.
Решение: всегда давайте разбивку по категориям.
Проблема 2: метрика измеряет не то. Метрика «корректности» в ответах поддержки может не заметить, что ответ корректен, но груб. Метрика не улавливает тон.
Решение: многомерное оценивание. Корректность + тон + длина + формат — по отдельности.
Проблема 3: нечувствительность к серьёзности. Неверный ответ оценивается одинаково — и в случае тривиальной ошибки, и в случае опасной галлюцинации.
Решение: взвешенное оценивание. Серьёзные ошибки весят больше. Часть ошибок весит 0 (нарушения безопасности); часть — −1 (катастрофические сбои, они хуже, чем «ничего»).
Проблема 4: бимодальная чувствительность. Балл либо идёт со 100% до 99% (незаметно), либо со 100% до 50% (катастрофа). Тонкие регрессии не проявляются.
Решение: градуированное оценивание. Каждый ответ оценивается по непрерывной шкале (1–5 или 0–1), а не бинарно.
Проблема 5: усреднение по всем группам. Среднее по всем пользователям скрывает, что у 10%-го сегмента всё посыпалось.
Решение: разбивка по релевантным срезам (тариф, тип запроса, локаль).
Как построить сильные метрики
Многомерность. Каждый ответ получает несколько баллов. Корректность. Тон. Формат. Безопасность. Длина. Всё, что важно.
Взвешенность. Одни измерения важнее других. Учитывайте это в любой составной метрике.
Калиброванная серьёзность. Внутри измерения различайте мелкие и крупные ошибки. Фактически неверный ответ хуже, чем слегка неточный.
Метрики по категориям. Показывайте баллы в разрезе релевантных срезов. Лёгкие/средние/сложные. По теме. По типу пользователя.
Тренд во времени. Один балл бесполезен; полезен тренд. Стройте графики баллов во времени. Отслеживайте дрейф.
Согласованность с пользователем. Метрики должны коррелировать с тем, что реально волнует пользователей. Жалуются на грубость — измеряете грубость. Жалуются на длину — измеряете длину.
Проблема судьи
Когда вы используете подход «LLM-судья» (одна LLM оценивает ответ другой), судья — это ваш оценщик. Если судья смещён или ошибается, ваши оценки бесполезны.
Типичные проблемы судей
Проблема 1: смещение по длине. LLM-судьи склонны предпочитать более длинные ответы. Они поставят длинному ответу балл выше — даже если он раздут.
Проблема 2: смещение по формату. Судьи предпочитают структурированные ответы (списки, заголовки) сплошному тексту, независимо от того, что лучше подходит под задачу.
Проблема 3: самопредпочтение. Когда модель-судья из того же семейства, что и оцениваемая модель, она ставит более высокие баллы ответам собственного семейства.
Проблема 4: подхалимаж. Судьи соглашаются с любой подачей, которую им дают. Скажешь судье «предыдущая версия была плохой, оцени новую» — и баллы новой раздуются.
Проблема 5: нет опоры на критерии. Судьи оценивают по впечатлению, а не по конкретным критериям. Тот же промпт — разные баллы на разных прогонах.
Как построить сильных судей
Калибруйте по людям. Возьмите выборку баллов судьи; пусть человек их переоценит. Там, где они расходятся, донастройте промпт судьи или примите, что по этому измерению нужен человек.
Используйте разные модели-судьи. По возможности берите судью из другого семейства моделей, чем оцениваемая система. Это снижает самопредпочтение.
Формулируйте критерии явно. Промпт судьи должен точно описывать, как выглядит «хорошо» и «плохо», с примерами. Размытые критерии дают размытое оценивание.
Избегайте наводящих формулировок. Не говорите судье «оцени по шкале, где большинство ответов — хорошие». Опирайтесь на конкретные виды поведения.
Рубрики с якорями. Оценивайте по чёткой рубрике с примерами для каждого уровня. «Балл 5: фактически точно, конкретно, хорошо структурировано. Балл 4: в основном точно, может не хватать одной детали. Балл 3: …» С якорями судья стабилен. Без них — плывёт.
Требуйте структурированный вывод. Судья выдаёт структурированные баллы (по каждому измерению, с обоснованием), а не свободный текст. Так проще агрегировать и проверять.
Сильный промпт судьи выглядит примерно так:
Вы оцениваете ответ ИИ-ассистента.
Запрос пользователя: {query}
Ответ ассистента: {response}
Поставьте баллы по следующим измерениям по шкале от 1 до 5:
1. Фактическая точность: все утверждения верны? (5 = всё верно, 4 = в основном верно с мелкими проблемами, 3 = есть неверное, 2 = много неверного, 1 = в основном неверно)
2. Релевантность: ответ отвечает на фактический вопрос пользователя? (5 = полностью отвечает, 1 = не отвечает)
3. Полнота: в ответе достаточно информации? (5 = полный, 1 = сильно неполный)
4. Тон: тон уместно профессиональный? (5 = идеальный тон, 1 = неуместный)
Для каждого балла укажите:
- Балл
- Одно предложение с конкретной причиной
- Конкретный фрагмент ответа, который подтверждает ваш балл
Вывод JSON: {"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}
Прогоните этого судью по калибровочному набору (с оценками, выставленными людьми). Подстраивайте, пока судья не начнёт соглашаться с людьми в приемлемых пределах.
Проектирование оценочных наборов для продакшена
Несколько схем, которые работают в продакшене:
Набор 1: регрессионный
Определённый набор тест-случаев (200–500), который система обязана пройти перед любым деплоем. Собран из реальных сбоев, граничных случаев и заведомо корректных сценариев. Меняется нечасто.
Это ваш набор «ломать нельзя». Интеграция с CI: каждый PR его прогоняет. Регрессия блокирует слияние.
Набор 2: дымовой тест
Небольшой поднабор (10–30 случаев), который прогоняется часто. Быстрая обратная связь во время разработки. Сразу ловит катастрофические регрессии.
Интеграция: pre-commit-хук или быстрый дымовой тест перед основной оценкой.
Набор 3: разведочный
Более крупный и разнообразный датасет (тысячи случаев), нарезанный из реального трафика в продакшене. Прогоняется реже (раз в неделю?). Ищет закономерности, которые меньшие наборы могут упустить.
Интеграция: запланированная задача. Результаты разбираются на еженедельных встречах по качеству.
Набор 4: онлайн
Выборка реального трафика в продакшене, оцениваемая автоматически (LLM-судьёй) или по пользовательским сигналам. Ловит дрейф, который офлайн-оценки пропускают.
Интеграция: непрерывная, на основе дашбордов.
Набор 5: пользовательские сценарии
Сквозные (end-to-end) тесты, прогоняющие полные пользовательские сценарии, а не отдельные вызовы LLM. Для агентных систем и многошаговых процессов.
Интеграция: перед деплоем крупных изменений.
У зрелой системы в продакшене есть все пять. Начните с регрессионного; добавляйте остальные по мере роста возможностей.
Дисциплина по стоимости и времени
Оценки стоят денег (вызовы LLM) и времени (прогонять их, разбирать результаты).
Оценка на 500 случаев с флагманским судьёй может стоить €5–20 за прогон. Гоняйте её на каждый PR (10 в день) — и выйдет €50–200 в день. Управляемо, но ощутимо.
Стратегии:
Гоняйте дымовые тесты на PR; полные наборы — при слиянии. Экономит на тех PR, что не будут слиты.
Кэшируйте результаты. Если ни промпт, ни модель не менялись, заново гонять не нужно. Кэшируйте по ключу (версия промпта, модель, версия датасета).
Где можно, берите судей подешевле. Более дешёвая модель-судья с хорошей калибровкой часто вполне приемлема.
Распараллеливайте. Прогоны оценок легко распараллеливаются. Используйте параллелизм.
Сэмплируйте, а не гоняйте всё. Для рутинных проверок берите выборку из 50 случаев вместо всех 500. Полный прогон — на важных изменениях.
По времени бюджет обычно определяется вопросом «сколько может ждать PR?». Цельтесь в полную оценку меньше чем за 15 минут. Дольше — и разработчики переключаются на другое и теряют продуктивность.
Операционные схемы
Несколько практик, отличающих зрелые программы оценки:
Схема 1: деплои с гейтом по оценкам
Продакшн-деплои изменений, влияющих на LLM, привязаны к результатам оценки. Балл упал ниже порога? Деплой блокируется. Инженер разбирается.
Порог обычно относительный: «балл должен быть в пределах 2% от базового уровня». Допускает шум, но ловит существенные регрессии.
Схема 2: расследование при движении баллов
Любое осмысленное движение балла (вверх или вниз) расследуется. Балл вырос? Почему? Мы улучшились или тест стал легче? Балл упал? Где именно? Регрессия локализована в одном срезе?
Не радуйтесь и не паникуйте из-за агрегатных движений; разбирайтесь.
Схема 3: непрерывное курирование датасета
Датасет — не одноразовая сборка. Его курируют непрерывно. Процесс:
- Пользователь пожаловался на ответ → добавили в датасет как регрессионный тест.
- Вышла новая функция → добавили случаи, покрывающие её.
- Поведение модели кого-то удивило → если это настоящий сбой, добавили.
- Устаревшие случаи (больше не актуальны) — вывели из обихода.
Хорошо работает ежемесячная встреча для пересмотра. К датасету относятся как к живому активу.
Схема 4: разбор по расхождениям
Разбирая результат оценки, сосредоточьтесь на расхождениях с базовым уровнем:
- Случаи, где новая версия набрала больше базового уровня (улучшения).
- Случаи, где новая версия набрала меньше (регрессии).
- Случаи, где балл не изменился (нет сигнала).
Сигнал — именно в расхождениях. Просматривать 500 случаев подряд непрактично; разобрать 30 расхождений — вполне реально.
Схема 5: ручной разбор разногласий с судьёй
Периодически (раз в неделю?) берите выборку случаев, где судья поставил низкий балл и где — высокий. Человек проверяет: согласны ли вы с судьёй?
Разногласия выявляют:
- Смещения судьи (донастройте промпт судьи).
- Реальные проблемы качества (чините систему).
- Проблемы датасета (ожидаемый ответ для случая неверен).
Именно так вы поддерживаете качество судьи со временем.
Схема 6: квартальный пересмотр оценок
Квартальная ретроспектива самой программы оценки:
- Какие реальные регрессии оценочный набор поймал за квартал?
- Какие реальные регрессии он пропустил?
- Какие ложные тревоги он дал?
- Какие пробелы в покрытии нам известны?
- Насколько датасет покрывает текущее поведение в продакшене?
Это мета-оценка: оценка самого оценивания. Без неё программа оценки деградирует.
Разобранный пример: оценка поддержки клиентов
Чтобы стало конкретно, вот оценочная схема промышленного уровня для ИИ-системы ответов на запросы поддержки.
Цель: добиться, чтобы ответы ИИ на запросы клиентов были точными, полезными, в стиле бренда и безопасными.
Датасеты:
-
Регрессионный набор (300 случаев):
- 50 лёгких случаев (чёткие политики, простые ответы).
- 100 средних случаев (типичная сложность).
- 100 сложных случаев (неоднозначные, чувствительные, многосоставные).
- 50 случаев с известными сбоями (сценарии, где раньше случались регрессии).
-
Разведочный набор (1000 случаев): ежемесячно нарезается из реального трафика в продакшене, персональные данные вычищены.
-
Состязательный набор (50 случаев): специально сконструированные промпты, пытающиеся вытянуть информацию, добиться возврата для неподходящих случаев, манипулировать ИИ.
Метрики:
Для каждого случая судья выставляет баллы по:
- Фактической точности (1–5).
- Соответствию политикам (1–5).
- Уместности тона (1–5).
- Полноте (1–5).
- Уместности длины (1–5).
- Безопасности (бинарно: прошёл/не прошёл).
Судьи:
- Основной судья: Claude (провайдер, отличный от тестируемой системы, которая работает на GPT, — выбор другого провайдера снимает смещение самопредпочтения внутри одного семейства моделей).
- Откалиброван по ревьюеру-человеку на 100 эталонных случаях.
- Перекалибровка ежеквартально.
Агрегация:
- Средний балл по каждому измерению в каждом срезе (срезы: тип обращения, тариф клиента, язык).
- Доля прохождения по безопасности (должна быть 100%).
- Взвешенный балл на случай (используется для сравнения расхождений).
Операции:
- Дымовой тест (30 случаев) на каждом PR.
- Полный регрессионный набор (300 случаев) при слиянии PR.
- Разведочный набор (1000 случаев) еженедельно.
- Состязательный набор (50 случаев) перед любым изменением промпта или модели.
- Онлайн-выборка 1% трафика в продакшене, оцениваемая в реальном времени.
Разбор:
- Ежемесячная встреча: тренды оценок, новые режимы отказа, обновления датасета.
- Ежеквартальная встреча: мета-оценка, калибровка судьи, аудит датасета.
Результаты (из реальных внедрений похожих систем):
- около 3 пойманных регрессий в месяц, которые без оценок уехали бы в продакшен.
- около 1 ложной тревоги в месяц (оценка помечает регрессию, с которой на самом деле всё в порядке).
- Дрейф обнаруживается за дни, а не за недели или месяцы.
- Уверенность в выкатке изменений промпта и модели выросла.
Вот как выглядят оценки промышленного уровня. Это не быстрый проект на выходные, а постоянная инвестиция с реальной отдачей.
Типичные ловушки
Несколько сценариев, которые встречаются снова и снова:
Ловушка 1: строить оценки после релиза продукта. «Оценки добавим позже». Позже не наступает. Стройте их с первого дня.
Ловушка 2: единоличное владение. Один человек построил оценку; больше никто её не сопровождает. Он уходит — оценка гниёт. Распределяйте ответственность.
Ловушка 3: считать оценки статикой. Построили один раз, больше не обновляем. По мере развития продукта они становятся бесполезными. Относитесь к оценке как к живому активу.
Ловушка 4: слепо доверять баллам оценок. Оценка сказала, что лучше, — катим. Без выборочной проверки человеком вы выкатываете то, что оценка оценила высоко, а пользователи ненавидят. На важных изменениях дополняйте оценки проверкой человеком.
Ловушка 5: оптимизироваться под оценку. Подгонять промпты так, чтобы хорошо набрать в оценке. Оценка растёт; реальность — нет. Следите за этим: если улучшения в оценке не подкреплены улучшениями в продакшене, вы оптимизируетесь под тест.
Ловушка 6: игнорировать стоимость инфраструктуры. Оценки в масштабе стоят дорого (вызовы LLM накапливаются). Без учёта расходов вы узнаете об этом в конце месяца.
Ловушка 7: нет чётких критериев «прошёл/не прошёл». «Балл ушёл с 4,2 до 4,0 — это регрессия?» Определяйте пороги заранее. И держитесь их.
Ловушка 8: оценки съедают всю энергию тестирования. Строите изощрённые оценки, пока базовые тесты корректности отсутствуют. Оценки — про дрейф качества; но не всё тестирование сводится к ним.
Культурная часть
Самое трудное в оценках для продакшена — культура. Инженерам и продуктовым специалистам нужно:
- Доверять оценкам настолько, чтобы привязывать к ним деплои. Без этого оценки — театр.
- Не доверять оценкам настолько, чтобы расследовать движения баллов. Слепое доверие ведёт к оптимизации под тест.
- Вкладываться в курирование датасета как в постоянную работу. Это не разовый проект.
- Принять, что оценки не заменяют человеческое суждение. Они лишь сокращают объём того, что людям нужно проверять.
- Признавать, когда оценочный набор не работает. Когда реальные регрессии проскакивают, виноват не жалующийся пользователь, а оценочный набор.
Команды с такой культурой выкатывают быстрее и надёжнее. Команды без неё в итоге либо чрезмерно полагаются на сломанные оценки, либо парализованы их отсутствием.
Главное
Построить оценки, которые действительно ловят регрессии, сложнее, чем кажется, но это выполнимо.
Что важно:
- Реальные, разнообразные датасеты, взятые из реальности продакшена.
- Многомерные, чувствительные к срезам метрики, согласованные с пользовательским опытом.
- Калиброванные судьи, которых вы действительно сверили с человеческим суждением.
- Несколько оценочных наборов под разные задачи (регрессия, дымовой тест, разведка, онлайн, сквозные сценарии).
- Операционная дисциплина: деплои с гейтом по оценкам, непрерывное курирование датасета, расследование движений баллов.
- Культурная готовность использовать и улучшать оценки со временем.
Сделанные как надо, оценки становятся самой ценной инфраструктурой в вашем ИИ-стеке. Именно так вы выкатываете быстро, не теряя качества. Без них вы летите вслепую.
Стройте оценки. Доверяйте оценкам. Улучшайте оценки. Именно так удерживается качество ИИ в продакшене.
