Atomowe grafy zadań: planowanie pracy agenta jako graf zależności

Większość prób zwiększenia niezawodności agentów opartych na LLM zaczyna się od użycia większego modelu. Framework Atomic Task Graph (ATG), zaproponowany przez badaczy z Uniwersytetu Tsinghua i Południowego Uniwersytetu Technologicznego w Chinach, podchodzi do tego inaczej: zmienia sposób, w jaki agent organizuje swoją pracę. Zgodnie z artykułem, modele otwartej kodu o pojemności 7B i 8B, opakowane w ATG, przewyższyły GPT-4 działający według standardowego schematu ReAct w dwóch dobrze znanych testach agentów, przy czym nie było żadnej drobnej kalibracji, uczenia wzmacniającego ani aktualizacji wag. Poniżej wyjaśniono, dlaczego łańcuchy rozumowania liniowego zawodzą, jak ATG zastępuje je grafem zależności oraz jakie pomysły można przejąć do własnych agentów.

Dlaczego liniowe pętle agentów zawodzą przy długich zadaniach

Rozważmy prośbę typu „przygotuj raport sprzedaży za rok 2024 z wykresami”. Typowy agent w stylu ReAct traktuje to jako jedną długą sekwencję kroków, z których każdy zależy od poprzedniego.

Step 1
↓
Find database
↓
Query data
↓
Analyze numbers
↓
Create graphs
↓
Write report

Łańcuch działa poprawnie, dopóki każdy krok się udaje. Problemy pojawiają się, gdy któryś z nich zawodzi. Jeśli zapytanie do bazy danych nie powiedzie się, wszystkie kolejne kroki opierają się już na brakujących lub błędnych danych.

Database query
↓
Everything after it becomes wrong

W takiej sytuacji agent może albo rozpocząć od nowa, albo kontynuować pracę na podstawie tego, co ma. Wielu wybiera drugą opcję, co stanowi główne źródło halucynacji: model wymyśla wiarygodne dane, aby wypełnić lukę, a każda późniejsza decyzja odziedzicza ten błąd.

Kontekst stale się powiększa

Drugim problemem jest to, jak te agenty przechowują stan. Po każdej akcji myśl, wywołanie narzędzia oraz obserwacja są dodawane do coraz dłuższego zapisu transkrypcji.

User
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action

W końcu model analizuje strony historii. Kontekst staje się zbyt złożony, a wczesne błędy pozostają widoczne, więc nadal wpływają na późniejsze decyzje. Podobnie jak w grze telefonicznej, z każdym rundą plan jest nieco zniekształcany, aż odbiega od rzeczywistości.

Główna idea: graf zamiast łańcucha

ATG zastępuje pojedynczą sekwencję grafem zadań. Każdy węzeł reprezentuje jedną jednostkę pracy, a każda krawędź odnotowuje zależność pomiędzy dwiema jednostkami.

Report
            /      \
      Analysis    Charts
       /     \
 Database   Statistics

Taka struktura sprawia, że niezależność jest widoczna: zadania niespowiązane już się nie czekają, a błąd w jednej gałęzi nie unieważnia pozostałych.

Jak ATG buduje i uruchamia graf

Framework działa w pięciu etapach.

1. Recyrtyczna dekompozycja na zadania atomowe

Wszystko zaczyna się od żądania użytkownika.

Create sales report

ATG dzieli to zadanie na podzadania.

Create sales report
↓
Load data
↓
Analyze sales
↓
Create charts
↓
Write summary

Następnie kontynuuje dzielenie każdego zadań podrzędnych, które są nadal zbyt szerokie, takich jak krok analizy.

Analyze sales
↓
Revenue
↓
Profit
↓
Growth
↓
Regional trends

Rozbicie ustaje, gdy każdy węzeł liściowy odpowiada pojedynczej wywołaniu narzędzia, na przykład:

SQL query
Python calculation
Matplotlib chart
Markdown writer

Tymi węzłami liściowymi są zadania atomowe: tak małe, że dalsze ich dzielenie nie miałoby sensu. Zasada zatrzymania jest ważna – niejasny węzeł pozostawia zbyt dużo swobody do improwizacji, podczas gdy jedno zapytanie SQL ma precyzyjny, sprawdzalny wynik.

2. Wyraźne dane wejściowe i wyjściowe dla każdego węzła

Każdemu węzłowi przypisuje się interfejs, podobny do sygnatury funkcji. Zamiast instrukcji typu „przeprowadź analizę”, planer opisuje, co węzeł pobiera i co wytwarza.

def analyze_sales(data):
    return summary

Ten fragment ma charakter ilustracyjny, a nie jest kodem frameworku, ale pokazuje umowę między elementami. Ponieważ graf zależy wyłącznie od tej umowy, węzeł można spróbować ponownie lub zastąpić innym narzędziem, bez żeby jego sąsiedzi to zauważyli – to właśnie ta cecha sprawia, że kod modularny jest łatwy w utrzymaniu.

3. Równoległe wykonywanie niezależnych gałęzi

Agent sekwencyjny wykonywać będzie zadania jeden po drugim, nawet jeśli niektóre z nich są ze sobą niespowiązane.

Task A
↓
Task B
↓
Task C

Jeśli B i C potrzebują tylko wyniku A, a nie wyników siebie nawzajem, ATG może to bezpośrednio wyrazić.

Task A
       /     \
 Task B     Task C
       \     /
       Task D

B i C mogą wtedy działać jednocześnie, podczas gdy D czeka na oba. W artykule opisano znacznie krótsze ścieżki wykonywania we wszystkich przeprowadzonych testach, co jest naturalnym skutkiem łączenia niezależnych kroków w równoległe.

4. Próba przed użyciem rzeczywistych narzędzi

Zanim cokolwiek zostanie wykonywane, ATG symuluje wewnętrznie cały plan, pytając w zasadzie model, czy plan zadziałałby, gdyby został zrealizowany zgodnie z opisem. Symulacja szuka:

• kroków, które brakuje
• niewłaściwego narzędzia przypisanego do węzła
• błędnych zależności pomiędzy węzłami
• niespójności interfejsowych, gdy wyjście jednego węzła nie pasuje do wejścia następnego
• ścieżek wykonywania, które faktycznie nie mogą zostać ukończone
• naruszeń ograniczeń zadania

Jest to odpowiednik w świecie agentów wykonywania testów przed wdrożeniem i jest tani, ponieważ nie wykorzystuje żadnych zewnętrznych narzędzi. Sprawdzenie jest jednak tak dobre, jak model, który je przeprowadza: model, który napisał plan, może mieć swoje słabe punkty, więc należy go traktować jako filtr, a nie gwarancję.

5. Celowe naprawianie uszkodzonego podgrafu

Najbardziej charakterystycznym aspektem jest sposób, w jaki ATG radzi sobie z błędami podczas wykonywania. Weźmy prosty graf:

Database
↓
Analysis
↓
Charts
↓
Report

Załóżmy, że węzeł analityczny zawodzi. Tradycyjny agent zazwyczaj reaguje poprzez odrzucenie swoich postępów i rozpoczęcie pracy od nowa.

Database
↓
Analysis
↓
Charts
↓
Report
↓
Start over

ATG natomiast zachowuje ten sam graf i zamyka w lodzie wszystkie węzły, które już dostarczyły ważnego wyniku. Poniższy diagram jest celowo identyczny z oryginałem: struktura się nie zmienia, tylko węzeł analityczny jest oznaczony do ponownej obróbki, podczas gdy węzły bazy danych, wykresów i raportów pozostają bez zmian.

Database
↓
Analysis
↓
Charts
↓
Report

Regenerowany jest tylko nieudany podgraf, a gdy mu się uda, graf kontynuuje pracę z nowym wynikiem.

Database
↓
New Analysis
↓
Charts
↓
Report

To jest kompilacja stopniowa zastosowana do planowania. Należy pamiętać, że jeśli naprawiona analiza da inne wyniki, węzły poniżej w łańcuchu, które je wykorzystują, muszą zostać ponownie uruchomione; oszczędza się natomiast prace na wyższych poziomach i niepowiązane gałęzie.

Dlaczego mniejsze konteksty oznaczają mniej halucynacji

W pętli ReAct każdy krok ma dostęp do pełnej historii. W ATG każdy węzeł otrzymuje tylko dane wejściowe określone przez jego interfejs, dzięki czemu jest mniej szumów i mniej możliwości na przeniknięcie wcześniejszych błędów.

W artykule ilustruje się to na przykładzie ALFWorld:

• w przypadku ReAct 42,86% trajektorii zawierało halucynowane działania
• w przypadku ATG wartość ta spadła do 12,14%

To oznacza względne zmniejszenie o około 72%, osiągnięte bez modyfikacji samego modelu.

Co pokazują testy

W ocenie wykorzystano trzy otwarte modele:

• Mistral 7B
• Gemma 7B
• Llama 3 8B

i trzy benchmarki dla agentów:

• ALFWorld
• WebShop
• ScienceWorld

Główne porównanie zestawia Llama 3 8B z ATG przeciwko GPT-4 z ReAct. W ALFWorld bazowy model GPT-4 osiągnął:

GPT-4 + ReAct
41.24

natomiast mały model z ATG osiągnął:

Llama 3 8B + ATG
63.65

W WebShop bazowy model GPT-4 osiągnął:

GPT-4 + ReAct
64.34

a Llama 3 8B z ATG osiągnął:

Llama 3 8B + ATG
68.36

To są liczby podane w artykule naukowym. Wskaźniki GPT-4 odnoszą się do wersji z ReAct, więc porównanie pokazuje, jak duża struktura może skompensować rozmiar modelu, a nie to, że model 8B jest ogólnie silniejszy od GPT-4.

Dlaczego ta idea rezonuje z inżynierami oprogramowania

Standardową strategią w tej branży jest skalowanie modeli, klastrów i budżetów. ATG pyta natomiast, jak lepiej zorganizować pracę, co jest bardziej kwestią inżynierii oprogramowania niż uczenia maszynowego. Przypomina to Git, grafy zależności, systemy budowania, planery zadań, optymalizację kompilatorów oraz systemy rozproszone. Większość oprogramowania już dawno przestała być ściśle sekwencyjna; agenci nadążają za tym rozwojem.

Konkretny przykład: budowa strony internetowej

Gdy poprosimy agenta o stworzenie strony internetowej, agent liniowy zazwyczaj tworzy plan w takim wydaniu:

Think
↓
Write HTML
↓
Write CSS
↓
Write JavaScript
↓
Debug
↓
Deploy

Planer w stylu ATG może zamiast tego stworzyć drzewo niezależnych elementów:

Website
│
├── HTML
├── CSS
├── Images
├── API
└── Tests

Każdą gałąź można rozwijać oddzielnie. Jeśli CSS przestanie działać, regenerowany jest tylko węzeł CSS. Brzmi to oczywiste, ale większość agentów obecnie nie funkcjonuje w ten sposób. Powiązane wzorce obronne są omówione w architekturze przeciwko kumulacji halucynacji w grafach agentów.

Kiedy graf zadań nie jest opłacalny

Planowanie, symulacja oraz prowadzenie rejestru węzłów dodają nakładu pracy. Dla zadań wymagających dwóch lub trzech wywołań narzędzi prosty pętla ReAct jest prostszy w implementacji. Graf okazuje się przydatny, gdy zadania są długie, częściowo niezależne i kosztowne w ponownym uruchomieniu, oraz tylko wtedy, gdy planer rozkłada je w sensowny sposób: zły graf wykonywany efektywnie nadal stanowi zły plan.

Główne wnioski

• Pętle liniowe pozwalają na to, by jeden nieudany krok zepsuł wszystko, co następuje po nim, a rosnące zapisy transkrypcji powiększają wpływ wczesnych błędów.

Węzły atomowe z określonymi wejściami i wyjściami sprawiają, że plany są równoległe, poddawalne weryfikacji i możliwe do naprawy.

Próba bez użycia rzeczywistych narzędzi pozwala wykryć błędy strukturalne zanim zostaną one użyte; celowana naprawa unika konieczności całkowitego restartu.

Ograniczony kontekst na poziomie każdego węzła to najłatwiejszy do ponownego wykorzystania element, który przyczynia się do zmniejszenia ilości halucynacji.

Lepsza struktura procesu pracy stanowi dodatkowy czynnik obok rozmiaru modelu, często oferując korzyści przy niższych kosztach.