Перейти к содержимому
Экосистема AI Vibe
← Назад к AI Vibe News

Редакция 27 июля 2026 г.

Разборы

Eval-пайплайн для LLM-приложения: как поймать тихую регрессию до деплоя

Eval-пайплайн для LLM-приложения: как поймать тихую регрессию до деплоя.

Вы один крутите промпты и смену модели в проде — а «всё зелёное» в CI значит лишь то, что код не упал. Ответ LLM может быть валидным по форме и при этом фактически неверным: тон съехал, шаг пропал, JSON собрался, а смысл — нет. В практическом гайде moksh на Dev.to разбирает трёхслойный eval — эвристики, LLM-as-judge и человеческий контроль — с привязкой к GitHub Actions, чтобы ловить дрейф качества до релиза, а не после жалоб пользователей.

Почему unit-тесты не спасают LLM-фичу

Классические assert-проверки заточены под детерминизм. У генеративной модели temperature даёт разброс; семантически эквивалентный ответ не совпадёт со строкой в expected; мелкая правка промпта или тихое обновление весов у провайдера копит постепенный дрейф, который не виден в diff'е кода.

LLM apps break silently.

Именно поэтому в материале звучит формулировка «тихой» поломки: ошибки фактов, тона и пропущенных шагов не всплывают как stack trace. Для соло-разработчика, который сам пишет промпт и выкатывает фичу, это означает одно — нужен отдельный слой проверки выхода модели, а не только инфраструктуры вокруг неё.

Три слоя eval: от JSON до судьи-модели

Автор предлагает не один «волшебный» тест, а каскад с разной ценой и глубиной.

Heuristic evals — быстрые объективные проверки: валидность JSON, лимиты по словам, наличие PII. Их разумно вешать на каждый pull request как regression gate: дёшево, воспроизводимо, без вызова второй модели.

LLM-as-judge — вторая модель оценивает ответ по rubric, когда субъективика слишком тяжела для кода и слишком объёмна для ручного ревью. Это уже не «ещё один промпт ради красоты», а контроль качества в AI-assisted продукте: генерация и оценка разведены.

Human evals — ground truth: золотой датасет, калибровка judge-модели, финальное решение перед крупным релизом. Без человека judge со временем уезжает вместе с дрейфом продакшена.

Связка трёх слоёв закрывает разные классы регрессий: формат, смысл и продуктовую приемлемость.

Инструменты и золотой датасет

Для сборки harness moksh называет три точки входа:

  • PromptFoo — open-source, тест-кейсы в YAML, CLI и diff reporting;
  • Braintrust — hosted-платформа для датасетов и сравнения экспериментов;
  • Inspect — open-source framework от UK AI Safety Institute под rigorous benchmarking.

Минимальный каркас можно собрать и без них: Python-скрипт, JSON с тест-кейсами и цикл сравнения выхода LLM с assertions или rubric — но готовые инструменты ускоряют итерации, когда датасет растёт.

Золотой набор — 500–1000 production-representative запросов, включая edge cases и adversarial prompts; обновлять ежеквартально, чтобы не отстать от дрейфа поведения пользователей. Стартовый порог для блокировки деплоя — 90% pass rate; при этом автор советует coverage over perfection: широкий датасет с 85% прохождения лучше узкого с 99%.

Отдельное предупреждение — provider drift: Anthropic и OpenAI могут тихо обновлять underlying models, поэтому полные eval нужны даже без изменений в вашем репозитории. Публичные бенчмарки вроде MMLU не заменяют ваши данные: они не отражают требования конкретного LLM-приложения.

CI/CD: что гонять на каждый PR, а что — ночью

В гайде явно указан GitHub Actions. Схема простая:

  • блокировать деплой, если pass rate падает ниже порога;
  • быстрые heuristic tests — на каждый PR;
  • полные LLM-judge evals — ночной прогон.

Для команды, которая часто крутит промпты и модели, это паттерн «не ловить регрессию в проде»: дешёвые ворота на каждый коммит, дорогая проверка — по расписанию, когда бюджет на inference позволяет.

Минимальный старт, если вы один за весь AI-контур

Не обязательно сразу строить полный зоопарк. Moksh описывает путь из четырёх шагов:

  1. взять 100 реальных запросов из production;
  2. вручную разобрать 50 для ground-truth baseline;
  3. написать basic test runner;
  4. реализовать один heuristic check.

По его словам, это уже даёт больше безопасности, чем ноль автоматизированного тестирования, и даёт основу для расширения — второй check, judge-слой, ночной workflow.

Для соло-workflow без отдельного ML-инженера это практичный первый шаг: не ждать «идеального eval», а зафиксировать хотя бы один объективный критерий на реальных запросах пользователей. Когда промпт меняется в пятницу вечером, у вас есть что-то кроме «вроде нормально ответило».

Источники