Evals and observability: never ship “seems to work” to production

Главная ошибка команд, выпускающих AI-фичи, — единая метрика «успеха». Композитный показатель усредняет разнонаправленные движения и прячет деградацию: качество ответов выросло на 3%, а p95 latency удвоился — «успех» не изменился, а пользователи ушли. Меряйте оси раздельно:

• Quality — решена ли задача пользователя: точность extraction, полезность ответа, выполнение инструкции. Определяется rubric-ой, специфичной для задачи.
• Faithfulness — опирается ли ответ на предоставленные источники (критично для RAG): доля утверждений, подкреплённых контекстом.
• Latency — отдельно time-to-first-token (определяет ощущение отзывчивости при streaming) и полное время ответа; всегда p50/p95/p99, никогда не среднее — среднее маскирует хвост, который и бесит пользователей.
• Cost — цена запроса в токенах и деньгах, по фичам: рост cost на 40% при неизменном качестве — это регрессия, даже если «всё работает».

К этим четырём добавляются операционные счётчики из прошлых уроков: repair rate structured outputs, доля ответов без цитат, доля «данных недостаточно», число tool calls на задачу. Каждый из них — ранний индикатор, срабатывающий за часы и дни до жалоб.

Раздельные оси дают язык для честных trade-off-ов: «новый промпт даёт +5 п.п. качества за +30% cost — принимаем?» — это решение продукта, а не спор о вкусах. С единой метрикой такой разговор невозможен в принципе.

Golden set — размеченный набор кейсов, на котором проверяется каждая версия системы. Реалистичный размер для старта — 30–50 кейсов, зрелый набор — 150–300; больше обычно не нужно, важнее состав:

• 60–70% — типовые запросы из реального трафика (с обезличиванием персональных данных);
• 20–30% — пограничные случаи: неполные данные, противоречивый вход, длинные документы, смешение языков;
• 10% — adversarial: попытки увести модель от задачи, провокации выдумки, кейсы «правильный ответ — отказ».

Каждый кейс: input, ожидание (эталонный ответ или свойства, которым ответ обязан удовлетворять) и rubric — явные критерии оценки. Rubric важнее эталона: для генеративных задач «правильных» ответов много, а критерии («все суммы совпадают с документом», «нет утверждений без опоры», «формат соблюдён») проверяемы всегда.

Ручная проверка 300 кейсов на каждый коммит нереальна, поэтому оценивает LLM-судья. Но судье нельзя верить на слово — его калибруют: 50–100 кейсов размечают люди, затем считается согласованность судьи с человеком. Ниже ~85% — переписывайте rubric и промпт судьи, пока не сойдётся. Судья фиксируется как версия: конкретная модель, промпт, temperature 0 — иначе ваши метрики поплывут от апдейта судьи, а не системы.

Golden set — живой артефакт: каждый продовый инцидент и каждое ручное исправление добавляют кейс. Set, не обновлявшийся квартал, измеряет вчерашнюю систему.

Правило простое: любое изменение промпта, модели, схемы инструмента или параметров retrieval проходит через прогон golden set до мержа — ровно так же, как код проходит через тесты. Для этого промпты и конфигурация должны жить в git, а не в head инженера или в админке без истории.

# в CI-пайплайне, на каждый PR, затрагивающий prompts/ или model config
npm run evals -- --suite golden --baseline main --report evals-report.json
# gate: quality не ниже baseline минус 2 п.п., cost не выше +20%, p95 не выше +30%

Пороги — предмет договорённости команды, но принцип один: регрессия блокирует мерж, а осознанный trade-off (потеря качества ради троекратной экономии) оформляется явным override с записью, кто и почему решил. Отчёт прогона — не одна цифра, а diff по кейсам: какие кейсы сломались, какие починились, с примерами вход/выход. Смотреть на сломанные кейсы глазами — обязательная часть ревью: два процентных пункта могут означать «чуть хуже везде» или «полный провал на юридических документах», и это очень разные ситуации.

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

Экономика вопроса: прогон 200 кейсов стоит единицы долларов. Один необнаруженный регресс в проде стоит на порядки дороже — деньгами, доверием и неделей отладки.

Без трассировки отладка LLM-системы выглядит так: «пользователь пожаловался на странный ответ — попробуем воспроизвести». С трассировкой: открыли trace по id из жалобы, увидели всю цепочку, нашли причину. Разница — часы против минут.

Что пишется в trace каждого запроса:

• trace id, сквозной через все компоненты и возвращаемый клиенту (чтобы жалоба сразу содержала его);
• span на каждый model call: версия промпта (hash), версия модели, параметры, input/output токены, latency, finish reason;
• span на каждый tool call: аргументы, результат или ошибка, длительность;
• для RAG — какие чанки нашлись, их score и что вошло в контекст;
• итог: суммарный cost, число итераций, финальный статус.

Технически это обычный OpenTelemetry с атрибутами под LLM-специфику — не изобретайте свой формат, возьмите готовые конвенции (Langfuse, OpenLLMetry) и получите визуализацию бесплатно.

Два обязательных правила. Первое — PII redaction: в traces попадает контент промптов и ответов, значит туда попадают персональные данные; маскирование до записи, а не при чтении, и понятная политика retention. Второе — sampling с умом: 100% трассировка ошибок и провалов evals, 1–10% успешных запросов; при инциденте sampling поднимается до 100% одним переключателем.

И замыкание петли, ради которого всё затевалось: каждый провал eval-прогона ссылается на trace своего прогона, каждый продовый инцидент — на traces реальных запросов. Плохой кейс из прода за один шаг превращается в новый кейс golden set — это и есть работающий цикл улучшения качества.