Reasoning drift в AI: как модель деградирует при работающем сервисе

Reasoning drift как скрытая операционная проблема

На Reddit разгорелась дискуссия о Claude: жалобы на медлительность, ухудшение качества кода, потерю связности, полуответы, странные отказы. Сервис при этом формально работает — ответы приходят, подписка активна, интерфейс не падает. Складывается впечатление, что модель быстрее сдаётся, хуже удерживает контекст, всё чаще выдаёт неполноценные решения.

Это ощущение подтвердилось более серьёзным сигналом: на GitHub появился подробный issue по Claude Code с описанием деградации качества, который связали с менеджером AI-группы AMD Stella Laurenzo. Но главный вопрос не в том, деградировал ли Claude на самом деле. Главный вопрос: есть ли какие-либо гарантии защиты пользователей, когда коммерческая AI-модель формально работает, но качество результата падает? Для компаний, внедривших AI в критичные для бизнеса процессы, это реальная угроза.

Три разных явления под одним названием

Фраза «модель стала хуже» хорошо отражает эмоции, но плохо помогает разобраться. Под ней смешиваются минимум три сценария:

• Настоящее ухудшение качества решений — модель действительно стала хуже справляться с задачами • Изменение формата ответа — модель отвечает короче или суше, хотя результативность могла остаться прежней • Рост непредсказуемости — средний уровень прежний, но результаты сильнее гуляют от запроса к запросу

В этом материале речь идёт прежде всего о первом сценарии — reasoning drift: ситуация, в которой модель со временем хуже удерживает ход решения, сбивается с плана, перестаёт соблюдать условия, теряет нить длинной сессии и выдаёт ответы, которые звучат убедительно, но не доводят задачу до конца. Это особенно проявляется на длинных, многошаговых задачах, требовательных к контексту.

Рядом с reasoning drift есть другая, близкая по ощущениям, но иная по природе проблема — safety drift: модель не столько хуже рассуждает, сколько чаще перестраховывается и отказывает даже в допустимых сценариях. Это разные случаи, хотя пользователю их легко перепутать.

Как это выглядит в боевых условиях

Один из самых неприятных симптомов — полуответы: внешне внятный ответ, который по сути не решает поставленную задачу:

• Модель предлагает подход, но не доводит его до рабочего результата • Отвечает только на один аспект сложного вопроса • Начинает писать код, но обрывается задолго до завершения функции • Забывает собственный план спустя время, пропускает ключевые шаги

В реальных обсуждениях пользователи сообщают о конкретных случаях: код обрывается прямо внутри функции, простая фронтенд-правка формы, которая раньше занимала минуты, растягивается на двадцать минут. Модель может закрыть 2 из 7 пунктов задачи или начать галлюцинировать. Показательный пример: пользователь потратил более 50 000 токенов только на то, чтобы вернуть модель к уже согласованному плану.

Проблема в том, что стандартные метрики мониторинга (задержка ответа, частота сбоев, доступность) хорошо ловят падение сервиса, но плохо замечают ситуацию, когда сервис функционирует, а качество результата проседает на критичных задачах.

Парадокс: что вы на самом деле покупаете

Если я плачу за доступ к мощной модели, её работа должна оставаться неизменной. Но это ожидание не совпадает с реальностью AI-сервисов. Подписка — это не доступ к зафиксированной версии алгоритма. Это доступ к внешнему сервису, где постоянно меняются:

• Распределение нагрузки — как система распределяет запросы между серверами • Выделяемые ресурсы — сколько вычислительной мощности на обработку каждого обращения • Система подсказок — какие данные и инструкции влияют на реакцию модели до начала диалога • Обработка больших текстов — как система управляется с длинными сообщениями • Параметры генерации — вариативность ответов («температура») и степень усилий • Производительность при нагрузке — выдержит ли платформа пиковые всплески

Одна и та же модель по названию может быть совершенно разной системой по фактическому поведению. Пользователь часто не знает и не может узнать, получает ли он ту же конфигурацию, что неделю назад.

Здесь есть неочевидный момент: провайдер может выпустить обновление, которое одновременно улучшит модель для большинства, снизит стоимость, сделает поведение безопаснее — и ухудшит качество на узком, но критичном классе задач конкретного клиента. Провайдер оптимизирует скорость, стоимость, безопасность и среднее качество. Улучшение по одним метрикам вполне может сопровождаться ухудшением на важном для вас классе задач. Парадокс: глобального падения качества модели может не быть, но для конкретного бизнеса картина выглядит иначе — рабочий процесс разваливается.

Почему для B2B это больнее

Для индивидуального пользователя снижение производительности — досадное неудобство. Для бизнеса, внедривших AI в работу, это уже операционная проблема. Типовой сценарий: аналитик или разработчик регулярно опирается на AI в длинных и дорогих по времени задачах. Пока модель работает стабильно, он справляется с нагрузкой. Но если качество начинает понемногу проседать, растёт не только число перезапусков, но и объём ручной проверки, доработки, возврата к уже согласованным шагам.

Проблема в том, что это редко выглядит как явная поломка. Замедление легко списать на сложность задачи, нечёткое ТЗ или неудачный день. Деградация качества рассуждений может выражаться не в очевидной поломке, а в скрытом росте расходов и сроков проекта, несмотря на формальную работоспособность сервиса.

Что рынок обещает и чего не обещает

Провайдеры (OpenAI, Anthropic, Google) хорошо проработали:

• Процедуры вывода моделей из обращения и прекращение поддержки • Версионирование и снимки состояния — чёткое обозначение версий и использование псевдонимов • Описание изменений в релизах и этапы жизненного цикла • Уровни обслуживания (SLA) с описанием гарантий доступности • Поддержка пользователей и советы по миграциям

Однако практически отсутствуют правила для:

• Стабильности качества на критичных сценариях — нет обязательств на специфичные для клиента классы задач • Стабильности уровня рассуждений — нет гарантий по многошаговым логическим цепочкам • Информирования о существенных изменениях качества, не приводящих к нарушению API • Механизмов доказательства скрытых регрессий — как документировать и верифицировать деградацию • Компенсаций клиентам, когда интерфейс доступен, но результативность падает

Одна из причин отсутствия стандартов — нет унифицированного подхода к измерению качества на реальных задачах, особенно где важны длинные рассуждения, полнота ответа и устойчивость. Поставщики балансируют между качеством, скоростью, стоимостью и безопасностью. Для пользователя это означает одно: от скрытой регрессии качества он защищен слабо.

Важный косвенный сигнал: согласно Stanford HAI Foundation Model Transparency Index за 2025 год, прозрачность в AI-индустрии снижается. Это напрямую не про деградацию рассуждений, но объясняет, почему ожидать прозрачности именно в этом вопросе пока не стоит.

Вывод: фрагментарная защита существует, но требует значительных усилий самого клиента — введения собственных процедур контроля, доработки инфраструктуры, активного взаимодействия с провайдером. Тот, кто положился на внешний AI-сервис без подстраховки, рискует столкнуться со скрытым, но реальным падением производительности.