BLUF: Eine Teilenummer ist eine Identitätsbedingung, nicht nur ein semantischer Hinweis. Für Enterprise-RAG über Wartungshandbücher und Produktkataloge sollten Sie eine exakte Kennungssuche neben lexikalischem und vektoriellem Retrieval vorsehen. Führen Sie Ranglisten zusammen, statt inkompatible Rohscores zu addieren, und erhalten Sie bestätigte exakte Treffer auch bei einem nachgeschalteten Reranker. Setzen Sie hybride Suche erst ein, wenn eine Auswertung nach Anfrageklassen bessere Evidenzabdeckung innerhalb Ihres Latenzbudgets zeigt. Eine flüssige Antwort zum ähnlichen Bauteil bleibt eine falsche Antwort.
Betrachten Sie die beispielhaften Kennungen AX-104-B und AX-104-8. Es handelt sich um erfundene Beispiele, nicht um Kundendaten. Ein Techniker benötigt die Anzugsprozedur für das erste Bauteil; ein semantisch ähnliches Handbuch zum zweiten ist kein zulässiger Ersatz. Embeddings können bei „Ersatzdichtung für die Kühlmittelpumpe“ helfen. Ihr Ähnlichkeitsscore beweist jedoch nicht, dass zwei Katalogkennungen dasselbe physische Teil bezeichnen. Auch lexikalisches Retrieval ist nicht automatisch exakt: Tokenisierung, Satzzeichenbehandlung und OCR-Fehler können die Unterscheidung bereits vor dem Ranking zerstören.
Beginnen Sie mit dem Identitätsvertrag, nicht mit Fusionsgewichten
Speichern Sie Originalkennung, Lieferanten- oder Katalognamensraum, Revision, Quelldokument-ID und autoritative Aliasse als strukturierte Metadaten. Verwenden Sie ein eigenes, nicht tokenisiertes Kennungsfeld für Gleichheitsabfragen und ein separates analysiertes Textfeld für die beschreibende Suche. Erhalten Sie den Originalwert für Quellenbelege. Die Elastic-Referenz zu Keyword-Feldern unterscheidet strukturierte Kennungen und termbasierte Abfragen von der Volltextsuche. Die Anwendung muss wissen, ob ein Revisionssuffix die zulässige Prozedur verändert, ob ein Händlercode ein Alias ist und ob Groß- und Kleinschreibung im jeweiligen Katalog relevant sind.
Normalisierung ist eine versionierte Fachregel. Bindestriche zu entfernen oder Schreibweisen zu vereinheitlichen kann helfen, wenn der Lieferant diese Varianten ausdrücklich gleichsetzt. Pauschales Entfernen von Satzzeichen oder Ersetzen von O durch 0 kann dagegen unterschiedliche Teile auf denselben Schlüssel abbilden. Prüfen Sie Kollisionen bei der Übernahme und sperren Sie mehrdeutige Zuordnungen, statt still einen Datensatz auszuwählen. Behandeln Sie OCR-Korrekturen als klärungsbedürftige Vorschläge, nicht als autoritative Berichtigung.
Übernehmen Sie Kennung und Revision in die Metadaten jedes relevanten Chunks. Ergänzen Sie eingebettete Passagen um nützlichen Titel- und Teilekontext, ohne vorauszusetzen, dass der Anhang eines langen Dokuments eine Kürzung überlebt. Die Modellkarte von multilingual E5 verlangt bei asymmetrischem Retrieval die Präfixe query: und passage: auch für nicht englische Eingaben und dokumentiert eine Grenze von 512 Tokens. Das sind modellspezifische Vorgaben, keine allgemeinen Embedding-Standards. Versionieren Sie Tokenizer, Embedding-Modell, Normalisierungsregeln und Chunking gemeinsam im Indexmanifest. Die Evaluierung von RAG-Chunking-Strategien behandelt die Evidenzeinheit; hier geht es darum, welche Einheiten überhaupt in die Kandidatenmenge gelangen.
Referenzdatenfluss: Identität und Bedeutung brauchen getrennte Pfade
Authentifizierte Anfrage → serverseitig abgeleiteter Berechtigungsumfang → Kennungsextraktion und Mehrdeutigkeitsprüfung → parallele Kandidatenzweige → Deduplizierung anhand stabiler IDs und RRF → Regel für exakte Identität → optionaler Reranker → Evidenzprüfung → belegte Antwort oder Rückfrage.
Zweig A: Berechtigungsumfang + Namensraum + bestätigte Kennung + Revision → strukturierte Gleichheitsabfrage → exakte Evidenzkandidaten.
Zweig B: derselbe Berechtigungsumfang + Originalanfrage + freigegebene Aliasse → lexikalische Suche über kennungsgeeignete Felder und Beschreibungstext → geordnete lexikalische Kandidaten.
Zweig C: derselbe Berechtigungsumfang + modellspezifische Anfragekodierung → gefiltertes Vektorretrieval → geordnete semantische Kandidaten.
Die Fusion erhält ausschließlich autorisierte Kandidaten. Führen Sie den exakten Treffer als ausdrückliches Signal mit, statt auf seinen Sieg in einer Rangsumme zu vertrauen. Bei einer eindeutigen Kennung kann eine sicherheitsorientierte Regel die Antwortbelege auf diese Identität begrenzen und semantisches Ranking nur innerhalb ihrer Dokumente nutzen. Passen mehrere Revisionen, fragen Sie nach oder zeigen Sie klar getrennte Alternativen. Ein exakter Treffer identifiziert das Teil; er beweist nicht, dass die gefundene Seite die gesuchte Prozedur enthält.
Bauen Sie keinen privilegierten Schnellpfad für Katalogabfragen. Wenden Sie den Berechtigungsumfang in jedem Zweig an, bevor Kandidateninhalte den Retrieval-Dienst verlassen. Reranker, Erweiterung auf Elterndokumente und Caches dürfen ihn nicht ausweiten. Leiten Sie Filter serverseitig ab, verweigern Sie den Zugriff bei fehlendem Umfang und berücksichtigen Sie die Policy-Version in Cache-Schlüsseln. Diese Kontrollen erweitern die RAG-Architektur für Zugriffskontrolle; sie ersetzen sie nicht durch eine Ranking-Heuristik.
Entscheidungstabelle: Routen Sie nach dem Fehlerrisiko
| Anfrageklasse | Ausgangspfad | Pflichtkontrolle | Eskalation bei |
|---|---|---|---|
| Bestätigte vollständige Kennung | Exakte strukturierte Abfrage, danach lexikalische Evidenzsuche | Übereinstimmender Namensraum und Revision | Fehlender autorisierter exakter Evidenz |
| Kennung mit vermutetem OCR-Fehler | Exakte Abfrage plus begrenzte Aliasvorschläge | Original erhalten; nicht still ersetzen | Mehreren plausiblen unterschiedlichen Teilen |
| Kennung plus Prozedurfrage | Exakte Identitätsbedingung plus lexikalische/Vektorsuche im Umfang | Evidenz muss die gesuchte Prozedur tragen | Richtigem Teil, aber falscher Prozedur oder Revision |
| Natürlichsprachliches Symptom | Lexikalische und Vektorkandidaten mit RRF | Kompatibilität vor Teileempfehlung prüfen | Mehreren passenden Komponenten |
| Katalogvergleich | Jede Identität separat abrufen, anschließend vergleichen | Getrennte Quellenbelege und Revisionsangaben | Fehlenden oder inkompatiblen Spezifikationen |
Diese Routing-Regel ist ein Architekturvorschlag, keine Herstellergarantie. Für einen bereinigten Katalog mit reinen Kennungsanfragen kann ein exakter Suchdienst ausreichen. Ein hybrider Aufbau ergänzt einen Indexpfad, Rechenarbeit pro Anfrage und zusätzliche Fehlerzustände. Sein Nutzen liegt in breiterer Kandidatenabdeckung bei gemischten Fragen, nicht in der Erlaubnis, ein Ersatzteil zu erraten.
RRF kombiniert Positionen, keine Sicherheit
Die Elastic-Dokumentation zu Reciprocal Rank Fusion definiert den fusionierten Dokumentenscore als Summe von 1 / (rank_constant + Rang) über die Listen, in denen das Dokument vorkommt. Die Rangzählung beginnt bei eins. Fehlende Dokumente liefern keinen Beitrag. Damit müssen Sie keinen BM25-Score zu einer Vektorähnlichkeit mit anders interpretierter Skala addieren. Deduplizieren Sie innerhalb jeder Liste anhand einer stabilen ID der Retrieval-Einheit und führen Sie anschließend dieselbe Einheit listenübergreifend zusammen. Eine Chunk-ID ist keine Teile-ID: Ein Bauteil kann mehrere ergänzende Evidenzpassagen benötigen.
Die Microsoft-Dokumentation zum hybriden Ranking trennt die RRF-Konstante ausdrücklich von der Nachbaranzahl der Vektorabfrage. Sie ordnet semantisches Reranking nach der Fusion ein. Unterscheiden Sie deshalb in Konfiguration und Traces vier Größen: abgerufene Kandidaten, für die Fusion verfügbare Kandidaten, Reranker-Eingaben und schließlich an den Generator übergebene Einheiten.
RRF garantiert keinen exakten Treffer. Ein allgemeines Handbuch weit oben in beiden Listen kann ein exakt passendes Handbuch überholen, das nur in einer Liste vorkommt. Ein RRF-Score ist auch keine kalibrierte Wahrscheinlichkeit für eine korrekte Antwort. Ein zusätzlicher Retriever oder ein weiteres Vektorfeld kann die Scoreverteilung ändern, obwohl die Korpusqualität unverändert bleibt. Übernehmen Sie deshalb keinen alten absoluten Annahmeschwellenwert nach einer Änderung der Zweiganzahl. Halten Sie Identitätsbedingung und Entscheidung über ausreichende Evidenz ausdrücklich getrennt.
Kandidatenfenster können den Reranker wirkungslos machen
Elastic dokumentiert die Kürzung der Vektorergebnisse, wenn k größer als rank_window_size ist. Liegt das relevante Handbuch außerhalb aller erhaltenen Zweigfenster, können weder Fusion noch ein stärkerer Reranker es zurückholen. Ermitteln Sie den ersten Verlustpunkt: Quelle fehlt im Index, Kennung stimmt nicht, Zweig liefert nichts, Kandidaten werden abgeschnitten, Fusion oder Reranker stuft ab oder der Prompt-Kontext wird gekürzt.
Beginnen Sie mit einem begrenzten Vergleich unterschiedlicher Zweigfenster auf einem eingefrorenen Evaluationssatz. Erfassen Sie den Recall der Kandidatenvereinigung vor der Fusion und zusätzlich den Recall am endgültigen Kontext-Cutoff. Vergrößern Sie jeweils nur ein Fenster; halten Sie Embedder, Korpus, Filter und sonstige Einstellungen konstant. Größere Fenster können Recall verbessern, verursachen aber zusätzliche Arbeit für Sortierung, Reranking und Kontextauswahl. Sinnvoll ist die kleinste Konfiguration, die Ihre Segmentuntergrenzen erfüllt, nicht die größte vom Dienst akzeptierte.
Messen Sie bei parallelen Zweigen die einzelnen Laufzeiten, gesamte Retrieval-Wandzeit, Reranker-Zeit und Ende-zu-Ende-Antwortlatenz. Ein langsamer Zweig kann die hohen Latenzperzentile bestimmen; die reine Fusionszeit verdeckt ihn. Definieren Sie Timeouts und einen gekennzeichneten eingeschränkten Betriebsmodus. Bei kennungsgebundenen Anfragen kann ein Vektor-Timeout eine rein exakte/lexikalische Antwort erlauben, sofern autorisierte Evidenz ausreicht. Der Ausfall der exakten Suche darf nicht still zu einer ungefähren Teilezuordnung führen. Fällt die Autorisierung aus, wird Retrieval verweigert.
Ablationstabelle: Messen Sie, statt einen Sieger zu erfinden
Verwenden Sie einen versionierten Fragensatz mit getrennten Klassen für vollständige Kennungen, Schreib-/OCR-Varianten und natürlichsprachliche Fragen. Hinterlegen Sie relevante Dokument- und Evidenzstellen-IDs, zulässige Revisionen, Berechtigungsumfang, Anfrageherkunft und erwartete Antwortverweigerung. Ergänzen Sie schwierige Negativbeispiele: ein abweichendes Zeichen, derselbe Code in einem anderen Lieferantennamensraum, veraltete Handbücher und nicht autorisierte Beinahe-Duplikate. Trennen Sie Entwicklungsbeispiele vom zurückgehaltenen Freigabesatz.
Die folgende Tabelle ist eine Messvorlage, kein Benchmark-Ergebnis. NG bedeutet nicht gemessen: Für diesen Artikel wurden kein Produktionskorpus, kein Retrieval-Dienst und kein repräsentativer Lasttest bereitgestellt. Jede Recall-Zelle benötigt ihre eigene Anfrageanzahl und Unsicherheitsbewertung. Wiederholen Sie die Zeilen mit und ohne exakte Routing-Regel, um deren Beitrag zu isolieren. Sonst stammt ein vermeintlicher Hybridvorteil möglicherweise allein aus der Identitätsprüfung.
| Variante | Exakt Recall@10 | Varianten Recall@10 | Natürlichsprachlich Recall@10 | Ende-zu-Ende p95 |
|---|---|---|---|---|
| Nur lexikalisch | NG | NG | NG | NG |
| Nur Vektorsuche | NG | NG | NG | NG |
| Lexikalisch + Vektor, RRF | NG | NG | NG | NG |
| RRF + Reranker | NG | NG | NG | NG |
| RRF mit größerem Kandidatenfenster | NG | NG | NG | NG |
Definieren Sie Recall@10 als Anteil der annotierten relevanten Evidenzeinheiten innerhalb der ersten zehn abgerufenen Einheiten, gemittelt innerhalb jeder Anfrageklasse. Erfassen Sie zusätzlich den Recall der Kandidatenvereinigung, MRR für den ersten nützlichen Treffer und bei abgestuften Relevanzlabels nDCG. Bewerten Sie Teile-/Revisionskorrektheit und Belegbarkeit der Antwort separat. Fragen ohne mögliche Antwort haben keinen Recall-Nenner; prüfen Sie korrekte Antwortverweigerung und falsche Substitution, statt sie künstlich in den Recall-Mittelwert aufzunehmen.
Dokumentieren Sie für Latenzangaben Hardware oder Dienstklasse, Korpusgröße, Parallelität, Anfrageanzahl, warme und kalte Caches sowie den Einbezug der Antwortgenerierung. Diese Vorlage fordert Ende-zu-Ende-p95; bewahren Sie Zweig- und reine Retrieval-Laufzeiten als Diagnosewerte auf. Quantifizieren Sie, soweit sinnvoll, die Unsicherheit über Anfragen, etwa per Bootstrap. Wenige Beispiele sind ein Debugging-Satz, kein belastbarer Nachweis allgemeiner Qualitätsverbesserung. Legen Sie Annahmeuntergrenzen und tolerierbare Regression vor der Optimierung fest. Verwerfen Sie Kandidaten, die exakte Identitätsfehler gegen einen besseren Gesamtmittelwert eintauschen.
Freigabecheckliste und Betriebsevidenz
Datenübernahme: Erkennen Sie Normalisierungskollisionen, validieren Sie Namensraum- und Revisionsmetadaten und prüfen Sie Kennungserhalt bei OCR und Extraktion sowie Löschung und Ablösung von Dokumenten.
Retrieval: Belegen Sie denselben Berechtigungsumfang in exaktem, lexikalischem und Vektorzweig. Protokollieren Sie Zweigverfügbarkeit, Kandidatenanzahlen, stabile IDs und den Verlustpunkt annotierter Evidenz. Vermeiden Sie sensible Rohfragen und Dokumentinhalte in gewöhnlicher Telemetrie.
Ranking: Erhalten Sie die ausdrückliche Identitätsentscheidung, prüfen Sie deterministische Gleichstände und Deduplizierung. Vergleichen Sie Konfigurationen mit und ohne Reranking sowie mit größeren Fenstern. Ein Reranker darf den Identitätsvertrag nicht ersetzen.
Antwort: Prüfen Sie, ob Quellenbelege die Prozedur für das angefragte Teil und seine Revision tragen. Verweigern Sie die Antwort oder fragen Sie nach, wenn Identität oder Evidenz mehrdeutig sind. Suchrelevanz ist keine technische Freigabe zum Einbau eines Ersatzbauteils.
Einführung: Vergleichen Sie den Kandidaten im Shadow-Betrieb mit der eingefrorenen Baseline, prüfen Sie Fehler je Anfrageklasse und starten Sie einen Canary mit Rückkehr zum vorherigen Index- und Retrieval-Manifest. Beobachten Sie Nulltreffer, Rückfragen, falsche Substitutionen, Timeouts und Kosten gemeinsam mit der sichtbaren Latenz. Änderungen an Aliasregeln, Embeddings oder Kandidatenfenstern verlangen einen neuen Regressionstest.
Was Sie zuerst bauen sollten
Begrenzen Sie den ersten Schritt auf einen Katalog und die zugehörigen Handbücher. Sichern Sie zunächst die exakte Zuordnung ab; ergänzen Sie lexikalische und Vektorkandidaten dort, wo tatsächliche Anfrageklassen sie benötigen. Das erste Ergebnis sollte ein Identitätsvertrag, ein gelabelter Evidenzsatz und ein Ablationsbericht sein, nicht die Behauptung, hybride Suche sei grundsätzlich überlegen.
Wenn Ihr Assistent plausible Handbücher für die falschen Teile liefert, unterstütze ich Sie bei der Prüfung von Kennungsschema, Retrieval-Traces und Evaluationsdesign. Bringen Sie einen repräsentativen Korpusausschnitt, fehlgeschlagene Anfragen sowie Ihre Latenz- und Zugriffsanforderungen mit. Entscheidend ist, ob Fusion die autorisierte Evidenzabdeckung verbessert, ohne exakte Identität aufzuweichen, nicht ob die Architektur eine Vektordatenbank enthält.
