Zum Inhalt springen

Wissensbasis

Context Products entwickeln

Wie aus Dokumenten, Gesprächen und Quellcode Context Products werden, Schritt für Schritt von der Ingestion bis zum Code-Wissensgraphen, für Plattform- und Datenteams.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Der Engpass ist für uns nicht mehr der Code, sondern der Kontext (öffnet in einem neuen Tab). Gemeint sind die Standards, Konventionen und Entscheidungen, die nur in den Köpfen erfahrener Entwickler:innen stecken. Jede falsche Antwort eines Agenten ist ein Befund aus einem Dokumentations-Audit. Die Abhilfe: den Standard dort aufschreiben, wo der Agent und der nächste Mensch ihn finden.

Die folgenden Pipelines unterscheiden sich je nach Quelle. Jede bewahrt aber Struktur und Metadaten, die bei einem rohen Dump verloren gingen. Ein Agent kann dann über das Ergebnis schlussfolgern, statt aus Fragmenten zu raten.

Wie macht ihr aus rohen Unternehmensdaten Context Products?

Pipelines für Ingestion und Transformation machen aus den wichtigsten Quellen des Unternehmens strukturierte Assets. Diese werden anschließend im Context-Katalog registriert. Extrahieren allein ist dabei nicht das Ziel. Die Pipelines verknüpfen rohe Information zu einer vernetzten Wissensbasis, über die Agenten schlussfolgern können. Dieses “cognify” ist ein Prinzip von Memory-Frameworks wie Cognee (topoteretes - Cognee - The Open-Source AI Memory Platform for Agents (öffnet in einem neuen Tab)).

Unternehmenswissen aufnehmen

Ein großer Teil des Unternehmenswissens liegt unstrukturiert oder halbstrukturiert vor. Robuste Pipelines, die diese Information verarbeiten, sind deshalb eine grundlegende Fähigkeit.

Unstrukturierter Text (Confluence, Jira)

Dokumente aus Wissensbasen wie Confluence und Issue-Trackern wie Jira bilden den Kern des Domain Context. Eine wirksame Ingestion-Pipeline für diese Quellen hat mehrere Schritte:

  1. Extraktion: Über die offiziellen REST-APIs zieht ihr die Inhalte aus den Quellsystemen. Bei Confluence extrahiert ihr den Inhalt der Seiten in bestimmten Spaces. Bei Jira holt ihr Beschreibungen, Kommentare und wichtige Felder der Issues, die zu einer JQL-Abfrage passen (Medium - Building a Confluence-Powered Search Engine Using LangChain and LLMs (öffnet in einem neuen Tab)).
  2. Chunking: Rohe Dokumente sind oft zu groß für das Kontextfenster eines LLM. Ihr müsst sie deshalb in kleinere, semantisch zusammenhängende Chunks teilen. Statt naiv in feste Größen zu schneiden, nutzt ihr intelligente Strategien. Ihr teilt etwa an HTML-Überschriften (<h1>, <h2>), an Absätzen oder an den Abschnitten eines Jira-Issues (Shakudo - Building a Confluence Q&A App with LangChain and ChatGPT (öffnet in einem neuen Tab)).
  3. Anreicherung: Während der Verarbeitung müssen entscheidende Metadaten erhalten bleiben und an jedem Chunk hängen. Dazu gehören Quell-URL, Seitentitel, Autor:in, Erstellungsdatum und relevante Labels oder Tags, etwa der Key des Confluence-Space oder des Jira-Projekts. Diese Metadaten braucht ihr zum Filtern und für die Quellenangaben in der fertigen Antwort der KI.
  4. Vektorisierung und Speicherung: Jeder Chunk läuft dann durch ein Embedding-Modell, das ihn als numerischen Vektor darstellt. Die Vektoren landen zusammen mit Text und Metadaten in einem Retrieval-System, etwa einer Enterprise-Suchmaschine, und lassen sich später abfragen (Shakudo - Building a Confluence Q&A App with LangChain and ChatGPT (öffnet in einem neuen Tab)).

Gesprächsverläufe

Gesprächsverläufe sind eine eigene, dynamische Form von Kontext und für Konversations-Agenten unverzichtbar. Anders als statische Dokumente wächst dieser Kontext mit jeder Interaktion. Er braucht deshalb aktive Verwaltung, damit er die Token-Limits nicht sprengt und die Kontinuität erhalten bleibt (Mem0 - LLM Chat History Summarization Guide October 2025 (öffnet in einem neuen Tab)). Jede Strategie wägt dabei Genauigkeit gegen Kosten ab:

  • Conversation Buffer Memory: Der einfachste Ansatz behält den gesamten rohen Verlauf. Dabei geht nichts verloren, doch der Ansatz skaliert nicht und sprengt schnell die Token-Limits des Modells (Pinecone - Conversational Memory for LLMs with Langchain (öffnet in einem neuen Tab)).

  • Conversation Window Memory: Praktischer ist es, nur die letzten k Interaktionen zu behalten. Das ist effizient, riskiert aber den Verlust wichtiger Informationen aus früheren Teilen des Gesprächs (Pinecone - Conversational Memory for LLMs with Langchain (öffnet in einem neuen Tab)).

  • Conversation Summary Memory: Hier schreibt ein LLM in regelmäßigen Abständen eine laufende Zusammenfassung des Gesprächs. Das spart viele Tokens, kann beim Zusammenfassen aber Nuancen und konkrete Details verlieren (Managing Context History Best Practices (öffnet in einem neuen Tab)).

    Eine ausgefeilte Agenten-Architektur kann die Ansätze kombinieren. Ein kurzer Window-Buffer hält den unmittelbaren Kontext. Ein Hintergrundprozess wertet das Gespräch rückblickend aus und überführt wichtige Fakten und Entscheidungen in ein strukturierteres, zusammengefasstes Langzeitgedächtnis. Diese aktive Verwaltung ist eine Kernaufgabe der Agent-Context-Schicht.

Fortgeschrittenes Memory: mehr als Zusammenfassen

Einfache Memory-Strategien sind nützlich. Agentische Systeme auf dem Stand der Technik brauchen aber einen ausgefeilteren Ansatz, der sich an der menschlichen Kognition orientiert. Plattformen wie Zep und Cognee leisten hier Pionierarbeit. Sie bauen persistente Langzeitspeicher, die über einfache Gesprächsprotokolle hinausgehen (arXiv - Zep: A Temporal Knowledge Graph Architecture for Agent Memory (öffnet in einem neuen Tab)).

Diese Systeme folgen einem ähnlichen Prinzip wie das menschliche Gehirn, das episodisches und semantisches Gedächtnis unterscheidet:

  • Episodisches Gedächtnis: hält die rohen Ereignisse einer Interaktion in ihrer Reihenfolge fest, etwa das Transkript einer Chat-Sitzung.
  • Semantisches Gedächtnis: zieht aus diesen Ereignissen die wichtigsten Fakten, Entitäten und Beziehungen und fügt sie zu einer strukturierten Wissensbasis zusammen.

Frameworks wie Zep bauen dafür für jede:n Nutzer:in oder jede Sitzung einen temporalen Wissensgraphen (getzep - Zep Cloud: Examples & Integrations (öffnet in einem neuen Tab)). Mit jedem neuen Gespräch extrahiert das System automatisch Entitäten und Fakten. Es fügt sie in den Graphen ein und aktualisiert vorhandene Information. So kann der Agent darüber schlussfolgern, wie sich Information über die Zeit ändert, etwa die Vorliebe einer Person von einer Sitzung zur nächsten (Zep: Context Engineering Platform for AI Agents (öffnet in einem neuen Tab)).

Braucht der Agent Kontext, holt er nicht einfach ein rohes Chat-Protokoll. Er fragt den reichhaltigen Graphen ab und stellt daraus einen strukturierten, Token-sparenden Block zusammen. Darin stehen die relevantesten Fakten, Vorlieben und früheren Interaktionen (Zep: Context Engineering Platform for AI Agents (öffnet in einem neuen Tab)). Dieser Ansatz der “memory formation” liefert viel tieferen und verlässlicheren Kontext als einfaches Zusammenfassen. Er macht wirklich personalisiertes und kontextbewusstes Verhalten des Agenten möglich (arXiv - Zep: A Temporal Knowledge Graph Architecture for Agent Memory (öffnet in einem neuen Tab)).

Code als Kontext modellieren: von Quelldateien zu semantischem Verständnis

KI-Agenten in der Softwareentwicklung reicht roher Quellcode als Kontext nicht. Sie brauchen ein tiefes, strukturelles Verständnis der Codebasis. Ein “Technical Context”-Produkt mit hoher Abbildungstreue entsteht in mehreren Stufen zunehmender Abstraktion. Der Weg führt vom rohen Text über die syntaktische Struktur bis zu den semantischen Beziehungen.

Syntaktische Analyse mit Abstract Syntax Trees (ASTs)

Übliches textbasiertes Chunking taugt für Quellcode nicht, weil es die grammatische Struktur ignoriert. Es schneidet Code oft mitten in einer Funktions- oder Klassendefinition. Der Chunk ist dann syntaktisch ungültig und bedeutungslos (Enhancing LLM Code Generation with RAG and AST-Based Chunking (öffnet in einem neuen Tab)).

Richtig ist es, den Code in einen Abstract Syntax Tree (AST) zu parsen. Ein AST stellt die syntaktische Struktur des Codes als Baum dar. Jeder Knoten steht für ein Konstrukt wie eine Funktionsdeklaration, ein if-Statement oder eine Variablenzuweisung (Wikipedia - Abstract syntax tree (öffnet in einem neuen Tab)).

In der Praxis nutzt ihr ASTs so:

  1. Parser wählen: Wählt einen robusten Code-Parser. tree-sitter ist eine ausgezeichnete Wahl: schnell, fehlertolerant und mit einer großen Bibliothek an Grammatiken für viele Programmiersprachen (arXiv - Abstract Syntax Tree for Programming Language Understanding and Representation: How Far Are We? (öffnet in einem neuen Tab)). Für Sprachen mit eigenen oder komplexen Grammatiken eignen sich andere Tools wie ANTLR (Reddit - AST for any code : r/Compilers (öffnet in einem neuen Tab)).
  2. Code parsen: Für jede Quelldatei im Repository erzeugt der gewählte Parser den zugehörigen AST.
  3. Knoten extrahieren: Ein Programm durchläuft dann den AST und zieht die semantisch sinnvollen Code-Einheiten heraus. Statt beliebiger Chunks entsteht eine Sammlung vollständiger Funktionen, Klassen, Methoden und Import-Blöcke. So ist jedes Stück Kontext für das LLM syntaktisch vollständig und logisch geschlossen (Enhancing LLM Code Generation with RAG and AST-Based Chunking (öffnet in einem neuen Tab)).

Den Code-Wissensgraphen bauen

Ein AST zeigt eine einzelne Datei in der Tiefe. Das komplexe Geflecht von Beziehungen zwischen den Dateien einer großen Codebasis erfasst er nicht. Um diese Abhängigkeiten abzubilden, baut ihr aus den strukturierten Daten der ASTs einen Code-Wissensgraphen (DZone - Enhancing Code Analysis With Code Graphs (öffnet in einem neuen Tab)). Er stellt das gesamte Softwareprojekt als Netz verbundener Entitäten dar und erlaubt mächtige Abfragen zu Struktur und Auswirkungen.

Der Graph entsteht systematisch:

  1. Schema definieren: Ein Graph-Schema modelliert die Code-Entitäten und ihre Beziehungen. Knotentypen wären etwa Module, File, Class, Function und Variable. Als Beziehungen kämen IMPORTS, DEFINED_IN, CALLS, INHERITS_FROM und INSTANTIATES dazu (FalkorDB - Code Graph: From Visualization to Integration (öffnet in einem neuen Tab)).
  2. Graph aus den ASTs befüllen: Die Ingestion-Pipeline geht den AST jeder Datei durch. Für jeden relevanten AST-Knoten, etwa eine Funktionsdefinition, legt sie einen passenden Function-Knoten im Graphen an. Dann zieht sie Beziehungen entlang der Code-Struktur, etwa eine CALLS-Kante zu einer anderen Funktion oder eine INHERITS_FROM-Kante zur Elternklasse.
  3. Abhängigkeiten ergänzen: Danach reichert ihr den Graphen mit Informationen über externe Abhängigkeiten an. Mit Tools wie der GitHub Dependency Graph API legt ihr Knoten für Bibliotheken von Drittanbietern an. Von den Modulen des Projekts führen dann DEPENDS_ON-Kanten zu diesen externen Paketen (GitHub Docs - About the dependency graph (öffnet in einem neuen Tab)).
  4. Speichern und abfragen: Den fertigen Graphen ladet ihr in eine native Graphdatenbank wie Neo4j. Ihre mächtige und effiziente Abfragesprache, etwa Cypher, durchläuft den Graphen. So beantwortet ihr komplexe Fragen zur Codebasis, an denen andere Methoden scheitern (Neo4j - Generative AI - Ground LLMs with Knowledge Graphs (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Artikel

Dokumentation

Paper und Berichte

Posts

Tools und Repositories