Wir haben durchgerechnet, den ganzen Bestand ins Fenster zu legen
Alle paar Monate fragt jemand, ob wachsende Kontextfenster unsere Retrieval-Pipeline überflüssig machen. Eine berechtigte Frage mit einer rechnerischen Antwort — und die Rechnung hängt so stark am Bestand, dass eine allgemeine Meinung dazu wenig wert ist.
Die Frage in ihrer ehrlichen Form
Nicht, ob langer Kontext funktioniert. Er funktioniert. Die Frage ist, ob er für einen gegebenen Bestand die bessere Wahl ist, und das hängt an drei Eigenschaften: wie groß der Bestand ist, wie oft er sich ändert und wie viele Fragen täglich dagegen laufen.
So gestellt hört die Antwort auf, Geschmackssache zu sein. Wir haben einen Kunden, bei dem wir das gesamte einschlägige Material bei jedem Aufruf ins Fenster legen, und einen anderen, bei dem das nicht zu vertreten wäre — und beide Systeme sind ansonsten gleich gebaut.
Der Bestand, bei dem wir es tun
Interne Richtlinien von vielleicht dreißigtausend Token, ein paar Mal im Jahr aktualisiert, einige Dutzend Abfragen am Tag. Das Ganze passt bequem hinein, es gibt keinen Index zu pflegen, keinen Chunker zu justieren und keinen Retrieval-Fehlermodus zu debuggen.
Dieses System ist deutlich einfacher als unsere Retrieval-Pipelines, und die Einfachheit ist der eigentliche Gewinn, nicht die Qualität. Ändert sich eine Richtlinie, tauscht jemand eine Datei. Keine Neuindexierung, kein Veralterungsfenster, nichts, was aus dem Tritt geraten kann.
Der Bestand, bei dem wir es nicht tun
Technische Dokumentation von mehreren hundert Megabyte, wöchentlich geändert, einige tausend Abfragen am Tag. Der Abruf schickt etwa sechs Passagen. Die Alternative schickt bei jeder einzelnen Frage um Größenordnungen mehr Token, und keine Caching-Strategie behebt das, wenn die Fragen nichts miteinander zu tun haben.
Wir haben es sauber durchgerechnet, statt darüber zu streiten: rund das Vierzigfache je Frage, für einen gemessenen Qualitätsunterschied auf unserem Referenzset, der innerhalb der Streuung dreier Läufe lag. Das Vierzigfache für einen nicht nachweisbaren Unterschied zu zahlen ist kein Abwägen, sondern ein Fehler mit Begründung.
| Eigenschaft des Bestands | Spricht für |
|---|---|
| Passt mit Luft ins Fenster | Ins Fenster legen |
| Ändert sich wöchentlich oder öfter | Beides. Langer Kontext spart Neuindexierung |
| Hohes Abfragevolumen | Retrieval. Kosten skalieren mit jedem Aufruf |
| Antworten brauchen Herkunft für den Nutzer | Retrieval. Passagen tragen ihre Quelle |
Die Untersuchung, die den Handel eingeordnet hat
Li und Kollegen veröffentlichten in jenem Juli einen Vergleich, der Retrieval-Augmented Generation und Modelle mit langem Kontext auf denselben Aufgaben gegenüberstellt, und schlagen ein Vorgehen vor, das zwischen beiden routet, statt sich auf eines festzulegen — weil der günstigere Weg für einen großen Teil der Anfragen genügt.
Beim Routen sind wir ebenfalls gelandet, von der Kostenseite her statt von der Qualitätsseite. Neu war für uns die Beobachtung, dass die Wahl je Anfrage statt je System getroffen werden kann — was wir nicht taten und im Rückblick offensichtlich ist.
Die Mischform, die wir betreiben
Für den mittleren Fall, einen Bestand von einigen hunderttausend Token, rufen wir zuerst ab und fallen auf das vollständige Dokument zurück, wenn der Abruf mehrere Passagen aus derselben Datei mit geringem Abstand ihrer Werte liefert. Dieses Muster bedeutet meist, dass die Frage dem Dokument als Ganzem gilt.
Es greift bei etwa jeder zwanzigsten Anfrage. Der Rest wird zu normalen Kosten aus Passagen beantwortet, und der Rückfall trägt den teuren Weg nur dort, wo der günstige sichtbar gescheitert ist, statt bei jedem Aufruf.
Das Argument, das nicht von Kosten handelt
Herkunft. Eine abgerufene Passage kommt mit ihrer Quelle, und unsere Oberfläche zeigt, auf welchem Dokument und welchem Abschnitt eine Antwort ruht. Liegt der gesamte Bestand im Fenster, kann das Modell zitieren — und das Zitat ist erzeugt statt festgehalten.
Für das Richtliniensystem ist das vertretbar, weil ein Nutzer das ganze Dokument in einer Minute prüfen kann. Für die technische Dokumentation wäre es das nicht, denn die Quelle ist genau das, was ein Techniker will, und ein leicht falscher erzeugter Verweis ist schlechter als gar keiner.
Was die Antwort ändern würde
Vor allem der Preis. Die Rechnung ist ein Verhältnis zwischen den Kosten von Token und den Kosten, einen Index zu pflegen, und beides bewegt sich. Wir wiederholen den Vergleich für einen Kunden, wenn sich sein Volumen deutlich ändert oder eine Preisänderung das Verhältnis verschiebt — bisher etwa einmal im Jahr.
Caching ändert es ebenfalls, aber weniger als es scheint. Es hilft, wenn viele Fragen einen gemeinsamen Anfang teilen, und unsere Fragenverteilung wird von unzusammenhängenden Einzelanfragen beherrscht — dem Fall, den Caching am schlechtesten bedient.
Was wir nicht behaupten
Wir behaupten nicht, Retrieval sei die bessere Architektur. Bei einem Drittel der Systeme, die wir betreiben, ist es einfacher, das Material ins Fenster zu legen, und genau das tun wir. Die Behauptung ist nur, dass die Wahl aus drei messbaren Eigenschaften folgt — nicht aus einer allgemeinen Haltung dazu, welcher Ansatz moderner ist.
Wir behaupten auch nicht, unser Faktor vierzig sei übertragbar. Er gilt für einen Bestand, bei einem Volumen, unter einer Preisliste; nützlich ist die Methode: das Verhältnis für den Bestand vor sich zu messen, bevor man eine Architektur dafür wählt.