Если вы считаете, что ваша языковая модель готова к релизу после того, как вы десяток раз прогнали промпты в веб-интерфейсе и вам понравились ответы, — готовьтесь к катастрофе. Ваше демо — это фасад, за которым скрывается галлюцинирующий стохастический попугай, готовый слить клиентскую базу, нагрубить пользователю или сломать парсер на бэкенде в первый же час реальной нагрузки. Оценка качества LLM в продакшене не делается глазами. И тем не менее, большинство команд до сих пор деплоят нейросети, опираясь на субъективное «выглядит неплохо», а потом удивляются, почему система деградирует.
Ручная проверка не масштабируется. Когда у вас в системе сложный RAG (Retrieval-Augmented Generation), разветвленная логика роутинга и динамические контексты, любое, даже минорное изменение системного промпта меняет распределение вероятностей по всему словарю. Вы поправили промпт, чтобы модель перестала извиняться в каждом предложении, и внезапно она разучилась выдавать валидный JSON. Глазами вы поймаете только очевидные галлюцинации. Тихую деградацию на краевых случаях (edge cases), когда модель начинает игнорировать бизнес-правила при длине контекста больше 8 тысяч токенов, вы не заметите, пока клиенты не начнут обрывать телефоны технической поддержки.
Выкатывать LLM без жесткого каркаса автоматизированных проверок — это инженерия каменного века. Единственный профессиональный подход к недетерминированным системам — это загнать их в рамки строгого контроля.
Оценка качества LLM в продакшене начинается с Golden Set
Вам нужен Golden Set. Это не просто выгрузка случайных диалогов в CSV-файл. Это жестко структурированный эталонный набор тестовых кейсов, который функционирует как юнит-тесты для вашей модели. Golden Set должен быть репрезентативен профилю нагрузки вашего продакшена. Если вы работаете с индустриальными системами и разворачиваете инференс на изолированном железе клиента, вы не можете позволить себе фиксить поведение модели в онлайне. Цена ошибки на edge-вычислениях максимальна — данные не покидают периметр, обновления редкие, система обязана работать автономно и абсолютно предсказуемо.
Правильный Golden Set состоит из нескольких слоев. Первый — бизнес-критичные пути. Это самые частые запросы, где эталонный ответ известен до запятой. Второй слой — сложные сценарии из реальной практики саппорта, тикеты, в которых пользователи сформулировали запрос максимально неоднозначно или нелогично.
Третий — ловушки и атаки. Промпт-инъекции, попытки заставить модель выдать закрытую инструкцию, вопросы, на которые в базе знаний намеренно нет ответа. Модель должна уметь сказать «я не знаю» вместо того, чтобы услужливо генерировать правдоподобный бред. Например, если в вашей базе знаний документ на 15 страниц, а критически важный факт находится на седьмой, стандартная модель обязательно словит эффект Lost in the Middle и проигнорирует его. В Golden Set должны быть десятки таких длинных контекстов, чтобы доказать, что выбранная стратегия чанкинга RAG действительно решает эту проблему.
Четвертый слой — форматирование. Запросы, проверяющие способность модели отдавать чистые машиночитаемые данные без словесного мусора вроде «Конечно, вот ваш результат». Лишняя кавычка или markdown-разметка там, где ожидается чистый JSON-массив, обвалит весь последующий пайплайн.
Golden Set нельзя написать один раз и забыть. Это живая база, которая непрерывно пополняется после каждого инцидента. Модель облажалась в проде? Разбираете причину, вытаскиваете этот контекст, добавляете в тесты. Только так вы получаете гарантию, что регрессия не повторится при следующей итерации весов.
Eval-пайплайн и LLM-судья: метрики, которым можно верить
Теперь о том, как измерять результаты. С традиционным ML все прозрачно: у вас есть классические precision, recall, F1-score. Для генеративного текста метрики вроде BLEU или ROUGE бесполезны — они штрафуют за перефразирование, хотя семантика ответа может быть абсолютно верной. Нам нужны метрики более высокого уровня: фактологичность (faithfulness), релевантность ответа (answer relevance), строгое соблюдение синтаксиса и контроль токсичности.
И тут индустрия свернула не туда, породив опасный хайп вокруг концепции LLM-судьи (LLM-as-a-judge). Идея выглядит соблазнительно: давайте попросим более мощную модель, например GPT-4, оценивать ответы нашей локальной модели. На практике вы просто получаете вторую недетерминированную систему, которая оценивает первую.
LLM-судья предвзят по своей природе. Он страдает от verbosity bias — систематически завышает оценки за длинные, водянистые ответы, путая объем с качеством. У него есть ярко выраженный position bias — при сравнении двух вариантов он чаще выбирает тот, что стоит первым в промпте. И самое ужасное: судья отвратительно справляется со сверкой фактов, если они закопаны глубоко в контексте документа. Вы не можете просто сказать судье: «Оцени этот ответ по десятибалльной шкале». Это гарантированный путь к мусорным метрикам.
LLM-судья работает исключительно в режиме беспощадного диктатора. Температура генерации строго на ноль. Вместо пространных оценок — бинарная логика. Вы разбиваете проверку на микро-шаги и задаете конкретные вопросы: «Содержит ли ответ факт X из контекста? Да или Нет», «Содержит ли ответ извинения? Да или Нет». Никаких абстрактных критериев «полезности».
Чтобы система не развалилась под нагрузкой, выстраивается многоступенчатый eval-пайплайн:
- Оффлайн-гейт в CI/CD: При каждом коммите в репозиторий с промптами или при обновлении квантованных весов модели прогоняется весь Golden Set. Парсеры детерминированно проверяют 100% совпадение схем данных. На уровне фактологии работает локальная легковесная модель-судья (например, специализированная Prometheus) с жестким бинарным скорингом. Пайплайн падает и блокирует релиз, если метрики проседают хотя бы на полпроцента.
- Теневое развертывание (Shadow mode): Новая конфигурация разворачивается параллельно с текущей. Реальный трафик дублируется на новую модель, но клиенту отдается ответ от старой. Мы логируем различия в семантике ответов и замеряем p99 latency под реальной нагрузкой. Если новая версия начинает сыпать таймаутами из-за более тяжелого системного промпта, это отобразится в логах до того, как пострадает UX.
- Синтетический мониторинг в онлайне: В продакшене вы не можете гонять LLM-судью на каждый ответ — это удвоит косты на GPU-инференс и убьет latency. Поэтому трекаются легковесные прокси-метрики. Длина генерируемых токенов: если модель внезапно стала отвечать в три раза короче или длиннее, это аномалия. Количество ошибок десериализации на клиенте — прямой индикатор сломанного формата. Implicit-сигналы от пользователей — прерванная генерация, быстрая перезапись запроса.
- Регулярный сэмплинг: От 1 до 5 процентов ответов из продакшена асинхронно прогоняется через тяжелого LLM-судью или отправляется на ручную разметку для калибровки автоматических метрик.
Когда ваша система обслуживает тысячи запросов в секунду на изолированных контурах, интуиция становится непозволительной роскошью. Оценивать LLM — значит собирать железобетонный датасет краевых случаев, выстраивать CI/CD с бинарными порогами падения и измерять деградацию математически. Любой другой подход — это просто дорогая имитация инженерии, которая рассыплется под первым серьезным трафиком.