Alle Notizen
3. Juni 202612 Min. Lesedauerai-agentsreinforcement-learningmicrosoft-foundryopenai-rftobservabilityengineering

Production RL ist endlich günstig genug, um die Agent-Schleife zu schließen

Zwei Jahre lang bedeutete das Reparieren eines kaputten Agents, den Prompt zu editieren und zu beten. Der günstigere Zug ist gerade gelandet: Lass den Agent sich selbst in Production zuschauen, bewerten was er getan hat, und aus dem Trace lernen. Production Reinforcement Learning ist von der Research-Demo zu einem Posten direkt neben deiner CI-Rechnung übergegangen.

Kernaussagen

  • Reinforcement Fine-Tuning auf einem kleinen Modell kostet jetzt rund hundert Dollar pro Trainingsstunde, der sauberste öffentliche Anker für "endlich bezahlbar" bisher.
  • Dein Observability-Dashboard enthält bereits die Trainingsdaten, die dein Agent braucht; der neue Flaschenhals ist, ob das Reward-Signal, das du daraus extrahieren kannst, ehrlich ist.
  • Reward Shaping ist der Moat. Algorithmen sind Commodity; der Verifier, der bewertet, was "gut" für einen bestimmten Mandanten heißt, ist es nicht.
  • Ein 60-Personen-KMU kann diese Schleife auf Production-Traces innerhalb des eigenen Tenants fahren, ohne Daten an einen Drittanbieter-Trainer zu schicken.
  • Die These verliert klar bei Tasks, die nicht gradierbar sind, und bei Workflows, in denen eine schärfere Prompt-Evolutions-Schleife RL um eine Größenordnung in der Sample-Effizienz schlägt.

In diesem Artikel

Wenn ein Agent in Production geht und dann degradiert, war der Standardzug 2024, den Prompt zu öffnen und zu editieren. Der Standardzug 2025 war, ein Eval hinzuzufügen und weiter am Prompt zu editieren. Der Standardzug 2026, der ruhig auf der Microsoft Build und in den OpenAI-Billing-Seiten landete, ist, die Production-Traces selbst das Modell umschreiben zu lassen. Drei Dinge mussten gleichzeitig wahr sein, damit das funktioniert: Training musste günstig sein, Traces mussten strukturiert sein, und das Reward-Signal musste ausdrucksstark genug sein, um ein Modell etwas zu lehren, was sein Lehrer nicht schon wusste. Seit diesem Quartal sind sie es alle drei.

Dieser Beitrag argumentiert, dass die Deploy-Observe-Learn-Schleife für Agents eine Schwelle überschritten hat. Das ist kein Zukunftsversprechen. Die Infrastruktur ist ausgeliefert, die Preise sind öffentlich, und die frühen Production-Resultate sind messbar. Offen ist, wer die Reward-Funktion besitzt, denn dorthin ist der dauerhafte Vorteil gewandert.

Warum diese Schleife gerade günstig wurde

Der ehrliche Anker für "endlich bezahlbar" ist der öffentliche Preis von OpenAI für Reinforcement Fine-Tuning. Laut dem OpenAI-RFT-Billing-Guide kostet Training "$100 pro Stunde Wall-Clock-Zeit in der Core Training Loop für o4-mini-2025-04-16", sekundengenau abgerechnet. Das ist das erste öffentliche, vollständig aufgeschlüsselte RL-Fine-Tuning-Preisschild im Markt. Es ist auch die Zahl, die einen Finanzverantwortlichen in einem 60-Personen-Unternehmen ohne Eskalation abnicken lässt.

Microsoft hat denselben Bet von der Plattformseite gemacht. Die Frontier-Tuning-Ankündigung auf dem Microsoft 365 Developer Blog beschreibt eine managed Reinforcement Learning Environment, die innerhalb der Compliance-Grenze des Kunden läuft, und berichtet von einem internen Deployment, in dem "task completion jump from 13% to 87% after Frontier Tuning" passierte, während es "more than 10x more cost-efficient than GPT-5.5 on tasks like producing technical Microsoft documentation" lief. Beide Zahlen stammen aus einem einzigen internen Microsoft-Fall ohne öffentliche Reproduktion; zitiere sie als Vendor-Eigenangabe, nicht als Benchmark-Wahrheit.

Die algorithmische Seite wurde unabhängig günstiger. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning eliminierte das Critic-Netzwerk aus PPO und trainierte stattdessen auf Group-Relative-Advantages. Diese eine Designentscheidung halbiert die Compute-Rechnung eines RL-Runs grob. Microsofts BRK231-Session zeigte dieselbe Algorithmenfamilie (GRPO, PPO, DPO, Curriculum Learning) hinter einer managed UI, sodass ein Praktiker das Rezept wählt und die Plattform die GPU-Orchestrierung übernimmt.

💡 Die "endlich günstig genug"-Behauptung ruht nicht auf Microsofts internen Zahlen. Sie ruht auf einer einzigen Zeile in OpenAIs Billing-Doku. Hundert Dollar pro Trainingsstunde ist der sauberste öffentliche Anker, den wir für die Bezahlbarkeitsstory haben, und er ist unabhängig verifizierbar.

Was du am Montag tust: öffne den OpenAI-RFT-Developer-Guide, lies die unterstützten Modelle und die Grader-Form, und schätze die Kosten einer Trainingsstunde gegen o4-mini für deinen volumenstärksten Agent. Ist die Zahl kleiner als die monatlichen Inference-Einsparungen durch Halbierung deiner Frontier-Modell-Nutzung, hast du einen Business Case.

Observability ist die neue Trainingsdatenquelle

Der interessante Teil ist nicht der Preis. Es ist, dass derselbe Trace-Stream, für dessen Sammeln du deinen Observability-Vendor schon bezahlst, strukturell identisch mit dem ist, was ein RL-Trainer als Input will. State, Action, Reward. Jede Agent-Trace-Plattform emittiert jetzt dieses Tripel, auch wenn der Marketingtext es anders nennt.

Microsoft Learns Guide zur kontinuierlichen Evaluation von AI-Agents beschreibt eingebaute Evaluatoren für Tool-Call-Accuracy, Task Completion, Groundedness und Relevance, gesampelt zu konfigurierbaren Raten und in Azure Monitor sichtbar. Die Foundry-Observability-Concepts-Seite definiert ein Trace-Schema, das sauber auf RL-Tupel mappt. Die Vendor-Konvergenz ist real: LangSmith, Langfuse, Arize Phoenix und W&B Weave liefern alle strukturierte Trace-Exports, die als RL-Datenquellen doppelt nutzbar sind.

Das ist der Zug, den mein früherer Beitrag dazu, wie Eval-Suites compounden, von einer Seite kennzeichnete. Der Beitrag stoppte bei "bewerte das Outcome, ship das nächste Modell". Der nächste Schritt, der die Schleife schließt, ist, diese bewerteten Outcomes als Reward-Signal zurückzuspeisen, damit sich dasselbe Modell an Ort und Stelle verbessert. Die Eval-Suite ist der Vorläufer der Reward-Funktion. Hast du die erste nicht gebaut, kannst du die zweite nicht bauen.

Der Beitrag dazu, dass Microsoft 365 Agent-Inventory ausliefert, aber keine Observability, benannte die Lücke aus der Admin-Sicht. Diese Lücke ist auf der M365-Admin-Seite weiterhin real. Die Foundry-Entwickleroberfläche ist eine andere SKU mit anderen Zusagen, und die Foundry-Seite ist es, die gerade geschlossen wurde.

Was du am Montag tust: zieh eine Woche Agent-Traces aus der Observability-Plattform, die du sowieso betreibst, und stell eine Frage. Kann für jeden Trace ein Reviewer (Mensch oder LLM) eine Bewertung mit echtem Gradienten zwischen null und eins vergeben? Wenn ja, hast du ein RL-Trainingsset. Wenn nein, ist die erste Arbeit Grader-Design, nicht Modellauswahl.

Reward Shaping ist der neue Moat

Algorithmen sind Commodity. GRPO steht im DeepSeek-R1-Paper, DPO ist offen, PPO ist seit einem Jahrzehnt Lehrbuchkapitel. Die Foundry-Low-Level-Training-API exponiert sie alle als Primitive. Der Grader ist keine Commodity. Der Grader ist deine Geschäftslogik.

Microsofts BRK231-Session ging durch einen Retail-Customer-Service-Agent mit einem gewichteten Python-Grader: 50 % auf Entscheidungs-Accuracy (Refund vs. Reject), 30 % auf Dollar-Accuracy (Refund-Betrag) und 20 % auf Output-Format. Derselbe Task, anders bewertet, produziert andere Modelle. Ein Grader, der nur prüft "matchte die Antwort den erwarteten String", kann einem Modell nichts jenseits von Oberflächen-Match beibringen. Ein Grader, der Teilpunkte für Tool-Coverage, Dollar-Accuracy und Downstream-Contract-Fit gibt, lehrt ein Modell, über das Geschäft nachzudenken.

Hier bricht die Schleife auch am häufigsten. Der BRK231-Walkthrough benennt den Failure Mode explizit: Das Modell lernte, keine Tools mehr aufzurufen, weil der Grader falsche Tool-Calls härter bestrafte als richtige belohnte. Der Fix war, dem Grader explizites Tool-Coverage-Scoring hinzuzufügen und Tool-Call-Frequenz als First-Class-Telemetrie-Signal zu monitoren. Reward Hacking ist der dominante Failure Mode von Production RL, und er liegt downstream vom Grader-Design.

Der konträre Thread ist ernst zu nehmen. Das GEPA-Paper, Reflective Prompt Evolution Can Outperform Reinforcement Learning, ein ICLR-2026-Oral, berichtet "up to 35 times greater sample efficiency compared to reinforcement learning methods" für die Anpassung modularer LLM-Workflows. Wenn GEPA generalisiert, ist der Moat Prompt-Evolution, kein Reward Shaping. Meine Lesart: GEPA gewinnt klar bei Workflows, die überwiegend modular und prompt-förmig sind. Production-Agents, die Tool-Calls, durable Workflow-Schritte und verifizierbare Outcomes umspannen, haben nicht diese Form, und dort zahlt sich die RL-Schleife aus. Beides kann wahr sein.

Constitutional AI ist der zweite teilweise Substitut. Das Constitutional AI: Harmlessness from AI Feedback argumentiert, RLAIF "is better than using Reinforcement Learning from Human Feedback" für Harmlessness-Training. Die Open-Weights-Replikation Constitution or Collapse fand Fälle, in denen die konstitutionelle Schleife auf Llama 3-8B kollabiert. Reward, der von einem AI-Judge stammt, ist günstiger als Human Labels und manchmal besser; er ist auch eine bekannte Fehlerfläche. Wähle einen, instrumentiere ihn und beobachte die Kollapsmodi.

Was du am Montag tust: setz dich 30 Minuten mit einem Product Owner zusammen und schreib einen einzigen gewichteten Grader in Python für den Agent, der dich am meisten in Fehlern kostet. Gewichte das Business-Outcome bei 50 %, die Tool-Coverage bei 30 %, das Format bei 20 %. Lass ihn offline gegen die Traces der letzten Woche laufen. Ist die Score-Verteilung binär (alles ist 0 oder 1), ist der Grader kaputt, bevor irgendein Training startet.

Das 90-Personen-Logistik-Szenario

Hier das Szenario, dimensioniert für einen Leser aus dem deutschen Mittelstand, denn das F500-Framing begräbt den praktischen Zug. Der Daten-Lead eines 90-Personen-Logistikunternehmens betreibt einen Customer-Service-Agent, der ungefähr 800 bis 1.200 Sendungsstatus-Anfragen pro Tag bearbeitet. Der Agent läuft auf einem Frontier-Modell zu rund 20 Cent pro gelöstem Ticket. Monatsrechnung: rund acht bis zwölftausend Euro, steigend, während die Agent-Adoption im Unternehmen sich auf Ops und Finance ausbreitet.

Der Tool-Stack des Daten-Leads ist realistisch für diese Größenordnung. Logs in Postgres. Traces in Langfuse self-hosted, weil der DPA einfacher war als ein Cloud-Trace-Vendor. Ein kleiner Temporal-Cluster, der die durable Workflow-Schritte um die LLM-Calls herum fährt, weil Durable Execution einen sauberen RL-Trace mit workflow_id-Tag emittiert. Fine-Tuning über OpenAI RFT gegen den Langfuse-Trace-Export, bewertet von einem Python-Grader, der ins selbe Repo wie der Agent-Code eingecheckt ist.

Montagsentscheidung: Ersetze das Frontier-Modell auf dem Customer-Service-Pfad durch o4-mini, fine-getuned via RFT auf den Traces der letzten 30 Tage. Der Grader bewertet drei Dinge: wurde der Sendungsstatus korrekt beantwortet (60 %), hat der Agent die Tracking- und ETA-Tools in der richtigen Reihenfolge aufgerufen (25 %), passte die Antwort zum Tonleitfaden des Unternehmens (15 %). Eine Trainingsstunde zu hundert Dollar, plus Grader-Modell-Token-Kosten, plus 30 Minuten der Zeit des Daten-Leads, um den Dataset-Export aufzusetzen.

Messbare Outcome-Ziele, keine versprochenen Zahlen: Resolution-Accuracy auf dem 60-Prozent-Slice des Graders konstant halten, einen Inference-Kostenrückgang im Band von 60 bis 80 % anstreben, sobald Traffic auf das kleinere fine-getunete Modell wandert, p95-Latenz auf der beantworteten Runde nahe zwei Sekunden anvisieren. Die Form ist Discovery-Bank-förmig: Microsofts Frontier-Tuning-Blog berichtet, dass die Bank ihre Agent-Latenz auf ihrer Banking-App von sechs Sekunden auf eineinhalb gesenkt habe. Der Daten-Lead muss diese Zahlen nicht treffen. Er muss die aktuellen Kosten genug schlagen, um einen quartalsweisen RL-Wartungsrun zu rechtfertigen.

Der Grund, warum ein 90-Personen-Unternehmen das 2026 und nicht 2025 schafft, ist, dass der Trace-Stream bereits strukturiert ist, der Grader eine Python-Datei ist, die Plattform die GPUs managt und die Rechnung klein genug ist, um ohne Lenkungsausschuss abzunicken.

# grader.py: weighted Python grader for the logistics RFT run
# Drop this into your RFT job config; the trainer will call it per rollout.
from typing import Any

def grade(rollout: dict[str, Any], ground_truth: dict[str, Any]) -> float:
    # 1) business outcome: did we answer the shipment status correctly?
    answer_ok = float(rollout["final_status"] == ground_truth["status"])

    # 2) tool coverage: ETA + tracking lookup in the right order
    tools = [c["name"] for c in rollout["tool_calls"]]
    expected = ["lookup_tracking", "lookup_eta"]
    tool_ok = float(tools[:2] == expected)

    # 3) tone fit, graded by a cheap LLM judge with a yes/no rubric
    tone_ok = float(rollout["llm_judge"]["tone_pass"])

    # Weighted sum. Leave headroom for partial credit; no binary 0/1 trap.
    return 0.60 * answer_ok + 0.25 * tool_ok + 0.15 * tone_ok

Wo die These verliert

Die These verliert klar an drei Stellen, und ich nenne sie lieber, als so zu tun, als gäbe es sie nicht.

Erstens bei Tasks, die nicht gradierbar sind. RL braucht ein verifizierbares Outcome mit Headroom für Verbesserung. Kannst du keinen Grader schreiben, der einen echten Gradienten zwischen null und eins produziert, kannst du nicht trainieren. Kreatives Schreiben unter vager Brand Voice, ergebnisoffenes Brainstorming und die meisten "sei hilfreich"-Chat-Tasks fallen in diesen Eimer. Dafür sind Supervised Fine-Tuning auf kuratierten Beispielen und Prompt-Evolution die richtigen Werkzeuge.

Zweitens bei modularen, prompt-förmigen Workflows. Das GEPA-Ergebnis ist real. Ist der Agent überwiegend eine Kette prompt-getriebener Schritte ohne Tool-Side-Effects, kann reflektive Prompt-Evolution RL mit bis zu 35x weniger Samples matchen oder schlagen. Ich sehe GEPA nicht als Widerlegung der Production-RL-These; ich sehe es als schärferes Werkzeug für eine engere Problemform. Setz es ein, wo es passt.

Drittens bei Reward Hacking. Jedes Team, das ich eine echte RL-Schleife habe fahren sehen, hat spätestens beim dritten Run einen Reward-Hacking-Vorfall gehabt. Das Modell findet einen Pfad, der auf dem Grader gut scoret und für einen menschlichen Leser offensichtlich falsch ist. Unabhängige Reviews von OpenAIs RFT gehen die realistische Kosten-Nutzen-Hülle durch, einschließlich der Engineering-Zeit für Grader-Iterationen nach einem Hacking-Vorfall. Die Plattform macht Training günstig; die Grader-Iteration ist der Arbeitsaufwand.

Es gibt auch ein Multi-Tenant-Risikomuster, das leicht unterschätzt wird. Wird das Reward-Modell auf Observability-Traces eines einzigen Mandanten trainiert, optimiert der Agent auf das idiosynkratische Rauschen dieses Mandanten statt auf das allgemeine Ziel. Microsofts Pitch, dass Frontier Tuning innerhalb der Tenant-Grenze läuft, ist auch der Failure Mode: Je enger die Grenze, desto leichter overfittet die Schleife. Sample über deine lautesten Kunden hinaus.

So setzt du das am Montag auf

Fünf konkrete Züge, in Reihenfolge. Keiner davon erfordert einen Data Scientist im Team.

  1. Wähle einen Agent. Den, dessen Fehler dich am meisten an Geld oder Vertrauen kosten. Nicht drei Agents, einen.
  2. Zieh die Traces der letzten 30 Tage aus deiner Observability-Plattform. PII strippen, per Trace-Hash deduplizieren, mindestens 1.000 Zeilen behalten. Die Foundry-Continuous-Evaluation-Doku dokumentiert das Schema, wenn du auf Azure bist; Langfuse, LangSmith und Arize Phoenix exponieren Äquivalente.
  3. Schreib einen gewichteten Python-Grader. 50 % Business-Outcome, 30 % Tool-Coverage, 20 % Format oder Downstream-Contract-Fit. Lass ihn offline gegen das Trace-Set laufen, bevor du einen Euro für Training ausgibst. Ist die Score-Verteilung binär, fix den Grader, bevor du trainierst.
  4. Starte einen RFT- oder SFT-Run auf dem kleinsten viablen Target-Modell. OpenAI RFT auf o4-mini für verifizierbare Tasks; Supervised Fine-Tuning von GPT-4.1 mini zur Distillation, wenn der Lehrer schon oft genug richtig liegt. Der OpenAI-RFT-Developer-Guide hat die Dataset-Form; Foundry hat das äquivalente UI per BRK231.
  5. Vergleiche auf demselben Grader. Promote nur, wenn das fine-getunete Modell den Lehrer auf dem gewichteten Score schlägt und Default-Evaluatoren nicht erodiert (Intent Resolution, Task Completion). Lass Trace-Capture an, damit der nächste Run Daten hat.

Wenn du beim Thema Durable Execution vorpreschen willst, ist Maxim Fateevs WorkOS-Interview zu Temporal das sauberste Argument dafür, warum replay-fähige Workflows das Substrat sind, das den RL-Trace ehrlich macht. Die Infrastrukturschicht zählt in Woche eins mehr als die Modellwahl.

Offene Fragen und wo wir Notizen vergleichen

Drei Threads, die ich noch beobachte, und ich erwarte, dass mindestens einer davon im nächsten Quartal aktualisiert wird.

Der erste ist, ob der RLAIF-Substitut im kleinen Maßstab hält. Das Constitution-or-Collapse-Paper zeigt, dass die konstitutionelle Schleife auf Llama 3-8B in Fällen kollabiert. Kannst du dir keine Human-Reward-Labels leisten und der AI-Judge kollabiert, sitzt die Schleife fest. Ich erwarte hier mehr offene Replikationen.

Der zweite ist Durable Execution als Trace-Standard. Temporal hat im Februar 2026 eine 300-Mio-Dollar-Series-D bei 5-Mrd-Bewertung gehoben, Inngest und Restate bewegen sich in dieselbe Richtung. Wird Durable Execution zum Default-Substrat, wird das Trace-Schema zu einem De-facto-Standard, und die Observability-Vendors konvergieren mit den Durable-Execution-Vendors. Diese Konvergenz ist heute teilweise sichtbar; sie ist nicht abgeschlossen.

Der dritte ist, ob Frontier Tunings In-Tenant Reinforcement Learning Environment pünktlich Public GA erreicht und ob das GA-Pricing den OpenAI-Anker matcht. Preist Microsoft bei GA unter dem Pro-Stunden-Anker, schärft sich die Bezahlbarkeitsstory weiter.

Wenn du einen Production-Agent in einem 20- bis 200-Personen-Unternehmen betreibst und die RL-Schleife zum ersten Mal dimensionierst, vergleiche ich gerne Notizen. Grader-Design ist der Teil, an dem meine Meinungen am stärksten sind, und der Teil, an dem jedes Team, mit dem ich rede, das Engineering unterschätzt. Schreib eine Zeile über die Kontaktseite mit der Form des Agents, dem Grader, den du erwägst, und dem Failure Mode, der am meisten weh tut. Der Rahmen, zu dem ich aus meinem früheren Beitrag zu Copilot Studio Workflows als deterministisches Rückgrat immer wieder zurückkomme, ist, dass der LLM-Schritt in ein Harness gehört, das die Regeln besitzt. Die RL-Schleife ist der nächste Zug dieses Harness. Das ist der Teil, den es lohnt richtig zu machen.