Tree-of-Code: древовидная структура для сквозной генерации и выполнения кода при решении сложных задач

Исследование предлагает метод "Tree-of-Code" (ToC), который заставляет LLM решать сложные задачи путем написания и выполнения целой программы за один раз, вместо пошаговых действий. Если программа не работает, модель анализирует ошибку, исправляет код и пробует снова, создавая "дерево" из различных версий решения.

Ключевой результат: Этот подход значительно повышает точность решения сложных задач (почти на 20%) и требует в 4 раза меньше итераций по сравнению с пошаговыми методами вроде ReAct.

Представьте, что вам нужно приготовить сложное блюдо по новому рецепту. Вместо того чтобы спрашивать у повара "что делать дальше?" после каждого шага, вы просите его написать весь рецепт целиком от начала до конца. Затем вы пытаетесь по нему готовить. Если на каком-то этапе что-то идет не так (например, тесто не поднялось), вы не выбрасываете все, а возвращаетесь к повару, показываете ему проблему ("тесто не поднялось") и просите переписать рецепт с учетом этой ошибки.

Метод Tree-of-Code (ToC) работает по схожему принципу с LLM:

1. Генерация целой программы (CodeProgram): Вместо того чтобы давать команды по одной, LLM генерирует сразу всю программу для решения задачи (весь "рецепт"). Сначала модель формирует план действий в виде мыслей (<thought>), а затем пишет код (<execute>), который этот план реализует.

2. Проверка через "казнь" (Execution): Сгенерированный код запускается в реальной среде. Результат может быть только двух видов: "успешно выполнено" или "ошибка". Это и есть главный сигнал обратной связи.

3. Самокоррекция и рост "дерева" (Reflection & Tree Expansion):

   • Если код выполнился успешно, решение считается рабочим и сохраняется.
   • Если код выдал ошибку, LLM получает текст этой ошибки и инструкцию "подумай, что пошло не так, и исправь". Модель генерирует новую, исправленную версию программы. Этот процесс повторяется, создавая ветку "дерева" решений.
   • Чтобы найти наилучшее решение, система может параллельно запустить несколько таких "поваров" (разные LLM или разные промпты), создавая несколько веток "дерева". В конце выбирается самый популярный ответ из всех успешно выполненных программ.

Суть метода — заставить LLM не просто рассуждать, а создавать проверяемый результат (код), а затем использовать объективную обратную связь (ошибку выполнения) для итеративного улучшения этого результата.

• Прямая применимость: Нулевая. Обычный пользователь в интерфейсе чат-бота не имеет среды для выполнения кода и автоматической отправки ошибок обратно модели. Это чисто инженерный фреймворк.

• Концептуальная ценность: Очень высокая. Исследование дает пользователю мощную ментальную модель для взаимодействия с LLM:

  1. Принцип "Сначала план, потом действие": Заставляя модель сначала структурировать свои мысли в виде плана, а затем генерировать итоговый ответ, можно значительно повысить его логичность и полноту.
  2. Принцип "Ошибка — это не провал, а подсказка": Вместо того чтобы разочаровываться в неверном ответе, его можно использовать. Нужно скопировать ответ, указать на конкретную ошибку и попросить модель исправить себя. LLM отлично справляются с ролью "отладчика" собственных текстов.
  3. Принцип "Параллельных вселенных": Если задача сложная, можно открыть 2-3 чата и дать немного разные промпты. Сравнив результаты, можно получить более качественный итоговый ответ. Это ручная версия "дерева" решений.

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

  • Механизм адаптации: Вместо автоматического выполнения кода пользователь сам выступает в роли "компилятора". Он "выполняет" ответ модели (т.е. проверяет его на логику, факты, соответствие требованиям). Если находит "ошибку", он формулирует ее в виде четкой обратной связи и отправляет модели вместе с ее же неверным ответом для исправления.

Представим, что нужно составить контент-план для кулинарного блога.

Ты — опытный контент-стратег. Твоя задача — разработать контент-план для Instagram-блога "Быстрые рецепты для занятых" на одну неделю.

**Целевая аудитория:** работающие люди 25-40 лет, у которых мало времени на готовку.
**Формат:** 4 поста (рецепты) и 3 Stories (интерактив).
**Ключевое требование:** Все рецепты должны готовиться не дольше 20 минут.

Действуй по следующему алгоритму:

1.  **Сначала создай общую стратегию.** Подумай о темах недели, разнообразии блюд (завтрак, обед, ужин) и типах интерактива. Оформи свои мысли в тегах `<стратегия>`.

2.  **Затем, на основе этой стратегии, сгенерируй детальный контент-план** в виде таблицы. Оформи его в тегах `<контент-план>`.

3.  **Самопроверка:** После генерации перечитай свой план и убедись, что все рецепты действительно укладываются в 20 минут. Если найдешь несоответствие, явно укажи на него и исправь.

Приступай.

Этот промпт имитирует ключевые принципы Tree-of-Code без использования кода:

1. Декомпозиция ("Мысль -> Действие"): Инструкция "Сначала создай стратегию... Затем сгенерируй план" заставляет LLM сначала выстроить логический каркас (<стратегия>), а уже потом наполнять его деталями (<контент-план>). Это аналог "глобального планирования" в CodeProgram, что снижает риск получения хаотичного и несвязанного набора идей.

2. Структурирование вывода: Использование тегов <стратегия> и <контент-план> помогает модели лучше организовать ответ и следовать заданной структуре, что повышает его читаемость и качество.

3. Ручная "самокоррекция" (Reflection): Требование "Самопроверка" прямо просит модель выполнить рефлексивный шаг, аналогичный анализу ошибок выполнения в ToC. Это побуждает LLM еще раз проверить свой ответ на соответствие ключевому ограничению (20 минут), что повышает надежность и точность результата.

Задача: подготовить краткое содержание (саммари) длинной статьи для презентации.

Ты — ассистент руководителя. Тебе нужно подготовить краткое изложение статьи [вставить сюда текст статьи] для 5-минутного доклада на совещании.

Действуй строго по этому процессу:

1.  **<План_изложения>:** Сначала определи 3-4 ключевые идеи или аргумента статьи. Представь их в виде плана из тезисов. Не пиши полный текст, только структуру будущего саммари.

2.  **<Полный_текст_саммари>:** На основе созданного плана напиши связный текст объемом не более 250 слов. Текст должен быть ясным, убедительным и легким для восприятия на слух.

3.  **<Проверка_на_ошибки>:** После написания текста вернись к исходной статье и своему плану. Проверь, не упустил ли ты важную деталь и не исказил ли смысл. Если найдешь ошибку, напиши: "Коррекция: [в чем была ошибка]. Исправленная версия:" и предоставь новый, улучшенный текст саммари.

Этот промпт также использует адаптированную логику ToC для повышения качества сложной задачи — суммаризации:

1. Принудительная декомпозиция: Требование сначала создать <План_изложения> заставляет модель идентифицировать главные структурные элементы статьи перед тем, как погружаться в написание связного текста. Это предотвращает "утопание в деталях" и помогает создать сбалансированное саммари, а не просто пересказ первых абзацев.

2. Итеративное построение: Процесс "План -> Текст" является аналогом "Мысль -> Код". План служит каркасом, который обеспечивает логическую целостность финального продукта.

3. Встроенный цикл обратной связи: Шаг <Проверка_на_ошибки> — это ручная симуляция "execution-based reflection". Он заставляет модель перепроверить свою работу по объективным критериям (исходный текст и собственный план), найти потенциальные "баги" (пропущенные детали, искажение смысла) и "отладить" свой ответ. Это значительно повышает фактическую точность и надежность итогового саммари.