Автоматизация оценки качества LLM: интеграция Braintrust

Почему оценка качества LLM ломается после релиза

Офлайн-наборы примеров и реальный трафик расходятся почти всегда. На закрытой выборке метрики выглядят ровно, но в проде распределение запросов другое: короткие уточнения, смешанные языки, обрывки контекста, вложения. Оценка качества LLM по среднему баллу этого не ловит — модель уверенно отвечает там, где раньше честно говорила «не знаю».

Хуже всего то, что изменения приходят по одному. Правка формулировки в системном промпте, смена версии модели, новый инструмент в цепочке вызовов — и регрессии после обновления промптов проявляются не в том сценарии, который трогали, а в соседнем. Всю матрицу сценариев после каждой такой правки никто не перепроверяет, поэтому галлюцинации в проде всплывают через дни.

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

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

Автоматическая оценка ответов вместо ручных прогонов

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

Сколько ручной работы уходит из процесса

Автоматизация проверок ответов строится на однозначных критериях: ответ опирается на источник, не выдумывает факты, держит заданный тон, не раскрывает внутренние инструкции. Сформулированные один раз, они применяются к каждому прогону одинаково — разные эксперты перестают трактовать правильность по-своему.

Сокращение ручной разметки идёт за счёт отсечения очевидных случаев: автоматика сама отмечает ответы с высоким сходством к эталону и поднимает наверх те, где расхождение значимое. Человеку остаётся десятая часть выборки — пограничные и конфликтные диалоги.

За какое время ловится регрессия

Braintrust хранит историю прогонов, поэтому новый набор ответов сравнивается с предыдущим сразу после сборки: метрики по единым критериям правильности считаются автоматически, просадка видна в отчёте без ручного сопоставления.

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

Варианты контура проверок: сравнение подходов

Контур проверок — это метрики, наборы данных и правила разметки, которые отвечают на вопрос, стало ли качество ответов лучше после правки модели или формулировки запроса. Собирают его тремя способами, и выбор зависит не от размера команды, а от того, как часто меняются сценарии и кто участвует в разметке.

Когда хватает открытых библиотек

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

Когда нужен отдельный внешний контур

Отдельный контур нужен, когда важны воспроизводимость и разметка силами нескольких людей. Braintrust хранит версии наборов данных и метрик, поэтому спор «стало хуже или показалось» закрывается ссылкой на конкретный прогон, а не повторным запуском скриптов. Гибрид снимает компромисс: автоматические проверки остаются в репозитории, а экспертные оценки и сравнение версий — во внешнем контуре.

Этапы внедрения: от аудита сценариев до регламента

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

Аудит и постановка критериев

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

1. Разбираем сценарии и классифицируем ошибки по типам — получаем список того, что вообще нужно проверять.
2. Формулируем критерии правильности: обязательные факты, допустимые формулировки, запреты в ответе.
3. Собираем набор проверок — вопросы с эталонными ответами и автоматические проверки на формат и обязательные блоки.

Проверка на исторических данных и выкатка

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

• Прогоняем контур на накопленных диалогах и сверяем с ручной разметкой.
• Настраиваем регулярные прогоны на Braintrust на каждое изменение промпта или модели; в отчёте — динамика по каждому критерию.
• Выкатываем контур проверок в рабочий режим и передаём регламент: как добавлять проверки, как читать отчёт, при какой просадке откатывать изменение.

Что передаём на руки: тесты, схемы, регламенты

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

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

Документация и правила разметки

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

Что уже настроено в вашем контуре

Контур собран на Braintrust и связан с вашим репозиторием: прогон запускается из ветки, результат сравнивается с предыдущим релизом, падение метрики ниже порога уходит в канал команды. Новый сценарий добавляется одним файлом эталонов и одной записью в конфигурации — без правок кода проверок.

Кейс: сокращение ошибок в ассистенте поддержки

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

Что было до внедрения

Доля некорректных ответов держалась около 12%: ассистент путал условия возврата, ссылался на устаревшие разделы базы знаний и уверенно отвечал там, где нужна была передача оператору. Ручная проверка релиза занимала 3-4 дня — эталонные диалоги прогоняли глазами, и обновление ждало вердикта. За квартал две регрессии ушли в продакшн: их заметили по жалобам, когда выросла доля эскалаций на операторов.

Что изменилось после

Мы собрали контур проверок на Braintrust: эталонный набор диалогов с разметкой, автоматические оценки по критериям — полнота ответа, опора на источник, корректность эскалации, отсутствие выдуманных условий. Прогон запускается на каждом изменении инструкций или модели, а порог качества блокирует релиз, если оценка по критерию просела; на ручной разбор уходят только случаи, где автоматика не уверена.

Доля некорректных ответов снизилась с 12% до 3%, проверка релиза сократилась с 3-4 дней до 40 минут, пропущенных регрессий за квартал — ноль. В поддержке это дало меньше эскалаций и разгрузило операторов на сложных обращениях: типовые вопросы ассистент закрывает сам, а команда видит, какой именно критерий тянет качество вниз после очередного изменения.

Чем отличается офлайн-разметка от проверок в проде

Офлайн-разметка и проверки в проде отвечают на разные вопросы. Набор на исторических данных показывает, стала ли модель лучше на известных случаях; живой трафик — не ломается ли она на том, чего в наборе не было.

Подготовленный набор на исторических диалогах

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

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

Контроль на живом трафике

Онлайн-контроль качества ответов работает на том, что приходит сейчас: доля отказов и повторных вопросов, разбор диалогов, где пользователь ушёл, сбор обратной связи пользователей прямо в интерфейсе. Это единственный способ увидеть сдвиг тематики и редкие сценарии. Но эталона здесь нет — оценка шумная, зависит от поведения аудитории, а часть обратной связи просто не приходит.

Разница методов проверки в том, что офлайн отвечает за регрессию, а онлайн — за обнаружение. Рабочая схема: набор на исторических диалогах стоит воротами перед выпуском, а аномалии из прода разбираются и превращаются в новые примеры набора.

Частые технические вопросы перед интеграцией

Перед интеграцией инженерные команды задают почти одни и те же вопросы — и все они про то, как проверки уживаются с уже работающим продуктом.

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

Модель уже в проде — её придётся останавливать?

Нет. Сначала теневой прогон на исторических запросах, без влияния на живые ответы. Изменения в проверках и правилах выкатываем за переключателем, который снимается одним действием, — откат занимает минуты.

Сколько исторических данных нужно для старта?

Обычно нескольких сотен размеченных примеров на сценарий, собранных из реального потока запросов, — тогда пороги не случайны. Если данных мало, стартуем на синтетических примерах и активно добираем спорные случаи.

Как подключать новые сценарии к проверкам?

Новый сценарий получает свои эталонные ответы и пороги, общие проверки (формат, полнота, безопасность) переиспользуются. Перед выкатом обязателен прогон на старых наборах — регрессии видны до релиза.

Свой контур проверок или внешняя платформа?

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

Обсудим задачу: какие данные нужны для старта

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

• Описание сценариев: какие задачи решает модель, кто пользователь и что считается правильным ответом.
• 30–50 примеров удачных ответов — из них собирается эталон и база для повторных прогонов.
• Примеры неудачных ответов, включая пограничные случаи: выдуманные факты, отказ, сломанный формат.
• Текущие метрики и логи обращений: доля ошибок, время ответа, разметка от пользователей, если она ведётся.
• Ограничения по срокам: когда нужен первый результат и какие релизы нельзя останавливать.
• Правила работы с данными: где допустимо обрабатывать запросы, что обезличивать, нужен ли изолированный контур.
• Кто со стороны заказчика утверждает критерии качества и разбирает спорные примеры.

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