🤖 AI

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

El artículo presenta OR-Space, una evaluación de espacio de trabajo de ciclo completo diseñada para evaluar agentes de optimización industrial en tareas realistas y multietapa que involucran la construcción, revisión y explicación fundamentada de modelos dentro de entornos persistentes con múltiples artefactos, superando las evaluaciones tradicionales de formulación de problemas en un solo intento.

Autores originales: Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

Publicado 2026-05-28

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Chenyu Zhou, Xinyun Lu, Jiangyue Zhao, Jianghao Lin, Dongdong Ge, Yinyu Ye

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás contratando a un nuevo asistente brillante para ayudar a gestionar una fábrica. Quieres ver si realmente puede hacer el trabajo, no solo hablar de ello.

Durante mucho tiempo, la forma en que probábamos a estos asistentes de IA (llamados "agentes LLM") era como darles una tarjeta de receta perfectamente escrita. La tarjeta decía: "Aquí está el problema, aquí están los ingredientes, aquí está la fórmula matemática. Ahora, escribe el código para resolverlo".

Si la IA escribía el código correctamente, le dábamos una estrella dorada. Pero en el mundo real, los gerentes de fábrica no reciben tarjetas de receta perfectas. Reciben un escritorio desordenado con notas adhesivas, hojas de cálculo, código antiguo del año pasado y correos electrónicos del jefe que dicen: "Por cierto, necesitamos cambiar las reglas para el próximo mes".

OR-Space es una nueva prueba, mucho más difícil, diseñada para ver si la IA puede manejar ese escritorio desordenado y real.

Las Tres Formas en que Probamos a la IA

El artículo introduce una evaluación llamada OR-Space (Espacio de Investigación Operativa). En lugar de una sola pregunta, le da a la IA un "espacio de trabajo" completo (una carpeta digital con archivos) y le pide que realice tres tipos diferentes de tareas que ocurren en una fábrica real:

Construir (El Arquitecto):
- El Escenario: Le entregas a la IA una carpeta con un memorándum empresarial, una hoja de cálculo con números y un archivo de código vacío.
- La Tarea: La IA debe leer el memorándum, entender qué significan los números y escribir un programa informático completamente nuevo para resolver el problema de la fábrica desde cero.
- El Truco: El memorándum puede ser vago y la hoja de cálculo puede tener columnas desordenadas. La IA debe conectar los puntos entre el texto y los datos sin una guía perfecta.
Revisar (El Reparador):
- El Escenario: La fábrica acaba de cambiar de opinión. Quizás ahora tienen más camiones o una nueva regla de seguridad. Se le da a la IA el programa antiguo y las nuevas reglas.
- La Tarea: La IA debe actualizar el código antiguo para adaptarlo a las nuevas reglas sin romper las partes que ya funcionaban.
- El Truco: Esto es como intentar reformar una casa mientras la gente sigue viviendo en ella. Si la IA copia un nombre de variable del código antiguo que ya no tiene sentido, todo el sistema se bloquea. El artículo encontró que algunas IAs se confunden con el código antiguo e intentan copiar sus errores, mientras que las IAs más inteligentes saben qué conservar y qué desechar.
Explicar (El Traductor):
- El Escenario: La computadora ha resuelto el problema, pero el gerente de la fábrica (que no es un experto en matemáticas) pregunta: "¿Por qué decidiste enviar 5 camiones al almacén del norte en lugar del del sur?".
- La Tarea: La IA debe examinar la solución, el código y los registros de datos para dar una respuesta veraz.
- El Truco: La IA no puede simplemente inventar una historia. Debe señalar la línea específica en la hoja de cálculo o la regla específica en el código que obligó a esa decisión. Si adivina, pierde puntos.

Por qué esta Prueba es Diferente (El "Espacio de Trabajo" vs. El "Prompt")

Los autores argumentan que las pruebas anteriores eran como tarjetas de memoria. Mostrabas a la IA un problema limpio y aislado, y ella respondía.

OR-Space es como una oficina real.

Los Archivos están Separados: Los requisitos están en un documento de Word, los números en un archivo CSV y el código en un archivo Python. La IA debe abrirlos todos, leerlos y darse cuenta de cómo encajan entre sí.
El Problema de la "Anclaje" (Grounding): En una prueba de tarjetas de memoria, la IA podría adivinar la respuesta correcta porque reconoce las palabras. En OR-Space, si la IA no vincula correctamente la palabra "capacidad" en el memorándum con la columna "max_load" en la hoja de cálculo, falla. El artículo llama a esto "anclaje": atar las palabras a los datos reales.

Lo que Encontraron (Los Resultados)

Los investigadores probaron 20 modelos de IA diferentes (los más "inteligentes" disponibles) en esta nueva prueba. Esto es lo que sucedió:

Es Más Difícil de lo que Parece: Incluso las mejores IAs tuvieron dificultades. Aunque algunas podían resolver la versión de "tarjeta de memoria" del problema, a menudo fallaban cuando tenían que navegar por la carpeta desordenada de archivos.
El Código Antiguo es un Arma de Doble Filo: Cuando se le dio a la IA código antiguo para ayudarle a revisar el modelo, las IAs más inteligentes mejoraron porque usaron el código antiguo como una pista útil. Pero las IAs más débiles empeoraron porque copiaron ciegamente los errores del código antiguo (como intentar usar una variable que ya no existía).
La Brecha de "Explicar": Algunas IAs eran excelentes escribiendo el código pero terribles explicándolo. Podían resolver las matemáticas pero no podían decirte por qué tomaron esa decisión basándose en los archivos que tenían.
La Penalización del "Sistema de Archivos": El artículo encontró que cuando las IAs tenían que navegar realmente por carpetas y leer archivos (el modo "Sistema de Archivos"), rendían peor que cuando la misma información simplemente se pegaba en un solo bloque gigante de texto. Esto demuestra que encontrar y organizar información es una habilidad en sí misma, no solo un problema de formato.

La Conclusión

El artículo concluye que no podemos probar a la IA solo en lo bien que escribe código a partir de un prompt perfecto. Para ser útil en industrias reales (como logística, manufactura o finanzas), la IA debe ser probada en su capacidad para:

Encontrar la información correcta en un montón desordenado de documentos.
Actualizar sistemas antiguos sin romperlos.
Explicar sus decisiones utilizando evidencia de los archivos reales, no solo historias inventadas.

OR-Space es el nuevo "examen de conducir" para estos agentes de IA, moviéndolos del estacionamiento (prompts perfectos) a las calles concurridas de la ciudad (espacios de trabajo reales).

Resumen Técnico: OR-Space

Enunciado del Problema

Las evaluaciones existentes para agentes de Modelos de Lenguaje Grande (LLM) en Investigación de Operaciones (IO) abstraen en gran medida las complejidades de los flujos de trabajo industriales reales. Las evaluaciones actuales suelen reducir las tareas de IO a problemas de "una sola vez", donde un agente traduce una instrucción textual autónoma en una formulación matemática o código de un solver. Este enfoque no logra capturar dos características definitorias de la IO industrial:

El Entorno de Espacio de Trabajo: Los agentes del mundo real operan dentro de entornos persistentes y multiartefacto que contienen requisitos comerciales, datos estructurados (CSV/JSON), artefactos de código, retroalimentación del solver e interacciones con partes interesadas distribuidas en múltiples archivos.
El Entorno de Ciclo de Vida: La IO industrial es iterativa. Los ingenieros no solo generan una solución una vez; construyen modelos iniciales, los revisan en respuesta a cambios en las reglas comerciales o a la retroalimentación del solver, y explican las decisiones resultantes a partes interesadas no expertas.

En consecuencia, las evaluaciones actuales no pueden determinar si un agente puede realizar trabajo de optimización confiable a través de un espacio de trabajo multiartefacto y a lo largo de múltiples etapas del ciclo de vida de la modelización.

Metodología

Los autores presentan OR-Space, una evaluación de espacio de trabajo de ciclo completo diseñada para evaluar agentes de optimización industrial. La metodología se estructura en torno a dos ejes centrales: un espacio de trabajo ejecutable persistente y una tubería de tareas orientada al ciclo de vida.

1. Formalización del Espacio de Trabajo de IO

Un espacio de trabajo de IO ( $W$ ) se define como un entorno estructurado, persistente y ejecutable:
$W = \langle D, P, S, E, M \rangle$

$D$ (Documentos): Artefactos en lenguaje natural (por ejemplo, business_requirement.md) que describen objetivos y requisitos.
$P$ (Parámetros): Archivos de datos estructurados (CSV, JSON) que contienen entradas numéricas, que a menudo requieren limpieza y alineación de esquemas.
$S$ (Código): Artefactos de código, incluidos scripts heurísticos, plantillas parciales o implementaciones heredadas.
$E$ (Entorno): Un entorno tipo sandbox basado en Docker que admite entrada/salida de archivos, ejecución de solvers (Gurobi, COPT, PuLP, HiGHS) y restricciones de recursos.
$M$ (Métrica): La métrica de evaluación (oculta para el agente) utilizada por el sistema de pruebas de la evaluación.

A diferencia de evaluaciones anteriores que serializan todo el contexto en una sola instrucción, OR-Space requiere que los agentes localicen, conecten y fundamenten la información a través de estos artefactos distribuidos.

2. Modos de Tarea Orientados al Ciclo de Vida

OR-Space define tres modos de tarea secuenciales derivados de 100 problemas base (extendidos desde la evaluación IndustryOR):

Construir ( $T_{Build}$ ): El agente construye un modelo de optimización listo para el solver desde cero utilizando documentos comerciales y archivos de datos, comenzando desde un andamio de código vacío.
Revisar ( $T_{Revise}$ ): El agente modifica un flujo de trabajo de optimización existente bajo requisitos actualizados. Esto incluye variantes como Revise-code (modificar código heredado), Revise-model (modificar solo la formulación) y Revise-all. El agente debe preservar la lógica previa válida mientras integra nuevas restricciones o variables.
Explicar ( $T_{Explain}$ ): El agente responde preguntas fundamentadas sobre soluciones, restricciones e implicaciones comerciales utilizando evidencia distribuida en documentos, datos, código y salidas del solver (por ejemplo, variables duales, valores de holgura).

3. Protocolo de Evaluación

Construir y Revisar: Evaluados mediante métricas puntuadas por el solver. Una presentación es correcta si se ejecuta sin errores, devuelve un estado "Óptimo" y logra un error objetivo relativo $\le 1\%$ frente a un oráculo de verdad fundamental.
Explicar: Evaluado utilizando una rúbrica fundamentada de "LLM como juez". Las puntuaciones se basan en Cobertura Exacta (35%), Razonamiento (35%), Fundamentación (20%), Calidad de la Respuesta (10%) y una Penalización por Alucinación (hasta -12).
Análisis de Fallos: El marco registra modos de fallo específicos, incluidos errores de ejecución, formulaciones no viables, objetivos incorrectos y explicaciones infieles.

Contribuciones Clave

Identificación de Limitaciones: El artículo identifica que las evaluaciones existentes de IO sufren de entornos de espacio de trabajo autónomos y configuraciones de tareas de una sola vez, lo que subrepresenta la naturaleza multiartefacto y orientada al ciclo de vida de los flujos de trabajo industriales reales.
Evaluación OR-Space: Una nueva evaluación construida en torno a espacios de trabajo ejecutables persistentes donde los requisitos, datos, código y salidas del solver están distribuidos en múltiples archivos.
Modos de Tarea: La definición de tres modos orientados al ciclo de vida (Construir, Revisar, Explicar) que capturan la construcción, el mantenimiento y la comunicación de modelos.
Marco de Evaluación: Un protocolo para analizar las capacidades de los agentes y los modos de fallo en tareas fundamentadas en el espacio de trabajo, incluida la fundamentación de datos, la consistencia de la revisión y la fidelidad de la explicación.

Resultados

Los autores evaluaron 20 modelos (de vanguardia de código cerrado, pequeños basados en API y de código abierto) a través de la evaluación. Los hallazgos clave incluyen:

La Fundamentación en el Espacio de Trabajo es Difícil: Incluso los agentes de vanguardia luchan con la construcción de modelos fundamentada en el espacio de trabajo. La mejor puntuación de Construir fue del 72,0% (gemini-3.1-pro), con la mayoría de los modelos de vanguardia en el rango del 53–68%. Esto resalta la dificultad de recuperar esquemas de datos y semántica comercial a partir de artefactos distribuidos en comparación con instrucciones limpias.
Código Heredado como Señal vs. Ruido: En la tarea Revisar, los modelos fuertes (por ejemplo, gpt-5.4, claude-opus-4-6) a menudo mejoraron el rendimiento aprovechando el código heredado como señal (por ejemplo, gpt-5.4 mejoró del 59% al 79%). Por el contrario, los modelos más débiles o "flash" a menudo sufrieron caídas de rendimiento (por ejemplo, gemini-3-flash bajó 23 puntos porcentuales), lo que sugiere que trataron los detalles de implementación como ruido o copiaron importaciones no relacionadas con el solver.
La Explicabilidad es Distinta: El rendimiento en Explicar estuvo débilmente correlacionado con las puntuaciones de Construir y Revisar ( $r \approx 0.16-0.28$ ). Algunos modelos que construyeron modelos ejecutables fallaron al explicarlos fielmente (por ejemplo, gemini-2.5-pro resolvió el 69% de las instancias de Revisar pero obtuvo solo 32.2 en Explicar).
Impacto de la Interfaz: El uso de una interfaz de sistema de archivos (frente a una serialización de instrucción plana) generalmente redujo el rendimiento en tareas de generación de código (Construir y Revisar) en un promedio de 8.2 y 12.2 puntos porcentuales, respectivamente. Esto indica que el descubrimiento de archivos y la inspección de esquemas son dificultades sustanciales, no cosméticas.
Sensibilidad al Contexto: Añadir formulaciones formales al contexto de código generalmente ayudó a los modelos fuertes, pero podría perjudicar a los modelos ligeros. Se encontró que el contexto solo de formulación era más frágil que el contexto basado en código.

Significado y Afirmaciones

El artículo sitúa a OR-Space como un cambio necesario en los paradigmas de evaluación, desde la generación de texto aislada hacia flujos de trabajo de ingeniería robustos y fundamentados en solvers. Los autores afirman que:

Brecha de Fiabilidad: Navegar por un espacio de trabajo abierto y multiartefacto sigue siendo altamente desafiante para los agentes actuales de LLM, exponiendo fallos sistémicos en el mapeo de datos y la fundamentación de restricciones que las evaluaciones basadas únicamente en texto ocultan en gran medida.
Preparación Práctica: OR-Space proporciona una base rigurosa para medir la preparación práctica de los agentes de optimización al simular la naturaleza iterativa y multi-paso de la IO industrial.
Modos de Fallo: La evaluación permite una atribución detallada de fallos, distinguiendo entre errores de modelado matemático, errores de fundamentación de datos y restricciones alucinadas, lo cual es crítico para desplegar agentes en entornos del mundo real.

El trabajo concluye que, aunque los LLM muestran promesa en tareas de formulación aisladas, su capacidad para realizar ingeniería de IO confiable a través de un espacio de trabajo persistente y un ciclo de vida completo está actualmente limitada, lo que hace necesaria una investigación adicional sobre la fiabilidad de los agentes, los modos de fallo y la interacción con el espacio de trabajo.