Дерево мыслей: когда ИИ нужен поиск вариантов

Дерево мыслей оправдывает дополнительные вызовы модели, когда промежуточное решение можно оценить, не доводя его до конца. Даже небольшой поиск в приведённом ниже расчёте увеличивает число вызовов с 1 до 21. Начните с базового решения на модели с рассуждениями и добавляйте ветвление только там, где поиск может исправить ошибки.

Источники проверены 24 октября 2026 года. Все результаты бенчмарков ниже взяты из исходной статьи 2023 года Shunyu Yao и соавторов. Разобранные ветви поиска и расчёты числа вызовов модели служат для объяснения метода и не являются результатами работы в продакшене.

Как дерево мыслей организует поиск решения

Tree of Thoughts (ToT) позволяет приложению сравнивать незавершённые решения и выбирать, какие из них стоит развивать. Большая языковая модель, или LLM, предлагает следующие шаги; оценщик проверяет получившиеся состояния; алгоритм поиска решает, что сохранить, продолжить или отбросить. Yao и соавторы представили этот подход в мае 2023 года. Описание метода в исходной статье.

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

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

В цикле есть три явные операции:

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

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

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

Дерево мыслей и цепочка рассуждений: в чём разница

Разница в том, на каком этапе сравниваются альтернативы: пока решение ещё не закончено или после того, как получены полные ответы.

Именно это различие описано в обзоре подходов и описании метода у Yao и соавторов. Стандартный подход self-consistency генерирует полные цепочки и выбирает самый частый ответ. Для этого нужен осмысленный способ распознавать эквивалентные ответы: устроить голосование по произвольным текстам сложнее, чем по числовым результатам.

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

Два близких приёма решают другие задачи. Few-shot-промптинг задаёт примеры нужного поведения или формата ответа, помогая генератору или оценщику соблюдать требования. Цепочки промптов связывают этапы — например, извлечение фактов и последующую подготовку ответа. Фиксированная последовательность этапов становится поиском лишь тогда, когда система хранит альтернативы и решает, какие из них исследовать.

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

Пример: создаём ветви, оцениваем и отсекаем

Верное промежуточное уравнение всё равно может вести в тупик. Оценщик должен уметь различать эти ситуации.

Возьмём пример Game of 24 из статьи: из чисел 4, 9, 10 и 13 нужно получить 24 с помощью базовых арифметических операций, использовав каждое число ровно один раз. Следующий разбор составлен для объяснения механики; это не запись диалога с моделью. Возможность или невозможность продолжения проверена перебором оставшихся арифметических комбинаций. Исходные числа в примере из статьи.

1. 1

   Строим ветви из начального состояния

   Вариант A: вычислить 4 + 9 = 13. Остаются числа 10, 13, 13.

   Вариант B: вычислить 13 - 9 = 4. Остаются числа 4, 4, 10.

   Оба действия допустимы. Одинаковые числа здесь — отдельные оставшиеся значения; состояние должно сохранять количество их вхождений.

2. 2

   Оцениваем получившиеся состояния

   В варианте A получить 24 уже нельзя, если использовать каждое оставшееся значение один раз и только сложение, вычитание, умножение или деление. Отсекаем эту ветвь.

   Вариант B допускает верное продолжение: вычесть одну из оставшихся 4 из 10, затем умножить результат на другую 4. Сохраняем его.

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

3. 3

   Развиваем оставшуюся ветвь

   Из состояния 4, 4, 10 рассмотрим два шага: 4 + 4 = 8, после которого остаются 8, 10, и 10 - 4 = 6, после которого остаются 4, 6.

   Первое состояние не позволяет получить 24 оставшейся операцией. Второе позволяет: 4 × 6 = 24. Сохраняем это продолжение и проверяем полное выражение.

4. 4

   Проверяем итоговый ответ

   Выражение (13 - 9) × (10 - 4) = 24 использует каждое исходное число один раз и даёт нужный результат. Поиск заканчивается, потому что результат прошёл проверку условий задачи.

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

Какие результаты получили авторы Tree of Thoughts

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

Для Game of 24 авторы проверили GPT-4 на 100 сравнительно сложных заданиях. Эксперименты проводились в мае 2023 года. В таблице 2 приведены следующие доли успешных решений:

Источник: Yao и соавторы, таблица 2 и условия эксперимента с Game of 24.

Ширина — это число сохраняемых состояний, а не число вызовов модели. Генерация кандидатов и их оценка требуют дополнительных ресурсов. В конфигурации для Game of 24 авторы получали оценку каждого кандидата трижды. Условия эксперимента.

В статье также изучались задачи Creative Writing и Mini Crosswords. Это другие задачи с другими способами оценки. Практический вывод гораздо уже, чем «ToT делает модели лучше»: поиск может помочь, когда важно выбрать перспективное промежуточное направление и его можно оценить. Прежде чем добавлять контроллер, разработчику всё равно нужны подтверждения на собственных задачах.

Сколько вызовов модели добавляет ветвление?

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

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

Зададим по три потомка для каждого раскрываемого родителя, будем сохранять два состояния после каждого уровня и раскроем три уровня. Число раскрываемых родительских состояний составит 1, 2 и 2. Получаем:

• Генерация: 1 + 2 + 2 = 5 вызовов.
• Оценка: 3 × (1 + 2 + 2) = 15 вызовов.
• Итоговый ответ: 1 вызов.
• Всего: 5 + 15 + 1 = 21 вызов, то есть в 21 раз больше, чем в базовом варианте с 1 вызовом.

Если оценивать каждого кандидата трижды, то же дерево потребует 5 + 45 + 1 = 51 вызов. Если объединить оценки всех кандидатов на каждом уровне в один запрос, получится 5 + 3 + 1 = 9 вызовов. Объединение меняет контекст оценщика и условия вынесения решения; это вариант реализации, а не гарантия того же качества.

Для сравнения: self-consistency с пятью отдельно запрошенными вариантами использует пять вызовов модели, если итоговое голосование выполняет детерминированный код. Дополнительная модель-судья увеличит число вызовов и изменит это сравнение.

Общая формула расчёта: C = Σ nₜ(g + kv) + f. Здесь nₜ — число родителей, раскрываемых на уровне t; g — число запросов генерации на родителя; k — число потомков на родителя; v — число запросов оценки на потомка; f — число запросов для подготовки итогового ответа. Формула предполагает отдельную оценку каждого потомка; при пакетной оценке считайте объединённые запросы напрямую.

Как реализовать Tree of Thoughts: управление поиском

Храните состояние поиска и правила остановки в коде приложения. Модели поручите предлагать и оценивать результаты промежуточных шагов с чёткими границами, которые можно проверить.

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

1. 1

   Определите состояние, которое можно проверить

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

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

2. 2

   Разделите задачи генератора и оценщика

   Инструкция генератору может выглядеть так: «Предложи разные следующие назначения из этого состояния. Для каждого кандидата верни назначение и обновлённое состояние. Соблюдай перечисленные ограничения».

   Инструкция оценщику: «Проверь каждого кандидата на соответствие ограничениям. Верни его идентификатор, нарушенные ограничения, если они есть, и статус продолжения: возможно, неопределённо или исключено. Укажи поля состояния, на которых основана оценка».

   Начните с детерминированных проверок таких правил, как пересечение временных интервалов или отсутствие обязательных полей. Если нужна оценка модели, проверьте её на известных примерах с помощью процесса оценки LLM-as-a-judge.

3. 3

   Явно задайте правила отсечения и бюджет

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

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

4. 4

   Проверяйте результат перед принятием или действием

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

   Исследуйте ветви в изолированной среде или храните их как предложения действий. Пробная ветвь расписания не должна отправлять приглашения. Ветвь с изменениями кода не должна развёртывать их, пока контроллер ещё сравнивает кандидатов.

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

Когда модель с рассуждениями позволяет обойтись без ToT

Внешний ToT не нужен, если модель с рассуждениями уже отвечает требованиям к качеству и задержке, а приложению не требуется управлять промежуточными альтернативами.

Модель с рассуждениями выполняет внутреннюю работу перед ответом. В актуальных рекомендациях Anthropic по промптингу советуют задавать таким моделям общие цели, а не предписывать каждый шаг рассуждения. Это аргумент в пользу того, чтобы начать с ясной задачи, ограничений и критериев приёмки. Но это не доказывает, что конкретная модель внутри реализует алгоритм ToT, описанный Yao и соавторами. Рекомендации Anthropic по промптингу.

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

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

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

Какие обещания Tree of Thoughts преувеличены

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

Другое преувеличение — будто больше ветвей гарантирует лучший ответ. Ветви могут повторять одну и ту же идею. Оценщик может разделять ошибочное предположение генератора. Раннее отсечение способно удалить единственное полезное продолжение. Уверенный тон не заменяет проверки условий задачи.

Наконец, лучший результат статьи на Game of 24 не доказывает, что ToT нужен каждому бизнес-процессу. Если извлечение данных из документов даёт результат, не соответствующий схеме, могут помочь более удачные примеры и валидация. Если помощнику поддержки не хватает нужного правила, ему может потребоваться правильный источник. Перебор дополнительных путей при том же недостатке информации не даст отсутствующий факт.

Используйте поиск для выбора между решениями, которые можете оценить. Недостающий контекст и нарушения требований устраняйте напрямую.

Что изменить в своём приложении на этой неделе

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

Подождите, если пока не можете объяснить, почему одно частичное решение лучше другого. Соберите набор допустимых и недопустимых состояний, проверьте решения оценщика и улучшите его оценки, прежде чем расширять дерево.

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

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

Частые вопросы о Tree of Thoughts

Рассуждение и Chain-of-Thought — это одно и то же?

Рассуждение — более широкая способность разбирать и решать задачу. Chain-of-thought — подход к промптингу, использующий промежуточные шаги. Модель может выполнять внутренние рассуждения, не выводя эти шаги в ответе.

Что такое дерево в ИИ?

Дерево представляет состояния и возможные следующие действия. Узел — это состояние, а его потомки — альтернативы, достижимые следующим шагом. В ToT эти состояния представляют частичные решения.

Что называют деревом рассуждений?

В этом контексте так называют организацию альтернативных частичных решений в виде ветвей с их оценкой и выбором продолжения. Конкретный подход Yao и соавторов называется Tree of Thoughts.

Что такое промптинг по методу дерева мыслей?

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

Что означает правило трёх C в промптинге?

Алгоритм ToT, описанный Yao и соавторами, не определяет правила трёх C. Эта мнемоника не служит его спецификацией: в статье описаны разбиение решения на мысли, их генерация, оценка состояний и поиск.

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

Стандартный CoT строит одну непрерывную цепочку рассуждений. ToT явно рассматривает альтернативные частичные пути и оценивает их по ходу поиска. Self-consistency устроен иначе: генерирует полные пути и объединяет итоговые ответы.

Как выглядит пример промптинга с цепочкой рассуждений?

В разобранном арифметическом примере можно показать 13 - 9 = 4, затем 10 - 4 = 6, затем 4 × 6 = 24. Такие промежуточные шаги в качестве образца иллюстрируют CoT. Сравнение альтернативных шагов и выбор ветви для продолжения добавляют механизм поиска ToT.

Что такое Chain-of-Thought простыми словами?

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

Как работает Chain-of-Thought?

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

Подпишитесь на рассылку, чтобы получать практические руководства по созданию надёжных процессов с ИИ.