🤖 AI

OR-Space: A Full-Lifecycle Workspace Benchmark for Industrial Optimization Agents

Het artikel introduceert OR-Space, een benchmark voor werkruimtes met een volledige levenscyclus die is ontworpen om industriële optimalisatie-agenten te evalueren op realistische, meerstaps taken die modelconstructie, revisie en onderbouwde uitleg omvatten binnen persistente, multi-artifact-omgevingen, en zo verder gaat dan traditionele beoordelingen van eenmalige probleemformuleringen.

Oorspronkelijke auteurs: Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

Gepubliceerd 2026-05-28

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een briljante nieuwe assistent inhuurt om een fabriek te helpen runnen. Je wilt zien of ze de baan daadwerkelijk kunnen uitvoeren, en niet alleen erover kunnen praten.

Lange tijd was de manier waarop we deze AI-assistenten (zogenaamde "LLM-agents") testten, als het geven van hen een perfect geschreven receptkaart. De kaart zei: "Hier is het probleem, hier zijn de ingrediënten, hier is de wiskundige formule. Schrijf nu de code om het op te lossen."

Als de AI de code correct schreef, gaf men haar een gouden ster. Maar in de echte wereld krijgen fabrieksmanagers geen perfecte receptkaarten. Ze krijgen een rommelig bureau met post-its, spreadsheets, oude code van vorig jaar en e-mails van de baas met de boodschap: "Oh, trouwens, we moeten de regels voor volgende maand aanpassen."

OR-Space is een nieuwe, veel moeilijkere test die ontworpen is om te zien of AI die rommelige, echte bureau-omgeving aankan.

De Drie Manieren waarop we de AI Testen

Het artikel introduceert een benchmark genaamd OR-Space (Operations Research Space). In plaats van één vraag, geeft het de AI een hele "werkruimte" (een digitale map met bestanden) en vraagt het haar om drie verschillende soorten taken uit te voeren die in een echte fabriek voorkomen:

Bouwen (De Architect):
- Het Scenario: Je geeft de AI een map met een zakelijk memo, een spreadsheet met cijfers en een leeg codebestand.
- De Taak: De AI moet het memo lezen, uitzoeken wat de cijfers betekenen, en een gloednieuw computerprogramma schrijven om het probleem van de fabriek vanaf nul op te lossen.
- De Vreemde: Het memo kan vaag zijn, en de spreadsheet kan rommelige kolommen hebben. De AI moet de punten verbinden tussen de tekst en de data zonder een perfecte leidraad.
Herzien (De Reparateur):
- Het Scenario: De fabriek is van gedachten veranderd. Misschien hebben ze nu meer vrachtwagens, of een nieuwe regel over veiligheid. De AI krijgt het oude programma en de nieuwe regels.
- De Taak: De AI moet de oude code updaten om te passen bij de nieuwe regels, zonder de delen die al werkten, kapot te maken.
- De Vreemde: Dit is als proberen een huis te renoveren terwijl er nog mensen in wonen. Als de AI een variabele-naam uit de oude code kopieert die niet meer logisch is, crasht het hele systeem. Het artikel vond dat sommige AI's in de war raken door de oude code en proberen de fouten ervan te kopiëren, terwijl slimmere AI's weten wat ze moeten behouden en wat ze moeten weggooien.
Uitleggen (De Vertaler):
- Het Scenario: De computer heeft het probleem opgelost, maar de fabrieksmanager (die geen wiskunde-expert is) vraagt: "Waarom heb je besloten om 5 vrachtwagens naar het noordelijke magazijn te sturen in plaats van naar het zuidelijke?"
- De Taak: De AI moet naar de oplossing, de code en de datalogboeken kijken om een waarheidsgetrouw antwoord te geven.
- De Vreemde: De AI kan niet zomaar een verhaal verzinnen. Ze moet verwijzen naar de specifieke regel in de spreadsheet of de specifieke regel in de code die die beslissing af dwong. Als ze gokt, verliest ze punten.

Waarom deze Test Anders is (De "Werkruimte" versus de "Prompt")

De auteurs betogen dat eerdere tests als flitskaarten waren. Je toont de AI een schoon, geïsoleerd probleem, en ze geeft een antwoord.

OR-Space is als een echt kantoor.

De Bestanden zijn Gescheiden: De eisen staan in een Word-document, de cijfers in een CSV-bestand en de code in een Python-bestand. De AI moet ze allemaal openen, lezen en beseffen hoe ze bij elkaar passen.
Het "Grounding"-Probleem: Bij een flitskaarttest kan de AI het juiste antwoord raden omdat ze de woorden herkent. In OR-Space faalt de AI als ze het woord "capaciteit" in het memo niet correct koppelt aan de kolom "max_load" in de spreadsheet. Het artikel noemt dit "grounding" – het verbinden van woorden met de feitelijke data.

Wat ze Vonden (De Resultaten)

De onderzoekers testten 20 verschillende AI-modellen (de "slimste" die beschikbaar waren) op deze nieuwe test. Dit is wat er gebeurde:

Het is Moeilijker dan het Lijkt: Zelfs de beste AI's hadden moeite. Hoewel sommige het "flitskaart"-versie van het probleem konden oplossen, faalden ze vaak wanneer ze de rommelige map met bestanden moesten navigeren.
Oude Code is een Dubbelzinnig Zwaard: Toen de AI oude code kreeg om het model te helpen herzien, werden de slimste AI's beter omdat ze de oude code gebruikten als een nuttige hint. Maar de zwakkere AI's werden slechter omdat ze blind de fouten van de oude code kopieerden (zoals het proberen te gebruiken van een variabele die niet meer bestond).
De "Uitleg"-Kloof: Sommige AI's waren geweldig in het schrijven van code, maar vreselijk in het uitleggen ervan. Ze konden de wiskunde oplossen, maar konden je niet vertellen waarom ze die keuze maakten op basis van de bestanden die ze hadden.
De "Bestandssysteem"-Boete: Het artikel vond dat wanneer AI's daadwerkelijk mappen moesten navigeren en bestanden moesten lezen (de "Filesystem"-modus), ze slechter presteerden dan wanneer dezelfde informatie gewoon in één groot tekstblok was geplakt. Dit bewijst dat het vinden en ordenen van informatie op zichzelf een vaardigheid is, en niet slechts een opmaakprobleem.

De Conclusie

Het artikel concludeert dat we AI niet alleen kunnen testen op hoe goed ze code schrijft vanuit een perfecte prompt. Om nuttig te zijn in echte industrieën (zoals logistiek, productie of financiën), moet AI getest worden op haar vermogen om:

De juiste informatie te vinden in een rommelige stapel documenten.
Oude systemen bij te werken zonder ze kapot te maken.
Haar beslissingen te verklaren met bewijs uit de feitelijke bestanden, en niet alleen verzonden verhalen.

OR-Space is de nieuwe "rijtest" voor deze AI-agents, die hen verplaatst van de parkeerplaats (perfecte prompts) naar de drukke stadsstraten (echte werkruimtes).

Technische Samenvatting: OR-Space

Probleemstelling

Bestaande benchmarks voor Large Language Model (LLM)-agenten in Operations Research (OR) abstraheren grotendeels de complexiteit van real-world industriële workflows. Huidige evaluaties reduceren OR-taken doorgaans tot "one-shot" problemen waarbij een agent een zelfstandige tekstuele prompt vertaalt naar een wiskundige formulering of solver-code. Deze aanpak faalt in het vastleggen van twee bepalende kenmerken van industriële OR:

De Werkruimte-omgeving: Real-world agenten opereren binnen persistente, multi-artifact-omgevingen die zakelijke vereisten, gestructureerde data (CSV/JSON), code-artifacten, solver-feedback en interacties met belanghebbenden bevatten, verspreid over meerdere bestanden.
De Levenscyclus-omgeving: Industriële OR is iteratief. Ingenieurs genereren niet slechts één keer een oplossing; ze bouwen initiële modellen, herzien deze als reactie op veranderende zakelijke regels of solver-feedback, en leggen de resulterende beslissingen uit aan niet-expert belanghebbenden.

Bijgevolg kunnen huidige benchmarks niet bepalen of een agent betrouwbaar optimalisatiewerk kan uitvoeren binnen een multi-artifact-werkruimte en door meerdere fasen van de modelleringstcyclus heen.

Methodologie

De auteurs introduceren OR-Space, een benchmark voor de volledige levenscyclus van een werkruimte, ontworpen om industriële optimalisatie-agenten te evalueren. De methodologie is gestructureerd rond twee kernassen: een persistente uitvoerbare werkruimte en een op levenscyclus gerichte taakpijplijn.

1. Formalisering van de OR-werkruimte

Een OR-werkruimte ( $W$ ) wordt gedefinieerd als een gestructureerde, persistente, uitvoerbare omgeving:
$W = \langle D, P, S, E, M \rangle$

$D$ (Documenten): Natuurtaalkundige artifacten (bijv. business_requirement.md) die doelen en vereisten beschrijven.
$P$ (Parameters): Gestructureerde databestanden (CSV, JSON) met numerieke invoer, die vaak reiniging en schema-afstemming vereisen.
$S$ (Code): Code-artifacten, waaronder heuristische scripts, gedeeltelijke sjablonen of legacy-implementaties.
$E$ (Omgeving): Een Docker-gebaseerde sandbox die bestands-I/O, solver-uitvoering (Gurobi, COPT, PuLP, HiGHS) en resource-beperkingen ondersteunt.
$M$ (Metriek): De evaluatiemetriek (verborgen voor de agent) die wordt gebruikt door de benchmark-harnas.

In tegenstelling tot eerdere benchmarks die alle context serialiseren in één enkele prompt, vereist OR-Space dat agenten informatie lokaliseren, verbinden en verankeren over deze verspreide artifacten heen.

2. Op levenscyclus gerichte taakmodi

OR-Space definieert drie sequentiële taakmodi, afgeleid van 100 basisproblemen (uitgebreid vanuit de IndustryOR-benchmark):

Bouwen ( $T_{Build}$ ): De agent bouwt een solver-klaar optimalisatiemodel vanaf de grond op, gebruikmakend van zakelijke documenten en data-bestanden, beginnend bij een leeg codeschavet.
Herzien ( $T_{Revise}$ ): De agent past een bestaande optimalisatieworkflow aan onder bijgewerkte vereisten. Dit omvat varianten zoals Revise-code (aanpassen van legacy-code), Revise-model (alleen de formulering aanpassen) en Revise-all. De agent moet geldige eerdere logica behouden terwijl nieuwe constraints of variabelen worden geïntegreerd.
Uitleggen ( $T_{Explain}$ ): De agent beantwoordt verankerde vragen over oplossingen, constraints en zakelijke implicaties met behulp van bewijs verspreid over documenten, data, code en solver-outputs (bijv. duale variabelen, slack-waarden).

3. Evaluatieprotocol

Bouwen & Herzien: Geëvalueerd via door de solver gescoorde metrieken. Een indiening is correct als deze zonder fouten wordt uitgevoerd, een "Optimal"-status retourneert en een relatieve objectieve fout $\le 1\%$ behaalt ten opzichte van een ground-truth oracle.
Uitleggen: Geëvalueerd met een verankerde "LLM-as-judge"-rubriek. Scores zijn gebaseerd op Exacte Dekking (35%), Redenering (35%), Verankering (20%), Antwoordkwaliteit (10%) en een Hallucinatieboete (tot -12).
Foutanalyse: Het framework logt specifieke foutmodi, waaronder uitvoeringsfouten, onhaalbare formuleringen, incorrecte doelstellingen en ontrouwe uitleggen.

Belangrijkste Bijdragen

Identificatie van Beperkingen: Het artikel identificeert dat bestaande OR-benchmarks lijden aan zelfstandige werkruimte-instellingen en single-shot-taakinstellingen, wat de multi-artifact- en levenscyclus-georiënteerde aard van real-world industriële workflows onderschat.
OR-Space Benchmark: Een nieuwe benchmark opgebouwd rond persistente uitvoerbare werkruimten waar vereisten, data, code en solver-outputs verspreid zijn over meerdere bestanden.
Taakmodi: De definitie van drie op levenscyclus gerichte modi (Bouwen, Herzien, Uitleggen) die modelconstructie, onderhoud en communicatie vastleggen.
Evaluatiekader: Een protocol voor het analyseren van agentcapaciteiten en foutmodi in op werkruimte-gebaseerde taken, inclusief dataverankering, revisieconsistentie en trouw van uitleg.

Resultaten

De auteurs evalueerden 20 modellen (gesloten-bron frontlijn, kleine API-gebaseerde en open-source) over de benchmark. Belangrijkste bevindingen zijn:

Werkruimte-verankering is moeilijk: Zelfs frontlijn-agenten worstelen met modelconstructie die verankerd is in de werkruimte. De beste Build-score was 72,0% (gemini-3.1-pro), met de meeste frontlijnmodellen in het bereik van 53–68%. Dit onderstreept de moeilijkheid om dataschema's en zakelijke semantiek te herstellen uit verspreide artifacten in vergelijking met schone prompts.
Legacy-code als signaal versus ruis: In de Revise-taak verbeterden sterke modellen (bijv. gpt-5.4, claude-opus-4-6) vaak hun prestaties door legacy-code als signaal te benutten (bijv. verbeterde gpt-5.4 van 59% naar 79%). Omgekeerd leden zwakkere of "flash"-modellen vaak aan prestatiedalingen (bijv. daalde gemini-3-flash met 23 procentpunten), wat suggereert dat ze implementatiedetails als ruis behandelden of niet-solver-imports kopieerden.
Uitlegbaarheid is distinct: De prestatie in Explain was zwak gecorreleerd met Build- en Revise-scores ( $r \approx 0,16-0,28$ ). Sommige modellen die uitvoerbare modellen bouwden, faalden om deze trouw uit te leggen (bijv. gemini-2.5-pro loste 69% van de Revise-instanties op, maar scoorde slechts 32,2 op Explain).
Interface-impact: Het gebruik van een bestandssysteem-interface (in plaats van een flat-prompt-serialisatie) verlaagde over het algemeen de prestaties in code-generatietaken (Bouwen en Herzien) met gemiddeld respectievelijk 8,2 en 12,2 procentpunten. Dit geeft aan dat bestandsontdekking en schema-inspectie substantiële moeilijkheden zijn, en niet louter cosmetische.
Contextgevoeligheid: Het toevoegen van formele formuleringen aan de code-context hielp over het algemeen sterke modellen, maar kon lichtgewicht modellen schaden. Formulering-only context bleek brozer dan op code gebaseerde context.

Betekenis en Claims

Het artikel positioneert OR-Space als een noodzakelijke verschuiving in evaluatieparadigma's van geïsoleerde tekstgeneratie naar robuuste, door solvers verankerde engineering-workflows. De auteurs claimen dat:

Betrouwbaarheidskloof: Het navigeren door een open, multi-artifact-werkruimte voor huidige LLM-agenten nog steeds uiterst uitdagend blijft, wat systemische fouten blootlegt in data-mapping en constraint-verankering die tekst-only benchmarks grotendeels verbergen.
Praktische Klaarheid: OR-Space biedt een rigoureuze basis voor het meten van de praktische klaarheid van optimalisatie-agenten door de iteratieve, multi-stap aard van industriële OR te simuleren.
Foutmodi: De benchmark maakt fijne attributie van fouten mogelijk, waarbij onderscheid wordt gemaakt tussen wiskundige modelleringfouten, data-verankeringsfouten en gehallucineerde constraints, wat cruciaal is voor het inzetten van agenten in real-world omgevingen.

Het werk concludeert dat hoewel LLM's veelbelovend zijn in geïsoleerde formuleringstaken, hun vermogen om betrouwbaar OR-engineering uit te voeren over een persistente werkruimte en volledige levenscyclus momenteel beperkt is, wat verdere research vereist naar agent-betrouwbaarheid, foutmodi en interactie met de werkruimte.