Классические CI/CD-ворота хорошо работают с детерминированным ПО, но для систем на базе LLM этого уже недостаточно. Здесь деградирует не код, а поведение модели. В переводе статьи Freddy Daniel Alvarez Pinto, о котором пишет Tproger, разбирается, почему стандартные проверки не замечают постепенное ухудшение качества ответов, смещение распределения запросов и проблемы с контекстом.
Автор выделяет три типичных режима отказа: eval drift, distribution shift и context poisoning. В качестве примера он приводит ситуацию, в которой обновлённый RAG-пайплайн начал рекомендовать устаревшие цены из-за дрейфа embedding-модели. При этом тесты и алерты продолжали показывать зелёный статус.
Для production-систем на базе ИИ предлагаются четыре release gates: baseline eval suite, eval drift detection, shadow traffic validation и cost/latency guardrails. По словам автора, такие проверки должны отслеживать изменения поведения модели относительно исторических и production-данных, а не сводиться только к бинарному pass/fail. Отдельно подчёркивается, что eval-датасеты нужно версионировать так же тщательно, как Terraform state.
Ключевые факты
Автор выделяет три режима отказа: eval drift, distribution shift и context poisoning
В статье перечислены четыре release gates: baseline eval suite, eval drift detection, shadow traffic validation и cost/latency guardrails
Пример с RAG-пайплайном описывает дрейф embedding-модели, из-за которого система начала выбирать устаревшие чанки
Автор пишет, что более 20 лет управлял production-инфраструктурой, включая OpenStack, миграции баз данных и CI/CD-пайплайны