Warum wir Kontext deckeln statt ihn zu füllen
Wir haben in einem Kundensystem 40 Passagen übergeben, weil sie ins Fenster passten — und schlechtere Antworten bekommen als mit zwölf. Ein Paper von Liu et al. hat uns erklärt, warum, und seitdem behandeln wir Position als Qualitätsparameter.
Das Problem, bevor wir den Namen dafür hatten
Der Fall war ein Wissenszugang über eine große Dokumentensammlung. Die Retrieval-Stufe funktionierte messbar gut: Die richtige Passage war in über neun von zehn Fällen unter den abgerufenen. Trotzdem waren die Antworten unzuverlässig. Manchmal stand die Information wörtlich im übergebenen Kontext, und das Modell antwortete daran vorbei.
Unsere erste Vermutung war der übliche Verdächtige: zu wenig Kontext. Also übergaben wir mehr. Es wurde schlechter. Das war der Punkt, an dem klar wurde, dass wir die falsche Größe optimieren.
Was wir übersehen hatten
Wir hatten Retrieval als Mengenproblem behandelt: Ist die richtige Passage dabei, ja oder nein? Diese Frage beantwortet aber nur die halbe Kette. Die zweite Hälfte lautet: Wird die Passage auch benutzt, wenn sie dabei ist? Und die Antwort darauf hängt davon ab, wo sie steht.
Genau das misst „Lost in the Middle" von Liu et al. Die Autoren verschieben die relevante Stelle systematisch durch den Kontext und halten alles andere konstant. Das Ergebnis: Die Leistung ist am Anfang und am Ende der Eingabe am höchsten und fällt deutlich ab, wenn das Modell auf etwas in der Mitte zugreifen muss. Der wichtigste Zusatz für uns war, dass sich das auch bei Modellen zeigt, die ausdrücklich für lange Kontexte gebaut sind.
Abb. — Trefferquote nach Positiongold: die gesuchte Passage · cyan: was wir dagegen tun
Was wir daraufhin geändert haben
Drei Dinge, in dieser Reihenfolge. Erstens haben wir die Zahl der übergebenen Passagen gedeckelt. Nicht „so viele wie passen", sondern so wenige wie nötig — in dem genannten System zwölf statt vierzig. Allein das brachte den größten Sprung, ohne dass sich an der Suche etwas änderte.
Zweitens haben wir ein Cross-Encoder-Reranking vor die Übergabe gesetzt. Der entscheidende Punkt daran ist nicht die bessere Auswahl, sondern die bessere Reihenfolge: Was am zuverlässigsten gelesen wird, gehört an die Ränder. Drittens haben wir aufgehört, Retrieval-Qualität nur als Recall zu messen.
Wie wir es seitdem testen
In unser Testset gehört seither eine Variation, die viele Teams nicht haben: dieselbe Frage, dieselben Dokumente, nur die Position der Antwort wandert. Was danach an Unterschied bleibt, ist Positionseffekt und nichts anderes. Das ist billig zu bauen und deckt eine Fehlerklasse auf, die im normalen Betrieb wie Zufall aussieht.
Wir haben dafür eine Faustregel: Wenn die Antwortqualität zwischen Position 1 und Position 20 um mehr als ein paar Prozentpunkte auseinanderliegt, übergeben wir zu viel. Der Deckel ist dann die günstigere Korrektur als ein größeres Modell.
Wo wir bewusst anders entscheiden
Der Effekt ist kein Grund, Kontext prinzipiell klein zu halten. Bei Aufgaben, die Zusammenfassung über ein ganzes Dokument verlangen, ist mehr Kontext richtig — dort gibt es keine einzelne Stelle, die verloren gehen kann. Wir unterscheiden deshalb zwei Fälle: Antworten aus einer Fundstelle werden gedeckelt, Aggregation über viele Stellen nicht.
Ebenso wenig folgt daraus, dass lange Kontexte Retrieval ersetzen. Eher das Gegenteil: Wenn Position mitentscheidet, gewinnen Auswahl und Reihenfolge an Gewicht — also genau die beiden Dinge, die eine Retrieval-Stufe leistet.
Was wir dem Paper nicht entnehmen
| Verbreitete Lesart | Unsere Einschätzung |
|---|---|
| Lange Kontexte sind nutzlos | Nein. Gemessen wird ein Positionseffekt, kein Totalausfall |
| Das erledigt sich mit dem nächsten Modell | Offen. Das Paper zeigt den Effekt auch bei Long-Context-Modellen; wir planen nicht darauf, dass er verschwindet |
| Die Ursache ist bekannt | Nein. Das Verhalten ist gemessen, die Erklärung nicht abschließend. Wir bauen gegen das Verhalten, nicht gegen eine Theorie |
Der Aufwand, ehrlich gerechnet
Reranking kostet einen zusätzlichen Modellaufruf pro Anfrage und damit Latenz im zweistelligen Millisekundenbereich sowie etwas Rechenzeit. Der Deckel auf die Passagenzahl spart dagegen Eingabetoken, häufig mehr, als das Reranking kostet. In den Systemen, die wir betreiben, war die Umstellung unterm Strich nicht teurer — nur zuverlässiger.
Was wir mitnehmen
Ein Kontextfenster ist eine Kapazitätsangabe, keine Qualitätszusage. Was hineinpasst, ist nicht dasselbe wie das, was verwendet wird. Seit wir Position als eigenen Parameter behandeln — deckeln, sortieren, testen — diskutieren wir bei Antwortproblemen deutlich seltener über Modellwechsel.