Chunking ist Architektur
Zu kleine Chunks verlieren Zusammenhang, zu große Chunks verwässern den Treffer. Der erste Qualitätshebel ist die Zerlegung.
Architektur-Detail · Retrieval
Die kleinste produktionsfähige RAG-Architektur: Ingestion, Chunking, Embeddings, Vector Store, Retriever, Prompt Builder, LLM Gateway und Evaluation. Der Architekturwert liegt in sauberen Grenzen: Was wird offline indexiert, was passiert zur Laufzeit, welche Metadaten steuern Retrieval und wie wird Qualität gemessen?
Kuratierte Architekturentscheidung auf Basis der lokalen Compass-Daten
Relevant wenn
Wenn Fragen durch wenige Textstellen beantwortbar sind und du zuerst eine messbare Baseline für Chunking, Retrieval, Quellenqualität und Antwortverhalten brauchst.
Quellenlage
Reales Standardmuster aus RAG-Frameworks. Der Compass-Name bündelt typische RAG-Bausteine wie Dokumentladen, Textzerlegung, Umwandlung in Suchvektoren, Vektordatenbank, Abruf und Antwortgenerierung.
Ein Team braucht eine belastbare Retrieval-Baseline für unstrukturierte Dokumente, bevor Graphsignale, Ontologien oder Agentenlogik hinzukommen.
Systemkarte
Die Motion Map verdichtet das Muster auf seine wichtigsten Stationen: Eingabe, Daten- oder Graphschicht, Retrieval, Kontrolle und Antwort. Sie ist bewusst kleiner als die Referenzarchitektur darunter und soll zuerst die Leserichtung und die Systemgrenzen sichtbar machen.
Architekturblick
Diese Seite ist eine Entscheidungshilfe für den Stack. Der Blick liegt auf Datenfluss, Failure Modes, Evaluation, Tooling und dem nächsten sinnvollen Migrationsschritt.
Quellen werden extrahiert, in Chunks zerlegt, eingebettet und mit Metadaten im Vector Store gespeichert. Zur Laufzeit wird die Frage eingebettet, Top-k wird geladen, optional gefiltert oder rerankt und als begrenztes Kontextpaket an das LLM übergeben.
Erst Baseline stabilisieren, dann Keyword-Suche, Filter und Reranking ergänzen. GraphRAG erst prüfen, wenn echte Testfragen zeigen, dass Beziehungen oder Mehrsprung-Kontext fehlen.
Referenzarchitektur
Klassisches RAG baut keinen Knowledge Graph und trainiert das LLM nicht neu. Die Architektur macht Dokumente suchbar: Sie findet semantisch passende Textstellen und gibt sie als Kontext an das Modell. Der gesamte Nutzen steht und fällt deshalb mit Dokumentaufbereitung, Chunking, Retrieval und Evaluation.
01
PDFs, Webseiten, Markdown, Tickets oder Wissensartikel werden extrahiert, bereinigt und mit Metadaten versehen.
02
Die Texte werden in suchbare Abschnitte zerlegt. Größe, Überlappung und Abschnittsgrenzen entscheiden stark über die spätere Trefferqualität.
03
Jeder Chunk wird in einen Vektor umgewandelt. Der Vektor repräsentiert semantische Nähe, nicht fachliche Wahrheit.
04
Vektoren, Chunk-Text und Metadaten werden in pgvector, Pinecone, Weaviate, Qdrant, Milvus oder einem ähnlichen Store gespeichert.
05
Eine Nutzerfrage wird ebenfalls eingebettet. Die ähnlichsten Chunks werden gesucht, optional gefiltert und als Kontext zusammengestellt.
06
Das LLM formuliert die Antwort aus Frage, Kontext und Prompt. Idealerweise werden Quellen und Grenzen sichtbar gemacht.
Implementierungs-, Integrations- und Betriebsaufwand.
Qualität, Struktur und Zugänglichkeit der Daten vor dem Pilot.
Erfahrung mit RAG, Graphdenken, Infrastruktur und Evaluation.
Mehrsprung-Fragen, explizite Entitätsbeziehungen, robuste Auditpfade oder fachliche Regeln den Kontext bestimmen.
Sehr schnell zu bauen, aber betrieblich empfindlich: Chunking, Metadaten, Embedding-Modell, Top-k, Reranking und Prompt-Budget entscheiden über Qualität. Es gibt keine explizite Beziehungsmodellierung; Mehrsprung-Fragen und implizite Abhängigkeiten bleiben systematische Schwächen.
Qualitätshebel
Bei klassischem RAG ist schlechte Antwortqualität meistens kein einzelnes Modellproblem. Häufig fehlen passende Chunk-Grenzen, Metadaten, Testfragen oder eine klare Trennung zwischen Retrieval- und Antwortqualität.
Zu kleine Chunks verlieren Zusammenhang, zu große Chunks verwässern den Treffer. Der erste Qualitätshebel ist die Zerlegung.
Quelle, Datum, Dokumenttyp, Sprache, Abteilung oder Version können verhindern, dass semantisch ähnliche, aber fachlich falsche Treffer in den Kontext rutschen.
Eine kleine Testmenge mit erwarteten Quellen ist wertvoller als Bauchgefühl. Miss, ob die richtigen Chunks gefunden werden, bevor du Antworten bewertest.
Wenn Top-k zu breit ist, kann ein Reranker die ersten Treffer gegen die konkrete Frage neu sortieren, bevor das LLM antwortet.
Ausbaustufen
Klassisches RAG ist selten das Ende der Reise, aber ein guter Startpunkt. Es zeigt, welche Fragen mit Dokumentähnlichkeit lösbar sind und wo zusätzliche Signale nötig werden.
Stufe 1
Starte mit wenigen Quellen, sauberem Chunking, Metadatenfiltern und einer kleinen Evaluation.
Stufe 2
Ergänze Keyword-Suche, Filter, Reranking oder strukturierte Signale, wenn reine Ähnlichkeit zu unscharf ist.
Stufe 3
Ergänze Entitäten, Beziehungen und Pfade, wenn Fragen mehrere Dokumente, Abhängigkeiten oder fachliche Relationen verbinden.
Stufe 4
Ergänze Regeln, Rollen, Begriffe und erlaubte Aktionen, wenn Antworten an Fachlogik oder Governance gebunden werden müssen.
In welchem Kontext das Muster typischerweise Sinn ergibt und welchen Beitrag es dort leistet.
Mitarbeitende fragen natürlich nach Inhalten aus Handbüchern, Wikis und PDFs.
Ein Vektorindex findet passende Abschnitte, das LLM formuliert daraus eine quellennahe Antwort.
Tickets und Help-Center-Artikel enthalten ähnliche Fehlerbilder mit unterschiedlichen Formulierungen.
Semantische Suche findet relevante Lösungen auch ohne exakte Keywords.
Eine Mitarbeiterin fragt: Wie viele Tage Sonderurlaub gibt es bei einem Umzug? Die Antwort steht in einem PDF-Abschnitt des HR-Handbuchs.
Klassisches RAG reicht, weil die Frage durch wenige ähnliche Textstellen beantwortet werden kann und keine Beziehungen über mehrere Systeme nötig sind.
Ingestion- und Chunking-Pipeline festlegen
Goldene Fragen mit erwarteten Quellen sammeln
Recall@k und Quellenqualität messen