Resumo Técnico: OR-Space

Declaração do Problema

As benchmarks existentes para agentes de Modelos de Linguagem de Grande Porte (LLM) em Pesquisa Operacional (PO) abstraem em grande parte as complexidades dos fluxos de trabalho industriais do mundo real. As avaliações atuais tipicamente reduzem tarefas de PO a problemas "de um único tiro", onde um agente traduz um prompt textual autocontido em uma formulação matemática ou código de solucionador. Essa abordagem falha em capturar duas características definidoras da PO industrial:

1. O Ambiente de Trabalho: Agentes do mundo real operam dentro de ambientes persistentes e multiartefato contendo requisitos de negócios, dados estruturados (CSV/JSON), artefatos de código, feedback de solucionador e interações com partes interessadas distribuídos em múltiplos arquivos.
2. O Ambiente de Ciclo de Vida: A PO industrial é iterativa. Engenheiros não geram meramente uma solução uma única vez; eles constroem modelos iniciais, revisam-nos em resposta a regras de negócios em mudança ou feedback de solucionador, e explicam as decisões resultantes a partes interessadas não especialistas.

Consequentemente, as benchmarks atuais não podem determinar se um agente pode realizar trabalho de otimização confiável através de um ambiente de trabalho multiartefato e através de múltiplos estágios do ciclo de vida de modelagem.

Metodologia

Os autores introduzem o OR-Space, uma benchmark de ambiente de trabalho de ciclo de vida completo projetada para avaliar agentes de otimização industrial. A metodologia é estruturada em torno de dois eixos centrais: um ambiente de trabalho executável persistente e um pipeline de tarefas orientado ao ciclo de vida.

1. Formalização do Ambiente de Trabalho PO

Um ambiente de trabalho PO ($W$) é definido como um ambiente estruturado, persistente e executável:
$$W = \langle D, P, S, E, M \rangle$$

• $D$ (Documentos): Artefatos em linguagem natural (por exemplo, business_requirement.md) descrevendo objetivos e requisitos.
• $P$ (Parâmetros): Arquivos de dados estruturados (CSV, JSON) contendo entradas numéricas, frequentemente exigindo limpeza e alinhamento de esquema.
• $S$ (Código): Artefatos de código, incluindo scripts heurísticos, modelos parciais ou implementações legadas.
• $E$ (Ambiente): Um sandbox baseado em Docker suportando E/S de arquivos, execução de solucionador (Gurobi, COPT, PuLP, HiGHS) e restrições de recursos.
• $M$ (Métrica): A métrica de avaliação (oculta ao agente) utilizada pela infraestrutura da benchmark.

Diferentemente de benchmarks anteriores que serializam todo o contexto em um único prompt, o OR-Space exige que os agentes localizem, conectem e fundamentem informações através desses artefatos distribuídos.

2. Modos de Tarefa Orientados ao Ciclo de Vida

O OR-Space define três modos de tarefa sequenciais derivados de 100 problemas base (estendidos da benchmark IndustryOR):

• Construir ($T_{Build}$): O agente constrói um modelo de otimização pronto para solucionador do zero usando documentos de negócios e arquivos de dados, começando a partir de uma estrutura de código vazia.
• Revisar ($T_{Revise}$): O agente modifica um fluxo de trabalho de otimização existente sob requisitos atualizados. Isso inclui variantes como Revisar-código (modificando código legado), Revisar-modelo (modificando apenas a formulação) e Revisar-tudo. O agente deve preservar a lógica prévia válida enquanto integra novas restrições ou variáveis.
• Explicar ($T_{Explain}$): O agente responde a perguntas fundamentadas sobre soluções, restrições e implicações de negócios usando evidências distribuídas em documentos, dados, código e saídas de solucionador (por exemplo, variáveis duais, valores de folga).

3. Protocolo de Avaliação

• Construir e Revisar: Avaliados por meio de métricas pontuadas pelo solucionador. Uma submissão é correta se executar sem erro, retornar um status "Ótimo" e alcançar um erro objetivo relativo $\le 1\%$ contra um oráculo de verdade fundamental.
• Explicar: Avaliado usando uma rubrica fundamentada de "LLM-como-julgador". As pontuações são baseadas em Cobertura Exata (35%), Raciocínio (35%), Fundamentação (20%), Qualidade da Resposta (10%) e uma Penalidade de Alucinação (até -12).
• Análise de Falhas: A infraestrutura registra modos de falha específicos, incluindo erros de execução, formulações inviáveis, objetivos incorretos e explicações não fiéis.

Contribuições Principais

1. Identificação de Limitações: O artigo identifica que as benchmarks de PO existentes sofrem de ambientes de trabalho autocontidos e configurações de tarefas de um único tiro, que subrepresentam a natureza multiartefato e orientada ao ciclo de vida dos fluxos de trabalho industriais reais.
2. Benchmark OR-Space: Uma nova benchmark construída em torno de ambientes de trabalho executáveis persistentes onde requisitos, dados, código e saídas de solucionador são distribuídos em múltiplos arquivos.
3. Modos de Tarefa: A definição de três modos orientados ao ciclo de vida (Construir, Revisar, Explicar) que capturam a construção, manutenção e comunicação de modelos.
4. Estrutura de Avaliação: Um protocolo para analisar capacidades de agentes e modos de falha em tarefas fundamentadas no ambiente de trabalho, incluindo fundamentação de dados, consistência de revisão e fidelidade de explicação.

Resultados

Os autores avaliaram 20 modelos (fronteira de código fechado, pequenos baseados em API e código aberto) através da benchmark. As principais descobertas incluem:

• Fundamentação no Ambiente de Trabalho é Difícil: Mesmo agentes de fronteira lutam com a construção de modelos fundamentados no ambiente de trabalho. A melhor pontuação de Construir foi de 72,0% (gemini-3.1-pro), com a maioria dos modelos de fronteira na faixa de 53–68%. Isso destaca a dificuldade de recuperar esquemas de dados e semântica de negócios a partir de artefatos distribuídos em comparação com prompts limpos.
• Código Legado como Sinal vs. Ruído: Na tarefa Revisar, modelos fortes (por exemplo, gpt-5.4, claude-opus-4-6) frequentemente melhoraram o desempenho ao aproveitar o código legado como um sinal (por exemplo, gpt-5.4 melhorou de 59% para 79%). Por outro lado, modelos mais fracos ou "flash" frequentemente sofreram quedas de desempenho (por exemplo, gemini-3-flash caiu 23 pontos percentuais), sugerindo que trataram detalhes de implementação como ruído ou copiaram imports não relacionados ao solucionador.
• Explicabilidade é Distinta: O desempenho em Explicar foi fracamente correlacionado com as pontuações de Construir e Revisar ($r \approx 0,16-0,28$). Alguns modelos que construíram modelos executáveis falharam em explicá-los fielmente (por exemplo, gemini-2.5-pro resolveu 69% das instâncias de Revisar, mas pontuou apenas 32,2 em Explicar).
• Impacto da Interface: O uso de uma interface de sistema de arquivos (vs. uma serialização de prompt plano) geralmente reduziu o desempenho em tarefas de geração de código (Construir e Revisar) em uma média de 8,2 e 12,2 pontos percentuais, respectivamente. Isso indica que a descoberta de arquivos e a inspeção de esquema são dificuldades substanciais, não cosméticas.
• Sensibilidade ao Contexto: Adicionar formulações formais ao contexto de código geralmente ajudou modelos fortes, mas poderia prejudicar modelos leves. O contexto apenas de formulação foi encontrado como mais frágil do que o contexto baseado em código.

Significado e Alegações

O artigo posiciona o OR-Space como uma mudança necessária nos paradigmas de avaliação, da geração de texto isolada para fluxos de trabalho de engenharia robustos e fundamentados em solucionadores. Os autores alegam que:

• Lacuna de Confiabilidade: Navegar por um ambiente de trabalho aberto e multiartefato permanece altamente desafiador para agentes LLM atuais, expondo falhas sistêmicas no mapeamento de dados e fundamentação de restrições que benchmarks apenas de texto ocultam em grande parte.
• Prontidão Prática: O OR-Space fornece uma base rigorosa para medir a prontidão prática de agentes de otimização ao simular a natureza iterativa e multi-etapa da PO industrial.
• Modos de Falha: A benchmark permite a atribuição granular de falhas, distinguindo entre erros de modelagem matemática, erros de fundamentação de dados e restrições alucinadas, o que é crítico para implantar agentes em configurações do mundo real.

O trabalho conclui que, embora os LLMs mostrem promessa em tarefas de formulação isoladas, sua capacidade de realizar engenharia de PO confiável através de um ambiente de trabalho persistente e ciclo de vida completo é atualmente limitada, necessitando de mais pesquisa sobre confiabilidade de agentes, modos de falha e interação com ambiente de trabalho.