Как граф превращает ошибки ИИ-агента в подсказки

Когда агенту мало памяти

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

Новая работа Google, Georgia Tech и Peking University предлагает для этого практичную идею: не хранить процедуру только в тексте истории, а вынести её в отдельный граф действий. Авторы называют его Procedural Graph, по-русски — процедурный граф.

Смысл простой. Граф знаний отвечает на вопрос «что это такое?». Процедурный граф отвечает на вопрос «что делать дальше?». Это различие для ИИ-агентов полезно.

Идея статьи в одной картинке: граф знаний хранит факты, а процедурный граф хранит последовательности действий.

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

Что такое процедурный граф

Авторы предлагают хранить процедурные знания в виде троек. Но если в графе знаний это что-то вроде «Париж — столица — Франции», то здесь тройка другая: «процедура — отношение — следующая процедура».

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

🟠 условие — когда этот переход уместен

🟠 промт — что именно стоит сделать

🟠 ошибки — чего не надо делать

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

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

Как это работает во время инференса

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

🟣 находит текущее место агента в графе

🟣 достаёт локальную окрестность этого узла

🟣 просит отдельную LLM превратить этот кусок графа в короткий ситуационный промт

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

Общая схема: граф подсказывает следующий шаг во время инференса, а потом сам обновляется по логам выполнения.

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

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

Короткая выжимка по механике:

🟠 Граф не заменяет агенту рассуждение

🟠 Граф задаёт допустимые переходы и типичные ошибки

🟠 Промт привязан к текущему прогрессу агента

🟠 Если сопоставить шаг с графом не удалось, система может использовать весь граф как запасной вариант

Главное отличие от памяти и текстовых правил

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

Процедурный граф делает это явным.

Вместо списка воспоминаний или набора правил система знает:

🟣 какие шаги обычно следуют друг за другом

🟣 какие переходы допустимы

🟣 при каких условиях переход уместен

🟣 какие ошибки типичны именно на этом участке

Это особенно полезно там, где важно не просто вызвать правильный инструмент, а вызвать его в правильный момент.

Граф, который исправляет сам себя

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

Он может:

🟠 добавить недостающий узел

🟠 добавить новый переход

🟠 удалить переход, который часто ведёт в тупик

🟠 переписать атрибуты перехода: условие, промт, ошибки

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

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

В ИИ-агентах часто много разговоров про «самоулучшение», но мало механизмов, которые не дают системе испортить саму себя. Здесь такой механизм есть: редактор предлагает, валидация решает.

Что показали эксперименты

Авторы проверили подход на семи бенчмарках. Там есть и многосвязный поиск ответов, и многоходовые диалоги, и вызовы функций, и задачи из робототехники, и финансовый симулятор на 132 месяца.

Главный результат такой: процедурный граф стабильно выигрывает у методов на основе памяти.

По основной сводной таблице метод занял первое или совместное первое место в 21 из 24 сочетаний «модель + бенчмарк». Если сравнивать с лучшим базовым методом в каждом случае, получилось 19 побед, 2 ничьих и 3 проигрыша.

Короткая выжимка по результатам:

🟣 21 из 24 сочетаний «модель + бенчмарк» — первое или совместное первое место

🟣 19 побед, 2 ничьих, 3 проигрыша против лучшего базового метода

🟣 Лучше всего эффект виден в задачах, где важен порядок действий

Самоэволюция графа по раундам: продолжительность жизни агента и привлечённый капитал растут по мере исправления процедур.

Самые заметные прибавки были такими:

🟣 на BFCL v3 с Gemini 3.5 Flash: 67% против 58%

🟣 на GDPval с Gemini 3.1 Pro: 78,78 против 71,37

🟣 на τ-bench с Gemini 3.1 Pro: 80% против 73,04%

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

Короткая выжимка по результатам:

🟠 Лучше всего метод показывает себя на задачах с длинной процедурой

🟠 Обычная текстовая память не даёт такого стабильного эффекта

🟠 Один и тот же подход работает на разных LLM: Claude, Gemini, Grok

🟠 Эффект зависит от типа задачи: в фактологическом поиске он скромнее

Самый показательный эксперимент: агент-финдиректор

Авторы отдельно тестируют агентов в EnterpriseArena — это симулятор, где агент играет роль финансового директора. Нужно 132 месяца управлять ликвидностью компании, пережить три макроэкономических кризиса и не обанкротиться. Деньги от привлечения капитала приходят с задержкой от 1 до 6 месяцев. Значит, ключ к выживанию — просить деньги заранее.

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

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

Результаты по выживаемости:

🟣 Claude Sonnet 4.6: 58% выживших с графом против 44% без него

🟣 Gemini 3.1 Pro: 34% против 6%

🟣 Grok 4.1 Fast: 40% против 26%

🟣 Gemini 3.5 Flash: до полного финиша никто не дожил, но средняя продолжительность жизни выросла с 33,58 до 40,62 месяца

Короткая выжимка по выживаемости:

🟠 На длинном горизонте граф повышает шансы дожить до конца симуляции

🟠 Самый большой разрыв здесь у Gemini 3.1 Pro: 34% против 6%

🟠 Даже когда финиша нет, растёт средняя продолжительность жизни агента

Что меняется в поведении агента? Не просто число вызовов инструментов. Меняется момент принятия решений.

Без графа агент может бесконечно перепроверять баланс и рынок, но поздно начать привлечение капитала. С графом он чаще соблюдает правильную последовательность:

🟠 проверить деньги

🟠 посчитать прогноз

🟠 посмотреть рынок

🟠 заранее запросить финансирование

🟠 дождаться его прихода, не нарушая правила среды

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

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

Можно ли построить граф с нуля

Да, и это ещё один результат. Авторы сравнили пять режимов построения графа: вручную, с разовым обновлением, с поэтапной эволюцией, а также с нуля — из скелета `Start → End`.

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

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

Ещё интереснее история с плохим экспертным графом. На MultiChallenge ручной граф сначала вообще ухудшал качество: успех падал с 87,5% до 58,93%. Разовое статичное обновление делало ещё хуже — 53,57%. А вот итеративная эволюция с валидацией поднимала результат до 92,86%.

Иными словами, система умеет не только наращивать процедуру, но и исправлять плохие человеческие заготовки.

Цена вопроса: токены и сложность

За структуру надо платить. Промт от графа — это дополнительный вызов модели и дополнительные токены. Авторы честно это показывают.

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

Зато есть и экономия другого рода. В финансовом симуляторе после нескольких раундов эволюции число вызовов инструментов упало с 17,23 до примерно 3,1 в месяц. То есть агент стал действовать намного собраннее.

Тут вывод практичный: процедурный граф — это обмен токенов на надёжность и структурность поведения.

Вывод

Процедурный граф — это попытка дать ИИ-агенту явное процедурное знание: что делать, в каком порядке и при каких условиях. Не в виде длинной истории, не в виде россыпи текстовых правил, а в виде редактируемого графа переходов.

Из работы стоит вынести несколько вещей:

🟠 Длинные агентные задачи упираются в процедуру, а не только в качество рассуждения

🟠 Локальный структурный промт работает лучше, чем полный граф или просто память

🟠 Процедурное знание можно улучшать без дообучения модели, через журналы выполнения и валидацию

🟠 Граф, собранный с нуля, может догнать и обойти ручную экспертную схему

🟠 В задачах с задержками, ограничениями и строгим порядком действий такой подход особенно полезен

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