Das Modell findet das Werkzeug und weiß kaum, wozu es dient

Ein Agent mit 47.000 verfügbaren Werkzeugen – verteilt auf rund 16.000 Schnittstellen – kann nicht bei jeder Anfrage alle Beschreibungen lesen. Also sucht er vorher. Eine Bauart, die dafür seit gut einem Jahr gehandelt wird, spart sich den Suchindex ganz: Man näht jedem Werkzeug ein eigenes erfundenes Wort ins Vokabular des Modells und trainiert es, dieses Wort auf Zuruf auszusprechen. Das Verzeichnis steckt dann in den Gewichten statt in einer Datenbank – kein Vektorindex, keine Beschreibungen im Kontext, ein Schritt weniger. Ganz ohne Nachschlagewerk geht es allerdings nicht: Beim Antworten hält ein Suchbaum die Ausgabe auf gültige Werkzeugnamen fest.

Vier Leute bei SAP haben nachgesehen, was in diesen erfundenen Wörtern eigentlich drinsteckt. Ihr Prüfverfahren ist so einfach wie unangenehm: Man stellt Fragen über ein Werkzeug, ohne es beim Namen zu nennen – nur das eingenähte Wort steht da. Wer das Werkzeug kennt, kann antworten.

Das Ergebnis für ein Vier-Milliarden-Modell: 95,7 Prozent – der Anteil der Fälle, in denen das richtige Werkzeug unter den ersten fünfzig von siebenundvierzigtausend auftaucht, auf dem günstigsten der drei Testabschnitte.

Auf Multiple-Choice-Fragen über Werkzeuge aus demselben Katalog kommt dasselbe Modell auf 31,4 Prozent. Wer bei vier Antwortmöglichkeiten würfelt, erreicht 25.

Das eingenähte Wort ist bei dieser Konfiguration also eher ein Zeiger als eine Auskunft. Es bringt den richtigen Eintrag zuverlässig unter die ersten fünfzig, weiß aber kaum etwas über ihn – was das Werkzeug tut, welche Eingaben es braucht, wofür es taugt. Interessant ist der Verlauf: In der ersten Trainingsstufe, in der das Modell die Beschreibungen liest, entsteht dieses Wissen durchaus. Die zweite Stufe, die auf Treffgenauigkeit trainiert, drückt es wieder heraus – bei der Grundvariante um vierundzwanzig Prozentpunkte, bei einer verwandten nur um drei.

Der zweite Befund trifft die Praxis härter. Die Benchmark-Anfragen sind ausführliche, von einem Sprachmodell erzeugte Sätze. Stellt man stattdessen knappe, teils absichtlich mehrdeutige Aufgaben, bricht die Trefferquote ein: um 50 bis 53 Prozentpunkte bei den flachen Varianten, um 61 bis 64 bei den hierarchischen.

Auf diesem Prüffeld liegt die beste eingenähte Variante des Vier-Milliarden-Modells mit 44,4 Prozent unter einer Suche von der Stange, die nur Textähnlichkeit misst: 55,6. Mit einem anderen Grundmodell gleicher Größe, aber anderer Architektur, verschwindet der Abstand: dieselbe Variante erreicht dort 57,0 Prozent – praktisch gleichauf mit der Suche von der Stange. Der Vorsprung der Einbettungssuche ist also kein Naturgesetz der Bauart, sondern hängt daran, worauf sie aufsetzt.

Was dagegen spricht¶

Der Wissensverlust ist ein Befund über ein bestimmtes Grundmodell in einer bestimmten Trainingsart. Größere und andere Grundmodelle gehen in ihrer besten Variante mit deutlich mehr Wissen in die zweite Stufe – die Autoren nennen 73 bis 75 Prozent auf denselben Fragen, also das Dreifache des Zufalls – und behalten es dort weitgehend. Die übrigen Konfigurationen derselben Modelle starten niedriger, und nicht alle halten das Niveau: die hierarchische startet bei 39,7 Prozent, und eine der flachen fällt in der zweiten Stufe von 64,9 auf 49,0. Der Anhang räumt das ein, die Einleitung spricht dagegen davon, die zweite Stufe zerstöre das Wissen „nahezu durchgängig". Vorsichtiger als die Einleitung ist das Abstract: dort liegen „einige Modelle" bei den Wissensproben nahe am Zufall.

Vor allem aber liefert die Arbeit einen Gegenversuch, und er ist zweischneidig: Trainiert man die zweite Stufe auf knapp formulierten Anfragen, steigt die Trefferquote auf ihnen erheblich. Die Kapazität ist also da. Die Autoren ziehen daraus allerdings das Gegenteil einer Entwarnung – im selben Absatz fällt die Wissensprobe weiter, von 31,5 auf 26,0 Prozent, also fast auf Zufallsniveau, und sie schließen, dass das Trainingsziel der zweiten Stufe selbst die Ursache ist, unabhängig vom Zuschnitt der Anfragen. Hinzu kommt eine Unstimmigkeit der Arbeit mit sich selbst: Haupttext und Anhang berichten für denselben Versuch unvereinbare Werte, 28,7 auf 64,1 gegen 43,8 auf 87,8 Prozent. Die Richtung ist belastbar, die Höhe nicht. Auch eine Abhilfe steht im Papier – sparsames Nachtrainieren statt vollständiger Gewichtsanpassung, kombiniert damit, das Verzeichnis in der ersten Stufe in mehreren Formaten einzuprägen – und die Autoren beschränken ihren Befund ausdrücklich auf dieses eine Verfahren auf diesem einen Katalog.

Bleibt: Die Arbeit stammt aus dem Labor eines Unternehmenssoftware-Konzerns. Der neue Prüfsatz ist selbst maschinell erzeugt, und seine Kandidatenlisten stammen – jedenfalls beim Kurzanfragen-Test – aus derselben Einbettungssuche, gegen die er misst. Die Autoren raten davon ab, aus den Benchmarks Einsatzentscheidungen abzuleiten, ohne sie vorher am eigenen Werkzeugkatalog zu prüfen.

Warum das hier steht¶

Weil hier zwei Dinge auseinanderfallen, die man gewöhnlich zusammen denkt: etwas finden und etwas kennen. Ein Verfahren kann in seinem Benchmark nahezu perfekt sein und trotzdem kaum etwas über den Gegenstand wissen. Die Autoren führen das auf das Trainingsziel der zweiten Stufe zurück, nicht auf eine unglückliche Umsetzung – allerdings für genau dieses eine Verfahren auf genau diesem einen Katalog; auf andere Bauarten dieser Art verallgemeinern sie ausdrücklich nicht. Wie stark es ausfällt, hängt sichtbar an Details, die niemand für inhaltlich hält: an der Tokenform, am Grundmodell, daran, ob voll oder sparsam nachtrainiert wird.

Eine hohe Trefferquote bedeutet nicht, dass irgendwo Verständnis entstanden ist. Man muss danach eigens fragen, sonst fragt niemand.

Gegenprüfung

Von sieben Modellfamilien gegen den Volltext der Quelle gelesen; Befunde und Korrekturen stehen im Protokoll.claude · deepseek · gemini · gpt · grok · sol · terraPrüfprotokoll zu dieser Notiz →