Дрейф — постепенное расхождение между тем, на что система была настроена, и тем, что приходит на вход сегодня. Модель не меняется, меняется мир вокруг неё — и качество падает без единой правки кода.
Это главная причина, по которой ИИ-решение нельзя сдать и забыть: без регулярных замеров деградация всплывает по жалобам, когда потери уже накопились. Базовые схемы замеров собраны в статье про мониторинг ИИ-систем.
Виды
Дрейф входных данных (ковариатный). Меняется то, что приходит: новые формулировки обращений, другой формат документов, новый канал с иной лексикой. Система обучалась и настраивалась не на это. Пример: классификатор обращений настраивался на письма из почты, а через год подключили мессенджер — сообщения короче, лексика разговорная, и запросы уходят от тех, на которых подбирались пороги уверенности.
Дрейф связи (концептуальный). Меняется правильный ответ при тех же входных данных. Обновился регламент, изменились условия, появилась новая услуга. Самый коварный вид: данные выглядят прежними, а верное поведение стало другим. Пример: срок возврата изменили с 14 дней на 30 — система по-прежнему уверенно отвечает «14», и это не сбой модели, а устаревший источник; в RAG-системах такое лечится переиндексацией базы знаний.
Приоритетный дрейф (сдвиг долей). Сами входы прежние, но меняются пропорции: раньше 80% обращений касались доставки, теперь половина — о новой услуге. Каждая категория в отдельности обрабатывается как раньше, но общие метрики, нагрузка на контур проверки и структура затрат смещаются. Ошибок не прибавилось — изменился вес тех ошибок, что были.
Дрейф на стороне поставщика. Специфичный для облачных моделей: версия обновилась, и поведение изменилось, хотя у вас ничего не менялось.
На практике виды накладываются: новый канал приносит и новую лексику, и новые темы, поэтому первым вопросом диагностики будет «что именно сместилось — входы, верные ответы или их доли».
Как проявляется
Редко резко. Обычно это медленное сползание: чуть больше отказов, чуть чаще передача человеку, чуть выше доля повторных обращений по тому же вопросу.
Именно поэтому дрейф обнаруживают поздно — когда накопились жалобы. Разовое падение заметно сразу, а сползание на процент в месяц не замечает никто, если его не мерить.
Ранние признаки, видные в журналах до падения качества.
- Средняя длина обращения растёт или падает без изменений в продукте — признак ковариатного дрейфа.
- В запросах появляются слова, которых не было в первых месяцах: названия новой линейки, сленг нового канала.
- Смещается распределение категорий — доля одной темы выросла в полтора–два раза за несколько недель.
- В RAG растёт доля запросов, по которым не нашлось релевантного документа.
- Люди в контуре проверки начинают править ответы одного и того же типа — локальный сигнал, который точнее общих метрик.
Как обнаруживать
Регулярный прогон проверочного набора. Самый прямой способ: те же вопросы, те же эталоны, раз в месяц. Падение доли верных ответов видно сразу. Рабочий порог сигнала — падение на 3–5 процентных пунктов против предыдущего прогона; меньшие колебания обычно объясняются шумом разметки.
Наблюдение за распределением входов. Длина обращений, доля новых слов, соотношение категорий. Резкое изменение — сигнал, даже если качество ещё не просело. Считается автоматически из журналов, достаточно еженедельного среза.
Косвенные показатели. Доля отказов, доля передач человеку, доля повторных обращений. Собираются непрерывно и часто сигналят раньше прямых замеров: их стоит вывести на дашборд рядом с техническими метриками.
Обратная связь. Исправления, вносимые людьми в контуре проверки, — самый ценный источник: они показывают не только что стало хуже, но и где именно.
Итого ритм замеров: косвенные показатели — непрерывно, распределение входов — еженедельно, проверочный набор — раз в месяц, ревизия самого набора — раз в квартал.
Что делать
При дрейфе входных данных обычно достаточно обновить примеры и проверочный набор. При дрейфе связи — переиндексировать документы и убрать устаревшее. При изменении версии модели — прогнать проверочный набор и, если нужно, закрепить версию у поставщика.
Последнее стоит решить до запуска: работать на «последней версии» удобно, пока она не поменяется в неудобный момент. Закреплённая версия превращает чужое обновление в осознанное решение вашей команды, а не событие в журнале ошибок.
Как выстроить регулярную проверку
Минимальная схема, которая работает без отдельной инфраструктуры: раз в месяц прогон проверочного набора, запись результата в ту же таблицу, где ведутся эксперименты, и сравнение с предыдущими значениями. Если эксперименты уже фиксируются в системе отслеживания экспериментов, регулярный прогон занимает место одного эксперимента и наследует его историю сравнений.
Объём набора — 50–200 вопросов для типовой задачи; при меньшем колебания от прогона к прогону заглушают эффект, при большем прогон дорожает без выигрыша в чувствительности. Автоматический прогон такого объёма занимает минуты и обходится в несколько тысяч токенов.
Важно, чтобы набор при этом не менялся. Обновлять его нужно, но отдельно и осознанно: старый сохраняется для сравнения, новый ведётся параллельно. Иначе непонятно, изменилась система или изменились требования.
Что делать с накопленными обращениями
Реальные обращения — лучший источник для обновления набора. Раз в квартал полезно взять выборку из журналов, разметить правильные ответы и добавить в набор те случаи, которых в нём не было.
Отдельно стоит собирать вопросы, на которых система ошиблась и человек поправил: они показывают границу применимости точнее любых придуманных примеров.
При разметке журналов действует то же ограничение, что и при обучении: персональные данные из обращений обезличиваются до передачи разметчикам за пределами контура компании — требования 152-ФЗ распространяются на выборку так же, как на исходные данные.
Типичные ошибки
Менять набор и систему одновременно. Обновили примеры и промпт в один заход — сравнить не с чем, эффект изменений неотделим от смены меры. Правильный порядок: зафиксировать результат на старом наборе, затем менять одно за раз.
Лечить дрейф дообучением. При концептуальном дрейфе дообучение без обновления источников закрепляет устаревшие ответы. Сначала обновляются данные и регламенты, потом — модель или промпт.
Мерить только доступность и задержки. Технические метрики при дрейфе в норме: система быстро и стабильно отвечает неправильное. Качество замеряется отдельно, иначе деградация невидима до жалоб.
Подгонять промпт под последние жалобы. Десять свежих случаев — не выборка; правка под них регулярно снижает качество на остальном объёме. Решение о правке принимается по прогону набора, а не по последнему письму.
Частые вопросы
Как быстро наступает дрейф?
Зависит от предметной области. Там, где регламенты и продукты меняются часто, заметная деградация возможна за месяцы. Там, где всё стабильно, система может работать годами. Универсального срока нет — поэтому и нужен регулярный замер.
Может ли модель испортиться сама?
Сама модель — нет, если она локальная и зафиксирована. Портится соответствие между ней и реальностью. У облачных моделей добавляется ещё один источник: обновление версии на стороне поставщика без вашего участия.
Как понять, что дело в дрейфе, а не в поломке?
Поломка проявляется резко и обычно видна в ошибках, дрейф — медленным сползанием показателей при отсутствии технических сбоев. Различить помогает сохранённый проверочный набор: если на старых вопросах качество прежнее, а на новых обращениях падает, это дрейф входных данных.
Чем ковариатный дрейф отличается от концептуального на практике?
Проверочным вопросом: «на старых примерах система отвечает по-прежнему верно?» Если да, а на новых обращениях ошибается — ковариатный: изменились входы. Если ошибается и на старых примерах, где раньше была права, — концептуальный: изменилось верное поведение, и лечится это обновлением источников, а не примеров.
Сколько вопросов нужно в проверочном наборе?
Для типовой задачи — 50–200, покрывающих основные категории пропорционально их доле в реальных обращениях. Чувствительность к падению на 3–5 процентных пунктов при меньшем объёме низкая: один–два случайных промаха перекрывают сигнал.
Поможет ли дообучение при дрейфе?
При ковариатном — да, если дообучать на свежих примерах из нового канала или формата. При концептуальном дообучение без обновления базы знаний закрепляет устаревшие ответы: сначала чинятся источники, потом при необходимости модель. Порядок проверяется прогоном одного и того же набора до и после каждого шага.