Cumulative Reasoning: как проверять шаги решения — это порядок, при котором каждый промежуточный вывод сначала предлагается, затем проверяется на следование из посылок и только после этого попадает в накопленный реестр. Работа идёт тремя ролями: Proposer предлагает шаг, Verifier оценивает его связь с данными, Reporter решает, когда оснований достаточно для ответа. Ниже — полный разбор на учебном примере с заявкой Лира, включая отклонённый шаг и ответ Unknown.
Роли Proposer, Verifier и Reporter
Cumulative Reasoning (CR) — структурированный метод, который повышает качество решения задач языковой моделью за счёт итеративного и накопительного процесса рассуждения. В авторском описании метода, опубликованном в репозитории проекта на GitHub, CR распределяет модель по трём ролям: Proposer, Verifier и Reporter. Эти роли разбирают задачу на части, проверяют промежуточные шаги и собирают их в итоговое решение.
Proposer формирует кандидаты. Он смотрит на текущий контекст — исходные посылки и уже принятые утверждения — и предлагает следующий шаг. В документации проекта Instructor этот этап назван Propose: модель предлагает потенциальные шаги на основе текущего контекста, запуская цикл рассуждения. Кандидат приходит вместе с указанием, из каких посылок он выведен.
Verifier проверяет предложенное. Его задача — оценить, действительно ли шаг следует из тех посылок, на которые ссылается Proposer. В документации Instructor этот этап назван Verify: предложения Proposer оцениваются на точность, а корректные шаги включаются в текущий контекст. Проверка идёт по правилам логики вывода: Verifier отвечает, является ли переход от посылок к утверждению правильным.
Reporter решает, когда заканчивать. Он смотрит на накопленные проверенные утверждения и определяет, достаточно ли их для ответа на исходный вопрос. В документации Instructor этот этап назван Report: определяется подходящий момент для завершения процесса рассуждения. Reporter также выносит итоговую оценку гипотезы.
Роли можно исполнять вручную или программно. В авторском репозитории есть реализация CR Agent, которая решает задачи с подключением кодового окружения, и упрощённая версия на OpenAI Assistants API, построенная на принципах Meta Prompting. Для учебного разбора достаточно вести три роли последовательно: предложить шаг, проверить его, решить о завершении.
Разделение важно потому, что одна и та же модель в одной роли склонна защищать собственное предложение. Когда проверку ведёт отдельный проход с явным вопросом «следует ли это из данных посылок», у необоснованного шага больше шансов быть отклонённым до того, как он попадёт в цепочку. При этом проверка той же моделью не превращает утверждение в доказанный факт о внешнем мире: она подтверждает только связь с заданными посылками.
Что попадает в накопленный реестр и граф зависимостей
Реестр — это рабочая память процесса. В него попадают только проверенные утверждения. Каждая запись в реестре содержит несколько полей, и именно они делают цепочку воспроизводимой.
| Поле записи | Что содержит | Зачем нужно |
|---|---|---|
| ID утверждения | Короткий идентификатор шага | Ссылаться на шаг из следующих записей |
| Текст утверждения | Формулировка вывода | Видеть, что именно принято |
| Родительские ID | Посылки или шаги-основания | Восстановить, откуда вывод следует |
| Основание | Короткое объяснение связи | Проверить вывод повторно |
| Статус | Принято или отклонено | Не использовать отклонённое дальше |
Граф зависимостей строится из поля родительских ID. Каждое принятое утверждение указывает, из чего оно выведено: из исходных посылок или из ранее принятых шагов. Если нарисовать эти связи, получится направленный граф, где исходные посылки стоят в основании, а итоговый ответ — на вершине. Такой граф показывает путь от данных к выводу и позволяет проверить любой шаг, не перечитывая всё рассуждение.
Отклонённые шаги тоже полезно хранить, но с явным статусом. Они остаются в журнале как история попыток, однако в граф зависимостей не входят: ни один следующий шаг не может ссылаться на отклонённое утверждение как на основание. Это ключевое правило. Если отклонённый шаг просочится в родительские ID следующего вывода, вся ветка потеряет опору.
Реестр удобно вести таблицей. В учебном примере ниже он заполняется по шагам: сначала принимается S-a, затем отклоняется S-b, затем принимается S-c. Каждая строка ссылается только на то, что уже имеет статус «принято». Такой порядок гарантирует, что в момент вывода основание уже проверено.
Накопление отличает CR от однопроходного рассуждения. Модель не обязана выдать всю цепочку сразу: она добавляет по одному проверенному звену, и каждое следующее предложение опирается на уже принятый запас. Чем больше проверенных утверждений накоплено, тем шире набор оснований для следующих шагов. При этом запас растёт только за счёт проверенного: отклонённое в него не добавляется.
Полный пример Лиры с посылками и принятыми шагами
Разберём учебный пример. Он условный и служит для отработки порядка действий. Даны три посылки:
- P-a: «Все заявки с пометкой Архив передают хранителю».
- P-b: «Заявка Лира имеет пометку Архив».
- P-c: «Заявки, переданные хранителю, не поступают в обычную очередь».
Проверяемая гипотеза: «Лира не поступает в обычную очередь».
Шаг первый. Proposer предлагает S-a: «Лиру передают хранителю», указывая основания P-a и P-b. Verifier проверяет связь: из P-a и P-b вывод следует, потому что Лира подходит под условие пометки Архив, а все такие заявки передают хранителю. S-a принимается и попадает в реестр.
Шаг второй. Proposer предлагает S-b: «Все заявки Лира срочные». Verifier проверяет основания и не находит ни одной посылки о срочности. Связь не подтверждается, S-b отклоняется. В граф зависимостей он не входит.
Шаг третий. Proposer предлагает S-c: «Лира не поступает в обычную очередь», указывая основания S-a и P-c. Verifier проверяет: S-a уже принят и говорит, что Лиру передают хранителю, а P-c говорит, что переданные хранителю в обычную очередь не поступают. Связь следует, S-c принимается.
Reporter завершает работу, потому что проверенная S-c отвечает гипотезе. Реестр по итогам выглядит так:
| ID | Текст утверждения | Родители | Основание | Статус |
|---|---|---|---|---|
| S-a | Лиру передают хранителю | P-a, P-b | Пометка Архив подпадает под правило P-a | Принято |
| S-b | Все заявки Лира срочные | — | Посылки о срочности отсутствуют | Отклонено |
| S-c | Лира не поступает в обычную очередь | S-a, P-c | Переданные хранителю вне обычной очереди | Принято |
Обратите внимание на порядок: S-c опирается на S-a, который к этому моменту уже принят. Если бы S-a был отклонён, шаг S-c не имел бы основания и тоже не прошёл бы проверку. Цепочка зависит от статусов её оснований.
Отдельный вопрос «Когда Лира попадёт к хранителю?» получает ответ Unknown: сроков в посылках нет. Это корректное обозначение границы вывода. Метод отвечает на то, что подтверждается данными, и обозначает предел там, где данных не хватает. Предел одного повторного предложения задаётся упражнением и не является ограничением исходного метода.
Как отклонить необоснованный шаг без использования его дальше
Отклонение — предусмотренное рабочее действие. Порядок такой: Verifier получает кандидата вместе с родительскими ID, проверяет связь «посылки → утверждение» и, если связь не подтверждается, ставит статус «отклонено». Кандидат остаётся в журнале, но выпадает из графа.
Главное правило после отклонения: ни один следующий шаг не ссылается на отклонённое утверждение. Если Proposer в новом предложении указывает отклонённый ID среди родителей, Verifier отклоняет и это предложение — основание недостоверно. Так отклонённый шаг не может стать скрытой опорой для дальнейших выводов.
Проверим на примере. S-b отклонён. Если бы Proposer затем предложил шаг «Лира срочная и потому передаётся хранителю», ссылаясь на S-b, Verifier отклонил бы его: часть основания не принята. Цепочка не должна опираться на вычеркнутое звено.
Частая ошибка — оставить отклонённый шаг в контексте без пометки. Тогда следующее предложение может случайно на него сослаться, и в цепочке появится вывод из неподтверждённого утверждения. Пометка статуса и запрет на ссылку решают эту проблему.
Вторая ошибка — отклонять шаг без указания причины. Короткое основание отказа нужно, чтобы при повторной проверке было видно, чего не хватило: подходящей посылки, правильной формы вывода или ссылки на принятый шаг. В примере причина отказа S-b — отсутствие посылки о срочности.
Третья ошибка — принимать шаг, который лишь повторяет посылку. В документации проекта Instructor к предложениям предъявлено требование: каждое утверждение выводится не более чем из двух данных посылок и не дублирует те посылки, из которых выведено. Повтор посылки не добавляет нового знания и засоряет реестр.
Отклонение защищает итог. Чем строже проверка на входе, тем меньше неподтверждённых звеньев дойдёт до Reporter. При этом отклонение не означает, что утверждение ложно: оно означает, что связь с данными посылками не подтверждена. Ложность и невыводимость — разные вещи.
Как проверить достаточность ответа и закончить работу
Достаточность проверяет Reporter. Его вопрос: покрывают ли накопленные принятые утверждения исходную гипотезу. Если да, работа завершается; если нет, цикл продолжается новыми предложениями.
Порядок проверки достаточности:
- Сформулировать гипотезу в том же виде, в каком она была задана.
- Найти в реестре принятое утверждение, которое ей соответствует.
- Убедиться, что цепочка родителей этого утверждения доходит до исходных посылок без разрывов.
- Проверить, что в цепочке нет отклонённых шагов.
- Зафиксировать итог и остановить цикл.
В примере Лиры гипотеза «Лира не поступает в обычную очередь» совпадает с принятым S-c. Родители S-c — S-a и P-c, родители S-a — P-a и P-b. Цепочка доходит до посылок, отклонённых шагов в ней нет. Reporter завершает работу.
Если совпадения нет, Reporter не останавливает процесс. Тогда Proposer предлагает новые шаги, а Verifier их проверяет. Цикл идёт до момента, когда нужное утверждение принято либо когда становится ясно, что данных для него недостаточно.
Отдельный случай — гипотеза, для которой оснований не хватает. Тогда Reporter выносит Unknown. Это законный итог: он показывает, что вопрос выходит за пределы данных посылок. Завершение работы с Unknown отличается от незавершённого цикла тем, что Reporter явно зафиксировал границу.
В документации проекта Instructor итоговая оценка гипотезы описана как выбор между True, False и Unknown. В учебном примере мы используем собственный итог: Reporter завершает работу, потому что проверенная S-c отвечает гипотезе. Этот учебный итог не выдаётся за результат конкретной реализации.
Проверка достаточности опирается на сохранённый реестр. Поэтому важно, чтобы каждый принятый шаг был записан с родителями и основанием. Тогда Reporter может пройти цепочку заново и убедиться, что вывод держится.
Unknown при отсутствии нужной посылки
Unknown — это ответ, когда для гипотезы не хватает данных. Он не равен «ложно» и не равен «истинно». Он означает, что из заданных посылок нужный вывод не следует.
В примере Лиры вопрос «Когда Лира попадёт к хранителю?» получает Unknown. Посылки говорят, что Лиру передают хранителю, но не называют сроков. Ни одна посылка не содержит даты или момента передачи, поэтому вывести срок нельзя.
| Вопрос | Есть ли посылка | Итог |
|---|---|---|
| Лира не поступает в обычную очередь? | Да: P-a, P-b, P-c | Принято, S-c |
| Все заявки Лира срочные? | Нет | Отклонено, S-b |
| Когда Лира попадёт к хранителю? | Нет | Unknown |
Порядок работы с Unknown такой же, как с любым итогом. Reporter проверяет, есть ли в реестре принятое утверждение, отвечающее на вопрос. Если нет и новых посылок не появилось, выносится Unknown и цикл завершается.
Важно отличать Unknown от отклонённого шага. Отклонённый шаг — это кандидат, чья связь с посылками не подтвердилась. Unknown — это итоговая оценка вопроса, для которого оснований не нашлось. Первое относится к шагу, второе — к гипотезе.
Ещё одно различие: Unknown может смениться, если добавить посылку. Если бы в данных появилась посылка о сроке, вопрос о времени получил бы основание. Без неё Unknown остаётся честной границей метода.
Практический смысл Unknown в том, что он не даёт выдать догадку за вывод. Модель, склонная достраивать недостающее, здесь останавливается и обозначает предел. Это и есть проверяемость: читатель видит, что ответ опирается на данные, а где данных нет — там стоит Unknown.
Отличие проверки логического вывода от достоверности исходного факта
Verifier проверяет связь между посылками и утверждением. Он отвечает на вопрос: следует ли вывод из данных посылок по правилам логики. Это проверка логического вывода. Достоверность самих посылок проверяется отдельно.
Разница принципиальна. В примере Лиры Verifier подтвердил, что S-a следует из P-a и P-b. Это значит, что при истинных P-a и P-b утверждение S-a истинно. Но Verifier не проверял, действительно ли у заявки Лира есть пометка Архив и действительно ли все такие заявки передают хранителю. Эти посылки приняты как данные.
| Что проверяется | Вопрос | Кто отвечает |
|---|---|---|
| Логический вывод | Следует ли шаг из посылок | Verifier |
| Достоверность посылки | Верна ли сама посылка | Источник данных |
В документации проекта Instructor к предложениям предъявлено требование не вводить неопубликованное общее знание и сведения из здравого смысла. Это ограничивает вывод рамками заданных посылок. Проверка остаётся внутри данных.
Отсюда практическое следствие: корректная цепочка не гарантирует истинность итога о внешнем мире. Если посылка неверна, вывод из неё может быть логически правильным и при этом ложным по содержанию. Проверка той же моделью не превращает утверждение в доказанный факт о внешнем мире.
Поэтому в рабочем порядке полезно разделять два действия. Первое — проверить вывод: следует ли шаг из посылок. Второе — проверить источник: откуда взята посылка и насколько ей можно доверять. CR отвечает за первое; второе остаётся за тем, кто задаёт данные.
В примере Лиры обе стороны видны. Логика вывода S-c из S-a и P-c проверена. Достоверность самих P-a, P-b и P-c определяется источником, из которого они взяты. Метод не подменяет эту проверку.
Частые вопросы
Что такое Cumulative Reasoning простыми словами?
Это метод решения задач языковой моделью, при котором рассуждение идёт по шагам. Каждый шаг сначала предлагается, затем проверяется на следование из посылок и только после этого попадает в накопленный реестр. Работу ведут три роли: Proposer, Verifier и Reporter.
Чем Proposer отличается от Verifier?
Proposer формирует кандидатов на основе текущего контекста и указывает, из каких посылок выведен шаг. Verifier проверяет, действительно ли шаг следует из этих посылок. Одна роль предлагает, другая оценивает связь с данными.
Что делать, если шаг не обоснован?
Отклонить его и не использовать дальше. Отклонённый шаг остаётся в журнале со статусом, но в граф зависимостей не входит. Следующие предложения не должны ссылаться на него как на основание.
Когда метод отвечает Unknown?
Когда для гипотезы не хватает посылок. В примере Лиры вопрос о сроке передачи хранителю получает Unknown, потому что сроков в данных нет. Unknown показывает границу: из заданных посылок нужный вывод не следует.
Проверка вывода подтверждает истинность факта?
Нет. Verifier подтверждает, что шаг следует из посылок по правилам логики. Верность самих посылок определяется их источником. Корректная цепочка может опираться на неверную посылку и дать ложный итог о внешнем мире.