Schicht für Schicht: Entwurf eines echten RAG-Auswertungspipelines für KI-Agenten

Der Ersatz eines Spielzeug-Rückhol-Agenten durch einen echten RAG-Pipeline ist ein guter Zeitpunkt, um langsamer vorzugehen und die Arbeit schrittweise umzusetzen. In einer mehragentigen Unternehmensplattform wurde der RetrievalAgent ursprünglich mit einer absichtlich einfachen lokalen Implementierung betrieben. Das reichte aus, um die Architektur zu beweisen, doch für den Produktivbetrieb sind echte Dokumente, Embeddings, Vektorlagern sowie semantische Suchfunktionen erforderlich. Der Zielablauf führt von den Dokumenten über die Aufnahme, Aufteilung in Blöcke und Erstellung von Embeddings in ChromaDB weiter zu semantischer Suche, dem RetrievalAgent sowie der gesamten Plattform.

Anstatt alles auf einmal zu bauen, wird nach diesem Plan schrittweise ein weiteres Element hinzugefügt, wobei in jeder Phase Tests durchgeführt werden und der CI-Pipeline stets ein grünes Status angezeigt wird. Stetige Verbesserungen, eine funktionierende CI-Infrastruktur sowie eine solide Architektur sind die Ziele.

Die Bestandteile einer RAG-Pipeline

Ein vollständiger Pipeline-Prozess umfasst mehrere unabhängige ingenieurtechnische Aspekte, die in der untenstehenden Darstellung ab den Quelldokumenten dargestellt werden.

Source Documents
       ↓
Document Ingestion
       ↓
    Chunking
       ↓
   Embeddings
       ↓
 Vector Storage
       ↓
Semantic Search
       ↓
Retrieved Context
       ↓
Retrieval Agent

Es ist möglich, alle Komponenten gleichzeitig zu entwickeln, doch dadurch fällt es schwer, Fehler eindeutig zu identifizieren. Wenn die Qualität der Abrufvorgänge schlecht ist, wo liegt dann das Problem? Es könnte am Dokumentparsing, an der Aufteilung in Blöcke, an den Embeddings, der Vektorlagerei, der Abfragenlogik, den Metadaten oder der Integration des Agents liegen. Wenn jeder Schicht eine klare Verantwortung, einen Vertrag sowie Grenzen für Tests zugewiesen werden, lassen sich diese Fragen beantworten. Der Arbeitsrhythmus besteht aus Entwickeln, Testen, Hochladen, Validieren im CI-Prozess, Aufrechterhaltung des Funktionierens und anschließendem Weitermachen.

Beginnen Sie mit dem Datenschema

Vor der Verwendung von Embeddings oder ChromaDB ist die Erstellung des Datenschemas die erste Aufgabe. Der Pipeline muss zwei Konzepte voneinander unterscheiden: SourceDocument und DocumentChunk.

Ein SourceDocument bezeichnet die ursprüngliche Wissensquelle vor der Aufteilung. Es kann sich dabei um eine PDF-, DOCX- oder TXT-Datei, interne Dokumentation, Finanzberichte, Unternehmensrichtlinien, technische Handbücher oder Inhalt aus einer Wissensdatenbank handeln. Seine konzeptionelle Struktur sieht wie folgt aus:

SourceDocument
 ├── document_id
 ├── content
 ├── source
 └── metadata

Jedes ursprüngliche Dokument erhält somit eine stabile Identität innerhalb der Sucharchitektur.

Größere Unternehmensdokumente sollten normalerweise nicht als ein einziger großer Textblock eingebettet werden. Sie müssen in kleinere, sinnvolle Einheiten aufgeteilt werden – und genau das ist die Aufgabe von DocumentChunk:

DocumentChunk
 ├── chunk_id
 ├── document_id
 ├── content
 ├── source
 ├── chunk_index
 └── metadata

Die Beziehung zwischen den beiden ist eins-zu-viel:

SourceDocument
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Chunk 0       Chunk 1      Chunk 2
          │            │            │
          └────────────┼────────────┘
                       ↓
                 Same document_id
                  + source metadata

Eine einzige Quelle kann Dutzende oder sogar Hunderte von Fragmenten liefern, doch jedes Fragment enthält einen Link zu seiner ursprünglichen document_id und Quelle. Dieser Link wird entscheidend, sobald semantische Suchverfahren einzelne Fragmente viel größerer Dokumente zurückgeben.

Warum die Nachvollziehbarkeit von Anfang an integriert ist

Stellen Sie sich einen 50-seitigen Finanzbericht vor. Das System kann ihn in Dutzende von Fragmenten aufteilen, und eine semantische Suche könnte nur drei davon zurückgeben. Dennoch muss das System in der Lage sein anzugeben, aus welchem ursprünglichen Dokument die Informationen stammen. Die Rekonstruktion dieser Beziehung nach der Suche ist anfällig, daher sollte sie in jedem Schritt des Prozesses bewahrt werden.

Original Document
       ↓
SourceDocument
       ↓
DocumentChunk
       ↓
Embedding
       ↓
Vector Record
       ↓
Semantic Search
       ↓
RetrievedDocument
       ↓
Original Source

Die Nachvollziehbarkeit ist von Anfang an Teil der Datenarchitektur und keine Nachgedankenlösung.

Testen der Kontrakte

Sobald die Modelle definiert sind, umfassen automatisierte Tests sowohl SourceDocument als auch DocumentChunk. Sie überprüfen, ob die Modelle korrekt konstruiert werden und ob Schlüsselfelder wie Dokument-ID, Quelldaten, Inhalt sowie Chunk-Indizes sich wie erwartet verhalten.

Auf den ersten Blick mag es sich um einen kleinen Meilenstein handeln, doch diese Modelle bilden die Grundlage für den gesamten Abrufprozess:

Document Models
      ↓
   Chunking
      ↓
  Embeddings
      ↓
   ChromaDB
      ↓
  Retrieval
      ↓
    Agents

Ein fehlerhafter Vertrag an der Spitze dieser Kette kann alles darunter beeinträchtigen, weshalb die Datengrundlage geschützt wird, bevor weitere Infrastrukturen darauf aufgebaut werden.

Eine weitere bewusste Entscheidung war es, diese Stufe frei von externen Abhängigkeiten zu halten. Es finden hier weder Aufrufe an OpenAI noch an ChromaDB statt, und die Tests überprüfen lediglich die Dokumentverträge. Dadurch bleibt das schnelle CI-System deterministisch.

Code Change
     ↓
Local Fast Tests
     ↓
Commit
     ↓
Push to GitHub
     ↓
GitHub Actions
     ↓
Clean CI Environment
     ↓
Fast Unit Tests
     ↓
CI PASSED ✅

Das schnelle Suite wächst weiter, während die externen Integrationstests in ihrer eigenen separaten Gruppe bleiben. Die Regel dahinter: Jede neue Schicht wird mit automatischer Absicherung in die Plattform aufgenommen.

Der vollständige Roadmap

Der Vertrag für Dokumente ist lediglich Schicht eins. Hier ist die gesamte Zielarchitektur:

Enterprise Documents
        │
        ▼
     Ingestion
        │
        ▼
      Chunking
        │
        ▼
     Embeddings
        │
        ▼
     ChromaDB
   Vector Storage
        │
        ▼
 Semantic Retrieval
        │
        ▼
 Retrieved Context
        │
        ▼
  RetrievalAgent
        │
        ▼
Multi-Agent Platform

Jede Phase hat eine spezifische Aufgabe und sollte für sich allein verständlich sowie testbar bleiben.

Dann kommt das Chunking

Der nächste Bestandteil ist der Chunking Service, der ein SourceDocument in mehrere DocumentChunk-Objekte umwandelt.

SourceDocument
      │
      ▼
ChunkingService
      │
      ├── DocumentChunk 0
      ├── DocumentChunk 1
      ├── DocumentChunk 2
      └── DocumentChunk N

Im Laufe der Zeit muss der Dienst mit der Größe der Blöcke sowie deren Überschneidungen umgehen, Metadaten und Quellinformationen übertragen, jedem Block einen Index zuweisen sowie stabile Identifikatoren erzeugen. Eine architektonische Besonderheit ist, dass das Aufteilen in Blöcke außerhalb des Retrieval Agents stattfindet. Der Agent nutzt lediglich die Suchfunktionen und sollte nicht auch noch für die Vorbereitung der Dokumente zuständig sein.

Embeddings und Speicherung

Sobald das Aufteilen in Blöcke implementiert und getestet wurde, erzeugt die nächste Schicht Vektor-Embeddings.

DocumentChunk
      ↓
Embedding Service
      ↓
Embedding Model
      ↓
Vector Representation

Jeder Datenblock wird zu einem Vektor, der seine Bedeutung kodiert. Später werden diese Vektoren mit einer eingebetteten Benutzeranfrage verglichen, um verwandtes Material zu finden.

DocumentChunk
      ↓
EmbeddingService
      ↓
Embedding Provider
      ↓
Vector

Das Ändern des Embedding-Modells später sollte den Rest der RAG-Struktur kaum beeinträchtigen.

Nach den Embeddings kommt die persistente Vektorlagerei. Für die lokale Entwicklung kann der persistente Client von ChromaDB das indizierte Wissen über mehrere Neustarts der Anwendung hinweg beibehalten.

DocumentChunk
      +
Embedding
      +
Metadata
      ↓
   ChromaDB
      ↓
Persistent Vector Collection

Ein gespeichertes Datensatz benötigt mehr als nur einen Vektor. Er enthält außerdem genügend Informationen, um Kontext und Nachvollziehbarkeit zu gewährleisten:

Vector Record
 ├── chunk_id
 ├── embedding
 ├── content
 ├── document_id
 ├── source
 ├── chunk_index
 └── metadata

Dadurch liefert die Abfrage einen sinnvollen Dokumentkontext und nicht nur ähnliche Vektoren.

Abfragen

Sobald der Speicher gefüllt ist, kann das System semantische Suche durchführen. Der Abfragenpfad lautet:

User Query
    ↓
Query Embedding
    ↓
ChromaDB Similarity Search
    ↓
Top-K Relevant Chunks
    ↓
Scores + Metadata
    ↓
Retrieved Context

Anstatt sich ausschließlich auf präzise Schlüsselworttreffer zu verlassen, findet die semantische Suche Abschnitte, die konzeptionell mit der Anfrage des Benutzers verbunden sind. Die Ergebnisse werden anschließend in den standardisierten Suchvertrag umgewandelt, den die Plattform bereits verwendet.

Wiederherstellung der Verbindung zum Agenten

Nur wenn die Suchinfrastruktur funktioniert, wird der gesamte Ablauf wieder mit dem RetrievalAgent verbunden. Aus Sicht des Agenten bleibt die Situation einfach:

AgentRequest
     ↓
RetrievalAgent
     ↓
RetrievalService
     ↓
Relevant Documents
     ↓
Structured RetrievalResult

Hinter RetrievalService wird die Implementierung weitaus komplexer:

RetrievalService
      ↓
Query Embedding
      ↓
ChromaDB
      ↓
Semantic Search
      ↓
Ranking
      ↓
Retrieved Context

Die Trennung ist wichtig. Der Abruf-Agent sollte den Abruf als eine Fähigkeit betrachten und nicht über Vector-Datenbanken, die Erstellung von Embeddings, das Speichern in Blöcken oder die Aufnahme von Dokumenten Bescheid wissen müssen.

Der ursprüngliche Agent arbeitete mit lokalen Daten, und die Architektur sah ungefähr so aus:

RetrievalAgent
      ↓
RetrievalService
      ↓
Local Documents

Die Implementierung kann nun in Richtung etwas Umfassenderes weiterentwickelt werden:

RetrievalAgent
      ↓
RetrievalService
      ↓
Semantic Retrieval
      ↓
ChromaDB
      ↓
Embedded Enterprise Documents

Achten Sie darauf, was unverändert bleibt: der Link von RetrievalAgent zu RetrievalService. Nur die Infrastruktur hinter diesem Vertrag ändert sich, und genau deshalb wurde die Abstraktion für das Abrufen von Daten bereits vor dem Erscheinen der Vektordatenbank erstellt. Die Infrastruktur sollte sich frei entwickeln können, ohne dass eine Neugestaltung der Agentenarchitektur erforderlich wird.

In die Plattform integriert

Der RAG-Pipeline existiert nicht für sich allein. Ihr Zweck besteht darin, fundierte Unternehmenskenntnisse dem größeren Mehr-Agenten-System zur Verfügung zu stellen.

User
                          │
                          ▼
                    Supervisor Agent
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                    Execution Plan
                          │
                          ▼
                     Agent Registry
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
       RetrievalAgent  ResearchAgent AnalysisAgent
             │
             ▼
      RetrievalService
             │
             ▼
         RAG Pipeline
             │
             ▼
      Relevant Context
             │
             ▼
       Downstream Agents

In diesem Bild verbindet der Retrieval Agent die Schicht, in der mehrere Agenten ausgeführt werden, mit der Schicht, die das Unternehmenswissen enthält.

Eine Lektion verdient besondere Betonung: RAG bedeutet nicht einfach „eine Vektordatenbank hinzufügen“. Eine solide Sucharchitektur erfordert viele Entscheidungen:

• Dokumentverträge und -eingabe
• Chunking sowie Erstellung von Embeddings
• Vektorlagern und Metadaten
• Semantische Suche und Ranking
• Quellenrückverfolgbarkeit
• Integration von Agenten
• Testing und Überwachbarkeit

Die Vektordatenbank ist nur ein einzelner Bestandteil innerhalb eines weitaus größeren Suchsystems.

Ein absichtlich wiederkehrendes Muster

Der Entwicklungszyklus für diesen Meilenstein ist absichtlich wiederkehrend gestaltet:

Build One Layer
      ↓
Add Unit Tests
      ↓
Run Fast Suite
      ↓
Push to GitHub
      ↓
CI Validates
      ↓
Keep Green
      ↓
Build Next Layer

Es ermöglicht es, dass die Komplexität zunimmt, solange das Vertrauen in das bestehende System erhalten bleibt. Anstatt gleich fünf Komponenten hinzuzufügen und sie gemeinsam zu debuggen, wird jede Funktionalität vor dem Erscheinen der nächsten überprüft.

Das erste Meilenstein des eigentlichen Pipelines ist erreicht: der SourceDocument-Vertrag, der DocumentChunk-Vertrag, Tests für beide Modelle sowie ein erfolgreicher schneller CI-Testlauf. Der weitere Fahrplan lautet:

1. Document Contract             ✅ COMPLETE
          ↓
2. Chunking Service              ← NEXT
          ↓
3. Embedding Service
          ↓
4. ChromaDB Integration
          ↓
5. Semantic Retrieval
          ↓
6. RetrievalAgent Integration
          ↓
7. End-to-End RAG Pipeline

Jede Schicht wird unabhängig implementiert und getestet, bevor man zum nächsten Schritt übergeht.

Warum das wichtig ist

Der erste Retrieval Agent zeigte, dass die Agent-Architektur funktioniert. Das Ziel nun ist es, die vorübergehende Datenabfrage durch echte Infrastruktur zu ersetzen – von lokalen Abfragen über einen Dokumentenpipeline, Chunking, Embeddings, Vektorlagern und semantische Suche bis hin zu einem mit RAG ausgestatteten Agenten. Da der Agent von einer Service-Abstraktion und nicht direkt von ChromaDB abhängt, kann all das ohne Neuentwurf der Multi-Agenten-Plattform umgesetzt werden.

Ein allgemeineres Prinzip gilt: Schaffe stabile Kontrakte um die Komponenten, die voraussichtlich ändern werden. Modelle werden sich ändern, Vektordatenbanken können ausgetauscht werden, Chunking-Strategien werden sich entwickeln und Abfralgorithmen werden verbessert – doch die Plattform dahinter sollte nicht jedes Mal neu geschrieben werden müssen.

Was entwickelt wird, ist eine Abruffunktion, die zu einer unternehmensweiten Multi-Agenten-Plattform gehört – nicht nur eine einmalige RAG-Demo. Dort koordiniert der Supervisor, das Registry löst Funktionen auf, spezialisierte Agenten führen aus, RAG liefert fundiertes Wissen, Tests schützen das Verhalten, CI überwacht jede Änderung und Messungen zur Überwachbarkeit kontrollieren die Produktion. Die Methode bleibt stets gleich: Eine Schicht bauen, testen, einbringen, CI grün halten und anschließend die nächste Schicht entwickeln.