Chain of Thought (CoT)

Суть в двух словах

CoT особенно полезен, когда:

• задача многошаговая;
• answer выводится из нескольких промежуточных величин;
• важно увидеть, где именно модель ошиблась;
• downstream допускает чуть большую длину ответа ради надёжности.

Типичные кейсы:

• арифметика и логика;
• structured analysis;
• пошаговое сравнение вариантов;
• извлечение причинно-следственных цепочек;
• reasoning над таблицами, документами и бизнес-правилами.

Реши по шагам и затем дай финальный ответ отдельно.

В SaaS-компании 320 платящих клиентов. 25% на тарифе Pro по 8 000 ₽, остальные на тарифе Basic по 3 000 ₽. 6% клиентов не оплатили в этом месяце. Какова фактически признанная месячная выручка?

Что CoT реально улучшает

Обычный direct answer часто ломается в одном из трёх мест:

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

CoT снижает этот риск, потому что forcing function здесь не в "длине рассуждения", а в явной структуре вывода.

Что изменилось к 2026

Сегодня важно отличать два разных мира:

1. Классический prompt-level CoT
2. Provider-native reasoning models

Для reasoning-моделей вроде GPT-5.x reasoning lanes, Claude thinking или похожих managed режимов не всегда полезно требовать длинную явную цепочку мыслей. Часто лучше:

• сформулировать задачу ясно;
• указать критерий успеха;
• при необходимости попросить краткие промежуточные steps или structured reasoning output.

То есть CoT по-прежнему полезен, но "заставляй модель думать вслух максимально подробно" уже не универсальная best practice.

Когда CoT обычно стоит включать

Хорошие кандидаты:

• задачи со строгим финальным answer;
• аналitika, где важен обоснованный вывод;
• финансовые и операционные расчёты;
• policy application;
• problem solving, где надо показать reasoning trace.

Плохие кандидаты:

• краткие factual вопросы;
• чисто творческое письмо;
• простая классификация;
• задачи, где структурированный tool output надёжнее текста.

Почему CoT до сих пор остаётся базовой техникой

Даже после появления provider-native reasoning lanes CoT не исчезает по простой причине: это самый понятный способ проверить, выигрывает ли задача от явной промежуточной структуры.

Если direct answer даёт нестабильность, CoT остаётся первым диагностическим ходом:

• нужен ли вообще reasoning;
• где именно модель ошибается;
• помогает ли явное разбиение на шаги;
• стоит ли переходить к verification или decomposition patterns.

Современный практический паттерн

Вместо старого "think step by step" полезнее использовать более явные инструкции:

• разложи решение на шаги;
• показывай только существенные шаги;
• финальный answer вынеси отдельно;
• не делай лишних разветвлений;
• если не хватает данных, остановись и зафиксируй допущение.

Что делает CoT хорошим, а не просто длинным

Сильный CoT:

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

Слабый CoT:

• повторяет условие разными словами;
• добавляет нерелевантные микро-шаги;
• смешивает analysis и final answer;
• создаёт ощущение обоснованности без реальной проверки.

CoT и соседние техники

Частые ошибки

Ещё типичные промахи:

• слишком длинный reasoning без чёткой цели;
• отсутствие отдельного финального answer;
• конфликт между system-инструкцией и требованием "думай вслух";
• ожидание, что CoT автоматически делает модель factual.

Когда стоит эскалировать дальше

Если один CoT path недостаточно стабилен, следующий шаг обычно не "ещё длиннее CoT", а:

• Self-Consistency, если нужен voting over multiple paths;
• Chain-of-Verification, если надо проверять claims;
• Plan-and-Solve, если проблема в структуре execution;
• tool use, если ошибка упирается в вычисление, поиск или lookup.

Техническая реализация

Минимальный шаблон

def cot_prompt(task: str) -> str:
    return (
        "Реши задачу по шагам. "
        "Показывай только существенные промежуточные шаги. "
        "В конце выведи отдельную строку с финальным answer.\n\n"
        f"Задача: {task}"
    )

Когда лучше не хранить полный reasoning

Если задача пользовательская и high-volume, часто полезнее:

• логировать не весь длинный trace;
• а structured summary steps;
• плюс финальный answer;
• плюс confidence / disagreement / verification signals.

Хороший production routing

• direct answer для простых задач;
• CoT для умеренно сложных шаговых задач;
• Plan-and-Solve для procedural reasoning;
• Least-to-Most для зависимых промежуточных результатов;
• Self-Consistency или CoVe для verification.

Что измерять

Если CoT идёт в прод, полезно смотреть:

• uplift against direct answer;
• длину reasoning;
• rate of wrong final answers with plausible rationale;
• долю задач, где CoT ничего не улучшил.

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

Где нужен app-side parser

Если CoT идёт в workflow:

• отделяйте rationale от final answer;
• нормализуйте final answer отдельно;
• валидируйте числа, labels и decision fields кодом.

Иначе красивый reasoning может маскировать неверный итог.