Die RAG Stack-Entwickler, die tatsächlich verwendet werden.

RAG-Systeme erscheinen magisch, bis sie selbstbewusst die falsche Frage beantworten. Die meisten Fehler lassen sich auf einen einzigen Übeltäter zurückführen: reine semantische Suche. Sie betten Ihre Dokumente ein, führen eine Vektorähnlichkeitsabfrage durch und hoffen, dass das nächstgelegene Segment das genaue Faktum enthält, das Sie benötigen. Zu oft ist dem nicht so.

Einbettungsmodelle glänzen bei unscharfen Bedeutungen, nicht bei chirurgischer Präzision. Sie komprimieren Absätze in 768- oder 1.536-dimensionale Vektoren, die hochrangige Konzepte über exakte Tokens betonen. Dieser Kompromiss führt dazu, dass sie regelmäßig Details wie Teilenummern, Daten, rechtliche Zitationen und Funktionsnamen in „ähnlich genug“ Nachbarschaften verwischen.

Fragen Sie einen typischen RAG-Stack: „Wie hoch war unser Umsatz im Jahr 2025?“ und beobachten Sie, wie er mit Überzeugung halluziniert. Die Einbettung für diese Frage liegt sehr nah an Abschnitten, die „Umsatz 2023“ oder „prognostizierter Umsatz in den nächsten drei Jahren“ behandeln. Semantische Ähnlichkeit besagt, dass diese nahezu identisch sind; Ihr System gibt fröhlich die Zahlen von 2023 zurück, als kämen sie aus 2025.

Dieses Verhalten ist kein Fehler in den Embeddings; es ist das Design. Modelle, die auf allgemeinem Text trainiert wurden, optimieren für konzeptionelle Übereinstimmung: „Umsatzwachstum im Jahr 2023“ und „Umsatzprognose für 2025“ teilen sich die meisten ihrer Signale. Das Modell behandelt das Jahr als ein nebensächliches Detail, obwohl es in den Bereichen Finanzen, Recht oder Ingenieurwesen oft die Antwort ist.

Der gleiche Fehlermodus tritt auch bei anderen hochpräzisen Anfragen auf. Fragen Sie nach: - „Abschnitt 3.2.1 des Vertrags“ - „Fehlercode 0x80070005“ - „Funktion init_user_session in auth.py“

Eine reine semantische Suche bringt oft verwandte Konzepte ans Licht – „Kündigungsklausel“, „Zugriffsverweigerungsfehler in Windows“, „Benutzersitzungsinitialisierung“ – anstelle der genauen Klausel, des Fehlercodes oder der Funktionsdefinition, die Sie tatsächlich benötigen.

Unternehmensteams spüren dies besonders stark. Compliance-Tools müssen §230 von §320 unterscheiden. Unterstützungscopiloten müssen SKU-AX12B von SKU-AX21B differenzieren. Interne Ingenieurbots dürfen die Versionshinweise von v1.2.3 und v1.3.2 nicht verwechseln. Eine einzige vertauschte Ziffer kann ein anderes Produkt, Gesetz oder API bedeuten.

Kernproblem: RAG-Stacks streben nach konzeptionellem Verständnis, während sie in Präzision unterinvestieren. Ohne Mechanismen, die genaue Strings, Zahlen und Bezeichner respektieren, verhält sich Ihr „Wissenassistent“ eher wie ein meinungsstarker Autocomplete als wie ein vertrauenswürdiges Retrieval-System.

Hybridsuche behebt leise die meisten Probleme, die bei naivem RAG auftreten. Anstatt alles auf unscharfe Einbettungen zu setzen oder sich an brüchige Schlüsselwortfilter in Microsoft Word zu klammern, führt sie semantische Suche und Schlüsselwortsuche in Microsoft Word gleichzeitig für jede Abfrage aus und kombiniert die Ergebnisse. So erhalten Sie konzeptionelles Verständnis und exakte Zeichenkettenübereinstimmung in einem einzigen Durchgang.

Semantische Suche glänzt bei „finde mir ähnliche Dinge“, selbst wenn sich die Microsoft-Wortwahl verändert. Frage: „Wie behandelt dieser Vertrag die vorzeitige Kündigung?“ und die Vektorsuche wird Klauseln hervorheben, die nie den Begriff „vorzeitige Kündigung“ verwenden, aber dieselbe Idee beschreiben. Die Microsoft Word-Suche hingegen findet genaue Formulierungen, IDs, Zahlen und seltene Fachbegriffe, die von Einbettungen regelmäßig in Rauschen verwandelt werden.

Hybrid-Suche hält beide Engines jederzeit online. Für jede Frage berechnet das System ein Abfrage-Embedding, führt eine Vektorsimilaritäts-Suche durch und führt zudem eine Text- oder Schlüsselabfrage über dasselbe Korpus aus. Ein Rang-Fusionsschritt—MongoDB liefert dafür einen speziellen $rankFusion Operator—führt die beiden sortierten Listen in eine einzige, zuverlässigere Menge von Abschnitten zusammen.

Die Regel „immer beide verwenden“ ist wichtiger als welches LLM oder welches Embedding-Modell Sie wählen. Reine semantische Pipelines halluzinieren spezifische Details: Rechnungsnummern, Fehlercodes, Funktionsnamen. Reine Schlüsselwörter-Pipelines verpassen Paraphrasen und höherstufige Fragen wie „Vergleiche die Risikosektionen in diesen drei Verträgen.“ Hybride Suche deckt beide Aspekte ab, ohne dass die Nutzer zwischen Modi umschalten oder spezielle Syntax erstellen müssen.

Die Referenzarchitektur von Cole Medin zeigt, wie wenig Maschinenleistung man tatsächlich benötigt. Ein Python-Agent, der mit PydanticAI, MongoDB und Docling entwickelt wurde, verarbeitet PDFs, Microsoft Word-Dokumente, Markdown und mehr, und speichert dann die in Abschnitte unterteilten Texte sowie Embeddings in einer einzigen MongoDB-Sammlung. Jede Abfrage verteilt sich sowohl auf die MongoDB Atlas Vektorsuche als auch auf die klassische Textsuche und wird dann zusammengeführt, bevor das LLM jemals den Kontext sieht.

Diese eine architektonische Entscheidung – immer hybrides Retrieval zu verwenden – stabilisiert das Verhalten von RAG in fast jedem Anwendungsfall dramatisch: rechtliche Überprüfungen, Kundenservice, interne Wikis, sogar unstrukturierte technische Dokumente. Man hört auf, das „semantisch vs. Schlüsselwort“ als binäre Wahl zu diskutieren und beginnt, sie als ergänzende Signale zu betrachten. Die Genauigkeit steigt, die Varianz sinkt, und Ihre RAG lügt nicht mehr so oft.

Die meisten RAG-Tutorials ertränken Sie in Mikroservices und Orchestrierungs-Frameworks. Dieses Stack geht in die entgegengesetzte Richtung: drei bewegliche Teile, von Anfang bis Ende. MongoDB, Pydantic AI und Docling bilden eine kompakte Pipeline, die dennoch auf Millionen von Fragmenten und Dutzende gleichzeitiger Agenten skalierbar ist.

MongoDB steht im Zentrum als ein einheitlicher Speicher für alles: rohe Dokumente, in Abschnitte unterteilte Texte, Einbettungen und Metadaten. Eine Sammlung kann Textabschnitte, einen 1.536-dimensionalen Einbettungsvektor, Informationen zur Quelldatei und Seitenzahlen enthalten, alles indiziert mit Atlas Vector Search und klassischer Textsuche. Diese eine Datenbank ermöglicht dann hybride Suche, unscharfe Übereinstimmung und Reciprocal Rank Fusion ohne eine separate Vektor-Datenbank.

Pydantic AI verarbeitet das Agenten-Gehirn, ohne einen vollwertigen Workflow-Engine einzubeziehen. Sie definieren Werkzeuge als einfache Python-Funktionen, integrieren sie in einen Agenten und lassen das Framework Modellaufrufe, Wiederholungen und strukturierte Ausgaben verwalten. Das typ-first Design sorgt dafür, dass Abfrageergebnisse aus MongoDB als validierte Modelle ankommen, anstatt als fragile Diktate, und spiegelt damit die Muster im offiziellen Pydantic AI – RAG Beispiel wider.

Docling schließt den Kreis bei der Eingabe, wo die meisten RAG-Projekte oft scheitern. Es analysiert PDFs, Microsoft Word-Dokumente, Markdown und sogar Audio-Transkripte in strukturierten Text mit Überschriften, Tabellen und Layout-Hinweisen. Diese Struktur fließt direkt in Doclings hybrides Chunking ein, sodass Sie semantisch kohärente Abschnitte anstelle von zufälligen 500-Token-Stücken speichern.

Zusammen bilden diese drei Tools ein goldenes Dreieck für die Produktions-RAG. MongoDB bietet langlebigen Speicher und schnelle hybride Abfrage, Pydantic AI orchestriert Agenten und Tools auf eine saubere Weise, und Docling gewährleistet zuverlässige Eingabedaten. Sie erhalten einen Stack, der in ein einziges Python-Repository passt, lokal oder in der Cloud läuft und sich an nahezu jeden Anwendungsfall anpasst, ohne jeden Monat Komponenten austauschen zu müssen.

MongoDB steht im Mittelpunkt dieses Stacks und fungiert sowohl als primäre Dokumentdatenbank als auch als Vektor-Speicher. Anstatt Embeddings an einen separaten Dienst zu übermitteln, ermöglicht Ihnen die MongoDB Atlas Vektor-Suche, hochdimensionale Vektoren direkt an die gleichen Dokumente anzuhängen, die Ihren analysierten Inhalt, Metadaten und Chunk-Referenzen enthalten. Eine Sammlung speichert alles: Chunk-Text, Embedding-Arrays, Dokumenten-IDs, Überschriften und Zeitstempel.

Dieses einheitliche Systemdesign beseitigt leise eine gesamte Klasse von Kopfschmerzen. Kein Pinecone, Weaviate oder maßgeschneiderter Vektorcluster, den man bereitstellen, sichern und überwachen muss; keine Synchronisierungsjobs, um deine operativen Daten und Embeddings aktuell zu halten. Wenn Docling eine neue Microsoft Word-Datei oder PDF importiert und der Agent Embeddings generiert, landen diese Schreibvorgänge an einem Ort, unter einem Konsistenzmodell, mit einer einzigen Backup-Strategie.

Betrieblich ist das wichtiger als jedes Benchmark-Diagramm. Teams, die bereits MongoDB für ihre Anwendungsdaten nutzen, können Atlas Vector Search nahtlos integrieren, ohne neue Infrastruktur oder Anbieter in ihr Bedrohungsmodell aufzunehmen. Die rollenbasierte Zugriffskontrolle, VPC-Peering, Verschlüsselung im Ruhezustand und Auditing gelten gleichermaßen für rohe Dokumente und deren Embeddings, sodass Sicherheitsteams nicht zwei verschiedene Berechtigungssysteme verfolgen müssen.

Datenkonsistenz wird auf die beste Weise ebenfalls langweilig. Sie vermeiden doppelte Schreibvorgänge in der „Dokumenten-Datenbank“ und der „Vektor-Datenbank“, verhindern Wettlaufbedingungen zwischen der Eingabe und der Indizierung und umgehen im Hintergrund arbeitende Synchronisationsprozesse, die unvermeidlich um 2 Uhr morgens fehlschlagen. Eine einzige Schreibtransaktion kann den Textfragment, sein Einbettung und alle denormalisierten Metadaten aktualisieren, was die RAG-Antworten mit der tatsächlichen Quelle der Wahrheit in Einklang hält.

Hybride Suche lebt direkt in MongoDBs Aggregation-Pipeline. Eine typische Abfrage führt ein `$vectorSearch` auf dem Embedding-Feld durch, um semantisch relevante Abschnitte zu erfassen, und kombiniert es dann mit lexikalischen Operatoren wie `$search`, `$text` oder `$regex` für präzise Ergebnisse auf Microsoft Word-Niveau. Sie können beides in einer Pipeline ausführen und die Ergebnisse mit benutzerdefinierter Bewertungslogik oder MongoDBs `$rankFusion`-Operator zusammenführen.

Dieser Fusionsschritt gibt Ihnen eine feinkörnige Kontrolle. Sie können exakte Übereinstimmungen für Fehlermeldungen oder IDs anheben, ältere Dokumente abwerten oder nach Feldern wie `doc_type` und `tenant_id` filtern, bevor das LLM jemals ein Token sieht. All dies läuft serverseitig, nah an den Daten, was die Latenz niedrig hält und die Behauptung des „einfachen Stacks“ über Marketing hinaus begründet.

Pydantic AI fügt sich in dieses Stack als das Agenten-Framework ein, aber ihre geheimen Waffen sind die Abstammung. Sie stammt von Pydantic, der Datenvalidierungsbibliothek, die stillschweigend Tausende von Python-Backends, FastAPI-Apps und internen Tools antreibt. Dieses Erbe bedeutet starke Typisierung, strenge Schemas und vorhersehbares Verhalten anstelle von impulsbasierter Eingabemanipulation.

Wo LangChain blüht, schneidet Pydantic AI. LangChain bietet Dutzende von Abstraktionen – Ketten, Ausführbare, Executor, Retriever – die sich anfühlen können wie eine domänenspezifische Sprache über Python. Pydantic AI bleibt näher an der Sprache: Du schreibst normale Funktionen, definierst klare Ein- und Ausgabemodelle und überlässt dem Framework die Verwaltung der LLM-Aufrufe und der Werkzeugverbindungen.

Ein Pydantic AI „Werkzeug“ sieht aus wie idiomatisches Python, nicht wie Framework-Magie. Konzeptionell könnte ein hybrides Suchwerkzeug für MongoDB so aussehen:

• 1Ein Pydantic-Modell, das die Argumente des Tools beschreibt (Abfragezeichenfolge, Limit, Filter)
• 2Eine einfache asynchrone Funktion, die eine MongoDB-Aggregation mit Vektor- und keyMicrosoft Word-Stufen ausführt.
• 3Ein Pydantic-Modell für den Rückgabewert (Chunks, Scores, Metadaten)

Das Framework stellt dann diese Funktion dem Modell als ein typisiertes Werkzeug zur Verfügung, sodass das LLM sie mit strukturierten Argumenten anstelle von rohen JSON-Daten aufruft.

Typensicherheit wird zu einem echten Merkmal und nicht nur zu Marketing-Text. Wenn Ihr Tool einen `limit: int = Field(ge=1, le=20)` erwartet, validiert Pydantic AI dies, bevor Ihr Code jemals MongoDB erreicht. Wenn Ihr Agent ein `Response`-Modell mit `answer: str` und `sources: list[str]` zurückgeben muss, erkennen Sie Verstöße sofort, anstatt um 2 Uhr morgens unvollständig analysierte Modellausgaben zu debuggen.

Transparenz könnte das größte Unterscheidungsmerkmal sein. Pydantic AI vermeidet versteckte Planer und undurchsichtige Routing-Diagramme, die entscheiden, wann welches Werkzeug eingesetzt wird. Sie können weiterhin mehrstufige Agenten erstellen, behalten jedoch die explizite Kontrolle darüber, wann das Modell sucht, wann es schreibt und wie es Schleifen bildet, indem Sie den normalen Python-Kontrollfluss verwenden.

Für viele RAG-Projekte – Dashboards, interne Wissensbots, Codierungsassistenten – trifft Pydantic AI den richtigen Nerv. Sie erhalten strukturierte Tools, Streaming, Wiederholungen und mehrstufigen Zustand, ohne ein riesiges Framework zu integrieren oder eine Black Box rückzuentwickeln. Die meisten Teams benötigen nicht die vollständige Graph-Engine von LangChain, um einen zuverlässigen Hybrid-Suchagenten zu liefern; sie brauchen etwas, das sie lesen, debuggen und in einer einzigen Datei erweitern können.

RAG-Systeme stehen und fallen mit ihrer Ingestion-Pipeline. Wenn Ihre PDFs beschädigt werden, Tabellen verschwinden und Überschriften im Fließtext verschwimmen, wird Ihnen keine noch so ausgeklügelte hybride Suche helfen. Schrottige Daten hinein bedeuten irreführende Ergebnisse hinaus, egal wie beeindruckend Ihre Embeddings oder MongoDB-Abfragen aussehen.

Docling zielt direkt auf dieses Engpassproblem ab. Die Bibliothek analysiert unordentliche Dateien aus der realen Welt – PDF, Microsoft Word, Markdown, HTML, sogar Bilder und Audio-Transkripte – und wandelt sie in ein strukturiertes Dokumentenmodell um, anstatt einfach nur einen flachen Textdump zu erzeugen. Diese Struktur bewahrt Seiten, Überschriften, Listen, Tabellen, Beschriftungen und Metadaten, sodass Ihre nachgelagerten Einbettungen tatsächlich verstehen, woher ein Textabschnitt stammt.

Im Hintergrund führt Docling eine Layout-Analyse durch, um Spalten zu trennen, die Lesereihenfolge zu erkennen und Tabellen intakt zu halten, anstatt sie in unzusammenhängende Zeilen zu zerreißen. Es liefert sauberen Text sowie reichhaltige Metadaten wie Seitenzahlen, Abschnittsüberschriften und Elementtypen, die Sie direkt zusammen mit Embeddings in MongoDB speichern können. Wenn Ihr Agent eine Frage beantwortet, können Sie auf „Seite 37, Methodenabschnitt“ verweisen, anstatt auf einen rätselhaften Abschnitt.

Für hybrides RAG wird diese Metadaten zu Abruftreibstoff. Sie können Felder wie `section`, `doc_type` oder `heading` indizieren und sie in einer einzigen Aggregations-Pipeline mit Atlas Vector Search kombinieren. Fordern Sie „Latenzbenchmarks im Anhang“ an, und Ihre Abfrage kann vor der Durchführung der semantischen Suche nach Abschnittsmetadaten filtern, was das Rauschen erheblich reduziert.

Chunking ist der Bereich, in dem Docling still und leise seine Berechtigung verdient. Naive feste Größen der Chunks ignorieren die Struktur des Dokuments und schneiden durch Absätze, Code-Blöcke oder Tabellen. Die hybride Chunking-Strategie von Docling kombiniert semantische Grenzen (Überschriften, Absätze) mit Größenbeschränkungen, sodass Sie Teile erhalten, die sowohl kontextuell kohärent als auch embedding-freundlich sind.

Dieser hybride Ansatz glänzt bei langen technischen Berichten und Handbüchern. Ein einzelnes 100-seitiges PDF kann Hunderte von Abschnitten liefern, die an logischen Einheiten wie „2.3 Authentifizierungsfluss“ ausgerichtet sind, anstatt an willkürlichen Token-Fenstern. Ihr LLM sieht eigenständige Abschnitte mit intakten Diagrammen, Aufzählungslisten und umgebenden Erklärungen, was Halluzinationen reduziert und die Antwortverankerung verbessert.

Das Design von Docling ist absichtlich backend-unabhängig, sodass dieselbe Ingestionspipeline funktioniert, egal ob Sie Embeddings in MongoDB, Postgres oder OpenSearch speichern. Für ein Beispiel außerhalb dieses Stacks, siehe das offizielle Docling – RAG mit OpenSearch Beispiel, das dieselben Parsing- und Chunking-Primitiven gegen eine andere Suchmaschine verwendet.

Rohdokumente gelangen einmal in dieses System und bleiben dann nie wieder „roh“. Dateien aus PDFs, Microsoft Word, Markdown oder HTML durchlaufen Docling, welches das Layout normalisiert, reinen Text extrahiert und Strukturen wie Überschriften, Listen und Tabellen als Metadaten beibehält.

Die Ausgabe von Docling speist einen hybriden Chunker, der Inhalte entlang semantischer und struktureller Grenzen aufschneidet. Jeder Chunk erhält eine ID, einen Verweis auf das Quellendokument, die Position (Seite, Abschnitt) und alle Tags, die Ihnen wichtig sind—Produktname, Kunde, Umgebung—die als einfache Felder neben dem Text gespeichert werden.

Von dort aus wandelt ein dediziertes Embedding-Modell (OpenAI, Cohere oder ein internes Modell) jeden Abschnitt in einen Vektor fester Länge um, der typischerweise 768–3072 Dimensionen umfasst. Der Code erstellt dann ein einzelnes MongoDB-Dokument pro Abschnitt: `{ text, embedding, metadata… }`, indiziert durch die Atlas Vector Search sowie reguläre Text- und Microsoft Word-Indexes.

Die einmalige Eingabepipeline sieht folgendermaßen aus:

• 1Dateien → Docling (analysieren + strukturieren)
• 2Docling-Ausgabe → hybrides Chunking
• 3Chunks → Einbettungsmodell
• 4Chunks + Embeddings → MongoDB-Kollektion

Wenn ein Benutzer eine Frage eingibt, übernimmt ein Pydantic KI-Agent. Er validiert die Anfrage in ein strenges Schema, bereichert sie mit Systemeinstellungen (Temperatur, Werkzeuge) und generiert ein Abfrage-Embedding mit demselben Modell wie bei der Eingabe.

Der Agent sendet eine hybride Suche an MongoDB: eine Phase für Vektorsimilarität, eine für die Text-/Schlüsselwortsuche in Microsoft Word, kombiniert über `$rankFusion` oder eine benutzerdefinierte Bewertungs-Pipeline. MongoDB gibt die top 10–20 eingestuften Abschnitte zurück, vollständig mit Quellmetadaten, sodass die Antworten nachvollziehbar bleiben.

Pydantic AI bündelt diese Inhalte in ein retrieval-unterstütztes Prompt und ruft das LLM auf. Das Modell antwortet ausschließlich mit dem bereitgestellten Kontext, während der Agent die Struktur durchsetzt—JSON-Ausgaben, Zitationen oder Toolaufrufe—bevor die endgültige Antwort in Echtzeit an den Benutzer zurückgestreamt wird.

Hybrid-Suche hört auf, theoretisch zu sein, sobald Sie eine hässliche, spezifische Abfrage darauf werfen. Der Demo-Agent von Cole Medin läuft auf einer kleinen MongoDB-Sammlung, die über Docling befüllt wurde, und beantwortet Fragen live, sodass Sie sehen können, wie semantische und Schlüsselwortsuche von Microsoft Word um die Kontrolle bei jeder Anfrage kämpfen. Die $search-Pipeline von MongoDB führt beide Modi parallel aus und kombiniert die Ergebnisse mit Reciprocal Rank Fusion, sodass der Modus, der ein Datenstück höher einstuft, mehr Einfluss erhält.

Fragen Sie nach "Neuroflow-Umsatz 2025" und beobachten Sie, wie die wichtige Microsoft Word-Suche den gesamten Austausch steuert. Die Abfrageeinbettung für "2025" hilft kaum, da die meisten Einbettungsmodelle Jahre als generische Token behandeln. Die Textsuche von MongoDB hingegen konzentriert sich auf das wörtliche "2025" und nahegelegene finanzielle Begriffe und zeigt eine einzige Tabellenzeile und einen Satz an, die "Neuroflow", "Umsatz" und "2025" zusammen erwähnen.

Reine semantische Suche zu dieser Frage neigt dazu, Prognosen für 2024 oder 2023 oder allgemeine Kommentare zu „zukünftigen Einnahmen“ zu integrieren, da der Vektorraum alle zukunftsgerichtete Finanzsprache gruppiert. Hybride Suche behebt dieses Problem, indem sie der lexikalischen Suche ermöglicht, semantisch ähnliche, aber numerisch falsche Abschnitte abzulehnen. Der Agent führt dann diese präzisen Zeilen in das LLM ein, das sicher die Zahl für 2025 zitieren kann, ohne eine Zahl zu halluzinieren.

Ändern Sie die Abfrage zu "Zeitplan für den Converse Pro-Launch" und kehren Sie die Rollen um. Die Quellpräsentation verwendet Überschriften wie "Launch-Plan" und "Go-to-Market-Zeitplan" und niemals den Microsoft Word "Zeitplan". Ein naives Microsoft Word-Tool würde den relevanten Abschnitt völlig übersehen oder sich auf irgendeine zufällige Erwähnung von "Launch" stützen.

Die semantische Suche über MongoDB Atlas Vector Search versteht, dass „Zeitlinie“, „Zeitplan“ und „Rollout-Plan“ im selben konzeptionellen Kontext liegen. Sie gibt das Segment mit den Punkten des Launch-Plans, Terminen und Phasen zurück, obwohl die wörtliche Formulierung nicht mit der Abfrage übereinstimmt. Der Agent fasst dann diesen Abschnitt in eine klare narrative Antwort zusammen, anstatt einfach den Text der Folien wiederzugeben.

Hybride Suche entfaltet ihre volle Leistungsfähigkeit bei ungenaueren Analysefragen wie „Umsatzaufteilung nach Dienstleistungsbereich“. Hier liegt die beste Antwort in einer Tabelle, in der die Überschriften „ARR“, „Professionelle Dienstleistungen“ und „Plattformgebühren“ lauten und der Inhalt Dollarbeträge und Prozentsätze enthält. Benutzer spiegeln nicht immer diese genauen Bezeichnungen in ihren Fragen wider.

SchlüsselMicrosoft Word-Suchanker zu "Umsatz", "ARR" und numerischen Mustern wie "$1,2M" und "35%", um die richtigen Tabellenflächen anzuzeigen. Die semantische Suche versteht, dass "Dienstleistungsbereich" zu Spalten wie "Professionelle Dienstleistungen" oder "Implementierung" gehört, nicht nur zu jedem Auftreten von "Dienst". Zusammengeführt ziehen sie das exakte Tabellenstück heraus, sodass das LLM eine strukturierte Aufschlüsselung anstelle einer vagen Zusammenfassung ausgeben kann.

Hybride Suche wirft eine unmittelbare Frage auf: Wie kombiniert man zwei rangierte Listen, die völlig unterschiedliche Bewertungsmaßstäbe verwenden? Vektorähnlichkeit liefert Kosinusabstände oder Skalarprodukte; die Schlüsselwortsuche in Microsoft Word gibt BM25- oder Textwerte zurück. Ein einfaches Normalisieren und Mitteln dieser Zahlen schlägt in der Regel fehl, da sich die Punktverteilung jeder Algorithmus verändert, während Ihr Korpus wächst.

Die Reziproke Rangfusion (RRF) umgeht das Durcheinander, indem sie die Rohwerte vollständig ignoriert. Stattdessen zählt nur, an welcher Position ein Dokument in jeder Liste erscheint. Ein Abschnitt, der an Rang 1 in der Vektorsuche und Rang 20 in der Schlüsselwortsuche erscheint, sollte immer noch einen Abschnitt schlagen, der an Rang 10 in beiden erscheint.

RRF weist jedem Dokument einen kombinierten Wert mit einer kleinen Formel zu: 1 / (k + Rang), summiert über alle Ergebnislisten. Mit k, das typischerweise auf 60 gesetzt ist, erhält ein Dokument, das in einer Liste den 1. Platz einnimmt, 1 / 61, der Rang 2 erhält 1 / 62, und so weiter. Dokumente, die in einer Liste nicht vorhanden sind, tragen einfach nichts zu dieser Liste bei.

Dieser Ansatz hat zwei wichtige Eigenschaften für RAG. Erstens belohnt er Dokumente, die in einer der beiden Ranglisten nahe oben erscheinen, stark, selbst wenn sie nur in einer erscheinen. Zweitens hebt er automatisch Dokumente hervor, die in beiden Listen erscheinen, da ihre gegenseitigen Werte sich addieren. Keine manuelle Gewichtung oder Kalibrierung pro Index erforderlich.

Hybrid RAG profitiert direkt von diesen Eigenschaften. Die semantische Suche kann konzeptionell ähnliche Passagen aufzeigen, die ein Schlüsselwort in Microsoft Word niemals erwähnen, während die Schlüsselwortsuche genaue IDs, Fehlermeldungen und zitierte Texte liefert. RRF kombiniert beide Signale, sodass ein PDF-Ausschnitt mit „Fehler 0x80070005“ und einer semantisch verwandten Erklärung aus einem Microsoft Word-Fehlerbehebungsdokument beide nach oben gelangen können.

MongoDB integriert dies in Atlas über die $rankFusion-Stufe, die RRF innerhalb der Aggregationspipeline implementiert. Sie können eine $vectorSearch-Stufe, eine $search- oder $searchMeta-Stufe ausführen und dann beide Ausgaben ohne Verlassen der Datenbank an $rankFusion übergeben. Keine benutzerdefinierte Python-Zusammenführungslogik, keine zusätzlichen Netzwerk-Hops.

Für Entwickler, die ähnliche Stacks mit Pydantic AI und Docling erstellen, wird RRF zu einer Konfigurationswahl in einer einzigen Zeile, nicht zu einem algorithmischen Forschungsprojekt. Für eine detailliertere Durchsicht der Agentenorchestrierung rund um dieses Muster, siehe Wie man einen leistungsstarken RAG-Wissensdatenbank-Agenten mit Pydantic AI erstellt.

Hybrides RAG hört auf, ein Trendthema in Forschungspapieren zu sein, und wird zu einem Muster, das Sie tatsächlich implementieren können. Mit MongoDB, PydanticAI und Docling erhalten Sie einen Stack, der klein genug bleibt, um verständlich zu sein, während er fast jeden RAG-Anwendungsfall abdeckt, der für Sie wichtig ist: dichte semantische Suche, genaue Schlüssel-Microsoft Word-Suche und robuste Verarbeitung für PDFs, Microsoft Microsoft Word, Markdown und mehr.

Sie jonglieren nicht mit einer separaten Vektordatenbank, einem fehleranfälligen Parsing-Skript und einem überkomplizierten Orchestrierungsframework. Ein MongoDB-Cluster speichert Ihre Datenfragmente, Metadaten und Embeddings; Docling verwandelt unübersichtliche Dateien in strukturierten Text; PydanticAI verbindet alles zu einem Agenten, der Werkzeuge aufruft, hybride Suchen durchführt und fundierte Antworten statt Halluzinationen liefert.

Dies ist keine Whiteboard-Architektur. Im Video von Cole Medin wird ein funktionierender Python-Agent von Anfang bis Ende vorgestellt, der die MongoDB Atlas Vector Search nutzt, hybride Suchen mit Rangfusion durchführt und in Echtzeit live Abfragen über gemischte Dokumenttypen beantwortet. Die Latenz bleibt niedrig, die Komplexität ist überschaubar, und Sie können jeden Schritt vom Upload bis zur Antwort nachverfolgen.

Sie können genau das klonen, was Sie auf dem Bildschirm gesehen haben. Holen Sie sich das GitHub-Repository, das Cole für den MongoDB-Agenten veröffentlicht hat, unter https://github.com/coleam00/MongoDB-RAG-Agent und führen Sie es lokal mit einigen Umgebungsvariablen und einem MongoDB Atlas-Cluster aus. Von dort aus können Sie Ihre eigenen Dokumente austauschen, die Chunk-Größen anpassen oder den Agenten mit neuen Tools erweitern.

Behandeln Sie dies als eine Vorlage, nicht als ein Spielzeug. Dasselbe Muster skaliert von einem einzigen internen Handbuch zu Tausenden von Support-Tickets, Verträgen oder Forschungspapieren, ohne Sie bei jeder neuen Funktion in einen maßgeschneiderten Stack zu zwingen. Mit einem minimalen hybriden RAG-Setup, das tatsächlich funktioniert, können Sie weniger Zeit mit der Verwaltung von Infrastrukturen verbringen und mehr Zeit mit der Bereitstellung von KI-Funktionen, denen die Benutzer vertrauen.

Was ist hybrides Suchen in RAG?

Hybridsuche kombiniert semantische (Vektor-)Suche, die Konzepte und Beziehungen versteht, mit der Schlüsselwortsuche, die genaue Begriffe und Phrasen findet. Dieser Ansatz liefert genauere und relevantere Ergebnisse, indem er die Stärken beider Methoden für jede Anfrage nutzt.

Warum MongoDB für ein RAG-System verwenden?

MongoDB fungiert sowohl als standardmäßige NoSQL-Dokumentdatenbank als auch als Vektordatenbank durch Atlas Vector Search. Dies konsolidiert den Tech-Stack und vereinfacht Architektur, Bereitstellung und Datenmanagement, indem die Notwendigkeit für einen separaten, dedizierten Vektor-Store entfällt.

Was macht diesen Stack einfacher als LangChain oder LlamaIndex?

Dieser Stack priorisiert Einfachheit und direkte Kontrolle. Pydantic AI bietet einen 'pythonesken', typensicheren Ansatz zum Erstellen von Agenten, ohne die schweren Abstraktionen größerer Frameworks, während die integrierte Natur von MongoDB die betriebliche Komplexität reduziert.

Kann dieser Stack Enterprise-Dateiformate wie PDF und DOCX verarbeiten?

Ja. Der Stack verwendet Docling, eine leistungsstarke Bibliothek, die speziell zum Parsen und Extrahieren von Text aus verschiedenen gängigen Dateiformaten entwickelt wurde, einschließlich PDFs, Microsoft Word-Dokumenten, Markdown und mehr, was sie ideal für echte Unternehmensdaten macht.