Riepilogo Tecnico: OR-Space

Enunciato del Problema

I benchmark esistenti per gli agenti di Modelli Linguistici di Grande Dimensione (LLM) nell'ambito della Ricerca Operativa (OR) astraggono in larga misura le complessità dei flussi di lavoro industriali reali. Le valutazioni attuali riducono tipicamente i compiti di OR a problemi "one-shot", in cui un agente traduce un prompt testuale autosufficiente in una formulazione matematica o in codice per un solver. Questo approccio non riesce a catturare due caratteristiche definitorie dell'OR industriale:

1. L'Ambiente di Lavoro (Workspace Setting): Gli agenti reali operano all'interno di ambienti persistenti e multi-artifatto contenenti requisiti aziendali, dati strutturati (CSV/JSON), artefatti di codice, feedback dei solver e interazioni con gli stakeholder distribuiti su più file.
2. L'Ambiente del Ciclo di Vita (Lifecycle Setting): L'OR industriale è iterativo. Gli ingegneri non generano una soluzione una sola volta; costruiscono modelli iniziali, li revisionano in risposta a regole aziendali in cambiamento o feedback dei solver, e spiegano le decisioni risultanti a stakeholder non esperti.

Di conseguenza, i benchmark attuali non possono determinare se un agente sia in grado di svolgere lavori di ottimizzazione affidabili attraverso un ambiente di lavoro multi-artifatto e attraverso più fasi del ciclo di vita della modellazione.

Metodologia

Gli autori introducono OR-Space, un benchmark di ambiente di lavoro a ciclo completo progettato per valutare gli agenti di ottimizzazione industriali. La metodologia è strutturata attorno a due assi fondamentali: un ambiente di lavoro eseguibile persistente e una pipeline di compiti orientata al ciclo di vita.

1. Formalizzazione dell'Ambiente di Lavoro OR

Un ambiente di lavoro OR ($W$) è definito come un ambiente strutturato, persistente ed eseguibile:
$$W = \langle D, P, S, E, M \rangle$$

• $D$ (Documenti): Artefatti in linguaggio naturale (es. business_requirement.md) che descrivono obiettivi e requisiti.
• $P$ (Parametri): File di dati strutturati (CSV, JSON) contenenti input numerici, che spesso richiedono pulizia e allineamento dello schema.
• $S$ (Codice): Artefatti di codice, inclusi script euristici, modelli parziali o implementazioni legacy.
• $E$ (Ambiente): Una sandbox basata su Docker che supporta l'I/O file, l'esecuzione di solver (Gurobi, COPT, PuLP, HiGHS) e i vincoli di risorse.
• $M$ (Metrica): La metrica di valutazione (nascosta all'agente) utilizzata dall'infrastruttura del benchmark.

A differenza dei benchmark precedenti che serializzano tutto il contesto in un singolo prompt, OR-Space richiede agli agenti di localizzare, collegare e fondare le informazioni attraverso questi artefatti distribuiti.

2. Modalità di Compito Orientate al Ciclo di Vita

OR-Space definisce tre modalità di compito sequenziali derivate da 100 problemi base (estesi dal benchmark IndustryOR):

• Costruzione ($T_{Build}$): L'agente costruisce un modello di ottimizzazione pronto per il solver da zero utilizzando documenti aziendali e file di dati, partendo da un'impalcatura di codice vuota.
• Revisione ($T_{Revise}$): L'agente modifica un flusso di lavoro di ottimizzazione esistente in base a requisiti aggiornati. Ciò include varianti come Revise-code (modifica del codice legacy), Revise-model (modifica della sola formulazione) e Revise-all. L'agente deve preservare la logica precedente valida mentre integra nuovi vincoli o variabili.
• Spiegazione ($T_{Explain}$): L'agente risponde a domande fondate su soluzioni, vincoli e implicazioni aziendali utilizzando prove distribuite tra documenti, dati, codice e output del solver (es. variabili duali, valori di slack).

3. Protocollo di Valutazione

• Costruzione e Revisione: Valutate tramite metriche punteggiate dal solver. Una sottomissione è corretta se viene eseguita senza errori, restituisce uno stato "Ottimale" e raggiunge un errore relativo dell'obiettivo $\le 1\%$ rispetto a un oracolo ground-truth.
• Spiegazione: Valutata utilizzando una rubrica "LLM-as-judge" fondata. I punteggi si basano sulla Copertura Esatta (35%), sul Ragionamento (35%), sulla Fondazione (20%), sulla Qualità della Risposta (10%) e su una Penalità per Allucinazioni (fino a -12).
• Analisi dei Fallimenti: Il framework registra modalità di fallimento specifiche, inclusi errori di esecuzione, formulazioni non fattibili, obiettivi errati e spiegazioni infedeli.

Contributi Chiave

1. Identificazione delle Limitazioni: Il documento identifica che i benchmark OR esistenti soffrono di impostazioni di ambiente di lavoro autosufficienti e di impostazioni di compiti single-shot, che sottorappresentano la natura multi-artifatto e orientata al ciclo di vita dei flussi di lavoro industriali reali.
2. Benchmark OR-Space: Un nuovo benchmark costruito attorno ad ambienti di lavoro eseguibili persistenti in cui requisiti, dati, codice e output dei solver sono distribuiti su più file.
3. Modalità di Compito: La definizione di tre modalità orientate al ciclo di vita (Costruzione, Revisione, Spiegazione) che catturano la costruzione del modello, la manutenzione e la comunicazione.
4. Framework di Valutazione: Un protocollo per analizzare le capacità degli agenti e le modalità di fallimento in compiti fondati sull'ambiente di lavoro, inclusa la fondazione dei dati, la coerenza della revisione e la fedeltà della spiegazione.

Risultati

Gli autori hanno valutato 20 modelli (frontiera closed-source, piccoli basati su API e open-source) attraverso il benchmark. Le scoperte chiave includono:

• La Fondazione nell'Ambiente di Lavoro è Difficile: Anche gli agenti di frontiera faticano con la costruzione di modelli fondata sull'ambiente di lavoro. Il miglior punteggio di Costruzione è stato del 72,0% (gemini-3.1-pro), con la maggior parte dei modelli di frontiera nella fascia 53–68%. Ciò evidenzia la difficoltà di recuperare schemi di dati e semantica aziendale da artefatti distribuiti rispetto a prompt puliti.
• Codice Legacy come Segnale vs. Rumore: Nel compito Revise, modelli forti (es. gpt-5.4, claude-opus-4-6) hanno spesso migliorato le prestazioni sfruttando il codice legacy come segnale (es. gpt-5.4 è passato dal 59% al 79%). Al contrario, modelli più deboli o "flash" hanno spesso subito cali di prestazioni (es. gemini-3-flash è sceso di 23 punti percentuali), suggerendo che trattavano i dettagli di implementazione come rumore o copiavano importazioni non relative al solver.
• L'Interpretabilità è Distinta: Le prestazioni in Explain erano debolmente correlate con i punteggi di Build e Revise ($r \approx 0.16-0.28$). Alcuni modelli che hanno costruito modelli eseguibili non sono riusciti a spiegarli fedelmente (es. gemini-2.5-pro ha risolto il 69% delle istanze di Revisione ma ha ottenuto solo 32,2 in Spiegazione).
• Impatto dell'Interfaccia: L'uso di un'interfaccia filesystem (rispetto a una serializzazione flat-prompt) ha generalmente ridotto le prestazioni nei compiti di generazione di codice (Costruzione e Revisione) di una media di 8,2 e 12,2 punti percentuali, rispettivamente. Ciò indica che la scoperta dei file e l'ispezione degli schemi sono difficoltà sostanziali, non cosmetiche.
• Sensibilità al Contesto: L'aggiunta di formulazioni formali al contesto del codice ha generalmente aiutato i modelli forti ma potrebbe aver danneggiato i modelli leggeri. È stato riscontrato che il contesto basato solo sulla formulazione è più fragile rispetto al contesto basato sul codice.

Significato e Affermazioni

Il documento posiziona OR-Space come un cambiamento necessario nei paradigmi di valutazione, dalla generazione di testo isolata a flussi di lavoro ingegneristici robusti e fondati sul solver. Gli autori affermano che:

• Divario di Affidabilità: Navigare in un ambiente di lavoro aperto e multi-artifatto rimane altamente impegnativo per gli attuali agenti LLM, esponendo fallimenti sistemici nella mappatura dei dati e nella fondazione dei vincoli che i benchmark basati solo sul testo nascondono in gran parte.
• Prontezza Pratica: OR-Space fornisce una base rigorosa per misurare la prontezza pratica degli agenti di ottimizzazione simulando la natura iterativa e multi-step dell'OR industriale.
• Modalità di Fallimento: Il benchmark permette un'attribuzione fine-granulare dei fallimenti, distinguendo tra errori di modellazione matematica, errori di fondazione dei dati e vincoli allucinati, il che è fondamentale per il deployment di agenti in contesti reali.

Il lavoro conclude che, sebbene gli LLM mostrino promesse in compiti di formulazione isolati, la loro capacità di svolgere ingegneria OR affidabile attraverso un ambiente di lavoro persistente e un ciclo di vita completo è attualmente limitata, rendendo necessaria ulteriore ricerca sull'affidabilità degli agenti, sulle modalità di fallimento e sull'interazione con l'ambiente di lavoro.