Erst Retrieval, dann Generierung

Wer nicht täglich mit solchen Systemen arbeitet, stolpert weiter unten über ein knappes Dutzend Fachwörter. Sie sind hier einmal in Alltagssprache erklärt; das genügt, um die ganze Notiz zu verstehen.

Chunk

Ein Textabschnitt. Dokumente werden vor dem Einlesen in solche Stücke zerschnitten, weil immer nur einzelne Abschnitte gesucht und an das Sprachmodell weitergereicht werden, nie ganze Bücher.

Embedding

Eine lange Zahlenreihe, die den Inhalt eines Textstücks ausdrückt. Texte mit ähnlicher Bedeutung bekommen ähnliche Zahlenreihen — dadurch lässt sich Ähnlichkeit rechnen statt nur Wörter vergleichen.

Vektor

Das mathematische Wort für ebendiese Zahlenreihe. „Zwei Vektoren liegen nah beieinander" heißt: die beiden Texte ähneln sich inhaltlich.

Vektorspeicher, Index

Die durchsuchbare Ablage aller Chunks samt ihren Zahlenreihen. Im Projekt ist das der Ordner vectorstore. Er wird erzeugt, nicht von Hand gepflegt, und kann jederzeit neu gebaut werden.

Retrieval

Das Heraussuchen der passenden Chunks zu einer Frage. Der Schritt, um den es in dieser Notiz fast ausschließlich geht — noch bevor ein Sprachmodell überhaupt beteiligt ist.

Token

Die Recheneinheit für Text, ungefähr ein Wortteil. Ein Modell mit einer Grenze von 256 Token kann also nur etwa 150 bis 200 deutsche Wörter auf einmal verarbeiten.

dense / sparse

Zwei Suchprinzipien. Dense sucht nach Bedeutungsähnlichkeit und findet auch Umschreibungen; sparse sucht nach den tatsächlichen Wörtern und ist bei Eigennamen und Zitaten überlegen. Beides zusammen heißt hybride Suche.

Reranking

Ein zweiter, genauerer Sortierdurchgang: Man holt bewusst viele Kandidaten und lässt sie von einem präziseren Verfahren neu ordnen, bevor die besten weitergegeben werden.

Prompt

Der Text, den das Sprachmodell tatsächlich zu sehen bekommt — Frage, Gesprächsverlauf und die gefundenen Chunks in einem Stück. Steht in local_rag.py.

Repository

Der Projektordner unter Versionsverwaltung (Git). „Gehört ins Repository" heißt schlicht: als Datei im Projekt ablegen, damit die Änderung nachvollziehbar bleibt.

Wer bereits konkrete Probleme identifiziert hat, findet hier die Phase, die dafür am wahrscheinlichsten verantwortlich ist. Bei allgemeinem Tuning, ohne einem Symptom nachzugehen, werden die Phasen einfach der Reihe nach durchgearbeitet.

Jede Änderung hinterlässt den Eindruck, es sei besser oder schlechter geworden. Dies ist der Versuch, diese Veränderungen etwas strukturierter auf ihre Qualität zu überprüfen. Diese Phase lohnt sich selbst dann, wenn sonst nichts geändert wird.

Einen Satz von 25–40 Referenzfragen anlegen

Echte Fragen aus der tatsächlichen Forschungsarbeit, verteilt über beide Korpora und über verschiedene Fragetypen: eine Faktenfrage an einen Primärtext, eine Frage zur Deutung einer Passage, eine „wer vertritt welche These zu X"-Frage an die Sekundärliteratur, dazu zwei bis drei Fragen, deren Antwort beide Korpora berührt. Zu jeder Frage wird festgehalten, in welcher Datei und auf welcher Seite die Antwort tatsächlich steht.

# eval/goldset.csv
frage,korpus,erwartete_quelle,erwartete_seite,anmerkung
"Wie wird Odradek beschrieben?",primaer,hausvater.pdf,3,"Beschreibung, nicht Deutung"
"Welche Rolle spielt das Gesetz in Vor dem Gesetz?",primaer,prozess.pdf,182,
"Wer liest die Verwandlung als Familienkonflikt?",sekundaer,mueller_2003.pdf,44,"Argument im Fließtext"

Das Retrieval für sich bewerten, ohne LLM in der Schleife

Die Bewertung des Retrievals braucht keine Generierung und ist deshalb kostenlos, deterministisch und in Sekunden statt Minuten durch. Ein kurzes Skript lädt den Vektorspeicher, stellt jede Referenzfrage und berechnet Recall@k — taucht die erwartete Quelle mit der erwarteten Seite unter den ersten k Treffern auf? — für k = 5, 10 und 20, dazu den Mean Reciprocal Rank.

Dieser Ausgangswert gehört als schlichte Textdatei ins Repository. Jede spätere Änderung wird damit zur Differenz gegenüber einer Zahl, und eine Änderung, die diese Zahl nicht bewegt, lässt sich guten Gewissens zurücknehmen.

Das Skript liegt bereit: eval_retrieval.py

Es ist absichtlich schlicht gehalten und lässt sich ohne Programmierkenntnisse bedienen. Alle Einstellungen stehen als Großbuchstaben-Zeilen oben in der Datei; geändert wird dort und sonst nirgends.

1. Eigene Fragen eintrageneval/goldset.csv in Excel, Numbers oder LibreOffice öffnen und die drei Beispielzeilen durch echte Fragen ersetzen. frage: die Frage selbst. korpus: primaer oder sekundaer, damit beide Hälften getrennt ausgewertet werden. erwartete_quelle: der Dateiname, in dem die Antwort steht — ohne Pfad, Groß- und Kleinschreibung egal. erwartete_seite: die Seitenzahl, die der PDF-Betrachter anzeigt; im Zweifel leer lassen, dann zählt nur die Datei. anmerkung: freies Feld für Notizen. Als CSV speichern — ob das Tabellenprogramm Kommas oder Semikolons schreibt, erkennt das Skript selbst.
2. Skript startenIm Terminal, im Projektordner. Der erste Befehl schaltet die für dieses Projekt eingerichtete Python-Umgebung ein — das ist nötig, weil dort die passenden Zusatzpakete liegen; ohne ihn bricht der zweite Befehl mit einer Fehlermeldung über fehlende Module ab. Ollama muss an dieser Stelle nicht laufen, ein OpenAI-Schlüssel wird nicht gebraucht.
3. Zahlen lesenRecall@5 ist der Anteil der Fragen, deren Fundstelle unter den ersten fünf Treffern steht: 0.60 heißt drei von fünf Fragen. MRR beschreibt, wie weit oben die Treffer stehen — 1.00 wäre immer Platz eins, 0.50 im Schnitt Platz zwei. In der Liste der Einzelfragen bedeutet ein Strich statt einer Rangzahl, dass die Stelle unter den ersten 20 Treffern gar nicht auftauchte; diese Fragen sind die interessantesten.
4. Bericht aufhebenDas Skript schreibt eval/baseline.txt. Diese Datei ins Repository legen und bei jeder späteren Messung mit einer kurzen Notiz versehen, was zwischenzeitlich geändert wurde. Genau dieser Vergleich ist der Zweck der Übung.
5. Gegenprobe zum ZusatztextOben im Skript steht USE_QUERY_INSTRUCTIONS. Auf True gesetzt hängt das Skript den Zusatztext aus local_rag.py an jede Frage an. Ein Lauf mit True und einer mit False beantworten die Frage aus Phase 01, ob dieser Text tatsächlich hilft.

conda activate local_rag
python eval_retrieval.py

Zwanzig zufällige Chunks selbst lesen

Zwanzig Chunks direkt aus dem Speicher exportieren und als Mensch lesen. Beachtenswert sind: Sätze, die mitten im Teilsatz abbrechen; Anmerkungen, die in den Fließtext hineinragen; Seitenzahlen und Spaltentitel mitten im Absatz; Trennstriche, die vom Zeilenumbruch übrig geblieben sind; Literaturverzeichniszeilen, die wie Fließtext indexiert wurden. Grob schätzen, welcher Anteil eines Chunks Material ist, auf das man eine Antwort wirklich stützen möchte. Dieser Anteil ist der zweite Ausgangswert — und meist der aufschlussreichere von beiden.

Vier Eigenschaften eines Setups aus LangChain, FAISS und sentence-transformers, die das Retrieval unbemerkt verschlechtern und leicht zu übersehen sind.

from local_rag import LocalRAG
rag = LocalRAG()
print(rag.embeddings.client.max_seq_length)

Die beiden Pipelines verlangen von der Extraktion Verschiedenes: Bei den Primärtexten ist es vor allem eine Frage der Textbeschaffung, bei der Sekundärliteratur entscheidet sich die Extraktionsqualität. Bevor man eine der beiden für erledigt erklärt, lohnt der Blick darauf, was ein allgemeiner Loader eigentlich tut — PyPDFLoader und Verwandte — ein Loader ist das Stück Programm, das ein PDF einliest und in reinen Text verwandelt — behandeln eine Seite als einen flachen Zeichenstrom, also als eine einzige lange Buchstabenkette ohne Wissen darüber, was Überschrift, Fließtext oder Anmerkung war.

Die Primärtext-Pipeline

Erzählungen und Romane sind vergleichsweise einfach — kein Literaturverzeichnis, kein zweispaltiger Satz. Eine weitere Bearbeitung des Ausgangsmaterials könnte in erster Linie Seitenzahlen, Anmerkungen o.ä. entfernen.

Die Sekundär-Pipeline: ein Parser, der Dokumentstruktur erkennt

Hier liegt bei einer Vorverarbeitung viel Potenzial. Idealerweise verwenden wir einen Extraktor, der typisierte Elemente statt eines Zeichenstroms zurückgibt: Er liefert also nicht nur den Text, sondern zu jedem Stück auch die Angabe, worum es sich handelt — Überschrift, Fließtext, Fußnote, Literaturangabe. Damit wird aus einem mühsamen Textbereinigungsproblem eine schlichte Entscheidung pro Sorte: diese behalten, jene weglassen.

Es empfiehlt sich, Fußnoten/Anmerkungen mit element_type: footnote in den Metadaten zu indexieren. Standardmäßig könnte man sie vom Retrieval ausschließen und bei Bedarf wieder zuschalten. Löschen wäre unumkehrbar.

Werkzeuge, grob nach Aufwand geordnet

Alles in dieser Phase spielt sich in einer einzigen Datei ab: local_rag.py. Zur Orientierung vorab, welche Änderung wo ansetzt und was danach fällig wird. Die Zeilennummern sind Stand heute und verschieben sich beim Bearbeiten — verlässlich ist der genannte Ort.

„Index neu bauen" heißt jedes Mal dasselbe: add_pdfs.py mit CLEAR_VECTORSTORE_FIRST = True laufen lassen. Der alte Index passt nach solchen Änderungen nicht mehr und würde stillschweigend Unsinn liefern. Direkt danach eval_retrieval.py starten und die neue Zahl mit der alten vergleichen.

Das Embedding-Modell kommt zuerst

Bei einem deutschsprachigen Korpus könnte ein englisch trainiertes Modell mit kurzem Kontextfenster problematisch sein. Kandidaten, alle lokal lauffähig, sind:

• BAAI/bge-m3 — mehrsprachig, verkraftet lange Eingaben und liefert aus einem Modell dense und sparse Repräsentationen, womit hybride Suche (Phase 04) fast geschenkt ist. Hier eine gute Voreinstellung.
• intfloat/multilingual-e5-large — starke mehrsprachige Qualität, 512-Token-Fenster. Achtung: Dieses Modell erwartet, dass jedem Text ein Kennwort vorangestellt wird — query: vor der Frage, passage: vor dem Textabschnitt —, damit es beide unterschiedlich behandelt. Wird das vergessen, verschlechtern sich die Ergebnisse messbar, ohne dass eine Fehlermeldung darauf hinweist.
• jinaai/jina-embeddings-v3 — mehrsprachig, langer Kontext, aufgabenspezifische Adapter.

Im Code steht der Modellname genau einmal, in LocalRAG.__init__. Ein Wechsel ist wörtlich ein Austausch dieser Zeichenkette; das Modell wird beim ersten Start automatisch heruntergeladen, was einige Minuten dauern kann:

# local_rag.py, in LocalRAG.__init__ (derzeit Zeile 48)
self.embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-m3"        # vorher: sentence-transformers/all-MiniLM-L6-v2
)

Ein Hinweis, der bei der Modellwahl den Ausschlag geben kann: Bei bge-m3 genügt tatsächlich diese eine Zeile. Bei multilingual-e5-large reicht sie nicht, weil das Modell die oben erwähnten Kennwörter erwartet — Fragen und Textabschnitte müssten an zwei weiteren Stellen unterschiedlich behandelt werden. Wer den Aufwand klein halten will, nimmt deshalb bge-m3.

Wenn eine API in Frage kommt, sind gehostete Embedding-Modelle (Voyage, Cohere, OpenAI) bei mehrsprachigem Material meist noch einmal besser, zu Kosten, die bei dieser Korpusgröße vernachlässigbar sind — vorher ist allerdings zu klären, ob Institutsmaterial überhaupt an einen externen Dienst übergeben werden darf — das entscheidet der Datenschutz, nicht die Pipeline.

Danach die Chunk-Größe auf das setzen, was das Modell tatsächlich liest

Die Größe steht als Konstante ganz oben in der Datei, gut sichtbar und ohne Umwege änderbar. Die Werte sind Zeichen, nicht Token:

# local_rag.py, Zeile 16/17
CHUNK_SIZE = 2000
CHUNK_OVERLAP = 400   # wie viel benachbarte Chunks einander überlappen

Die Überlappung sorgt dafür, dass ein Gedanke, der genau auf einer Schnittkante liegt, nicht verloren geht — er steht dann am Ende des einen und am Anfang des nächsten Chunks. Als Faustregel liegt sie bei etwa einem Fünftel der Chunk-Größe.

Steht das Modell fest, wollen die beiden Korpora unterschiedlich geteilt werden:

• Primärtexte: an Absatz- und Szenengrenzen trennen statt nach fester Zeichenzahl. Erzählte Bedeutung übersteht Schnitte mitten im Satz nicht, und literaturwissenschaftliche Fragen hängen oft an der Gestalt einer Passage.
• Sekundärtexte: an Abschnittsgrenzen trennen, mit einer Obergrenze — und erwägen, jedem Chunk vor dem Embedding die Zwischenüberschrift und einen kurzen bibliografischen Nachweis voranzustellen, sodass er „Müller 2003, 3.2 Familienstruktur" mit sich führt. Ein isolierter Absatz aus der Mitte einer Argumentation ist sonst kontextlos; bei wissenschaftlichen Korpora hilft das zuverlässig.

Womit an welchen Stellen getrennt wird, steuert der Parameter separators. Die Liste wird von oben nach unten abgearbeitet: Erst wird an doppelten Zeilenumbrüchen — also Absätzen — geteilt, und nur wenn ein Stück dann immer noch zu groß ist, greift der nächste Eintrag. So bleiben Absätze ganz, solange es geht:

# local_rag.py, in LocalRAG.__init__ (derzeit Zeile 53)
self.text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=CHUNK_SIZE,
    chunk_overlap=CHUNK_OVERLAP,
    separators=["\n\n", "\n", ". ", " ", ""],   # Absatz, Zeile, Satz, Wort, Notfall
)

Wer für die beiden Korpora unterschiedlich trennen will, findet dafür genau eine Stelle. In add_documents wird jedes geladene Dokument durch denselben Splitter geschickt — hier würde eine Fallunterscheidung ansetzen, etwa anhand des Ordners, aus dem die Datei stammt:

# local_rag.py, in add_documents (derzeit Zeile 114/115)
docs = loader.load()
chunks = self.text_splitter.split_documents(docs)   # <- der eine Verzweigungspunkt
all_docs.extend(chunks)

Klein suchen, groß liefern

Kleine Chunks finden präzise, große Chunks antworten gut. Man muss sich nicht entscheiden: kleine Chunks (ca. 400–800 Zeichen) für den Abgleich indexieren, dem LLM aber deren übergeordneten Abschnitt übergeben. LangChain — die Programmbibliothek, auf der das Projekt aufbaut — bringt dafür eine fertige Komponente namens ParentDocumentRetriever mit, die genau diese Verdopplung von Such- und Liefereinheit übernimmt. Es ist das übliche Mittel, wenn ein kurzes Fragment über wenige passende Wörter einen Trefferplatz gewinnt und dabei viel unverbundenes Umgebungsmaterial in den Kontext zieht.

Ehrlicherweise ist das der größte Eingriff dieser Phase und anders als die bisherigen keine Einzeiler-Sache. Das Projekt greift derzeit unmittelbar auf den Vektorspeicher zu:

# local_rag.py, in query_with_history (derzeit Zeile 251)
docs_with_scores = self.vectorstore.similarity_search_with_score(retrieval_query, k=k)

Für „klein suchen, groß liefern" müsste dieser Aufruf durch den Retriever ersetzt und zusätzlich eine zweite Ablage für die großen Abschnitte angelegt werden — FAISS speichert nur die kleinen Stücke. Vorübergehend entfallen dadurch auch die Ähnlichkeitswerte in der Protokollausgabe. Deshalb steht dieser Punkt hinten: erst die billigen Änderungen messen, dann entscheiden, ob der Umbau überhaupt noch nötig ist.

Metadaten (falls vorhanden)

Metadaten sind Zusatzangaben, die an jedem Chunk mitgeführt werden — vergleichbar mit den Feldern eines Bibliothekskatalogs. Sie werden nicht durchsucht, aber man kann nach ihnen filtern. Falls sie durch eine Vorverarbeitung existieren, sollten mindestens mitgeführt werden: element_type (Fließtext / Anmerkung / Literaturverzeichnis), work bzw. author_year, section und page. Erst damit lassen sich Anmerkungen von einer Suche ausschließen oder eine Suche auf ein einzelnes Werk beschränken, ohne irgendetwas neu zu bauen.

source und page setzt der Loader bereits von allein. Eigene Angaben kommen an derselben Stelle dazu, an der auch getrennt wird — wichtig ist allein die Reihenfolge: vor dem Aufteilen, denn die Chunks erben die Metadaten des Dokuments, aus dem sie stammen:

# local_rag.py, in add_documents — zwischen Laden und Aufteilen
docs = loader.load()

for doc in docs:                                    # neu
    doc.metadata["korpus"] = "sekundaer"            # z. B. aus dem Ordnernamen
    doc.metadata["element_type"] = "body"

chunks = self.text_splitter.split_documents(docs)   # erbt die Angaben von oben

Gefiltert wird später bei der Suche, indem dem Aufruf ein filter mitgegeben wird — etwa filter={"element_type": "body"}, um Anmerkungen auszublenden. Ob es etwas gebracht hat, zeigt eval_retrieval.py unmittelbar danach.

Stichwortsuche neben die Vektoren stellen

Reines "Dense Retrieval" ist genau bei dem schwach, wovon der vorhandene Korpus voll ist: Eigennamen, Kunstwörter, Werktitel, wörtliche Zitate. Eine Anfrage nach Odradek oder Gregor Samsa will einen lexikalischen Treffer, keine semantische Näherung. Also BM25 parallel zur Vektorsuche laufen lassen: BM25 ist die klassische Stichwortsuche, wie man sie aus Bibliothekskatalogen kennt — sie zählt, welche Suchwörter wie häufig und wie selten im Text vorkommen, und findet damit genau das Wörtliche, das die Bedeutungssuche übersieht. Die beiden Trefferlisten werden anschließend zu einer verrechnet; das Standardverfahren dafür heißt Reciprocal Rank Fusion und gewichtet einen Treffer danach, wie weit oben er in den einzelnen Listen stand. In LangChain sind dafür EnsembleRetriever und BM25Retriever vorgesehen, es bleibt also eine kurze Änderung. Im literaturwissenschaftlichen Retrieval ist das oft ein großer und sofort sichtbarer Gewinn.

Danach mit einem Cross-Encoder umsortieren

Die Form des Retrievals ändert sich: statt 5 werden 30 bis 50 Kandidaten geholt, von einem Cross-Encoder gegen die Anfrage bewertet und auf die besten 5 bis 8 eingedampft. Ein Cross-Encoder ist ein zweites, kleineres Modell mit einer anderen Arbeitsweise: Die normale Suche berechnet für Frage und Textabschnitt getrennt je eine Zahlenreihe und vergleicht diese; der Cross-Encoder bekommt beides zusammen vorgelegt und beurteilt direkt, ob der Abschnitt zur Frage passt. Das ist zu langsam, um damit hunderttausende Chunks zu durchsuchen, aber genau richtig für eine Handvoll Kandidaten — und deutlich treffsicherer — und er ist besonders gut darin, zitatlastige, inhaltsarme Passagen nach hinten zu schieben.

• BAAI/bge-reranker-v2-m3 — mehrsprachig, lokal lauffähig; auf GPU bequem, auf CPU machbar, aber langsam.
• Cohere Rerank — API, starke mehrsprachige Qualität, minimaler Integrationsaufwand.

Nach Phase 02 und 03 ist das typischerweise der größte verbleibende Sprung.

1. Referenzfragen anlegen und Ausgangswert festhalten25–40 echte Fragen mit bekannter Fundstelle; Recall@5/10/20 ohne LLM. Zahlen ins Repository.
2. Zwanzig Chunks von Hand lesenAbschätzen, welcher Anteil Apparat und Layout-Rauschen ist. Meist die aufschlussreichste halbe Stunde.
3. Chunk-Größe gegen das Modellfenster prüfenAlles jenseits des Fensters wird verworfen, bevor der Vektor berechnet wird.
4. Prüfen, was Anweisungstext in der Anfrage bewirktRecall mit und ohne messen, statt anzunehmen, dass er hilft.
5. Auf ein mehrsprachiges Modell mit langem Kontext wechselnbge-m3 als Voreinstellung; Chunk-Größe passend nachziehen. Neu bauen, neu messen.
6. Sekundärkorpus mit einem strukturbewussten Parser neu extrahierenGROBID oder Docling. Anmerkungen und Literaturverzeichnis in Metadaten auszeichnen, nicht löschen.
7. Falls möglich: Saubere digitale Editionen für die Primärtexte beschaffenPDF-Extraktion umgehen, wo es schon eine TEI- oder Plaintext-Ausgabe gibt.
8. Falls die Dokumente geparst wurden und nicht mehr direkt auf PDFs gearbeitet wird: element_type als Metadatum ergänzen, mit FilterAnmerkungen standardmäßig ausschließen, aber zuschaltbar halten, damit beides testbar bleibt.
9. BM25 neben die Vektoren stellenEigennamen und wörtliche Zitate brauchen lexikalischen Abgleich.
10. 30–50 Kandidaten holen und auf 5–8 umsortierenMeist der größte verbleibende Gewinn, und er setzt sich hinter einen unveränderten Index.
11. Erst jetzt Antwort-Prompt und Modell überarbeitenAb hier sind die verbleibenden Fehler tatsächlich Generierungsfehler.