Атомні графи завдань: планування роботи агента як граф залежностей
Як фреймворк Atomic Task Graph розбиває завдання агентів на вузли з типизацією, моделює плани та виправляє лише несправні підграфи, щоб допомогти невеликим відкритим моделям конкурувати.
Джерела: This New AI Framework Turned 7B Models Into GPT-4 Competitors (Without Any Training)
Більшість спроб зробити агентів на основі LLM більш надійними починаються з використання більшої моделі. Фреймворк Atomic Task Graph (ATG), запропонований дослідниками з Університету Цінхуа та Південного технологічного університету Китаю, йде іншим шляхом: він змінює спосіб, яким агент організовує свою роботу. Згідно з дослідженням, моделі open-source розміром 7B та 8B, інтегровані в ATG, перевершили GPT-4, який використовував стандартний цикл ReAct, у двох відомих тестах на агентів, без жодної налаштування, навчання за принципом підкріплення чи оновлень ваг. Нижче — чому лінійні ланцюги міркувань не функціонують, як ATG замінює їх графом залежностей та які ідеї можна скористатися для створення власних агентів.
Чому лінійні цикли агентів зазнають невдач під час виконання довгих завдань
Розглянемо запит на кшталт «створіть звіт про продажі за 2024 рік із діаграмами». Типовий агент у стилі ReAct розглядає це як одну довгу послідовність кроків, кожен з яких залежить від попереднього.
Step 1
↓
Find database
↓
Query data
↓
Analyze numbers
↓
Create graphs
↓
Write report
Ланцюг залишається коректним, доки кожен крок виконується успішно. Проблеми починаються, коли хоча б один з кроків провалюється. Якщо запит до бази даних зазнає невдачі, усі наступні кроки будуються на неповних або неправильних даних.
Database query
↓
Everything after it becomes wrong
У такій ситуації агент може або почати все знову з самого початку, або продовжити роботу з тим, що у нього є. Багато хто обирає другий варіант, що є основною причиною галюцинацій: модель вигадує правдоподібні дані, щоб заповнити прогалини, і кожне наступне рішення успадковує цю помилку.
Контекст постійно зростає
Другою проблемою є те, як ці агенти зберігають стан. Після кожної дії думка, виклик інструменту та спостереження додаються до постійно зростаючого запису.
User
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
Зрештою модель аналізує сторінки історії. Контекст стає переповненим, а ранні помилки залишаються видимими, тож вони продовжують впливати на подальші рішення. Як у грі „телефонна лінія“, кожен етап трохи спотворює план, доки він не відхиляється від реальності.
Основна ідея: граф замість ланцюга
ATG замінює одну послідовність на граф завдань. Кожен вузол — це одиниця роботи, а кожна дуга фіксує залежність між двома одиницями.
Report
/ \
Analysis Charts
/ \
Database Statistics
Ця структура робить незалежність видимою: не пов’язана робота більше не чекає, а збій у одному підрозділі не робить недійсними його сусідні підрозділи.
Як ATG створює та запускає граф
Фреймворк працює у п’яти етапах.
1. Рекурсивний розклад на атомарні завдання
Усе починається з запиту користувача.
Create sales report
ATG розділяє цю мету на підзавдання.
Create sales report
↓
Load data
↓
Analyze sales
↓
Create charts
↓
Write summary
Потім він продовжує розділяти будь-яку підзавдання, яка все ще занадто широка, наприклад крок аналізу.
Analyze sales
↓
Revenue
↓
Profit
↓
Growth
↓
Regional trends
Розкладання припиняється, коли кожен листок відповідає одному виклику інструменту, наприклад:
SQL query
Python calculation
Matplotlib chart
Markdown writer
Ці листки – це атомарні завдання: одиниці, достатньо малі, щоб їх подальше розділення не мало сенсу. Правило зупинки має значення: нечіткий вузол залишає занадто багато простору для імпровізації, тоді як один SQL-запит має чіткий, перевірюваний результат.
2. Чіткі вхідні та вихідні дані для кожного вузла
Кожному вузлу присвоюється інтерфейс, схожий на підпис функції. Замість інструкції на кшталт „виконати аналіз“ планувальник описує, що споживає вузол та що він генерує.
def analyze_sales(data):
return summary
Цей уривок є ілюстративним, а не кодом фреймворку, проте він демонструє контракт. Оскільки граф залежить лише від цього контракту, вузол можна спробувати знову або замінити на інший інструмент, не привертаючи уваги його сусідів — це та сама властивість, яка робить модульний код керованим.
3. Паралельна обробка незалежних гілок
Послідовний агент виконує завдання одне за одним, навіть якщо деякі з них не пов’язані між собою.
Task A
↓
Task B
↓
Task C
Якщо B та C потребують лише результату A, а не один одного, ATG може це прямо виразити.
Task A
/ \
Task B Task C
\ /
Task D
Тоді B та C можуть виконуватися одночасно, поки D чекає на обидва. У дослідженні повідомляється про значно коротші шляхи виконання у всіх тестах, які були проаналізовані, що є природним наслідком об’єднання незалежних кроків у паралельні.
4. Тестування без використання реальних інструментів
Перш ніж щось виконати, ATG імітує весь план усередині себе, фактично запитуючи модель, чи спрацює план, якщо його буде виконано згідно з написаним. Під час імітації шукаються:
- кроки, яких бракує
- неправильний інструмент, призначений для вузла
- некоректні залежності між вузлами
- невідповідності інтерфейсів, коли вихідний сигнал одного вузла не підходить до вхідного сигналу наступного вузла
- шляхи виконання, які насправді не можна завершити
- порушення обмежень завдання
Це еквівалент агента, який проводить тести перед розгортанням, і це дешево, оскільки не викликається жоден зовнішній інструмент. Однак якість перевірки залежить від моделі, яка її виконує: модель, яка написала план, може мати свої сліпі зони, тому сприймайте її як фільтр, а не гарантію.
5. Цілеспрямована корекція пошкодженого підграфу
Найважливішим аспектом є те, як ATG справляється з несправностями під час виконання. Розглянемо просту схему:
Database
↓
Analysis
↓
Charts
↓
Report
Припустимо, що вузол аналізу зазнає несправності. Традиційний агент зазвичай реагує шляхом видалення своїх досягнень та початку роботи знову.
Database
↓
Analysis
↓
Charts
↓
Report
↓
Start over
ATG, натомість, зберігає ту саму схему та заморожує кожен вузол, який вже видав коректний результат. Наведена нижче діаграма навмисно виглядає ідентичною до оригіналу: структура не змінюється, лише вузол аналізу позначається на повторну обробку, тоді як вузли бази даних, графіка та звіту залишаються без змін.
Database
↓
Analysis
↓
Charts
↓
Report
Перегенерується лише несправний підграф, і як тільки він працюватиме коректно, схема продовжуватиме роботу з новим результатом.
Database
↓
New Analysis
↓
Charts
↓
Report
Це інкрементна компіляція, застосована до планування. Зверніть увагу, що якщо виправлена аналіза дає інші цифри, нижчележачі вузли, які її використовують, все одно мають її перезапустити; економиться лише робота вищележачих елементів та непов’язані гілки.
Чому менші контексти означають менше галюцинацій
У циклі ReAct кожен крок бачить повну історію. У ATG кожен вузол отримує лише ті дані, які вказані у його інтерфейсі, тому є менше «шуму» та менше можливостей для проникнення попередніх помилок.
У статті це квантується на ALFWorld:
- за допомогою ReAct 42,86% траєкторій містили галюциновані дії
- за допомогою ATG цей показник знизився до 12,14%
Це відносне зменшення приблизно на 72%, досягнуте без зміни основної моделі.
Що показують тестові сценарії
Для оцінки використовувалися три відкриті моделі:
- Mistral 7B
- Gemma 7B
- Llama 3 8B
та три критерії оцінки агентів:
- ALFWorld
- WebShop
- ScienceWorld
У основному порівнянні Llama 3 8B з ATG протиставляється GPT-4 з ReAct. У ALFWorld базова версія GPT-4 набрала:
GPT-4 + ReAct
41.24
тоді як невелика модель з ATG набрала:
Llama 3 8B + ATG
63.65
У WebShop базова версія GPT-4 досягла:
GPT-4 + ReAct
64.34
а Llama 3 8B з ATG —:
Llama 3 8B + ATG
68.36
Це цифри, наведені у статті. Показники GPT-4 стосуються базової версії з ReAct, тож порівняння показує, наскільки структура може компенсувати розмір моделі, а не те, що 8B-модель загалом сильніша за GPT-4.
Чому ця ідея сподобалась інженерам програмного забезпечення
Стандартною стратегією галузі було масштабування моделей, кластерів та бюджетів. ATG запитує, як краще організувати роботу, що є скоріше питанням інженерії програмного забезпечення, ніж машинного навчання. Це пов’язано з Git, графами залежностей, системами компіляції, планувальниками завдань, оптимізацією компіляторів та розподіленими системами. Більшість програмного забезпечення вже давно перестало бути суто послідовним; агенти наздоганяють цей рівень.
Конкретний приклад: створення веб-сайту
Якщо попросити агента створити веб-сайт, лінійний агент, як правило, створює план наступного типу:
Think
↓
Write HTML
↓
Write CSS
↓
Write JavaScript
↓
Debug
↓
Deploy
Планувальник у стилі ATG, натомість, може створити дерево окремих елементів:
Website
│
├── HTML
├── CSS
├── Images
├── API
└── Tests
Кожну гілку можна розробляти окремо. Якщо CSS пошкоджується, генерується лише відповідний CSS-вузол. Це здається очевидним, проте більшість сучасних агентів не працюють у такий спосіб. Схожі захисні патерни розглядаються у архітектурі проти посилення галюцинацій у графах агентів.
Коли граф завдань не є доцільним
Планування, симуляція та ведення обліку вузлів додають додатковий тягар. Для завдань, що вимагають двох-трьох викликів інструментів, простий цикл ReAct є більш простим рішенням. Граф стає корисним, коли завдання є довгими, частково незалежними та дорогими у перезапуску, і лише за умови розумного розбиття на складові з боку планувальника: поганий граф, виконаний ефективно, все одно залишається поганим планом.
Основні висновки
- Лінійні цикли дозволяють одному невдачному кроку пошкодити все, що йде далі, а зростаючі об’єми даних посилюють ранні помилки.