Реализация Chain-of-Thought (CoT) промптинга для LLM

Chain-of-Thought промптинг: почему ответы нестабильны

На многошаговых задачах — разбор договора по пунктам, расчёт по зависимым условиям, диагностика по логам — модель выдаёт связный результат, который противоречит части исходных данных. Правка формулировки помогает на один-два прогона, дальше поведение снова расходится: Chain-of-Thought промптинг без управления цепочкой рассуждений стабильности не даёт.

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

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

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

Что даёт управляемое рассуждение: измеримые эффекты

Управляемое рассуждение — это не «более умная модель», а заранее описанный порядок шагов, который модель проходит до вывода. На многошаговых задачах это меняет точность ответов, их повторяемость и объём ручной проверки.

Доля верных ответов на многошаговых задачах

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

Повторяемость: одинаковый вход — предсказуемый выход

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

Сколько ручной проверки снимается

Ручная проверка обычно покрывает всю выдачу, потому что доверия к отдельным ответам нет. После настройки шаблонов и набора проверочных примеров оператор смотрит только ветки с низкой уверенностью и спорные случаи — объём вычитки падает, а вместе с ним уходит класс ошибок «уверенный ответ без опоры на данные», который раньше ловил только человек.

Режимы рассуждения: сравнение и ограничения

Режим рассуждения — это бюджет на промежуточные шаги, а не «уровень интеллекта» модели. Чем больше шагов между вопросом и ответом, тем меньше ошибок на многоусловных задачах — и выше задержка. Режим подбираем под задачу, а не «на максимум».

Ниже — четыре режима и их ограничения.

Когда прямого ответа достаточно

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

Когда нужна проверка вторым проходом

Второй проход нужен, когда ошибка дороже задержки: расчёты, выбор из вариантов, ответы с опорой на документ. Мы разносим рассуждение и самопроверку модели по разным вызовам: сначала вывод, затем сверка с исходными данными и правилами. Это ловит ошибку в середине цепочки и снижает долю неверных ответов, но заметно увеличивает расход.

Порядок работ: от разбора задач до передачи

Внедрение начинается не с выбора модели, а с разбора задач: где ответ должен сопровождаться пошаговым рассуждением, а где достаточно короткой формы и Chain-of-Thought промптинг только замедлит отклик. Этапы выстраиваем так, чтобы каждый следующий шаг опирался на проверяемый артефакт, а не на впечатление от показательного примера.

1. Разбор задач и сбор реальных запросов: выгружаем историю обращений, убираем дубли и группируем по типам — получаем набор, отражающий фактическое распределение задач, а не удобные для показа случаи.
2. Разметка эталонных рассуждений: для каждого типа задачи описываем цепочку шагов, которая приводит к верному ответу.
3. Сборка черновых наборов подсказок: формулируем несколько вариантов под каждый тип задачи и сравниваем их между собой на одних и тех же примерах.
4. Настройка правил проверки: фиксируем, что считаем корректным ответом и как отлавливаем рассуждение, которое приводит к неверному выводу.
5. Прогон на отложенной выборке: только примеры, не участвовавшие в настройке, показывают реальную устойчивость решения.
6. Передача решения и обучение команды: документация, разбор типовых ошибок и регламент обновления наборов подсказок.

Разметка эталонных рассуждений

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

Проверка на отложенной выборке

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

Что остаётся у вас: библиотека подсказок и регламенты

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

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

Как хранятся и обновляются наборы подсказок

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

Кейс: как выросла точность ответов на разборе заявок

Что было до

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

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

Что стало после

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

• доля верных выводов — 94% против 68% до переработки;
• ручная правка — одно обращение из пятнадцати вместо каждого третьего;
• время разбора сократилось с 12 до 4 минут на обращение;
• эскалации старшему специалисту — втрое реже.

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

Чем отличается пошаговое рассуждение от самопроверки?

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

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

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

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

Частые технические сомнения и ограничения

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

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

Обязательны ли примеры рассуждений в подсказке?

Нет, рассуждение по шагам работает и без размеченных примеров. Примеры ускоряют выход на нужное качество и стабилизируют формат, но удлиняют подсказку и увеличивают объём вывода в 2-4 раза. Поэтому итог мы отдаём в заданном формате, а ход рассуждения оставляем внутренним — пользователь не видит лишнего текста.

Как измерить эффект, а не поверить на слово?

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

Можно ли перенести подсказки в другой сценарий?

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

Обсудим задачу: что уточнить перед стартом

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

• Примеры запросов — 30-50 реальных формулировок, включая короткие, с опечатками и смешанными языками.
• Эталонные ответы — по 20-30 примерам зафиксированный желаемый результат и то, что считается недопустимым.
• Типовые сбои — где текущая логика ошибается: пропущенный шаг рассуждения, подмена факта, обрыв на длинном запросе.
• Требования к проверке — какие проверки ответ проходит перед выдачей: сверка с источником, формат, обязательные поля.
• Ограничения по времени ответа — сколько секунд ждёт пользователь и что важнее: скорость или глубина рассуждения.
• Ограничения по данным — что нельзя передавать во внешние сервисы, нужна ли изоляция контура.
• Точки интеграции — откуда приходит запрос, куда уходит ответ, кто правит шаблон после запуска.
• Целевые метрики — доля верных ответов на проверочном наборе, доля отказов «не знаю», разброс между запусками.

С этого набора начинается обсуждение задачи: проводим созвон по проекту с инженером, разбираем спорные примеры, фиксируем, что считаем эталоном, и снимаем противоречия в требованиях. По итогам присылаем план работ — порядок этапов, состав проверок, документацию и оценку сроков.