Warum Enterprise RAG eine hybride Suche benötigt – nicht nur Vektoren

Der größte Irrtum bei Enterprise-RAG besteht darin, dass bessere Embeddings automatisch bessere Antworten liefern. Die Qualität der Antwort hängt weitaus stärker davon ab, was abgerufen wird, als davon, welches Chat-Modell verwendet wird.

Einführung

Retrieval-Augmented Generation ermöglicht es Assistenten, vor dem Sprechen aus externem Wissen zu schöpfen. Die meisten Demonstrationen stellen die Vektorsuche in den Mittelpunkt:

Documents
    │
Chunking
    │
Embedding Model
    │
Vector Database
    │
Top-K Retrieval
    │
Large Language Model

Embed-Dokumente, speichern Vektoren und holen für jede Anfrage die nächstgelegenen Nachbarn ab. Dieses Muster funktioniert in Demonstrationen hervorragend, bricht aber oft in der Produktion zusammen – insbesondere in Unternehmen voller Identifikatoren. Reine Vektorsuche reicht selten aus. Hybride Suchmethoden sind mittlerweile die Standardstrategie für ernstzunehmende RAG-Anwendungen.

Warum die Vektorsuche beliebt wurde

Suchmaschinen für Schlüsselwörter vergleichen Token. Die Anfrage „Wie kann man ein Passwort zurücksetzen?“ findet Dokumente mit den Begriffen „zurücksetzen/Passwort/Konto“. Die Anfrage „Kann ich das Konto nicht aufrufen?“ übersieht möglicherweise völlig die Dokumente zum Passwort, obwohl der Zweck identisch ist. Embeddings übertragen Bedeutungen in einen Vektorraum, wodurch Paraphrasen dennoch auf dieselben Ergebnisse stoßen. Für FAQs und erzählerische Dokumente stellt das einen Durchbruch dar.

Wo reine Vektoren versagen

Unternehmenskorpora sind voll von Rechnungsnummern, Mitarbeiteridentifikatoren, Fehlerrichtlinien, SKUs, Vertragsnummern, Richtliniennummern und Versionszeichenfolgen. Diese Zeichenfolgen sind für Nutzer wichtig, stellen aber eine Herausforderung für dichte Modelle dar.

Angenommen, es gibt ein Datensatz wie folgt:

Invoice Number : INV-93842
Status         : Paid
Customer       : ABC Corporation

eine Anfrage wie „Wie ist der Status der Rechnung INV-93842?“ liefert oft Zahlungsrichtlinien anstelle dieser Rechnung, da Embeddings die Begriffe „Rechnung/Zahlung“ stärker betonen als die genaue Identifikationsnummer.

Weitere Versagensmöglichkeiten

Suchen nach Datenbankfehlern erfolgen für:

ORA-12514

Kann anstelle der ORA-12514-Seite allgemeine Verbindungsanleitungen zurückgeben.

Produktabfragen wie:

RTX-9000 Switch

Können Netzwerkübersichten anstelle des RTX-9000-Manuals anzeigen.

Fragen zur Version wie:

Version 4.3.12

Liefern oft allgemeine Veröffentlichungshinweise, nicht speziell die für 4.3.12.

Suche im Gesundheitswesen für:

Patient ID: P-482731

Kann anstelle der Patientenakte Dokumente zu Registrierungsverfahren ausgeben.

Immer dann, wenn genaue Identifikatoren wichtig sind, verliert allein die semantische Ähnlichkeit an Zuverlässigkeit.

Warum Embeddings hier Schwierigkeiten haben

Modelle lernen Begriffe wie Arzt↔Ärztin und Auto↔Kraftfahrzeug. Zeichenfolgen wie:

INV-93842

oder

RTX-9000

enthalten nur wenig semantischen Inhalt. Wenn man:

INV-93842

in

ändert.

INV-93843

Es ändert die Geschäftseinheit, während die Embeddings nahezu identisch bleiben. Das ist ein inhärenter Aspekt der dichten Suche und kein Fehler eines einzelnen Anbieters.

Die Aufteilung der Unternehmenssuche

Semantische Informationen (Richtlinien, Anspruchsantragsverfahren, Passwort zurücksetzen) – hier sind Vektoren hervorragend geeignet. Genaue Informationen (IDs, Codes, SKUs, Versionen) – hier sind Schlüsselwortsuche/BM25 besser geeignet.

Die Verwendung nur einer Strategie bedeutet Exzellenz in einem Bereich und Schwierigkeiten im anderen. Die hybride Suche existiert, um beides abzudecken.

Einführung in die hybride Suche

Anstelle von BM25 oder Vektoren werden beide Methoden eingesetzt und miteinander kombiniert:

User Query
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
 Keyword Search (BM25)           Vector Search
        │                                 │
        └──────────────┬──────────────────┘
                       ▼
              Merge & Score Fusion
                       ▼
                 Cross-Encoder Re-ranker
                       ▼
                Top Relevant Context
                       ▼
                 Large Language Model

Die Schlüsselwortsuche schützt Identifikatoren und seltene Token. Die Vektorsuche deckt Synonyme und Formulierungen ab. Ein Neurankierer (oder eine rekursive Rangfusionsmethode) ordnet die kombinierten Ergebnisse für die Anfrage des Benutzers.

Warum die hybride Suche gewinnt

Für die Frage „Warum ist die Rechnung INV-93842 noch zur Freigabe ausstehend?“ kann das hybride System über Schlüsselwörter die exakte ID ermitteln, über Vektoren relevante Workflow-Dokumente abrufen und neu rangieren, sodass das Rechnungsrecord an erster Stelle steht, während die Prozessdokumente weiterhin verfügbar bleiben. Jede Methode nutzt ihre Stärken optimal aus.

Fazit

Vektordatenbanken bleiben grundlegend wichtig. Sie ersetzen die klassische Informationssuche nicht vollständig. Unternehmenswissen umfasst Prosa, Codes und Datensätze – die hybride Suche berücksichtigt diese Mischung.

Ein leistungsstärkeres Chat-Modell kann kein schwaches Kandidatenset ausgleichen. Investieren Sie lieber in eine Suche, die immer wieder die richtigen Passagen anzeigt, anstatt Budget für leistungsstärkere Generatoren oder auffälligere Prompts auszugeben – in RAG-Systemen hängt die Antwortqualität in erster Linie von der Suchqualität ab.

Operativ gesehen sollte protokolliert werden, welche Abteilung zu jedem Treffer beigetragen hat (Schlüsselwort gegen dichte Suche), die Fusionsgewichte an einem Evaluierungsset angepasst werden, das sowohl Paraphrasenfragen als auch ID-Suchanfragen enthält, und man sollte nach einer Demonstration, die nur leichte semantische Fragen stellt, nicht behaupten, „RAG sei abgeschlossen“. ID-Suchanfragen sind die Akzeptanztests, bei denen Unternehmen in der Produktion tatsächlich versagen.

Hybridlösungen ohne übermäßige Komplexität entwickeln

Begonnen werden sollte mit BM25 (oder einer äquivalenten lexikalischen Suche) zusätzlich zum bestehenden Vektorindex – viele Vekordatenbanken bieten bereits hybride APIs an. Stellen Sie sicher, dass die Chunk-IDs übereinstimmen, damit die Fusion unkompliziert möglich ist. Beginnen Sie mit der rekursiven Rangfusionsmethode, bevor ein Cross-Encoder-Re-Ranker trainiert wird; RRF ist kostengünstig und oft „gut genug“, um zu zeigen, dass die Lücke bei den ID-Suchanfragen geschlossen wird.

Erstellen Sie ein Evaluationsset mit zwei Kohorten: Fragen zur Paraphrasierung (semantisch) und Fragen zu Identifikatoren (genau). Bewerten Sie den Recall@k getrennt voneinander. Senden Sie nur hybride Ergebnisse, wenn sich beide Kohorten verbessern oder zumindest eine sich verbessert, ohne dass die andere leidet. Achten Sie auf die Latenz: Der parallele Betrieb von zwei Suchalgorithmen ist in der Regel in Ordnung; eine serielle Neubewertung riesiger Kandidatensätze hingegen nicht.

Die Chunking-Strategie ist weiterhin wichtig. Identifikatoren, die in großen Blöcken versteckt sind, schwächen sowohl die BM25-Werte als auch die dichten Bewertungen. Wählen Sie Chunk-Grenzen, bei denen Rechnungshüllen, Fehlerkodennamen und SKU-Spalten unverändert bleiben. Metadatenfilter (Produktlinie, Lokalisation, Dokumenttyp) verringern vor der Fusion zusätzlich falsche Ergebnisse.

Zuletzt sollten die Produktbeteiligten aufgeklärt werden: „Wir haben alles integriert“ ist keine Suchstrategie. Die hybride Strategie entspricht vielmehr der Art und Weise, wie Unternehmen tatsächlich Fragen stellen – zur Hälfte in natürlicher Sprache, zur Hälfte mit über die Tastatur eingegebenen Ticket-IDs.

Implementierungs-Checkliste

1. Aus den Produktionsprotokollen Inventurabfragen erstellen; kennzeichnen, welche eine exakte Übereinstimmung erfordern und welche paraphrasiert werden müssen.
2. Eine lexikalische Suche auf demselben Korpus sowie mit denselben Chunk-IDs wie der Vektorindex einrichten.
3. Mit RRF verknüpfen und die Quellen der Beiträge pro Treffer protokollieren.
4. Den Recall@k bei beiden Gruppen messen und die Gewichte anpassen.
5. Nur dann einen gelernten Neubewertungsmechanismus in Betracht ziehen, wenn das Latenzbudget es zulässt.
6. Identifikationsfelder in den Metadaten beibehalten, um bei bereits bekannten Rechnungen oder SKUs optionale strenge Filter anzuwenden.

Teams, die direkt zu „größeren Embedding-Modellen“ übergehen, entdecken oft wieder dieselben ID-Probleme mit „schöneren“ Vektoren. Die hybride Suche ist die langweilige Lösung, die der Art und Weise entspricht, wie Tickets formuliert werden.