Выбор модели и выпуск изменений

Читайте после Evaluation and data. Здесь одна методика применяется и к замене модели, и к изменению промпта, retrieval или workflow.

Результат главы

После главы вы сможете составить сравнимый эксперимент, отвергнуть дешёвый небезопасный вариант и подготовить проверяемое решение о следующем этапе выпуска. Артефакты: experiment manifest, отчёт, release decision и карточка отката.

Наивный выбор и причина ошибки

Команда выбирает модель с минимальной ценой токена. Она чаще повторяет шаги и иногда пропускает approval. Средний счёт за вызов снизился, но стоимость завершённой задачи и риск для пользователя выросли.

Причина — неверная единица сравнения. Пользователь получает результат работы системы, а не отдельный токен. Модель, инструкции, инструменты, контекст и retries вместе определяют этот результат.

Сначала задача и ограничения

Для Helios задача звучит так: «Корректно обработать обращение по заказу; для возврата соблюдать approval; при недостаточных данных запросить источник или передать человеку». Реальный аналог — support в marketplace или fintech.

До сравнения score заполните карточку допуска кандидата:

Поле	Что проверить	Когда кандидат пока не допускается
Input/output	Языки, modality, structured output, tool interface	Не выражается обязательный контракт задачи
Context	Реальный объём instructions, tools, evidence и резерв ответа	Полезные данные не помещаются в проверенный бюджет
Данные	Какие данные отправляются, где хранятся, кому доступны, как удаляются	Условия обработки или владелец решения не определены
Использование	Лицензия весов либо условия API, ограничения сценария	Условия не проверены на дату эксперимента
Эксплуатация	Доступность, rate limits, version pinning, fallback	Нельзя восстановить обслуживаемую версию
Экономика	Лимит стоимости задачи и latency, ожидаемая нагрузка	Измеренный результат не помещается в лимит

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

Три стратегии

Стратегия	Выигрыш	Цена	Когда плохой выбор
Один устойчивый baseline	Простое сравнение и эксплуатация	Не оптимален для каждого случая	Резко разные требования у классов задач
Routing / cascade	Потенциальная экономия на простых случаях	Ошибки маршрутизации, retries и дополнительные задержки	Нет evals для всей цепочки
Self-hosted модель	Контроль размещения и исполнения	GPU, capacity planning, обновления и лицензия	Нет ресурсов поддерживать serving

Начните с наиболее простого допустимого варианта. Сравнивайте альтернативы на своей задаче; публичный benchmark не заменяет проверку tool use, языка и ограничений вашего продукта.

Зафиксировать эксперимент до просмотра результата

Manifest должен задавать:

• неизменные case IDs, входы, ожидаемые outcomes и версию grader;
• полный ожидаемый список (case_id, trial), независимый от полученных логов;
• safety cases и пороги качества, стоимости и задержки;
• baseline и candidate bundles: model/version, prompt, tools, policy, corpus, параметры;
• состав затрат и единицу измерения; включаются неудачные попытки и retries;
• способ сбора latency, нагрузку, cache policy и правила для timeout;
• дату, владельца решения и границы обобщения.

Меняя модель, держите остальные компоненты фиксированными. Если приходится адаптировать её промпт или инструменты, назовите это сравнением двух system bundles. Оно полезно, но не позволяет приписать весь эффект одной модели.

Для реальных LLM нужны повторные прогоны и неопределённость оценки. Trial IDs связывают случаи для анализа, но не делают случайность разных моделей одинаковой. Не считайте повторения одного случая независимыми пользовательскими задачами. Подробнее о graders и repeated trials: Anthropic: Demystifying evals.

Метрики с явным знаменателем

В этой лаборатории successful trial означает одновременно passed=true и safety_passed=true.

pass_rate = successful_trials / all_expected_trials
cost_per_success = cost_of_all_trials / successful_trials

Стоимость неудач остаётся в числителе. Если успехов нет, cost_per_success=null; такой кандидат не проходит gate. Входная стоимость одного trial уже должна включать все внутренние попытки, инструменты и другие затраты, которые включены в ваш эксперимент. Агрегатор сам не восстанавливает потерянные счета.

Latency считается по всем trials, включая неудачные. В примере p95 определяется методом nearest-rank: отсортировать N наблюдений и взять элемент с номером ceil(0.95 × N). При восьми наблюдениях это максимум. Такая выборка учит арифметике, но не характеризует хвост production-распределения.

Лаборатория: допустить следующий этап или отклонить

Подготовьте Python-окружение по входной главе. Команды из корня:

uv run --directory examples/helios_ml --frozen python scripts/review_experiment.py --candidate balanced

Скрипт читает examples/helios_ml/fixtures/model_experiment.json. В нём четыре кейса и по два trial; base, balanced, fast — вымышленные кандидаты, а costs и latency заданы вручную. Модели не вызываются. Это лаборатория анализа сохранённых измерений и правил допуска, не benchmark реальных LLM.

Ожидаемый отчёт:

Вариант	Успехи	Общая стоимость, условные единицы	Стоимость успеха	p95, учебные ms	Решение
base	7/8	0.32	≈0.0457	900	База сравнения
balanced	8/8	0.16	0.02	700	Допустить следующий этап
fast	6/8	0.04	≈0.0067	300	Отклонить: safety failure

Теперь выполните отдельно:

uv run --directory examples/helios_ml --frozen python scripts/review_experiment.py --candidate fast

Ожидается exit code 1, eligible_for_next_stage=false, причина safety_failure: две попытки возврата имеют отрицательный safety outcome. Это правильное срабатывание gate. Код 0 означает прохождение условий; код 2 — некорректный вход. Скрипт ничего не развёртывает и не изменяет active bundle.

Gate проверяет полноту case/trial, версии suite, допустимость чисел, обязательные safety cases, quality floor, latency/cost budget и отсутствие уменьшения числа успешных task outcomes для любого case относительно baseline. В маленькой лаборатории это консервативное правило; в реальном stochastic benchmark нужен заранее выбранный способ учитывать статистическую неопределённость, а не требование идентичного результата каждого случайного запуска.

Контролируемые изменения

Сделайте рабочую копию fixture под игнорируемым examples/helios_ml/artifacts/ и передайте её через --input. Для каждого опыта сохраните изменённый JSON и отчёт, затем объясните причину решения:

1. Удалите один и тот же trial у baseline и candidate, сохранив expected_trials. Ожидается ошибка входа, а не улучшенный pass rate.
2. Уменьшите max_p95_latency_ms до 600. balanced должен получить latency_budget.
3. Замените один успешный task outcome baseline-кейса у balanced на неуспешный. Проверьте case_regression:<case_id>, даже если общий floor ещё пройден.
4. Восстановите исходную копию и снова получите исходный отчёт. Это проверка воспроизводимости анализа.

Не меняйте expected outcomes, чтобы протолкнуть кандидата. Если требования задачи действительно изменились, нужна новая suite и повторное сравнение обеих версий.

Перенос на настоящие модели

Следующий эксперимент требует отдельных реальных прогонов:

1. Подготовьте frozen набор из своего домена, отделив development cases от финальной проверки.
2. Выполните baseline и кандидатов с одинаковыми бюджетами и окружением. Сохраните output, trajectory, фактический outcome, ошибки, стоимость и latency.
3. Получите passed и safety_passed независимыми graders. Не просите саму оцениваемую модель объявить себя успешной. Для денег перечитайте authoritative state.
4. Экспортируйте полную таблицу в формат fixture; укажите synthetic=false, реальные версии и единицы стоимости. Используйте --input для её анализа.
5. Разберите paired ошибки по cases, оцените неопределённость и устойчивость на новых случаях. Gate не вычисляет доверительные интервалы и не заменяет эту работу.

Положительный offline результат допускает следующий этап исследования. Он не означает «модель доказанно лучше» и не даёт автоматического разрешения на production.

Выпуск и репетиция отката

Версионируйте весь bundle, не только текст system prompt. PromptOps — часть общего release lifecycle из Production architecture.

Этап	Evidence для перехода	Stop condition
Offline	Полная suite, допустимые метрики, разбор регрессий	Пропущенные trials, safety failure, недостаточная выборка
Shadow	Сравнение на реальном потоке без выполнения candidate writes	Утечки данных, несравнимые условия, потеря наблюдений
Canary	Ограниченная доля трафика, owner, бюджеты и мониторинг	Нарушение policy, outcome regression, превышение заранее заданного SLO
Rollout	Достаточное наблюдение по важным срезам	Новая деградация или невозможность безопасного отката

Учебная репетиция, без deployment: подготовьте карточку для инцидента «в canary обнаружен возврат без approval».

• Какой сигнал остановит новые денежные действия и кто принимает решение?
• Какой exact bundle был активен до выпуска и совместим ли он с текущими state/schema/corpus?
• Как переадресовать новые runs и отдельно обработать уже начатые?
• Какая повторная проверка докажет восстановление outcome и policy?
• Какие совершённые эффекты требуют reconciliation или компенсации?

Критерий приёмки: в карточке названы предыдущая версия, владелец, триггер, действие, проверка восстановления и обработка in-flight runs. Возврат старого промпта не отменяет уже совершённый перевод. Если старый bundle несовместим с новым state, сначала требуется стратегия миграции; обещание «просто откатим» неполно.

Self-check

• Почему стоимость токена не равна стоимости результата?
• Где находится независимый перечень ожидаемых trials?
• Может ли лучший средний score компенсировать safety failure?
• Что означает p95 на восьми наблюдениях?
• Какие проверки остаются после зелёного offline gate?
• Как доказать откат и что делать с уже совершёнными эффектами?

Источники и границы

Проверено 2026-09-07: Anthropic: Demystifying evals — provider guidance по оценке; OWASP: System Prompt Leakage — почему секретность промпта не заменяет системные security controls. Пороги, fixture, gate и карточка отката — учебные конструкции курса, а не отраслевые нормативы.