ThinkingBox-Training: Datenbank-Prüfung als Belohnung für Agenten-Training

Microsoft und Hugging Face nutzen die Datenbank-Endzustandsprüfung ihres Benchmarks ThinkingBox als Belohnungssignal für Reinforcement Learning. Ein Qwen3.8-27B-Modell stieg nach 50 GRPO-Schritten von 38 auf 107 Aufgaben, die in allen 20 Versuchen gelingen. Der Trainingscode ist auf GitHub veröffentlicht.

Forschung 22. Okt. 2026 5 Min. Lesezeit Quelle: Hugging Face Blog
Symbolbild, KI-generiert

Worum es geht

Microsoft und Hugging Face haben einen zweiten Blogbeitrag zu ThinkingBox veröffentlicht, einem Benchmark für KI-Agenten in Geschäftsabläufen mit Datenbanken. Im ersten Beitrag ging es darum, dass Agenten behaupten, fertig zu sein, die Datenbank aber etwas anderes zeigt. Nun wird dieselbe Prüfung als Belohnung für Reinforcement Learning (RL, Lernen durch Belohnung für gute Ergebnisse) genutzt. Der Code ThinkingBox-Training liegt auf GitHub.

Das Ergebnis laut Autoren: Für Qwen3.8-27B stieg die durchschnittliche Erfolgsquote von 51,70 % auf 60,78 %, und die Zahl der Aufgaben, die bei allen 20 Versuchen gelingen, von 38 auf 107 – nach nur 50 GRPO-Schritten (GRPO ist ein RL-Verfahren, das mehrere Antworten einer Aufgabe vergleicht).

Die Idee: Prüfer wird zum Lehrer

ThinkingBox-Bench umfasst 507 Aufgaben. Jede startet ein echtes Backend, gibt dem Agenten Werkzeuge (über MCP) und einen simulierten Nutzer mit privatem Kontext. Am Ende prüfen automatische Tests den Endzustand der Datenbank – nicht die einzelnen Werkzeugaufrufe. So kann der Agent auch neue Lösungswege finden.

Da solch ein Test meist 1 oder 0 liefert, taugt er direkt als Belohnung. Die große Mehrheit der Belohnungen kommt aus deterministischen Tests; eine Minderheit nutzt ergänzend einen LLM-Richter (GPT-5 Chat) für enge Rubrik-Fragen. Wichtig: Trainiert wurde auf anderen Aufgaben als dem Benchmark.

Welche Aufgaben sich fürs Training eignen

Bei GRPO entsteht nur dann ein Lernsignal, wenn von mehreren Versuchen (hier 8 pro Aufgabe) manche gelingen und manche scheitern. Sind alle falsch oder alle richtig, gibt es keinen Vorteil für einzelne Verläufe. Zudem ist jeder Versuch teuer: Backend, Werkzeugsitzung und ein Modell als simulierter Nutzer.

Deshalb schätzen die Autoren vorab die Schwierigkeit relativ zum Basismodell („offline policy-relative difficulty“). Jede Aufgabe wird n-mal probiert; die Erfolgswahrscheinlichkeit wird mit einer Jeffreys-Beta-Verteilung geschätzt. Aufgaben fallen in Bänder:

Band Erfolgswahrscheinlichkeit Entscheidung
Selten gelöst 0–0,08 verwerfen
Schwierig 0,08–0,40 behalten
Mittel 0,40–0,60 behalten
Häufig gelöst 0,60–0,90 behalten (Vollparameter-Training)
Fast immer gelöst 0,90–1 verwerfen

Der finale Pool enthielt 187 Aufgaben. Die Auswahl erfolgt einmal vorab und bleibt fix; ein erneutes Prüfen während des Trainings wurde nicht gewählt.

Trainingsaufbau

Jeder Versuch ist eine komplette Episode mit frischem Backend und isolierter MCP-Sitzung. Pro Update gab es 18 Gruppen à 8 Rollouts, also 144 Episoden, auf 24 H100-GPUs (3 Knoten à 8). Verwendet wurde Token-Mean-GRPO mit voller Parameteroptimierung, AdamW mit Lernrate 1e-6 und ohne Weight Decay, 50 Schritte. Gruppen ohne Varianz wurden DAPO-artig ersetzt; Systemfehler wie Backend-Timeouts wurden nicht als Fehlschlag gewertet, sondern neu aufgefüllt. Training und Auswertung müssen die Modellausgabe identisch interpretieren (Code in trainer/core/tb_interpret.py).

Ergebnisse

Metrik Basis RL-feinjustiert Änderung
Beobachtet 20/20 38 (7,50 %) 107 (21,10 %) +69 Aufgaben
pass@1 51,70 % 60,78 % +9,08 Pkt.
pass@20 453 (89,35 %) 446 (87,97 %) −7 Aufgaben

pass@1 und 20/20 stiegen in allen fünf Domänen (Retail, Autoversicherung, Reisen, Neobank, Consulting). pass@20 war uneinheitlich; den größten Rückgang gab es bei Autoversicherung (−7,0 Punkte), den größten 20/20-Zuwachs bei Retail (+24,5 Punkte). Die Autoren deuten das als „Schärfung“: Das Modell wurde nicht breiter, sondern wiederholbarer; einige seltene Lösungswege verschwanden.

Ein Beispiel: Bei einem Hotel-Downgrade, das eine Managerfreigabe erfordert, änderte das Basismodell in 15 von 20 Versuchen die Buchung ohne Freigabe; das trainierte Modell ließ Buchung und Zahlung in allen 20 Versuchen unverändert.

Im Vergleich (pass@1 / Aufgaben mit 20/20): Claude Opus 5.5 67,16 % / 241, GPT-5.4 65,36 % / 128, GPT-5.6 Sol 61,91 % / 82, Qwen3.8-27B RLFT 60,78 % / 107, GPT-6 Astra 58,31 % / 231, Kimi-K3 57,37 % / 68. Durchschnittlicher Erfolg und Wiederholbarkeit ergeben also unterschiedliche Rangfolgen.

Kosten

Die Autoren rechnen: Kosten pro verlässlicher Aufgabe = geschätzte Kosten der 507×20-Kampagne ÷ Aufgaben mit 20/20. Die Kampagne wurde von 925,80 $ auf 855,58 $ billiger (−7,6 %), die Kosten pro erfolgreichem Versuch fielen von 0,177 $ auf 0,139 $, pro verlässlicher Aufgabe von 24,36 $ auf 8,00 $. Das liegt nahe an GPT-5.4 (6,80 $), GPT-6 Astra (7,45 $) und Claude Opus 5.5 (7,80 $). Die Werte sind ein vergleichender Index, keine echten Rechnungen; Trainings- und Probing-Kosten sind nicht enthalten.

Selbst nachbauen

Das Repository microsoft/thinkingbox-training enthält Datenauswahl, Rollouts, Belohnung und Verl-Integration (Verl 0.9.0). Getestet auf Linux/WSL mit Python 3.12 und uv. Nötig sind NVIDIA-GPUs mit passendem CUDA/NCCL, ein lokaler Qwen3.8-27B-Checkpoint und OpenAI-kompatible Endpunkte für simulierten Nutzer und Richter. Die Referenzkonfiguration nutzt 3×8 H100. Die öffentlichen Beispielaufgaben sind nicht der private 187er-Pool; man muss eigene, vom Benchmark getrennte Daten liefern. Die Auswertung lief mit vLLM auf acht A100.

Einordnung

Die Arbeit zeigt, dass ein einfacher, ausführbarer Endzustandstest als Belohnung gut funktioniert und ein 27B-Modell bei Wiederholbarkeit deutlich verbessert. Einschränkungen: Der Trainingspool ist privat, das Training und der Test teilen Framework, simulierten Nutzer, Bewertungsart und einige Werkzeuge, was die Übertragbarkeit begrenzt. Die Abdeckung sank leicht. Zudem stammen alle Zahlen von den Autoren, und die Aufgaben sind synthetische Rekonstruktionen. Praktische Empfehlungen: vor dem Training die Schwierigkeitsverteilung prüfen, Parser in Training und Evaluation abgleichen und sowohl Abdeckung als auch Wiederholbarkeit berichten.

Quellen

#reinforcement-learning#agenten#microsoft#benchmark#grpo
Originalquelle lesen