RAG-Distraktoren: Warum ein höheres k Konkurrenten kauft, keine Antworten
Die Ränge zwei bis zehn einer Retrieval-Liste sind Distraktoren. Chromas Daten, ein Replay mit fokussiertem Kontext und die Token-Rechnung einer Support-Sitzung zeigen, wie man sie loswird.
Stell dir einen Retriever vor, der zu einer Frage zehn Chunks liefert. Genau einer enthält die Antwort. Überleg kurz, was die anderen neun sind. Ihr Wesen gibt das Ranking selbst vor: Aus dem gesamten Korpus sind es die Passagen, die der Frage am nächsten kommen und sie trotzdem nicht beantworten.
Hier ist nichts kaputt. Der Retriever hat getan, wofür er spezifiziert wurde. Diese neun Chunks sind kein durchgerutschtes Rauschen, sie sind sein Produkt.
Die folgenden Zahlen stammen aus veröffentlichten Messungen anderer, und jede ist mit Quelle angegeben. Das Argument, das sie verbindet, ist eine These über RAG in Produktion: Ein höheres k kauft meist keine Antworten. Es kauft Konkurrenten für die Antwort, und das sind die teuersten Tokens, die in ein Kontextfenster gelangen können.
Ein Name für das, was ausgeliefert wird
Chromas Context-Rot-Report vom 14. Juli 2025 trifft eine Unterscheidung, die viele Texte über Retrieval ignorieren. Irrelevanter Inhalt hat mit der Frage nichts zu tun. Ein Distraktor gehört zum Thema, beantwortet die Frage aber nicht.
Beide verhalten sich sehr unterschiedlich. Über achtzehn Modelle hinweg senkte schon ein einziger Distraktor die Genauigkeit gegenüber einer Baseline, die nur die Nadel enthielt. Mit vier Distraktoren summierte sich der Schaden, und der Effekt wuchs mit der Länge der Eingabe. In einer Kombination aus Heuhaufen und Nadel tauchten zwei der vier handgeschriebenen Distraktoren weit häufiger in halluzinierten Antworten auf als die anderen beiden. Auch die Modellfamilien unterschieden sich: Claude-Modelle hielten sich bei Mehrdeutigkeit eher mit einer Antwort zurück, GPT-Modelle antworteten eher selbstbewusst – und falsch.
Vergleich diese Definition jetzt mit einer gerankten Liste von zehn Treffern. Die Ränge zwei bis zehn passen exakt darauf, und sie sind so sortiert, dass die überzeugendsten ganz oben stehen.
Daraus folgt: Bessere Embeddings verschlimmern das. Der ganze Zweck eines besseren Retrievers ist es, Passagen näher an die Frage zu rücken. Für Rang eins ist das das Ziel. Für die anderen neun heißt es, dass jeder Beinahe-Treffer schärfer ist als alles, was das Modell vom Vorjahr hochgespült hätte. Das Geld fließt in die Qualität der Distraktoren und wird als Recall verbucht.
Die übliche Abhilfe wiederholt den Fehler eine Ebene höher. Ein Cross-Encoder-Reranker beurteilt Relevanz sorgfältiger als der erste Durchgang, bewertet aber eben immer noch Relevanz, und eine Passage kann genau beim Thema liegen und trotzdem keinerlei Antwort enthalten. Neun Beinahe-Treffer umzusortieren entfernt sie nicht. Das schafft nur eine andere Frage: Beantwortet die Passage die Frage, statt bloß zu ihr zu passen?
Die versteckte Hälfte der Kosten
Ein zweiter Posten taucht auf keiner Rechnung auf.
Mit einem unfokussierten Fenster muss ein einzelner Aufruf zwei Aufgaben erledigen: die relevante Passage finden und dann darüber nachdenken. Das Retrieval ist still ins Modell gewandert, wo es sich nicht loggen, tunen oder beim Scheitern beobachten lässt und wo es um dieselbe Aufmerksamkeit kämpft wie das Schlussfolgern, für das man eigentlich bezahlt hat.
Chroma hat diese Lücke beziffert. In ihren LongMemEval-Läufen ging jede Frage zweimal hinein. Einmal mit der vollen Eingabe, im Schnitt 113.000 Tokens. Einmal fokussiert, im Schnitt 300 Tokens, nur mit der relevanten Passage. Jede Modellfamilie schnitt mit der vollen Eingabe schlechter ab. Die größte Lücke zeigten Claude-Modelle, vor allem weil sie die Antwort verweigerten, sobald es mehrdeutig wurde.
Gleiche Frage, gleiches Modell, die Antwort in beiden Fenstern vorhanden. Geändert hat sich nur, was die Antwort umgab.
Ein größeres Fenster rettet das nicht
Anthropic hat im September 2025 einen Beitrag zu Context Engineering veröffentlicht, der die architektonische Ursache benennt. In einem Transformer schaut jedes Token auf alle anderen, was bei n Tokens n² paarweise Verbindungen ergibt, und mit wachsendem n hält das Modell diese Verbindungen immer schwächer fest. Übrig bleibt ein begrenztes Aufmerksamkeitsbudget, sodass zusätzlicher Kontext immer weniger einbringt.
Dieser Abfall ist ein Hang und keine Klippe, und genau deshalb übersieht man ihn. Nichts wirft einen Fehler. Die Präzision sickert einfach weg.
Chromas Daten zeigen, wo der Verlust am steilsten ist. Alle achtzehn Modelle schnitten bei Text, der zu Unsinn durchgemischt war, besser ab als bei Text in natürlicher Reihenfolge. Ein weiteres Muster: Je weniger die Formulierung einer Frage der Formulierung der beantwortenden Passage ähnelte, desto schneller fiel die Genauigkeit mit wachsender Eingabelänge, obwohl dieselben Paare bei kurzen Eingaben gut funktionierten.
Die praktische Lesart ist unbequem. Ein ordentlich strukturierter Korpus hilft nicht, und am härtesten treffen lange Fenster jene Nutzer, die in ihrem eigenen Vokabular fragen und nicht in dem der Dokumentation.
Vier Arten von Tokens und wie jede scheitert
| Art | Beispiele | Fehlerbild |
|---|---|---|
| Statisch | System-Prompt, Regeldateien, Tool-Definitionen | Wird in jedem Zug mitgeschickt, der Preis skaliert also mit der Zahl der Züge. Verwässert. |
| Abgerufen | Pro Anfrage geholte Chunks | Wird pro Abruf berechnet. Bringt Beinahe-Treffer mit. |
| Angesammelt | Chatverlauf, Tool-Ausgaben | Wächst nur in eine Richtung. Bricht spät, oft mehrere Züge nach der Vergiftung. |
| Ausgelagert | Notizen, Dateien, Zusammenfassungen von Sub-Agenten | Günstig aufzubewahren. Veraltet ohne jede Warnung. |
Die Dokumentation von Vektordatenbanken stellt die Zeile mit den abgerufenen Tokens als Recall-Problem dar und rechnet die anderen drei nie durch. Teams tunen das Retrieval mit großem Eifer, während sich dahinter unbemerkt die Präambel vervielfacht.
Replay mit fokussiertem Kontext
Ein einziges Experiment kann einen Kontextfehler von einem Modellfehler unterscheiden, und es braucht keine neue Infrastruktur.
Zieh dreißig fehlgeschlagene Fälle aus der Produktion. Stell für jeden von Hand den kleinsten Kontext zusammen, der die Antwort enthält und sonst nichts. Dann lass dieselbe Frage gegen beide Versionen laufen. Der normale Pfad sieht so aus:
chunks = index.query(question, k=10) # one may answer, the rest merely resemble
prompt = SYSTEM + "\n\n".join(c.text for c in chunks) + question
Und die Vergleichsschleife so:
for case in failing_cases:
full = assemble_context(case.question)
focused = case.gold_passage
log(case.id, ask(full), ask(focused)) # the gap is your context tax
Vergleiche die beiden Spalten. Besteht die fokussierte Version dort, wo die volle scheitert, hilft kein Modell-Upgrade.
Danach instrumentierst du die Buchführung. Logge die Tokens pro Zug in vier Töpfen: statisch, abgerufen, Tool-Ergebnisse und Verlauf. Dann schau dir die Aufteilung in dem Zug an, in dem die Qualität einbricht. Nur sehr wenige Teams haben diese Zahl für ihren eigenen Agenten je gesehen, und am meisten überrascht meist der statische Anteil.
Rechnung für eine Support-Sitzung
Chromas Zahlen sind die Ausgangsbasis. Ab hier ist es einfache Rechnerei.
Nimm einen Support-Agenten mit einer Präambel von 6.000 Tokens, einer mittleren Sitzungslänge von zwölf Zügen und Top-8-Retrieval mit rund 700 Tokens pro Chunk.
Über die Sitzung macht die Präambel 72.000 berechnete Tokens aus, mit Informationen, die sich nie ändern. Das Retrieval steuert pro Zug 5.600 bei, also 67.200 insgesamt. Davon wurden sieben von acht Chunks ausgewählt, weil sie der Frage ähneln, nicht weil sie sie beantworten. Zusammen sind das rund 59.000 Tokens fabrizierter Ablenkung, wiederholt in jeder Sitzung bei jedem Nutzer.
Vergleich das mit einem fokussierten Prompt von etwa 300 Tokens, der bei genau denselben Fragen besser abschnitt als die Eingabe mit 113.000 Tokens. Die Kosten sind nur der halbe Schaden. Diese Tokens drücken auch die Genauigkeit.
Was zuerst zu ändern ist
Behandle jedes Token wie einen Sitzplatz, für den eine Lizenz nötig ist.
Statischer Kontext muss seinen Platz rechtfertigen, indem er in jedem Zug, in dem er steht, das Verhalten ändert, und er steht in allen. Was eine Aufgabe von fünfzig steuert, gehört in einen Skill, der bei Bedarf geladen wird, und nicht in die immer aktive Präambel.
Abgerufener Kontext muss seinen Platz rechtfertigen, indem er antworten kann. Ranke also danach, ob ein Chunk die Antwort trägt, nicht nach Ähnlichkeit, und senke k so lange, bis das Replay keine Verbesserung mehr zeigt. Eine günstige Methode ist ein zweiter Durchgang, der jeden Kandidaten einem kleinen Modell mit einer einzigen Ja-Nein-Frage vorlegt, ob die Passage die Antwort enthält, und jedes Nein verwirft. Das entfernt typischerweise den Großteil des Abrufs.
Jedes Token wird in jedem Zug berechnet und zehrt vom selben Aufmerksamkeitsbudget. Zu fragen, ob ein Dokument relevant ist, ist deshalb der falsche Test. Entscheidend ist, ob es mehr wert ist als das, was es verdrängt.