Tree of Thoughts: осознанное решение задач с помощью поиска через LLM

Посвятив две последние записи агентам, которые самокорректируются через рефлексию (Reflexion) и критику с использованием инструментов (CRITIC), я захотел сделать шаг назад и рассмотреть более структурный подход: что если агент изначально не ограничивается одной цепочкой рассуждений? Tree of Thoughts (ToT) от Яо и др. (NeurIPS 2023) предлагает именно это — поисковый фреймворк, в котором LLM исследует ветвящееся пространство промежуточных шагов рассуждения вместо одной линейной цепочки. Я читаю эту работу сейчас, потому что она представляет собой наиболее четкую формулировку осознанного поиска для рассуждений LLM, а осознанный поиск — это именно то, что нужно, когда одна неверная промежуточная ступень в финансовых расчетах может незаметно исказить все последующие результаты.

Статья

Шуньюй Яо, Диань Юй, Джеффри Чжао, Ицхак Шафран, Томас Л. Гриффитс, Юань Цао и Картик Нарасимхан представляют Tree of Thoughts как обобщение промптинга цепочки мыслей (chain-of-thought). Ключевой ход заключается в том, чтобы рассматривать промежуточные шаги рассуждения как «мысли» — связные текстовые блоки, которые можно оценивать независимо — и организовывать их в дерево, а не в цепочку. В каждом узле модель генерирует несколько вариантов мыслей, оценивает каждый из них (через отдельный вызов LLM, который классифицирует состояния как «уверен / возможно / невозможно»), а затем применяет стандартный алгоритм поиска (BFS или DFS) для обхода дерева. Если ветвь кажется тупиковой, модель может отсечь её или вернуться назад (backtrack) — то, чего не могут сделать ни CoT, ни CoT-SC.

В статье метод оценивается на трех задачах: «Игра 24» (комбинирование четырех чисел для получения 24 с помощью арифметики), «Творческое письмо» (создание связного отрывка с использованием четырех случайных концовок предложений) и «Мини-кроссворды» (решение кроссворда 5×5). Все три задачи требуют рассуждений, которым полезны исследование и возврат назад — именно те условия, для которых авторы разработали ToT.

Ключевые идеи

• В «Игре 24» ToT с шириной луча b=5 достигает 74% успеха, в то время как GPT-4 со стандартным CoT — 4%, а CoT-SC со 100 выборками — 9%. Такой разрыв поражает.
• GPT-3.5 + ToT достигает лишь 19% в той же задаче; эффективность метода сильно зависит от модели. Качество генерации мыслей GPT-4 является основным драйвером роста: генерация GPT-4 + оценка GPT-3.5 дает 64%, тогда как генерация GPT-3.5 + оценка GPT-4 дает только 31%.
• В «Творческом письме» ToT набирает 7,56 балла против 6,93 у CoT по шкале связности GPT-4, а люди-аннотаторы предпочитают результаты ToT в 41/100 случаев против 21/100 для CoT.
• Мини-кроссворды: ToT достигает 60% точности на уровне слов (CoT: 40,6%, IO: 15,6%), но решает полностью только 4 из 20 игр (20%). Разрыв между успехом на уровне слов и на уровне всей игры показывает, что даже с возвратами удовлетворение глобальных ограничений остается сложной задачей.
• Шаг оценки сам по себе является вызовом LLM. В кроссвордах авторы отмечают, что оценщики иногда помечают правильные промежуточные состояния как «невозможные» из-за незнакомой лексики — это каскадный режим отказа, где ошибки оценщика отравляют весь поиск.
• Стоимость вычислений: ToT стоит примерно $0,74 за кейс в «Игре 24» против $0,47 для лучшего из 100 вариантов CoT. Авторы сами подчеркивают, что для задач, с которыми GPT-4 и так справляется хорошо, такие накладные расходы не оправданы.

Что подтверждается, а что — нет

Основной результат — то, что поиск по дереву промежуточных мыслей значительно превосходит последовательный CoT в задачах, требующих возвратов, — реален и воспроизводим. Разрыв 74% против 4% в «Игре 24» — это не статистический шум. Объяснение механически обосновано: одно неверное промежуточное уравнение в CoT обрушивает всю цепочку, в то время как ToT может отсечь эту ветвь и попробовать другое разложение.

Что мне кажется менее убедительным, так это претензия на универсальность. Все три оценочные задачи относительно синтетические: математическая головоломка, творческое письмо со структурными ограничениями и игра в слова. Ни одна из них не похожа на открытые, неоднозначные проблемы, возникающие в реальных финансовых рабочих процессах. Авторы также проводят оценку только на GPT-4 (и GPT-3.5 для аблации), поэтому мы не знаем, как ToT работает с меньшими или дообученными моделями — а цифра 19% для GPT-3.5 намекает, что «не очень хорошо».

Провал с кроссвордами на уровне игры (20% при 60% точности слов) указывает на более глубокую проблему: ToT — это локальный поиск, направляемый локальным оценщиком. Он не поддерживает модель глобальных ограничений, которая необходима для задач с плотным взаимодействием подрешений. Последующая статья «Graph of Thoughts» (Besta et al., AAAI 2024) явно критикует это и демонстрирует улучшение качества на 62% по сравнению с ToT в задачах сортировки при снижении стоимости более чем на 31% — за счет того, что мыслям разрешено объединяться и образовывать циклы, а не ограничиваться структурой дерева.

Наконец, структура затрат важна на практике. При b=5 с повторяющимися вызовами оценщика ToT примерно в 15–20 раз дороже в плане вызовов API, чем один проход CoT. Для приложений, чувствительных к задержкам или стоимости, это не является тривиально приемлемым.

Почему это важно для ИИ в финансах

Честный ответ таков: ToT наиболее важен для узкого сегмента задач Beancount, но этот сегмент реален.

Каноническая финансовая задача, где мне нужны возвраты (backtracking), — это многоэтапная классификация счетов для неоднозначных транзакций. Когда LLM сопоставляет импортированную банковскую выписку с планом счетов, одна неверная классификация в начале цепочки (например, трактовка выдачи кредита как дохода) может привести к ошибке проверки баланса через несколько шагов. В CoT-агенте к моменту ошибки баланса у модели нет механизма для пересмотра первоначальной классификации. ToT-агент мог бы вернуться к тому узлу и попробовать Liabilities:Loans вместо Income.

Аналогично, налоговая оптимизация за весь финансовый год — это подлинная задача поиска по дереву: выбор между постатейным вычетом и стандартным, выбор времени фиксации прироста капитала, группировка благотворительных взносов. Эти решения взаимодействуют нелинейно, и вам нужно оценить несколько ветвей, прежде чем принять решение. Структура BFS/DFS в ToT естественно ложится на эту задачу.

В чем ToT не помогает, так это в доминирующем сценарии Beancount: рутинном вводе транзакций и сверке. Для транзакции, имеющей четкое соответствие в реестре, CoT + PAL (перенос арифметики на интерпретатор кода) быстрее, дешевле и уже достаточно точен. Применять ToT для классификации expenses:groceries — это всё равно что забивать канцелярскую кнопку кувалдой.

Более насущной проблемой для безопасности записи данных (write-back safety) является надежность оценщика. Если оценщик состояния — это тоже LLM, он может ошибаться, а неверные оценки не просто замедляют поиск, они отсекают правильные пути. Любому производственному финансовому агенту, использующему ToT, потребуется внешний оракул (проверка баланса, валидатор схемы, движок правил) в качестве оценщика, а не еще один вызов LLM.

Что почитать дальше

• Graph of Thoughts: Solving Elaborate Problems with Large Language Models (Besta et al., AAAI 2024) — arXiv:2308.09687. Расширяет ToT от деревьев до произвольных графов, позволяя объединять мысли и создавать петли обратной связи. Заявление о снижении стоимости (>31%) напрямую актуально, если вы хотите использовать рассуждения на основе поиска без накладных расходов ToT.
• Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., ICLR 2024) — arXiv:2310.01798. Важный контраргумент: без внешней обратной связи внутренняя самокоррекция снижает производительность рассуждений. Это ставит под сомнение предположение о том, что оценщик на базе LLM в ToT достаточно надежен для управления поиском.
• RethinkMCTS: Refining Erroneous Thoughts in Monte Carlo Tree Search for Code Generation (arXiv:2409.09584) — применяет MCTS вместо BFS/DFS для поиска мыслей, используя обратную связь от выполнения кода как внешний оракул. Контекст генерации кода структурно похож на запись в финансовый журнал: у вас есть проверяемая истина (запускается ли код? проходит ли проверка баланса?), и именно здесь итерации Монте-Карло приносят пользу.