RAG (Retrieval-Augmented Generation) ist eine Architektur, bei der eine Anwendung zur Laufzeit relevante Dokumente aus einer Wissensquelle abruft, meist per Vektor- oder Hybridsuche, und sie dem Prompt eines Sprachmodells hinzufügt. Das Modell antwortet dann auf Basis dieses Kontexts. Antworten werden dadurch aktueller, konkreter und leichter überprüfbar.
Was ist RAG?
RAG (Retrieval-Augmented Generation) verbindet einen Suchschritt mit der Textgenerierung. Statt sich nur auf das zu verlassen, was ein Sprachmodell im Training gelernt hat, sucht die Anwendung zunächst relevante Informationen in den eigenen Daten, etwa in Dokumentation, Tickets, Verträgen oder einem Produktkatalog, und übergibt die Ergebnisse dem Modell als Kontext. Bekannt wurde der Begriff durch ein Forschungspapier von Lewis et al. aus dem Jahr 2020. Seitdem gehört RAG zu den verbreitetsten Mustern für LLM-Anwendungen in Unternehmen.
RAG ist attraktiv, weil sich Wissen durch Neuindizierung aktualisieren lässt, ohne ein Modell neu zu trainieren, weil Zugriffsrechte beim Abruf durchgesetzt werden können und weil Antworten ihre Quellen nennen können. Gleichzeitig kommen neue Komponenten hinzu, die eigenes Monitoring brauchen. Deshalb ist RAG ein Kernthema der LLM Observability.
Wie RAG funktioniert
- Ingestion: Dokumente werden in Chunks zerlegt, von einem Embedding-Modell in Vektoren umgewandelt und in einem Vektorindex gespeichert, oft zusammen mit Stichwortindizes und Metadaten wie Quelle, Datum und Berechtigungen.
- Retrieval: Zur Laufzeit wird die Nutzerfrage eingebettet, und die ähnlichsten Chunks werden abgerufen, häufig per Hybridsuche aus Vektorähnlichkeit und Stichwortsuche.
- Reranking und Filterung: Ein Reranker oder Regeln sortieren und kürzen die Kandidaten, setzen Zugriffsrechte durch und entfernen Duplikate.
- Anreicherung: Die ausgewählten Chunks werden zusammen mit Anweisungen in den Prompt eingefügt.
- Generierung: Das Modell erzeugt die Antwort, idealerweise mit Verweisen auf die verwendeten Chunks.
Varianten sind etwa Agentic RAG, bei dem ein Agent entscheidet, wann und was abgerufen wird, sowie mehrstufiges Retrieval für komplexe Fragen.
Jede Stufe hat eigene Stellschrauben: Chunk-Größe und Überlappung, das Embedding-Modell, die Zahl der abgerufenen Kandidaten, der Reranker und die Prompt-Vorlage. Eine Änderung an einer dieser Stellen kann eine Art von Frage verbessern und eine andere verschlechtern. Testen Sie Änderungen daher gegen einen festen Fragenkatalog und beobachten Sie ihre Wirkung anschließend im Betrieb. Wichtig ist auch die Aktualität des Index: Wenn Quelldokumente geändert werden, muss die Neuindizierung zeitnah erfolgen, sonst antwortet das System mit veraltetem Wissen.
Wo RAG scheitert
- Retrieval-Fehlgriffe: Das richtige Dokument existiert, wird aber nicht gefunden, etwa wegen ungünstiger Chunk-Größen, eines schwachen Embedding-Modells oder einer Frage, die anders formuliert ist als die Quelle.
- Veraltete oder falsche Daten: Der Index enthält alte Fassungen oder Dokumente, die der Nutzer nicht sehen darf.
- Kontextüberladung: Zu viele oder zu lange Chunks erhöhen Token-Verbrauch und Latenz und können die relevante Passage verdecken.
- Nicht quellentreue Generierung: Das Modell ignoriert den abgerufenen Kontext oder widerspricht ihm, eine Form der Halluzination.
- Addierte Latenz: Embedding, Suche, Reranking und Generierung summieren sich, und jede Stufe kann zum Engpass werden.
Eine RAG-Pipeline überwachen
Eine RAG-Anfrage lässt sich gut als verteilter Trace mit einem Span pro Stufe abbilden. Die OpenTelemetry GenAI Semantic Conventions (Status: Development) definieren Operationsnamen wie embeddings, retrieval und chat sowie Attribute wie gen_ai.data_source.id für die Wissensquelle, gen_ai.request.model und Token-Zahlen. Abgerufene Dokumente und der Suchtext sind als Opt-in-Attribute definiert, weil sie sensible Inhalte enthalten können.
Nützliche Signale je Stufe:
| Stufe | Signale |
|---|---|
| Ingestion | Indizierte Dokumente, Indizierungsverzug, fehlgeschlagene Dokumente |
| Retrieval | Latenz, Anzahl Treffer, Ähnlichkeitswerte, leere Ergebnisse |
| Reranking | Latenz, behaltene und verworfene Chunks |
| Generierung | Input- und Output-Tokens, Time to First Token, Finish Reason |
| Qualität | Kontextrelevanz, Groundedness, Antwortrelevanz aus Evaluierungen |
Beispiel: ein langsamer RAG-Endpunkt
Ein illustratives Beispiel: Die p95-Latenz eines Dokumentenassistenten steigt nach einem Release. Die Traces zeigen, dass der Modell-Span unverändert ist, der Retrieval-Span aber nun mehrere Sekunden dauert. Ein neuer Metadatenfilter wird nach der Vektorsuche auf eine große Kandidatenmenge angewendet statt direkt in der Indexabfrage. Nachdem der Filter in die Indexabfrage verschoben wurde, liegt die Retrieval-Latenz wieder auf dem vorherigen Niveau, was die Trace-Daten bestätigen.
Best Practices
- Versionieren Sie Index, Embedding-Modell, Chunking-Einstellungen und Prompt und halten Sie diese Versionen an jedem Trace fest.
- Bauen Sie einen Testsatz aus Fragen mit erwarteten Quelldokumenten auf und messen Sie die Retrieval-Qualität getrennt von der Antwortqualität, mithilfe der LLM-Evaluierung.
- Setzen Sie Berechtigungen im Retrieval durch, nicht im Prompt.
- Begrenzen Sie Anzahl und Größe der Chunks und überwachen Sie die Kontext-Tokens pro Anfrage.
- Überwachen Sie die Vektordatenbank wie jede andere Datenbank: Latenz, Fehler, Auslastung und Indexgröße.
Wie Obseria hilft
Obseria zeigt jede RAG-Anfrage als einen Trace vom API-Aufruf über Embedding und Vektorsuche bis zum Modellaufruf, auf Basis von Distributed Tracing mit OpenTelemetry. Datenbank- und Infrastrukturmetriken der Vektordatenbank liegen direkt neben GenAI-Spans und Token-Metriken. So erkennen Sie, ob eine langsame oder schwache Antwort am Retrieval, am Modell oder an den Daten liegt.
