RAG in Produktion: Warum Retrieval Langsam Wird_

Die meisten RAG-Demos sind schnell, weil sie die Teile vermeiden, die das Produktionsretrieval teuer machen.

Der Datensatz ist klein. Die Chunks sind sauber. Der Embedding-Aufruf erfolgt in der Nähe. Der Vektorindex ist warm. Es gibt keine Berechtigungsfilter, keine Reranking-Phase und keine Anforderung, zu erklären, warum ein Ergebnis ausgewählt wurde.

Echte Systeme sind langsamer, weil Retrieval nicht ein Schritt ist. Es ist eine Pipeline.

Das Latenzbudget Ist Nicht Nur Vektor-Suche

Wenn ein Benutzer eine Frage stellt, umfasst ein Produktionsabruffluss oft:

1. Abfragenormalisierung
2. Embedding-Generierung
3. MetadatFiltering
4. Vektorsuche
5. lexikalische Suche
6. Reranking
7. Zusammenstellung des Prompts
8. der finale Modellaufruf

Teams geben oft der Vektor-Datenbank die Schuld, weil sie das sichtbarste Element ist. In der Praxis ist der langsamste Teil oft woanders.

Traffic zwischen Regionen ist ein häufiges Beispiel. Wenn Ihre Anwendung in einer Region läuft, Ihr Embedding-Anbieter in einer anderen ist und Ihr Vektorspeicher in einer dritten, kann das System langsam erscheinen, selbst wenn jedes einzelne Element in Isolation „schnell“ ist.

Chunking-Qualität Bestimmt Retrieval-Qualität

Schlechte Chunks erzeugen schlechtes Recall.

Ein naiver Chunker mit fester Breite wird durch Überschriften, Codeblöcke, Tabellen und Absätze teilen, ohne irgendeinen von ihnen zu verstehen. Die resultierenden Embeddings sind technisch gültig und semantisch schwach.

Wenn der Inhalt strukturiert ist, chunk mit der Struktur:

• respektiere Markdown-Überschriften
• halte Codeblöcke intakt
• bewahre Abschnittsüberschriften mit ihrem Inhalt
• behalte Metadaten wie Dokument-ID, Abschnittspfad, Sprache und Zugriffsbereich

Du brauchst keinen perfekten Chunker. Du brauchst einen, der offensichtlich nicht die Bedeutung des Quellmaterials beschädigt.

Hybrides Retrieval Ist In Der Regel Die Bessere Standardlösung

Dichtes Retrieval ist gut bei semantischer Ähnlichkeit. Lexikalisches Retrieval ist gut bei genauen Begriffen, IDs, Dateinamen, Fehlermeldungen und Produktnamen.

Produktionssysteme benötigen meist beides.

Eine praktische Form sieht so aus:

type RetrievalResult = {
  id: string;
  score: number;
  source: "dense" | "lexical";
};

async function retrieve(query: string) {
  const [dense, lexical] = await Promise.all([
    vectorIndex.search(query),
    bm25Index.search(query),
  ]);

  return mergeAndDedupe([...dense, ...lexical]);
}

Das macht das System nicht einfacher, aber es macht es in der Regel zuverlässiger.

Reranking Ist Teuer Und Oft Loht Sich

Approximate-Nearest-Neighbor-Indizes optimieren für Geschwindigkeit, nicht für perfekte Rangordnung. Das ist für die Kandidatengenerierungsphase in Ordnung. Oft reicht es jedoch nicht für die endgültige Antwortphase.

Reranking verbessert die Präzision, indem es einen kleineren Kandidatensatz nimmt und jedes Ergebnis gegen die tatsächliche Abfrage mit einem stärkeren Modell bewertet.

Der Kompromiss ist offensichtlich:

• bessere Relevanz
• mehr Latenz
• höhere Kosten

Deshalb gehört Reranking nach dem Retrieval, nicht davor. Lassen Sie das schnelle System Kandidaten finden. Lassen Sie das langsamere System sie verfeinern.

Frische Ist Ein Systemproblem

Ein Großteil der RAG-Frustration ist tatsächlich ein Indizierungsproblem.

Die Quelle der Wahrheit ändert sich, aber der Retrieval-Index hinkt hinterher. Dann erhält der Benutzer eine Antwort aus veralteten Chunks, und das Team gibt dem Sprachmodell die Schuld.

Betrachten Sie die Indizierung als ihre eigene Pipeline:

• erfassen Sie Dokumentenänderungen
• stellen Sie die Arbeit zum erneuten Einbetten in eine Warteschlange
• upsert die neuen Chunks
• entfernen oder tombstone obsolet gewordene Chunks
• verfolgen Sie die Indexversion oder die Dokumentrevision

Wenn Sie dies überspringen, haben Sie kein Retrieval-System. Sie haben einen Schnappschuss.

Filter Ändern Die Form Des Problems

Unternehmenssuche bedeutet selten „alles durchsuchen“. Es bedeutet in der Regel „nur das durchsuchen, was dieser Benutzer sehen darf“.

Das bedeutet, dass das Design der Metadaten nahezu ebenso wichtig ist wie die Qualität der Embeddings.

Ein Chunk sollte normalerweise genügend Metadaten tragen, um zu unterstützen:

• Mandantenisolation
• Dokumenttypfilter
• Quellsystemfilter
• Frischenfenster
• Berechtigungsbewusstes Retrieval

Hier werden auch einige Benchmarks von Vektor-Datenbanken weniger nützlich. Ein Benchmark ohne echte Filter und Zugriffsbedingungen ähnelt nicht einer Produktionslast.

Eine Bessere Produktionshaltung

Wenn Ihre RAG-Funktion langsam erscheint, überprüfen Sie Folgendes, bevor Sie Embeddings die Schuld geben:

• Sind die Dienste in derselben Region?
• Überladen Sie die Kandidaten?
• Reranken Sie zu viele Chunks?
• Sind die Chunks strukturell sinnvoll?
• Ist der Index aktuell?
• Werden Berechtigungen in der Retrieval-Schicht durchgesetzt?

RAG-Qualität ist nicht nur Modellqualität. Es ist Retrieval-Engineering.

Weiterführende Literatur

• Dense Passage Retrieval for Open-Domain Question Answering
• OpenAI Embeddings Guide
• Pinecone: Hybrid Search