От вайб-проверок к регрессии: зачем LLM-фичам нужны quality gates в CI

На демо всё выглядит нормально. Промпт аккуратный, ответы связные, JSON парсится, никто не задаёт вопросов. Несколько прогонов спустя — всё ещё работает. Релизим.

Через неделю тот же самый запрос три раза подряд возвращает некорректный ответ. Не так, чтобы всё упало. Просто достаточно, чтобы сломать downstream парсер и разбудить кого-то в два часа ночи. Ничего драматичного. Просто отказ, который повторяется достаточно часто, чтобы начать мешать.

Этот сценарий возникает снова и снова не потому, что команды некомпетентны. Проверка “на глаз” кажется разумной. LLM-фича не падает с исключением, не даёт stack trace, не нарушает очевидных инвариантов. Таблицы expected output здесь не существует. Истину проверить нельзя — проверяют правдоподобие. Ответ звучит нормально, структура в целом держится, а edge cases выглядят академическими.

Есть и культурный зазор. CI вырос вокруг детерминированного кода: фиксированные входы, выходы, которые либо совпадают, либо нет. LLM-фичи выглядят как интерфейсы, но ведут себя как стохастические сервисы с памятью. В ответ команды делают то, что умеют: несколько ручных прогонов, пара промптов в стейдже, галочка “ок”. Это не халатность, а привычная реакция на систему, которая при первом контакте выглядит вежливой и стабильной.

Ломается всё не на демонстрации. Ломается на повторении, дрейфе и накоплении мелких изменений. В промпте сдвинули запятую. Обновилась модель. Temperature подкрутили с 0.2 до 0.4 “для живости”. Прогоните это пятьдесят раз — и картина меняется.

Читать далее