Projektowanie odpornych grafów agentów AI: ponawianie prób, rozwiązania awaryjne i GraphRAG

Gdy występują awarie: planowanie alternatywnych ścieżek

Kontynuując poprzednią dyskusję, wyobraźmy sobie, że do tego momentu agent zajmujący się badaniami finansowymi stał się znacznie bardziej zaawansowany.

Pamiętajmy o przykładowym pytaniu, jakie może zadać menedżer portfela – na przykład dlaczego określone akcje spadły po publikacji raportu z wyników, oraz jakie ryzyka wymagają dalszej uwagi. System ten potrafi rozłożyć takie pytanie na części, pobrać dane z różnych źródeł, przeprowadzić analizę wyników, przygotować odpowiedź, ją zweryfikować i w razie potrzeby przekazać ją ludzkiemu recenzentowi – w istocie funkcjonuje według modelu z udziałem człowieka.

Jest jednak jedna kwestia, której do tej pory nie poruszyliśmy: co się dzieje, gdy jakiś etap tego procesu zawodzi?

Wyobraźmy sobie, że system dociera do gałęzi odpowiedzialnej za dane rynkowe.

Wysyła prośbę o informacje o zmianach cen i wolumenie transakcji, ale dostawca danych nie odpowiada.

W takiej sytuacji przejście bezpośrednio do kroku Analyze, jakby nic się nie stało, nie jest możliwe.

Jednocześnie natychmiastowe zatrzymanie całego procesu jest zazwyczaj zbyt radykalne, ponieważ systemy produkcyjne wymagają jakiejś formy zachowania awaryjnego.

Dlatego właśnie niepowodzenie powinno być traktowane jako oddzielna gałąź w grafie, a nie jako kwestia drugorzędna.

Pierwotny, prosty przepływ wygląda tak:

Search Market Data
        ↓
     Analyze

Możemy go zamiast tego przekształcić w coś takiego:

                  Search Market Data
                    /          \
                   ↓            ↓
               Success        Failure
                  ↓              ↓
               Analyze          Retry (how to handle this!?)

Dzięki tej strukturze graf zawiera wyraźną instrukcję dotyczącą dalszych działań w przypadku niepowodzenia prośby.

Zarządzanie logiką ponawiania prób

Jeśli ponowna próba się powiedzie, proces pracuje dalej normalnie.

Jeśli jednak ponownie się to nie uda, może mieć sens przejść na inny źródło danych lub przekazać sprawę do ludzkiej oceny, zamiast wielokrotnie wysyłać tę samą prośbę.

Oto bardziej szczegółowa wersja tego rozgałęzienia:

                  Search Market Data
                    /          \
                   ↓            ↓
               Success        Failure
                  ↓              ↓
               Analyze         Retry
                                  ↓
                           ┌──────┴──────┐
                           ↓             ↓
                        Success       Failure
                           ↓             ↓
                        Analyze    Alternative
                                      Source

Ważne tutaj nie jest to, ile prób ponawienia jest dozwolonych — lecz fakt, że zarządzanie awariami jest wbudowane w projekt grafu od samego początku. Jak pokazuje diagram, różne rodzaje awarii mogą prowadzić na różne ścieżki.

Załóżmy, że API z danymi rynkowymi po prostu wygaśnie. Ponawianie prób jest rozsądne, ponieważ problem prawdopodobnie ma charakter tymczasowy.

Ale załóżmy, że prośba zostanie przetworzona prawidłowo, ale po prostu nie zwróci nic przydatnego dla danego okresu. Powtarzanie tej samej prośby nic nie da.

w takim przypadku lepszym rozwiązaniem jest zapytanie alternatywnego, zatwierdzonego źródła danych.

A jeśli i to nie da żadnego rezultatu, sytuacja ta prawdopodobnie wymaga przekazania jej do sprawdzenia przez człowieka. To właśnie takie szczegóły odróżniają niestabilny proces od niezawodnego.

Funkcja kierowania tym procesem może wyglądać następująco:

def route_after_market_search(state):
  if state["market_data"]:
          return "analyze"
      if state["retry_count"] < 2:
          return "retry"
      return "human_review"

Te warunki określają wyraźne granice dla grafu – można próbować ponownie, ale nie w nieskończoność.

To samo zasada obowiązuje w całym grafie, ponieważ wiele rzeczy może pójść nie tak po drodze:

• Krok pobierania danych może się nie udać
• Wywołanie LLM może się nie udać
• Dany źródło może być tymczasowo niedostępne
• Wygenerowana odpowiedź może nie przejść sprawdzenia walidacji

Zamiast otaczać całe aplikacje jednym ogromnym obsługownikiem błędów, można decydować, węzeł po węźle, co powinno się stać dokładnie w momencie wystąpienia problemu.

To jest jeden z powodów, dla których modelowanie przepływu pracy jako grafu jest atrakcyjne. Gdy wystąpi błąd, nie musisz zadawać ogólnikowych pytań typu „dlaczego agent zawiodł?”

Zamiast tego możesz prześledzić dokładną ścieżkę, którą obrał proces, i precyzyjnie określić, gdzie doszło do błędu:

Understand
    ↓
Search Filings ✓
    ↓
Search Earnings ✓
    ↓
Search Market Data ✗
    ↓
Retry ✓
    ↓
Analyze
    ↓
Write
    ↓
Check

Dzięki temu masz coś konkretnego do zbadania, a nie tylko „czarną skrzynkę”.

Oczywiście, w miarę rozszerzania się grafu ręczne zarządzanie tym wszystkim wymaga coraz większego wysiłku — i to uzasadniona obawa.

W takiej sytuacji musisz radzić sobie z logiką wykonywania, zarządzaniem stanem, warunkowym kierowaniem przepływu, obsługą ponownych prób, przechowywaniem danych oraz sposobem na sprawdzenie tego, co faktycznie wydarzyło się podczas danej rundy.

To właśnie w takich sytuacjach framework pomaga uniknąć konieczności ponownego tworzenia tej samej infrastruktury orkiestracji w każdym projekcie.

To właśnie tę lukę ma za zadanie wypełnić LangGraph.

LangGraph

Dzięki dostępowi do takiego frameworka proces pracy może być podzielony na oddzielne zadania badawcze, a wyniki połączone później; możliwe jest również ponowne wykonanie nieudanych kroków, pauzowanie w celu uzyskania opinii człowieka oraz śledzenie stanu podczas przechodzenia z jednego etapu na drugi.

Oczywiście sformułowanie tego grafu i jego faktyczne uruchomienie nadal wymagają pracy.

Moglibyście sami zająć się całym procesem orkiestracji, ale oznaczałoby to konieczność utrzymywania znacznej ilości infrastruktury wokół waszej podstawowej logiki AI.

LangGraph został zaprojektowany właśnie do obsługi tej warstwy.

LangGraph to framework stworzony do budowania procesów pracy agentów opartych na grafach i posiadających stan. Zamiast traktować agenta jako pojedynczy cykl, który ciągle pyta model językowy, co robić dalej, można wyraźnie zdefiniować węzły, przejścia między nimi, wspólny stan oraz ogólny tok wykonywania zadań.

Wracając do wcześniej omawianego agenta badawczego NVIDIA, jego strukturę można nakreślić w ten sposób:

                      Question
                         ↓
                    Understand
                         ↓
              ┌──────────┼──────────┐
              ↓          ↓          ↓
           Filings    Earnings    Market
              ↓          ↓          ↓
              └──────────┼──────────┘
                         ↓
                      Analyze
                         ↓
                       Write
                         ↓
                       Check
                    ↙    ↓    ↘
                Search  Rewrite  Human
                   ↓       ↓     Review
                   └───────┴───────┘
                           ↓
                          Send

Warto zauważyć, że struktura grafu oraz rzeczywista logika aplikacji mogą współistnieć w tej samej bazie kodu.

Zredukowana implementacja LangGraph tego samego procesu może wyglądać tak:

from langgraph.graph import StateGraph, END

builder = StateGraph(ResearchState)

builder.add_node("understand", understand)
builder.add_node("search_filings", search_filings)
builder.add_node("search_earnings", search_earnings)
builder.add_node("search_market", search_market)
builder.add_node("analyze", analyze)
builder.add_node("write", write)
builder.add_node("check", check)

builder.set_entry_point("understand")

builder.add_edge("understand", "search_filings")
builder.add_edge("understand", "search_earnings")
builder.add_edge("understand", "search_market")
builder.add_edge("analyze", "write")
builder.add_edge("write", "check")

Powyższy fragment jest celowo minimalny, aby można było skupić się na podstawowym modelu myślowym – łączeniu w całość węzłów, krawędzi oraz pojęć stanu przedstawionych wcześniej w tej serii.

• Każdy węzeł obsługuje jedną jednostkę pracy
• Graf określa, w jaki sposób te jednostki są ze sobą połączone
• Stan to to, co przekazuje informacje z jednego węzła do drugiego

To naprawdę wszystko. Ten model myślowy jest o wiele łatwiejszy do zrozumienia niż próba umieszczenia wszystkiego w jednym ogromnym poleceniu dla agenta.

Możesz spojrzeć na sam wykres i zrozumieć, co powinien robić proces pracy, zanim w ogóle zagłębisz się w to, jak implementowany jest każdy pojedynczy węzeł.

Załóżmy, że chciałbyś dodać krok zatwierdzenia przez człowieka przed udostępnieniem ostatecznej odpowiedzi — wtedy musiałbyś bezpośrednio zmodyfikować strukturę procesu pracy:

Check
  ↓
Human Review
  ↓
Send

Nie ma potrzeby ukrywania takich decyzji gdzieś w instrukcjach. Sama struktura sprawia, że są one jawne i łatwe do zrozumienia dla twojego zespołu.

Dlaczego wybrać LangGraph zamiast zwykłego pętli agenta?

Konwencjonalna pętla agenta zazwyczaj ma taką strukturę:

Think
  ↓
Choose Tool
  ↓
Use Tool
  ↓
Think Again
  ↓
Choose Tool
  ↓
...

W tym ustawieniu model ma dużą swobodę w decydowaniu o dalszych krokach. Ta elastyczność jest naprawdę cenna, gdy zadanie ma z natury otwarty charakter.

Ale proces badawczy finansowy, taki jak opisany tutaj, obejmuje kilka punktów decyzyjnych, które najprawdopodobniej chcesz mieć pod ścisłą kontrolą. To właśnie ta różnica stanowi sedno sprawy.

Nie każdy proces wymaga pętli agenta.

Rozważmy kilka przykładów:

• Może być konieczne, aby system zebrał określone dowody przed tym, jak będzie mógł podać odpowiedź.
• Możesz chcieć, aby dane rynkowe oraz dokumenty były pobierane niezależnie od siebie.
• Może być wymagany krok weryfikacji, zanim cokolwiek zostanie przekazane do ludzkiego recenzenta.
• Możesz chcieć, aby proces automatycznie się zatrzymał po określonej liczbie prób.

To nie są takie decyzje, które koniecznie powinny być pozostawione modelowi do improwizacji przy każdym uruchomieniu. Wewnątrz pętli nie ma sposobu, aby zagwarantować, że model za każdym razem wykona tę samą operację.

Graf umożliwia bezpośrednie włączenie tych ograniczeń do struktury procesu pracy. Model nadal może przeprowadzać rozumowanie w obrębie poszczególnych węzłów, ale otaczający go system określa, dokąd może przejść dalej.

To jest kluczowa różnica, którą należy pamiętać. Celem nie jest usunięcie zdolności do rozumowania z agenta — chodzi o celowe ustalenie, gdzie to rozumowanie powinno się znajdować, a gdzie lepsza jest deterministyczna orkiestracja.

Gdy nadal budujesz procesy pracy pracujące z ustrukturyzowanymi danymi finansowymi, pojawia się nowe pytanie.

Obecnie nasz agent pobiera dokumenty i dane z różnych źródeł. Ale co się stanie, gdy zawarte w tych informacjach powiązania będą rzeczywiście istotne?

• Firmy zatrudniają kierowników
• Ci kierownicy często zasiadają w radach nadzorczych spółek
• Jedna firma może przejąć inną

W dokumencie regulacyjnym może być wymieniona zupełnie inna firma

Jedno portfolio może zawierać wiele firm

Każda firma należy do jakiegoś sektora przemysłowego

To prowadzi nas do kolejnej kluczowej koncepcji: GraphRAG.

GraphRAG

sposobu zachowania agenta. Ale grafy mogą pełnić także drugą funkcję:

organizowanie samej wiedzy.

W naszym przykładzie konwencjonalne rozwiązanie RAG mogłoby pobrać dokumenty wspominające o wynikach finansowych NVIDIA, prognozach na przyszłość, kwotach przychodów, marżach oraz reakcji rynku.

Taki podejście sprawdza się dobrze, gdy odpowiedź znajduje się głównie w kilku istotnych dokumentach. Jednak kwestie finansowe nie zawsze są w takim ograniczonym zakresie.

Przekonująca odpowiedź często zależy od łączenia informacji rozproszonych w kilku oddzielnych dokumentach.

Załóżmy teraz, że chcemy zrozumieć nie tylko to, co zgłosiła NVIDIA, ale także jak poszczególne elementy tego raportu są ze sobą powiązane (co jest dokładnie sytuacją, z którą mamy do czynienia).

Dokładnie w takich przypadkach graf wiedzy okazuje się nieoceniony.

Zamiast przechowywać wiedzę wyłącznie jako fragmenty tekstu, możemy sformalizować ważne entytety oraz relacje pomiędzy nimi:

NVIDIA ──→ produces ──→ GPUs
   │
   ├──→ reports ──→ Earnings
   │
   ├──→ depends on ──→ Suppliers
   │
   ├──→ competes with ──→ AMD
   │
   └──→ operates in ──→ AI Infrastructure

Graph teraz uwzględnia powiązania, które nigdy nie ujawniłyby się przy czytaniu pojedynczego dokumentu osobno.

RAG w porównaniu z GraphRAG

Standardowy RAG zazwyczaj działa poprzez pobieranie istotnych fragmentów tekstu i podawanie ich modelowi jako kontekst. Oto uproszczony opis tego procesu:

Question
   ↓
Retrieve relevant chunks
   ↓
LLM
   ↓
Answer

GraphRAG wprowadza dodatkową warstwę. System może korzystać z relacji pomiędzy elementami, aby określić, które informacje są naprawdę ważne:

Question
   ↓
Identify entities
   ↓
Traverse relationships
   ↓
Retrieve relevant information
   ↓
LLM
   ↓
Answer

Dla naszego agenta do badań finansowych jest to przydatne wtedy, gdy pytanie wymaga połączenia kilku elementów lub dokumentów jednocześnie.

Załóżmy, że menedżer portfela pyta: jakie ryzyka mogą dotknąć NVIDIA, jeśli popyt na infrastrukturę AI spadnie?

Aby dobrze odpowiedzieć na to pytanie, konieczne może być powiązanie NVIDIA z jej produktami, klientami, dostawcami, konkurentami, ogólnymi warunkami rynkowymi oraz ryzykami, które zostały już wskazane w wcześniejszych raportach.

Graf zapewnia systemowi wyszukiwania ustrukturyzowaną ścieżkę do badania wszystkich tych powiązań.

                      NVIDIA
                    /   |   \
                   /    |    \
              Products Suppliers Competitors
                 |         |         |
                 ↓         ↓         ↓
             AI GPUs   Supply Risk    AMD
                 |
                 ↓
          AI Infrastructure
                 |
                 ↓
               Demand

Stamtąd model może analizować wszystko, co pochodzi z tych powiązanych entytetów.

To nie oznacza, że GraphRAG zawsze przewyższa zwykły RAG. Dodatkowa struktura okazuje się przydatna szczególnie wtedy, gdy relacje pomiędzy elementami informacji są kluczowe dla zadawanej pytania.

Jeśli odpowiedź znajduje się w jednym raporcie finansowym, konwencjonalny proces wyszukiwania prawdopodobnie wystarczy.

Jeśli odpowiedź na pytanie wymaga zebrania informacji rozproszonych w wielu entytetach i źródłach, rozwiązanie oparte na grafie wydaje się znacznie bardziej atrakcyjne.

Istnieje jeszcze jedna różnica, którą warto mieć na uwadze: graf przepływu pracy oraz graf wiedzy to dwie zupełnie różne rzeczy.

Graf przepływu pracy odpowiada na pytanie, co agent powinien zrobić dalej. Graf wiedzy odpowiada na pytanie, co jest powiązane z czym w danych, nad którymi pracujesz.

W naszym systemie oba mogą istnieć obok siebie:

WORKFLOW GRAPH:

Question
   ↓
Retrieve
   ↓
Analyze
   ↓
Write
   ↓
Check

Podczas gdy na poziomie niżej warstwa pozyskiwania danych działa na podstawie:

KNOWLEDGE GRAPH:
NVIDIA
 ├── Products
 ├── Suppliers
 ├── Competitors
 ├── Executives
 ├── Filings
 └── Industry

Zwróć uwagę na podział obowiązków: jedna struktura zarządza wykonywaniem zadań, natomiast druga organizuje wiedzę oraz relacje pomiędzy nią.

Gdy te dwa elementy zaczną się wzajemnie uzupełniać, agent do badań finansowych staje się znacznie bardziej skuteczny.

• Przepływ pracy określa sposób przeprowadzania badań.
• Graf wiedzy określa kterze informacje są ze sobą powiązane.

Oczywiście to rodzi kolejne pytanie: jeśli grafy dają tak wielką kontrolę, czy każdy proces powinien być budowany w ten sposób?

Niekoniecznie.

W wielu przypadkach wystarczy prosty cykl agenta, aby rozwiązać problem.

Dlatego zamiast domyślnie przekształcać każdy proces AI w graf, warto bezpośrednio porównać obie metody i ustalić kiedy dodana złożoność projektowania grafów rzeczywiście się opłaca.

Należy pamiętać, że grafy dają większą kontrolę, ale ta kontrola idzie w parze z dodatkową pracą – musisz samodzielnie projektować i utrzymywać tę strukturę.

Jeśli podstawowe zadanie jest naprawdę proste, umieszczenie go w grafie może sprawić, że system stanie się trudniejszy do zrozumienia, bez większych korzyści.

streszcz najnowszy raport finansowy NVIDIA.

To jest konkretne i samodzielne żądanie.

Można je obsłużyć, pobierając odpowiedni raport i przekazując go modelowi w celu stworzenia streszczenia:

Question
   ↓
Retrieve Report
   ↓
Summarize
   ↓
Answer

Nie ma tu żadnego skomplikowanego rozgałęziania ani trudnej logiki do zarządzania. Zwykły pipeline RAG lub prosta pętla agenta doskonale sobie z tym poradzi.

Porównajmy to teraz z szerszym zapytaniem, w którym użytkownik chce zrozumieć, co spowodowało spadek ceny akcji po publikacji wyników, chce porównać ten efekt z prognozami analityków, chce listę ryzyk wymagających monitorowania w przyszłości oraz chce mieć możliwość zatwierdzenia ustaleń przed włączeniem ich do raportu portfelowego.

To zupełnie inny rodzaj problemu.

Ta wersja obejmuje kilka rodzajów badań, czerpie z różnych źródeł, wymaga weryfikacji, może wymagać kilku prób oraz zawiera etap przeglądu przez człowieka.

Proces pracy wygląda teraz mniej więcej tak:

                      Question
                         ↓
                    Understand
                         ↓
              ┌──────────┼──────────┐
              ↓          ↓          ↓
           Filings    Earnings    Market
              ↓          ↓          ↓
              └──────────┼──────────┘
                         ↓
                      Analyze
                         ↓
                       Write
                         ↓
                       Check
                    ↙    ↓    ↘
                Search  Rewrite  Human
                   ↓       ↓     Review
                   └───────┴──────┘
                           ↓
                          Send

Na tym poziomie złożoności wyraźne opisanie procesu pracy zaczyna przynosić korzyści.

Kiedy więc wystarcza pętla agenta?

Pętla agenta jest zazwyczaj odpowiednim rozwiązaniem, gdy model może korzystać z pewnej swobody w wyborze narzędzia do użycia dalej.

Naprzимер:

Question
   ↓
LLM decides what to do
   ↓
Tool
   ↓
LLM decides what to do next
   ↓
Tool
   ↓
Answer

Gdy zadanie ma charakter eksploracyjny i nie można z góry przewidzieć LICZBY KROKÓW, taka elastyczność jest naprawdę cenna.

Agent może zdecydować, że musi sprawdzić wykaz dochodów, następnie pobrać konkretną miarę, a potem poszukać dodatkowego kontekstu. Nie musisz z góry planować każdej możliwej ścieżki.

Kiedy wykres zaczyna mieć sens?

Wykres staje się przydatny, gdy proces pracy ma reguły, które faktycznie mają znaczenie.

Dla systemu badawczego finansowego te reguły mogą wyglądać tak:

Retrieve evidence
      ↓
Run analysis
      ↓
Generate draft
      ↓
Verify claims
      ↓
Human review
      ↓
Publish

Są to ograniczenia na poziomie procesu pracy, a wykres umożliwia ich bezpośrednie zaprogramowanie zamiast liczenia na to, że model sam je wywnioskuje.

Kompromis

Wykres daje kontrolę, ale oznacza to również konieczność zajmowania się większą architekturą.

Teraz musisz przemyśleć:

• sposób strukturyzowania stanu
• logikę routingu
• to, co się dzieje, gdy coś zawodzi
• behawior ponawiania prób
• persistence

obserwowalność

testowanie

wersjonowanie

Żadna z tych rzeczy sama w sobie nie jest zła — oznacza to po prostu, że graf musi uzasadnić dodatkowy nakład pracy, jaki wprowadza.

Dla agenta badawczego NVIDIA nie miałoby sensu budować od razu całego grafu tylko dlatego, że grafy są interesujące.

Zamiast tego dodatkowa struktura powinna być wprowadzana tylko wtedy, gdy workflow faktycznie tego wymaga:

• Zacznij od prostoty.
• Dodaj rozgałęzienia dopiero wtedy, gdy są one rzeczywiście konieczne.
• Dodaj równoległą eksploatację, gdy zadania mogą faktycznie działać niezależnie od siebie.
• Dodaj punkty kontrolne, gdy workflow musi się zatrzymać lub odzyskać po przerwie.
• Dodaj etap przeglądu przez człowieka, gdy ryzyko uzasadnia dodatkowe komplikacje.
• Wprowadź GraphRAG, gdy relacje wewnątrz samej wiedzy zaczną mieć znaczenie.

W ten sposób graf istnieje, ponieważ wymaga tego problem, a nie dlatego, że jest dostępny.

Ostateczne refleksje

To prawdopodobnie najważniejsza lekcja wynikająca z prace nad tym projektem.

Graph nie służy temu, by system AI wyglądał skomplikowanie. Istnieje po to, aby ułatwić rozumienie i kontrolę procesu pracy.

Agent do badań finansowych stworzony na podstawie tej dyskusji może teraz rozwijać różne ścieżki, próbować ponownie, wstrzymywać się, angażować ludzkiego recenzenta oraz korzystać z powiązań między poszczególnymi elementami wiedzy, gdy jest to przydatne.

Mimo to nic z tego nie oznacza, że każdy system potrzebuje grafu. Czasami wystarczy zwykły pipeline RAG – to właściwa ilość narzędzi. Czasami pętla agenta obejmuje wszystko, czego wymaga problem.

Prawdziwą umiejętnością jest rozpoznawanie momentu, w którym problem staje się na tyle skomplikowany, że wykres zasługuje na taką inwestycję.