Дрейф промпта (Prompt Drift)

Дрейф промпта — это постепенное изменение, обычно ухудшение, хотя иногда просто неожиданное изменение поведения, качества или согласованности вывода промпта в реальных условиях с течением времени, даже если сам текст промпта не редактировался. Чаще всего это вызвано изменением вне промпта: провайдер модели незаметно обновляет или прекращает поддержку версии модели за конечной точкой API, происходит сдвиг в реальном распределении входных данных, которые теперь получает промпт (промпт для классификации тикетов поддержки, настроенный на прошлогодние типичные типы тикетов, сталкивается с другой смесью проблем в этом году), или накапливаются пограничные случаи и необычные входные данные, которые исходный дизайн промпта никогда не предвидел. Это отдельный тип сбоя, отличный от преднамеренного изменения версии промпта (которое является отслеживаемой, намеренной правкой) — дрейф промпта часто незаметен, пока метрики точности или жалобы пользователей не раскрывают, что что-то ухудшилось, что делает его настоящим риском производственной надёжности для любой команды, активно не отслеживающей качество ИИ-функции с течением времени. Дрейф, вызванный провайдером модели, — это особенно важная и недооценённая версия этой проблемы: провайдеры периодически обновляют модели за тем же идентификатором модели API (или прекращают поддержку старых версий по определённому графику), и промпт, тщательно настроенный и оценённый для одной версии модели, может вести себя значительно иначе — иногда лучше, иногда хуже, а иногда просто иначе таким образом, что ломает нижестоящий парсер, ожидающий определённую особенность формата — как только базовая модель меняется, даже если ни один символ кода промпта приложения не был затронут. Защита от дрейфа промпта требует постоянной, а не разовой практики оценки: повторный прогон набора для оценки тестирования промптов по регулярному графику (не только при первоначальном запуске), фиксация конкретных версий моделей вместо псевдонима «последняя», когда важна воспроизводимость, и сознательная повторная оценка перед принятием новой версии модели, мониторинг реальных сигналов качества производственного вывода с течением времени (отзывы/жалобы пользователей, частота сбоев нижестоящего парсинга, выборочная ручная проверка), а также отношение к обновлению версии модели с той же строгостью оценки, что и к преднамеренному изменению версии промпта, поскольку с точки зрения контроля качества эти два риска функционально схожи. Конкретный пример: точность классификации ИИ-функции модерации контента, стабильная на протяжении месяцев на одном неизменённом промпте, неожиданно падает после того, как провайдер базовой модели прекращает поддержку зафиксированной версии модели и автоматически переводит трафик на более новую версию по умолчанию — новая модель немного иначе интерпретирует одну неоднозначную границу категории, чем старая, и, поскольку промпт не менялся, команда изначально не может объяснить падение точности, пока не проверяет логи версий моделей и не сопоставляет падение точно с датой миграции. Решение — повторный прогон набора оценки на новой версии модели и корректировка нескольких примеров границ категорий в их few-shot промпте для перекалибровки — восстанавливает точность, но основной урок приводит к изменению процесса: явно фиксировать версии моделей и переоценивать перед любой миграцией версий, а не принимать тихие автоматические обновления до «последней» версии.