Die Demo funktioniert immer. Sie betten ein paar Dutzend Dokumente ein, stellen eine Frage, und das Modell beantwortet sie sofort korrekt, mit einer sauberen Quellenangabe. Sie zeigen es Ihrem Team. Alle sind beeindruckt. Dann richten Sie es auf den echten Dokumentensatz, ein paar Tausend Seiten statt ein paar Dutzend, und setzen es echten Nutzern vor, und plötzlich zerfällt alles. Antworten werden vage. Die Latenz schleicht über drei Sekunden. Das Modell verweist mit voller Überzeugung auf den falschen Abschnitt. Jemand stellt eine Frage mit einem exakten Produktcode darin, und das System liefert fünf Chunks zurück, die zwar thematisch verwandt, aber völlig nutzlos sind.
Die meisten Entwickler behandeln RAG wie einen einzelnen Haken auf einer Checkliste: „Haben wir eine Vektordatenbank hinzugefügt?“ Das ist der Fehler. Eine Vektordatenbank ist eine Komponente in einer Pipeline, nicht die Pipeline selbst. Die Lücke zwischen einer funktionierenden Demo und einem Produktionssystem ist kein klügeres Modell und kein besserer Prompt, sondern fast immer die darunterliegende Retrieval-Schicht, und ganz konkret drei Dinge, die die meisten Tutorials auslassen: wie Sie Ihre Dokumente chunkieren, wie Sie darin suchen und wie Sie vermeiden, dieselbe teure Arbeit zweimal zu machen. Beheben Sie diese drei Punkte, und alles, was danach kommt, wird einfacher.
Sie lernen:
- Warum Chunking mit fester Größe die Retrieval-Qualität stillschweigend verschlechtert und was semantisches Chunking behebt
- Warum reine Vektorsuche Exact-Match-Abfragen verpasst und wie Hybrid Retrieval (Vektor + BM25) diese Lücke schließt
- Wie Query-Caching sowohl die Latenz als auch die LLM-Kosten senkt, ohne veraltete Antworten auszuliefern
- Wie man eine einzelne Anfrage durch eine produktionsreife Pipeline von Anfang bis Ende nachverfolgt
- Was zuerst kaputtgeht, wenn Ihr Dokumentensatz und Ihr Traffic tatsächlich skalieren
- Welche Retrieval-Fehler leicht zu machen und teuer zu ignorieren sind
Inhaltsverzeichnis
- Die Grundlagen
- Die vollständige Architektur
- Die Kernschichten erklärt
- End-to-End-Durchlauf
- Sonderfälle
- Skalierung & Produktionsherausforderungen
- Codebeispiele
- Häufige Fallstricke
- Best Practices für die Produktion
Die Grundlagen
Was RAG tatsächlich abdeckt
Retrieval-Augmented Generation muss für jede einzelne Anfrage vier Fragen korrekt und in der richtigen Reihenfolge beantworten: Was meint der Nutzer eigentlich? Welche Teile Ihrer Dokumente sind für diese Bedeutung relevant? Wie bekommen Sie nur die nützlichen Teile in ein begrenztes Kontextfenster? Und wie erzeugen Sie eine Antwort, die in dem verankert ist, was Sie abgerufen haben, statt in dem, was das Modell bereits zu „wissen“ glaubt?
Die meisten Menschen, die ihr erstes RAG-Feature bauen, lösen nur die dritte und vierte Frage: Sie verdrahten einen Embedding-Aufruf, eine Vektor-Ähnlichkeitssuche und ein Prompt-Template und gehen davon aus, dass sich die ersten beiden Fragen von selbst erledigen. Tun sie nicht. Query-Verständnis und Retrieval-Qualität sind die eigentlichen schwierigen Probleme. Generierung ist der einfache Teil; ein leistungsfähiges LLM kann aus fast jedem Kontext, den Sie ihm geben, eine schlüssige Antwort schreiben, auch aus schlechtem Kontext. Genau das ist die Falle: schlechtes Retrieval wirft keinen Fehler, es erzeugt einfach eine selbstsichere, flüssige, falsche Antwort.
Warum es ein wertvolles Problem ist, das man richtig lösen muss
Retrieval-Qualität ist kein Nice-to-have, sie ist die Obergrenze für alles andere, was Sie darauf aufbauen:
- Halluzinationen verstärken Vertrauensverlust. Eine falsche Antwort, die richtig klingt, ist schlimmer als gar keine Antwort, besonders bei Support- oder Wissenswerkzeugen, bei denen Menschen nach ein paar guten Erfahrungen aufhören, Dinge doppelt zu prüfen.
- Latenz hat eine harte UX-Untergrenze. Nach ungefähr zwei Sekunden gehen Nutzer davon aus, dass etwas kaputt ist, unabhängig davon, wie gut die endgültige Antwort ist.
- Kosten skalieren mit schlechtem Retrieval, nicht mit gutem Retrieval. Teams, die nicht präzise abrufen können, kompensieren das, indem sie mehr Chunks in das Kontextfenster stopfen, was bei jedem einzelnen Aufruf mehr Input-Tokens bedeutet.
- Fehler sind still. Für „falschen Abschnitt abgerufen“ gibt es keinen Stack Trace. Sie erfahren es erst durch ein Support-Ticket oder einen Screenshot in Slack, was bedeutet, dass Sie Sichtbarkeit bewusst einbauen müssen — sie entsteht nicht zufällig.
Die vollständige Architektur
Documents ─▶ Chunking ─▶ Embedding ─┬─▶ Vector Index
└─▶ BM25 Index
User Query ─▶ Query Processing ─▶ Hybrid Retrieval ─▶ Rerank ─▶ Cache Check
│
┌───────────────┴───────────────┐
cache hit cache miss
│ │
return cached Context Assembly
answer │
▼
LLM Call
│
▼
Cache + Return
Das Leitprinzip unter all dem: Retrieval-Qualität ist eine harte Obergrenze für Generierungsqualität. Kein noch so ausgefeiltes Prompt Engineering rettet eine Antwort, die auf falschem Kontext aufgebaut ist; wenn überhaupt, macht ein besserer Prompt die falsche Antwort nur überzeugender.
Die Kernschichten erklärt
1. Semantisches Chunking
Was es ist: Dokumente entlang natürlicher Bedeutungsgrenzen aufzuteilen — Abschnittsüberschriften, Absatzumbrüche, Themenwechsel, die über Satz-Ähnlichkeit erkannt werden — anstatt stumpf alle N Zeichen oder Tokens abzuschneiden, unabhängig davon, was dort steht.
Warum es wichtig ist: Chunking mit fester Größe ist die mit Abstand häufigste Ursache für stillen Qualitätsverlust in einer RAG-Pipeline. Eine Chunk-Grenze bei 500 Tokens kümmert sich nicht darum, ob sie mitten in einem Satz landet, eine nummerierte Liste von ihrer Einleitung trennt oder einen Vorbehalt von der Regel abspaltet, die er einschränkt. Das Embedding für diesen Chunk repräsentiert dann nur eine halbe Idee, was bedeutet, dass er entweder nicht abgerufen wird, obwohl er sollte, oder ohne den Kontext abgerufen wird, der ihn überhaupt erst korrekt gemacht hat.
def semantic_chunks(sentences, embed_fn, threshold=0.75, max_tokens=400):
chunks, current, current_tokens = [], [], 0
prev_vec = None
for sentence in sentences:
vec = embed_fn(sentence)
sim = cosine_similarity(prev_vec, vec) if prev_vec else 1.0
too_big = current_tokens + count_tokens(sentence) > max_tokens
if (sim < threshold or too_big) and current:
chunks.append(" ".join(current))
current, current_tokens = [], 0
current.append(sentence)
current_tokens += count_tokens(sentence)
prev_vec = vec
if current:
chunks.append(" ".join(current))
return chunks
Produktions-Tipp: Semantische Grenzen allein können immer noch Chunks erzeugen, die zu groß oder zu klein sind. Behalten Sie immer eine harte Token-Obergrenze als Sicherheitsnetz bei und fügen Sie einen kleinen Überlappungsbereich (10–15 %) zwischen benachbarten Chunks hinzu, damit eine Grenze, die einen abhängigen Nebensatz trennt, auf beiden Seiten noch genug Kontext übrig lässt.
2. Hybrid Retrieval (Vektor + BM25)
Was es ist: Zwei Retrieval-Methoden parallel auszuführen — dichte Vektor-Ähnlichkeitssuche für semantische Bedeutung und eine sparsame Keyword-Methode wie BM25 für exakte Term-Treffer — und anschließend die beiden Ranglisten zusammenzuführen.
Warum es wichtig ist: Embeddings sind hervorragend bei „das bedeutet etwas Ähnliches“ und stillschweigend schlecht bei „das enthält exakt diese Zeichenfolge“. Fragen Sie einen Support-Bot nach dem Fehlercode ERR_4402 oder einem bestimmten Funktionsnamen, und eine reine Vektorsuche liefert Ihnen bereitwillig Chunks zurück, die thematisch verwandt sind, aber den wörtlichen Bezeichner nicht enthalten, weil das Embedding ihn zu einem allgemeinen Konzept geglättet hat. BM25 fängt genau die Fälle auf, die die Vektorsuche verpasst, und umgekehrt fängt die Vektorsuche paraphrasierte oder konzeptionelle Anfragen auf, die kein gemeinsames Vokabular mit dem Quelltext haben.
def hybrid_retrieve(query, vector_index, bm25_index, k=10, rrf_k=60):
vec_results = vector_index.search(query, top_k=k)
bm25_results = bm25_index.search(query, top_k=k)
scores = {}
for rank, doc_id in enumerate(r.id for r in vec_results):
scores[doc_id] = scores.get(doc_id, 0) + 1 / (rrf_k + rank)
for rank, doc_id in enumerate(r.id for r in bm25_results):
scores[doc_id] = scores.get(doc_id, 0) + 1 / (rrf_k + rank)
return sorted(scores.items(), key=lambda x: -x[1])[:k]
Das ist Reciprocal Rank Fusion, eine einfache und effektive Methode, zwei Rankings zusammenzuführen, ohne inkompatible Score-Skalen normalisieren zu müssen.
Produktions-Tipp: Gewichten Sie BM25 stärker, wenn die Anfrage Anführungsphrasen, Zahlen oder Bezeichner-ähnliche Tokens enthält (alles, was zu einem Code- oder SKU-Muster passt). Ein schneller Regex-Check vor dem Retrieval reicht aus, um die meisten dieser Fälle zu erfassen.
3. Query-Caching
Was es ist: Sowohl das Embedding für eine Anfrage als auch die endgültig generierte Antwort zu cachen, mit einem Schlüssel auf Basis der Anfrage (oder einer nahezu identischen Variante davon), sodass wiederholte oder sehr ähnliche Fragen die teuren Teile der Pipeline komplett überspringen.
Warum es wichtig ist: In den meisten produktiven RAG-Systemen entfällt ein kleiner Satz von Fragen auf einen unverhältnismäßig großen Anteil des Traffics — immer dieselben paar Anfragen im Stil von „wie setze ich mein Passwort zurück“ oder „wie lautet unsere Rückerstattungsrichtlinie“, nur leicht unterschiedlich von verschiedenen Nutzern formuliert. Für jede dieser Anfragen erneut zu embedden und neu zu generieren ist reine Verschwendung: Es ist dieselbe Latenz und derselbe Token-Preis für eine Antwort, die Sie bereits erzeugt haben.
def get_cached_or_generate(query, redis_client, embed_fn, generate_fn, sim_threshold=0.95):
query_vec = embed_fn(query)
cache_key = f"rag:cache:{hash_vector(query_vec)}"
cached = redis_client.get(cache_key)
if cached and cosine_similarity(query_vec, cached["vec"]) > sim_threshold:
return cached["answer"]
answer = generate_fn(query)
redis_client.setex(cache_key, 3600, {"vec": query_vec, "answer": answer})
return answer
In einer Pipeline, an der ich gearbeitet habe, hat allein das Hinzufügen dieser Schicht die durchschnittliche Query-Latenz während der Spitzenzeiten von ungefähr 3,2 Sekunden auf etwa 1,1 Sekunden gesenkt — einfach deshalb, weil ein großer Anteil wiederholter Anfragen das LLM überhaupt nicht mehr berührte. Ihre Zahlen hängen davon ab, wie repetitiv Ihr Anfrage-Traffic tatsächlich ist, aber das Muster gilt fast überall.
Produktions-Tipp: Cachen Sie niemals ohne TTL und ohne einen Invalidierungspfad, der an Dokument-Updates gekoppelt ist. Ein Cache, der länger lebt als das Dokument, aus dem er aufgebaut wurde, ist der Weg zu einer selbstsicher ausgelieferten Antwort, die letzten Monat korrekt war.
4. Reranking
Was es ist: Ein zweiter, teurerer Scoring-Durchlauf — meist ein Cross-Encoder-Modell — der auf die besten 20–50 Kandidaten aus dem Hybrid Retrieval angewendet wird, bevor die endgültigen Top-k in das Kontextfenster gelangen.
Warum es wichtig ist: Sowohl Vektor- als auch BM25-Suche sind schnelle Näherungen. Sie sind gut darin, „wahrscheinlich relevante“ Kandidaten in eine Shortlist zu bringen, aber nicht präzise genug, um ihnen als endgültigem Ranking zu vertrauen. Ein Cross-Encoder, der sich die Anfrage und jeden Kandidaten tatsächlich gemeinsam ansieht, statt vorberechnete Vektoren zu vergleichen, ist deutlich besser darin, diese Shortlist korrekt zu ordnen — nur ist er zu teuer, um ihn über Ihren gesamten Korpus laufen zu lassen.
Produktions-Tipp: Reranken Sie die Shortlist, niemals den vollständigen Korpus. Einen Cross-Encoder über auch nur ein paar Hundert Kandidaten laufen zu lassen, fügt spürbare Latenz hinzu; über Ihren gesamten Dokumentensatz ist es keine Option.
5. Kontextzusammenstellung & Token-Budgetierung
Was es ist: Die gerankten Chunks gezielt in Ihr Kontextfenster zu packen, überlappende Inhalte zu deduplizieren, nach Relevanz zu sortieren und zu stoppen, sobald Sie ein Token-Budget erreichen, statt jeden abgerufenen Chunk in den Prompt zu kippen.
Warum es wichtig ist: „Mehr Kontext“ ist nicht dasselbe wie „besserer Kontext“. Ab einem bestimmten Punkt verwässern zusätzliche Chunks das Signal, mit dem das Modell arbeiten muss, treiben Latenz und Kosten hoch und erhöhen die Wahrscheinlichkeit, dass sich das Modell an einem irrelevanten Abschnitt festbeißt. Ein hartes Token-Budget zwingt die vorgelagerten Retrieval- und Reranking-Stufen dazu, ihre Arbeit tatsächlich zu machen, statt sich auf Masse als Ausgleich zu verlassen.
End-to-End-Durchlauf
Verfolgen wir eine einzelne Anfrage durch die vollständige Pipeline: „Wie hoch ist das Timeout beim Retry des Payment-Webhooks?“
- Anfrage empfangen. Die API-Schicht nimmt den Rohstring an und normalisiert Whitespace und Groß-/Kleinschreibung.
- Cache-Prüfung. Die Anfrage wird eingebettet und mit gecachten Query-Vektoren oberhalb des Ähnlichkeitsschwellenwerts verglichen. Bei kaltem Cache ist das ein Miss.
- Query-Verarbeitung. Eine leichtgewichtige Prüfung markiert dies als Anfrage mit einem spezifischen technischen Begriff („webhook retry“), was die Hybrid-Gewichtung in Richtung BM25 verschiebt.
- Hybrid Retrieval. Vektorsuche und BM25-Suche liefern jeweils ihre besten Kandidaten zurück; Reciprocal Rank Fusion führt sie zu einer einzigen gerankten Shortlist zusammen.
- Reranking. Der Cross-Encoder bewertet die Shortlist anhand des tatsächlichen Anfrage-Texts und ordnet sie neu. Wenn das Reranking nichts über einem minimalen Relevanz-Score zurückliefert, verzweigt die Pipeline frühzeitig zu einer Fallback-Antwort („Ich konnte dazu nichts Spezifisches finden, versuchen Sie es mit einer Umformulierung“), statt das LLM zur Generierung aus schwachem Kontext zu zwingen.
- Kontextzusammenstellung. Die am höchsten bewerteten Chunks werden dedupliziert, sortiert und bis zum Token-Budget in den Prompt gepackt.
- LLM-Aufruf. Das Modell erzeugt eine Antwort, die im zusammengestellten Kontext verankert ist, mit Anweisungen, den Quell-Chunk zu zitieren.
- Cache-Schreibvorgang. Das Query-Embedding und die generierte Antwort werden mit TTL und einem Versions-Tag, das an den Last-Updated-Zeitstempel des Quelldokuments gebunden ist, in den Cache geschrieben.
- Antwort zurückgegeben. Der Nutzer erhält in ungefähr ein bis zwei Sekunden eine Antwort mit einer Quellenangabe zum konkreten Dokumentabschnitt.
Jeder Schritt in dieser Kette hat einen expliziten Fehlerpfad. Das ist der Unterschied zwischen einer Pipeline, die elegant degradiert, und einer, die entweder hängen bleibt oder halluziniert, wenn weiter vorne etwas nicht das zurückliefert, was erwartet wurde.
Sonderfälle
Tabellen und strukturierte Daten. Naives Chunking, ob semantisch oder nicht, zerreißt Tabellen oft, trennt Überschriften von Zeilen oder teilt eine Tabelle mitten in einer Zeile. Erkennen Sie tabellarische Inhalte bereits bei der Ingestion und chunkieren Sie sie als Einheit, indem Sie sie in eine Markdown- oder Key-Value-Darstellung umwandeln, die das Einbetten als Text überlebt.
Häufig aktualisierte Dokumente. Dokumente, die sich oft ändern (Preisseiten, Richtliniendokumente, Changelogs), brauchen eine Cache-Invalidierung, die an einen Content-Hash oder eine Versionsnummer gebunden ist, nicht nur eine TTL. Ein rein zeitbasierter Cache allein liefert für die gesamte TTL-Dauer veraltete Antworten aus, selbst wenn sich das Quelldokument fünf Minuten nach dem Schreiben des Cache-Eintrags geändert hat.
Mehrturn-Konversationen. Eine Anschlussfrage wie „und was ist mit Staging?“ ergibt für ein Retrieval-System ohne den Kontext des vorherigen Turns keinen Sinn. Fügen Sie einen Query-Rewriting-Schritt hinzu, der den jüngsten Konversationsverlauf in eine in sich geschlossene Anfrage einarbeitet, bevor sie ins Retrieval geht; andernfalls sucht Ihre Hybridsuche gegen eine halbe Frage.
Skalierung & Produktionsherausforderungen
Embedding-Generierung wird beim Ingestion-Maßstab zum Engpass. Ein paar Dokumente synchron einzubetten ist in Ordnung; Zehntausende einzubetten nicht. Verlagern Sie die Ingestion in eine asynchrone Task-Queue — Celery mit Redis als Broker ist eine naheliegende Wahl, wenn das ohnehin schon in Ihrem Stack ist — und batchen Sie Embedding-Aufrufe, statt pro Chunk eine einzelne Anfrage abzusetzen.
Die Suche im Vektorindex wird langsamer, wenn der Korpus wächst. Brute-Force-Ähnlichkeitssuche ist im kleinen Maßstab in Ordnung und bricht jenseits von ungefähr 100k Vektoren auseinander. Wechseln Sie zu einem Approximate-Nearest-Neighbor-Index (HNSW ist der übliche Standard) und akzeptieren Sie einen kleinen, einstellbaren Genauigkeits-Trade-off für einen großen Gewinn bei der Latenz.
Cache-Invalidierung wird im Maßstab schwieriger, nicht einfacher. Wenn mehr Dokumente sich häufiger ändern, reicht eine einzelne globale TTL nicht mehr aus. Binden Sie Cache-Keys an einen Versions-Hash der Quelldokumente, die zu einer bestimmten Antwort beigetragen haben, sodass ein Update an einem davon natürlich jede gecachte Antwort invalidiert, die davon abhing.
Kosten schleichen sich still nach oben. Ohne Token-Tracking pro Anfrage ist das erste Anzeichen eines Kostenproblems die Monatsrechnung, nicht eine konkrete Anfrage. Loggen Sie die Anzahl der Input- und Output-Tokens pro Request und schlagen Sie bei Ausreißern Alarm; eine Anfrage, die deutlich mehr Kontext hineinzieht als üblich, ist oft ein Zeichen dafür, dass Ihr Token-Budget oder Ihr Reranking-Schwellenwert enger gesetzt werden muss.
Codebeispiele
Semantisches Chunking, Hybrid Retrieval und semantisches Caching werden oben unter den Kernschichten vollständig behandelt. Noch ein weiteres nützliches Stück, das man griffbereit haben sollte: ein minimaler Fallback-Guard, damit die Pipeline niemals aus leerem oder nahezu leerem Kontext generiert:
def generate_with_guard(query, context_chunks, generate_fn, min_score=0.3):
if not context_chunks or context_chunks[0].score < min_score:
return "I couldn't find anything specific on that in the documentation."
context = "\n\n".join(c.text for c in context_chunks)
return generate_fn(query=query, context=context)
Diese eine Funktion ist dafür verantwortlich, aus einer „stillen falschen Antwort“ ein „ehrliches Ich weiß es nicht“ zu machen — eine kleine Änderung mit großer Wirkung auf das Nutzervertrauen.
Häufige Fallstricke
Fehler: Vektorsuche als die gesamte Lösung behandeln. Eine Pipeline nur mit Vektorsuche wird Exact-Match-Anfragen, IDs, Codes und zitierte Begriffe systematisch verfehlen. Lösung: Führen Sie standardmäßig Hybrid Retrieval aus, nicht erst als spätere Optimierung. Es ist früh günstig hinzuzufügen und teuer nachzurüsten, wenn Ihr Evaluationssatz bereits auf das Verhalten einer reinen Vektor-Pipeline zugeschnitten ist.
Fehler: Chunking nach einer festen Token-Zahl ohne Rücksicht auf Inhaltsgrenzen. Das ist die häufigste Ursache für „die Antwort ist fast richtig, aber ein Schlüsseldetail fehlt“. Lösung: Chunkieren Sie semantisch, begrenzen Sie die Größe als Sicherheitsnetz und fügen Sie einen kleinen Überlappungsbereich zwischen benachbarten Chunks hinzu.
Fehler: Caching ohne Invalidierungsstrategie. Ein Cache ohne Rückweg zum Quelldokument liefert bereitwillig die Antwort vom letzten Monat aus, als wäre sie aktuell. Lösung: Versionieren Sie Cache-Keys gegen einen Content-Hash der beitragenden Dokumente, nicht nur gegen eine zeitbasierte TTL.
Fehler: Annehmen, dass mehr abgerufene Chunks eine bessere Antwort bedeuten. Context Stuffing erhöht Kosten und Latenz und macht Antworten oft schlechter statt besser, weil das Signal verwässert wird. Lösung: Reranken Sie aggressiv und erzwingen Sie ein hartes Token-Budget für das, was tatsächlich den Prompt erreicht.
Fehler: Ohne Evaluationssatz ausliefern. Ohne einen festen Satz repräsentativer Anfragen und erwarteter Quellen gibt es keine Möglichkeit zu wissen, ob eine Änderung am Chunking oder Retrieval geholfen oder geschadet hat. Lösung: Erstellen Sie schon vor dem Release zumindest einen kleinen Evaluationssatz (30–50 Anfragen) und führen Sie ihn bei jeder Änderung an der Retrieval-Schicht erneut aus.
Best Practices für die Produktion
- Messen Sie Retrieval-Qualität getrennt von Generierungsqualität. Precision@k und Recall gegen einen festen Evaluationssatz zeigen Ihnen, ob das Problem im Retrieval oder im Prompt liegt; debuggen Sie nicht den LLM-Aufruf, wenn die eigentliche Ursache weiter oben liegt.
- Cachen Sie mit versionierten Schlüsseln, nicht nur mit TTLs. Binden Sie jeden Cache-Eintrag an einen Hash der Dokumente, aus denen er aufgebaut wurde, damit Dokument-Updates automatisch die richtigen Antworten invalidieren.
- Erzwingen Sie ein hartes Token-Budget bei der Kontextzusammenstellung. Mehr Chunks sind keine Strategie; ein enges, geranktes Kontextfenster schlägt fast immer ein großes, ungeranktes.
- Loggen Sie jedes Retrieval, nicht nur jeden Fehler. Welche Chunks abgerufen wurden, welcher Score wo lag und was vom Token-Budget verworfen wurde — das sind die Daten, die Sie beim ersten Bericht über eine falsche Antwort brauchen werden.
- Bauen Sie einen Fallback-Pfad für schwaches Retrieval. Ein ehrliches „Ich weiß es nicht“ bei niedrigem Relevanz-Score ist immer besser als eine flüssige Antwort, die auf Kontext basiert, der kaum zur Frage passte.
Zum Abschluss
Nichts davon ist exotisch: semantisches Chunking, Hybrid Retrieval und eine Caching-Schicht sind alles Dinge, die die meisten Backend-Ingenieure ohnehin schon bauen können. Die Lücke zwischen Demo und Produktion ist kein fehlender Durchbruch; die Demo hatte nur nie genug Dokumente oder genug Anfragevielfalt, um offenzulegen, wo Chunking mit fester Größe und reine Vektorsuche stillschweigend zu kurz greifen. Beheben Sie diese drei Dinge, bevor Sie den Prompt anfassen, und die meisten Tickets vom Typ „gestern hat es funktioniert, warum ist es heute falsch?“ tauchen gar nicht erst auf.
Was ist als Erstes kaputtgegangen, als Sie Ihre RAG-Pipeline aus der Demo in die Produktion gebracht haben? Ich würde wirklich gern hören, was Sie überrascht hat.