Angewandte RAG-Forschung: Chunking, hybrides Retrieval, Reranking und Quellenbindung im Praxistest

Stand November 2026 · CODLAB Team

Kurzantwort: Ein belastbares Retrieval-Augmented-Generation-System (RAG) entsteht nicht durch ein größeres Sprachmodell, sondern durch präzise Vorarbeit beim Suchen: strukturelles Chunking mit Metadaten, hybrides Retrieval aus lexikalischer Volltextsuche und Vektorsuche in PostgreSQL, nachgelagertes Reranking, harte Distanzschwellen für ehrliche Antwortverweigerung sowie überprüfbare Quellenverweise über Sprachgrenzen (DE/IT/EN) hinweg.

Warum angewandte RAG-Forschung vor dem Sprachmodell beginnt

Wenn ein interner Dokumentenassistent im Unternehmen eine unvollständige oder falsche Auskunft gibt, fällt der Verdacht fast immer sofort auf das Sprachmodell. In der angewandten Entwicklungs- und Forschungsarbeit bei CODLAB im Bereich Souveräne KI & Daten setzen wir die Fehleranalyse methodisch jedoch eine Stufe früher an — bei der Suche: Ein Modell kann sprachlich sauber formulieren und dennoch inhaltlich scheitern, sobald ihm die Suchstufe abgeschnittene Textfragmente, veraltete Revisionsstände oder semantisch naheliegende, fachlich jedoch unzuständige Absätze übergibt.

Das Grundprinzip von Retrieval-Augmented Generation wurde von Patrick Lewis et al. (2020) eingeführt, um parametrisches Modellwissen mit einem expliziten, austauschbaren Dokumentenindex zu verbinden (Lewis et al., NeurIPS 2020, arXiv:2005.11401). Für den industriellen und regulierten Mittelstand verschiebt sich dadurch die eigentliche Forschungsfrage: Nicht „Welches Modell kennt die meisten Fakten auswendig?", sondern „Unter welchen architektonischen Bedingungen findet die Suchstufe verlässlich die autorisierten Passagen — und wann erkennt das System zuverlässig, dass keine ausreichende Quelle vorliegt?"

Genau diese Trennung zwischen Suchqualität (Retrieval) und Antworttreue (Generation) dokumentieren wir in unseren CODLAB Engineering Notes, insbesondere in der technischen Notiz RAG bewerten: Retrieval und Antworten getrennt. Dieser Artikel führt die einzelnen Bausteine einer modernen RAG-Pipeline zusammen und zeigt, wie sich Architekturentscheidungen im eigenen Bestand systematisch prüfen lassen.

1. Strukturelles Chunking statt starrer Zeichenfenster

Jede Indexierung beginnt mit der Zerlegung längerer Dokumente in abrufbare Einheiten (Chunks). In schnellen Prototypen wird Text häufig nach jeweils N Token mit starrer Überlappung geschnitten. In technischen Handbüchern, Richtlinien oder Vertragswerken zerstört dieses Verfahren genau jene Bezüge, von denen die fachliche Korrektheit abhängt:

• Tabellen und Grenzwerte: Werden Kopfzeile und Tabellenkörper getrennt, verliert eine Temperatur-, Druck- oder Fristenangabe ihre Einheit und ihre Bedingung.
• Ausnahmen und Verweise: Steht der Grundsatz am Ende von Abschnitt 4.1, die entscheidende Einschränkung („gilt nicht bei...") jedoch am Anfang von Abschnitt 4.2, erzeugt ein harter Fensterschnitt ein Fragment, das für sich genommen das Gegenteil der dokumentierten Regel nahelegt.
• Gültigkeitskontext: Ohne mitgeführte Dokumentmetadaten ist im einzelnen Absatz nicht mehr erkennbar, ob er aus einer aktuellen Arbeitsanweisung oder aus einem archivierten Entwurf stammt.

Für komplexe Unternehmensdokumente entwerfen wir Chunking in unserer Zielarchitektur deshalb als strukturerhaltende Transformation statt als bloße Zeichenzählung: Überschriftenpfade (Dokumenttitel → Kapitel → Unterabschnitt) und zusammenhängende Tabellen samt Spaltenköpfen sollen als expliziter Kontext erhalten bleiben. Hier unterscheiden wir bewusst zwischen dieser Enterprise-Zielarchitektur und dem bewusst schlanken Referenz-Assistenten (ragbot) im Code von codlab.de (dessen öffentliche Chat-Demo seit Oktober 2026 abgeschaltet ist, während Code und Daten erhalten bleiben): Da dieses Modul für überschaubare Webseiten ausgelegt ist, bereinigt sein Einlesekommando (rag_ingest) HTML zu Fließtext und schneidet nach Satz- und Zeichengrenzen mit Überlappung, ohne eigene Hierarchie-Metadaten zu führen. Im Code umgesetzt ist dort hingegen die inhaltsbasierte Idempotenz über SHA-256: Das Django-Modell DocumentChunk speichert neben source_url, source_title und chunk_index ein indiziertes Feld content_hash, sodass unveränderte Abschnitte beim erneuten Einlesen übersprungen und geänderte Passagen gezielt neu eingebettet werden.

Welche Chunk-Größe für einen konkreten Dokumentbestand optimal ist, behandeln wir bewusst nicht als allgemeingültige Faustformel, sondern als messbare Forschungsfrage am jeweiligen Korpus: Kurze Fragmente erhöhen die Präzision einzelner Sätze, verlieren aber abteilungsübergreifenden Zusammenhang; lange Fragmente bewahren Kontext, verwässern jedoch den Embedding-Vektor.

2. Vektorsuche, lexikalische Suche und hybrides Retrieval in PostgreSQL

Dichte Vektorrepräsentationen (Dense Passage Retrieval, vgl. Karpukhin et al., 2020, arXiv:2004.04906) bilden Texte in einen hochdimensionalen Vektorraum ab, sodass synonyme Formulierungen nahe beieinander liegen. Fragt eine Mitarbeiterin beispielsweise nach „Wiederanlauf nach Not-Aus", kann die Vektorsuche auch einen Abschnitt mit der Überschrift „Rücksetzen der Sicherheitskette" finden. Für die Nachbarschaftssuche in PostgreSQL nutzt CODLAB die Erweiterung pgvector mit einem HNSW-Index (Hierarchical Navigable Small World, vgl. Malkov & Yashunin, arXiv:1603.09320).

Im Referenz-Assistenten (ragbot) ist diese Vektorschicht deklarativ im Django-ORM abgebildet (1536 Dimensionen, HnswIndex mit m=16, ef_construction=64 und Kosinus-Distanzoperator vector_cosine_ops) und arbeitet dort als reine Kosinus-Vektorsuche ohne Volltextspalte oder Mandantenfelder. Für komplexe Fachkorpora im Mittelstand reicht reine Vektorsuche jedoch oft nicht aus: Exakte Bezeichner wie Bauteilnummern (BG-4410-RevC), Normverweise (DIN EN ISO 13849-1), Fehlercodes oder Gesetzesparagraphen werden von allgemeinen Embedding-Modellen häufig auf unscharfe Nachbarn abgebildet.

In unserer Enterprise-Zielarchitektur erweitern wir diese PostgreSQL-Basis daher zu hybridem Retrieval. Statt eine separate Vektordatenbank neben der Anwendungsdatenbank zu betreiben — mit allen Risiken asynchroner Replikation und abweichender Zugriffsrechte — kombiniert dieser Entwurf zwei komplementäre Suchpfade in derselben Transaktions- und Berechtigungsschicht:

1. Semantischer Pfad: Annähernde Nächste-Nachbarn-Suche (ANN) über pgvector mittels Kosinus-Distanz für begriffliche Ähnlichkeit und Umschreibungen.
2. Lexikalischer Pfad: Klassische Volltextsuche über tsvector, tsquery und GIN-Indizes direkt in PostgreSQL (PostgreSQL Documentation, Chapter 12: Full Text Search), ergänzt um Trigramm- oder exakte Filter für Artikelnummern, Aktenzeichen und Normen.

Beide Trefferlisten werden anschließend über ein rangbasiertes Fusionsverfahren (etwa Reciprocal Rank Fusion) zusammengeführt, bevor die engere Auswahl an das Sprachmodell geht. Wie Vorfilter, Mandantengrenzen und HNSW-Ausführungspläne in PostgreSQL zusammenspielen — insbesondere warum ein restriktiver WHERE-Filter bei ANN-Indizes die tatsächliche Trefferzahl unerwartet reduzieren kann, wenn ef_search und iterative Index-Scans (technische Voraussetzung: pgvector ≥ 0.8.0) nicht geprüft werden — erläutern wir detailliert in unserer Notiz pgvector mit Django: Filter und Recall prüfen.

# Zielarchitektur für Mandantensysteme (Erweiterung gegenüber dem Einzelkorpus-Referenzmodell ragbot ohne tenant_id):
# Berechtigungsfilter greifen deterministisch VOR Distanzberechnung und Schwellenwert
allowed_chunks = EnterpriseDocumentChunk.objects.filter(
    tenant_id=active_tenant.id,
    collection__in=user_permitted_collections,
).exclude(embedding=None)

candidates = (
    allowed_chunks
    .annotate(distance=CosineDistance("embedding", query_vector))
    .order_by("distance")[:candidate_pool_size]
)
verified_hits = [c for c in candidates if c.distance is not None and c.distance <= max_distance]

3. Reranking und das „Lost-in-the-Middle"-Problem langer Kontextfenster

Mit wachsenden Kontextfenstern moderner Sprachmodelle liegt ein vermeintlich bequemer Ausweg nahe: Warum nicht einfach 40 bis 60 gefundene Absätze in den Prompt kopieren und das Modell selbst auswählen lassen? Empirische Untersuchungen von Nelson F. Liu et al. zeigen, warum diese Strategie in der Praxis kostspielig und fehleranfällig ist (Liu et al., „Lost in the Middle: How Language Models Use Long Contexts", arXiv:2307.03172): Sprachmodelle gewichten Informationen am Anfang und am Ende einer langen Eingabe deutlich stärker als relevante Fakten in der Mitte des Kontexts. Zugleich steigen Antwortlatenz, Speicherbedarf im KV-Cache und das Risiko widersprüchlicher Textstellen.

Eine zweistufige Retrieval-Architektur löst diesen Zielkonflikt durch Cross-Encoder-Reranking (vgl. Nogueira & Cho, 2019, arXiv:1901.04085):

• Stufe 1 (schnelle Vorauswahl): Hybrides Retrieval grenzt den Dokumentbestand auf eine überschaubare Kandidatenmenge ein (z. B. Top-25 bis Top-40); die tatsächliche Abfragelatenz ist dabei keine feste Konstante, sondern hängt von Korpusgröße, HNSW-Parametern (m, ef_search), Filterselektivität und Hardware ab und muss am Zielbestand gemessen werden. Da Frage und Dokument beim Embedding getrennt kodiert wurden (Bi-Encoder), bleibt feine Wortinteraktion hier noch unberücksichtigt.
• Stufe 2 (feingranulares Reranking): Ein spezialisiertes Cross-Encoder-Modell betrachtet Frage und Kandidatenabsatz gemeinsam über alle Aufmerksamkeitslayer hinweg und berechnet einen präzisen Relevanzwert. Nur die wenigen höchstbewerteten, deduplizierten Passagen gelangen in geordneter Reihenfolge in den Prompt des generativen Modells.

Ebenso wichtig wie die Sortierung ist eine explizite Relevanzschwelle. Im Referenz-Assistenten (ragbot) im Code von codlab.de verwirft die Abrufschicht beispielsweise alle Treffer oberhalb einer Kosinus-Distanz von 0.62 (MAX_DISTANCE = 0.62 bei Top-5-Abruf). Bleibt nach dieser Filterung kein belastbarer Abschnitt übrig, ruft das Backend das Sprachmodell gar nicht erst zum Raten auf, sondern gibt deterministisch eine ehrliche Ablehnung zurück. Für Unternehmensanwendungen ist diese gesteuerte Enthaltung (Abstention) kein Mangel, sondern eine zentrale Sicherheitsfunktion.

4. Zitate, Grounding und warum eine Fußnote noch keinen Beleg beweist

Viele Systeme werben mit anklickbaren Quellennummern wie [1] oder [2]. Auch unser Referenz-Assistent (ragbot) im Code von codlab.de nummeriert die übergebenen Quellenblöcke eindeutig, dedupliziert identische Quell-URLs und verpflichtet das Modell im Systemprompt, ausschließlich auf Basis dieser Passagen zu antworten. Dennoch unterscheiden wir in unserer Forschung strikt zwischen Zitationsformat und inhaltlicher Stützung (Faithfulness / Grounding).

Ein Sprachmodell kann einen formal korrekten Marker [1] hinter einen Satz setzen, obwohl es dabei eine Bedingung aus Quelle [1] weglässt oder zwei getrennte Aussagen unzulässig verknüpft. Zudem muss jedes RAG-System berücksichtigen, dass abgerufene Dokumente selbst fehlerhafte oder manipulierte Anweisungen enthalten können — ein Aspekt, den wir in unserer Notiz RAG: Quellen als nicht vertrauenswürdige Daten gesondert behandeln.

In einem belastbaren Prüfprotokoll bewerten wir Grounding daher auf Satz- und Aussagenebene: Jede fachliche Behauptung der Antwort wird in elementare Einzelaussagen zerlegt und gegen den tatsächlich abgerufenen Quelltext abgeglichen. Fehlt im Quelltext eine einschränkende Voraussetzung, gilt die Antwort als unzureichend gestützt — selbst wenn der Link auf das richtige Dokument zeigt.

5. Mehrsprachige Wissensbasen (DE/IT/EN) im europäischen Mittelstand

Viele mittelständische Unternehmen im deutschsprachigen Raum arbeiten täglich mehrsprachig: Konstruktionsrichtlinien und Betriebsanweisungen liegen auf Deutsch vor, Zuliefererspezifikationen aus Norditalien auf Italienisch und Halbleiter- oder Software-Datenblätter auf Englisch. Ein einsprachig gedachtes RAG-System scheitert hier an zwei Stellen: Erstens bricht die lexikalische Suche weg, wenn eine deutsche Anfrage auf ein englisches Datenblatt trifft; zweitens entstehen subtile Übersetzungsfehler bei Fachbegriffen, wenn Abkürzungen oder Rechtsbegriffe ungeprüft übertragen werden.

In unserer angewandten Arbeit untersuchen wir für mehrsprachige Korpora (DE/IT/EN) drei kombinierbare Muster:

• Mehrsprachige Embeddings mit sprachspezifischer Metadatenführung: Moderne mehrsprachige Vektormodelle projizieren semantisch äquivalente Sätze aus Deutsch, Italienisch und Englisch in benachbarte Vektorregionen, während das Sprachkennzeichen jedes Dokuments explizit gespeichert bleibt.
• Kontrollierte Anfrageerweiterung (Query Translation / Glossar-Mapping): Unternehmensspezifische Fachbegriffe werden vor der Suche über ein freigegebenes Terminologie-Wörterbuch ergänzt, damit auch der lexikalische Pfad exakte fremdsprachige Bauteil- oder Prozessbezeichnungen erfasst.
• Sprachgetrennte Ausgabekontrolle: Die Antwort erfolgt in der Sprache der Anfrage, kennzeichnet aber transparent, aus welcher Originalsprache die zitierte Fundstelle stammt, damit Fachleute den Wortlaut im Original prüfen können. Welche Sorgfalt bei mehrsprachigen Oberflächen, URLs und Metadaten insgesamt erforderlich ist, zeigt ergänzend unsere Notiz Django i18n: Sprache, URLs und Metadaten prüfen.

6. Synthetisches Prüfbeispiel für Entscheider im Mittelstand

Hinweis zur Einordnung: Das folgende Szenario ist vollständig synthetisch und dient ausschließlich der methodischen Veranschaulichung. Es beschreibt kein Kundenprojekt und keine gemessenen Kundenergebnisse.

Angenommen, ein mittelständischer Sondermaschinenbauer möchte seinen Servicetechnikern eine interne Dokumentensuche über freigegebene Wartungshandbücher (Deutsch), Komponentendatenblätter (Englisch) und Lieferantenprotokolle (Italienisch) bereitstellen. Statt sofort hunderte Ordner unstrukturiert einzulesen, gehen wir in einem reproduzierbaren Forschungs- und Pilotraster vor:

1. Prüfkorpus abgrenzen: Auswahl von 30 bis 50 repräsentativen, freigegebenen Dokumenten inklusive zweier bewusst aufgenommener Revisionsstände desselben Handbuchs und eines gesperrten Dokuments zur Rechteprüfung.
2. Fragenkatalog mit Referenzstellen definieren: Zusammenstellung von Fachfragen aus dem Servicealltag — darunter exakte Fehlercode-Anfragen, mehrsprachige Detailfragen, widersprüchliche Fassungen und unbeantwortbare Gegenfragen außerhalb des Bestands.
3. Architekturvarianten gegeneinander messen: Vergleich von reinem Vektor-Retrieval gegen hybrides Retrieval mit Reranking anhand getrennter Kennzahlen für Trefferquote der erwarteten Fundstellen (Recall@k), korrekte Enthaltung bei fehlender Quelle und fachliche Antworttreue.
4. Entscheidungsgrundlage dokumentieren: Erst wenn die Suchstufe die erwarteten Passagen reproduzierbar liefert und Zugriffsrechte auf Datenbankebene nachgewiesen sind, wird über den produktiven Ausbau entschieden.

Wie ein solcher begrenzter Einstieg organisatorisch und technisch abläuft, beschreiben wir unter Dokumentenassistenten auf eigenen Unterlagen. Wenn Sie für Ihren eigenen Dokumentbestand klären möchten, welche Retrieval-Architektur fachlich und wirtschaftlich trägt, erreichen Sie uns direkt für ein unverbindliches Gespräch über Kontakt & Projektanfrage.

Weiterführend in dieser Forschungsreihe: Wie man Such- und Antwortqualität unter nicht-deterministischer Dekodierung statistisch belastbar misst, zeigt unser Beitrag zu Mehrfachläufen und getrennten RAG-Metriken; welche architektonischen Schutzgrenzen gegen manipulierte Dokumente nötig sind, analysiert der Folgeartikel zu Indirect Prompt Injection und Quellengrenzen.

Verifizierte Primärquellen

• Lewis, P. et al. (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020, arXiv:2005.11401).
• Karpukhin, V. et al. (2020): Dense Passage Retrieval for Open-Domain Question Answering (EMNLP 2020, arXiv:2004.04906).
• Malkov, Yu. A. & Yashunin, D. A. (2016/2018): Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (arXiv:1603.09320).
• Nogueira, R. & Cho, K. (2019): Passage Re-ranking with BERT (arXiv:1901.04085).
• Liu, N. F. et al. (2023/2024): Lost in the Middle: How Language Models Use Long Contexts (TACL, arXiv:2307.03172).
• PostgreSQL Global Development Group: PostgreSQL Documentation — Chapter 12: Full Text Search sowie pgvector v0.8.0.

Ergänzender Praxisleitfaden im Blog: KI-Dokumentensuche auf Ihren eigenen Daten: Was vor dem Pilot geklärt sein sollte.