Последние недели вокруг Claude развернулась жаркая дискуссия на Reddit. Жалобы там очень разные: от медлительности и ухудшения качества кода до потери связности, полуответов и странных отказов на вполне обычных задачах. Формально сервис при этом работает: ответы приходят, подписка активна, интерфейс не лежит.

Ощущение знакомо мне лично - похожее впечатление стало складываться у меня в последние месяц-два во время работы даже с подпиской Max. Конечно, несколько сессий нельзя считать доказательством фактического регресса, однако складывается впечатление, что модель теперь быстрее сдаётся, хуже удерживает контекст и всё чаще выдаёт неполноценные решения.

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

Но меня в этой истории интересует уже не столько вопрос «деградировал ли Claude на самом деле», сколько другой: есть ли какие-либо гарантии защиты пользователей, когда коммерческая AI-модель формально продолжает работать, но качество результата меняется не в лучшую сторону? Ведь некоторые компании уже используют подобные AI-модели в рабочих процессах, критичных для бизнеса.

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

Почему мне захотелось разобраться

Если бы дело было только в моих ощущениях и в Reddit-тредах, я бы, наверное, не стал копать дальше. Но потом на GitHub появился подробный issue по Claude Code, где автор описывает ухудшение качества не по массе рабочих сессий. Ряд публикаций связал этот issue со Stella Laurenzo, старшим менеджером в AI-группе AMD. Само по себе упоминание её имени ещё ни о чём не свидетельствует, однако но выглядело как более серьёзный внешний сигнал, и стало интересно разобрать как инженерный вопрос, а не как разовую жалобу.

Почему «модель стала хуже» - это не одно явление

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

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

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

В этой статье меня интересует прежде всего первый сценарий - случаи, когда проседает именно качество решения задачи, а не только внешняя манера ответа.

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

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

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

И ещё одна оговорка: дальше я не включаю в reasoning drift ни safety drift, ни простую смену стиля ответа. Внешне они могут выглядеть похоже, но аналитически это другие случаи.

Для пользователя всё это действительно легко перепутать. Короткий ответ, распавшийся план, оборванное решение или внезапный отказ могут выглядеть одинаково: «модель стала слабее». Без систематической проверки трудно понять, с чем именно мы имеем дело - с реальным падением качества, сменой формата ответа, ростом разброса или сдвигом в сторону избыточной осторожности.

Полуответы: как проблема выглядит в работе

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

Модель предлагает подход, но не доводит его до рабочего результата;
Отвечает только на один аспект сложного вопроса;
Уходит в общие слова там, где нужен разбор по существу;
Начинает писать код, но обрывается задолго до завершения функции.

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

Код обрывается на полуслове. В треде Claude Performance Discussion пользователи часто отмечают случаи, когда AI прекращает ответ прямо внутри функции или перед финальным исправлением. Ответ формально присутствует, однако требует повторного выполнения работы вручную.

Модель забывает собственный план. В треде «Claude ignores its own plans, memory, and guardrails» автор описывает такую картину: Claude составляет подробный план, соглашается следовать правилам проекта, а спустя время пропускает ключевые шаги и делает задачу выполненной наполовину.

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

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

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

Что мы на самом деле покупаем, когда платим за AI

Ожидание простое: раз я плачу за доступ к мощной модели, значит её работа должна оставаться неизменной. Но это ожидание расходится с тем, как AI-сервисы устроены.

По сути, подписка - это не доступ к зафиксированной версии алгоритма. Это доступ к внешнему сервису, где множество факторов вне контроля пользователя постоянно меняются:

Маршрутизация запросов: каким образом система распределяет ваши запросы между серверами.
Вычислительные ресурсы: сколько вычислительной мощности выделяется на обработку каждого обращения.
Настройки безопасности: какие данные считаются подходящими для вывода.
Скрытый контекст: заранее заданный набор инструкций, влияющий на реакцию модели до начала диалога.
Обработка больших объёмов текста: как система управляется с длинными сообщениями.
Параметры генерации по умолчанию: такие как вариативность ответов («температура») и степень усилий.
Производительность при высокой нагрузке: насколько хорошо платформа выдерживает пиковые всплески активности.

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

Парадокс улучшения

Здесь есть неочевидный момент. Провайдер модели может выпустить обновление, которое одновременно:

улучшит модель для большинства пользователей;
ускорит ответы;
снизит стоимость обработки;
сделает поведение безопаснее;
и ухудшит качество на узком, но критичном классе задач конкретного клиента.

Это неудивительно: провайдер одновременно оптимизирует скорость, стоимость, безопасность и среднее качество на массовых сценариях. В такой системе улучшение по одним метрикам вполне может сопровождаться ухудшением на узком, но важном классе задач. Но именно поэтому фраза «в среднем модель стала лучше» для конкретной команды может быть бесполезна, если просел именно её рабочий сценарий.

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

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

Для индивидуального пользователя снижение производительности модели - досадное неудобство: можно переключиться на другой инструмент. Но для бизнеса, внедрившего AI в работу, это уже может стать операционной проблемой.

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

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

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

Я прошёлся по публичным документам OpenAI, Anthropic, Google, и увидел некоторую асимметрию.

Что у провайдеров проработано неплохо:

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

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

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

Одна из причин - отсутствие стандартизированного подхода к измерению качества на реальных задачах, особенно там, где важны длинные рассуждения, полнота ответа и устойчивость на критичных сценариях. Сами поставщики вынуждены балансировать между требованиями качества, скорости обработки запросов, стоимости и безопасности.

Но для пользователя практический итог один: от скрытой регрессии качества он защищён слабо.

Косвенный, но важный сигнал: общая прозрачность в AI снижается

Здесь стоит упомянуть одну вещь, которая напрямую не про деградацию качества рассуждений, но хорошо объясняет, почему ожидать прозрачности именно в этом вопросе пока не стоит.

В декабре 2025 года Stanford HAI (Transparency in AI is on the Decline) и CRFM (The 2025 Foundation Model Transparency Index) опубликовали очередной индекс прозрачности фундаментальных моделей (Foundation Model Transparency Index). Этот индекс оценивает не информирование пользователей о колебаниях качества работы модели, а гораздо более общие аспекты: доступность сведений о тренировочных данных, объёмах вычислений, потенциальных рисках и мониторинге после выпуска продукта. То есть вещи более базовые, чем «сообщили ли вы пользователям, что качество рассуждений просело».

Уже здесь наблюдается явный регресс: средний показатель отрасли снизился с 58 баллов в 2024-м до всего лишь 40 в 2025-м, вернувшись практически к уровням 2023 года. У Anthropic получилось набрать 31 очко из ста возможных, у OpenAI - 30, а у Google и вовсе 24 балла.

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

Когда модель не «глупеет», а перестраховывается

Некоторые жалобы на ухудшение качества AI вовсе не связаны с ухудшением когнитивных возможностей моделей. Бывает, что обновление механизмов защиты приводит к тому, что система чаще помечает обычные запросы как потенциально опасные. В результате вместо решения задачи пользователи получают предупреждения, усечённые ответы или излишнюю перестраховку.

Это и есть тот самый safety drift. Amazon Science в материале про FalseReject описывает его системно: механизмы безопасности нередко становятся слишком осторожными и начинают отказывать даже на безопасных запросах.

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

Четыре слоя, которые уже есть на рынке

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

1. Контроль версий на стороне провайдера

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

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

2. Собственные проверки и регрессионное тестирование

Важнейший практический элемент борьбы с ухудшением качества решений. Не полагаться слепо на заявления поставщиков, а иметь свой набор задач, регулярно проверяя: не стало ли хуже там, где это действительно критично.

Минимальный набор выглядит примерно так:

Базовые эталонные тесты, выполняемые регулярно и служащие ориентиром качества.
Canary-тесты, выявляющие первые признаки проблем с качеством.
Сложные стресс-тесты, проверяющие граничные возможности модели.
Безопасные контрольные сценарии, демонстрирующие надежность системы даже при незначительных изменениях.

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

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

3. Платформы мониторинга и оценки качества LLM

На рынке уже оформился отдельный класс решений для этой задачи. Gartner выделяет его как самостоятельную категорию - AI Evaluation and Observability Platforms. Важно сразу оговориться: ни одна из этих платформ не даёт защиту от деградации «из коробки» - это инфраструктура для обнаружения, а не готовый щит. Но без такой инфраструктуры обнаружение часто остаётся более ручным, более фрагментарным и хуже масштабируется.

Внутри категории важно различать две дисциплины: наблюдаемость (observability) и оценка качества (evaluation).

Наблюдаемость отвечает на вопрос «что происходит»: трассировка вызовов, задержки, стоимость, ошибки, расход токенов. Это приборная панель LLM-приложения. Она покажет, что модель стала отвечать медленнее или что выросло количество ошибок, но сама по себе не покажет, что качество рассуждений упало.

Оценка качества отвечает на вопрос «хорошо ли модель справляется с задачей»: эталонные наборы данных, автоматические оценщики, ручная разметка, A/B-эксперименты, регрессионное тестирование. Именно эта составляющая обнаруживает reasoning regression.

Среди заметных платформ я бы выделил скорее три характерных типа:

Arize / Phoenix - пример связки, где хорошо покрыты трассировка, эксперименты и оценка качества.
LangSmith - удобный пример платформы для команд, которым важны трассировка агентных сценариев, evals и ручная разметка.
Braintrust - пример подхода, где оценка качества ставится в центр и может прямо влиять на выпуск изменений через CI/CD.

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

Все эти платформы требуют от команды одного и того же: создать эталонные наборы данных для своих задач, настроить оценщики и определить пороги качества. Можно прекрасно видеть трассировку каждого запроса и всё равно не иметь чёткого правила «это хорошо / это плохо».

4. Аудит и взаимодействие с поставщиком услуг

Этот уровень связан больше с вопросами доверия, соответствия стандартам и договорными обязательствами. Здесь речь идёт не столько о повседневной работе, сколько о долгосрочном взаимодействии, включая возможность аудита, чёткое обоснование выбора поставщика и механизм подачи претензий. Хотя такая защита не гарантирует выявления каждой отдельной ошибки, она даёт правовую базу и формальные основания для претензий.

Выводы

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

Если смотреть на это с позиции корпоративного пользователя, вывод для меня такой: заметная часть защиты сегодня строится не у провайдера, а на стороне самой команды.

Внутри этой более широкой проблемы reasoning drift для меня остаётся особенно важным случаем. Именно он бьёт по сложным, длинным и дорогим задачам, где внешне всё ещё может казаться, что «всё почти нормально», а полезность ответа уже заметно просела.

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

Но самое полезное, что вынес из этого разбора: для критичных задач проблема начинается не тогда, когда «AI в целом стал хуже», а тогда, когда без собственных eval-процедур команда уже плохо видит скрытую регрессию качества. Как только формулируешь это точно, reasoning drift перестаёт быть предметом споров в соцсетях и становится инженерной задачей.

Reasoning drift у AI: почему коммерческая модель может молча стать хуже, и что с этим делать