ORAgentBench zeigt, wie unsicher KI-Agenten noch planen

Worum es geht

Ein neues Paper mit dem Namen ORAgentBench testet, ob LLM-Agenten echte Operations-Research-Aufgaben von Anfang bis Ende lösen können. Die Antwort ist nuechtern: Noch nicht verlaesslich. Die beste getestete Agenten-Konfiguration bestand nur 35,51 Prozent aller Aufgaben und 20,59 Prozent der schweren Aufgaben.

Das macht die Arbeit interessanter als viele Modellankuenigungen. Sie fragt nicht, ob ein Agent schoen klingenden Optimierungscode schreiben kann. Sie fragt, ob er aus unordentlichen Arbeitsunterlagen eine gueltige, gepruefte und brauchbar gute Entscheidung erzeugt.

Was ORAgentBench tatsaechlich macht

Operations Research ist die Disziplin hinter Tourenplanung, Schichtplanung, Lagersteuerung, Produktionsreihenfolgen und aehnlichen Optimierungsproblemen. In der Praxis sind diese Aufgaben selten sauber als fertige Mathematik formuliert. Sie liegen als Tabellen, Textregeln, Nebenbedingungen, Datenordner und Zielkonflikte vor.

ORAgentBench packt 107 von Menschen gepruefte Aufgaben in isolierte Umgebungen. Jede Aufgabe enthaelt eine natuerliche Beschreibung, mehrere Dateien, Konfigurationsartefakte und ein gefordertes Abgabeschema. Der Agent muss Loesungscode schreiben, ausfuehren und ein Ergebnis liefern. Versteckte Validatoren prüfen anschliessend Schema, harte Nebenbedingungen und normalisierte Loesungsqualitaet.

Warum das wichtig ist

Viele Unternehmen wollen Agenten nicht nur für E-Mails oder Code-Vervollstaendigung einsetzen, sondern für Entscheidungen: Welche Maschine läuft zuerst, welche Lieferung geht auf welchen Lkw, welcher Techniker faehrt welche Route? Genau dort wird es teuer, wenn ein Agent fast richtig liegt.

Die Zahlen aus ORAgentBench sind deshalb ein Realitaetscheck. Ein Agent, der ein paar Demo-Aufgaben löst, ist noch kein Planungswerkzeug für Fabrik, Klinik, Lager oder Energiehandel. Besonders wichtig ist die Fehleranalyse: Die Probleme lagen nicht nur in Syntax oder Solver-Aufrufen. Viele Fehler waren strategisch: uebersehene Betriebsregeln, bruechige Modellierungen, schwache Konstruktion gueltiger Lösungen und zu wenig Verbesserung nach der ersten machbaren Antwort.

Einfach erklaert

Stell dir vor, jemand soll einen Koffer für eine Familie packen: Gewichtslimit, Wetter, Medikamente, Kleidung für drei Tage, keine Fluessigkeiten über 100 Milliliter. Ein Sprachmodell kann vielleicht eine schoen klingende Packliste schreiben. ORAgentBench fragt aber: Passt wirklich alles hinein, bleibt das Gewicht unter der Grenze, fehlen keine Medikamente, und ist die Liste besser als eine zufaellige Notloesung?

Das ist der Unterschied zwischen plausibel reden und eine Entscheidung treffen, die im Alltag funktioniert.

Praktisches Beispiel

Ein Lager verschickt taeglich 10.000 Pakete. Ein Agent bekommt CSV-Dateien mit Bestellungen, Lkw-Kapazitaeten, Sperrzeiten, Prioritaeten und regionalen Regeln. Er soll nicht nur Python-Code ausgeben, sondern eine Versandplanung, die alle harten Regeln einhaelt und moeglichst wenig Verspaetung erzeugt.

Wenn der Agent eine Regel uebersieht, etwa dass Gefahrgut nicht mit bestimmten Artikeln kombiniert werden darf, kann die Lösung formal gut aussehen und trotzdem unbrauchbar sein. ORAgentBench bewertet genau solche Faelle strenger als reine Textbenchmarks.

Einordnung und Grenzen

Erstens ist ORAgentBench ein Benchmark, kein Produkt. Er zeigt Lücken, liefert aber nicht automatisch eine fertige Lösung für Planungssysteme.

Zweitens sind die Ergebnisse modell- und promptabhaengig. Neue Agenten, bessere Tools oder speziell trainierte OR-Workflows können die Werte verändern.

Drittens misst der Benchmark definierte Aufgaben in isolierten Umgebungen. Reale Unternehmen haben zusaetzlich Legacy-Systeme, unvollstaendige Daten, Verantwortungsfragen und Sicherheitsgrenzen.

SEO- und GEO-Schluesselbegriffe

ORAgentBench, LLM agents, operations research, AI benchmarks, autonomous agents, scheduling, logistics optimization, supply chain AI, agent evaluation, decision automation, enterprise AI, arXiv