Загружаем паттерны…
Разработка на основе eval-ов (CI агентов)(EDD)
Дисциплина жизненного цикла разработки, при которой агенты и промпты строятся прежде всего под evals. Тщательно отобранные эталонные наборы данных (примерно от 50 до 500 случаев со смещением в сторону известных режимов отказа) версионируются вместе с промптами, запускаются как набор регрессионных тестов на каждом pull request, а слияние или продвижение ограничивается пороговыми значениями метрик. Конвейер фиксирует версии модели и судьи, поэтому тихое обновление модели на стороне провайдера обнаруживается как регрессия, а не поглощается незаметно, и выстраивает проверки по этапам: сначала lint, затем офлайн-eval, затем контроль стоимости, прежде чем изменение можно будет слить. В отличие от agent-observability-tracing, которая представляет собой телеметрию времени выполнения, а не контроль перед слиянием, и от фиксированных публичных бенчмарков, которые не являются собственными командными регрессионными наборами в CI.
За 30 секунд
- Что это
- Эталонные наборы данных под контролем версий запускаются как регрессионные наборы на каждом PR, а слияние допускается только при достижении пороговых значений метрик, с зафиксированными версиями модели и судьи.
- Когда применять
- Команды, выпускающие агентов, которым нужно замечать негласные обновления моделей, непрерывно покрывать известные режимы отказа и измеримо проверять изменения промптов.
- Осторожно
- Эталонные наборы устаревают или перестают соответствовать реальным сбоям в продакшене, если их не поддерживать активно и не смещать акцент на актуальные режимы отказа.
Спросите ИИ-эксперта об этом паттерне
Откроет ассистента с готовым вопросом. Вы проверите его перед отправкой.
Разработка на основе eval-ов (CI агентов): Обзор
Дисциплина жизненного цикла разработки, при которой агенты и промпты строятся прежде всего под evals. Тщательно отобранные эталонные наборы данных (примерно от 50 до 500 случаев со смещением в сторону известных режимов отказа) версионируются вместе с промптами, запускаются как набор регрессионных тестов на каждом pull request, а слияние или продвижение ограничивается пороговыми значениями метрик. Конвейер фиксирует версии модели и судьи, поэтому тихое обновление модели на стороне провайдера обнаруживается как регрессия, а не поглощается незаметно, и выстраивает проверки по этапам: сначала lint, затем офлайн-eval, затем контроль стоимости, прежде чем изменение можно будет слить. В отличие от agent-observability-tracing, которая представляет собой телеметрию времени выполнения, а не контроль перед слиянием, и от фиксированных публичных бенчмарков, которые не являются собственными командными регрессионными наборами в CI.
- Version-controlled golden datasets (~50-500 cases) weighted toward known failure modes
- Regression suite runs on every pull request; merge gated on metric thresholds
- Pinned model and judge versions so silent provider updates surface as regressions
- Staged CI pipeline: lint, then offline eval, then cost gate before merge
- LLM-as-judge and code-based scorers combined per failure dimension
- Prompt and dataset changes reviewed together as a single diff
Получите полевой гид по оценке агентов
Все 25 методов оценки агентов в одном гиде: какой бенчмарк что измеряет, когда публичный балл вводит в заблуждение и как строить оценки на собственных сбоях. Ссылка приходит вместе с подтверждением, вместе с еженедельным The Agent Architect.
Одно письмо в неделю, отписка в один клик. Адрес используется только для рассылки брифинга.
Источники
Статьи, спецификации и репозитории, на которых основан этот паттерн.
От инженера, создавшего этот каталог
Узнайте, что упускают ваши оценки
Измерять агента сложнее, чем его выпустить, и большинство наборов тестов остаются зелёными, пока продакшн уходит в сторону. Мы разберём вашу систему оценки целиком: что вы измеряете сейчас, чего пока не видите и какие регрессии текущий набор пропустит.
€750 вместо €1 500, одна неделя, письменный отчёт и разбор в звонке, до 30 сентября