Дослідники Юсін Лу, Ічен Чен та Шаньчань Ву представили фреймворк «Procedural Graph», який дозволяє агентам великих мовних моделей (LLM) переписувати власні плани виконання завдань безпосередньо під час роботи.
Проблема сучасних агентів
Більшість асистентів на базі LLM діють подібно до шеф-кухаря, який може лише декламувати рецепт. Модель зберігає кроки в тимчасовій пам'яті, обирає наступний інструмент і сподівається, що наступний токен буде правильним. На практиці часто виникають три типи помилок:
- Відхилення від мети — через кілька кроків агент забуває початкову ціль.
- Неправильне використання інструментів — він викликає API у неправильному порядку або зациклюється на одному й тому самому виклику.
- Помилки, що не враховуються — та сама помилка з'являється у непов'язаних сесіях, оскільки ніщо не фіксує невдачу на постійній основі.
Оскільки міркування залишаються неявними, розробники не можуть зрозуміти причину певної дії, а користувачі не можуть виправити систематичні недоліки.
Перетворення промптів у граф
Procedural Graphs замінюють підхід «тільки пам'ять» на явну структуру, яку можна редагувати. Фреймворк визначає три основні елементи:
| Елемент | Роль |
|---|---|
| Вузол (Node) | Конкретний крок, наприклад, «Пошук рейсу» або «Перевірка оплати». |
| Ребро (Edge) | Потік між вузлами — послідовності по прямій лінії, умовні розгалуження (if/then) та цикли. |
| Атрибут (Attribute) | Метадані, прив'язані до вузла або ребра, наприклад, рівень успіху, середній час виконання або показник впевненості. |
Коли агент LLM отримує запит, він спочатку відображає його на існуючий граф або створює новий «на льоту». Потім виконання йде за ребрами, викликає інструменти та зберігає результати в атрибутах. Оскільки граф існує поза потоком токенів моделі, люди можуть переглядати, візуалізувати та редагувати його.
Саморозвиток у п'яти кроках
Новизна полягає в циклі, який дозволяє агенту вдосконалювати власний граф:
- Записувати кожен шлях, який проходить агент, реєструючи вхідні дані, виклики інструментів та результати.
- Порівнювати успішні шляхи з невдалими, визначаючи точки їхнього розходження.
- Діагностувати помилку, вивчаючи атрибути вузлів (наприклад, низький рівень успіху) та умови ребер.
- Пропонувати правки — LLM отримує аналіз помилки та пропонує модифікації графа (додати відсутній крок перевірки, видалити зайвий цикл, посилити умову).
- Перевіряти оновлений граф на тестовому екземплярі; якщо продуктивність покращується, зміна закріплюється.
Оскільки граф слугує єдиним джерелом істини, агент може додавати кроки, видаляти тупикові шляхи або переналаштовувати логіку без допомоги людини. Навіть незграбний робочий процес, створений людиною, може з часом «самовідновитися».
Чому ці зміни важливі
Узагальнення поза межами запам'ятовування
Статичний промпт фіксує лише один випадок виконання завдання. Граф абстрагує принцип «як це зробити» для цілого класу завдань — пошук і бронювання, конвеєри введення даних, діалоги з усунення несправностей — тому одна й та сама структура працює з різними параметрами. Командам більше не потрібно повторно формулювати промпт для моделі для кожної варіації.
Прозоре прийняття рішень
Граф виглядає як блок-схема. Зацікавлені сторони можуть точно простежити, який вузол ініціював виклик інструменту і чому було обрано певне розгалуження.
Нейросимволічна синергія
Procedural Graphs поєднують розпізнавання патернів за допомогою глибокого навчання (розуміння мови LLM) із символічним міркуванням (явна логіка графа). LLM забезпечує інтуїцію для створення або модифікації кроків, а граф забезпечує логічну послідовність. Автори описують це як надання LLM «Системи 2» — свідомого, перевірюваного контролера, який доповнює швидку асоціативну «Систему 1» сирого передбачення токенів.
Підсумок
Procedural Graphs надають агентам LLM гнучку, доступну для перегляду основу, яка дозволяє їм навчатися на кожному виконанні. Перетворюючи миттєві промпти на тривалі структури, цей підхід обіцяє створення ШІ-асистентів, які важче зламати, легше зрозуміти та які краще адаптуються до нових викликів.