Graph of Thoughts: как объединять решения ИИ — это метод, где рассуждение модели описывают графом операций: узлы хранят мысли, рёбра задают зависимости, а отдельные результаты соединяют в один. Официальная реализация проекта на GitHub моделирует задачу как Graph of Operations, который исполняет большая языковая модель.
Узлы, зависимости и Graph of Operations
В документации проекта на GitHub Graph of Thoughts описан как способ решать сложные задачи через моделирование их в виде Graph of Operations (GoO), который автоматически исполняется большой языковой моделью. Граф операций задаёт структуру работы, а движок выполняет её шаг за шагом.
Узел — это отдельное состояние мысли: черновик ответа, фрагмент списка, промежуточная формулировка. Зависимость — ребро, которое говорит, из каких результатов собран следующий. На постере ETH Zurich в легенде к схеме перечислены состояния мысли, операции и оценки, а также блоки Generate, Aggregate, Sort, KeepBest. Эти имена показывают, что граф собирается из типовых действий.
Graph of Operations описывает не только GoT, но и прежние схемы: на постере ETH Zurich сказано, что GoO позволяет задавать CoT, CoT-SC и ToT. Это значит, что граф — общий язык описания рассуждения, а сам GoT — один из вариантов его заполнения.
Практический вывод: прежде чем писать промпт, нарисуйте узлы и стрелки. Если стрелка ведёт от двух узлов к одному, это объединение. Если от одного к нескольким — ветвление. Если стрелка возвращает результат назад на доработку, это цикл обратной связи.
Объединение результатов и ветвление вариантов
Ветвление создаёт несколько независимых продолжений из одной точки. Объединение берёт несколько готовых результатов и сводит их в один узел. На постере ETH Zurich ключевая новизна GoT относительно ToT описана как произвольные графовые преобразования мыслей; там же показаны агрегация мыслей и агрегация цепочек.
Разница видна на сортировке. В README проекта приведён пример: список из 32 чисел сортируют CoT-подобным способом, а затем более сложным GoT-подходом, и результаты сравнивают по числу ошибок в итоговом состоянии. Оба запуска дают выходной граф, который можно открыть и изучить.
Ветвление отвечает на вопрос «какой из вариантов лучше». Объединение отвечает на вопрос «как собрать один ответ из нескольких пригодных частей». Для длинного документа ветвление даст несколько черновиков, а объединение сведёт их в связный текст.
| Приём | Что делает | Когда уместен |
|---|---|---|
| Ветвление | Создаёт несколько продолжений из одного узла | Нужен выбор лучшего варианта |
| Объединение | Сводит несколько узлов в один | Есть пригодные части от разных веток |
| Доработка | Возвращает результат на повторный проход | Нужно исправить найденный конфликт |
Генерация, оценка, отбор, объединение, доработка
Пять операций образуют рабочий цикл. Генерация создаёт варианты. Оценка присваивает им баллы. Отбор оставляет лучшие. Объединение сводит пригодные результаты. Доработка исправляет то, что не прошло проверку.
В README проекта показан код сортировки: создаётся GraphOfOperations, к нему добавляются операции Generate, Score и GroundTruth, затем настраивается языковая модель и контроллер, после чего запускается исполнение и сохраняется выходной граф. Оценка там задаётся функцией подсчёта ошибок, а финальное состояние несёт число этих ошибок.
На постере ETH Zurich у операции Generate указан параметр k, а у агрегации — k, означающий число попыток объединить две мысли. Это подсказывает порядок настройки: сначала задайте, сколько вариантов генерировать, затем как их оценивать, затем сколько лучших оставлять.
Промпт, чтобы получить план объединения результатов для вашей задачи:
Ты помогаешь собрать один итоговый документ из нескольких черновиков.
Тема: [ваша тема].
Ниже перечислены черновики с краткими пометками о качестве.
Шаг 1. Для каждого черновика назови одну сильную часть и одну слабую.
Шаг 2. Отметь, какие части противоречат друг другу.
Шаг 3. Собери один связный текст, взяв сильные части и убрав противоречия.
Шаг 4. Перечисли, что осталось неясным и требует уточнения у человека.
Формат ответа: сначала список сильных частей, затем итоговый текст, затем список неясностей.
Вариации той же задачи: объединить две версии инструкции в одну; свести три описания процесса в единую памятку; собрать один список требований из нескольких предложений; соединить два плана мероприятия в один; объединить черновики письма в финальную версию. В каждом случае меняйте [ваша тема] и число черновиков.
Полный ручной граф памятки «Маяк»
Возьмём учебное задание: составить план инструкции для волонтёров мероприятия «Маяк». Исходные условия: регистрация гостей ведётся офлайн на бумаге; у стойки дежурят координатор и волонтёр; собирать телефоны гостей запрещено организатором. Это условный учебный пример.
Узел A «Встреча»: приветствие, поиск фамилии в списке, отметка присутствия. Узел B «Сложные ситуации»: нет фамилии — направить к координатору; нет документа — уточнить порядок у координатора, не вводить новое требование. Узел C «Проверка ограничений» отклоняет предложение B добавить телефон в таблицу, потому что оно противоречит исходным условиям. Узел D «Объединение» принимает A и исправленный B: встреча → проверка фамилии → отметка или обращение к координатору.
Рёбра A→D и B→D показывают объединение результатов, C→B — необходимость доработки. Граф читается так: две рабочие ветки дают пригодные части, проверка отсекает нарушение, объединение собирает итог.
| Узел | Содержание | Роль в графе |
|---|---|---|
| A | Приветствие, поиск фамилии, отметка | Источник результата |
| B | Нет фамилии, нет документа | Источник результата |
| C | Отклонение сбора телефонов | Проверка ограничений |
| D | Встреча → проверка → отметка | Объединение A и B |
В финальную карточку входят исходные условия, содержание каждого узла, принятые и отклонённые элементы и итоговая памятка. Такой граф удобно рисовать на бумаге до обращения к модели: он показывает, где именно нужно объединение.
Проверка конфликта и сохранение ограничений
Проверка конфликта ищет утверждения, которые противоречат исходным условиям. В примере с «Маяком» узел C отклоняет добавление телефона в таблицу, потому что организатор запретил сбор телефонов. Это и есть конфликт между удобством учёта и заданным ограничением.
Порядок проверки: выпишите исходные условия отдельным списком; пройдите по каждому узлу и отметьте утверждения, которые их затрагивают; для спорного утверждения укажите, какое условие оно нарушает; верните узел на доработку с явной пометкой.
Качество проверяется сохранением запрета сбора телефонов и отсутствием выдуманных правил. Оценка «мне нравится» здесь не работает: она не показывает, уцелело ли ограничение. Критерий — воспроизводимость: другой человек по вашей карточке получит ту же памятку.
Промпт, чтобы проверить план на конфликт с ограничениями:
Ниже исходные условия и черновик инструкции.
Исходные условия: [ваши условия].
Черновик: [ваш текст].
Найди утверждения, которые противоречат исходным условиям.
Для каждого укажи: цитату из черновика, нарушенное условие, предлагаемую замену.
Если противоречий нет, перечисли условия, которые черновик сохраняет.
Граница ручного примера и исполнения библиотеки
Ручной граф и запуск библиотеки — разные вещи. В README проекта показано, как исполняется код: создаётся контроллер, ему передаются языковая модель, граф операций, промптер и парсер, затем вызывается запуск и сохранение выходного графа. Это программное исполнение с реальными вызовами модели.
Ручная карточка «Маяка» демонстрирует операции: узлы, зависимости, проверку и объединение. Текстовый запрос не равен запуску библиотеки GoT. Ручной пример показывает логику, а библиотека выполняет её на модели.
На постере ETH Zurich у контроллера указана цель — инициировать, координировать и продвигать исполнение GoT; у промптера — строить запрос к модели; у парсера — извлекать информацию из рассуждения. Эти роли полезно держать в голове: граф задаёт структуру, а контроллер ведёт её по шагам.
Практический вывод: ручной граф годится для проектирования и проверки ограничений. Для повторяемой обработки больших объёмов нужна библиотека с настроенной моделью и сохранением выходного графа.
Когда граф избыточен и как ограничить размер
Граф избыточен, когда задача решается одним проходом: короткий ответ, простая формулировка, одна ветка без объединения. Тогда узлы и рёбра добавляют работу без пользы.
Ограничители размера: число вариантов на генерации; число лучших результатов, которые остаются после отбора; число попыток объединения; глубина цепочки доработок. На постере ETH Zurich у агрегации указано k — число попыток объединить две мысли, а у KeepBest — сколько лучших оценённых мыслей сохранить.
Порядок действий для ограничения: начните с двух-трёх узлов; добавьте объединение только там, где есть пригодные части от разных веток; оставьте одну проверку ограничений; фиксируйте число вариантов заранее.
| Признак | Решение |
|---|---|
| Один проход даёт ответ | Обойтись без графа |
| Несколько пригодных частей | Добавить узел объединения |
| Есть жёсткое ограничение | Добавить узел проверки |
| Много вариантов | Ограничить число генераций и отбора |
Частые вопросы
Что такое Graph of Thoughts простыми словами?
Это способ описать рассуждение модели графом: узлы хранят промежуточные мысли, рёбра показывают, из чего собрана следующая. Официальная реализация на GitHub моделирует задачу как Graph of Operations и исполняет её языковой моделью. Граф позволяет соединять несколько результатов в один.
Чем GoT отличается от Tree of Thoughts?
На постере ETH Zurich ключевая новизна GoT относительно ToT описана как произвольные графовые преобразования мыслей. Дерево даёт ветвление и выбор пути, а граф добавляет соединение нескольких узлов и циклы обратной связи. Поэтому объединение частей становится отдельной операцией.
Как объединять промежуточные результаты?
Соберите пригодные части от разных веток в один узел и проверьте, нет ли между ними противоречий. В примере с «Маяком» узел D принимает результаты A и B после исправления. Перед объединением убедитесь, что каждая часть прошла проверку ограничений.
Как проверить, что ограничения сохранились?
Выпишите исходные условия отдельно и пройдите по каждому узлу. Отметьте утверждения, которые затрагивают эти условия, и укажите нарушенное. В примере узел C отклоняет сбор телефонов, потому что это запрещено организатором.
Когда граф не нужен?
Когда задача решается одним проходом и не требует соединения нескольких результатов. Короткий ответ, простая формулировка и одна ветка обходятся без узлов и рёбер. Граф добавляют там, где есть пригодные части от разных веток или жёсткое ограничение.