Оценка LLM-приложений в продакшене: почему проверки «на глаз» больше не работают (2026)

Почему этот плейбук написала Фора Софт

Фора Софт с 2024 года довела до продакшена 9+ LLM-приложений. Голосовые агенты на OpenAI Realtime и LiveKit Agents; реализации RAG в BrainCert, VALT и платформах для совещаний; MCP-серверы для видео и систем наблюдения.

В каждом — оценочная обвязка: эталонный датасет, интеграция с RAGAS или Braintrust, качественные гейты в CI/CD. Подходы в этом руководстве собраны из этих проектов и публичных источников: сравнения платформ Braintrust 2026, документации LangSmith, фреймворка RAGAS, статистики McKinsey о 67 % внедрений RAG.

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

Почему проверки «на глаз» проваливаются

Большинство команд «оценивает» LLM-приложение так: показывают пару запросов команде и спрашивают «нормально ли выглядит?». Этого хватает на v0-демо — и больше ни на что. Три типа провала:

1. Искажения выборки (sample bias). Команда пробует те запросы, которые сама придумала, — обычно грамотные, в рамках домена, по счастливому пути. Реальные пользователи присылают странные запросы, с опечатками, на языках, которые команда не закладывала, на крайних случаях, о которых никто не подумал. Длинный хвост проверки «на глаз» не ловят вообще.

2. Эффект привязки (anchor effect). Как только команда довольна v1, каждое следующее изменение оценивается относительно v1. Медленная деградация остаётся незамеченной. Мы видели проекты, где за полгода апгрейдов модели, правок промпта и тюнинга поиска точность на длинном хвосте незаметно падала на 15 %, и никто этого не замечал.

3. Нет регресс-тестов. Команда переходит на GPT-4 Turbo / Claude 3.5; кто-то меняет промпт; кто-то добавляет фильтр в поиск. Без автоматического набора тестов единственный сигнал — жалобы клиентов. А клиенты обычно уходят раньше, чем жалуются.

Лекарство — автоматическая оценка на эталонном датасете с регресс-тестами в CI/CD. Когда это есть, каждое изменение промпта или модели становится тестируемым; падение качества всплывает раньше, чем до него доберутся клиенты.

5 категорий оценки LLM

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

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

На основе модели (LLM-as-judge). Отдельная LLM (часто GPT-4) оценивает вывод по критериям, которые вы зададите («ответ опирается на факты?», «отвечает ли на вопрос?»). Мощно и дёшево; но есть искажения: LLM любят свои собственные ответы, более длинные ответы, определённые формулировки. Используйте аккуратно — никогда как единственный метод оценки.

Человеческая оценка. Доменные эксперты размечают примеры по интересующим вас параметрам. Эталон качества, но дорого (75–375 ₽ за пример) и медленно. Используется при сборке эталонного датасета и для периодической перекалибровки автоматических метрик.

Бизнес-метрики. Эталонные данные, которые реально важны: удержание пользователей, конверсия, NPS, доля доведённых до конца обращений (для голосовых агентов). Запаздывающий индикатор; полезен, чтобы убедиться, что метрики оценки коррелируют с тем, что вам действительно нужно.

Оценка для RAG (RAGAS)

RAG-приложениям нужны RAG-специфичные метрики. Open-source-фреймворк RAGAS определяет четыре основные:

Релевантность контекста. Действительно ли извлечённые чанки относятся к запросу пользователя? Ловит сбои поиска — правило 73 %: когда RAG ломается, проблема обычно в извлечении, а не в генерации. Целевое значение: >0,8.

Релевантность ответа. Отвечает ли LLM на заданный вопрос (а не уходит в сторону)? Ловит проблемы в поведении модели. Целевое значение: >0,85.

Обоснованность (faithfulness). Подтверждаются ли утверждения в ответе извлечёнными чанками? Ловит галлюцинации. Целевое значение: >0,85.

Полнота контекста (context recall, с эталоном). Если у вас есть размеченный валидационный набор — нашёл ли ретривер чанки, в которых лежит ответ? Самая сложная для подсчёта метрика (нужна разметка эталона), но и самая показательная для качества поиска.

Под капотом RAGAS использует LLM-as-judge. Запускайте на эталонном датасете из 100–200 вопросов, отслеживайте метрики во времени, ставьте алерты на регрессии. Подробнее об архитектуре поиска, которую вы будете оценивать, — в нашем гайде по RAG для видео и аудио.

Оценка голосовых агентов

У голосовых агентов есть параметры оценки, которых нет у текстовых:

Бюджет задержки. Задержка voice-to-voice по p50 (<800 мс) и p95 (<1,4 с). Считается на каждом ходе диалога; алерт на дрейф. Подробности — в нашем руководстве по OpenAI Realtime.

Точность вызова инструментов. Вызвал ли агент правильный инструмент с правильными аргументами? Считается по каждому инструменту. Цель: >96 % успешных вызовов.

Обработка перебивания. Когда пользователь перебивает агента в момент речи — останавливается ли тот в течение 200 мс? Отслеживайте задержку реакции (barge-in latency) и ложные срабатывания.

Доля доведённых до конца обращений (containment rate). Процент звонков, завершённых без передачи оператору. Самая важная бизнес-метрика для голосовых агентов.

Воспроизведение трейсов. Записывайте полное аудио и транскрипт каждого звонка; затем переигрывайте — чтобы пополнять эталонный датасет или прогонять регресс-тесты. Это умеют Helicone, LangSmith и Braintrust.

Матрица инструментов: Braintrust, LangSmith, Galileo, Confident AI, Helicone

Регресс-тесты в CI/CD

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

На что ставить гейт. Ключевые метрики: faithfulness и answer relevance из RAGAS, ваши доменные метрики. Задайте пороги по качеству (например, faithfulness не ниже 0,85). Задайте пороги по регрессии (ни одна метрика не падает больше чем на 3 % относительно main).

Пайплайн. PR открыт → CI запускает оценку (5–15 минут на датасете в 100 вопросов) → результаты публикуются комментарием в PR и статус-чеком → PR можно мерджить только если пороги по качеству пройдены.

Контроль расходов. Прогоны оценки тратят токены LLM. Один прогон RAGAS на 100 вопросах стоит примерно 37–150 ₽. Способы экономить: (1) кэшируйте одинаковые промпты и ответы между прогонами, (2) полный набор — на release-ветках, сокращённый — на feature-ветках, (3) тяжёлые неблокирующие метрики прогоняйте пакетно по ночам.

Воспроизведение продакшен-трейсов. Снимайте трейсы в продакшене; 5–10 % попадают в «свежий продакшен»-набор для оценки. Прогоняйте по ночам. Дрейф ловится быстрее, чем на одном статичном эталонном датасете.

Как собрать эталонный датасет

Самая сложная часть оценки. Сделаете хорошо — это станет вашим самым ценным LLM-инженерным активом. Сделаете плохо — все метрики оценки бессмысленны.

Шаг 1: опишите сценарии. Перечислите 5–10 основных вариантов использования вашего LLM-приложения. По каждому — 3–5 типичных запросов. Получите ~30–50 запросов на счастливый путь.

Шаг 2: соберите крайние случаи. Прошерстите продакшен-логи (или сессии бета-тестеров) на предмет запросов, которые удивили команду. Опечатки, многоязычные, длинные, короткие, нестандартные интерпретации. Цель — 30–50 крайних случаев.

Шаг 3: разметка доменными экспертами. На каждый запрос доменный эксперт (не инженер, который пишет приложение) пишет «правильный» ответ или размечает допустимые варианты. Стоит 75–375 ₽ за запрос для общей тематики; 375–1 500 ₽ для медицины, права и других специализированных доменов.

Шаг 4: ревью и доработка. Команда инженерии смотрит разметку на согласованность. Расхождения вскрывают двусмысленности в описании сценариев. Итерируйте.

Шаг 5: поддерживайте во времени. Раз в квартал добавляйте новые запросы из продакшен-трейсов. Удаляйте те, что больше не отражают поведение продукта. Раз в год переразмечайте, если продукт или домен заметно изменился.

Сколько стоит оценка

Стоимость запуска. Сборка эталонного датасета: 22 500–150 000 ₽ за 100–200 вопросов в стандартном домене. Специализированные домены — в 3–5 раз дороже. Интеграция инструментов (Braintrust / LangSmith / RAGAS): 1–2 недели работы инженера.

Стоимость прогонов. Один прогон: 37–150 ₽ на 100 вопросов с судьёй уровня GPT-4. Ежедневные прогоны: 2 250–4 500 ₽/мес. CI/CD-прогоны на каждый PR: 37 ₽ × число PR. Типично — 3 750–15 000 ₽/мес. при активной разработке.

Стоимость инструментов. Braintrust 18 600 ₽/мес. фикс (без лимита по пользователям). LangSmith 2 900 ₽/место/мес. Galileo — enterprise. Self-hosted Langfuse / Confident AI: бесплатно + ~3 700 ₽/мес. на Postgres.

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

Мини-кейс: оценка голосового агента экономит 3 млн ₽/мес. на оттоке

B2B-платформа голосовой поддержки клиентов на ИИ (под NDA, ~3 млн звонков в месяц) пришла к нам в конце 2025-го с растущим оттоком. Обратная связь клиентов: «бот раньше работал, теперь даёт неправильные ответы». Команда инженерии полгода итерировала промпты и обновляла модели — без оценочной обвязки.

Четырёхнедельная интервенция. Неделя 1: собрали эталонный датасет на 240 пар «запрос — ответ» по 8 сценариям, разобрав 6 недель продакшен-звонков; разметку делали доменные эксперты — их менеджеры поддержки. Неделя 2: подключили Braintrust + RAGAS; прогнали базовую оценку на текущем продакшене; зафиксировали пороги качества. Неделя 3: пересобрали CI/CD-пайплайн с гейтами оценки на каждом PR. Неделя 4: прогнали регресс-анализ за полгода и нашли ту самую правку промпта, с которой началось падение качества.

Результат. Метрика faithfulness на эталонном датасете выросла с 0,71 (после регрессии) обратно до 0,89 — после отката плохой правки промпта и перенастройки. Жалобы клиентов на качество за следующий месяц упали на 60 %. Отток, который команда списывала на «качество бота» (~3 млн ₽/мес. упущенного MRR), развернулся за 6 недель. Инвестиция: 2,4 млн ₽ за четырёхнедельный проект и 18 700 ₽/мес. на Braintrust далее. Чтобы получить такой же аудит, позвоните или напишите нам.

Каркас решения: подобрать стек оценки за пять вопросов

В1. Какой стек? Много LangChain — LangSmith. Смешанный или нейтральный — Braintrust. Self-hosted и комплаенс — Langfuse или Confident AI.

В2. Сколько LLM-фич? 1 — open-source RAGAS или DeepEval хватает. 2–3 — управляемая платформа окупается. 5+ — без управляемой платформы уже не обойтись.

В3. Требования по комплаенсу? Стандартные — любая cloud-опция. HIPAA / SOC 2 / резидентность ЕС — self-hosted Langfuse / Confident AI внутри вашего VPC.

В4. Размер команды? 1–3 инженера — code-first OSS (DeepEval, RAGAS). 4–15 — управляемый UI помогает. 15+ — enterprise-тариф с ролевым доступом.

В5. Объём в продакшене? <10 тыс. LLM-вызовов в день — подходит любой инструмент. >100 тыс. — выбирайте те, у которых сильное семплирование и контроль расходов.

Чего избегать

1. LLM-as-judge как единственная метрика. У судей-LLM есть искажения (более длинные ответы, определённые формулировки, предпочтение собственного семейства моделей). Обязательно комбинируйте хотя бы с одной другой категорией: с эталоном, бизнес-метрикой или человеческой оценкой.

2. Эталонный датасет устаревает за полгода. Раз в квартал добавляйте новые запросы из продакшена. Без обновления вы тестируете вчерашнее приложение, а не сегодняшнее.

3. Нет интеграции с CI/CD. Оценка по ночам ловит регрессии с опозданием в дни. Оценка как гейт PR — до мерджа. Первое — наблюдаемость, второе — реальная защита от деградации качества.

4. Команда инженерии размечает свои же данные. Инженеры знают, что должна делать LLM, и размечают снисходительно. Доменные эксперты (реальные пользователи или их прокси) размечают строго. Всегда привлекайте внешних разметчиков.

5. Считать оценку разовым проектом. Оценка — это непрерывный процесс. Соберите v0-обвязку и итерируйте датасет, метрики и гейты по мере развития продукта.

Какие KPI отслеживать

KPI качества. Ключевые метрики оценки (faithfulness > 0,85, релевантность ответа > 0,85 и т. д.). Регрессионная доля (% PR, проваливших гейт оценки). Время до обнаружения дрейфа в продакшене (цель: <24 часов).

Бизнес-KPI. Жалобы клиентов на качество в месяц (цель: тренд вниз). Доля доведённых до конца обращений (для голосовых агентов) или доля выполненных задач (для текстовых). Отток, который вы относите на качество LLM.

KPI надёжности. Аптайм пайплайна оценки (цель: 99 %+). Доля ложных срабатываний на гейтах качества (цель: <10 % — гейты, которые блокируют хорошие PR, подрывают доверие команды).

FAQ

Что почитать дальше

Готовы выпускать LLM-приложения, которые держат качество?

Оценка LLM — это новый MLOps. Продакшен LLM-приложения без оценки тихо ломаются: апгрейд модели незаметно ухудшает качество, правка промпта рушит крайние случаи, клиенты уходят, не успев пожаловаться. Каркас из 5 категорий (с эталоном, без эталона, на основе модели, человеческая оценка, бизнес-метрики) ловит разные классы багов; в зрелых деплоях используют 3 и больше.

Эталонный датасет — самый сложный шаг и самый ценный актив. Качественные гейты в CI/CD сильнее ретроспективных дашбордов. Матрица инструментов богатая (Braintrust, LangSmith, Galileo, Confident AI, Helicone, Langfuse) — выбор зависит от стека и комплаенс-требований. RAGAS для метрик под RAG работает поверх любой платформы.