Wissensgraphen für agierende KI: Vier Muster, die über Vektor-RAG hinausgehen.
Die Vektorsuche findet ähnlichen Text, nicht miteinander verbundene Fakten. Vier Graphmuster für Agenten: angeleitete Anfragen, Planung, Überprüfung der Ausführung und Selbstkorrektur.
Quellen: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
Die meisten Teams, die KI-Systeme entwickeln, stoßen auf dieselben Probleme. Es wird eine Vektordatenbank eingerichtet, die Dokumente in Teile aufgeteilt, ein LLM integriert – das Ergebnis wird als RAG-Pipeline bezeichnet. Das System funktioniert, bis ein Benutzer eine Frage stellt, bei der es darum geht, drei Fakten aus unterschiedlichen Datensätzen miteinander zu verknüpfen. In diesem Fall erfindet das System entweder eine überzeugend klingende Antwort oder liefert etwas, das technisch korrekt ist, aber im Kontext nutzlos ist.
In der Regel liegt das Problem nicht beim LLM selbst, sondern bei der darunterliegenden Suchschicht. Die Vektorähnlichkeitssuche dient im Grunde dazu, Passagen zu finden, die ähnlich klingen, wodurch semantisch nahe liegender Text gefunden wird, während faktische Zusammenhänge, die kausal oder relationell sind, übersehen werden. Für einen Agenten, der mehrere Schritte durchdenken, Aktionen ausführen und Entscheidungen miteinander verknüpfen muss, verstärkt sich diese Einschränkung noch. Eine schlechte Antwort führt dazu, dass sich Fehler entlang der gesamten Schlussfolgerungskette anhäufen.
Der Argument, den man ernst nehmen sollte, ist, dass ein Wissensgraph kein bloß aufwendigereres Abrufmechanismus ist. Er ist die strukturelle Grundlage, die es einem Agenten ermöglicht, zu reasoningen, anstatt nur Daten abzurufen.
Die Kernidee
Agentic AI wird oft als Schlagwort behandelt: Man fügt einige Toolaufrufe zu einem LLM hinzu und erklärt den Sieg für errungen. Ein disziplinierterer Ansatz entwirft die Wissensschicht gezielt für mehrstufiges Reasoning und nicht für einmaliges Fragebeantworten.
Es kommt zu einem Wandel von einem flachen Abrufmodell zu einem strukturierten Graphen, in dem Entitäten, Beziehungen und Kontext im Vordergrund stehen. Ein Graph protokolliert nicht nur, dass Produkt X einen Defekt aufweist. Er protokolliert auch, dass Produkt X vom Lieferanten Y hergestellt wird, in Region Z verschickt wird und vom Compliance Framework W abgedeckt ist. Ein Agent, der diesen Graphen abfragt, kann diese Verbindungen durchlaufen und Erkenntnisse gewinnen, die eine Vektorabfrage niemals zeigen würde.
Keines davon ist in der Datenbanktheorie neu. Die strenge Anwendung darauf auf agierende Systeme ist der innovative Aspekt, und der Zeitpunkt ist sinnvoll. Agent-Pipelines haben sich durch besseres Reasoning von LLMs, verbesserte APIs zum Aufrufen von Tools sowie umfangreichere Orchestrierungsframeworks ausreichend weiterentwickelt, sodass die Wissensschicht nun das Engpassproblem darstellt. Eine fehlerfreie Agent-Architektur erzeugt weiterhin „Müll“, wenn die zugrunde liegende Wissensrepräsentation flach und unvernetzt ist.
Die Methode gliedert sich in vier architektonische Muster, von denen jedes eine andere Phase des Agent-Lebenszyklus abdeckt: Grundlegung, Planung, Ausführung und Selbstkorrektur. Zusammen bilden sie einen Entwurf für Produktivsysteme und nicht nur ein theoretisches Übungsszenario.
Warum das wichtig ist
Die Erstellung von RAG-Modellen ist in der Regel anfällig, und ihre Fehler sind schwer nachzuvollziehen. Nach einer schlechten Antwort bleibt die Ursache verborgen: schwache Informationsabrufung, eine fehlerhafte Trennung der Datenblöcke oder ein Modell, das im Widerspruch zum ihm gegebenen Kontext steht. Bei der flachen Vektorabfrage bleibt nur das Raten übrig. Wenn man einen Wissensgraphen einsetzt, entsteht eine nahezu kostenlose Erklärbarkeit, da der Durchlaufpfad selbst der Nachweis der Logik darstellt.
Das ist in regulierten Branchen von großer Bedeutung. Gesundheitswesen, Finanzwesen und Rechtstechnologie benötigen alle KI-Systeme, die ihre Arbeitsweise nachweisen können. Ein System, das die drei Graphenknoten sowie die beiden Beziehungsstufen hinter einer Antwort angibt, lässt sich auditen, während ein System, das nur ein top-k-Kosinus-Ergebnis liefert, dies nicht ermöglicht. Für Teams, die KI-Systeme unter strengen Compliance-Anforderungen einsetzen, macht das den Unterschied zwischen einem einsatzfähigen Produkt und einem Konzept, das niemals das Labor verlässt.
Es gibt auch einen Aspekt der Zuverlässigkeit. Agentenbasierte Systeme versagen in Kaskaden, wobei eine schlechte Entscheidung früh in der Kette alles danach beeinträchtigt. Ein Graph fungiert als strukturelles Schutzsystem: Die Agenten können vor dem Weitermachen die Zwischenergebnisse daran überprüfen und Abweichungen früh erkennen. Er ähnelt einem Faktenprüfer, der in den Schlussfolgerungsprozess integriert ist und nicht erst am Ende hinzugefügt wird.
Vielleicht ist der am meisten unterschätzte Vorteil die Aktualisierung von Wissen ohne Neutraining. Mit Embeddings bedeutet das Hinzufügen neuer Fakten oft das Neu-Embedden großer Datenmengen und möglicherweise Störungen im bestehenden Abrufverhalten. Mit einem Graph hingegen fügt man Knoten und Kanten hinzu, und die Schlussfolgerungen der Agenten spiegeln diese sofort wider. In schnelllebigen Bereichen wie Finanzmärkten, medizinischer Forschung und sich entwickelnden Softwareökosystemen ist das ein echter wettbewerbsmäßiger Vorteil.
Die vier Muster in der Praxis
1. wissensbasiertes Anregen
Das erste Muster verankert den Ausgangskontext des Agenten in strukturierten Fakten und nicht in unscharfen Ähnlichkeitsergebnissen. Anstatt Abschnitte zu holen, die ähnlich erscheinen, wird das Graph nach dem mit der Absicht des Benutzers relevanten Teilgraphen abgefragt, und dieser strukturierte Kontext wird in die Anfrage eingefügt.
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
Schauen Sie sich an, was hier passiert. Der Agent sucht nicht nach Dokumenten, die wie die Frage klingen. Er extrahiert konkrete Entitäten, holt deren relationale Umgebung ab und injiziert diese als strukturierten Kontext. Was das LLM erhält, ist eine Karte – anstatt einer Ansammlung von Abschnitten, die nur lose miteinander verbunden sind.
2. graphbasiertes Planen
Das zweite Muster bezieht sich auf mehrstufiges Planen. Agenten zerlegen komplexe Ziele in ausführbare Schritte, wobei diese Schritte auf dem beruhen sollten, was angesichts des aktuellen Wissensstands tatsächlich möglich ist. Ein Graph macht das Planen deutlich weniger frei formbar.
Vergleichen Sie das Planen einer Autoreise ohne Karte und mit einer. Ohne Karte ist die Route lediglich plausibel. Mit einer Karte berücksichtigt die Route tatsächliche Straßen, Entfernungen und Einschränkungen. Der Graph übernimmt dabei die Rolle der Karte.
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
Der entscheidende Aspekt besteht darin, graph_schema in den Planer einzubringen. Der Agent kann nur solche Schritte planen, die die Struktur des Graphen unterstützt, wodurch halluzinierte Pläne erheblich reduziert werden, da er keine Aktionen vorschlagen kann, die auf in dem Wissensmodell fehlenden Datenbeziehungen beruhen.
3. Ausführung mit Graphenvalidierung
Während der Ausführung handelt der Agent und erzeugt dabei schrittweise teilweise Ergebnisse. Das dritte Muster besagt, dass jedes Zwischenergebnis vor seiner Annahme gegenüber dem Graphen überprüft werden muss. Angenommen, der Agent kommt zu dem Schluss, dass Lieferant Y den Defekt im Produkt X verursacht hat. Das System sollte unverzüglich bestätigen, ob der Graph eine Beziehung zwischen diesem Lieferanten und diesem Produkt enthält, und die Behauptung sonst markieren.
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
}
Hier liegt vermutlich der größte Anteil an Produktivität. Es wird ein kontinuierlicher Halluzinationserkennungsalgorithmus in den Ausführungslauf integriert, als struktureller Bestandteil des Denkprozesses und nicht als nachträgliche Ergänzung. Ungenügend überprüfte Aussagen führen nicht zum Absturz des Systems. Sie werden markiert, damit der Agent sie überarbeiten oder an einen menschlichen Prüfer weiterleiten kann.
4. Selbstkorrektur durch Graphenabfrage
Das vierte Muster schließt den Kreislauf. Bei Erkennung einer Inkonsistenz oder bei negativer Rückmeldung versucht der Agent nicht blind erneut. Er durchläuft den Graphen, um alternative Denkwege zu finden – dadurch unterscheidet sich ein Agent, der angemessen versagt, von einem, der bei schlechten Eingaben endlos im Kreis läuft.
Nehmen wir an, der Agent untersucht, warum eine Konformitätsprüfung fehlgeschlagen ist. Er beginnt bei der Einheit, die den Fehler ausgelöst hat, verfolgt die damit verbundenen Beziehungen nach außen und entdeckt eine fehlende Verbindung – beispielsweise eine regulatorische Aktualisierung, die noch nicht mit der betroffenen Produktkategorie verknüpft wurde. Das ist eine Lücke im Graphen und nicht im LLM, und der Agent kann dies ausdrücklich melden: Die Schlussfolgerung konnte nicht validiert werden, da die Beziehung zwischen der genannten regulatorischen Aktualisierung und der Gesundheitsproduktkategorie fehlt. Das ist ein behobbarer Fehler und keine Halluzination.
Was dagegen zu tun ist
Zögern Sie nicht, die Vektor-Datenbank zu entfernen. Beginnen Sie damit, herauszufinden, wo in dem jeweiligen Bereich eine strukturierte Darstellung wichtig ist. Listen Sie die beteiligten Entitäten sowie die Beziehungen zwischen ihnen auf, prüfen Sie anschließend die Fragen, die der Agent beantworten muss, und zählen Sie, wie viele davon die Verfolgung von Verknüpfungen über mehrere Fakten hintereinander erfordern. Wenn dies auf die meisten schwierigen Fragen zutrifft, liegt das zugrunde liegende Problem in einem Graphenproblem.
Was Tools angeht, ist Neo4j die am weitesten verbreitete Graphen-Datenbank, und ihre Python-SDK integriert sich gut mit LangChain und LlamaIndex. Amazon Neptune und Memgraph sind je nach Betriebsumgebung gute Alternativen. Für die Orchestrierung lohnt sich LangGraph, dessen Zustandsverwaltung einer Graphenuntersuchung ähnelt. Der Schlussfolgerungs-Zustand des Agents befindet sich bereits in einer Graphenstruktur, wodurch das Hinzufügen eines externen Wissensgraphen ganz natürlich erscheint.
Eine praktikable Vorgehensweise beginnt mit Muster eins, das nach der kleinstmöglichen Anpassung an ein bereits vorhandenes RAG-System fragt. Erstellen Sie zunächst den ersten Graphen um die wichtigsten Entitäten und Beziehungen herum und vergleichen Sie anschließend die Halluzinationsraten bei fundierten Anfragen mit Ihrem Ausgangswert. Wenn diese sinken – was sehr wahrscheinlich der Fall ist – haben Sie die Geschäftsgründe für die verbleibenden drei Muster erarbeitet.
Eine Warnung: Der Aufbau eines Graphen ist keineswegs trivial. Unordentliche, inkonsistente oder schlecht beschriftete Quelldaten führen zu einem unübersichtlichen Graphen sowie zu unkoordiniertem Agentenverhalten – also gilt hier genauso wie überall sonst das Prinzip „Gut Ding braucht Weile“. Investieren Sie zuerst in die Datenqualität und die Ontologiegestaltung, bevor Sie Infrastruktur für Graphen einrichten. Ein sauberer, gut strukturierter Graph mit 10.000 Knoten wird sich besser schlagen als ein umfangreiches, inkonsistentes Netzwerk mit 10 Millionen Knoten.
Was daraus folgt
Dies führt zu Agenten, die über das einfache Abrufen und Erzeugen hinausgehen. Sie pflegen ein sich ständig entwickelndes, strukturiertes Modell der Welt, in der sie arbeiten, und nutzen es, um zu reasoningen, zu planen und sich in Echtzeit zu korrigieren. Was KI, die lediglich Fragen beantwortet, von KI unterscheidet, die Probleme löst, liegt hauptsächlich darin, wie Wissen dargestellt wird – und Graphen gehören zu den stärksten strukturellen Lösungen, die zur Verfügung stehen.
Probieren Sie das in jedem System aus: Wenn der Agent morgen eine falsche Entscheidung trifft, lässt sich die genaue Ursache dann nachvollziehen? Wenn nicht, läuft die Produktion blind. Diese vier Muster weisen auf Agenten hin, die ihr Reasoning offenlegen, ihre eigenen Schlussfolgerungen überprüfen und auf Weise versagen, die man debuggen kann – und genau diese Form muss KI für Produktionszwecke annehmen. Teams, die zuerst dorthin gelangen, werden diejenigen schlagen, die immer noch nur Cosinus-Werte betrachten und sich fragen, warum ihr Agent weiterhin Fehler macht.
Verwandte Artikel
- Praktische Hinweise: Aufbau eines für die Produktion bereiten agierenden Betrugserkennungssystems — Detaillierte Anleitung zu den Praktischen Hinweisen zum Aufbau eines für die Produktion bereiten agierenden Betrugserkennungssystems: Verträge, Überprüfungen sowie Code-Blöcke, die Teams nutzen können, die dieses Muster implementieren.
- Semantische Suche mit ChromaDB und Embeddings für eine Multi-Agenten-Plattform — Umstellung einer Unternehmens-Multi-Agenten-Plattform auf echte semantische Suche: wortbasiertes Aufteilen in Abschnitte, Kosinusabstand in ChromaDB, Testschichten sowie der nächste Schritt mit RetrievalAgent.