Zehn Fehler bei der stummen Informationsabrufung in produktiven RAG-Systemen und wie jeder dieser Fehler behoben wird.
Vom Chunk-Größe- und Überschneidungsprinzip bis hin zu hybriden Suchverfahren, RRF, Neubewertung, Auswahl von Embedding-Modellen und Bewertungsmethoden: zehn Fehler bei der Informationsabrufung, die zu falschen RAG-Antworten führen, und deren Lösungen.
Ein Support-Chattenbot erklärte einmal in wunderschöner Prosa die falsche Rückerstattungspolitik. Der Suchalgorithmus fand einen Absatz, in dem das Wort „Rückerstattung“ viermal vorkam. Er war thematisch passend und beschrieb eine eingestellte Produktlinie. Der große Sprachmodell tat, was ihm aufgetragen wurde, nämlich auf der bereitgestellten Kontextbasis selbstbewusst zu antworten. Niemand hatte ihm mitgeteilt, dass der Kontext falsch war.
So verlaufen die meisten RAG-Fehler, die schließlich in einer Fehlersuche enden. Ein Team verbringt zwei Wochen damit, das Modell auszutauschen, den Systemprompt umzuschreiben und „nur aus dem Kontext antworten“ fett hinzuzufügen – doch die Häufigkeit der Halluzinationen ändert sich kaum. Das Problem lag nie bei der Generierung. Das Modell argumentierte korrekt auf der Grundlage von Beweisen, die bereits bei seiner Bereitstellung falsch waren.
Zehn spezifische Fehler beeinträchtigen die Qualität der Informationsabrufung in produktiven RAG-Systemen. Sie treten in der Regel in einer festen Reihenfolge auf: Zunächst Fehler bei der Aufteilung in Blöcke, da diese an der Anfangsstufe aller Prozesse liegen, anschließend Probleme im Design der Informationsabrufung, dann Entscheidungen bezüglich Neubewertung und Einbettung der Ergebnisse, und schließlich die Messlücke, die es ermöglicht, dass all diese Probleme unbemerkt bleiben. Jeder Abschnitt unten erläutert, warum der Fehler auftritt, welche Folgen er hat und was geändert werden sollte; wo die Studien widersprüchlich sind, wird dieser Widerspruch offen dargestellt.
Warum die Informationsabrufung der Schwachpunkt von RAG ist
Die Berichte von Praktikern zur RAG-Produktion im Jahr 2026 kommen immer wieder zu derselben Diagnose: Die meisten schlechten Antworten lassen sich auf das Abrufen von Inhalten zurückführen. Falsche Dokumente werden zurückgegeben, die richtigen werden übersehen oder liegen in der Rangliste zu weit unten, um verwendet zu werden. Eine gängige Schätzung liegt bei etwa 70 Prozent oder mehr. Diese Zahl variiert je nach Bericht und Bereich, sodass sie nur als grobe Orientierung dient – unabhängige Quellen stimmen jedoch in der Richtung überein. Wenn ein RAG-System Fehler macht, ist die wahrscheinlichste Erklärung, dass dem LLM nie die richtigen Belege gezeigt wurden; daher besteht der erste Schritt darin, zu prüfen, was der Abrufmechanismus zurückgegeben hat, bevor der Prompt geändert wird.
Die zehn Fehler lassen sich in vier Gruppen nach dem Verarbeitungspfad einteilen. Die Nummern 1 bis 4 beeinträchtigen den Inhalt, der in den Vektor-Speicher gelangt. Die Nummern 5 bis 7 betreffen die Architektur des Abrufvorgangs. Die Nummern 8 und 9 liegen in der Rangliste- und Embedding-Phase. Nummer 10 bezieht sich darauf, dass nichts davon gemessen wird.
Unten verwendete Begriffe
- Chunking bezeichnet das Aufteilen von Quelldokumenten in Abschnitte vor der Indizierung. Sowohl Embedding-Modelle als auch Kontextfenster funktionieren besser mit kurzen, fokussierten Einheiten als mit ganzen Dateien.
- Dichte Suche (Vektorsuche) platziert Abfragen und Chunkes in einem gemeinsamen Embedding-Raum und gibt die nächstgelegenen Ergebnisse zurück. Sie ist stark bei Paraphrasen, aber schwach bei wörtlichen Texten.
- Sparse Suche wie BM25 ordnet Chunkes nach gemeinsamen Abfragedingen und gewichtet seltene Wörter stärker. Codes, Namen und Fachbegriffe passen gut dazu, Synonyme hingegen nicht.
- Hybride Suche führt beide Suchverfahren nebeneinander aus und fügt die beiden Ranglisten zusammen, meist mithilfe von Reciprocal Rank Fusion (RRF). RRF verwendet Rangpositionen anstelle von Rohwerten, wodurch das Problem gelöst wird, dass BM25-Werte und Kosinusähnlichkeiten nicht vergleichbar sind.
Vier Fehler bei der Aufteilung in Blöcke
1. Die Aufteilung in feste Größen als Standard verwenden und nie andere Methoden testen
Tutorials verwenden zunächst die Aufteilung jedes Dokuments in 500-Token-Blöcke, unabhängig vom Inhalt. Das dauert fünf Minuten, funktioniert gut genug für Demonstrationen, und Teams setzen es ohne weitere Überprüfung ein.
Die Studien sind sich hier uneinig, und das anzugeben ist nützlicher, als einen Konsens vorzutäuschen. Mehrere Vergleiche aus dem Jahr 2026 bevorzugen eine feste oder rekursive Tokenaufteilung gegenüber semantischem Chunking. In einem umfangreichen Benchmark verschiedener Strategien siegte die rekursive Aufteilung in 512 Token, teilweise weil das semantische Chunking im Durchschnitt nur Fragmente von 43 Token erzeugte, die zu klein waren, um Kontext zu tragen. Andere Studien aus anderen Bereichen deuten in eine andere Richtung: Eine wissenschaftlich geprüfte Bewertung von Systemen zur Unterstützung klinischer Entscheidungen zeigte eine Genauigkeit von 87 % bei adaptivem, themenorientiertem Chunking im Vergleich zu 50 % bei einer festen Basislösung (p = 0,001). Ein weiterer Vergleich ergab, dass eine gut abgestimmte feste Tokenanzahl in echten Datensätzen dem semantischen Splitting gleichkommen oder es sogar übertreffen konnte, was im Einklang mit den ursprünglichen 100-Wort-Abschnitten in der RAG-Publikation steht.
Keine Strategie funktioniert überall. Alle Quellen sind sich einig, dass das Problem nicht darin liegt, eine feste Teilung zu wählen, sondern darin, einfach irgendeine Strategie zu wählen, ohne eine Alternative am tatsächlichen Korpus zu testen.
Die praktische Lösung besteht darin, zu messen anstatt zu theorisieren. Sammeln Sie 20 bis 50 repräsentative Frage-Antwort-Paare, indizieren Sie dasselbe Korpus unter zwei oder drei möglichen Strategien und vergleichen Sie Recall@5 sowie die Kontextgenauigkeit. Inhalte mit eingebauter Struktur, wie API-Dokumente, rechtliche Unterlagen und Finanzberichte, funktionieren in der Regel besser, wenn sie zunächst entlang dieser Struktur geteilt werden, da diese Einheiten bereits kohärent sind:
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Recursive splitting respects structure first, falls back to
# character boundaries only when a section is still too large.
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, # tokens, not characters, if you swap in a token-aware splitter
chunk_overlap=75, # ~15% overlap, a reasonable starting point
separators=["\n## ", "\n### ", "\n\n", "\n", ". ", " "],
)
chunks = splitter.split_text(document_text)
2. Eine Blockgröße für jede Dokumentart
Die Größe wird einmalig und frühzeitig anhand einer Faustregel festgelegt und anschließend auf eine gemischte Sammlung angewandt. API-Referenzen, lange Richtliniedokumente sowie Chat-Transkripte erhalten alle denselben Block.
Überdimensionierte Blöcke schwächen das Relevanzsignal. Ein 2.000-Token großer Block, der fünf Themen umfasst, ergibt einen Vektor, der ein verschwommenes Durchschnittswert aller fünf Themen ist und keines davon gut abbildet. Zu kleine Blöcke führen dazu, dass der Leser den benötigten Kontext verliert – wie bei einer Funktionssignatur ohne Angaben zu den Parametern oder einem Satz ohne Angabe zur betroffenen Abschnitt.
Die Größe sollte der Inhaltsdichte entsprechen. Technische Dokumentation umfasst in der Regel etwa 256 bis 512 Token, was dazu beiträgt, dass sich einzelne Konzepte auf einen Punkt konzentrieren. Erzählerischer oder politischer Text benötigt in der Regel 1.024 bis 2.048 Token, um den umgebenden Kontext beizubehalten. Dies sind Ausgangspunkte zur Überprüfung, denn die richtige Zahl hängt vom Embedding-Modell sowie davon ab, wie die Nutzer ihre Fragen formulieren.
3. Überlappungen ignorieren
Überlappungen werden einmal festgelegt und danach ignoriert oder weggelassen, weil sie angeblich Speicherplatz verschwenden. Ohne sie wird ein Satz, der eine Grenze zwischen Blöcken überschreitet, in zwei Teile geteilt. Ein Block endet mit der Einleitung und der nächste beginnt mit dem Schluss – weder kann als Ganzes verstanden werden. Dies ist ein häufiger und völlig vermeidbarer Grund für die Beschwerde, dass die Antwort irgendwo vorhanden ist, das Modell sie jedoch nicht finden kann.
Ein Überschneidungsbereich von 10 bis 20 % der Chunk-Größe ist ein sinnvoller Standardwert: 50 bis 100 Token für einen 500-Token-Chunk – das ist günstig im Vergleich zu den Fehlern, die dadurch vermieden werden. Mehr ist nicht immer besser. Eine viel höhere Überschneidung führt meist zu zusätzlichem Speicherbedarf und Störungen, und zumindest eine systematische Analyse aus dem Jahr 2026 mit SPLADE-Retrieval fand in dieser Konfiguration keinen messbaren Vorteil durch Überschneidungen. Die optimale Einstellung sollte durch gezielte Einstellungen bestimmt werden, nicht durch den Standardwert.
4. Ignorieren der eigenen Struktur des Dokuments
Es ist einfacher, jede Datei als einheitlichen Block zu behandeln – egal ob es sich um eine Markdown-API-Dokumentation, einen Vertrag mit nummerierten Klauseln oder einen stark tabellarischen Finanzbericht handelt – doch eine strukturunabhängige Aufteilung führt oft dazu, dass eine Überschrift von ihrem jeweiligen Abschnitt oder eine Tabelle vom erklärenden Absatz getrennt wird. Typischerweise wird dadurch eine Funktion Beschreibung von ihrer Parameterliste getrennt, wodurch eine Frage zu dieser Funktion nur eine unvollständige Antwort liefert.
Die Lösung besteht darin, zunächst nach Struktur zu teilen – entlang von Überschriften, Abschnitten, Listen und Tabellen – und nur innerhalb der zu großen Abschnitte eine nach Größe gestützte Aufteilung zu verwenden. Aus diesem Grund sind bis Mitte 2026 die meisten Produktions-Pipelines zur Aufteilung von Daten hybride Ansätze: Zuerst Struktur, anschließend semantische Aufteilung in langen, unstrukturierten Abschnitten, feste Größen als letztes Mittel – und keine einzige Methode wird auf ein gemischtes Korpus aufgezwungen.
Drei Fehler in der Sucharchitektur
5. Alleinige Verwendung der Vektorabfrage
Startvorlagen verwenden standardmäßig die Vektorabfrage. Es handelt sich dabei um einen einzigen API-Aufruf, und sie wirkt in einer Demo hervorragend, in der die Testabfragen konversationelle Paraphrasen sind – genau das, wofür dichte Embeddings am besten geeignet sind.
Reales Traffic unterscheidet sich vom Demo-Traffic. Nutzer geben Produktcodes, Fehlermeldungen, Flaggennamen, Ticketnummern sowie Eigennamen ein – alles kurze, wörtliche Tokens. Dichte Modelle, die darauf trainiert sind, Bedeutungen zu gruppieren, neigen dazu, diese mit verwandten, aber falschen „Nachbarn“ zu verwechseln. Benchmarks zeigen immer wieder diesen Unterschied: Eine optimierte hybride Lösung übertraf in einem E-Commerce-Ranking-Test jede Methode für sich allein, und ein Praxis-Benchmark zeigte, dass eine rein vektorbasierte Methode bei der Recall@10-Rate hinter einer richtig kombinierten hybriden Lösung zurückblieb – hauptsächlich aufgrund fehlender exakter Identifikatoren. Die Zahlen variieren je nach Korpus, doch die Richtung bleibt überall dort bestehen, wo getestet wurde. Immer dann, wenn Abfragen sowohl konversationellen als auch exakt-matching-Stil kombinieren – was fast immer der Fall ist – gewinnt die hybride Lösung.
Die Änderung besteht darin, neben dem Vektorindex einen BM25- oder SPLADE-Index hinzuzufügen. Weaviate, Elasticsearch, OpenSearch, Qdrant und Milvus unterstützen mittlerweile alle nativ hybride Abfragen, und sowohl LangChain als auch LlamaIndex liefern Fusion-Retriever, die diese Funktionen bereitstellen:
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_texts(chunk_texts)
bm25_retriever.k = 20
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# weights are a starting point for RRF-style blending; tune against your eval set
hybrid_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6],
)
results = hybrid_retriever.invoke(user_query)
6. Zusammenführung mit gewichteter Durchschnittsberechnung, nicht RRF
Nach dem Hinzufügen von BM25 ist der intuitive Schritt, beide Score-Listen auf den Bereich 0 bis 1 zu normalisieren und sie mit einem Gewicht zu mischen. In einer Tabellenkalkulation erscheint das sinnvoll. Doch die BM25-Scores sowie die Kosinusähnlichkeiten stammen aus unbegrenzten, unterschiedlich geformten Verteilungen, und die Min-Max-Normalisierung ist anfällig. Ein Ausreißer-Dokument, das einen Abfragedurchschnitt Dutzende Male wiederholt, kann nach der Normalisierung alle anderen BM25-Scores auf Null drücken und so die zusammengeführte Rangliste auf eine Weise verfälschen, die ohne gezielte Überprüfung schwer erkennbar ist.
Die rekursive Rangfusionsmethode umgeht dieses Problem, indem sie die Rangposition jedes Dokuments in jeder Liste verwendet und die Scores völlig ignoriert. Deshalb ist RRF und nicht die gewichtete Durchschnittsberechnung die Standardmethode in nahezu allen in technischen Berichten aus dem Jahr 2026 genannten produktiven hybriden Implementierungen. Die Standardformel gibt jedem Dokument die Summe von 1 / (k + Rang) für alle Listen, in denen es erscheint, wobei k=60 ein gängiger Standardwert ist, der den Einfluss extrem hoher oder niedriger Ränge dämpft.
7. Ein k für jede Stufe
Top-k ist in der Regel eine globale Konstante, die bei der ersten Suchphase, bei der Fusion sowie für die endgültige Anfrage wiederverwendet wird. Wenn die erste Phase nur die wenigen Datenblöcke abruft, die die Anfrage aufnehmen kann, ist die Erinnerungsfähigkeit bereits vor dem Eingreifen des Neurangiers verschwunden: Ein Datenblock, der bei der Vektorsuche auf Platz 14 landete, erreicht die Anfrage niemals. Der gegenteilige Fehler besteht darin, Hunderte von Kandidaten an einen Neurangier zu liefern, ohne anschließend zu prüfen, wodurch Zeit und Geld verschwendet werden und die Anfrage mit schwachem Material gefüllt wird. Die Aufmerksamkeit des großen Sprachmodells verschlechtert sich unter dieser Belastung (Effekt des „Verlorengehens in der Mitte“), wodurch die Vorteile des Neurankings unbemerkt zunichte gemacht werden.
Betrachten Sie k stattdessen als Trichter. Nehmen Sie in der ersten Phase eine große Anzahl an Kandidaten – etwa 20 bis 100 – damit der Reranker Raum hat, frühe Sortierfehler zu korrigieren, und reduzieren Sie anschließend die Auswahl auf eine kleine Endgruppe von rund 3 bis 8 Elementen für die Ausgabe. Justieren Sie das k für jede Phase separat anhand des Bewertungssatzes, da ein einziger Wert nicht beiden Zwecken dienen kann.
Zwei Fehler bei der Rangliste und den Embeddings
8. Verzicht auf Reranking
Reranking beinhaltet einen zusätzlichen Netzwerkaufruf oder eine Inferenzschritt, was zu Verzögerungen führt und bei gehosteten Diensten zu zusätzlichen Kosten. Unter Zeitdruck wird dies als Erstes gestrichen, wodurch die Reihenfolge in der ersten Phase als endgültig angesehen wird.
Die Vektorsuche in der ersten Stufe stützt sich auf Bi-Encoder, die einen Textabschnitt bereits vor dem Eintreffen einer Abfrage in einen festen Vektor komprimieren. Dadurch sind sie in großen Skalen schnell, doch ihre Genauigkeit wird eingeschränkt, da die feinabgestimmte Interaktion zwischen einer bestimmten Abfrage und einem bestimmten Textabschnitt verloren geht. Cross-Encoder wiederherstellen diese Interaktion, indem sie sowohl die Abfrage als auch den Textabschnitt gleichzeitig verarbeiten. Unabhängige Berichte aus dem Jahr 2026 bezeichnen das Umrangieren der Ergebnisse mit Cross-Encodern als die beste Ergänzung für Pipelines mit einer ordentlichen Erststufen-Suche: Typischerweise sind Gewinne von mehreren Punkten in der Genauigkeit oder im NDCG zu verzeichnen, und bei lexikalisch schwierigen Datensätzen werden Werte in den Zwanzigern erreicht – all das bei einer zusätzlichen Latenz von unter 200 ms bei vernünftigen Pool-Größen. Ein Kundenprojekt eines Beratungsunternehmens verzeichnete durch das Umrangieren der Ergebnisse einen Anstieg der Genauigkeit um 23 Punkte, was größer war als jeder Einfluss durch Embeddings oder Änderungen der Blöchkopfgröße. Sobald eine hybride Suche funktioniert, ist dies das Nächste, was man ausprobieren sollte.
Die Änderung besteht darin, eine Neurankierungsstufe zwischen Fusion und dem endgültigen Prompt einzufügen. Für die Selbsthosting-Lösung ohne Gebühr pro Aufruf ist bge-reranker-v2-m3 ein beliebter offener Cross-Encoder mit guter Mehrsprachigkeitsabdeckung. Cohere’s Rerank API ist die übliche verwaltete Alternative, wenn keine GPU-Infrastruktur gewünscht wird. Beide integrieren sich in LangChain und LlamaIndex:
from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)
def rerank(query: str, candidates: list[str], top_k: int = 5) -> list[str]:
pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [text for text, _ in ranked[:top_k]]
final_context = rerank(user_query, fused_candidates, top_k=5)
9. Ein allgemeines Embedding-Modell auf einem spezialisierten Korpus
Das mit dem Framework gelieferte Embedding-Modell wird oft direkt auf ein rechtliches, medizinisches oder finanzielles Korpus angewendet, wobei dies durch einige manuelle Überprüfungen gerechtfertigt wird. Allzweckmodelle lernen aus umfangreichen Web- und enzyklopädischen Texten und unterscheiden daher weniger klar zwischen Fachjargon und allgemeinem Sprachgebrauch als Modelle, die auf fachspezifischem Material trainiert wurden. Dieser Mangel hat besonders große Auswirkungen dort, wo die Risiken am höchsten sind. In regulierten Bereichen führt ein Fehlgriff – beispielsweise ein Abschnitt über den Standardverfahren anstelle der spezifischen Ausnahme, nach der gefragt wurde – zu einer Antwort, die plausibel erscheint, aber falsch ist, was schlimmer ist als ein offensichtlicher Fehler.
Vor dem Commit sollte man mindestens einen auf das jeweilige Domänenumfeld angepassten oder feinabgestimmten Embedder gegen den allgemeinen Standard auf der Referenzdatensammlung testen. Wenn eine Feinabstimmung des Embedders nicht möglich ist, kann ein auf einer kleinen Menge von gelabelten Domänenabfragen trainierter Cross-Encoder-Reranker oft den größten Teil des Unterschieds schneller und kostengünstiger ausgleichen, da er die Fehler in der ersten Bearbeitungsstufe behebt, ohne das gesamte Korpus erneut einbetten zu müssen.
Der Fehler, der die anderen verdeckt
10. Abrechnung nach Anzeigenaufrufen
Die Evaluierungsinfrastruktur wirkt im Vergleich zur Entwicklung neuer Funktionen wie eine Überlast, und es scheint auszureichen, sich einige Ausgaben anzusehen, solange die Demo gut aussieht. Mit Abstand verursacht dies die größten nachgelagerten Kosten, denn dadurch werden die anderen neun Probleme übersehen. Halluzinationen, die technisch auf dem abgerufenen Kontext beruhen, Dokumente in der falschen Reihenfolge sowie in genau falschen Grenzen abgeschnittene Abschnitte lassen sich durch das Lesen der Ausgaben nicht zuverlässig erkennen, und bis die Nutzer sie melden, sind sie bereits in Produktion.
Die Lösung besteht aus einer „goldenen Sammlung“ von 50 bis 200 repräsentativen Frage-Antwort-Paaren, die Randfälle wie mehrdeutige Formulierungen, mehrstufige Fragen, die zwei Dokumente erfordern, sowie feindliche Umformulierungen abdecken. Sie wird mit einem standardmäßigen Bewertungssystem in zwei Teilen bewertet. Der Informationsabrufmechanismus wird anhand von Präzision und Erinnerung im Kontext beurteilt, während der Antwortgenerator anhand von Treue und Relevanz der Antwort bewertet wird. Zwei Frameworks dominieren diesen Bereich, und Teams kombinieren sie oft. Ragas ist der übliche Ort, um Metriken zu untersuchen, und sein synthetischer Generator kann eine „goldene Sammlung“ aus dem Korpus erstellen, die von einem Menschen weiter verfeinert werden kann. DeepEval, das auf pytest basiert, ist die übliche Methode, um die Bewertung zu einem echten CI-Checkpoint zu machen. Eine gängige Aufteilung besteht darin, Ragas für die Erkundung und Datenerzeugung sowie DeepEval für die Überprüfung jeder Pull-Request-Nachfrage zu verwenden:
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase
def test_refund_policy_query():
test_case = LLMTestCase(
input="What is the refund window for the Pro plan?",
actual_output=rag_pipeline.run("What is the refund window for the Pro plan?"),
retrieval_context=rag_pipeline.last_retrieved_chunks,
expected_output="Pro plan purchases can be refunded within 14 days of purchase.",
)
faithfulness = FaithfulnessMetric(threshold=0.8)
precision = ContextualPrecisionMetric(threshold=0.7)
assert_test(test_case, [faithfulness, precision])
Setzen Sie ein solches System in CI ein, sodass eine Anpassung der Aufteilung der Daten, ein Austausch von Einbettungen oder ein Update der Wissensdatenbank, das die Suchleistung verschlechtert, den Build abbricht, bevor der Tag eines Kunden ruiniert wird.
Wie sich die Fehler je nach Einstellung unterscheiden
- Interne Unternehmenssuche und Dokumenten-FAQs, die häufigste Konfiguration, sind stark von einer hybriden Suchmethode abhängig. Das Personal fügt Ticketnummern, Richtliniencodes und SKUs zusammen mit Fragen in Alltagssprache ein, wobei eine reine Textsuche den wörtlichen Inhalt oft übersehen wird.
- Kundenorientierte Support-Bots profitieren am meisten von einer Neubewertung der Ergebnisse. Eine flüssige, aber falsche Antwort führt dort eher zu einem Ticket oder zum Verlust des Kontos statt zu einem gleichgültigen Achselzucken eines Kollegen.
- Geregulierte Branchen (Finanzen, Gesundheitswesen, Recht) benötigen auf den jeweiligen Bereich abgestimmte Embeddings oder Reranker sowie eine strenge Bewertung, da eine nahezu fehlerfreie Suche zu Compliance-Problemen und Haftungsrisiken führen kann.
- Verbraucherprodukte mit hohem Traffic arbeiten unter den strengsten Latenzgrenzen für Fusion und Reranking. Das Ziel ist die beste Genauigkeit, die dennoch in ein Suchbudget von unter 200 ms passt – wodurch kleine Cross-Encoders oder selbst gehostete GPU-Reranker den größten Modellen vorgezogen werden.
- Code-Assistenten und Entwickler-Tool-Plattformen stellen einen neuartigen und schnell wachsenden Anwendungsfall dar, bei dem strukturbewusstes Aufteilen wichtiger ist als bei Prosa. Code und API-Referenzen sind stark strukturiert, und ein unvorsichtiges Aufteilen zerstört genau die Struktur, die sie suchbar macht.
Die nächste Entscheidung treffen
In der Vorab-Phase, also noch während getestet wird, ob RAG überhaupt praktikabel ist, ist eine Suchfunktion, die ausschließlich Vektoren verwendet, der richtige Ausgangspunkt: Sie lässt sich am schnellsten implementieren und beantwortet die Frage zur Architektur bereits innerhalb eines Tages. Sobald es echte Benutzeranfragen gibt, sollten die Protokolle nach exakt übereinstimmenden Mustern wie Produktnummern, Ticket-IDs und Konfigurationswerten durchsucht werden. Falls solche gefunden werden, sollte zunächst BM25 in Kombination mit RRF eingeführt werden, da Quellen dies einheitlich als den größten einzelnen Verbesserungsfaktor bei der Informationsabrufung bezeichnen – und das mit großem Abstand. Erst danach kommt das Neuranking, wenn die hybride Suche funktioniert und das Ziel Präzision statt reiner Erinnerung ist. Diese Methode ist kostengünstig, was sie leistet, und erfordert keinen Neubau des Index. SPLADE oder auf bestimmte Domänen abgestimmte Embeddings sollten von Teams verwendet werden, die bereits über einen ausgereiften Bewertungsprozess verfügen und nachgewiesen haben, dass eine Kombination aus Hybridsuche und Neuranking Lücken aufweist – schließlich erfordern sie mehr Aufwand und Wartung und lassen sich ohne eine Grundlagenmetrik nur schwer rechtfertigen.
Die Anzahl der Mitarbeiter und das Budget bestimmen die Antwort. Mit zwei Ingenieuren ist eine verwaltete Reranking-API (Cohere ist die übliche Wahl) vorteilhafter als der Betrieb eines eigenen Cross-Encoders: Bei geringem Traffic sind die Gebühren im Vergleich zu den Stunden, die GPU-Server verbrauchen, gering. Wenn bereits MLOps-Mitarbeiter und GPUs vorhanden sind oder der Traffic so hoch ist, dass die Abrechnung pro Anfrage relevant wird, macht es mehr Sinn, ein offenes Modell wie bge-reranker-v2-m3 zu hosten.
Was eine gute Pipeline trotzdem kostet
RAG ist keine perfekte Lösung. Seine größte Stärke liegt in der Verankerung in externen Quellen: Antworten können auf abgerufte Quellen verweisen, anstatt sich ausschließlich auf das zu stützen, was das Modell auswendig gelernt hat, und die Wissensdatenbank kann ohne Neutraining aktualisiert werden. Die zusätzlichen Komponenten bringen jedoch tatsächlich erhebliche Betriebsbelastung mit sich. Es müssen zwei Indizes synchronisiert werden, ein Neurankierungsmechanismus, um Abweichungen zu überwachen, ein Bewertungspfad, der als erstklassiges Ergebnis erhalten bleiben muss, sowie ein Chunking-Verfahren, das überprüft werden muss, wenn sich die Zusammensetzung der Dokumente ändert.
RAG beseitigt außerdem keine Halluzinationen. Er verringert zwar Falschdarstellungen aufgrund fehlender Kenntnisse, lässt aber den Fall unberührt, in dem das LLM den ihm korrekt bereitgestellten Kontext falsch interpretiert oder anwendet. Es gibt Treue-Metriken, weil „in abgerufenem Kontext verankert“ und „korrekt“ unterschiedliche Eigenschaften sind, und ein ausgereifter Prozess misst beides.
Produktionsreife
- Bewertung in CI. Führen Sie die Paarung von Ragas und DeepEval für jeden Prompt, jeden Änderung an dem Retriever oder an der Wissensdatenbank durch, anstatt dies nur einmal bei der Veröffentlichung zu überprüfen.
- Index-Synchronisierung. Aktualisieren Sie die BM25- und Vektorindizes gemeinsam oder nach demselben Zeitplan. Wenn ein veralteter, spärlicher Index zusammen mit frischen Embeddings verwendet wird, führt dies zu Abweichungen bei der Informationsabrufung, die schwer zu erkennen sind.
- Beobachtbarkeit. Erfassen Sie die für jede Anfrage abgerufenen Teile, nicht nur die endgültige Antwort. Dadurch kann eine schlechte Antwort ohne Spekulation entweder auf das Informationsabrufen oder auf die Generierung zurückgeführt werden.
- Anmeldeinformationen. Halten Sie die API-Schlüssel für das Neuranking sowie für die Embeddings außerhalb des Repositoriums und wechseln Sie sie über den üblichen Secrets Manager aus.
Die kurze Lektion
Betrachten Sie, was der Retriever zurückgegeben hat, bevor Sie den Prompt oder das Modell ändern. Neun der zehn Fehler (schlechtes Chunking, keine hybride Suche, naive Fusion, falsch dimensionierte Kandidatenpools, übersprungenes Neuranking, unüberprüftes Embedding-Modell) sind Retrieval-Probleme, für die es Lösungen gibt. Der zehnte Fehler, nämlich das Fehlen einer Bewertung, ist der Grund, warum die anderen neun so oft unentdeckt bleiben.
Keine der Lösungen erfordert ein Forschungsteam. Das Hinzufügen von BM25 neben einem bestehenden Vektorlagern, das Ersetzen der Score-Verrechnung durch RRF oder das Weglassen einer Neubewertung zwischen Fusion und Erstellung entspricht eher einer ingenieurtechnischen Aufgabe als einer Neugestaltung, und alle diese Ansätze erhalten konsequente Unterstützung aus unabhängigen Quellen – selbst wenn die Zahlen unterschiedlich sind. Ein praktischer Einstieg: Holen Sie sich zwei Wochen an echten Benutzerabfragen, zählen Sie, wie viele davon exakte Identifikatoren enthalten, die bei einer Vektorsuche unklar würden, und erstellen Sie aus bereits vorhandenen Fehlern eine Gold-Set mit 50 Abfragen. Das ist weniger, als es klingt, und zeigt, welche der zehn Fehler am meisten kosten.
Verwandte Artikel
- Debugging leiser RAG-Fehler: Abruf, Chunking, Filter und Bewertungen — RAG-Antworten können richtig klingen und dennoch falsch sein. Ein für Python-Entwickler gedachter Leitfaden zur Nachverfolgung von Abrufen, Chunking, Metadatenfiltern, Bewertungen, hybriden Suchverfahren und Grundlagenverifizierungen.
- Hybrider RAG für Rechtstexte: Chunking, BM25, BGE und Neubewertung — Ein RAG-Pipeline für Rechtstexte basierend auf der indischen Verfassung: Eltern-Kind-Chunking, Abruf mit BM25 plus BGE, Rangfusion, Neubewertung durch Cross-Encoder sowie Abfragedehnung, getestet an Benchmarks.