RAG für Agenten: Antworten belegen, ohne im Kontext zu ertrinken
Retrieval-augmented Generation wird meist als Pipeline eingeführt: Frage einbetten, Top-Chunks holen, einfügen, generieren. Für eine Frage-Antwort-Box funktioniert das. In einem Agenten ist es die falsche Form, denn der Agent weiß erst nach einem Schritt, was er braucht.
Die funktionierende Variante behandelt Retrieval als Werkzeug, das der Agent aufruft, wenn er Belege braucht — manchmal zweimal mit anderen Suchanfragen, manchmal gar nicht. Diese eine Änderung entfernt viel irrelevanten Kontext und macht den ganzen Lauf günstiger und schärfer.
Retrieval als Werkzeug, nicht als Vorspann#
Bieten Sie Suche als normales Werkzeug mit Suchargument und kleiner, strukturierter Rückgabe an: einige Passagen, je mit Identifikator und Quelle. Der Agent entscheidet, wann er sucht, verfeinert nach dem ersten Ergebnis und ruft stattdessen ein anderes Werkzeug auf, wenn die Antwort strukturierte Daten sind. Die Pipeline-Variante kann nichts davon und zahlt die Kosten bei jeder Anfrage.
Protokollieren Sie die Suchanfragen des Agenten. Sie sind die ehrlichste Beschreibung dessen, was Ihre Nutzer wirklich fragen.
Chunking-Entscheidungen zählen mehr als das Embedding-Modell#
- Nach Struktur trennen — Überschriften, Abschnitte, Listenpunkte — nicht nach fester Zeichenzahl.
- Chunks eigenständig halten: ein Chunk, der mit `Außerdem erfordert es` beginnt, ist ohne Kontext wertlos.
- Dokumenttitel und Abschnittsüberschrift an jeden Chunk hängen — für Modell und Zitat.
- Identifikator und URL speichern, damit eine Antwort auf ihre Quelle zeigen kann.
- Wenige, größere, sinnvolle Chunks bevorzugen; Overlap ist ein Pflaster für schlechte Grenzen.
Hybrid schlägt reine Vektoren auf echten Korpora#
| Anfrageart | Vektorsuche | Stichwortsuche | Am besten |
|---|---|---|---|
| Konzeptuelle Frage | Stark | Schwach | Vektor |
| Exakter Produktcode oder Fehlertext | Schwach | Stark | Stichwort |
| Seltener Eigenname | Gemischt | Stark | Stichwort |
| Umformulierte Richtlinienfrage | Stark | Schwach | Vektor |
| Realer Traffic insgesamt | Gemischt | Gemischt | Beides, zusammengeführt und neu sortiert |
Zitieren lassen — und Scheitern erlauben#
Zwei Anforderungen erledigen den Großteil der Vertrauenswürdigkeit. Erstens trägt jede aus Retrieval stammende Aussage den Identifikator ihrer Passage, und Ihre Oberfläche macht daraus einen Link — unbelegte Aussagen werden sichtbar statt plausibel. Zweitens muss die Suche nichts zurückgeben dürfen, und dem Agenten muss beigebracht sein, dass `das finde ich in unserer Dokumentation nicht` ein korrektes Ergebnis ist. Ein Agent, der beim Suchen nicht scheitern darf, erfindet.
Den Index ehrlich halten#
Retrievalqualität verfällt leise. Dokumente ändern sich, Abschnitte werden gelöscht, und der Index liefert weiter, was er zuletzt sah. Regelmäßig neu indexieren, Chunks gelöschter Quellen entfernen und ein kleines Evaluationsset aus Anfragen mit bekannten korrekten Passagen pflegen. Ohne das droht der schlimmste Fehler: ein Agent, der selbstsicher eine im März zurückgezogene Richtlinie zitiert.
Häufige Fragen
Soll der Agent immer vor der Antwort suchen?
Nein. Retrieval bei jeder Anfrage verschwendet Latenz und füllt Kontext bei Fragen, die keine Belege brauchen. Lassen Sie den Agenten entscheiden und messen Sie, wie oft er hätte suchen sollen und es nicht tat.
Wie viele Passagen zurückgeben?
Drei bis sechs gut gewählte schlagen zwanzig. Mehr Text verdünnt Aufmerksamkeit, erhöht Kosten und die Chance, dass der Agent sich auf eine nur scheinbar passende Passage stützt.
Was, wenn Retrieval nichts Brauchbares liefert?
Das muss ein unterstützter Ausgang sein. Geben Sie ein explizites leeres Ergebnis zurück und weisen Sie den Agenten an zu sagen, dass er nichts gefunden hat, und den nächsten Schritt anzubieten.
rag für agentenretrieval augmented generationhybride suchechunking strategiebelegte antworten
