Chain of Draft (CoD)

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

CoD = reasoning trace, но в сильно сжатом виде.

Подходит, когда:

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

Реши задачу. Сначала сделай very short draft steps: максимум 5 слов на шаг. Потом дай итоговый ответ.

В компании 120 клиентов, churn 5% в месяц. Сколько клиентов останется примерно через 3 месяца, если не будет новых?

Зачем нужен CoD, если уже есть CoT

Обычный Chain-of-Thought полезен, но дорог:

• длиннее по токенам;
• медленнее;
• иногда переобъясняет очевидное;
• не всегда нужен downstream.

CoD предлагает компромисс:

• оставить краткий reasoning trace;
• но сделать его телеграфным и функциональным.

То есть это budget reasoning mode, а не новая универсальная замена CoT.

Когда техника особенно полезна

Хорошие кейсы:

• internal reasoning helpers;
• classification with short rationale;
• concise planning;
• cost-sensitive support copilots;
• light analytical prompts;
• workflows, где reasoning trace нужен машине, а не человеку.

Почему CoD особенно полезен как cost/latency compromise

На практике часто есть неудобный выбор:

• либо direct answer слишком хрупок;
• либо полный CoT слишком дорог и многословен.

Chain of Draft закрывает именно этот промежуток. Он полезен как компромиссный режим, когда reasoning trace ещё нужен, но уже не хочется платить за длинное объяснение каждого шага.

Менее полезен CoD:

• для educational explanations;
• для аудита reasoning человеком;
• для high-stakes legal/medical explanation;
• когда hidden reasoning provider-side already good enough.

Если downstream-пользователю нужно не просто решение, а понятная аргументация, draft-mode почти всегда слишком сжат. Это хороший internal trace, но плохой explanatory artifact.

Практическое правило 2026

Сегодня CoD стоит воспринимать не как замену всем reasoning-техникам, а как budget mode:

• full explanation, если её будет читать человек;
• short draft, если важны скорость и стоимость;
• hidden reasoning, если модель уже умеет думать без внешнего trace.

Хороший prompt pattern

Полезно ограничивать:

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

Без этих ограничений draft быстро превращается обратно в длинный CoT и теряет смысл.

Что делает draft рабочим

Полезный draft:

• достаточно короткий;
• сохраняет порядок reasoning;
• помогает понять, откуда взялся final answer;
• не пытается быть мини-эссе.

Плохой draft:

• уже не читается как reasoning path;
• дублирует final answer;
• слишком обрывочен, чтобы быть полезным;
• или наоборот снова становится обычным CoT.

Сравнение с соседними техниками

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

Ещё типичные проблемы:

• draft смешивается с final answer;
• число шагов не ограничено;
• техника используется там, где нужен полноценный explanation;
• никто не меряет, даёт ли CoD выигрыш относительно normal CoT.

Когда лучше выбрать другую технику

Если проблема не в длине CoT, а в его надёжности, лучше идти не в CoD, а в:

• Self-Consistency;
• Plan-and-Solve;
• tool use;
• verification.

CoD оптимизирует budget, но не решает системно проблему плохого reasoning quality.

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

prompt = """
Реши задачу.
Сначала выведи черновик рассуждения:
- не более 5 слов на шаг
- не более 6 шагов
Потом выведи финальный answer отдельно.
"""

Practical guardrails

• ограничивайте длину draft;
• отделяйте draft от final answer;
• не просите CoD там, где downstream ждёт строгий JSON без лишнего текста;
• проверяйте, улучшает ли draft accuracy при acceptable token budget.

Что стоит измерять

• token savings vs CoT;
• latency delta;
• answer quality delta;
• user comprehension, если draft виден наружу.

Так вы поймёте, где CoD действительно полезен, а где он просто модная, но бесполезная микрооптимизация.

Production use

В production CoD особенно уместен как:

• optional low-cost route;
• internal rationale layer;
• concise plan format before execution;
• fallback между direct answer и full CoT.