Grafy wiedzy dla sztucznej inteligencji agentowej: cztery wzorce wykraczające poza wektorowe RAG.
Wyszukiwanie wektorowe znajduje podobny tekst, a nie powiązane fakty. Cztery wzorce grafowe dla agentów: ugruntowane sterowanie, planowanie, weryfikacja wykonania oraz samokorekcja.
Źródła: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
Większość zespołów tworzących systemy AI napotyka ten sam problem. Wdraża się bazę danych wektorowych, dokumenty są dzielone na fragmenty, podłącza się model językowy, a całość nazywa się pipeline’em RAG. Działa to dobrze, dopóki użytkownik nie zada pytania wymagającego połączenia trzech faktów z różnych domen danych. Wtedy system albo wymyśla odpowiedź brzmiącą przekonująco, albo zwraca coś technicznie poprawnego, ale bezużytecznego w danym kontekście.
Zazwyczaj winą nie jest model językowy – winna jest warstwa wyszukiwania. Wyszukiwanie podobieństwa wektorowego polega w istocie na znajdowaniu fragmentów tekstu o podobnym brzmieniu, więc znajduje teksty semantycznie bliskie, ale pomija fakty powiązane przyczynowo lub relacyjnie. Dla agenta, który musi rozumować krok po kroku, podejmować działania i łączyć decyzje, ta ograniczenie się pogłębia. Jedna zła odpowiedź prowadzi do błędów, które gromadzą się w całym łańcuchu rozumowania.
Argument, który warto potraktować poważnie, brzmi tak: graf wiedzy to nie tylko bardziej zaawansowany mechanizm wyszukiwania. To strukturalna podstawa, która umożliwia agentowi rozumowanie, a nie tylko wyszukiwanie informacji.
Główna idea
Sztuczną inteligencję opartą na agentach często traktuje się jako modny termin – dodaje się kilka wywołań narzędzi wokół modelu LLM i ogłasza zwycięstwo. Bardziej zdyscyplinowany podejście polega na projektowaniu warstwy wiedzy specjalnie do rozumowania wieloetapowego, a nie do odpowiadania na pytania w pojedynczym kroku.
Przejście od prostego modelu wyszukiwania do zstrukturyzowanego grafu, w którym entity, relacje i kontekst mają pierwszorzędne znaczenie. Graf nie tylko rejestruje, że produkt X ma wadę – rejestruje również, że produkt X jest wytwarzany przez dostawcę Y, wysyłany do regionu Z i objęty ramami zgodności W. Agent przeszukujący ten graf może podążać tymi powiązaniami i odkrywać informacje, których nigdy nie udałoby się uzyskać przy użyciu zwykłego wyszukiwania wektorowego.
Żadna z tych koncepcji nie jest nowością w teorii baz danych. Ich ścisłe zastosowanie w systemach agentowych stanowi element nowy, a czas ich pojawienia się jest uzasadniony. Pipeline’y agentów rozwinęły się na tyle, dzięki lepszemu rozumowaniu opartemu na modelach językowych, udoskonalonym interfejsom API do wywoływania narzędzi oraz bardziej zaawansowanym frameworkom orkiestracji, że warstwa wiedzy staje się teraz wąskim gardłem. Nawet doskonała architektura agenta wytwarza błędne wyniki, gdy podstawowa reprezentacja wiedzy jest prostsza i niespójna.
Metoda ta dzieli się na cztery wzorce architektoniczne, z których każdy odpowiada innemu etapowi życiowemu agenta: ugruntowanie, planowanie, wykonywanie i samokorekta. Razem tworzą one plan działania dla systemów produkcyjnych, a nie tylko ćwiczenie teoretyczne.
Dlaczego to ma znaczenie
Produkcja RAG jest zazwyczaj krucha, a jej awarie trudne do wyśledzenia. Po słabej odpowiedzi przyczyna pozostaje ukryta: słabe wyszukiwanie, błędna granica fragmentu lub model sprzeczny z danym mu kontekstem. W przypadku prostego wyszukiwania wektorowego pozostaje tylko domysł. Włączenie grafu wiedzy sprawia, że wyjaśnialność pojawia się niemal bezkosztowo, ponieważ ścieżka przemieszczania się po grafie stanowi ślad rozumowania.
Ma to ogromne znaczenie w sektorach regulowanych. Ochrona zdrowia, finanse i technologie prawnicze wymagają sztucznej inteligencji, która potrafi pokazać, jak pracuje. System, który informuje o trzech węzłach grafu i dwóch krokach relacyjnych leżących u podstaw odpowiedzi, może być sprawdzany, natomiast ten, który podaje tylko wynik kosinusowy typu top-k, nie może. Dla zespołów rozwijających sztuczną inteligencję w środowisku surowych wymogów regulacyjnych to różnica między rozwiązaniem gotowym do wdrożenia a tylko koncepcją, która nigdy nie opuszcza laboratorium.
Istnieje również kwestia niezawodności. Systemy agentowe zawodzą w sposób łańcuchowy – jedna zła decyzja na wczesnym etapie może zaszkodzić całej kolejności działań. Graf pełni rolę strukturalnej ochrony: agenci mogą sprawdzać pośrednie wnioski w jego oparciu przed kontynuacją i wcześnie wykrywać odchylenia. Przypomina to narzędzie weryfikacji faktów wbudowane w pętlę rozumowania, a nie takie dodane na końcu.
Być może najmniej docenianą zaletą jest aktualizacja wiedzy bez konieczności ponownego szkolenia. Przy użyciu embeddingów dodawanie faktów często oznacza ponowne włączenie dużych fragmentów danych, co może zakłócić istniejące zachowania wyszukiwania. Z grafem natomiast dodaje się węzły i krawędzie, a rozumowanie agenta natychmiast je odzwierciedla. W szybko zmieniających się dziedzinach, takich jak rynki finansowe, badania medyczne czy rozwijające się ekosystemy oprogramowania, stanowi to prawdziwą przewagę operacyjną.
Cztery wzorce w praktyce
1. Prompting oparty na wiedzy
Pierwszy wzorzec umacnia początkowy kontekst agenta w strukturalnych faktach, a nie w wynikach niejasnego porównywania podobieństwa. Zamiast wyszukiwać fragmenty, które wydają się podobne, należy zapytać graf o podgraf istotny dla intencji użytkownika i włączyć ten strukturalny kontekst do promptu.
from neo4j import GraphDatabase
import json
def get_grounded_context(user_query: str, entity_extractor, driver) -> str:
# Step 1: Extract entities from the user query
entities = entity_extractor(user_query) # e.g., ["Product X", "Supplier Y"]
# Step 2: Pull a relevant subgraph from Neo4j
with driver.session() as session:
result = session.run(
"""
MATCH (e)-[r]-(connected)
WHERE e.name IN $entities
RETURN e.name AS entity,
type(r) AS relationship,
connected.name AS related_entity,
connected.attributes AS attributes
LIMIT 50
""",
entities=entities
)
subgraph = [record.data() for record in result]
# Step 3: Format subgraph as structured context
context_str = json.dumps(subgraph, indent=2)
grounded_prompt = f"""
You are a reasoning agent. Use ONLY the following structured knowledge to answer.
If the answer isn't derivable from this context, say so explicitly.
KNOWLEDGE GRAPH CONTEXT:
{context_str}
USER QUERY: {user_query}
"""
return grounded_prompt
Spójrz, co się tutaj dzieje. Agent nie szuka dokumentów, które brzmią jak pytanie. Wyodrębnia konkretne entity, pobiera ich otoczenie relacyjne i wprowadza je jako ustrukturyzowany kontekst. To, co otrzymuje LLM, to mapa, podczas gdy wcześniej miało do czynienia z serią akapitów, które były ze sobą tylko luźno powiązane.
2. Planowanie kierowane grafem
Drugi wzorzec dotyczy planowania wieloetapowego. Agenci dzielą złożone cele na wykonalne kroki, a te kroki powinny opierać się na tym, co jest faktycznie możliwe przy obecnym stanie wiedzy. Graf sprawia, że planowanie staje się znacznie mniej swobodne.
Porównaj planowanie podróży samochodowej bez mapy i z mapą. Bez niej trasa jest jedynie prawdopodobna. Z mapą trasa uwzględnia rzeczywiste drogi, odległości i ograniczenia. Graf pełni rolę mapy.
def plan_with_graph(goal: str, graph_schema: dict, llm) -> list[dict]:
schema_str = json.dumps(graph_schema, indent=2)
planning_prompt = f"""
You are a planning agent. Given the goal below, decompose it into steps.
Each step must reference a valid entity type or relationship from the schema.
Do not invent steps that require knowledge outside this schema.
GRAPH SCHEMA:
{schema_str}
GOAL: {goal}
Return a JSON list of steps. Each step must include:
- "action": what to do
- "graph_query": the Cypher query to retrieve required context
- "depends_on": list of prior step indices this step requires
"""
raw_plan = llm.complete(planning_prompt)
plan = json.loads(raw_plan)
return plan
Kluczowym elementem jest wstrzykiwanie graph_schema do planera. Agent może planować jedynie te kroki, które są strukturalnie obsługiwane przez graf, co znacznie ogranicza powstawanie fałszywych planów, ponieważ nie może proponować działań zależnych od relacji danych nieobecnych w modelu wiedzy.
3. Wykonywanie z walidacją grafu
Podczas wykonywania zadań agent podejmuje działania i generuje częściowe wyniki. Trzeci wzorzec zakłada walidację każdego pośredniego wyniku w odniesieniu do grafu przed jego przyjęciem. Załóżmy, że agent doszedł do wniosku, iż to dostawca Y spowodował wadę stwierdzoną w produkcie X. System powinien natychmiast potwierdzić, że w grafie istnieje relacja pomiędzy tym dostawcą a tym produktem, oraz zaznaczyć tę tezę, jeśli takiej relacji nie ma.
def execute_with_validation(step: dict, intermediate_result: str, driver, llm) -> dict:
# Extract claims from the intermediate result
claim_extraction_prompt = f"""
Extract all factual claims from this text as a list of (subject, predicate, object) triples.
TEXT: {intermediate_result}
Return as JSON array.
"""
claims = json.loads(llm.complete(claim_extraction_prompt))
validation_results = []
with driver.session() as session:
for claim in claims:
result = session.run(
"""
MATCH (s {name: $subject})-[r]-(o {name: $object})
WHERE type(r) = $predicate OR $predicate IN r.aliases
RETURN count(r) AS match_count
""",
subject=claim["subject"],
predicate=claim["predicate"],
object=claim["object"]
)
record = result.single()
validation_results.append({
"claim": claim,
"validated": record["match_count"] > 0
})
unvalidated = [v for v in validation_results if not v["validated"]]
return {
"result": intermediate_result,
"validated": len(unvalidated) == 0,
"flagged_claims": unvalidated
}
To jest chyba miejsce, gdzie znajduje się największa wartość produkcyjna. W pętli wykonywania buduje się ciągły detektor halucynacji jako integralną część procesu rozumowania, a nie coś dodanego później. Niezweryfikowane twierdzenia nie powodują awarii systemu – są oznaczane, aby agent mógł je poprawić lub przekazać do sprawdzenia przez człowieka.
4. Samokorekcja poprzez przemierzanie grafu
Czwarty wzorzec zamyka tę pętlę. Po wykryciu niespójności lub otrzymaniu negatywnej informacji zwrotnej agent nie próbuje ponownie bez celu. Przemierza graf, aby znaleźć alternatywne ścieżki rozumowania, co odróżnia agenta, który sprawnie radzi sobie z błędami, od tego, który wiecznie krąży w pętli przy złych danych wejściowych.
Załóżmy, że agent bada przyczynę niepowodzenia sprawdzenia zgodności. Zaczynając od podmiotu, który spowodował to niepowodzenie, analizuje powiązania na zewnątrz i znajduje brakujący element, na przykład aktualizację przepisów, która jeszcze nie została powiązana z daną kategorią produktów. To luka w grafie, a nie w modelu językowym, i agent może ją wyraźnie zgłosić: wniosek nie mógł zostać zweryfikowany, ponieważ brakuje powiązania pomiędzy określoną aktualizacją przepisów a kategorią produktów medycznych. Jest to błąd, który można naprawić, a nie halucynacja.
Co z tym zrobić
Nie spiesz się z usuwaniem bazy danych wektorowych. Zacznij od zastanowienia się, gdzie w danym obszarze ma znaczenie struktura. Wymień zaangażowane entity oraz relacje między nimi, a następnie przyjrzyj się pytaniom, na które musi odpowiedzieć agent, i policz, ile z nich wymaga śledzenia linków między kilkoma faktami kolejno. Jeśli to opisuje większość trudnych pytań, problemem jest problem grafowy.
Jeśli chodzi o narzędzia, Neo4j jest najbardziej ugruntowaną bazą danych grafowych, a jej SDK dla Pythona dobrze integruje się z LangChain i LlamaIndex. Amazon Neptune oraz Memgraph to dobre alternatywy w zależności od środowiska, w którym działasz. Jeśli chodzi o orkiestrację, rozważ LangGraph – jego mechanizm zarządzania stanem przypomina przemierzanie grafu. Stan rozumowania agenta znajduje się już w strukturze grafowej, co sprawia, że dodanie zewnętrznego grafu wiedzy wydaje się naturalne.
Skuteczna sekwencja rozpoczyna się od wzoru numer jeden, który zakłada najmniejsze modyfikacje w istniejącym systemie RAG. Najpierw utwórz pierwszy graf oparty na najważniejszych entytetach i relacjach, a następnie porównaj wskaźniki halucynacji w przypadku promptów opartych na faktach z wartościami bazowymi. Jeśli te wskaźniki spadną, co jest bardzo prawdopodobne, uzyskasz uzasadnienie biznesowe dla pozostałych trzech wzorów.
Jedna uwaga: budowa grafu jest daleka od bycia prostą. Nieuporządkowane, niespójne lub źle oznaczone dane źródłowe prowadzą do nieuporządkowanego grafu oraz nieprzewidywalnego zachowania agenta, więc zasada „brudne dane, brudny wynik” obowiązuje tu tak samo jak wszędzie indziej. Inwestuj w jakość danych i projekt ontologii przed tworzeniem infrastruktury grafowej. Czysty, dobrze zstrukturyzowany graf składający się z 10 000 węzłów będzie lepszy od rozległego, niespójnego grafu z 10 milionami węzłów.
Kierunek rozwoju
Tutaj chodzi o agenty, które wykraczają poza prostą wyszukiwanie i generowanie informacji. Utrzymują rozwijający się, uporządkowany model świata, w którym działają, i wykorzystują go do rozumowania, planowania oraz korygowania swoich działań w otwartym środowisku. To, co odróżnia sztuczną inteligencję, która jedynie odpowiada na pytania, od tej, która rozwiązuje problemy, wynika głównie z sposobu reprezentacji wiedzy, a grafy należą do najskuteczniejszych strukturalnych rozwiązań dostępnych na rynku.
Spróbuj to zastosować w dowolnym systemie: jeśli agent podjąłby jutro złą decyzję, czy można by wyśledzić dokładną przyczynę? Gdy to nie będzie możliwe, procesy będą przebiegać bez żadnej kontroli. Te cztery wzorce wskazują na agenty, które ujawniają swój sposób rozumowania, sprawdzają własne wnioski i popełniają błędy, które można naprawić, i to właśnie taki kształt powinna przybrać sztuczna inteligencja przeznaczona do użycia w produkcji. Zespoły, które dotrą tam pierwsze, pokonają te, które wciąż analizują wskaźniki kosinusowe i zastanawiają się, dlaczego ich agenci ciągle ponoszą porażki.
Literatura pokrewna
- Praktyczne notatki: Budowanie systemu detekcji oszustw w stanie produkcyjnym — Szczegółowy przewodnik po Praktycznych notatkach: Budowanie systemu detekcji oszustw w stanie produkcyjnym: umowy, sprawdzenia oraz gotowe fragmenty kodu dla zespołów wdrażających ten model.
- Wyodrębnianie semantyczne z użyciem ChromaDB i embeddingów dla platformy multi-agent — Przenoszenie platformy multi-agent do prawdziwego wyodrębniania semantycznego: dzielenie tekstu z uwzględnieniem słów, odległość kosinusowa w ChromaDB, warstwy testowe oraz kolejny krok w implementacji RetrievalAgent.