Ein 270M-Modell für Multi-Hop-Fragen: Verluste bei der Genauigkeit, Gewinne vor Ort

Ein Modell mit 270 Millionen Parametern wurde auf einen schmalen Teil des Multi-Hop-Reasoning feinabgestimmt und dann mit weit größeren Modellen verglichen. Es verlor bei jeder Genauigkeitszahl. Nützlich ist es trotzdem, und die Gründe lohnen eine genaue Betrachtung.

Die Aufgabe klingt bescheiden. Eine Multi-Hop-Frage kommt herein, und das Modell muss die erste Suche für ein Retrieval-System benennen. Von 95 zurückgehaltenen Testfragen lag das winzige Gemma-3-270M 81-mal richtig, also bei 85,3 %. Beide größeren Konkurrenten schnitten besser ab. Dennoch passt es auf einen Laptop, kostet pro Aufruf nichts und läuft ohne Verbindung. Ein zusätzlicher Befund kam dabei heraus: Ein fester System-Prompt hilft einem Modell dieser Größe weit mehr als erwartet, und der Gewinn lässt sich beziffern.

Der Aufbau

Multi-Hop-Fragen brauchen mehr als einen Fakt. Nehmen wir „Were Scott Derrickson and Ed Wood of the same nationality?“ („Hatten Scott Derrickson und Ed Wood dieselbe Nationalität?“). Für die Antwort muss man die Nationalität der einen Person finden, dann die der anderen, und dann vergleichen. HotpotQA, der hier verwendete Datensatz, besteht aus solchen Fragen, die jeweils mindestens zwei Fakten brauchen, meist aus zwei verschiedenen Wikipedia-Artikeln.

Ziel war nur der erste Schritt, Hop-1 genannt: die erste Suche, die ein System ausführen muss, bevor es irgendetwas anderes finden kann. Für eine gegebene Frage schreibt das Modell ein kurzes YAML-Objekt mit drei Teilen. thought erklärt, was zuerst gesucht werden soll, action ist immer der feste Wert Lookup, und target_entity benennt genau das, wonach gesucht wird. Eine korrekte Ausgabe für die Derrickson-Frage sieht so aus:

thought: "I need to find the nationality of Scott Derrickson first to eventually compare it to Ed Wood."
action: "Lookup"
target_entity: "Scott Derrickson"

Das Modell ruft keine Dokumente ab, macht keinen zweiten Hop und gibt keine endgültige Antwort. Es entscheidet nur, was zuerst gesucht wird.

Bei Vergleichsfragen hätte das Modell beide Entitäten und den Vergleich in einer einzigen Ausgabe liefern können. Das Design vermeidet das bewusst. Jeder Hop bekommt eine atomare Aktion, eine Vergleichsfrage wird also zu drei getrennten Schritten. Entität eins finden, Entität zwei finden, und erst dann die Ergebnisse vergleichen. Geht etwas schief, lässt sich der fehlerhafte Schritt leicht ausmachen. Das kostet allerdings Genauigkeit, weil sich Fehler über eine längere Kette aufsummieren. Bei 90 % pro Schritt landet eine dreistufige Kette bei rund 73 % Ende-zu-Ende. Der Tausch ist akzeptabel, denn ein System, das scheitert und sagt, wo, ist mehr wert als eines, das still scheitert.

Fürs Training brauchte es gelabelte Beispiele korrekter Hop-1-Zerlegungen, und GPT-4o diente als Lehrer. Sein Prompt enthielt fünf ausgearbeitete Beispiele und strenge Regeln: Das Ziel muss direkt aus dem Wortlaut der Frage stammen und darf nie ein Name sein, den das Modell selbst herleitet, und alles Unbekannte kommt in thought, nicht in target_entity. Dieser Prompt lief über HotpotQA-Fragen, und ein zweiter GPT-4o-Aufruf bewertete jede Ausgabe anhand der Gold-Artikeltitel aus HotpotQA selbst. 474 Labels überstanden die Prüfung.

Die Regeln des Lehrers sind wichtiger, als sie aussehen. Wenn das Ziel die Wörter der Frage wiederverwenden muss, muss das kleine Modell keine Namen aus dem Gedächtnis auflösen – genau dort würde ein 270M-Modell halluzinieren. Unsicherheit in thought hält target_entity sauber genug, um es direkt in einen Suchaufruf zu geben.

Die Labels wurden 80/20 aufgeteilt: 379 fürs Training und 95 zurückgehalten für jede Auswertung unten. Gemma-3-270M wurde dann mit Supervised Fine-Tuning auf den 379 trainiert, also direkt auf Frage-Antwort-Paaren und ohne jedes Belohnungssignal.

Wie bewertet wird

Jede Zahl unten basiert auf denselben 95 zurückgehaltenen Fragen und zwei getrennten Maßen.

• Zielkorrektheit. Hat das Modell das Richtige als Suchziel gewählt? Ein Treffer bedeutet, dass target_entity einem der Gold-Titel von HotpotQA für diese Frage entspricht (ohne Groß-/Kleinschreibung), oder dass ein GPT-4o-Richter entscheidet, dass beide Zeichenketten zur selben Suche führen. Das ist die Hauptmetrik.

Fünfundneunzig Fragen bedeuten, dass jede einzelne den Wert um etwa 1,05 Punkte verschiebt. Deshalb stehen neben den Prozentwerten die Rohzahlen. Auch der Richter schwankt: Als er 75 bereits akzeptierte Zeilen bei Temperature 0 neu bewertete, änderten sich zwei Urteile. Unterschiede unter etwa 3 Punkten gelten daher als Rauschen.

Eine Prompt-Zeile, die zählte

Zuerst kam ein Nebenexperiment. Zwei Kopien des Modells wurden auf identischen Daten trainiert (dieselben 379 Beispiele, derselbe Split, dieselben Hyperparameter) und unterschieden sich in einem einzigen Absatz. Kopie A sah vor jedem Beispiel eine feste Systemnachricht, die Aufgabe und YAML-Layout in einfachen Worten beschrieb. Kopie B sah nur Frage und Antwort.

Vorab lautete die Wette gegen die Systemnachricht. Mit assistant_only_loss=True wird der Loss nur auf den Tokens der eigenen Antwort des Modells berechnet, dem Signal, das das Lernen antreibt. Systemnachricht und Frage bekommen nie einen eigenen Loss, also schien es, als könnten sie nichts beibringen.

Diese Wette ging verloren. Kopie A lag bei beiden Metriken vorn, jeweils um fünf Fragen.

Das Ergebnis rechtfertigte, die Nachricht zu behalten, sollte aber nicht überbewertet werden. Gewinne von 5,3 Punkten (Zielkorrektheit) und 5,2 Punkten (exakte Übereinstimmung) liegen über der 3-Punkte-Schwankung des Richters. Anderes Rauschen bleibt jedoch: nur 95 Testfragen und ein einziger Trainingslauf pro Kopie. Als das Setup mit Systemnachricht später für einen anderen Benchmark von Grund auf neu trainiert wurde, ergab es 81/95, wo der erste Lauf 83/95 lieferte. Zwei Punkte Schwankung allein durch einen neuen Lauf bedeuten, dass die echte Größe des Gewinns über mehrere Läufe unbekannt bleibt.

Teilweise ist das Warum klar. Auf die Tokens der Systemnachricht fällt kein direkter Loss, aber das macht sie fürs Training nicht unsichtbar. Gradienten der Antwort-Tokens fließen zurück durch die Attention-Schichten, die die Systemnachricht lesen, also kann das Modell lernen, diesen Kontext zu nutzen, statt sich nur auf das Wissen des Basismodells zu verlassen. Darüber hinaus wird es zur begründeten Vermutung. Eine plausible Theorie: Wer Aufgabe und Schema ausformuliert, verschafft den Next-Token-Vorhersagen des Basismodells schon vor dem Training einen Vorsprung, und es bleiben weniger Lücken zu schließen. Das veröffentlichte Modell behält die Systemnachricht.

Praktisch heißt das: Der Instruktionstext ist auch zur Inferenzzeit Teil der Eingabe, also muss dieselbe kurze Nachricht vorhanden sein, wenn das Modell genutzt wird. Lässt man sie beim Deployment weg, landet das Modell in einer Situation, die es im Training nie gesehen hat.

Der Benchmark gegen größere Modelle

Nach dem Training trat das Modell auf denselben 95 Fragen gegen drei Referenzpunkte an: sein eigenes unverändertes Basismodell, Llama-3.1-8B-Instruct über Groq und den GPT-4o-Lehrer, dessen Ausgaben die Labels lieferten.

Die ersten beiden Spalten nebeneinander zeigen, was Fine-Tuning bei festem Prompt beiträgt. Das feinabgestimmte Modell gegen die anderen beiden zeigt, wie sich ein kleiner Spezialist gegen größere Modelle schlägt, die jeweils einen vollen Prompt bekamen. Die beiden Prompts sind wirklich verschieden. Der kurze ist die Systemnachricht, mit der das kleine Modell trainiert und getestet wurde: Aufgabe und drei Feldnamen, sonst nichts. Der lange Five-Shot-Prompt ist der, mit dem die Trainings-Labels erzeugt wurden. Er bringt fünf ausgearbeitete Beispiele plus Formatregeln mit, die der kurze weglässt, etwa den wörtlichen String "Lookup" und die Vorgabe, dass die Ausgabe ein flaches Mapping und keine Liste sein muss. Den größeren Modellen den langen Prompt zu geben, war Absicht. Es ging darum, ihre Leistung mit ordentlichen Anweisungen zu sehen, nicht darum, ob sie ein unausgesprochenes Format erraten. Mit dem kurzen Prompt landeten beide nahe null, und der Grund war nicht schwaches Reasoning, sondern fehlende Formatregeln. Der lange Prompt behob das für beide.

Bei der Genauigkeit liegt das kleine Modell hinter Llama-3.1-8B und mit größerem Abstand hinter GPT-4o. Beim Tempo hängt es GPT-4o ebenfalls hinterher, obwohl kein Netzwerk-Roundtrip anfällt. Der Grund: GPT-4o läuft auf einem Serving-Stack, der auf schnellen Traffic in großem Maßstab getrimmt ist, während das kleine Modell einen Aufruf nach dem anderen auf einer geteilten Colab-GPU abarbeitet, wo Batching und Weight-Caching niemand in der Hand hat.

Llama-3.1-8B hat etwa 30-mal mehr Parameter. OpenAI hält die Größe von GPT-4o geheim, daher gibt es kein Verhältnis, aber klein nennt es niemand. Keines der größeren Modelle wurde hier geschlagen. Der Benchmark klärt aber eine andere Frage: Kann ein Modell dieser Größe diese eine schmale Aufgabe bewältigen? Es kann, mit 81 von 95. Ist die Genauigkeitstabelle aber das einzige Kriterium, gewinnt das kleine Modell nicht.

Was der Benchmark nicht erfassen konnte

Das eigentliche Argument für dieses Modell steht nicht in dieser Tabelle. Es kommt aus drei Dingen, die die Tabelle nie gemessen hat.

Kosten. Gemessen, nicht geschätzt. Die Tokenzahlen stammen aus den echten Prompts und Antworten der GPT-4o-Läufe, gezählt mit tiktoken (dem Tokenizer hinter OpenAIs Modellen) und zu OpenAIs veröffentlichten Preisen berechnet. Ein typischer GPT-4o-Aufruf verbrauchte 606,6 Prompt-Tokens und 39,4 Completion-Tokens, etwa $0,0019 pro Aufruf oder knapp $1,91 je 1.000 Aufrufe. Das feinabgestimmte Modell hat keine Gebühr pro Aufruf. Hardware und Strom kosten trotzdem etwas, „kostenlos“ trifft es also nicht ganz, aber es gibt keine Rechnung pro Anfrage und kein Rate-Limit.

Datenschutz. Die beiden lokalen Inferenzfunktionen stellen keinerlei Netzwerkanfrage. Die Frage geht in den Tokenizer, dann ins Modell und bleibt auf dem Gerät. Das ist eine Eigenschaft des Codes und keine Benchmark-Zahl, Lesen genügt also zur Überprüfung. Eine Einschränkung betrifft die gehostete Demo: Sie läuft auf Servern von Hugging Face, Text, den man dort eintippt, verlässt also den Rechner des Besuchers. Die Datenschutzaussage gilt nur für selbst gehostete Läufe.

Offline-Betrieb. Zweimal geprüft, nicht angenommen. Zuerst wurden HF_HUB_OFFLINE=1 und TRANSFORMERS_OFFLINE=1 gesetzt. Diese Flags lassen die Hugging-Face-Bibliotheken bei jedem Netzwerkversuch einen Fehler werfen, statt still einen Cache zu nutzen. Dann wurde das WLAN komplett abgeschaltet und der eigene Lade- und Generierungscode der Demo mit beiden Flags ausgeführt. Eine brandneue Frage, die weder in Trainings- noch in Testdaten vorkam, ergab trotzdem ohne Verbindung eine korrekte Zerlegung.

Keine Genauigkeitstabelle zeigt diese drei Eigenschaften. Sie sind die eigentlichen Gründe, ein kleines Modell lokal zu betreiben, statt ein riesiges über das Netz aufzurufen, und das Argument wirkt ehrlicher, wenn die wenig schmeichelhaften Genauigkeitszahlen direkt daneben stehen.

Was verfügbar ist

Modell, Datensatz und eine funktionierende Demo sind öffentlich auf Hugging Face:

• das feinabgestimmte Modell
• der Zerlegungs-Datensatz
• ein Live-Demo-Space

Die Demo nutzt einen geteilten kostenlosen GPU-Pool, daher ist die erste Anfrage nach einer Ruhephase langsam, während die Gewichte laden. Sie bringt zwei eingebaute Fragen mit, eine vom Typ „Brücke“ und eine vom Typ „Vergleich“, sodass Besucher beide Zerlegungsformen sehen, ohne etwas einzutippen.

Die Prüfungen gingen über diese beiden Beispiele hinaus. Eine wirklich neue Frage, die weder in Trainings- noch in Testdaten stand („The author of The Hobbit was born in which country?“ – „In welchem Land wurde der Autor von ‚Der Hobbit‘ geboren?“), bekam eine saubere, korrekte Zerlegung. Nicht jeder Versuch war fehlerfrei: Eine Frage nach dem Hauptsitz von SpaceX ergab die richtige Zielentität, aber eine thought-Zeile ohne Sinn. Derzeit ist die Wahl der Suche stabiler als die angehängte Erklärung, besonders wenn die Formulierung von dem abweicht, was in HotpotQA üblich ist.

Was unterm Strich bleibt

Man nehme einen eng umrissenen Schritt einer größeren Reasoning-Kette. Ein Modell mit 270 Millionen Parametern löst ihn in 81 von 95 Fällen korrekt, liegt bei der Genauigkeit hinter viel größeren Modellen und läuft trotzdem auf einem Laptop – ohne Rechnung und ohne Netz. Für Setups, in denen Fragen das Gerät nicht verlassen dürfen und eine falsche erste Suche später in der Pipeline abgefangen oder wiederholt werden kann, ist Hop-1 einen Versuch wert. Es beweist nicht, dass ein so kleines Modell eine ganze Reasoning-Kette allein und ohne Prüfinstanz dahinter tragen kann.