Al utilizar la IA para construir un modelo de optimización matemática para un problema empresarial real, probablemente se haya topado con el mismo muro: la IA funciona maravillosamente en ejemplos de libros de texto y se desmorona en el momento en que le entrega sus datos reales y su problema real.
Esa brecha no es una coincidencia. Es por diseño y es la razón por la que construí ORPilot.
La promesa de la optimización impulsada por la IA
La Investigación de Operaciones (OR) ha estado impulsando silenciosamente algunas de las decisiones más impactantes en los negocios durante décadas: enrutar los camiones de reparto, programar la producción de las fábricas, diseñar cadenas de suministro y asignar carga a los transportistas. Las matemáticas son maduras y los solucionadores son excelentes. El cuello de botella siempre ha sido la experiencia humana necesaria para traducir un problema empresarial en un modelo matemático.
Los modelos de lenguajes grandes (LLM) parecían la solución perfecta. Un creciente cuerpo de investigación, incluida la serie OptiMUS, OR-LLM y otros, ha demostrado que los LLM de última generación pueden generar código de resolución correcto para problemas de programación lineal (LP) y programación entera mixta (MIP) bien especificados. Los resultados parecieron impresionantes. Las demostraciones fueron convincentes.
Luego intenta utilizar una de estas herramientas en un problema real y las grietas aparecen de inmediato.
Donde las herramientas existentes fallan
Casi todas las herramientas de LLM para OR creadas hasta la fecha comparten una suposición oculta: la descripción del problema es completa, inequívoca y se entrega a la IA en un mensaje único y bien formateado con todos los datos claramente integrados en línea.
No es así como funcionan los problemas reales del quirófano. Ni siquiera cerca.
Considere lo que realmente sucede cuando un equipo de la cadena de suministro quiere crear un modelo de optimización:
La descripción del problema es incompleta y ambigua. Un analista de negocios dirá “queremos minimizar los costos de transporte” y olvidará mencionar que cada centro de distribución tiene un límite de rendimiento, que algunas rutas no existen o que abrir una instalación implica un costo fijo único. Estas omisiones no son
descuido. Son suposiciones que el analista considera obvias, y por eso exactamente son peligrosas. Un sistema de IA que comienza a modelar antes de que se definan estos detalles produce un modelo que es técnicamente correcto pero prácticamente incorrecto. Los datos son demasiado grandes para caber en una indicación. Un problema real en la cadena de suministro podría involucrar cientos de sitios de producción, centros de distribución, clientes y miles de productos durante múltiples períodos. La tabla de demanda por sí sola podría tener millones de entradas. No puedes incrustar eso en un mensaje. Incluso si pudiera, inundar la ventana contextual con datos sin procesar aumenta drásticamente el riesgo de sufrir alucinaciones. Los datos que tiene no son los datos que necesita el modelo. Es posible que el modelo necesite una matriz de distancias entre todos los pares de ubicaciones. Lo que tienes es una tabla de coordenadas GPS. El modelo podría necesitar demanda agregada por producto y período. Lo que tienes es un libro de transacciones con una fila por pedido. Cerrar esta brecha, es decir, calcular parámetros derivados de datos sin procesar, es un paso de ingeniería importante que ninguna herramienta LLM para OR maneja automáticamente. Una vez que tenga un modelo funcional, la portabilidad y la reproducibilidad son importantes. Si desea volver a ejecutar el modelo con datos actualizados, cambiar de Gurobi a un solucionador de código abierto o entregar el modelo a un colega en una máquina diferente, volverá al punto de partida a menos que la herramienta produzca un artefacto duradero e independiente del solucionador. La mayoría de las herramientas producen código específico del solucionador y nada más.
Estos no son casos extremos. Son las condiciones estándar para cualquier implementación de quirófano en el mundo real. Las herramientas LLM-for-OR existentes se crearon para un mundo diferente, un mundo de libros de texto, y muestran sus costuras en el momento en que lo abandonan.
Presentamos ORPilot
ORPilot es un agente de IA de código abierto creado desde cero para las condiciones de producción. Es, hasta donde yo sé, la primera herramienta de OR basada en LLM diseñada explícitamente para la realidad desordenada, a gran escala y con gran cantidad de datos de la optimización industrial.
La mayoría de las herramientas de optimización de IA pasan directamente a escribir código en el momento en que describe su problema. ORPilot hace algo diferente: primero hace preguntas.
Esa decisión de diseño, que prioriza la comprensión sobre la velocidad, refleja un único principio rector: un agente de IA debe trabajar de la misma manera que lo haría un consultor de quirófano humano capacitado.
Un buen consultor no llega a una reunión con un cliente y comienza a escribir un modelo matemático en la pizarra. Hacen preguntas. Escuchan atentamente. Ellos retroceden cuando algo
es ambiguo. Se aseguran de que los datos tengan la forma correcta antes de comenzar el modelado. Sólo después de todo eso cogen el bolígrafo.
El proceso de ORPilot refleja esta disciplina a través de cinco etapas conectadas secuencialmente.
Etapa 1: Agente de entrevista
El agente entrevistador es el punto de entrada. Recibe su descripción inicial del problema empresarial, que puede ser vaga, incompleta o incluso contradictoria, y lo involucra en una
diálogo estructurado para llenar los vacíos. El principio clave del diseño es que no se comienza a modelar hasta que se completa la entrevista.
Se solicita al agente que identifique lagunas de información en la descripción actual, haga como máximo una pregunta aclaratoria específica por turno (para evitar abrumarlo) y finalice una vez que la función objetivo, las variables de decisión, las restricciones y los requisitos de datos se hayan especificado sin ambigüedades.
En la práctica, esto significa conversaciones como:
ORPilot: “Una vez que se abre una instalación, ¿permanece abierta durante todos los períodos posteriores o se puede cerrar más tarde?”
ORPilot: “¿Este modelo maneja un solo tipo de producto o varios productos?”
ORPilot: “Usted mencionó un costo de transporte. ¿Es este costo por unidad enviada, por envío independientemente de la cantidad, o algo más?”
Antes de finalizar la entrevista, el agente presenta un resumen estructurado completo con función objetivo, variables de decisión, restricciones, parámetros, índices y le brinda la oportunidad de corregir cualquier cosa antes de que ese resumen se transmita. Esta es la protección contra el modo de falla más común en las herramientas LLM para OR: modelar el problema incorrecto.
Etapa 2: Agente de recopilación de datos
Esta etapa no tiene contraparte en la mayoría de las herramientas LLM-for-OR existentes. Es una de las innovaciones estructurales más importantes de ORPilot.
La mayoría de las herramientas LLM-for-OR existentes asumen que los datos están incrustados en el texto del problema, lo suficientemente pequeños como para caber en un mensaje. Para problemas de libros de texto, esto funciona. Para problemas reales, se descompone de dos maneras. En primer lugar, los conjuntos de datos reales son demasiado grandes. Por ejemplo, un problema de cadena de suministro de 500 clientes, 500 productos y 12 períodos tendría 3.000.000 de entradas de demanda. En segundo lugar, incorporar datos en el mensaje aumenta el riesgo de alucinaciones y quema la ventana de contexto innecesariamente.
La respuesta de ORPilot es tratar los datos como si estuvieran completamente separados del mensaje. Los datos residen en archivos CSV. La IA accede a él únicamente escribiendo y ejecutando código. El trabajo del agente de recopilación de datos es determinar exactamente cómo deben verse esos archivos CSV.
Con base en la especificación del problema por parte del agente entrevistador, el agente de recolección de datos determina:
Qué entidades (conjuntos) existen en el modelo Qué atributos (parámetros) necesita cada entidad El esquema preciso para cada tabla requerida: nombres de columnas, tipos, semántica
Le presenta esta especificación y espera hasta que haya proporcionado todos los archivos en el formato correcto. Valida la integridad antes de continuar.
Fundamentalmente, el agente es flexible: si no tiene una pieza particular de datos listos para el modelo (por ejemplo, el modelo necesita una matriz de distancia pero solo tiene coordenadas GPS), le dice al agente lo que realmente tiene y este actualiza el esquema en consecuencia, pasando la brecha a la siguiente etapa para manejarla.
Etapa 3: Agente de cálculo de parámetros
Casi todas las herramientas LLM-for-OR existentes asumen que las cantidades numéricas que necesita el modelo aparecen directamente en los datos proporcionados por el usuario. En la práctica, esto casi nunca es cierto. Dos ejemplos que surgen constantemente en problemas reales de quirófano:
Un modelo de rutas de vehículos necesita una matriz de distancias por pares. El usuario tiene coordenadas GPS. Calcular distancias euclidianas o geográficas es una transformación completamente fuera del alcance de la formulación LP/MIP. Un modelo de producción de múltiples períodos necesita demanda agregada por período. El usuario tiene un libro de transacciones con una fila por pedido. El parámetro del modelo es una suma agregada que debe calcularse a partir de los datos sin procesar.
El agente de cálculo de parámetros salva esta brecha automáticamente. Recibe la especificación del problema y los archivos CSV sin formato, luego:
Identifica qué parámetros del modelo no se pueden leer directamente desde las tablas sin formato. Genera una secuencia de comandos de Python para calcular esos parámetros derivados. Ejecuta la secuencia de comandos en un entorno de espacio aislado. Escribe los resultados como archivos CSV adicionales, que se pasan al paso de modelado.
Esto garantiza que cuando el agente de modelado vea los datos, estén limpios, escritos correctamente, indexados correctamente y listos para el modelo. En nuestros experimentos, este paso redujo sustancialmente los errores de generación de código y el número de reintentos.
Otra situación común en la que el agente de cálculo de parámetros podría resultar útil es el cálculo de valores de BigM. En algunos experimentos que hice en ORPilot, el agente de cálculo de parámetros calculó un valor de BigM necesario para las restricciones que vinculan las variables de envío continuo con las decisiones binarias de apertura de instalaciones. Este es un parámetro derivado que no sería práctico pedirle al usuario que lo proporcione directamente.
Etapa 4: Agente de generación de código
Con una especificación completa del problema, datos sin procesar y parámetros derivados, todo a mano, el agente de generación de código produce un script completo de resolución de Python para el backend elegido. ORPilot actualmente admite cinco backends: Gurobi, CPLEX, PuLP, Pyomo y OR-Tools.
El código generado se ejecuta inmediatamente en un sandbox. Si algo sale mal: error de sintaxis, excepción de tiempo de ejecución o resultado del solucionador no factible/ilimitado, el mensaje de error completo y el rastreo se devuelven al LLM junto con el código generado previamente. El agente vuelve a intentarlo, hasta un número máximo de intentos configurable por el usuario.
En la práctica, la mayoría de los errores se resuelven en uno o dos reintentos. La razón clave por la que el ciclo de reintento de ORPilot es efectivo es que las etapas anteriores ya han hecho el trabajo duro: el problema está especificado correctamente, los datos están listos para el modelo y el agente solo
necesita corregir un error a nivel de código en lugar de repensar toda la estructura del modelo.
Etapa 5: Agente reportero
Después de una solución exitosa, un agente reportero traduce los resultados numéricos al inglés simple, explicando qué instalaciones abrir, qué rutas usar, qué cantidades producir, en el lenguaje de dominio del problema comercial original, para el consumo de un usuario comercial en lugar de un experto en quirófano.
Por qué es importante este orden
El proceso es deliberadamente secuencial. Cada etapa depende de que la anterior se complete con éxito. La entrevista debe finalizar antes de que comience la recolección de datos. Los datos deben validarse antes de ejecutar el cálculo de parámetros. Los parámetros deben estar listos antes de que se genere el código.
Esta secuenciación evita el modo de falla más común en las herramientas OR basadas en LLM: errores en cascada donde una descripción ambigua del problema se propaga a través de la canalización y produce código que es sintácticamente válido pero modela el objetivo incorrecto.
Cómo se ve esto a escala
Probé ORPilot en algunos problemas de OR, uno de los cuales es un problema de diseño de la red de la cadena de suministro con 50 sitios de producción, 50 centros de distribución, 500 clientes, 500 productos, 12 períodos. El modelo resultante tenía más de 9,7 millones de variables de decisión y 963.000 restricciones. ORPilot manejó con éxito todo el proceso de principio a fin, desde la conversación inicial hasta la recopilación de datos, el cálculo de parámetros, la generación de código y la generación de informes de la solución, produciendo una solución óptima con Gurobi. Consulte mi artículo aquí https://arxiv.org/abs/2605.02728 para ver los resultados de más problemas de prueba.
Empezando
ORPilot es de código abierto y está disponible ahora:
GitHub: https://github.com/GuangruiXieVT/ORPilot
Documento: https://arxiv.org/abs/2605.02728
La instalación tarda unos minutos. ORPilot admite OpenAI, Anthropic, Google y DeepSeek como proveedores de LLM, y Gurobi, CPLEX, PuLP, Pyomo y OR-Tools como backends de resolución.
En la próxima publicación de esta serie, profundizaremos en la Representación Intermedia (IR), el artefacto JSON independiente del solucionador que hace que los resultados de ORPilot sean reproducibles y portátiles entre backends sin tener que volver a llamar al LLM. ¡Manténganse al tanto!