Глава 56. Как выбирать модели и провайдеров без религиозной войны

На демо новая модель написала лучший ответ, и команда решила мигрировать. На русских договорах она действительно была сильнее. В production выяснилось, что p95 latency вырос вдвое, structured output иногда не проходил схему, а нужный регион обработки данных отсутствовал.

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

Выбор начинается с workload

Соберите репрезентативный набор запросов, включая длинные, грязные и опасные случаи. До теста задайте gates: качество по классам риска, schema validity, p95 latency, цена успешного результата, rate limits, регион, retention, SLA и условия использования данных.

use_case: invoice_extraction
hard_gates:
  schema_validity: 0.995
  critical_field_accuracy: 0.99
  p95_latency_ms: 8000
  data_region: eu
score_weights:
  quality: 0.55
  cost_per_success: 0.25
  latency: 0.20

def eligible(run, gates):
    return all(run.metrics[name] >= value for name, value in gates.minimums.items()) \
        and run.p95_ms <= gates.p95_ms

Тест запускают несколько раз: вариативность тоже свойство модели. Цена считается с retries и routing. Затем проводят shadow или canary на реальном распределении. Провайдерская переносимость означает не общий знаменатель всех API, а собственный контракт use case и адаптеры, которые сохраняют различия.

Failure modes

Публичный benchmark не совпадает с задачей. Средняя accuracy скрывает провал редкого дорогого класса. Бесплатный тариф меняет рейтинг. Судья-модель предпочитает ответы своего семейства. Миграция меняет tokenizer и разрушает бюджет контекста. Поэтому исходные ответы сохраняют и часть выборки оценивают вслепую люди.

Decision record вместо спора

Выбор модели — решение с датой годности. Оно устаревает быстрее, чем большинство архитектурных решений, поэтому его надо записывать так, чтобы через полгода можно было пересмотреть без нового спора.

Минимальный документ на одну страницу:

• use case и workload: какие запросы, какое распределение, какие дорогие классы;
• gates: пороги, зафиксированные до прогонов;
• результаты: таблица кандидатов по всем осям, включая разброс между прогонами;
• решение и обоснование: кто основной, кто резерв;
• что осталось непроверенным: честный список;
• дата пересмотра и владелец.

Дата пересмотра важнее самого выбора. Без неё команда либо мигрирует на каждую новость, либо не мигрирует никогда, и оба режима одинаково плохи.

Правило главы

Выбирайте минимальную модель и провайдера, которые проходят заранее записанные gates на вашем workload. Победитель меняется без переписывания веры команды.

Чеклист главы

• Набор запросов репрезентативен: длинные, грязные, опасные и редкие дорогие случаи включены.
• Gates заданы до прогонов: качество по классам риска, schema validity, p95, цена успеха, лимиты, регион, retention.
• Сделано минимум три прогона; разброс между прогонами посчитан и учтён.
• Цена считается с учётом ретраев и роутинга, а не по прайсу за токен.
• Слепое сравнение части выборки выполнено людьми; judge не является единственным арбитром.
• Проверены нефункциональные условия: регион, SLA, условия использования данных, лимиты.
• Токенизация и бюджеты контекста пересчитаны под каждого кандидата.
• Перед переключением проведён shadow или canary на реальном распределении.
• Решение оформлено decision record с датой пересмотра и владельцем.
• Резервный маршрут проверен на том же наборе, а не назначен по остаточному принципу.

Практикум

Задача 56.1 — сравнение с записанными заранее правилами. ⭑⭑⭑

Сравните две модели на 100 примерах одного use case.

Критерии приёмки:

• Gates и веса зафиксированы до запуска и не менялись после просмотра результатов.
• Сделано минимум три прогона; посчитаны разброс, p95 и цена валидного результата.
• Проведено слепое сравнение двадцати пар людьми; результат сопоставлен с автоматической оценкой.
• Проверены нефункциональные требования: регион, лимиты, retention, условия использования данных.
• Оформлен decision record с датой следующего пересмотра и владельцем.

Подсказки:

1. Фиксируйте gates письменно и покажите их коллеге до прогона: это единственная защита от подгонки критериев под понравившийся результат.
2. Разброс между прогонами часто больше разницы между моделями. Если так — у вас нет победителя, и это тоже вывод.

Задача 56.2 — миграция без сюрпризов. ⭑⭑

Спланируйте переход на выбранную модель как обычный релиз.

Критерии приёмки:

• Пересчитаны бюджеты контекста под новую токенизацию; лимиты обновлены.
• Прогнан eval-набор и adversarial-набор; регрессии в дорогих классах отсутствуют.
• Переход выполнен через shadow или canary с одновременным control.
• Готов и отрепетирован откат; известно, что делать с задачами, поставленными до переключения.
• Через две недели подведён итог по качеству, стоимости и latency, и он записан в decision record.

Подсказки:

1. Structured output — первое, что ломается при смене модели. Проверяйте его отдельно и до всего остального.
2. Не мигрируйте одновременно с изменением промпта: иначе разбираться в результате будет невозможно.