Canary-релиз LLM: почему сравнение общих процентов может обмануть
Новый вариант получает небольшую долю трафика, но туда случайно попали в основном простые вопросы. Его среднее качество выше, хотя на сложных сценариях он хуже старого. Для canary важны сопоставимость групп, устойчивое назначение и проверка отдельных срезов.
Не меняйте долю и правила отбора одновременно с промптом без записи. Иначе после инцидента будет непонятно, изменилось решение или состав пользователей.
Где возникает ошибка
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Срез | Старый вариант | Новый вариант | Что сравнивать |
|---|---|---|---|
| Простые вопросы | Много случаев | Почти весь canary | Недостаточно общего среднего |
| Сложные ограничения | Есть случаи | Мало случаев | Нужна отдельная проверка |
| Закрытые документы | Проверены | Не представлены | Покрытие отсутствует |
Малое число случаев в критичном срезе означает неопределённость, а не отсутствие проблем. Для редких опасных сценариев используйте закреплённый набор проверок до выпуска и контролируемые тесты, а не ждите случайного появления в canary.
Единица назначения тоже важна. Если один разговор переключается между вариантами, накопленное состояние может смешать поведение и испортить сравнение.
Как воспроизвести проблему
Определите единицу распределения, показатели успеха и критерии остановки до запуска. Сохраняйте вариант на протяжении выбранной единицы, например задачи или диалога. Проверяйте сопоставимость намерений и источников, не раскрывая лишние персональные данные.
Покажите вместе качество, ошибки, задержку и расход. При ухудшении выясните, связано ли оно с новым вариантом либо общим сбоем источника. Не объявляйте победу после первых нескольких удачных запросов. Для расширения доли нужен заранее понятный набор свидетельств, а не только хорошая средняя оценка.
Что учитывать при переносе
Canary ограничивает масштаб риска, но не делает эксперимент статистически достаточным автоматически. Для небольшого трафика проверка может занять долго. Критичные запреты должны работать независимо от доли эксперимента.
Мониторинг должен связывать сигналы с пользовательским опытом; правила сравнения вариантов и срезов задаются экспериментом. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Откат LLM-релиза: почему старый код может не работать с новым индексом, Нагрузочный тест LLM: почему прогрев кэша может скрыть реальную стоимость.
