Concept drift: был хорош на запуске, через месяц поплыл
🤔 Зачем это читать
На запуске всё было прекрасно. Бот в поддержке отвечал точно, клиенты хвалили, на совещании ты гордо показывал цифры: 9 из 10 обращений закрывает сам. Прошло полтора месяца. И вдруг — жалобы. «Ваш бот несёт чушь», «посоветовал товар, которого у вас нет», «отвечает мимо». Ты в недоумении: мы же ничего не трогали. Код тот же, настройки те же. Лезешь к разработчикам — те разводят руками: «у нас всё работает, ничего не меняли».
Знакомо? Или другой вариант, ещё коварнее. Никто не жалуется громко — просто медленно растёт число обращений, которые бот перекидывает на живого оператора. По чуть-чуть, незаметно. Через квартал ты вдруг обнаруживаешь, что «автономный» бот закрывает уже не 9 из 10, а 6 из 10, нагрузка на людей вернулась, а экономии, под которую брали бюджет, нет. И никто не может сказать, в какой именно день это сломалось, потому что не ломалось в один день — оно сползало.
Дело вот в чём: сломался не код. Изменился мир вокруг агента. Завезли новые товары, сменился поставщик и прайс, клиенты стали спрашивать про другое, провайдер обновил саму модель. Рецепт тот же — а блюдо поплыло. У этого явления есть имя: дрейф (concept drift) — медленное расхождение между тем, на что агент был настроен, и тем, что происходит на самом деле. Лечится оно не «один раз настроить и забыть», а живым наблюдением плюс регулярной переоценкой.
После этой темы ты научишься отличать дрейф от обычной разовой ошибки — по тому, как именно агент «портится», — и понимать, что с ним делать. Это граница между «у нас почему-то всё развалилось, виноватых нет» и «мы поймали сползание на цифрах раньше, чем его заметил клиент».
Задержись на 10 секунд. Вспомни любую вещь у себя на работе, которая «когда-то работала, а потом незаметно перестала». Скрипт продаж, который устарел под новых клиентов. Регламент, написанный под старый ассортимент. Отчёт, в который годами тянут уже не те цифры. Никто его не ломал — просто мир уехал, а он остался. Подержи эту картинку: с AI-агентом ровно так же, только сползает он быстрее.
🍲 Рецепт тот же — а блюдо поплыло
Представь, ты держишь ресторан. Полгода назад поставил в меню фирменный томатный соус — он гремел, гости возвращались ради него. Рецепт записан до грамма, повар готовит ровно по нему, ничего в нём не менял. А последние недели соус «не тот»: то кисловат, то водянист, гости морщатся. Повар клянётся, что делает всё как написано. И ведь не врёт.
Что произошло? Сменился поставщик помидоров. Новая партия кислее и водянистее прежней. Рецепт, выверенный под старые помидоры, на новых даёт другой вкус. Виноват не повар и не рецепт — изменился продукт на входе, а рецепт остался прежним. Вот это и есть дрейф: мир под блюдом уехал, а настройка — нет.
С AI-агентом один в один. «Рецепт» — это его инструкция и примеры, на которых он был настроен на запуске. «Продукты на входе» — это реальность вокруг: ассортимент, прайс, формулировки клиентов, сама модель-повар. Пока реальность совпадает с той, под которую настраивали, блюдо «то самое». Реальность сползла — блюдо поплыло, хотя в рецепте не тронули ни строчки. Вот четыре поставщика, которые меняются чаще всего:
- Сменился ассортимент и прайс. Завезли 200 новых позиций, убрали старые, переписали цены. Агент уверенно советует то, чего на складе уже нет, и называет вчерашние суммы.
- Сменились запросы клиентов. Раньше спрашивали про доставку, теперь — про рассрочку и обмен старого на новый (trade-in). Агент настроен на старые вопросы и в новых плавает.
- Сменился внешний источник. Партнёр поменял формат прайса, у поставщика другой каталог, в системе новые поля. То, из чего агент берёт факты, стало выглядеть иначе.
- Обновилась сама модель. Провайдер выкатил новую версию повара — и она отвечает чуть иначе, чем та, под которую вы всё вылизывали. Это мы подробно разбирали в теме 2.7 — Модели стареют за недели: модель под тобой меняется, даже когда ты сам ничего не трогаешь.
«всё отлично»
завезли товары
прайс
клиентов
🥄 Почему дегустация нужна не один раз на открытии
Главная ошибка владельца — попробовать блюдо один раз, на открытии, убедиться «вкусно» и больше не пробовать никогда. На кухне так не делают: хороший шеф снимает пробу регулярно — на каждой новой партии продуктов, каждую смену. Потому что вкус плывёт не от того, что рецепт испортился, а от того, что меняются продукты под ним.
В теме про оценку мы уже разбирали этот приём — дегустация (оценка, eval): прогоняешь агента по набору заранее подготовленных вопросов с известными правильными ответами и смотришь, насколько он попал. Так вот, ключевая мысль этой темы: дегустацию нельзя делать только перед запуском. То, что проверяют до открытия зала, называют офлайн-оценкой (offline eval) — это проба на тест-кухне, для своих. А то, что делают на работающем агенте, на живом потоке, изо дня в день, — это онлайн-оценка (online eval), та самая регулярная проба ложкой по ходу смены. Без второй ты узнаёшь о дрейфе последним — от клиента.
«Регулярно пробовать» на языке агента — это два простых движения, и оба про наблюдение, которое мы разбирали в этом модуле:
- Живой мониторинг. Смотришь не разово, а постоянно: какая доля обращений уходит на человека, сколько клиентов недовольны, как часто агент говорит «не знаю». Эти цифры ползут вниз раньше, чем приходят жалобы.
- Регулярная переоценка. Тот же дегустационный набор вопросов прогоняешь по агенту не один раз, а по расписанию — раз в неделю, раз в месяц. Балл пополз вниз — сигнал: блюдо плывёт, пора разбираться, какой поставщик сменился.
А когда дрейф пойман — лечение по сути одно: обновить «рецепт» под новые «продукты». Подсунуть агенту свежие примеры (как теперь спрашивают клиенты), подтянуть актуальные данные (новый прайс, новый каталог), перепроверить инструкцию под новую модель. Не «чинить поломку», а догнать настройку до сползшей реальности.
# дегустационный набор: 100 типовых вопросов с эталонными ответами
КАЖДЫЙ ПОНЕДЕЛЬНИК:
прогнать агента по 100 вопросам набора
посчитать балл = доля попаданий в эталон
ЕСЛИ балл на этой неделе сильно ниже прошлой:
# блюдо поплыло — НЕ ждём, пока пожалуется клиент
поднять тревогу → разобраться, какой «поставщик» сменился
обновить примеры и данные под новую реальность
ИНАЧЕ:
всё ровно, едем дальше
# суть: пробуем по расписанию, а не один раз на открытии
Заметь главное отличие от обычной поломки. Обычная ошибка — это сбой здесь и сейчас: отвалился доступ к складу, агент вернул пустоту, ты починил доступ — всё работает. Дрейф — это не сбой, это медленное расхождение: ничего не отвалилось, всё «работает», просто настройка всё больше расходится с реальностью. Первое чинят на месте. Второе — ловят наблюдением и догоняют переоценкой. Спутать их легко, и именно на этом — тренажёр ниже.
🎮 Дрейф или разовый сбой?
Три ситуации с работающего агента. По каждой — два решения. Твоя задача — прочитать симптом и выбрать, что это: медленный дрейф (лечится наблюдением и переоценкой под новую реальность) или разовая поломка (чинится на месте). Жми вариант — сразу увидишь разбор. Опора простая: сполз постепенно и «всё работает» — дрейф; отвалилось резко и сломано — сбой.
📖 Ключевые понятия
- Дрейф (concept drift)
- Медленное расхождение между тем, на что агент был настроен, и тем, что происходит на самом деле. Код и настройки те же, но мир под ними уехал: новый ассортимент, новый прайс, другие запросы клиентов, обновлённая модель. Рецепт прежний — блюдо поплыло. Не поломка, а сползание.
Строго в ML это целое семейство дрейфов. Когда меняется поток входных данных (новый ассортимент, прайс, каталог) — это ближе к дрейфу данных (data drift); когда меняется сама связь «вопрос → правильный ответ» (клиенты спрашивают про другое, обновился сам «повар»-модель) — это дрейф концепта (concept drift) в узком смысле. В обиходе всё это зовут просто дрейфом, и для владельца разница невелика: лечение одно — держать оценку живой. - Офлайн-оценка (offline eval)
- Дегустация на тест-кухне, до запуска: прогнали агента по набору вопросов с известными ответами, убедились, что готов. Нужна, но устаревает — реальность за окном меняется, а набор остался прежним. Поэтому одной её мало.
- Онлайн-оценка (online eval)
- Та же дегустация, но на работающем агенте, по расписанию: раз в неделю или месяц гоняем тот же набор и смотрим, не пополз ли балл. Это и есть «снимать пробу регулярно, а не один раз на открытии». Главное оружие против дрейфа.
- Живой мониторинг
- Постоянное наблюдение за рабочими цифрами агента: доля обращений на человека, недовольство клиентов, как часто он отвечает «не знаю». Эти числа сползают раньше, чем приходят жалобы, — и потому ловят дрейф первыми.
🛡️ Частые заблуждения
«Раз на запуске протестировали и было хорошо — дальше можно не трогать»
Это и есть главная ловушка. «Хорошо на запуске» гарантирует качество только под тот мир, что был на запуске. Мир уезжает: товары, цены, запросы, сама модель. Проверка один раз — как попробовать соус только на открытии ресторана и больше никогда. Пробу снимают регулярно, иначе блюдо тихо плывёт.
«Качество просело — значит, что-то сломалось, ищем поломку»
Не обязательно. Поломка — это резкий сбой здесь и сейчас, с технической причиной в логах (отвалился доступ, ошибка соединения). Дрейф — это плавное сползание, когда всё «работает», но настройка всё дальше от реальности. Искать «поломку» при дрейфе бесполезно: ломать нечего. Надо догонять настройку до изменившегося мира, а не чинить несуществующий сбой.
«Мы же ничего не меняли — значит, агент не мог испортиться»
Мог, и именно поэтому. Чтобы агент «поплыл», вам и не нужно ничего менять — достаточно, чтобы изменился мир вокруг. Завезли товары, поставщик переписал прайс, провайдер обновил модель. Вы стоите на месте, а реальность под вами движется — и неподвижная настройка с каждым днём всё дальше от неё. «Ничего не трогали» — это не алиби, а как раз диагноз.
🧠 AI-чутьё (AI Judgment)
Дрейф неизбежен — вопрос в том, узнаешь ты о нём от цифры или от клиента
Рамка темы простая и неприятная: дрейф не «может случиться» — он случится обязательно. Мир вокруг любого AI-решения меняется по определению: ассортимент, цены, запросы клиентов, и сама модель стареет за недели (мы это разбирали в теме 2.7). Поэтому «настроили и забыли» — это не стратегия, а отложенный провал. Вопрос не «случится ли дрейф», а «насколько поздно ты о нём узнаешь».
И вот здесь главная развилка владельца. Если ты мониторишь агента только на запуске — ты узнаёшь о сползании последним, от рассерженного клиента, когда доля закрытых обращений уже упала, экономия испарилась, а репутация просела. Если ты держишь оценку живой — гоняешь дегустационный набор по расписанию и следишь за рабочими цифрами — ты ловишь сползание на графике раньше, чем его почувствует первый клиент. Одно и то же явление, разница только в том, кто сообщает тебе плохую новость: твоя приборная панель или твой клиент в отзыве.
Практический вывод: оценивая любой AI-проект — свой или вендорский — задавай не только вопрос «как он работает сейчас», но и «кто и как будет замечать, что он плывёт, и по каким цифрам». Если в плане проекта нет строчки про регулярную переоценку и живой мониторинг — это не готовое решение, а бомба замедленного действия с красивым демо. «Настроить и забыть» в мире AI не существует. Существует «настроить и регулярно пробовать».
🎯 Практика
Одно задание на пять минут — оно превращает «дрейф» из страшного слова в твою личную защиту от тихого провала.
- Возьми любое AI-решение, к которому ты имеешь отношение (или то, что вам предлагает вендор). Выпиши в столбик три «поставщика», которые под ним точно сменятся за ближайший год: ассортимент, прайс, типичные запросы клиентов, версия модели — что из этого у вас живое и движется?
- Для каждого пункта ответь честно: как мы узнаем, что он сменился и агент под него поплыл? Если ответ «нам пожалуется клиент» — это и есть твоя дыра. Запиши, какая цифра (доля на оператора, недовольство, «не знаю») сползала бы раньше жалобы.
- Сформулируй одну строчку для плана проекта: «раз в [неделю/месяц] прогоняем дегустационный набор и смотрим на [цифру]; балл пополз — разбираемся, какой поставщик сменился». Это и есть переход от «настроили и забыли» к «настроили и регулярно пробуем». Покажи эту строчку тому, кто отвечает за проект, — и посмотри, есть ли она у них уже.
Помнишь ту вещь с работы, что «когда-то работала, а потом незаметно перестала», с начала страницы? Теперь у тебя есть для неё имя — дрейф — и приём против него: не проверять один раз, а пробовать по расписанию. С AI это не роскошь, а условие, чтобы решение не протухло через месяц.