Dokumente vorbereiten
Quellen werden in kleinere Chunks zerlegt. Größe, Überlappung und Metadaten entscheiden stark darüber, ob später der richtige Kontext gefunden wird.
Deep Dive · RAG
RAG verbindet semantische Suche mit LLM-Antworten: Erst werden passende Textstellen über Embeddings gefunden, dann nutzt das Modell diese Textstellen als Kontext. Das Muster ist besonders stark, wenn Nutzer natürlich fragen sollen, aber die Antwort in eigenen Dokumenten liegen muss.
Kuratierter erster Schnitt · Stand Mai 2026
RAG beantwortet Fragen mit zusätzlichem Kontext aus eigenen Dokumenten. Das System sucht zuerst nach semantisch ähnlichen Textstellen. Diese Fundstücke werden zusammen mit der Frage an das LLM gegeben, damit die Antwort auf konkretem Kontext basiert.
Der entscheidende Punkt: RAG macht Dokumentwissen über Bedeutungssuche zugänglich. Es geht weniger um exakte Stichwörter als um passende Kontexte: Welche Textstellen helfen dem Modell, eine konkrete Frage sachlich, quellenbezogen und verständlich zu beantworten?
Vom Dokument zur Antwort
Quellen werden in kleinere Chunks zerlegt. Größe, Überlappung und Metadaten entscheiden stark darüber, ob später der richtige Kontext gefunden wird.
Jeder Chunk wird in einen Vektor übersetzt. Der Vektor beschreibt numerische Nähe im Modellraum und macht ähnliche Formulierungen vergleichbar.
Eine Nutzerfrage wird ebenfalls eingebettet. Der Vektorindex liefert die ähnlichsten Chunks, meist ergänzt durch Filter, Ranking oder Reranking.
Das LLM erhält Frage und gefundene Textstellen. Die Qualität hängt davon ab, ob der Kontext vollständig, präzise und widerspruchsarm ist.
Viele Missverständnisse entstehen, wenn Embeddings, Index, Retriever und LLM als eine einzige magische Komponente behandelt werden. Praktisch sind es getrennte Entscheidungen, die jeweils Fehler erzeugen können.
Numerische Repräsentation eines Textes. Ähnliche Formulierungen, Themen und Begriffe liegen im Modellraum näher beieinander.
Datenstruktur für schnelle Ähnlichkeitssuche. Sie macht große Dokumentmengen über semantische Nähe durchsuchbar.
Komponente, die aus Frage, Filtern, Index und Ranking den Kontext für das LLM zusammenstellt.
Kleiner Textabschnitt aus einer Quelle. Gute Chunks sind klein genug für präzise Treffer und groß genug für tragfähigen Kontext.
Graphbeziehung zwischen ähnlichen Chunks oder Entitäten. Sie macht semantische Nähe im Graph navigierbar.
Chunking ist eine frühe Qualitätsentscheidung. Der Schnitt entscheidet, wie gut der Retriever genau die Textstelle findet, die eine Antwort trägt.
Texte werden nach Zeichen oder Tokens geschnitten. Das ist einfach, schnell und braucht zusätzliche Prüfung bei Überschriften, Tabellen und Sinnabschnitten.
Abschnitte folgen Überschriften, Absätzen oder Themenwechseln. Das ist meist besser für Handbücher, Policies und längere Fachtexte.
Kleine Chunks werden gesucht, aber größere Elternabschnitte als Kontext mitgegeben. Das verbindet präzise Treffer mit genug Lesekontext.
Überlappung verhindert harte Schnittkanten. Eine gut gewählte Überlappung erhält Kontext und begrenzt Duplikate im Ranking.
Ein gutes RAG-System verbindet ähnliche Treffer mit Steuerung: erlaubte Quellen, passende Trefferzahl und Relevanzsortierung bestimmen gemeinsam, welcher Kontext zur Frage passt.
Quelle, Dokumenttyp, Datum, Sprache, Version oder Berechtigung grenzen Treffer ein, bevor sie dem LLM gegeben werden.
Die Anzahl der Treffer ist eine Qualitätsentscheidung: Sie balanciert Kontextbreite und Präzision.
Ein zweites Modell sortiert die ersten Vektortreffer nach Frage-Relevanz neu. Das hilft besonders bei ähnlichen, aber fachlich falschen Chunks.
Ein kleines Beispiel zeigt, wo Qualität entsteht: bei Quelle, Chunk, Metadaten, Trefferliste und Kontextauswahl.
Release-Notes beschreiben, dass die Reporting API ab Version 4.2 andere Authentifizierung braucht.
Ein Abschnitt enthält die Änderung, ein anderer die Migrationsschritte, ein dritter bekannte Fehlerbilder.
Jeder Abschnitt bekommt einen Vektor und Metadaten wie Produkt, Version, Datum und Quelle.
Die Frage nach Authentifizierungsfehlern findet mehrere ähnliche Abschnitte aus Release-Notes und Supportartikeln.
Filter und Reranking wählen die aktuelle Version, die Migrationsschritte und den passenden Fehlerartikel aus.
Evaluation
Ohne Messung bleibt RAG ein Bauchgefühl. Eine kleine Testmenge mit echten Fragen und erwarteten Quellen reicht oft, um Chunking, Filter, Top-k und Reranking gezielt zu verbessern.
Ist der richtige Kontext unter den ersten k Treffern vorhanden?
Wie viele der gelieferten Treffer helfen tatsächlich bei der Antwort?
Wie weit oben steht der erste wirklich relevante Treffer?
Eine kleine Sammlung echter Fragen mit erwarteten Quellen macht Retrieval-Qualität sichtbar.
Viele RAG-Probleme entstehen bereits im bereitgestellten Kontext. Das Modell antwortet auf die Textstellen, die es bekommen hat. Wenn der Kontext falsch, alt oder zu breit ist, wird auch die Antwort instabil.
Ein Treffer nutzt dieselben Begriffe, bezieht sich aber auf eine andere Produktversion oder einen anderen Prozess.
Der Chunk enthält den Anfang der Erklärung, aber die entscheidende Ausnahme steht im nächsten Absatz.
Der Vektorindex findet ein altes Dokument, weil es semantisch gut passt, obwohl eine neuere Version gilt.
Viele mittelmäßig relevante Chunks verdrängen den einen wirklich wichtigen Abschnitt im Prompt.
RAG wird greifbarer, wenn man es als Antwortmuster für dokumentennahe Fragen betrachtet: Nutzer können natürlich fragen, und der passende Kontext muss auffindbar sein.
RAG findet passende Abschnitte auch dann, wenn die Frage anders formuliert ist als die Überschrift im Dokument.
Die semantische Suche kann ähnliche Beschreibungen, Workarounds und Troubleshooting-Schritte zusammenbringen.
Mehrere relevante Chunks können als Kontext dienen, wenn Reranking und Quellenbegrenzung sauber eingestellt sind.
RAG ist ein guter Startpunkt für dokumentennahe Fragen. Die Entscheidung hängt daran, wie viel zusätzliche Struktur der Antwortkontext braucht.
Praxisentscheidung
In einem Projekt entsteht Antwortqualität aus dem Zusammenspiel von LLM, Dokumentaufbereitung, sinnvollen Chunkgrößen, robusten Metadaten, Reranking und einer kleinen Sammlung echter Testfragen. Wenn mehrere Retrieval-Signale kombiniert werden müssen, ist der nächste naheliegende Schritt.
Nächste Schritte