🤖 AI

Beyond Next-Token Prediction: An RLVR Proof of Concept for Tool-Use Agents on Atlassian Workflows

Dieses Paper präsentiert einen Proof of Concept, der demonstriert, dass Reinforcement Learning mit verifizierbaren Belohnungen (RLVR) die Fähigkeit kleiner Sprachmodelle zur Ausführung komplexer, mehrstufiger Tool-Aufrufe in synthetischen Atlassian-Umgebungen (Jira und Confluence) signifikant verbessert und dabei in den meisten Szenarien ohne die Nutzung von Live-APIs oder menschlichem Feedback nahezu perfekte Erfolgsraten erzielt.

Ursprüngliche Autoren: Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Veröffentlicht 2026-07-03

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Karthikeya Aditya Vissa, Sankalp Mane, Ananya Mantravadi, Harshit Rajgarhia, Abhishek Mukherji

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten einen sehr klugen, belesenen Bibliothekar (die KI), der hervorragend darin ist, das nächste Wort in einem Satz vorherzusagen. Wenn Sie fragen: „Der Himmel ist...“, wird er selbstbewusst „blau“ sagen. Aber wenn Sie ihn bitten, tatsächlich etwas in einem komplexen Bürosystem zu tun – wie zum Beispiel: „Erstelle ein neues Projekt-Ticket und verknüpfe es mit einer bestimmten Seite“ – stolpert er oft. Er beherrscht vielleicht die Worte, um es zu sagen, aber er bringt die Details falsch an, wie etwa die falsche ID-Nummer in das falsche Feld einzutragen oder zu vergessen, erst zu prüfen, ob das Feld überhaupt existiert.

In dieser Arbeit geht es darum, diesen Bibliothekar zu lehren, den Job tatsächlich zu machen und nicht nur darüber zu reden, indem eine spezifische Trainingsmethode namens RLVR (Reinforcement Learning with Verifiable Rewards) eingesetzt wird.

Hier ist die Aufschlüsselung ihres Experiments in alltagssprachlicher Form:

1. Das Problem: Der „Autopilot“ vs. der „Pilot“

Große Sprachmodelle (LLMs) werden darauf trainiert, Autopiloten zu sein, die das nächste Wort vorhersagen. Sie sind exzellent darin, Geschichten oder E-Mails zu schreiben. Aber in einem Unternehmensumfeld (speziell bei der Nutzung von Atlassian-Tools wie Jira und Confluence) geht es beim Erfolg nicht darum, einen schönen Satz zu schreiben; es geht darum, genau die richtigen Knöpfe in der exakten Reihenfolge mit den exakten Daten zu drücken.

Der alte Weg: Sie bitten die KI: „Erstelle eine Sub-Task.“ Die KI sagt vielleicht: „Okay, ich werde eine Sub-Task erstellen“, aber sie vergisst, sie einer Person zuzuweisen, oder verwendet den falschen Projektcode. Es sieht flüssig aus, aber die Aufgabe schlägt fehl.
Das Ziel: Die Autoren wollten sehen, ob sie die KI dazu bringen können, nicht mehr nur „das nächste Wort zu raten“, sondern wie ein „Pilot“ zu handeln, der vor dem Flug erst die Instrumente überprüft.

2. Die Lösung: Ein „Videospiel“-Trainingsgelände

Anstatt die KI auf den echten, Live-Servern eines Unternehmens üben zu lassen (was riskant und langsam ist), bauten die Autoren einen perfekten digitalen Zwilling (eine Videospiel-Version) der Jira- und Confluence-Systeme.

Der Simulator: Dieses „Spiel“ sieht exakt so aus und funktioniert exakt so wie die echte Software, ist aber sicher. Wenn die KI einen Fehler macht, geht nichts kaputt.
Der Schiedsrichter (Das Belohnungssystem): Dies ist das Geheimrezept. Normalerweise benötigt man einen Menschen, der die Arbeit der KI bewertet. Hier haben sie einen strengen, automatisierten Schiedsrichter gebaut.
- Wenn die KI die richtigen Daten in das richtige Feld setzt? Punkte.
- Wenn die KI prüft, ob eine Seite existiert, bevor sie versucht, sie zu bearbeiten? Bonuspunkte.
- Wenn die KI versucht, ein Werkzeug zu benutzen, das nicht existiert, oder einen erforderlichen Schritt vergisst? Punktabzug.
- Entscheidend: Der Schiedsrichter muss nicht auf den Bildschirm schauen. Er prüft einfach die Mathematik und den Code.

3. Das Training: Versuch und Irrtum

Sie nahmen zwei Versionen einer KI (ein kleineres 1,7B-Modell und ein größeres 4B-Modell) und ließen sie tausende Male in diesem Simulator spielen.

Die KI versucht, eine Aufgabe zu lösen (wie „Erstelle eine Seite“).
Sie scheitert, erhält eine niedrige Punktzahl vom Schiedsrichter und versucht es erneut.
Sie lernt langsam: „Oh, ich habe Punkte bekommen, als ich zuerst die übergeordnete Seite geprüft habe. Ich habe Punkte verloren, als ich den Projektcode vergessen habe.“
Dies ist Reinforcement Learning: Die KI lernt durch Belohnung für gutes Verhalten und Bestrafung für schlechtes Verhalten.

4. Die Ergebnisse: Von „Okay“ zu „Perfekt“

Sie testeten die KI vor und nach diesem Training bei fünf verschiedenen Büroaufgaben.

Vor dem Training: Die KI war bei einfachen Aufgaben ganz ordentlich, aber bei komplexen Aufgaben schlecht. Beispielsweise erhielt die untrainierte KI bei der Erstellung einer neuen Confluence-Seite nur etwa 35 % der Punkte. Sie machte ständig kleine, kostspielige Fehler.
Nach dem Training: Die trainierte KI wurde nahezu perfekt. Bei derselben Aufgabe der Seitenerstellung sprang sie auf 100 %.
Der große Gewinn: Das Training war am effektivsten bei den schwierigsten Aufgaben (denen mit den meisten Regeln und Datenfeldern). Die KI lernte, das strikte „Erst prüfen, dann handeln“-Muster anzuwenden, das von diesen Systemen verlangt wird.

5. Die Kehrseite (Einschränkungen)

Die Autoren sind sehr ehrlich darüber, was dies noch nicht leistet:

Es ist keine Magie für alles: Sie mussten die „Schiedsrichter-Regeln“ für diese spezifischen Aufgaben handgestaltet haben. Man kann dies nicht einfach in jede Software der Welt einspeisen, ohne zuerst einen neuen Schiedsrichter dafür gebaut zu haben. Es ist wie ein Trainer, der zwar fantastisch Fußball lehrt, aber noch nichts über Basketball weiß.
Eine Aufgabe war zu einfach: Für eine spezifische Aufgabe (Änderung des Ticket-Status) war die KI bereits perfekt, sodass das Training keinen Mehrwert bot.

Das Fazrazit

Diese Arbeit beweist, dass man eine Standard-KI nehmen, sie in eine sichere, simulierte Büroumgebung setzen und einen strengen, automatisierten Schiedsrichter nutzen kann, um ihr beizubringen, wie man komplexen Regeln folgt. Dies verwandelt die KI von einem „geschwätzigen Bot“, der gut klingt, aber an den Details scheitert, in einen „zuverlässigen Mitarbeiter“, der die Arbeit perfekt erledigt. Dies erfordert jedoch den Bau eines maßgeschneiderten „Trainingsgyms“ für jede spezifische Art von Software, die sie nutzen soll.

Technisches Resümee: Jenseits der Next-Token-Vorhersage: Ein RLVR-Proof-of-Concept für Tool-Use-Agenten auf Atlassian-Workflows

Problemstellung
Große Sprachmodelle (LLMs) sind fundamental auf die Vorhersage des nächsten Tokens auf Internet-Skala optimiert – ein Ziel, das nicht mit den Anforderungen spezialisierter Enterprise-SaaS-Workflows übereinstimmt. In diesen Umgebungen hängt der Erfolg von der Ausführung spezifischer API-Aufrufe mit präzisen, verschachtelten Argumenten in einer strikten Reihenfolge ab. Das Paper argumentiert, dass sich diese Diskrepanz in Form von „Silent Failures“ (stillen Fehlern) bei Tool-Use-Agenten manifestiert: fehlende Pflichtfelder, Halluzinationen nicht existenter Tools oder vorzeitiger Abbruch nach einer einzigen Leseoperation. Während die bestehende Literatur Tool-Aufrufe mittels Supervised Fine-Tuning oder Reinforcement Learning (RL) auf Open-Web- oder breiten Agentic-Benchmarks adressiert, mangelt es an einem Fokus auf schmale, schema-lastige Enterprise-Workflows, die von „Check-then-Mutate“-Mustern dominiert werden.

Methodik
Die Autoren schlagen einen Proof of Concept vor, der Reinforcement Learning with Verifiable Rewards (RLVR) direkt auf synthetischen, schema-getreuen Kopien von Zielumgebungen anwendet. Dieser Ansatz eliminiert die Notwendigkeit für Live-APIs, gelernte Reward-Judges oder Human-in-the-Loop-Labeling.

Synthetische Umgebungen: Das Team konstruierte fünf synthetische Umgebungen, die die Jira REST v3 und Confluence v2 APIs emulieren. Diese Umgebungen wahren die Schema-Fidelity (entsprechend den öffentlichen Verträgen), sind zustandsbehaftet (stateful), aber zwischen den Rollouts zurücksetzbar, um eine Kontamination zu verhindern, und sind vollständig deterministisch.
Verifizierbare Reward-Funktionen: Anstatt sich auf ein gelernter Reward-Modell zu verlassen, wird die Korrektheit durch programmatische Checker bestimmt, die den Tool-Call-Trace inspizieren. Die Reward-Funktion ( $R \in [0, 1]$ $R \in [0, 1]$ ) ist in drei additive Komponenten zerlegt:
1. Argument-Korrektheit (R1): Kleine Konstanten, die für das Übereinstimmen erwarteter Argumentwerte vergeben werden (z. B. spezifische Projekt-Keys, Parent-IDs).
2. Strukturelle Boni (R2): Belohnungen für das Einhalten des validate–mutate–verify-Musters (z. B. Durchführung eines get_*-Aufrufs vor einem create_*-Aufruf).
3. Strafen (R3): Subtraktionen für destruktives Verhalten, wie etwa fehlende erforderliche Aufrufe, ungültige Payload-Formen, Duplikate oder halluzinierte Tool-Namen sowie das Überschreiten von Call-Budgets.
Trainingsschleife: Die Autoren verwenden Group Relative Policy Optimization (GRPO) auf Qwen3-1.7B und Qwen3.5-4B Modellen. Die Trainingsschleife umfasst das Generieren mehrerer Rollouts pro Prompt, das Bewerten dieser gegen die verifizierbaren Reward-Funktionen und das Aktualisieren der Policy-Parameter. Das Training erfolgt auf moderater Hardware (einzelne oder duale Nvidia RTX PRO 6000 GPUs) und nutzt Early Stopping basierend auf der Reward-Konvergenz.

Zentrale Beiträge

Synthetische Atlassian-Suite: Ein Satz von fünf schema-getreuen Umgebungen, die Jira-Ticket-Transitionen, Sub-Task-Erstellung, Confluence-Seiten-Erstellung, Confluence-Page-Labeling und ein produktübergreifendes Szenario abdecken.
Reward-Design: Ein Framework zur Zerlegung komplexer Tool-Use-Korrektheit in verifizierbare, programmatische Signale (Argument-Matching, strukturelle Ordnung und Strafen-Durchsetzung), die vollständig aus Tool-Call-Traces berechenbar sind.
Baseline und Trainingsergebnisse: Eine umfassende Evaluierung, die gepromptete Baselines (Qwen3-1.7B und Qwen3.5-4B) gegen RLVR-trainierte Policies unter Verwendung identischer Reward-Checker vergleicht.
Trainings-Rezept: Ein End-to-End GRPO-Trainingsrezept, das eine Konvergenz in zehn bis wenigen hundert Generations-Batches auf kleinen Modellen erreicht.

Ergebnisse
Die Studie evaluiert die Leistung in fünf Szenarien und stellt fest, dass das „Ticket-Transition“-Szenario eine Transparenzkontrolle darstellt, bei der die Reward-Funktion sättigt (das gepromptete 4B-Modell erreicht bereits einen perfekten Score).

Leistungssteigerungen: In den vier nicht-degenerierten Szenarien übertrifft die RL-trainierte Policy die geprompteten Baselines signifikant.
- Confluence Page Creation: Die dramatischste Verbesserung, von einem Baseline-Wert von 0,35 auf 1,00 (+0,65).
- Confluence Page Labeling: Verbesserung von 0,52 auf 0,95 (+0,43).
- Jira Sub-task Creation: Verbesserung von 0,68 auf 1,00 (+0,32).
- Cross-Product (Jira + Confluence): Verbesserung von 0,92 auf 1,00, wodurch die verbleibende Lücke geschlossen wurde, um perfekten Rollout-Erfolg bei allen 12 Evaluations-Prompts zu erzielen.
Trainingsdynamik: Die Modelle erreichten einen durchschnittlichen Reward von $\ge 0,95$ innerhalb von 100 Generations-Batches für die From-Scratch-Szenarien. Die Reward-Varianz (Min/Max innerhalb der Generations-Gruppe) kontrahierte während des Trainings, da die Policy aufhörte, Low-Reward-Rollouts zu emittieren.

Bedeutung und Limitationen
Das Paper positioniert diese Arbeit als vorläufigen Proof of Concept, der demonstriert, dass ergebnisoptimierte kleine Modelle mithilfe günstiger, synthetischer Substrate und verifizierbarer Rewards für spezialisierte Enterprise-APIs trainiert werden können.

Die Autoren führen explizit zwei Limitationen an, um Erwartungen zu dämpfen:

Skalierbarkeit des Reward-Designs: Das Hand-Crafting verifizierbarer Rewards skaliert derzeit nicht auf die gesamte Oberfläche der Atlassian Public API oder breitere Enterprise-Ökosysteme; es ist nur für die wenigen berichteten Endpunkte effektiv.
Reward-Sättigung: Ein Szenario (Ticket-Transition) besitzt eine zu einfache Reward-Form, die es dem geprompten 4B-Modell ermöglicht, sofort das Maximum zu erreichen, wodurch RL für diese spezifische Aufgabe unnötig wird.

Die Autoren schließen, dass das Rezept auf diesem spezifischen Substrat zwar funktioniert, aber noch keinen generischen Lösungsansatz für alle Enterprise-Tool-Use-Aufgaben ohne signifikantes manuelles Reward-Engineering etabliert.