Semantische Suche mit ChromaDB und Embeddings für eine Mehr-Agenten-Plattform

Ein neuer Meilenstein wurde im Projekt Enterprise Multi-Agent AI Platform erreicht: Der Abrufprozess führt nun eine echte semantische Suche durch, wobei Embeddings aus ChromaDB verwendet werden. Die Architektur hat sich von der Dokumentvorbereitung zu einem funktionsfähigen Abrufweg weiterentwickelt, bei dem zunächst SourceDocument, anschließend DocumentChunker, danach EmbeddingService, danach OpenAI Embeddings, danach ChromaDB, gefolgt von der semantischen Suche und schließlich RetrievedDocument ausgeführt werden.

Das stellt einen bedeutenden Entwicklungsfortschritt dar. Die Plattform bereitet nicht mehr nur Dokumente vor und erzeugt Embeddings. Sie kann vektorisiertes Unternehmenswissen speichern, es nach Bedeutung durchsuchen, die relevanten Teile bewerten und strukturierte Ergebnisse liefern. Bei der Entwicklung traten außerdem einige Probleme bezüglich der Abrufqualität auf, die behoben werden mussten, bevor der Prozess mit dem RetrievalAgent verbunden werden konnte.

Der Prozess nimmt Form an

Die Abrufarchitektur ist wie folgt aufgebaut:

Enterprise Documents
        │
        ▼
   SourceDocument
        │
        ▼
 DocumentChunker
        │
        ▼
  DocumentChunk[]
        │
        ▼
 EmbeddingService
        │
        ▼
 OpenAI Embeddings
        │
        ▼
     ChromaDB
        │
        ▼
 Semantic Search
        │
        ▼
RetrievedDocument[]
        │
        ▼
  RetrievalAgent

Jede Schicht hat eine einzige Verantwortung – und das ist beabsichtigt. Das Ziel war niemals eine einzige große RAG-Funktion, die Dateien lädt, Texte aufteilt, Embeddings erstellt, eine Vektordatenbank verwaltet, Suchvorgänge durchführt und schließlich eine Antwort liefert. Stattdessen setzt sich das System aus klaren architektonischen Grenzen zusammen.

Phase 1: Quelldokumente

Alles beginnt mit dem Unternehmenswissen. Im Laufe der Zeit kann dieses Wissen aus PDF-, DOCX- und TXT-Dateien, Finanzberichten, internen Richtlinien, technischer Dokumentation, Forschungsmaterialien sowie Unternehmenswissensdatenbanken stammen. Das SourceDocument-Modell verleiht diesem Material vor dem Eintreten in den Prozessablauf eine einheitliche Struktur. Konzeptionell sieht es so aus:

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

Das hier wichtige Prinzip ist die Nachvollziehbarkeit. Alles, was später abgerufen wird, muss weiterhin auf die Quelle zurückverfolgbar sein.

Phase 2: Aufteilung in Blöcke

Größe Dokumente sollten im Allgemeinen nicht als ein einziger Block eingebettet werden. Der DocumentChunker teilt jedes SourceDocument in kleinere Teile auf, die für die Abrufung bereit sind:

SourceDocument
      │
      ▼
DocumentChunker
      │
      ├── Chunk 0
      ├── Chunk 1
      ├── Chunk 2
      └── Chunk N

Jeder Chunk behält seinen chunk_id, document_id, content, source, chunk_index sowie die Metadaten bei. Somit kann die semantische Suche mit kleinen Informationseinheiten arbeiten, ohne den Zusammenhang zum ursprünglichen Dokument zu verlieren.

Verbesserung der Chunk-Qualität

Durch Ausführung des eigentlichen Abrufprozesses wurde ein Problem aufgedeckt. Das auf Zeichen basierende Chunking kann bei gewöhnlichen Texten an unpassenden Stellen unterbrechen, manchmal sogar mitten in einem Wort. Eine Grenze kann konzeptionell dazu führen, dass ein Chunk so endet:

...important financial risks for

danach folgt ein Abschnitt, der so beginnt:

the upcoming quarter...

Oder, im schlimmsten Fall, eine Trennung mitten in einem Wort. Solche Abschnitte sind technisch gesehen gültig, doch die Qualität der Extraktion hängt von mehr als nur gültigen Datenstrukturen ab. Die Grenzen bestimmen die semantische Qualität dessen, was eingebettet wird.

Daher wurde die Strategie zur Aufteilung in Abschnitte so geändert, dass bei normaler Prosa Wortgrenzen bevorzugt werden, während für Texte ohne nützlichen Leerlauf eine Rückfalllösung mit Zeichengrenzen verwendet wird. Der Aufteilungsmechanismus verfügt nun über zwei Verhaltensweisen:

Normal prose
    ↓
Prefer word-aware boundaries

Text without whitespace
    ↓
Fallback to character boundaries

Es handelt sich um ein kleines Implementierungsdetail mit einer wichtigen architektonischen Lektion: Das Bestehen von Tests bedeutet nicht, dass die Qualität der Abfrage gut ist, und echte Daten bringen Probleme zum Vorschein, die isolierte Unit-Tests nicht immer aufzeigen können.

Phase 3: Embeddings

Sobald die Fragmente bereit sind, wandelt der EmbeddingService ihren Text in numerische Vektoren um.

DocumentChunk
      │
      ▼
EmbeddingService
      │
      ▼
Embedding Model
      │
      ▼
Vector Representation

Die Dienstplattform unterstützt Einzeltext-Embeddings für Abfragen sowie Batch-Embeddings für Dokumentteile. Ein früherer lokaler Integrationstest bestätigte eine Vektordimension von 1.536. Die Zahl selbst ist weniger wichtig als die Tatsache, dass die Implementierung der Embeddings hinter einer Dienstgrenze bleibt, sodass der Retrieval Agent niemals wissen muss, wie Vektoren erzeugt werden.

Phase 4: ChromaDB-Vektorlagern

Die nächste Ebene ist das persistente Vektorlagern. Jeder Dokumentteil kann nun zusammen mit seinem Vektor und Metadaten gespeichert werden. Konzeptionell gesehen:

DocumentChunk
      +
Embedding
      +
Metadata
      │
      ▼
   ChromaDB
      │
      ▼
Persistent Vector Collection

Ein Vektordatensatz kann Informationen wie folgende speichern:

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

Ein reiner Vektor ist für den Rest der Anwendung nutzlos. Die Plattform benötigt den eigentlichen Inhalt zurück und muss wissen, woher dieser Inhalt stammt.

Phase 5: semantische Suche

Durch die in ChromaDB gespeicherten eingebetteten Fragmente kann das System semantische Abfragen durchführen. Der Abfragepfad sieht wie folgt aus:

User Query
     │
     ▼
EmbeddingService
     │
     ▼
Query Embedding
     │
     ▼
   ChromaDB
     │
     ▼
Similarity Search
     │
     ▼
Top-K Relevant Chunks
     │
     ▼
RetrievedDocument[]

Die Dokumentensuche hat sich von der Suche nach Dokumenten verändert, die genau diese Wörter enthalten, zur Suche nach Abschnitten, deren Bedeutung am besten zur Anfrage passt. Das ist eine der zentralen Fähigkeiten hinter RAG.

Korrektur der Ähnlichkeitsmetrik

Reale Tests brachten ein weiteres Problem zutage. Vektordatenbanken unterstützen unterschiedliche Distanz- oder Ähnlichkeitsmetriken, und wenn die Sammlung eine Metrik verwendet, während die Anwendung die zurückgegebene Distanz als eine andere interpretiert, wird der Relevanzwert irreführend. Für diesen Workflow wurde die ChromaDB-Sammlung ausdrücklich für die Kosinus-Distanz konfiguriert, sodass die Suchschicht die Ergebnisse stets als auf der Kosinus-Ähnlichkeit basierend lesen kann.

Query Embedding
      │
      ▼
ChromaDB
      │
      ▼
Cosine Distance
      │
      ▼
Similarity Score
      │
      ▼
Ranked Results

Semantische Suche geht nicht nur darum, Dokumente zurückzugeben. Sie beinhaltet auch das Verständnis dafür, wie relevant diese sind.

Echte Suchergebnisse

Nach der Aufteilung in Blöcke und den Anpassungen bezüglich der Ähnlichkeit wurde der Prozess mit einer echten Abfrage zu Finanzrisiken getestet. Die gerankten Ergebnisse wiesen Ähnlichkeitswerte von etwa 0,6181, 0,5520 und 0,4198 auf, und der abgerufte Kontext enthielt die relevanten Informationen zu Liquiditätsrisiken und Marktvolatilität. Der Prozess schaffte somit den gesamten Weg bis hierhin:

Question
   ↓
Query Embedding
   ↓
ChromaDB
   ↓
Semantic Similarity
   ↓
Relevant Chunks
   ↓
Financial Risk Context

Zu diesem Zeitpunkt hörte die Infrastruktur zur Informationsabrufung auf, nur eine Einrichtungsarbeit zu sein, und begann, echtes semantisches Wissensabrufen zu zeigen.

Warum echte Abfruchtests wichtig sind

Simulierte Unit-Tests bleiben äußerst wertvoll. Sie gewährleisten Geschwindigkeit, Determinismus, Sicherheit in der kontinuierlichen Integration, keinerlei externe API-Kosten, kontrollierte Fehlerfälle sowie Isolation der Anwendungslogik. Allerdings können sie nicht auf jede Frage eine Antwort geben. Ein simulierter Test kann lediglich bestätigen, dass etwas strukturell funktioniert:

EmbeddingService
      ↓
Expected Vector

Aber es kann nicht vollständig zeigen, dass die folgende Kette ein gutes Abrufverhalten liefert:

Real Document
      ↓
Real Chunking
      ↓
Real Embedding
      ↓
Real Vector Database
      ↓
Real Semantic Query
      ↓
Useful Context

Daher trennt die Teststrategie mehrere Ebenen der Validierung voneinander.

Teststrategie

Die Plattform entwickelt sich in Richtung drei komplementärer Testebenen.

Unit-Tests sind schnell und deterministisch und gehören in den normalen CI-Pipeline-Prozess:

Application Logic
      ↓
Mock External Dependencies
      ↓
Controlled Results
      ↓
Assertions

Integrationstests überprüfen die echte Infrastruktur und können unabhängig von dem schnellen CI-Stack ausgeführt werden:

Application
      ↓
Real Embedding Provider
      ↓
Real ChromaDB
      ↓
End-to-End Retrieval

Im Laufe der Reifung der Plattform werden Tests zur Leistung und Widerstandsfähigkeit notwendig:

Realistic Workload
      ↓
Concurrent Requests
      ↓
Latency
Throughput
Rate Limits
Failures
Cost
Scalability

Ein für die Produktion bereites KI-System benötigt alle drei Aspekte. Das Simulieren externer Dienste in Unit-Tests ersetzt keine Integrationstests, und Integrationstests ersetzen wiederum keine Leistungsprüfungen. Jede Schicht beantwortet eine andere ingenieurtechnische Frage.

CI bleibt erfolgreich

Nach den Verbesserungen bei der Datenabfrage ist das schnelle Testset weiterhin in Ordnung – 17 Tests bestehen, und 2 Integrationstests wurden ausgeblendet. Das ist wichtig, denn der RAG-Pipeline wird immer komplexer, ohne dass die deterministische CI-Validierung aufgegeben werden muss. Der Entwicklungszyklus setzt sich wie folgt fort:

Code Change
     ↓
Fast Unit Tests
     ↓
Commit
     ↓
Push
     ↓
GitHub Actions
     ↓
CI Validation
     ↓
Keep Green

Tests gegen echte Dienste bleiben als separate Ausführung verfügbar.

Vernetzung von RAG mit der Multi-Agenten-Plattform

Die Abrufinfrastruktur existiert nicht isoliert. Sie soll die Wissensschicht für das größere Multi-Agenten-System bilden, und die übergeordnete Architektur entwickelt sich in diese Richtung:

User
                          │
                          ▼
                    Supervisor Agent
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                    Execution Plan
                          │
                          ▼
                     Agent Registry
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
      RetrievalAgent ResearchAgent AnalysisAgent
             │
             ▼
      RetrievalService
             │
             ▼
      EmbeddingService
             │
             ▼
          ChromaDB
             │
             ▼
      Semantic Search
             │
             ▼
      Relevant Context
             │
             ▼
       Downstream Agents

Dies ist der Punkt, an dem RAG und Multi-Agent-Orchestrierung zu verschmelzen beginnen.

Den Retrieval-Agenten einfach halten

Eines der zentralen Ziele ist es, den RetrievalAgent darauf zu konzentrieren, seine eigene Aufgabe zu erledigen. Er sollte nichts über Chunking-Algorithmen, die Implementierung von Embeddings, Vektordimensionen, die Interna von ChromaDB, Ähnlichkeitsberechnungen oder Speicherkonfigurationen wissen müssen. Stattdessen:

RetrievalAgent
      ↓
RetrievalService
      ↓
VectorStoreService
      ↓
EmbeddingService + ChromaDB

Der Agent fragt nach relevanten Kenntnissen, und die Abrufinfrastruktur entscheidet darüber, wie diese Kenntnisse gefunden werden. Diese Trennung ermöglicht es der zugrundeliegenden Implementierung, sich weiterzuentwickeln, ohne dass der Agent neu geschrieben werden muss.

Nächstes Meilenstein: Ersatz der vorübergehenden Abrufmethode

Der nächste Schritt ist klar. Der Retrieval Agent muss weiterhin direkt mit der eigentlichen Abrufinfrastruktur verbunden sein. Derzeit sieht das so aus:

BEFORE

RetrievalAgent
      ↓
Temporary Local Documents

Und das Ziel ist folgendes:

NEXT

RetrievalAgent
      ↓
RetrievalService
      ↓
VectorStoreService
      ↓
EmbeddingService
      ↓
ChromaDB
      ↓
Semantic Search
      ↓
Enterprise Knowledge

Nach dieser Integration hört der Agent auf, vorläufige, fest kodierte Ergebnisse zurückzugeben, und bezieht sein Wissen aus der tatsächlichen, indizierten Dokumentensammlung.

Von der Infrastruktur zur Mehr-Agenten-Ausführung

Diese Integration markiert einen weiteren Übergang. Der größte Teil der bisherigen Arbeit galt dem Aufbau der Abrufinfrastruktur. Sobald RetrievalAgent den eigentlichen semantischen Pipeline-Prozess nutzt, kann die Architektur Workflows wie diesen unterstützen:

User Request
      ↓
Supervisor
      ↓
Planning Agent
      ↓
Execution Plan
      ↓
Retrieval Agent
      ↓
Enterprise Knowledge
      ↓
Analysis Agent
      ↓
Report Agent
      ↓
Quality Review
      ↓
Final Response

RAG wird dann zu einer Funktion innerhalb eines umfassenderen Mehr-Agenten-Exekutionsystems und ist nicht mehr eine eigenständige Suchfunktion.

Die zukünftige Entwicklung

Der Entwicklungsplan für die Suche entwickelt sich von grundlegenden Komponenten hin zu produktorientierten Funktionen:

Document Contracts               ✅
        ↓
Chunking                         ✅
        ↓
Embeddings                       ✅
        ↓
ChromaDB Vector Storage          ✅
        ↓
Semantic Search                  ✅
        ↓
RetrievalAgent Integration       ← NEXT
        ↓
Reranking
        ↓
Caching & Cost Controls
        ↓
Observability & Metrics
        ↓
Multi-Tenant Isolation
        ↓
Production Hardening

In den späteren Phasen gewinnt die Bedeutung zu, da sich die Plattform von einer funktionalen Architektur hin zu einem Unternehmensbetrieb entwickelt.

Produktionsfähige RAG-Plattformen benötigen mehr als nur die Informationsabrufung

Die Extraktion relevanter Datenblöcke aus ChromaDB ist ein Meilenstein, aber nicht das Ende der Architektur. Eine produktionsfähige Informationsabrufungsplattform muss letztendlich folgende Aspekte berücksichtigen:

• Neubewertung der Reihenfolge, da die anfängliche Vektorähnlichkeit nicht immer die beste Sortierung liefert.
• Caching, da wiederholte Embeddings und Suchanfragen zu Verzögerungen und Kosten führen.
• Überwachbarkeit, damit Latenzzeiten bei der Informationsabrufung, bei den Embeddings, die Anzahl der Dokumente, Scores, Fehler sowie Kosten gemessen werden können.
• Entwicklung von Modellen und Vektorräumen, da der Wechsel von Embedding-Modellen möglicherweise versionierte Indizes sowie kontrolliertes Neu-Embedding erfordert.
• Bearbeitung von Rate-Limits, da externe KI-Anbieter betriebliche Einschränkungen auferlegen, die nicht deterministisch sind.

Mehrfachnutzer-Isolation, da Unternehmensdaten keine unbegrenzten Abrufgrenzen teilen dürfen.

Schema-Verträge, was stabile Schnittstellen zwischen den Eingabeschicht, Einbettungsschicht, Speicherschicht, Abrufschicht und Agentenschicht bedeutet.

Leistungsprüfungen unter realistischen Konkurrenzsituationen und Datenvolumina.

Diese Punkte gehören in den Entwicklungsplan, sollten jedoch innerhalb stabiler Grenzen hinzugefügt werden und nicht von Anfang an in eine einzige große Implementierung integriert werden.

Das ingenieurwissenschaftliche Prinzip

Die wichtigste Lektion dieser Phase: Zuerst die Abstraktion entwerfen, das Verhalten anhand echter Daten überprüfen und anschließend die Produktionsfunktionen im Laufe des Wachstums der Architektur weiter verfestigen. Der Fortschritt war beabsichtigt:

Data Contract
     ↓
Chunking
     ↓
Unit Testing
     ↓
Embeddings
     ↓
Mocked Provider Testing
     ↓
Real Integration Validation
     ↓
Vector Storage
     ↓
Semantic Retrieval
     ↓
Retrieval Quality Improvements
     ↓
Agent Integration

Jede Phase bringt eine andere Art von Problem zum Vorschein, und genau deshalb lohnt sich die schrittweise Architektur.

Von Dokumenten zur Mehr-Agenten-Ausführung

Das größere Bild wird immer klarer:

Enterprise Knowledge
        ↓
Document Processing
        ↓
Chunking
        ↓
Embeddings
        ↓
Vector Storage
        ↓
Semantic Retrieval
        ↓
Retrieval Agent
        ↓
Multi-Agent Orchestration
        ↓
Analysis + Research + Reporting
        ↓
Quality Review
        ↓
Grounded Enterprise Response

RAG ist nicht die gesamte Plattform. Es handelt sich um die Wissensinfrastruktur, die es spezialisierten Agenten ermöglicht, im Kontext des Unternehmens zu arbeiten.

Derzeitiger Meilenstein

Was heute vorhanden ist: einheitliche Dokumentmodelle, einfaches sowie textgrenzenbewusstes Aufteilen in Abschnitte, ein Embedding-Dienst mit simulierten Unit-Tests sowie einer echten Validierungsphase, persistente ChromaDB-Speicherung mit explizit festgelegter Kosinusähnlichkeit, semantische Suche, die gerankte Ergebnisse zurückgibt, sowie ein schnelles Set aus 17 bestandenen Tests. Der nächste Meilenstein ist die Verbindung von RetrievalAgent mit dem eigentlichen semantischen Abrufprozess – ab diesem Punkt hört das System auf, lediglich einen RAG-Untersystem zu enthalten, und beginnt mit der Ausführung mehrerer Agenten unter Nutzung von RAG.

Unter Enterprise AI versteht man nicht einfach das Einbinden eines LLM in eine Vektordatenbank und den Sieg zu verkünden. Schichten benötigen Verträge, Verträge erfordern Tests, Integrationen brauchen echte Validierung und das System muss Raum zum Weiterentwickeln haben. Der Prozesspfad hat sich von Dokumenten, Blöcken, Embeddings und Vektoren zu Dokumenten, Blöcken, Embeddings, ChromaDB, semantischer Suche sowie relevantem Unternehmenskontext entwickelt. Als Nächstes wird dieser Kontext in den RetrievalAgent fließen und anschließend in die mehragentige Ausführung. Der Arbeitszyklus bleibt unverändert: entwickeln, testen, messen, verbessern, integrieren und skalieren.