Wenn Sie ein einfaches RAG-System implementiert haben, kennen Sie das Muster: Dokumente in Chunks aufteilen, embedden, in einer Vektor-Datenbank speichern, bei einer Abfrage die Top-k Ergebnisse abrufen und in den Prompt einfügen. Das funktioniert für Demos. In der Produktion enttäuscht es oft.
Der Abstand zwischen Demo-RAG und Produktions-RAG ist groß. Echte Welt-Dokumente sind unordentlich. Echte Welt-Abfragen sind mehrdeutig. Die Qualität variiert stark je nach Abfragetyp. Kosten und Latenz sind reale Einschränkungen. Updates und Versionierung sind wichtig.
Dieser Artikel behandelt, wie ein produktionsreifes RAG-Pipeline aussieht – die sechs Stufen, die Muster in jeder Stufe und die Evaluationsdisziplin, die Systeme unterscheidet, die funktionieren, von denen, die enttäuschen.
Die Pipeline
Ein produktives RAG-System hat sechs logische Stufen:
[Documents]
↓
1. Ingestion (parsing, cleaning, metadata extraction)
↓
2. Chunking (splitting into retrieval units)
↓
3. Embedding (vectors + storage)
↓
[Query]
↓
4. Retrieval (semantic + lexical + filters)
↓
5. Reranking (top-k → top-N)
↓
6. Generation (LLM + context)
↓
[Response]
Jede Stufe hat ihre eigenen Qualitätssorgen. Die Verbesserung einer Stufe verbessert das Gesamtsystem.
Wir werden jede Stufe durchgehen.
Stufe 1: Ingestion
Garbage in, garbage out. Die Qualität Ihrer Ingestion bestimmt den Deckel für alles, was danach kommt.
Quellentypen, denen Sie begegnen werden:
- PDFs (meistens die schlechtesten).
- Word-Dokumente.
- HTML-Seiten.
- Markdown.
- Tabellenkalkulationen.
- Präsentationen (PowerPoint, Google Slides).
- E-Mails.
- Code.
- Strukturierte Daten (CSVs, JSON).
Jeder hat seine eigenen Parsing-Probleme.
PDF-Parsing. PDFs sind ein Präsentationsformat, kein Datenformat. Sie sind berüchtigt für ihr Parsing. Strategien:
- Textbasierte PDFs:
pdfplumber,pymupdf,unstructured. Funktionieren für sauberen Text. - Gescannte PDFs: OCR mit Tesseract, Google Cloud Vision oder AWS Textract.
- Layout-bewusst:
LayoutLM, Mathpix oder LLM-basiertes Parsing (GPT-4 vision) für komplexe Layouts (Tabellen, mehrspaltig).
Moderne Herangehensweise bei schwierigen PDFs: Nutzen Sie ein visionfähiges LLM, um OCR und den Inhalt zu strukturieren. Die Kosten sind höher, aber die Qualität ist deutlich besser als bei traditionellem OCR.
Umgang mit Tabellen. Tabellen in unstrukturiertem Text sind ein Problem. Entweder:
- Konvertieren Sie sie in Markdown-Tabellen (erhält Struktur).
- Linearisieren Sie sie in Prosa (“Zeile 1: Kunde A hatte 50 Bestellungen…”).
- Behandeln Sie sie als separate abrufbare Einheiten mit einem strukturierten Schema.
Die richtige Wahl hängt davon ab, welche Abfragen Sie erhalten.
Metadatenextraktion. Jedes Dokument hat Metadaten, die wichtig sind:
- Titel, Autor, Datum, Version.
- Thema, Kategorie, Tags.
- Quell-URL oder -ort.
- Berechtigungen / Sichtbarkeit.
Fangen Sie dies bei der Ingestion ein. Es wird bei der Retrieval-Zeit zu Filterparametern.
Reinigung. Entfernen Sie Boilerplate:
- Wiederkehrende Header/Fußzeilen auf jeder Seite.
- Navigation, Werbung, Cookie-Banner.
- “Inhaltsverzeichnis”-Seiten.
- Leere oder doppelte Absätze.
Ein sauberer Korpus ermöglicht besseres Retrieval. Boilerplate verursacht falsche Übereinstimmungen.
Qualitätschecks.
- Hat der Parser tatsächlich Text extrahiert? (Einige PDFs geben leere Strings zurück.)
- Gibt es Kodierungsprobleme?
- Werden Tabellen beibehalten?
- Werden Abbildungen beschrieben oder übersprungen?
Integrieren Sie Plausibilitätsprüfungen in die Ingestion-Pipeline und erkennen Sie Parsing-Fehler, bevor sie den Index verunreinigen.
Stufe 2: Chunking
Sie haben saubere Dokumente. Jetzt teilen Sie sie in Retrieval-Einheiten (Chunks).
Der grundlegende Kompromiss:
- Kleine Chunks: präzises Retrieval (fokussiert auf die Frage), aber fehlender Kontext.
- Große Chunks: mehr Kontext, aber weniger präzise (der relevante Teil ist verborgen).
Beide Extremwerte verlieren Qualität. Der Sweet Spot variiert je nach Inhaltstyp.
Gängige Strategien:
Festgrößen-Chunks mit Überlappung. Teilen Sie in N-Token-Chunks (300-800 Token) mit 50-100 Token Überlappung. Einfach, funktioniert als Baseline.
Satzbewusstes Chunking. Teilen Sie an Satzgrenzen (mit nltk, spaCy oder ähnlichen). Vermeidet Halbsatz-Splits.
Absatzbasiert. Jeder Absatz ist ein Chunk. Funktioniert für Dokumente mit gut strukturierten Absätzen.
Hierarchisch (klein + groß). Zwei Indizes:
- Kleine Chunks (300 Token) für präzises Retrieval.
- Große Chunks (1500 Token) oder volle Abschnitte für Kontext. Bei Retrieval: kleine Chunks abrufen; große Elternchunks dem LLM übergeben.
Dokumentstruktur-bewusst. Nutzen Sie die Dokumentstruktur (Überschriften, Abschnitte), um Chunks zu informieren. Jeder Abschnitt wird ein Chunk, mit Hierarchie beibehalten.
Semantisches Chunking. Nutzen Sie Embeddings, um natürliche Bruchstellen (Orte, an denen das Thema wechselt) zu finden. Teurer, aber für einige Inhalte besser.
LLM-basierte Zusammenfassung Chunking. Lange Dokumente werden in hierarchische Chunks auf mehreren Ebenen (Absatzzusammenfassung, Abschnittszusammenfassung, Dokumentzusammenfassung) zusammengefasst. LLM generiert diese einmal bei der Ingestion.
Die richtige Strategie hängt vom Inhalt ab. Artikel und Wikis: Absatz- oder hierarchisch. Code: Funktionsebene. Gespräche: Gesprächsweise. Technische Dokumente: struktur-bewusst.
Chunk-Metadaten. Jeder Chunk sollte folgende Daten tragen:
- Quelldokument-ID und URL.
- Abschnittspfad (Kapitel > Abschnitt > Unterabschnitt).
- Seitenzahl (für Zitierung).
- Überschriften über diesem Chunk (für Kontext).
- Dokumentebene-Metadaten (Datum, Autor, Typ).
Diese Metadaten ermöglichen Filterung und Zitierung in der Endantwort.
Stufe 3: Embedding
Konvertieren Sie Chunks in Vektoren.
Embedding-Modellwahl.
Im Jahr 2026:
- OpenAI text-embedding-3-large: starker Allrounder, teuer.
- Voyage Voyage-3: wettbewerbsfähig, oft besser bei technischem Inhalt.
- Cohere embed-v4: starker multilingueller.
- BAAI bge-large: starker Open-Source.
- Nomic embed-text: guter Open-Source, kostenlos für Selbsthostung.
- Domain-spezifische Modelle: für Code (Voyage Code, OpenAI text-embedding-3-large funktioniert auch für Code), Recht, Medizin usw.
Modellwahl: Testen Sie gegen Ihr Domain. Nehmen Sie nicht an, dass der Leaderboard-Sieger am besten für Ihre Daten ist.
Embedding-Dimension. Modelle bieten 256-3072 Dimensionen an. Höhere Dimensionen = bessere Qualität, höhere Kosten/Speicher. Für die meisten Anwendungsfälle ist 768-1536 der Sweet Spot.
Versionierung. Embedding-Modelle werden aktualisiert; Sie möchten möglicherweise wechseln. Planen Sie dies:
- Verfolgen Sie, welche Embedding-Modellversion jeden Vektor erzeugt hat.
- Re-embeden Sie alles bei Migration (oder nutzen Sie eine Dual-Index-Übergang).
- Mischen Sie keine Vektoren aus verschiedenen Modellen in derselben Suche.
Kosten. Das Embedding von Millionen von Chunks kostet Geld. €0,10–€0,50 pro Million Token (variiert je nach Anbieter). Für große Corpora rechnen Sie vorab.
Speicher. Vektoren sind groß. 1M Chunks × 1536 Dimensionen × 4 Bytes = 6 GB. Planen Sie den Speicher entsprechend.
Stufe 4: Retrieval
Die Abfrage kommt. Sie müssen relevante Chunks finden.
Vektor-Suche (dichter Retrieval). Embedden Sie die Abfrage, finden Sie die nächsten Nachbarn. Erfasst semantische Ähnlichkeit. Standard.
Schlüsselwort-Suche (BM25 / lexikalisch). Traditionelle Textsuche. Erfasst exakte Übereinstimmungen, seltene Begriffe, spezifische Namen. Ergänzt oft die Vektor-Suche.
Hybride Suche. Führen Sie beide durch, fusionieren Sie die Ergebnisse. Reciprocal Rank Fusion (RRF) ist der Standard-Fusionsansatz.
def reciprocal_rank_fusion(rankings, k=60):
scores = {}
for ranking in rankings:
for rank, doc_id in enumerate(ranking):
scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
return sorted(scores.items(), key=lambda x: -x[1])
In der Praxis schlägt hybride Suche Vektor-nur oder Schlüsselwort-nur auf den meisten Benchmarks. Nutzen Sie sie standardmäßig.
Metadaten-Filterung. Filtern Sie Retrieval durch Metadaten vor dem Scoring. “Nur Dokumente aus 2025+”. “Nur Dokumente im zugänglichen Satz des Benutzers.” “Nur Dokumente vom Typ Richtlinie.”
Kritisch für Multi-Tenant-Systeme: Jede Abfrage muss auf die Dokumente beschränkt sein, auf die der jeweilige Mandant Zugriff hat.
Abfrageverstehen. Vorverarbeiten Sie die Abfrage:
- Rechtschreibkorrektur. “engineerin” → “engineering.”
- Akronym-Ausweitung. “MFA” → “Multi-Faktor-Authentifizierung MFA.”
- Synonyme / Abfrageerweiterung. Generieren Sie alternative Formulierungen; suchen Sie mit jeder.
- Zerlegung. Mehrteilige Fragen werden in Unterabfragen zerlegt, jede wird separat abgerufen.
Diese Vorverarbeitungsschritte verbessern die Retrieval-Qualität erheblich bei echten Welt-Abfragen.
HyDE (Hypothetical Document Embeddings). Generieren Sie einen fiktiven “ideal Antwort” mit einem LLM. Embedden Sie dies. Nutzen Sie das Ergebnis als Retrieval-Abfrage. Funktioniert oft besser als die direkte Embedding der Frage, da die fiktive Antwort ähnlicher zu echten Antwortdokumenten ist.
def hyde_retrieve(query, k=20):
hypothetical = llm("Write a passage answering: " + query)
embedding = embed(hypothetical)
return vector_search(embedding, k=k)
Kompromiss: Zusätzlicher LLM-Aufruf pro Abfrage (Latenz, Kosten). Würdig für schwierige Abfragen; übertrieben für einfache.
Multi-Vektor-Retrieval. Anstelle eines Vektors pro Chunk, mehrere (z. B. einen für den Chunk, einen für eine Zusammenfassung, einen für hypothetische Fragen). Fügt Speicher und Komplexität hinzu, verbessert aber Retrieval für einige Inhalte.
Stufe 5: Reranking
Nach der initialen Retrieval (Top-k, k=20-50), nutzen Sie einen Reranker, um die Kandidaten sorgfältiger zu bewerten.
Warum Reranking?
Die initial Retrieval ist schnell, aber ungenau. Vektorähnlichkeit ist ein grober Proxy für Relevanz. Ein Reranker (typischerweise ein Cross-Encoder-Modell) liest die Abfrage und jeden Kandidaten, produziert ein präziseres Score.
Reranker-Optionen:
- Cohere Rerank. Branchenstandard. Gute Qualität, gehostet.
- Voyage Rerank. Starker Wettbewerber.
- BGE Rerank-large. Open-Source, kostenlos für Selbsthostung.
- MiniLM Cross-Encoders. Kleiner, schneller, geringere Qualität.
- LLM-basiertes Reranking. Nutzen Sie ein kleines LLM, um Abfrage-Kandidaten-Paare zu bewerten. Höchste Qualität, höchste Kosten.
Der Effekt.
Das Hinzufügen von Reranking verbessert in der Regel die Endaufgabenqualität bei den meisten RAG-Systemen; betrachten Sie den oft zitierten Bereich von 10–20 % als Planungsabschätzung, um gegen Ihre eigenen Evaluierungen zu prüfen. Es ist fast immer wertvoll, die Latenz und Kosten zu akzeptieren.
Typische Konfiguration:
- Retrieval mit hybrider Suche: 30–50 Kandidaten.
- Reranking auf Top 5–10.
- Top-Ergebnisse an LLM übergeben.
Adaptives Reranking.
Für Abfragen, bei denen das erste Ergebnis eine hohe Vektorähnlichkeit hat (klarer Treffer), Reranking überspringen. Für Abfragen mit engen Scores (mehrere Kandidaten sind eng beieinander), Reranking aggressiv durchführen.
Stufe 6: Generation
Das LLM erzeugt die Antwort mithilfe des abgerufenen Kontexts.
Promptstruktur:
You are an assistant answering questions based on the provided context.
Context:
[Document 1 - title, URL]
[chunk 1 content]
[Document 2 - title, URL]
[chunk 2 content]
...
User question: {query}
Instructions:
- Answer based only on the provided context.
- If the context doesn't contain the answer, say so. Don't make up information.
- Cite sources using [Source N] notation.
- Be concise but complete.
Die Prompt-Muster, die wichtig sind:
- Quellentagging. Jeder Kontext-Chunk wird mit seiner Quelle für Zitierung getaggt.
- Grundungsanweisungen. Sagen Sie dem Modell explizit, nur den Kontext zu verwenden.
- Zitierpflicht. Zitierung erzwingen. Erkennt Halluzinationen.
- Fallback-Anweisung. “Wenn der Kontext keine Antwort hat, sagen Sie das.” Verhindert Erfindungen.
Zitierverarbeitung.
Ein gängiges Muster: Fügen Sie Quellverknüpfungen in die Antwort ein. Die UI rendert sie als klickbar.
"The company's remote work policy allows up to 4 days/week from home [1].
[1]: https://wiki.company.com/policies/remote-work"
Das macht die Antwort überprüfbar. Nutzer vertrauen mehr auf grundierte Antworten.
Kontextgrößenmanagement.
Lange Kontexte verschlechtern sich. Die meisten Modelle arbeiten am besten mit fokussierten Kontexten (5–10 hochrelevanten Chunks) anstatt alles zu laden. Qualität sinkt mit Kontextschwellen.
Wenn Sie viele Kontexte einbeziehen müssen, summieren Sie weniger relevante Elemente anstelle, sie vollständig einzubeziehen.
Eval bei jeder Stufe
Sie können nichts optimieren, was Sie nicht messen. Jede Stufe benötigt ihre eigenen Evaluierungen.
Ingestion-Eval. Wurden die Dokumente korrekt geparst? Probieren Sie Dokumente aus; prüfen Sie, ob Schlüsselinhalte erhalten bleiben.
Chunking-Eval. Sind die Chunks in der richtigen Größe? Erhalten sie den Kontext? Brechen sie an sinnvollen Grenzen?
Embedding-Eval. Werden ähnliche Konzepte ähnlich eingebettet? Auf einer Testmenge bekannter ähnlicher und bekannter unterschiedlicher Paare, stimmt die Kosinusähnlichkeit mit Erwartungen überein?
Retrieval-Eval. Bei einer Abfrage, sind die relevanten Chunks in den Top-K? Gängiges Maß: Recall@K (was % der Abfragen haben mindestens einen relevanten Chunk in Top K).
Reranking-Eval. Bei abgerufenen Kandidaten, stellt der Reranker den relevantesten zuerst? Maß: NDCG (normalized discounted cumulative gain) oder MRR (mean reciprocal rank).
Generation-Eval. Bei Kontext und Abfrage, erzeugt das LLM eine korrekte Antwort? Maße: Faithfulness (nutzt die Antwort den Kontext?), Richtigkeit (ist die Antwort richtig?), Hilfreichkeit (beantwortet sie den Nutzerintent?).
End-to-End-Eval. Bei einer echten Abfrage, erzeugt das System die richtige Antwort? Wichtigste; hängt von allen Stufen ab.
Sie benötigen Testmengen für jede. Ein gängiges Bootstrap:
- Erstellen Sie 50–100 Abfragen mit bekannten guten Antworten.
- Für jede Abfrage, identifizieren Sie, welche Dokument(e) die Antwort enthalten.
- Nutzen Sie dies, um Retrieval (abrufen wir die richtigen Dokumente?) und Generation (ist die Antwort richtig?) zu evaluieren.
Tools: Ragas, TruLens, benutzerdefinierte Suiten. Das genaue Tool spielt weniger eine Rolle als das Durchführen der Evaluierungen.
Betriebsbedingungen
Einige produktionsreale Realitäten:
Indexierungspipelines. Neue Dokumente kommen hinzu, werden eingebettet und in den Indizes ergänzt; Löschungen und Aktualisierungen müssen ebenfalls verarbeitet werden. Diese Pipeline läuft kontinuierlich, nicht nur bei der Einrichtung. Bauen Sie sie als System und nicht als einmaliges Skript.
Latenz.
Typische Aufteilung:
- Embedding (Abfrage): 50–200 ms.
- Vektor-Suche: 50–200 ms.
- Reranking: 200–500 ms (je nach K).
- Generation: 1–5 s (je nach Kontext und Modell).
- Gesamt: 1,5–6 s.
Optimierung:
- Cache Embedding von häufigen Abfragen.
- Cache Reranking für wiederholte Abfrage-Kandidaten-Paare.
- Streamen Sie Generation.
- Wo möglich parallelisieren.
Für Latenz unter 2 s benötigen Sie in der Regel ein schnelles Embedding-Modell, ein schnelles Vektor-Datenbank und entweder ein schnelles Reranking oder Reranking für gekachte/einfache Abfragen überspringen.
Kosten.
Pro-Abfrage-Kosten:
- Embedding: ~€0,0001.
- Vektor-Suche: ~€0,0001 (infrastrukturabhängig).
- Reranking: €0,001–0,01 (modellabhängig).
- Generation: €0,005–0,05 (modell + kontextabhängig).
- Gesamt: ~€0,01–0,05 pro Abfrage.
Bei großem Volumen summieren sich die Kosten. Eine Million Abfragen kosten €10K–50K.
Kostenoptimierung:
- Caching.
- Nutzen Sie günstigere Modelle, wo Qualität erlaubt.
- Komprimieren Sie den Kontext (Zusammenfassungen vs. volle Chunks).
Updates. Dokumente ändern sich. Muster:
- Versionierung: Jedes Dokument hat eine Version; alte Versionen werden je nach Richtlinie beibehalten oder gelöscht.
- Inkrementell: Neue Versionen werden neu in Chunks und neu embedded; alte Chunks gelöscht.
- Diff-bewusst: Nur geänderte Abschnitte werden erneut verarbeitet.
Für Szenarien mit vielen Updates ist dies von Bedeutung.
Berechtigungen. Bei RAG über private Daten besitzen Dokumente Zugriffskontrollen, die das Retrieval zwingend durchsetzen muss.
- Metadatenbasierte Filterung (jeder Chunk hat accessible-by-Metadaten).
- Mandantenisolierte Indizes für eine strikte Trennung.
- Audit-Logs darüber, wer auf welche Daten zugegriffen hat.
Vertrauen Sie niemals dem LLM die Durchsetzung von Berechtigungen an. Erzwingen Sie sie in der Retrieval-Schicht.
Gängige Fehlmodi
Einige Muster, die wir in fehlenden RAG-Systemen beobachten:
Fehler 1: Schlechtes Chunking. Chunks werden in der Mitte eines Gedankens geteilt, Tabellen über mehrere Chunks verteilt, Überschriften von ihrem Inhalt getrennt. Lösung: bessere Chunking-Strategie.
Fehler 2: Retrieval fehlt die Antwort. Der relevante Chunk existiert, aber wird nicht abgerufen. Oft ein Abfrage/Dokument-Mismatch. Lösung: HyDE, Abfrageerweiterung, bessere Embeddings.
Fehler 3: Richtige Chunks, falsche Reihenfolge. Relevanter Chunk wird abgerufen, aber niedrig gerankt. LLM nutzt höher gerankte irrelevante Chunks. Lösung: Reranking.
Fehler 4: Richtige Chunks, Halluzination. Chunks sind richtig, aber LLM erfindet zusätzliche Informationen. Lösung: strengere Grundungsanweisung, Zitierpflicht, niedriger Temperatur.
Fehler 5: Richtige Chunks, falsche Antwort. Chunks enthalten die Antwort, aber LLM extrahiert den falschen Teil. Lösung: bessere Generationsanweisung, möglicherweise größeres Modell.
Fehler 6: Veraltete Daten. Index wurde nicht aktualisiert. Lösung: kontinuierliche Ingestion-Pipeline.
Fehler 7: Berechtigungslecks. Nutzer sehen Chunks, auf die sie keinen Zugriff haben. Lösung: Filterung beim Retrieval erzwingen und Zugriffe auditieren.
Fehler 8: Kostenexplosion. Latenz und Kosten wuchsen mit Wachstum von Corpus und Traffic. Lösung: Caching, Modellrouting, mögliche Architekturänderungen.
Ein vollständiges Beispiel: RAG für eine Unternehmenswissensbasis
Als konkretes Beispiel dient ein typisches RAG-System für eine Unternehmenswissensbasis.
Korpus: ~50.000 Dokumente (Wiki-Seiten, Richtlinien, Runbooks, Meeting-Notizen, Slack-Threads).
Pipeline:
-
Ingestion:
- Notion: API-Export.
- Slack: Archiv-Export, gefiltert auf relevante Kanäle.
- Google Drive: API-Export von genehmigten Ordnern.
- Reinigung: Emojis-nur-Nachrichten, Boilerplate-Signaturen entfernen.
-
Chunking:
- Hierarchisch: Absatzebene kleine Chunks, Abschnittsebene Elternchunks.
- ~250K Chunks auf kleiner Ebene.
- Metadaten: Quelle, Abschnittspfad, letzte_Aktualisierung, zugänglich_für.
-
Embedding:
- Voyage-3 Embeddings, 1024 Dimensionen.
- In Pinecone (managed) gespeichert.
- Wöchentlich re-embedded für geänderte Dokumente.
-
Retrieval:
- Hybrid: Vektor-Suche + BM25 (via Pinecone’s hybrid).
- HyDE für die Abfrage.
- Metadatenfilter für Zugänglichkeit.
- Top 30 abgerufen.
-
Reranking:
- Cohere Rerank.
- Top 30 → Top 8.
-
Generation:
- Claude Sonnet 5.
- Top 8 Elternchunks (nicht kleine Chunks) als Kontext bereitgestellt.
- Zitierung in der Antwort erforderlich.
Eval:
- 100 handgefertigte Abfrage/Antwort-Paare.
- Retrieval Recall@30: ~92 %.
- End-Antwort-Richtigkeit: ~85 %.
- Faithfulness (keine Halluzination): ~95 %.
Betrieb:
- Tägliche inkrementelle Ingestion.
- Wöchentliche vollständige Re-embedding für geänderte Dokumente.
- Observability je Abfrage.
- Monatliche Eval-Wiederholung; Trendüberwachung.
- Quartalsweise Abfragesprotokollprüfung, um neue Fehlmodi zu erkennen.
Kosten:
- Embedding: ~€500/Monat (Steady-State).
- Vektor-Datenbank-Hosting: ~€800/Monat (Pinecone).
- Retrieval + Generation pro Abfrage: ~€0,02.
- Gesamt: ~€2.500/Monat + €0,02 × Abfragemenge.
Für die meisten Unternehmen ist dies durch die Produktivitätsgewinne voll gerechtfertigt.
Ein 90-Tage-Plan für den RAG-Ausbau
Wenn Sie von Null beginnen:
Tage 1–30: MVP.
- Identifizieren Sie den Korpus und die primäre Anwendung.
- Bauen Sie eine grundlegende Ingestion (eine Quelle).
- Grundlegendes Chunking (Festgröße mit Überlappung).
- Standard-Embedding-Modell.
- Nur Vektor-Suche (kein Rerank).
- Einfache Generationsanweisung.
Tage 31–60: Qualität.
- Handgefertigte Eval-Menge erstellen (50–100 Abfragen).
- Identifizieren Sie Fehlmodi.
- Fügen Sie Reranking hinzu.
- Fügen Sie hybride Suche hinzu.
- Verbessern Sie Chunking.
Tage 61–90: Betrieb.
- Kontinuierliche Ingestion-Pipeline.
- Observability.
- Eval-Automatisierung.
- Berechtigung/Authentifizierung.
- Kostenüberwachung.
Nach 90 Tagen haben Sie ein System, das nicht nur demonstriert werden kann, sondern tatsächlich genutzt werden kann. Echte Nutzer können sich darauf verlassen.
Qualität lebt in jeder Stufe
Produktiver RAG ist ein sechsstufiger Pipeline mit Qualitätssorgen in jeder Stufe. Die Muster, die Systeme unterscheiden, die funktionieren, von denen, die enttäuschen:
- Ingestion: gründliches Parsing, Strukturbeibehaltung, Metadatenextraktion.
- Chunking: passende Strategie für Inhaltstyp, oft hierarchisch.
- Embedding: Qualität Modell, Versionierung, Planung für Migration.
- Retrieval: Hybrid standardmäßig, Abfrageverstehen, Metadatenfilterung.
- Reranking: fast immer wertvoll.
- Generation: Grundung, Zitierung, Fallback für Unbekannte.
- Eval: in jeder Stufe, kontinuierlich.
Keine dieser Aspekte ist optional. Der Abstand zwischen RAG mit 60 % Antwortqualität und RAG mit 90 % lebt in diesen Details.
Die Investition ist real – ein produktiver RAG-Ausbau ist Monate, nicht Wochen. Die Auszahlung ist ein System, das Ihre Nutzer tatsächlich vertrauen können. Das ist der Schwellenwert, der zählt.
