Nur abrufen, wenn es hilft
„Immer abrufen“ ist die Voreinstellung, weil sie einfach ist, und eine Weile war sie auch unsere. Dann fiel auf, dass der Assistent auf „wie setze ich mein Passwort zurück“ mit drei lose verwandten Richtlinienauszügen und einer Relativierung antwortete.
Die Antwort, die zu lang war
Die Beschwerde war nicht, dass Antworten falsch seien. Sie war, dass einfache Fragen aufwendige Antworten erzeugten. Auf die Frage, wie man ein Passwort zurücksetzt, rief der Assistent drei Richtliniendokumente ab, zitierte sie und ergänzte einen Vorbehalt zu Ausnahmen, die gar nicht galten.
Das Retrieval funktionierte genau wie gebaut. Jede Frage löste eine Suche aus, jede Suche lieferte ihre besten Passagen, und jeder Passagensatz landete in der Antwort, ob er etwas beitrug oder nicht.
Die Idee, die wir aus der Forschung übernommen haben
Asai und Kollegen haben das Problem klar benannt: eine feste Zahl Passagen abzurufen, unabhängig davon, ob Retrieval nötig ist oder ob die Passagen relevant sind, kann die Vielseitigkeit eines Modells mindern und wenig hilfreiche Ausgaben erzeugen. Ihre Antwort, Self-RAG, trainiert ein Modell, bedarfsweise zu entscheiden und das Abgerufene über besondere Tokens zu reflektieren.
Die Diagnose deckte sich genau mit unserer. Das Mittel passte nicht zu unserer Lage, und diese Unterscheidung sollte man ausdrücklich machen.
Warum wir die Entscheidung außerhalb des Modells gelassen haben
Die Entscheidung ins Modell zu trainieren heißt, dass sie nur so einsehbar ist wie das Modell. Unsere muss prüfbar sein: Ein regulierter Kunde muss sehen, warum eine bestimmte Antwort die Dokumentbasis herangezogen hat oder nicht — und diese Erklärung muss über Modellversionen hinweg stabil bleiben.
Also liegt die Entscheidung in der Pipeline. Ein kleiner Klassifikator läuft vor dem Retrieval und gibt eine von drei Routen aus: direkt antworten, abrufen und dann antworten, oder eskalieren. Das ist eine Komponente, die wir vollständig testen, unabhängig versionieren und in einem Satz erklären können.
| Entscheidung im Modell | Entscheidung in der Pipeline |
|---|---|
| Lernt feine Fälle aus Daten | Nur so gut wie ihre Merkmale |
| Ändert sich mit dem Modell | Eigenständig versioniert |
| Einzelfall schwer erklärbar | Eine Klassifikatorausgabe zum Draufzeigen |
| Braucht Trainingsdaten und einen Lauf | Braucht ein Referenzset und einen Nachmittag |
Was es gut genug vorhersagt
Zwei Signale trugen den größten Teil der Genauigkeit. Erstens, ob die Frage eine Entität nennt, die im Bestand existiert — Kontonummern, Produktcodes, Vertragsreferenzen. Wenn ja, abrufen. Zweitens, ob die Frage zu einer kleinen Menge prozeduraler Absichten passt, die der Assistent ohnehin beantworten kann, also die Passwort-Klasse.
Alles andere ruft im Zweifel ab. Uns ist ein unnötiger Abruf lieber als ein verpasster, denn ein unnötiger kostet Latenz, ein verpasster eine falsche Antwort.
Was sich an der Ausgabe geändert hat
Kurze Fragen bekamen kurze Antworten, und darum ging es. Messbar wurde der Effekt an der Rückfragequote: weniger klärende Züge, weil die Antwort nicht mehr mit Material aufgefüllt war, an dem die Nutzer vorbeilesen mussten.
Die Tokenkosten sanken als Nebeneffekt, nicht als Ziel. Die eingesparten Abrufe waren die günstigen, die Ersparnis entsprechend bescheiden und nicht der Grund für die Umstellung.
Was wir damit nicht sagen
Wir sagen nicht, dass gelernte Abrufentscheidungen die falsche Richtung sind. Für offene Assistenten ohne Prüfpflicht ist es wahrscheinlich besser, das Modell entscheiden zu lassen, denn die Abwägung ist tatsächlich fein, und ein Regelwerk bleibt immer grob.
Wir behaupten auch nicht, drei Routen reichten allgemein. Es ist das, was dieser Assistent brauchte. Ein System mit mehreren getrennten Beständen müsste in der Route auch den Bestand benennen, und das ist ein anderer Klassifikator.