Что именно происходит: описание сбоя в Qwen Flash Next
Прямой ответ на главный вопрос: сбой воспроизводится не в одной сборке, а минимум в двух, поэтому объяснить его ошибкой конкретного кванта не получится. Пользователь описал проблему в сообществе r/LocalLLaMA: аномальные блоки размышлений появляются и на квантованных версиях от Unsloth, и на квантах AtomicChat. Harness минимальный - pi с конфигурацией по умолчанию. Автор предполагает связь с самой моделью или с форматом взаимодействия, а не с паблишером весов.
Симптом выглядит так. После вызова инструмента модель выдаёт reasoning-блок, в котором рассуждает, будто пользователь ещё ничего не спросил. В тексте фигурируют только системная настройка и блок системных инструкций, а реальной задачи в сообщении как будто нет. Дальше модель заключает, что её ответ был лишь подтверждением инструкций и что содержательного предыдущего рассуждения, которое стоило бы воспроизвести, не было.
Работа после этого не останавливается. Модель переходит к следующему tool call или отвечает нормально, как если бы ничего не произошло. Сбой возникает и в первых сообщениях, и глубоко в переписке, разницы автор не видит. История в messages есть, но модель словно теряет к ней доступ.
Как выглядит аномальный блок размышлений
Формулировка меняется от случая к случаю, смысл остаётся прежним. Пример из сообщения:
«Пользователь ещё ничего не спросил: это просто системная настройка плюс блок системных инструкций, сообщающий, что я эксперт-программист, помогающий пользователю решать проблемы. В сообщении нет реальной задачи. Мой ответ был лишь подтверждением инструкций. Не было содержательного предшествующего рассуждения, которое можно было бы воспроизвести».
Сравнить со своим логом просто. Если reasoning после tool call начинается с системного префикса, не содержит отсылки к исходному запросу и звучит как первичное знакомство с инструкциями, это тот же паттерн. Роли модель не путает: она не отвечает от лица пользователя, она теряет саму задачу. То, что аномалия затрагивает именно reasoning-слой, роднит её с другими странностями в цепочках рассуждений Qwen, которые разбирались на примере фразы «in this timeline», хотя природа явлений может быть разной.
Условия воспроизведения: кванты, harness, конфигурация
| Параметр | Что зафиксировано |
|---|---|
| Квантованные сборки | Unsloth и AtomicChat, сбой на обеих |
| Harness | минимальный pi, конфигурация по умолчанию |
| Позиция в диалоге | первые сообщения и глубокая история, без разницы |
| Поведение после сбоя | модель продолжает работу штатно |
| Причина | не установлена, автор только спрашивает о ней |
Отделим подтверждённое от предположений. Подтверждено: аномальный reasoning после tool call воспроизводится на двух независимых наборах квантов при минимальном harness pi с настройками по умолчанию, и он не привязан к позиции в диалоге. Не подтверждено: распространённость и причина. Пока это одно сообщение, называть поведение багом модели или дефектом формата одинаково преждевременно.
Почему это важно: риски для агентных сценариев
Reasoning-блок в агентном пайплайне часто служит планом следующего шага: модель решает, какой инструмент вызвать, с какими аргументами и что делать с результатом. Если после tool call рассуждение перезапускается от системных инструкций, план строится из общего описания роли, а не из цели пользователя. На практике это даёт лишние вызовы инструментов, аргументы не по делу и в редких случаях зацикливание на одном шаге.
Масштаб проблемы в описанном кейсе ограничен: модель восстанавливается и продолжает работу. Речь о деградации качества отдельного шага, а не об отказе. Для чат-сценариев это почти незаметно, для автономных агентов уже повод для внешнего контроля.
Рабочая рамка простая. Там, где цена ошибки низкая (черновики, поиск, разбор логов), достаточно смотреть на итоговый результат. Там, где агент что-то меняет во внешних системах, нужен детерминированный слой проверки аргументов и лимит шагов. Как это выглядит на практике, разбиралось в материале про агента с правами read-only, который всё равно менял записи в CRM: модель может быть уверена в своём плане, а исправлять приходится на границе исполнения. Та же логика работает и здесь: сначала фиксируем, где рассыпается цепочка, потом решаем, что чинить.
Отдельный риск - тихая деградация. Аномальный reasoning не роняет процесс и не всегда меняет видимый ответ, поэтому без логирования такие эпизоды не попадают в статистику.
Возможные причины: от training-данных до квантования
Четыре гипотезы чаще всего называют для такого поведения. Ни одна не подтверждена источником: автор лишь спрашивает, чем может быть вызван сбой. Факт остаётся один: сбой есть на квантах Unsloth и AtomicChat, значит, один паблишер весов его не объясняет. Остальное - версии про обучение, формат tool-call, сборку контекста и квантование.
Training-данные для reasoning: почему модель «теряет» задачу
Reasoning-модели учатся на длинных цепочках рассуждений, и зачины там встречаются самые разные. Если в обучающих примерах попадаются последовательности, где после tool call reasoning начинается заново с разбора системных инструкций, модель может воспроизводить этот шаблон как нормальный ход мысли. Тогда аномалия не сбой вычислений, а выученный паттерн, который включается, когда контекст после tool call выглядит неоднозначно.
Проверить гипотезу можно косвенно. Меняйте формулировку системной инструкции и следите, меняется ли частота аномалий. Если сбой привязан к конкретной структуре системного блока (например, к явному «ты эксперт-программист»), это довод в пользу версии об обучении. Прямых доказательств тут нет и из одного сообщения их не получить.
Формат tool-call: как разметка вызова влияет на контекст
После вызова инструмента модель получает результат отдельным сообщением. Если формат этого сообщения не сохраняет явную связь с исходной задачей, следующий reasoning-блок может строиться только из того, что осталось в поле зрения: системный промпт и результат инструмента. Отсюда и фраза про отсутствие реальной задачи.
Проверка техническая: залогируйте полный payload, который уходит в модель после каждого tool call, и посмотрите, есть ли там исходный запрос пользователя и системные инструкции в ожидаемом порядке. Ошибки в шаблоне вызова, лишние служебные строки или потерянный блок с задачей видны именно на этом уровне.
Обработка истории сообщений: где теряется контекст
Автор прямо пишет: история в messages есть, но модель путается. Вопрос не в том, хранится ли история, а в том, как harness и chat template собирают её в финальный prompt. Роли, разделители, порядок блоков и способ упаковки tool-результатов влияют на то, увидит ли модель задачу рядом с вызовом инструмента.
Практический шаг: выведите итоговый prompt в том виде, в котором он реально уходит в модель, и сравните с ожидаемым шаблоном Qwen. Смотрите на роли сообщений (system, user, assistant, tool) и на то, не слипаются ли служебные блоки с текстом задачи. Ошибка уровня шаблона даёт ровно такой симптом: формально модель видит всё, но не связывает части в одну задачу.
Квантованные веса: усиливают ли они аномалии
Сбой на двух наборах квантов говорит о том, что винить один паблишер нельзя. Это не снимает вопрос, снижает ли квантование устойчивость reasoning в целом. Потеря точности весов чаще проявляется на длинных цепочках и редких паттернах, а не на коротких ответах, и аномальный блок как раз относится к редкому случаю.
Что можно проверить: сравнить поведение на разных уровнях квантования (агрессивном и консервативном) при одном промпте и одинаковой истории. Если частота аномалий заметно падает на более точных весах, версия получает аргумент. Если нет, причина выше уровня квантизации. Тест на нерезаной модели дал бы более чистый ответ, но для него нужно соответствующее железо.
Как диагностировать сбой: пошаговый план
Без логов причина останется догадкой. Порядок действий такой:
- Включите полное логирование запросов и ответов, включая reasoning-блоки целиком. Сохраняйте и то, что уходит в модель, и то, что она возвращает.
- Соберите минимальный воспроизводимый кейс: один tool call, короткая история, один и тот же промпт. Harness pi с конфигурацией по умолчанию подходит как чистая стартовая точка.
- Проверьте зависимость от позиции: воспроизводится ли сбой в первых сообщениях и в длинной истории. В источнике разницы не нашли, но в вашем окружении она может проявиться.
- Прогоните разные шаблоны чата и форматы tool-call. Меняйте по одному элементу, иначе результат не интерпретировать.
- Сравните несколько уровней квантования при прочих равных. Это отделит вклад весов от вклада сборки контекста.
- Зафиксируйте частоту: сколько tool call из сотни дают аномальный reasoning. Без числа спорить не о чем.
Дальше сузьте область. Если аномалия исчезает при смене шаблона, проблема на стороне сборки контекста. Если остаётся на всех форматах и квантах, версия про модель или обучение становится основной. Логика та же, что при разборе сбоев агента на отметке выполненных пунктов to-do: сначала исключаем обвязку, потом смотрим на модель.
Обходные пути и временные решения
Причину это не убирает, но снижает риск. Что можно попробовать уже сейчас:
- Дублируйте задачу. Короткое напоминание о цели в сообщении с результатом инструмента даёт модели зацепку, если она потеряла исходный запрос.
- Ограничивайте длину reasoning. Ранний переход к следующему шагу снижает шанс, что блок уйдёт в разбор системных инструкций.
- Проверяйте следующий шаг извне. Схема аргументов, белый список инструментов и лимит шагов ловят ошибку до того, как она уйдёт во внешнюю систему.
- Держите fallback. Для критичных вызовов вторая модель или более консервативный режим генерации уменьшат цену единичного сбоя.
Ни один пункт не гарантирует результата: это гипотезы для проверки на вашем наборе промптов. Часть из них может не дать эффекта, если дело в весах.
Что делать, если проблема не воспроизводится
Сбой может зависеть от конкретных промптов, длины контекста и версии harness. Если у вас всё работает, это не значит, что паттерна нет: он проявляется редко и тихо. Разумный минимум - мониторинг reasoning-блоков в агентных сценариях: складывайте аномалии в отдельный лог и считайте их долю от общего числа шагов.
Если кейс удалось поймать, оформите его как минимальный воспроизводимый пример: версия модели и кванта, harness и его версия, полный prompt, ответ с аномальным reasoning, поведение после сбоя. С таким набором можно писать мейнтейнерам модели или harness. Массовость проблемы не подтверждена: в обсуждении есть только одно сообщение, других отчётов в нём не приводится.
Итог: что мы знаем и чего не знаем
Знаем: после tool call в Qwen Flash Next иногда появляется reasoning-блок, где модель рассуждает так, будто задачи не было, и упоминает только системную настройку и системные инструкции. Паттерн зафиксирован на квантах Unsloth и AtomicChat при минимальном harness pi с настройками по умолчанию, встречается и в начале диалога, и в глубокой истории. После аномалии модель обычно продолжает работу штатно.
Не знаем: причину и распространённость. Гипотезы - training-данные для reasoning, формат tool-call, сборка истории сообщений, квантование. Ближе всего к ответу подводит логирование полного payload и сравнение поведения на разных шаблонах и квантах.
Практический вывод: в чатах можно жить с этим как с редкой странностью, в агентных пайплайнах стоит добавить внешний контроль за следующим шагом. Если вы сталкивались с похожим поведением, полезны логи: они переводят разговор из плоскости «у меня тоже так бывает» в проверяемые данные. За обновлениями самой модели удобно следить по дайджестам, например в разборе главных событий недели в AI, где подтверждённые релизы и технические детали отделяют от слухов.