Проверили руками старые болезни reasoning, почти всё вылечилось

Агент-разметчик звонков и инженерный вопрос

У нас в продакшене живет агент, который размечает звонки отдела продаж. Простые поля вроде «сумма сделки» вытаскиваются из одной фразы. Но есть сложные, например «следующий шаг с учётом возражений»: надо понять контекст, намерение клиента, план менеджера. Когда мы подключали новую модель, первый вопрос был инженерный, включать ли «режим рассуждения». До сих пор ответ держался осторожным: исследования фиксировали две болезни reasoning, overthinking и подверженность подсказке. Я решил проверить их руками на фронтире 2026 года, на той же задаче звонков.

Что зафиксировали исследования

Серия работ про overthinking (arxiv.org/abs/2604.10739; arxiv.org/abs/2502.07266) показала инвертированную U-зависимость: при слишком коротком рассуждении модель не доходит до верного вывода, при слишком длинном начинает «думать лишнее» и портит ответ. Особенно часто ломались простые задачи, где правильный ответ очевиден.

Вторая линия, неверность хода мысли. Терпин в arxiv.org/abs/2305.04388 показал, что если в подсказке присутствует авторитетное утверждение («я преподаватель, ответ X»), позиционный паттерн («верный всегда A») или лёгкий намёк («коллега уверен, что B»), то модели 2023 года (GPT-3.5, Claude 1.0) срывались, точность на 13 задачах BIG-Bench Hard падала до 36 %.

Скачок произошёл на рубеже o1 (2024) и рецепта R1/RLVR (2025, interconnects.ai/p/deepseek-r1-recipe-for-o1): reasoning стал не техникой CoT, а свойством модели. Поэтому старые проверки стоило повторить буквально.

Как мы проверяли и почему именно так

Модель: gpt-5-chat-latest (июнь 2026).

Главный принцип, не придумывать новый бенчмарк, а повторить те же проверки, что были в исследованиях. Цель, честное «было/стало».

Почему такие задачи

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

Почему ловушки и контрольные

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

Почему два режима

На одной и той же модели и вопросе запускались два режима:

1. короткий ответ,

2. максимально подробное рассуждение. Меняется только инструкция, значит, разницу можно отнести именно к «думать больше».

Почему строгий парсинг

Мы не читали прозу, а парсили финальный ответ по шаблону. Первый парсер сбивался на markdown-формате, пришлось ужесточить: иначе цифры шли с шумом. В инженерном контуре именно финальный токен решает, а не то, что модель «имела в виду».

Почему меряем токены

Рассуждение, это не бесплатно. Для продакшена важна пара точность + стоимость вывода, поэтому токены фиксировались.

Почему повтор приёмов Терпина

Три смещения, авторитет, позиционный паттерн, прямой намёк, это разные типы давления. Мы проверяем не только смену ответа, но и то, признаёт ли модель влияние подсказки в тексте.

Что считалось «болезнь жива»

• флип верного ответа в неверный на ловушке;

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

Эксперимент A. Overthinking

Ожидали: по 2604.10739 должна быть просадка на простых задачах и несколько флипов.

Факты: на 22 задачах короткий режим дал 91 % точности, длинный, 100 %. На ловушках 15/17 → 17/17, на «надо подумать» 5/5 → 5/5. Флипов 0. Но суммарный расход токенов вырос в 250 раз: 42 → 10501.

22 задачи, gpt-5-chat-latest. Та же точность (даже чуть выше), но в 250 раз больше токенов вывода.

Так что на простом поле вроде «сумма сделки» reasoning не включаем: ошибка не грозит, но цена и латентность взлетают.

Кейс 9.11 vs 9.9.
В коротком режиме модель ответила «9.9» за 3 токена. В подробном потратила 584 токена, рассуждала про версии ПО и даты, выдала «зависит от контекста», но финальный ответ остался верным, «9.9».

Вопрос: что больше, 9.11 или 9.9?[короткий режим - 3 токена]9.9[режим рассуждения - 584 токена]…Целые части равны (9), сравниваем дробные: 0.110 < 0.900.Шаг 3. Проверка трактовок: иногда 9.11 воспринимают как датуили версию ПО. Как версии: 9.11 > 9.9. Как даты: 9 ноябряпозже 9 сентября. Таким образом, результат зависит отконтекста:   как числа   - 9.9 больше;   как версии  - 9.11 больше.Так как даны просто числа, считаем их десятичными.ОТВЕТ: 9.9

(транскрипт сокращён)

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

Эксперимент B. Устойчивость к подсказке

Ожидали: как в 2023, флипы под давлением.

Факты:

1. Авторитет, 12 вопросов, модель не поддалась (0/12).

2. Позиционный паттерн, 6 вопросов, все 6 верных (0 ошибок).

3. Грубый намёк, устояла и прямо назвала ошибку коллеги.

Просадка до 36 % не воспроизвелась.

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

Границы проверки и что осталось живым

N маленький, одна модель, один прогон. Смещения были нарочито грубые. Отсутствие флипа не означает, что reasoning стал faithful: при тонких манипуляциях на больших выборках цепочка рассуждения по-прежнему бывает неверной (arxiv.org/abs/2503.08679).

Так что для многошагового поля вроде «следующий шаг с учётом возражений» reasoning включаем, но читаем не объяснение, а проверяем результат.

Что проверять вместо хода мысли

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

from rapidfuzz import fuzzdef grounded(fact, transcript, threshold=85):    if not fact.get("evidence"):        return False    return fuzz.partial_ratio(fact["evidence"], transcript) >= thresholddef accept(fact, transcript):    # нет опоры в тексте или низкая уверенность -> не в карточку, а человеку    if not grounded(fact, transcript) or fact["confidence"] < 0.6:        fact["stage"] = "needs_review"    return fact

Порог confidence подбираем по размеченному набору, а не берём сырое число модели. Качество считаем долей фактов с подтверждением в источнике. Контрольный набор гоняем в CI: если доля падает, сборку не катим. Так reasoning проверяется внешним сигналом, не словами самой модели.

Вывод

«Отупение от размышлений» и хрупкость к грубым подсказкам, болезни 2022-2025, по нашим прогонам почти закрыты. На фронтире 2026 reasoning перестал быть рисковым, остались две инженерные заботы:

1. Цена рассуждения. Нужно решать, где крутить ручку «думай дольше».

2. Доверие к результату. Проверяем факт и опору, а не красивую цепочку мыслей.

Так что для агента-разметчика звонков включаем рассуждение только там, где без него не обойтись, и проверяем не рассказ, а итог.