Speicher- und Retrieval-Architekturen

Unsere Position. Ein Knowledge-Graph-Schema behandeln wir als Kontextarchitektur (öffnet in einem neuen Tab). Graph-Retrieval legt seinen Pfad offen. Aus einer Antwort, die ihr hinnehmt, wird so eine, die ihr prüfen könnt. Der Preis dafür sind eine Ingestion-Pipeline und Entity Resolution. Er lohnt sich, wenn Antworten nachvollziehbar sein müssen. Wo ein Suchfeld reicht, ist er übertrieben.

Welche Speichertechnologie passt zu welchem Kontextbedarf?

Der Speicher folgt der Form der Frage: Ähnlichkeit, Relevanz, Beziehungen oder Arbeitsstand. Der “Domain Context Service” sollte kein einzelner monolithischer Dienst sein. Er sollte eine Fassade sein, die Anfragen anhand der Metadaten des angefragten Context Product intelligent an das passende Backend leitet. Das kann eine Suchmaschine sein, eine Graphdatenbank oder ein anderes System.

Für semantische Relevanz: Vektordatenbanken oder Enterprise-Suchmaschinen

Der Aufstieg von Retrieval-Augmented Generation (RAG) ist eng mit Vektordatenbanken verknüpft. Im Unternehmenseinsatz müsst ihr aber scharf trennen, ob ihr Dokumente nach semantischer Ähnlichkeit findet oder die Dokumente mit der höchsten Relevanz für eine Anfrage abruft (Coveo - Why Search Engines Outperform Vector Databases for RAG (öffnet in einem neuen Tab)).

Vektordatenbanken sind stark in der Ähnlichkeitssuche. Sie betten Text in einen hochdimensionalen Raum ein und finden die “nächsten Nachbarn” eines Anfragevektors. Für konzeptuell verwandte Inhalte ist das mächtig. Wo es auf Präzision ankommt, scheitert es oft (Meilisearch - Why you shouldn’t use vector databases for RAG (öffnet in einem neuen Tab)). Sucht jemand etwa einen bestimmten Fehlercode oder eine Produkt-SKU, hilft reine Vektorsuche womöglich wenig. Sie liefert dann konzeptuell ähnliche, aber falsche Treffer.

Echte Relevanz im Unternehmen verlangt hybride Suche, eine Kernkompetenz moderner Enterprise-Suchmaschinen. Sie verbinden mehrere Retrieval-Signale zu einem einzigen, justierbaren Ranking-Algorithmus:

• Vektorsuche: erfasst Bedeutung und Absicht hinter einer Anfrage.
• Lexikalische Suche (z. B. BM25): liefert hohe Präzision für Schlüsselwörter, exakte Phrasen und bestimmte Identifikatoren.
• Metadatenfilter: grenzt Ergebnisse über strukturierte Attribute ein, etwa Autor:in, Erstellungsdatum, Dokumenttyp oder Security-Tags.
• Justierbares Ranking: lässt Geschäftslogik die Ergebnisse beeinflussen. Offizielle Dokumentation rangiert dann etwa vor Forenbeiträgen, oder neuere Dokumente kommen zuerst.

Enterprise-Suchplattformen sind außerdem ausgereifte Technik, gebaut für Indexierung und Updates in großem Maßstab und in Echtzeit. Genau hier können manche reinen Vektordatenbanken bei stark dynamischen Datenbeständen auf Probleme mit Kosten und Komplexität stoßen (Coveo - Why Search Engines Outperform Vector Databases for RAG (öffnet in einem neuen Tab)).

Für das Verständnis von Beziehungen: die Stärke von GraphRAG

Bei vielen komplexen Fragen steht die Antwort in keinem einzelnen Dokument. Sie ergibt sich erst aus den Beziehungen zwischen mehreren Informationen. Standard-RAG ruft eine Liste unabhängiger Text-Chunks ab und eignet sich dafür schlecht. Hier verschaffen Knowledge Graphs und das GraphRAG-Muster einen klaren Vorteil (DZone - Enhancing Code Analysis With Code Graphs (öffnet in einem neuen Tab)).

Ein Knowledge Graph speichert Informationen als Netz aus Entitäten (Knoten) und ihren Beziehungen (Kanten). Diese Struktur eignet sich ideal für komplexe Systeme wie Codebasen, Organigramme oder Lieferketten. Der GraphRAG-Ablauf unterscheidet sich grundlegend von Standard-RAG:

1. Anker-Knoten finden: Zuerst sucht das System mit der Anfrage einen oder mehrere Startpunkte im Graphen, die “Anker-Knoten”. Schon dieser Schritt kann hybride Suche auf den Eigenschaften der Knoten nutzen.
2. Graph-Traversierung: Von den Anker-Knoten aus durchläuft das System den Graphen programmatisch. Es folgt bestimmten Beziehungstypen und sammelt so eine reiche, vernetzte Nachbarschaft an relevantem Kontext.
3. Subgraph serialisieren: Den entstandenen Subgraphen, keine bloße Liste von Textschnipseln, serialisiert das System in ein Format, das das LLM versteht. Das können Textbeschreibungen der Knoten und Beziehungen sein. Das Ergebnis landet im Prompt.

So beantworten Agenten Fragen, die Schlussfolgern über mehrere Hops verlangen (Neo4j (öffnet in einem neuen Tab)). Ein Beispiel mit dem Code Knowledge Graph ist die Anfrage “Which API endpoints are affected by the deprecation of the LegacyBilling class?”. Das System sucht dafür den Knoten LegacyBilling und durchläuft von dort die Beziehungen INHERITS_FROM, CALLS und DEFINED_IN. So findet es die verbundenen Funktionen und die Dateien, die sie als API-Endpunkte bereitstellen. Für ein dokumentzentriertes RAG-System ist eine solche Anfrage nahezu unmöglich (DZone - Enhancing Code Analysis With Code Graphs (öffnet in einem neuen Tab)).

Für Agenten-Memory: versionierter Kontext in Git

Für KI-Agenten mit lange laufenden, mehrstufigen Aufgaben ist Memory mehr als ein Protokoll vergangener Unterhaltungen. Es ist ein Arbeitsraum für Planung, Ausführung und Reflexion. Klassisches Agenten-Memory ist oft flüchtig und unstrukturiert (From Token Streams to Version Control: Git-Style Context Management for AI Agents (öffnet in einem neuen Tab)). Ein neues, wirkungsvolles Muster für dauerhaftes, strukturiertes und prüfbares Agenten-Memory ist der Git-Context-Controller (GCC) (arXiv - Git Context Controller: Manage the Context of LLM-based Agents like Git (öffnet in einem neuen Tab)).

Das Muster behandelt das Memory eines Agenten als Git-Repository. Es liegt in einem eigenen Verzeichnis .GCC/ im Workspace des Agenten. Die Struktur ist hierarchisch und semantisch aussagekräftig:

• main.md: Datei im Wurzelverzeichnis mit dem übergeordneten Ziel des Agenten, seinem Plan und seiner To-do-Liste.
• Branches: Der Agent kann Branches anlegen (git branch explore-new-approach) und darin alternative Strategien erkunden, ohne seine Hauptlinie des Denkens zu beschädigen. Gescheiterte Experimente lassen sich verwerfen, erfolgreiche zurückmergen.
• Commits: Mit einem COMMIT-Befehl setzt der Agent atomare Checkpoints für nennenswerten Fortschritt. Jeder Commit trägt eine Nachricht, die das Erreichte zusammenfasst, und ist mit ausführlichen Logs verknüpft.
• log.md: enthält Schritt für Schritt die feingranulare Spur der Beobachtungen, Gedanken und Aktionen des Agenten (OTA).
• metadata.yaml: speichert strukturierte Informationen über die Umgebung, etwa Dateistrukturen oder Abhängigkeiten.

Für fortgeschrittene agentische Workflows bringt das GCC-Muster deutliche Vorteile. Das Memory orientiert sich an Meilensteinen. Agenten erkunden verschiedene Lösungswege ohne Risiko. Die Historie ihres Denkprozesses bleibt vollständig prüfbar. Vor allem gelingen Zusammenarbeit und Übergabe nahtlos. Ein neuer Agent, sogar ein anderes LLM, übernimmt eine Aufgabe, indem er einfach das Kontext-Repository klont und den neuesten Stand auscheckt (From Token Streams to Version Control: Git-Style Context Management for AI Agents (öffnet in einem neuen Tab)).

Dieser Ansatz ergänzt Managed-Memory-Dienste wie Zep sehr gut. GCC glänzt bei prüfbarem, versioniertem Memory für komplexe, zustandsbehaftete Aufgaben wie Codegenerierung. Zep ist dagegen darauf optimiert, den dynamischen Gesprächskontext von Nutzerinteraktionen zu verwalten.

---

Verwandte Seiten

• Context Products entwickeln: wie der Code Knowledge Graph und die Dokumentindizes entstehen.
• Just-in-time Retrieval: warum Coding-Agents Daten oft über Tools laden statt über einen Index.
• Persistentes Agenten-Memory: das Problem des Vergessens, das jeder Memory-Speicher lösen muss.
• Governance und Betrieb: wie jeder Speicher nach Rolle filtert und aktuell bleibt.

Quellen

Artikel

• Enhancing Code Analysis With Code Graphs (öffnet in einem neuen Tab) - DZone-Artikel über Code Knowledge Graphs, die Multi-Hop-Fragen nach Auswirkungen beantworten, an denen dokumentzentriertes Retrieval scheitert.
• From Token Streams to Version Control: Git-Style Context Management for AI Agents (öffnet in einem neuen Tab) - Blogpost über Agenten-Memory nach Git-Art. Branches dienen der Erkundung, Commits sind Checkpoints, die ein anderer Agent klonen kann.
• How to improve multi-hop reasoning with knowledge graphs and LLMs (öffnet in einem neuen Tab) - Neo4j-Artikel über GraphRAG, das von Anker-Knoten aus traversiert, um Fragen über mehrere verbundene Fakten zu beantworten.
• Why Search Engines Outperform Vector Databases for RAG (öffnet in einem neuen Tab) - Artikel von Coveo, einem Anbieter von Suchtechnik. Er trennt semantische Ähnlichkeit von Relevanz und plädiert für hybride Enterprise Search in RAG.
• Why you shouldn’t use vector databases for RAG (öffnet in einem neuen Tab) - Artikel von Meilisearch, einem Anbieter von Suchtechnik, darüber, wo reine Vektorsuche an Präzision scheitert, etwa bei Fehlercodes und SKUs.

Papers und Berichte

• Git Context Controller: Manage the Context of LLM-based Agents like Git (öffnet in einem neuen Tab) - arXiv-Paper, das den Git-Context-Controller vorstellt. Er führt Agenten-Memory als Repository mit Zielen, Branches, Commits und Logs.

Posts

• Context architecture (öffnet in einem neuen Tab) - LinkedIn-Post, der ein Knowledge-Graph-Schema als Kontextarchitektur behandelt. Ihre Ingestion-Kosten lohnen sich dort, wo Antworten nachvollziehbar sein müssen.