Тестирование и оценка LLM API: построение CI/CD-пайплайна (2026)

3,2% появляется в отчёте аудита первым —3,200 некорректных JSON-пейлоадов на каждые 100,000 вызовов API, каждый из которых — тихий сбой бизнес-логики.

Причиной стало изменение одной строки модели. Ни одна панель это не поймала. HTTP остаётся зелёным, пока структурированные выходы тихо деградируют, а вы прослеживаете обломки на три спринта назад.

Интегрированный в CI eval ловит семантические регрессии на пулл-реквесте —с той же силой, с которой юнит-тесты блокируют нулевые указатели.

Этот пайплайн охватывает путь от детерминированных проверок до скоринга LLM-as-Judge с замкнутым контуром, превращающим сегодняшние сбои в завтрашние CI-тесткейсы.

Почему «Выглядит правильно» масштабируется до ~50 ревью —а потом терпит неудачу

Почему «Выглядит ли это правильно?» не масштабируется

Человек-ревьюер, смотрящий на выходы LLM, ненадёжен тремя конкретными, измеримыми способами:

1. Усталость. Точность резко падает после ~50 последовательных ревью. Ваше 51-е суждение значительно хуже 5-го —и вы не заметите деградацию.
2. Непоследовательность. Межэкспертная надёжность между двумя человеческими ревьюерами на одном наборе выходов LLM обычно опускается ниже 0,6 —то есть два квалифицированных человека не соглашаются по вопросу «это корректно?» в 40% случаев.
3. Стоимость и задержка. 1,000 выходов по 90 секунд на ревью = 25 часов человеческого времени. Это $750–2,500 за каждый eval-прогон —и на планирование уходят дни.

Машинная оценка последовательна, мгновенна и почти бесплатна. Но «машинная оценка» — это не одна вещь: это стек из трёх примитивов, которые вы комбинируете в зависимости от того, что тестируете.

Три примитива оценки

Уровень 1: детерминированные проверки. Микросекунды. Нулевая стоимость API. Валидация JSON Schema. Точное строковое совпадение. Подсчёт успешных/неуспешных вызовов инструментов. Проверка существования цитат. Регулярные выражения для отказов. Они ловят примерно 50% реальных сбоев —и это единственный уровень, который можно запускать на каждом запросе без забот о бюджете. Начните здесь.

Уровень 2: метрики на основе embedding. Миллисекунды. ~$0.001 за проверку. BERTScore. Косинусная близость к эталонному ответу. Полезно, когда у вас есть «gold»-ответы и нужна толерантная к перефразированию оценка близости. Не полезно для открытой генерации, где существует несколько корректных ответов.

Уровень 3: LLM-as-Judge. Сотни миллисекунд. $0.01–0.10 за проверку. Способная LLM оценивает выходы по рубрикам с использованием цепочки рассуждений (chain-of-thought). Ловит семантические сбои, которые пропускают детерминированные проверки —неверную суммаризацию, бесполезные ответы, некорректные отказы. Требует калибровки по человеческим меткам и активной митигации смещений (смещение позиции, смещение многословия, смещение самоусиления).

6-уровневый продакшн-стек оценки

Dataset —Metrics/Rubrics —Judge —CI Gate —Production Observation —Closed Loop

Разорвите любое звено — и оценка превратится в офлайн-отчёт, который никто не читает. Датасет семплируется из продакшна с весом в сторону сбоев. Рубрики определяют «корректно» в измеримых терминах. Судья оценивает последовательно и в масштабе. CI-гейт блокирует регрессии до мерджа. Наблюдение в продакшне ловит то, что пропускает CI. Замкнутый контур превращает сегодняшний сбой в продакшне в завтрашний CI-тесткейс. Шесть уровней. Один пайплайн. Без пробелов.

Почему систематическое тестирование меняет всё

Скрытая стоимость регрессии

3,2% тихо некорректных JSON-ответов означают 3,200 сломанных выходов на каждые 100,000 вызовов API. Если эти выходы приводят в движение последующие действия, у вас 3,200 сбоев бизнес-логики —и вы их не обнаружите, пока финансовая сверка не сойдётся, а это могут быть недели.

Eval-пайплайн ловит эти 3,2% в CI, до того как изменение строки модели достигнет продакшна. Стоимость настройки пайплайна меньше стоимости одного инцидента.

Обнаружение дрейфа промптов

Незначительные изменения версий моделей —gpt-5.5-2026-07-01 на gpt-5.5-2026-07-15 —не сопровождаются заметками об изменении поведения. В чейнджлоге написано «улучшено следование инструкциям». Точность структурированного извлечения упала на 4 пункта. Вы не узнаете об этом, если не прогоняете один и тот же eval-набор против каждой версии модели.

Проблема многопровайдерной оценки

Если вы маршрутизируете между моделями —а вы должны, ради стоимости и надёжности —вам нужны eval-результаты для каждой модели в пуле маршрутизации. Не только для основной. Единый API-endpoint позволяет прогнать один и тот же eval-набор против всех моделей через одну интеграцию. Тот же формат запроса. Те же тесткейсы. Та же модель-судья. Единственная меняющаяся переменная — model: "...".

Прежде чем строить eval-набор, поймите профили производительности и стоимости каждой модели в вашем пуле маршрутизации. Наше сравнение бенчмарков между провайдерами предоставляет данные по каждой модели, чтобы обосновать ваши приоритеты тестирования.

Как построить ваш пайплайн оценки

Шаг 1: постройте свой eval-датасет

Датасет — самый сложный шаг, и именно в него большинство команд недоинвестируют. Плохой датасет даёт вам точные оценки неправильных вещей. Хороший датасет семплируется из продакшна, взвешен в сторону сбоев и обновляется еженедельно.

Процесс построения:

1. Случайно отберите 200–500 запросов из продакшн-логов. Не из тестовой среды. Реальные пользователи задают вопросы, о которых авторы тестов никогда не думают.
2. Вручную аннотируйте каждый: каким был корректный ответ? Что сделало бы ответ неправильным? Какие краевые случаи модель должна обрабатывать?
3. Стратифицируйте по сложности: треть простых, треть средних, треть сложных. Если ваш eval-набор состоит только из простых запросов, ваши оценки будут завышены.
4. Обновляйте еженедельно: семплируйте новые данные за последние 7 дней продакшн-логов. Заменяйте самые старые 20% eval-набора. Это держит ваш eval в соответствии с тем, что пользователи реально спрашивают —а это дрейфует со временем.

Правило, предотвращающее самую частую ошибку: как минимум 20% вашего eval-набора должны происходить из исторических сбоев. Если eval-набор содержит только happy-path запросы, вы тестируете, работает ли модель в идеальных условиях —а не то, элегантно ли она терпит неудачу в условиях, которые реально встречаются в продакшне.

Шаг 2: определяйте рубрики, а не просто «хорошо ли это?»

Четыре хорошо откалиброванные рубрики бьют 15 шумных. Каждая рубрика требует:

• Точное определение: «faithfulness = каждое фактическое утверждение в ответе подтверждается извлечённым контекстом»
• Шкалу оценки: 1–5 или 0–1
• Порог прохождения: «faithfulness ≥ 0,85»
• Два-три оценённых примера в качестве калибровочных ориентиров для вашей модели-судьи

Базовый набор рубрик для большинства приложений LLM API: faithfulness (факты корректны?), answer relevance (отвечает ли ответ на запрос?), context precision (действительно ли извлечённые чанки релевантны?), task completion (выполнила ли модель то, что просили?), refusal correctness (отказала ли модель, когда должна была —и не отказала, когда не должна?).

Шаг 3: выберите и откалибруйте своего судью

GPT-4 — наиболее широко используемый LLM-судья —его согласие с человеческими аннотаторами превышает 80% на MT-Bench и 85%+ на G-Eval. Но неоткалиброванный судья даёт вам числа, которые выглядят точными и систематически неверны.

Процесс калибровки: возьмите 50 примеров с человеческой аннотацией. Прогоните их через модель-судью. Рассчитайте корреляцию между оценками судьи и человеческими оценками. Если корреляция ниже 0,75 для любой рубрики, промпт судьи для этой рубрики нужно доработать —или вам нужна другая модель-судья.

Три смещения, которые необходимо митигировать:

• Смещение позиции. Судья предпочитает ответ, который появляется первым. Исправление: рандомизируйте порядок ответов для каждой оценки.
• Смещение многословия. Судья оценивает длинные ответы выше независимо от качества. Исправление: оценивайте релевантность и полноту как отдельные измерения.
• Смещение самоусиления. Судья завышает оценки для выходов, сгенерированных той же моделью-семейством. Исправление: используйте другое семейство моделей в качестве судьи, чем в продакшне. Если в продакшне работает Claude, судите GPT-4. Или используйте выделенную модель-судью. Об изоляции API-ключей и контроле доступа, которые надёжно разделяют судью и продакшн-модели, см. руководство по лучшим практикам безопасности.

Самое упускаемое из виду правило: зафиксируйте версию модели-судьи. Когда вы обновляете судью с GPT-4 до GPT-4o, каждая историческая оценка становится несопоставимой. Вы не можете понять, улучшилась ли ваша продакшн-модель или судья стал строже. Либо держите версию судьи постоянной, либо перекалибровывайте на 50 человеческих примерах после каждого обновления судьи и устанавливайте маппинг оценок между старым и новым судьями.

Шаг 4: настройте CI-гейт

Два инструмента, две философии:

• Promptfoo. Открытый исходный код. Интеграция с Git. Декларативная конфигурация в YAML. Лучший выбор для команд, которые хотят eval как код, живущий рядом с их промптами в одном репозитории.
• DeepEval. Нативно для Python. 30+ встроенных метрик. CI/CD-интеграция на основе декораторов. Лучший выбор для команд, которые хотят глубоко интегрировать eval в свой Python-набор тестов.

Логика CI-гейта независимо от инструмента:

tests:
  - path: eval_dataset.jsonl
    asserts:
      - type: python
        value: |
          def check_regression(output, context):
              baseline = context['baseline_scores']
              current = compute_scores(output)
              for rubric, score in current.items():
                  if baseline[rubric] - score > 2:
                      return False, f"{rubric} dropped {baseline[rubric] - score:.1f} points"
              return True, "All rubrics within threshold"

Любая рубрика, упавшая более чем на 2 пункта от базовой линии —CI не проходит —мердж заблокирован. Это не опционально. Изменение промпта, ухудшающее качество на 3 пункта по критической рубрике, никогда не должно достигать продакшна. Ваши юнит-тесты блокируют исключение нулевого указателя. Ваши eval-гейты должны с той же силой блокировать семантическую регрессию. Рабочий процесс оптимизации промптов, который питает CI-гейт, освещён в нашем производственном руководстве по промпт-инжинирингу.

Шаг 5: наблюдение в продакшне + замкнутый контур

CI-оценка ловит регрессии до деплоя. Она не ловит сдвиги распределений, адверсариальные входы или краевые случаи, не покрытые вашим eval-набором. Для них вам нужна непрерывная оценка на продакшн-трейсах.

Прикрепляйте eval-оценки к вашим OTel-спанам. Любая рубрика, удерживающая падение на 2–5 пунктов в скользящем окне, триггерит алерт. Методология калибровки судьи и рабочий процесс оптимизации промптов, питающий CI-гейт, оба рассмотрены в предыдущих шагах этого руководства. Методология оценки с цепочкой рассуждений, упомянутая здесь, была установлена статьёй G-Eval (Liu et al., 2023). Неудачные трейсы автоматически кластеризуются по типу ошибки, версии промпта и модели. Именованные проблемы с репрезентативными сбоями повышаются обратно в ваш офлайн eval-датасет —на этот раз с ручной аннотацией и документированием конкретного паттерна сбоя.

Этот замкнутый контур — разница между eval-оценкой, которая со временем снижается, и той, которая продолжает улучшаться. Без него ваш eval-набор устаревает, модель дрейфует, а CI-гейт становится формальностью, которая проходит, пока качество продакшна деградирует.

Паттерны тестирования для конкретных API-сценариев

Тестирование структурированного вывода

Одна только валидация JSON Schema ловит ~70% сбоев структурированного вывода. Добавьте проверки бизнес-правил для оставшихся 30%: «цена не может быть отрицательной», «email должен соответствовать регулярному выражению», «итог должен равняться сумме позиций плюс налог». Проверки согласованности между полями: «если payment_method равен ‘credit_card’, то last_four не должен быть null».

Провайдер-специфичная ловушка: OpenAI возвращает function.arguments как JSON-строку. Anthropic возвращает tool_use.input как JSON-объект. Ваш парсер должен обрабатывать оба —и ваш eval-набор должен тестировать оба. Мокайте оба формата ответов в CI.

Полный справочник форматов запросов и ответов по всем провайдерам —включая структурированный вывод, вызовы инструментов и стриминг —см. в документации chat completions API.

Тестирование вызовов инструментов

Четыре проверки в порядке частоты сбоев: (1) имя инструмента соответствует схеме. (2) Обязательные аргументы присутствуют и имеют корректные типы. (3) Параллельные вызовы инструментов не мешают друг другу. (4) После ошибки инструмента модель повторяет попытку с исправленными аргументами —или эскалирует —не зацикливается.

Установите жёсткий лимит циклов в тестировании: один и тот же инструмент вызван более трёх раз подряд —тест провален. Модель должна распознать паттерн, а не повторять его.

Тестирование качества RAG

Три измерения: релевантность контекста (об извлечённых чанках то, о чём спросил пользователь?), верность ответа (каждое утверждение в ответе подтверждается извлечённым чанком?), точность цитирования (указывает ли каждая цитата на чанк, который действительно содержит цитируемую информацию?). Минимальный порог: точность цитирования top-1 —90%. Ниже этого пользователи потеряют доверие —быстро.

Почему большинство LLM eval-пайплайнов терпят неудачу в течение 3 месяцев

Тестирование только happy-path сценариев

Ваш eval-набор содержит «Какая политика возврата?» и «Как сбросить пароль?» —чистые, дружелюбные, хорошо сформированные запросы. В продакшне есть «i cant log in wtf???» и «URGENT: my refund still hasn’t processed and it’s been TWO WEEKS» —с опечатками, злостью и отсутствующим контекстом. Если ваш eval-набор не включает продакшн-подобные краевые случаи, ваша eval-оценка в 95% ничего не значит.

Исправление: семплируйте из продакшн-логов. Обеспечьте, чтобы как минимум 20% вашего eval-набора происходили из исторических сбоев —запросов, которые ранее давали неправильные ответы, отказы или галлюцинации.

Незафиксированная версия модели-судьи

Вы обновили судью с GPT-4 до GPT-4o. Все ваши eval-оценки сдвинулись вверх на 3 пункта. Ваша команда праздновала «улучшение качества». В продакшне ничего не изменилось. Просто судья стал снисходительнее.

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

Оптимизация на eval-наборе

Вы настроили промпт против вашего eval-набора. 95% точности. Задеплоили. Точность в продакшне: 68%. Eval-набор содержал паттерны, под которые вы оптимизировали. Продакшен содержит всё остальное.

Исправление: разделение train/eval/test (70/15/15). Оптимизатор видит тренировочный набор. CI работает на eval-наборе. Тестовый набор откладывается —вы прогоняете его один раз перед релизом, и оценка, которую он сообщает, — ближайшая оценка производительности продакшна, которую вы получите до деплоя.

Как только ваши eval-гейты проходят в CI, паттерны деплоя вроде канареечных раскаток и цепочек фолбэка защищают от сдвигов распределений в продакшне. Стратегии раскатки и конфигурацию фейловера моделей см. в руководстве по оптимизации продакшна.

Дополнительное чтение. Расширьте сторону структурированного вывода вашего набора тестов с помощью нашего сравнения JSON mode и структурированного вывода, которое охватывает провайдер-специфичную обработку форматов, которую должен валидировать ваш CI-пайплайн. О методологии оптимизации промптов см. шаг 4; о стратегиях раскатки и конфигурации фейловера моделей см. руководство по оптимизации продакшна выше.

FAQ

Сколько тесткейсов мне нужно для старта?

Пятьдесят — минимум для направленной обратной связи —достаточно, чтобы понять, улучшило изменение ситуацию или ухудшило, но слишком шумно для CI-гейта. От ста до 500 кейсов дают статистическую значимость —один сбой на краевом случае не может сдвинуть ваши оценки более чем на несколько пунктов. Начните с 50. Добавляйте 20–30 новых кейсов еженедельно из продакшн-логов. Если вы новичок в программном LLM-тестировании и хотите сначала получить основы API, наш справочник для начинающих по LLM API покрывает структуру запроса до того, как вы построите eval-набор.

LLM-as-Judge против человеческой оценки —насколько велик разрыв?

Судья GPT-4 соглашается с человеческими аннотаторами более чем в 80% случаев на задачах фактов и следования инструкциям. Разрыв самый большой по субъективным измерениям (креативность, стилистическое качество). По объективным измерениям —faithfulness, соответствие формату, завершённость задачи —LLM-судьи соответствуют отдельным человеческим аннотаторам или превосходят их, потому что устраняют усталость и непоследовательность.

Стоит ли использовать ту же модель в качестве судьи, что и в продакшне?

Нет. Смещение самоусиления реально и измеримо —модели завышают оценки выходов того же семейства на 5–10%. Используйте другое семейство моделей или выделенную модель-судью. Если ваш продакшн-стек работает на Claude, оценивайте GPT-4.

Как оценивать стриминговые ответы?

Оценивайте полностью конкатенированный ответ, а не отдельные токены. Добавляйте ассерты производительности: TTFT (время до первого токена) ниже вашего целевого порога, межтокенная задержка P95 в пределах бюджета. Стриминг-специфичные баги —например, неэкранированные переводы строк в данных SSE-событий, ломающие парсер —требуют выделенных детерминированных проверок.

Как прогнать один eval-набор по трём провайдерам, не написав три адаптера?

Отправляйте идентичные тесткейсы через один базовый URL, меняя только параметр model между gpt-5.5, claude-sonnet-4-20250514 и gemini-3.1-pro. Один формат запроса. Один eval-пайплайн. Единственная меняющаяся переменная — какая модель обрабатывает промпт —а это именно то, что ваш eval-набор спроектирован измерять. Для вашего первого единого eval-запроса через один базовый URL следуйте руководству быстрого старта.

Оценка LLM — не фаза, которую вы проходите. Это инфраструктура, которую вы поддерживаете. 6-уровневый стек —датасет, рубрики, судья, CI-гейт, наблюдение в продакшне, замкнутый контур —минимальная жизнеспособная система для понимания того, становятся ли ваши фичи на LLM лучше или хуже.

Начните с 50 тесткейсов и детерминированных проверок. Запустите их в CI на этой неделе. Добавляйте 20 кейсов в неделю из продакшн-логов. Через месяц у вас будет статистически значимый eval-набор и CI-гейт, ловящий регрессии раньше, чем их заметят пользователи.

Ваш eval-набор не должен требовать провайдер-специфичного адаптера для каждой тестируемой модели. Начните тестирование на TokSpan —прогоните те же 50 тесткейсов против GPT, Claude и Gemini через единую точку интеграции.