rag chunking vector-search reranking llm-evaluation

Warum RAG bei echten Dokumenten versagt: Chunking, hybrider Suchalgorithmus, Neuranking und Bewertungsmethoden.

Warum RAG bei echten Dokumenten versagt und die Methoden, um dies zu beheben: ein zweiphasiges Design, Entscheidungen bei der Aufteilung in Blöcke, hybrische Suche, Neubewertung sowie Bewertung der Suche allein.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20267 Min. Lesezeit1518 Wörter

Quellen: Production-Ready RAG Architecture: Core Patterns Explained

Warum Demos mit echten Daten versagen

RAG-Tutorials laufen in der Regel mit einem ordentlichen PDF oder einer Wikipedia-Exportdatei, was nicht dem tatsächlichen Einsatzfall entspricht. Wenn derselbe Prozess auf echtes Unternehmensmaterial angewandt wird – mit ungleichmäßiger Formatierung, Supportanfragen und umfangreichen internen Wikis – liefern die Antworten oft unvollständige, erfundene oder eindeutig falsche Ergebnisse. Zwei Gründe erklären nahezu jeden Produktionsfehler.

RAG ist zunächst ein Abrufsystem und erst in zweiter Linie ein Generierungssystem. Wenn beim Abruf der falsche Kontext angezeigt wird, hat das Modell trotz aller Fähigkeiten kaum eine Chance auf eine richtige Antwort.
Die Gesamtqualität wird durch die schwächste Stufe begrenzt, nicht durch den Durchschnitt. Ein starkes Embedding-Modell kann keinen Chunker retten, der einen Satz in zwei Teile geschnitten hat.

Zwei Phasen

Jedes RAG-System besteht aus einer Offline-Indizierungsphase und einer Online-Abfragesphase:

Indexing (offline):   documents → chunks → embeddings → vector store
Query (online):       question → embedding → retrieval → context assembly → LLM

Produktionsumgebungen fügen um diese Grundstruktur Caching, Neuranking, Schutzmechanismen, Überwachung sowie Fallback-Logik hinzu, bleibt aber dennoch die Basis für alles Weitere – und kein Tool kann eine schwache Basis reparieren.

Chunking lohnt sich am meisten

Die meisten Systeme versagen bei der Aufteilung in Blöcke, und dieses Versagen bleibt unsichtbar, bis man drei Schritte später eine falsche Antwort debuggt. Das ist wichtig, weil eingebettete Modelle am besten mit kohärenten Textabschnitten funktionieren, Kontextfenster begrenzt sind, übermäßig große Blöcke Störungen verursachen und zu kleine Blöcke die umliegenden Fakten ausschließen, die eine Antwort benötigt.

Beim Chunking mit fester Größe werden alle N Token mit 10 bis 20 Prozent Überschneidung geteilt. Es ist einfach und vorhersehbar, ignoriert jedoch die Grenzen von Sätzen und Absätzen, wodurch beispielsweise eine Definition unerkannt geteilt werden kann. Es handelt sich dabei um einen gängigen Ausgangspunkt, der selten der beste ist.

Rekursives oder hierarchisches Chunking versucht zunächst natürliche Trennpunkte, doppelte Zeilenumbrüche, anschließend einfache Zeilenumbrüche, dann Sätze und schließlich Wörter – es greift erst dann auf andere Methoden zurück, wenn ein Abschnitt immer noch zu groß ist. Die meisten Frameworks verwenden heutzutage standardmäßig diese Methode, und sie stellt eine klare Verbesserung gegenüber einer rein festen Größenanpassung dar.

Strukturbezogenes Chunking folgt der eigenen Gliederung des Dokuments: Überschriften, Abschnitte, Codeblöcke und Tabellen. Bei technischen Dokumenten und Markdown ist diese Methode oft deutlich überlegen. Bewahren Sie Eltern-Kind-Verbindungen auf, damit Sie auf einen kleinen, präzisen Abschnitt zugreifen und bei Bedarf auf den gesamten übergeordneten Abschnitt erweitern können.

Semantisches Chunking nutzt ein Embedding-Modell oder ein LLM, um herauszufinden, wo sich das Thema tatsächlich ändert, und teilt dort den Text auf. Es liefert die kohärentesten Abschnitte – allerdings zu einem echten Zusatzkostenfaktor, da jede Grenzentscheidung eine Modellaufruf erfordert – weshalb es in der Regel nur für Korpora verwendet wird, bei denen die Qualität der Informationsabrufung die Kosten rechtfertigt.

Sensible Standardwerte:

Beginnen Sie mit rekursivem oder strukturbezogenem Aufteilen und vermeiden Sie das Aufteilen nach fester Größe.
Streben Sie nach Blöcken mit etwa 300 bis 800 Token an, und passen Sie diese anschließend an Ihr eigenes Bewertungsset an – nicht an eine Zahl aus einem Blog.
Speichern Sie Metadaten zu jedem Block, wie zum Beispiel das Quelldokument, den Abschnittstitel sowie die Seiten- oder Absatznummer. Filterung und Zitierungen benötigen diese später.
Sammeln Sie eine kleine Anzahl echter Fragen und prüfen Sie, was abgerufen wird, bevor Sie das Embedding-Modell verwenden. Eine schlechte Aufteilung verschlechtert heimlich die Ergebnisse – beheben Sie sie daher vor der Anpassung weiterer Komponenten.

Embeddings und Vektordatenspeicher

Embedding-Modelle platzieren Text in einem hochdimensionalen Raum, in dem semantische Nähe zu geometrischer Nähe wird, wobei dies in der Regel durch Kosinusähnlichkeit oder Skalarprodukt bewertet wird. Das Modell ist zwar wichtig, doch Datenqualität und die Aufteilung des Textes in Abschnitte spielen in der Regel eine größere Rolle als das jeweilige Modell innerhalb des Pipelines. Zu den wichtigsten Kategorien gehören allgemein einsetzbare offene Modelle, domainspezifische Embeddings für juristischen, medizinischen oder Code-Text sowie proprietäre APIs. Wählen Sie entsprechend dem Wortschatz Ihres Bereichs – nicht allein aufgrund der Rangliste.

Die eigentliche Aufgabe eines Vektorlagers besteht darin, schnell eine annähernde Suche nach dem nächsten Nachbarn durchzuführen, da eine genaue, brute-force-basierte Vergleichsmethode nur für kleine Datensammlungen praktikabel ist. Die meisten Lager verwenden graphbasierte Indizes wie HNSW oder clusterbasierte Indizes wie IVF, sodass eine Abfrage nicht mit jedem Vektor verglichen werden muss. Der Kompromiss besteht darin, dass zwar die Chance besteht, den wahren nächsten Nachbarn zu übersehen, dafür aber die Abfristzeit sublinear ist. Dieser Parameter wird selten früh angepasst, doch das Wissen darum hilft, wenn man herausfinden möchte, warum der offensichtlich richtige Datensatz nicht abgerufen wurde.

Beim Auswahl eines Lagers sollten Sie prüfen, ob er nach Metadaten filtert, ob er native hybride Suchfunktionen aus Vektoren und Schlüsselwörtern (BM25) unterstützt, wie einfach er lokal im Vergleich zu einer verwalteten Variante betrieben werden kann, sowie wie die Persistenz, Replikation und Skalierbarkeit bei Ihrem Datenvolumen aussehen. Zu den gängigen Optionen gehören Qdrant, Weaviate, Pinecone, Chroma, pgvector und OpenSearch k-NN.

Ursprünglich zählt die Marke des Shops weniger als vier weitere Faktoren: ordentliche Daten, solide Strukturierung, korrekte Metadaten sowie eine Möglichkeit, Vektor- und Schlüsselwortsuche zu kombinieren. Die hybride Suche kommt in nahezu jeder ernsthaften Implementierung zum Einsatz, da die reine Vektorabfrage immer wieder literale Token wie Fehlercodes, Produkt-SKUs und IDs übersieht, die eine Schlüsselwortabfrage mühelos erfasst. Die Kombination von dichten und spärlichen Bewertungen wird in der Regel durch einen einzigen Gewichtsfaktor gesteuert, sodass eine Abfrage je nach Anwendungsfall entweder auf die Bedeutung oder auf genaue Begriffe ausgerichtet werden kann. Ein konzeptioneller hybrider Ansatz sieht so aus, wobei sich die genaue API je nach Shop unterscheidet:

# Conceptual shape of a hybrid query — exact API varies by vector store
results = vector_store.hybrid_search(
    query=user_question,
    alpha=0.5,          # weight between dense (1.0) and keyword (0.0) search
    filters={"doc_type": "runbook", "product": "checkout-service"},
    top_k=25,
)

Jenseits der top-k-Ähnlichkeit

Das Auswählen der top-k nächsten Abschnitte ist nur der Beginn der Extraktion, nicht ihr Ende. Reales Datenverkehrsmaterial weist weiterhin dieselben Probleme auf: Der nächstgelegene Abschnitt ist nicht unbedingt der nützlichste, die Fakten einer Antwort sind auf mehrere Abschnitte verteilt, Modelle schenken dem Material in der Mitte eines langen Kontexts zu wenig Aufmerksamkeit – selbst wenn es dort vorhanden ist (Effekt des „Verlorengehens in der Mitte“) – und das Embedding-Modell versteht möglicherweise das Vokabular Ihres Fachgebiets nicht.

Techniken, die sich lohnen, grob nach dem Nutzen im Verhältnis zur Aufwand:

Neubewertung. Mit einer kostengünstigen Vektorsuche werden eine große Anzahl an Kandidaten ausgewählt – beispielsweise die besten 20 bis 50, manchmal sogar 100 – und anschließend mithilfe eines Cross-Encoders oder eines kleinen LLM neu bewertet, bevor nur diejenigen für die Eingabe ausgewählt werden. Dies zählt stets zu den besten Ergänzungen für einen Arbeitsablauf. Ein Cross-Encoder bewertet Abfrage und Dokument gemeinsam, was weitaus genauer ist als der Vergleich zweier getrennt berechneter Vektoren, er muss jedoch für jeden Kandidaten einmal ausgeführt werden und kann nicht eine ganze Sammlung abdecken. Die Bi-Encoder-Suche ist kostengünstig und ungenau, schränkt das Feld jedoch ein, während der Cross-Encoder teuer und präzise ist, aber nur die verbleibenden Kandidaten prüft.
Hybride Suche, die dichte Vektoren mit spärlicher Schlüsselwortsuche kombiniert, damit genaue Token nicht dem Zufall überlassen werden.

Abfragedurchführung: Die Frage wird umgeschrieben, ein hypothetisches Antwortdokument erstellt und darauf gesucht (im HyDE-Stil), oder eine komplexe Frage wird in unabhängig abgerufene Unterfragen aufgeteilt.

Metadatenfilterung, bei der die Kandidaten vor Durchführung der Vektorabfrage nach Dokumenttyp, Zeitraum oder Produkt eingeschränkt werden und nicht danach.

Auswahl des übergeordneten Dokuments: Es wird anhand eines kleinen, präzisen Teils abgeglichen, doch das größere übergeordnete Dokument wird zurückgegeben, damit der Kontext vollständig ist.

Beurteilung der Abfrageleistung für sich genommen

Eine Bewertungsmenge ist besser als ein Bauchgefühl. Schreiben Sie 20 bis 50 realistische Fragen, notieren Sie, welche Fragmente für jede Frage abgerufen werden sollen, und überprüfen Sie direkt, ob das richtige Fragment zu den Top 5 oder Top 10 gehört (Recall@k). Fügen Sie erst dann einen LLM-Bewerter zur Relevanzprüfung hinzu, wenn die manuelle Überprüfung Ihr Vertrauen gewonnen hat. Wenn die Qualität der Informationsabrufung niemals unabhängig von der Qualität der Antwort gemessen wird, wird Zeit in die Optimierung des falschen Schritts investiert. Open-Tools wie Ragas umfassen spezifische RAG-Metriken, sodass Sie das gesamte System nicht von Hand entwickeln müssen.

LlamaIndex oder LangChain – konzeptionell

LlamaIndex ist datenorientiert und bietet starke, festgelegte Abstraktionen für Indexierungs-, Abruf- und Abfragemaschinen; es fühlt sich natürlich an, wenn das Kernproblem darin besteht, eine Menge an Dokumenten effektiv abrufen zu müssen. LangChain hingegen ist vielseitig einsetzbar, entstanden aus Ketten- und Agentenkonzepten, und verfügt über ein viel umfangreicheres Integrationssystem. Er ist flexibler, erfordert aber entsprechend mehr Ressourcen, wenn nur der Dokumentenabruf notwendig ist. Keines der beiden ist ein Wundermittel, da beide dieselben zugrundeliegenden Muster nutzen. Wählen Sie eines aus, lernen Sie seine Konzepte gründlich kennen und seien Sie nicht dogmatisch – denn das architektonische Wissen bleibt unabhängig von der verwendeten Syntax gültig.

Zusammenfassung

Indexierung und Abfragen sind getrennte Phasen, daher sollten sie unabhängig voneinander entworfen werden.
Das Chunking ist eine bewusste Gestaltungsoption und kein Standard der Frameworks, den man einfach akzeptieren muss.
Vector-Speicher gehören zur Infrastruktur; der Nutzen ergibt sich aus Filtern und hybriden Suchverfahren, nicht aus der Marke des Tools.
Die Qualität der Informationsabrufung muss unabhängig von der Qualität der Antwort gemessen werden.
Frameworks sind Werkzeuge und keine Architekturen, daher sollten die zugrundeliegenden Muster erlernt und das Werkzeug als austauschbar betrachtet werden.