Зачем оценивать LLM дисциплинированно
У LLM-сервисов нет классической «точности»: качество зависит от промпта, корпуса знаний, версии модели и даже формата ответа. Типичная история проекта: «поменяли промпт — вроде стало лучше» — и через неделю выясняется, что сломался соседний сценарий, о котором никто не подумал. Дисциплинированная оценка (эвалы) решает ровно это: у сервиса появляется контрольный набор вопросов с эталонами, автоматические метрики и правило «ни одно изменение не уходит в бой без прогона». Качество перестаёт быть мнением и становится числом с трендом.
Второй драйвер — сравнения: выбор между моделями (open-source против API, одна версия против другой), между вариантами RAG-конвейеров, между квантованием и полной точностью. Без единого контрольного набора такие сравнения — маркетинг; с ним — таблица на ваших данных. Именно так устроен наш подход в пилотах: например, прирост от гибридного поиска и реранкинга мы показываем на контрольных вопросах заказчика, а не на абстрактных бенчмарках.
Золотой набор и метрики
Основа контура — золотой (golden) набор: 60–120 реальных запросов пользователей с эталонными ответами или эталонными фрагментами источников; для RAG метрики считаются отдельно по компонентам. Поиск: нашла ли система правильный фрагмент (полнота@k, точность выдачи). Генерация: опирается ли ответ на найденное (faithfulness/groundedness), отвечает ли на вопрос (relevance), полон ли ответ (completeness). Эксплуатационные метрики — латентность и стоимость — собираются контуром LLMOps-мониторинга. Для сценариев с формализованным выходом (JSON для 1С, структурированные выходы) добавляется валидация схемы и бизнес-правил: доля валидных ответов — самая беспощадная и самая полезная метрика.
LLM-как-судья: дёшево, но с оговорками
Ручная разметка дорогая и медленная, поэтому массовые проверки автоматизируют «LLM-как-судья»: модель-оценщик по критериям (соответствие эталону, обоснованность, полнота) выставляет баллы или вердикты «лучше/хуже». Работает, но с известными смещениями: судья благоволит длинным ответам, лоялен к стилю собственной семьи моделей, чувствителен к формулировке критерия. Поэтому три правила: критерии формулируются под задачу (не «оцени качество», а «есть ли в ответе факт X, подтверждён ли он фрагментом Y»); судья калибруется по ручной разметке (сколько его вердиктов совпало с экспертными); спорные случаи уводятся в ручную очередь. Судья — это скрининг масштаба, а не замена эксперту на решающих рубежах.
Открытые инструменты
Рабочий стек собирается из открытых инструментов. Ragas (Apache 2.0) — метрики именно для RAG: faithfulness, relevance, полнота поиска на ваших фрагментах. DeepEval (Apache 2.0) — фреймворк оценки в стиле юнит-тестов: метрики подключаются к тестам, гоняется в CI. promptfoo (MIT) — регрессионное тестирование промптов и конфигураций: матрица «промпт × модель × тесты», сравнение вариантов, детекция деградаций. Все три разворачиваются в контуре заказчика; результаты прогонов уходят в дашборды мониторинга. Выбор комбинации — по сценарию: Ragas для поисковых контуров, DeepEval/promptfoo — для регрессий при разработке.
Как применяем: контур оценки
- Сбор золотого набора. 60–120 реальных запросов из логов/поддержки; эталоны размечают люди, знающие предметную область; набор расширяется инцидентами эксплуатации.
- Базовая линия. Прогон текущей версии на наборе — стартовые цифры, без которых «улучшение» неизмеримо.
- Метрики и судьи. Настройка метрик под сценарий; калибровка LLM-судьи по ручной разметке; фиксация порогов приемлемости.
- Регрессии в CI. Изменение промпта/модели/корпуса → автоматический прогон → блокировка релиза при выходе за пороги.
- Сравнения до/после. Любое «улучшение» подтверждается таблицей на золотом наборе — как в пилотах поиска и оркестрации.
- Продакшн-петля. Оценки пользователей и периодические прогоны набора в бою — контроль дрейфа качества.
Текстовая схема: золотой набор (запросы + эталоны) → прогон версии → метрики по компонентам + судьи (калиброванные) → таблица до/после → решение о релизе → петля в продакшне (мониторинг дрейфа).
| Формат | Цена | Срок |
|---|---|---|
| Методология и сбор золотого набора | от 90 000 ₽ | 1–2 недели |
| Пилот: набор + метрики + судьи + первая регрессия | от 480 000 ₽ | 4–6 недель |
| Промышленный контур: CI-регрессии, пороги, отчётность | от 690 000 ₽ | 3–5 недель |
| Расширенный контур: мультисценарии, A/B, продакшн-петля | 0,9–1,2 млн ₽ | 6–8 недель |
Регрессионное тестирование в CI
Главная практика контура: изменения не оцениваются «на глаз». Обновили промпт — прогон. Провайдер обновил модель — прогон. Переоборудовали корпус знаний — прогон. Прогон автоматически сравнивает метрики с порогами: вышли за порог по faithfulness — релиз блокируется до разбора. Это переводит качество ИИ-сервиса из категории «надеемся» в категорию «проверено», и стоит такой контур дешевле, чем одна молчаливая деградация, замеченная по жалобам ключевого клиента через месяц. Инженерная реализация — DeepEval/promptfoo в пайплайне CI с публикацией отчётов владельцу сервиса.
Честность метрик
Мы принципиально не называем проценты улучшений до замера на данных заказчика: у каждого корпуса, сценария и аудитории — своя база. Золотой набор собирается из реальных запросов именно вашей системы; эталоны размечают ваши эксперты; таблица «до/после» показывается с примерами: какой запрос раньше возвращал мусор, а теперь — пункт регламента. Автоматические метрики и судьи — это screening для скорости; решающие выводы подтверждаются ручной выборочной проверкой. Разбор ошибок важнее средних баллов: какие типы запросов стабильны, какие плавают, где система систематически врёт — это и есть повестка доработок.
Тонкости, которые всплывают в проектах
Первая — набор живёт: запросы пользователей меняются, набор пополняется инцидентами, иначе контур оценивает вчерашний день. Вторая — эталоны неоднозначны: на один вопрос бывает несколько правильных ответов; это учитывается в метриках (оценка по критериям, а не посимвольное сравнение). Третья — протечка тестов в обучение: золотой набор не должен использоваться для дообучения оцениваемой модели, иначе метрики станут отражать заучивание. Четвёртая — стоимость прогонов: судьи и полные прогоны на больших наборах тратят токены; прогонная стратегия (быстрый smoke на каждом коммите, полный — на релиз) балансирует цену и покрытие.
Проверки в производстве: A/B и теневые контуры
Золотой набор — лаборатория; производство — поле, где живут настоящие запросы. Два рабочих инструмента переноса оценки в бой. Теневой запуск: новая версия сценария работает параллельно с боевой на реальном трафике, ответы сравниваются (судьёй и пороговыми метриками), пользователи видят старую версию — риск нулевой, данные настоящие. A/B-деление: части пользователей достаётся новая версия, сравнение идёт по объективным метрикам (доля решённых обращений, повторные вопросы) и оценкам пользователей.
Правила гигиены: решения о раскатке принимаются по заранее зафиксированным метрикам, а не по впечатлениям; длительность проверки достаточна, чтобы не поймать случайность; у каждой проверки — владелец и дата решения. Так контур оценки замыкается: лабораторный набор и регрессии удерживают качество при изменениях, производственные проверки — подтверждают эффект на реальных пользователях.
Как стартуем
- Пришлите сценарий и 20–30 примеров реальных запросов — соберём методологию и структуру золотого набора за 1–2 недели.
- Пилот: набор, метрики, калиброванный судья, первая регрессия и таблица до/после — от 480 000 ₽ за 4–6 недель.
- Встраивание регрессий в ваш CI и продакшн-петлю — по результатам пилота.
Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.