Оценка 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, все последующие изменения оцениваются по сравнению с ней. Медленное ухудшение остаётся незамеченным. Мы видели проекты, где за полгода апгрейдов модели, правок промпта и настройки поиска точность на длинном хвосте незаметно упала на 15 %, и никто этого не заметил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Под капотом RAGAS используется LLM-ас-джадж. Запускайте на эталонном датасете из 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. Самостоятельно развернутые 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. Самохостинг и соответствие требованиям — Langfuse или Confident AI.

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

В3. Требования по комплаенсу? Стандартные — любая облачная опция. 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-ас-джадж как единственная метрика. У моделей-судей есть искажения (например, предпочтение более длинных ответов, определённых формулировок или моделей из своего семейства). Обязательно комбинируйте их хотя бы с одной другой метрикой: эталоном, бизнес-показателем или оценкой человека.

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

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

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

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

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

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

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

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

FAQ

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

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

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

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