Serie AI-Native · Investigación

Deja que el modelo escriba el problema. Deja que el solver firme la respuesta.

Por Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app · 2026-08-04

Pídele a un modelo de lenguaje que planifique tu trimestre y obtendrás algo hermoso. Pídeselo dos veces y obtendrás dos planes hermosos y distintos — y si contrastas cualquiera de ellos con tus restricciones reales (este ingeniero está ocupado, esa fecha límite es innegociable, este presupuesto tiene un tope), verás que viola varias en silencio. Pídele lo mismo a un programa entero binario y obtendrás exactamente una respuesta que respeta, de forma demostrable, cada restricción que le diste — y jamás te dirá si le diste las restricciones correctas, ni si lo que le pediste maximizar vale la pena maximizarlo.

Esas no son dos herramientas que compiten. Son dos mitades de un cerebro, y la pregunta de ingeniería interesante — de la que trata este artículo — es la costura.

Lo que la investigación realmente zanjó

Los últimos dos años produjeron una respuesta inusualmente clara a la pregunta "¿pueden planificar los LLM?" — y es una división del trabajo, no un ganador.

Primera mitad: los LLM no pueden ser el garante. Kambhampati y colegas lo plantean sin rodeos en su position paper de ICML 2024, así: "We argue that auto-regressive LLMs cannot, by themselves, do planning or self-verification (which is after all a form of reasoning)" [1] (Traducción: Sostenemos que los LLM autorregresivos no pueden, por sí mismos, planificar ni autoverificarse —lo cual es, al fin y al cabo, una forma de razonamiento). El respaldo empírico es igual de tajante. En Game of 24, coloreado de grafos y tareas clásicas de planificación, Stechly et al. encontraron que dejar que el modelo critique sus propias respuestas hacía las cosas peor: "We observe significant performance collapse with self-critique and significant performance gains with sound external verification" [2] (Traducción: Observamos un colapso significativo del desempeño con la autocrítica, y mejoras significativas con verificación externa rigurosa). Un estudio complementario concluyó que "self-critiquing appears to diminish plan generation performance, especially when compared to systems with external, sound verifiers" [3] (Traducción: la autocrítica parece disminuir el desempeño en la generación de planes, especialmente en comparación con sistemas que cuentan con verificadores externos rigurosos). En palabras simples: que un LLM revise a otro LLM es un rumor verificando a otro rumor.

La segunda mitad: los LLM son sorprendentemente buenos para escribir el problema. OptiMUS, el sistema de Stanford, convierte descripciones en lenguaje natural en programas lineales de enteros mixtos y "can develop mathematical models, write and debug solver code, evaluate the generated solutions, and improve its model and code based on these evaluations" [4] (Traducción: puede desarrollar modelos matemáticos, escribir y depurar código para el solver, evaluar las soluciones generadas, y mejorar su modelo y código a partir de esas evaluaciones), superando al estado del arte previo por un 20-30%. Chain-of-Experts, presentado en ICLR 2024, propuso "the first LLM-based solution, namely Chain-of-Experts (CoE), a novel multi-agent cooperative framework to enhance reasoning capabilities" [5] (Traducción: la primera solución basada en LLM, llamada Chain-of-Experts (CoE), un novedoso marco cooperativo multiagente para mejorar las capacidades de razonamiento) para el modelado complejo en investigación de operaciones; para 2025, OR-LLM-Agent había descompuesto el pipeline en "three sequential stages: mathematical modeling, code generation, and debugging" [6] (Traducción: tres etapas secuenciales: modelado matemático, generación de código y depuración), superando a los modelos generales de punta en benchmarks de investigación de operaciones. La formulación —esa traducción tediosa y propensa a errores de una situación caótica en variables de decisión y restricciones— es justo la parte que los humanos odian y en la que los modelos brillan.

Y el ejemplo que demuestra que el matrimonio funciona: AlphaGeometry alcanzó un desempeño cercano al oro olímpico con un sistema que "uses a neural language model, trained from scratch on our large-scale synthetic data, to guide a symbolic deduction engine through infinite branching points" [7] (Traducción: usa un modelo de lenguaje neuronal, entrenado desde cero con nuestros datos sintéticos a gran escala, para guiar un motor de deducción simbólica a través de puntos de ramificación infinita). La mitad neuronal propone en los puntos donde la búsqueda explota; la mitad simbólica deriva con certeza. Veinticinco problemas resueltos, frente a los diez que logró el mejor sistema puramente simbólico. Ninguna de las dos mitades por separado se acerca.

Una pieza más, porque mi planificador está construido sobre ella: el control de horizonte retráctil —planificar una ventana, actuar, observar la realidad, replanificar desde donde realmente estás— no es un truco exclusivo de la robótica. Es un paradigma general de toma de decisiones; trabajos recientes modelan cadenas de suministro competitivas completas como agentes donde "every agent re-plans their actions in a receding horizon manner based on estimates of market and supplier parameters" [8] (Traducción: cada agente replanifica sus acciones de manera retráctil, con base en estimaciones de los parámetros de mercado y de proveedores).

Los tres sistemas en mi mesa de trabajo

No llegué a esta pregunta desde la literatura. Llegué a ella con tres artefactos en la mano, cada uno dueño de una pieza, construidos con años de diferencia sin saber que eran partes de una sola máquina.

El solver: Life GPS (2019, público). Conté la historia completa en el ensayo anterior: un planificador semanal que trata tu semana como una cuadrícula de franjas horarias y resuelve sobre ella un programa lineal de enteros binarios —variables de decisión x[slot,task] ∈ {0,1}, función objetivo = cumplimiento ponderado, restricciones = una tarea por franja, pisos y techos por tarea, plazos. El motor en Python, ya reescrito (allocator.py, PuLP + CBC), contiene la parte que más importa: replan() congela el pasado, resta de cada presupuesto lo que realmente gastaste, y vuelve a resolver el horizonte restante — Model Predictive Control, aplicado a una vida. Y aquí está el detalle que solo aprecié mientras investigaba para este artículo: la reescritura ya tiene dos costuras para LLM. intake() acepta un llm_fn inyectado que convierte "envía mi MVP, medita a diario, cinco días, ocho horas" en un PlanRequest; explain() valida y traduce la cuadrícula resuelta de vuelta a oraciones. La integración que sigue no es una propuesta para atornillarle IA a un solver. Los enchufes ya están en la pared.

El estratega (privado). Un sistema operativo de estrategia que mantengo de código cerrado: ejecuta un pipeline disciplinado que va desde el diagnóstico (un núcleo al estilo Rumelt: ¿qué está pasando realmente?), pasando por conjuntos de opciones genuinamente distintas, escenarios de estrés y respuestas competitivas, y llega a un nodo de decisión que está siempre firmado por un humano — con cada afirmación condicionada a evidencia, y la ejecución rastreada con métricas líderes y trampas (tripwires) que se activan cuando se rompe un supuesto. Lo que produce, en términos de optimización, es precisamente lo que un solucionador no puede producir por sí mismo: el objetivo (qué valorar, con evidencia detrás de cada peso) y el conjunto de restricciones (qué reglas rigen, y por qué).

La prueba de que no es un juguete (privado). El primer compromiso real del motor de estrategia funciona a través de un centro de equipo con acceso segmentado por rol — una iniciativa activa con un cliente cuyo registro de evidencia, opciones y plan de 90 días fluyen todos del mismo pipeline. Esto importa aquí por una razón: los pesos y restricciones de un proyecto real vienen acompañados de evidencia nombrada y una firma humana, no de las vibras de un modelo.

La arquitectura: tres capas, dos relojes

Pon la investigación y los artefactos uno junto al otro y el diseño casi se escribe solo.

Capa 1 — el estratega (reloj lento: semanas, o cuando se activa una trampa/tripwire). El razonamiento del modelo de lenguaje, con humanos en los nodos de decisión, produce el enunciado del problema: qué iniciativas existen, cuánto vale cada una (un peso, con la evidencia que lo justifica), cuáles son los pisos, techos, plazos y dependencias. Esta es la lección de OptiMUS generalizada: la superpotencia del modelo es la formulación. Es quien escribe el programa lineal.

Capa 2 — el solucionador (reloj rápido: diario, o en cada chequeo). El programa entero binario asigna horas y dólares bajo el conjunto de restricciones, y el bucle de MPC resuelve de nuevo a partir de los datos reales. El solucionador es el "external sound verifier" (Traducción: el verificador externo riguroso)external sound verifier (verificador externo y riguroso) que los estudios de autocrítica exigen [2][3]: no se le puede convencer de abandonar una restricción, no puede alucinar una hora que no existe, y cuando el problema es inviable lo dice, en vez de escribir algo plausible.

Capa 3 — los sensores. La telemetría cierra ambos bucles: pruebas que pasan, métricas que se mueven, tareas que se completan (en mi stack, los reportes calificados por evidencia que cada repositorio ya emite). Los sensores baratos son lo que convirtió esto de un juguete de 2019 en un sistema en vivo — la retroalimentación que un humano antes tecleaba a mano dos veces al día ahora se archiva sola.

Los dos relojes son la parte que a la mayoría de los diseños se les escapa. La replanificación táctica (el reloj del solucionador) y la replanificación estratégica (el reloj del estratega) son operaciones distintas con costos distintos. Resolver de nuevo la asignación toma milisegundos y es seguro hacerlo cada hora. Reescribir el objetivo es costoso y peligroso hacerlo de forma reactiva — por ese camino se llega al thrashing. Por eso la escalada es explícita: el solucionador resuelve de nuevo dentro del enunciado del problema actual hasta que una tripwire — un factor de ruptura de supuestos nombrado y pre-registrado — se activa y le devuelve la pluma al estratega. Ese es el patrón de horizonte retráctil aplicado dos veces, en dos horizontes [8].

El contrato de la costura

Todo lo anterior vive o muere en la costura, así que hagamos de la costura un contrato:

• Los pesos bajan solo con evidencia y una firma. El modelo puede proponer que "la iniciativa A vale 3× la iniciativa B"; la propuesta lleva su evidencia; un humano la firma antes de que el solucionador siquiera la vea. Un peso sin firmar no entra en la función objetivo.
• El modelo formula; nunca verifica. Traducir a variables de decisión, restricciones, código del solucionador: ese es el trabajo del modelo [4][5][6]. Verificar factibilidad y optimalidad: ese es el trabajo del solucionador, estructuralmente — no un prompt que le pide al modelo que se revise a sí mismo [1][2].
• El modelo explica los números del solucionador, nunca los suyos propios. explain() convierte la cuadrícula resuelta en oraciones. La disciplina: narra lo que se resolvió. Si la narración y la cuadrícula no coinciden, gana la cuadrícula.
• Los objetivos no medibles se quedan fuera de la función objetivo. Si una meta todavía no tiene métrica, aparece como "aún no medible — definir la métrica", nunca como un coeficiente inventado. Un término del objetivo que nadie puede medir es justo lo que enseña a los tableros a adular.

El modo de falla: blanquear suposiciones como si fueran autoridad

Aquí está el peligro del que nadie te advierte, y la razón por la que el contrato de arriba es estricto. El resultado de un solucionador se siente autoritativo — al fin y al cabo, es demostrablemente óptimo. Pero es demostrablemente óptimo para el problema que se le dio. Dale pesos que un modelo alucinó y te devolverá basura óptima y precisa, con toda la confianza del mundo — y esa precisión hará que la basura resulte más persuasiva de lo que jamás fue la suposición cruda del modelo. El solucionador blanquea la suposición y la convierte en autoridad.

Tres mitigaciones, todas baratas:

• Pesos con compuerta de evidencia (arriba): sin firma, no hay coeficiente.
• Análisis de sensibilidad como resultado de primera clase: cada plan sale acompañado de la pregunta "which weight, if wrong by 2×, flips this plan?" (Traducción: ¿qué peso, si estuviera equivocado por un factor de 2×, hace fracasar este plan?). Si la respuesta es "the one weight we're least sure of" (Traducción: justo el peso del que menos estamos seguros), el plan es una hipótesis, no un cronograma — y el panel debería decirlo así.
• Probabilidades honestas, acotadas: cualquier probabilidad que se le muestra a un humano proviene de comparar la velocidad observada contra la velocidad necesaria, y queda acotada lejos de la certeza absoluta. La primera lectura de mi propio panel bajo esta regla fue un crudo 2% en una meta de ingresos — que es exactamente el número que te hace cambiar los insumos en lugar de admirar la interfaz.

Lo que funciona hoy, y lo que sigue

Una v0 de esta arquitectura salió en vivo hoy en el panel de propietario de mi portafolio: tres líneas de metas con hitos fechados, la flota de iniciativas como grafo de dependencias, y los mejores próximos 1-3 movimientos re-resueltos a partir de la telemetría en vivo de las tarjetas de reporte en cada carga — incluyendo viaje en el tiempo que reproduce lo que el instrumento habría dicho en cualquier día anterior. Su re-solucionador sigue siendo un puntuador voraz (greedy), no el programa entero completo; el camino para reemplazarlo es corto porque Life GPS ya expone /plan y /replan por HTTP. El orden de construcción, una sesión de trabajo por cada paso: (1) cambiar el puntuador voraz por el BILP detrás de la API con compuerta de propietario; (2) dejar que el motor de estrategia redacte el archivo de pesos de la misma forma en que redacta un compromiso con cliente — con evidencia adjunta y firma humana; (3) registrar trampas (tripwires) para que las re-resoluciones estratégicas se disparen por eventos, no por calendario. Meta: las tres costuras en vivo dentro de dos semanas (para el 2026-08-18). Cada paso es pequeño porque cada pieza ya funciona; el trabajo está en la costura, que es la tesis.

Patrones / Antipatrones

• Patrón: lo neuronal propone, lo simbólico dispone — en cada punto de ramificación infinita, y solo ahí [7].
• Patrón: dos relojes — la asignación se re-resuelve rápido y barato; los objetivos se re-resuelven lento, ante trampas (tripwires).
• Patrón: el verificador es estructural (un solucionador, una prueba, una compuerta), nunca un segundo prompt.
• Antipatrón: pedirle al modelo que planifique y que revise el plan — un rumor auditando a otro rumor [2][3].
• Antipatrón: un optimizador alimentado con pesos sin firmar — basura óptima, blanqueada por precisión.
• Antipatrón: un solo reloj — ya sea estrategia agitándose a diario o asignación congelada trimestre tras trimestre.

Procedencia — qué está verificado y qué es mío

Las ocho citas de investigación fueron verificadas palabra por palabra contra las fuentes listadas al momento de la publicación (el resumen de Nature exige un user-agent de navegador para poder consultarse). Life GPS es mi propio código público, descrito a partir de su repositorio. El motor de estrategia y el compromiso con su cliente son mis sistemas privados, descritos solo a nivel de capacidades — sin detalles internos, conforme a sus licencias. El panel, su re-solucionador voraz y la lectura del 2% están en vivo, con compuerta de propietario, y son míos.

Referencias

1. Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S., Saldyt, L., & Murthy, A. (2024). Position: LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks. (Traducción: Posición: los LLM no pueden planificar, pero pueden ayudar a planificar en marcos LLM-Modulo). ICML 2024. arxiv.org/abs/2402.01817
2. Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks. (Traducción: Sobre las limitaciones de autoverificación de los modelos de lenguaje grandes en tareas de razonamiento y planificación). arxiv.org/abs/2402.08115
3. Valmeekam, K., Marquez, M., & Kambhampati, S. (2023). Can Large Language Models Really Improve by Self-critiquing Their Own Plans? (Traducción: ¿Pueden los modelos de lenguaje grandes mejorar realmente autocriticando sus propios planes?). arxiv.org/abs/2310.08118
4. AhmadiTeshnizi, A., Gao, W., & Udell, M. (2024). OptiMUS: Scalable Optimization Modeling with (MI)LP Solvers and Large Language Models. (Traducción: OptiMUS: modelado de optimización escalable con solucionadores de (MI)LP y modelos de lenguaje grandes). ICML 2024. arxiv.org/abs/2402.10172
5. Xiao, Z., Zhang, D., et al. (2024). Chain-of-Experts: When LLMs Meet Complex Operations Research Problems. (Traducción: Chain-of-Experts: cuando los LLM se encuentran con problemas complejos de investigación de operaciones). ICLR 2024. iclr.cc/virtual/2024/poster/18977
6. Zhang, B., Luo, P., Yang, G., Soong, B. H., & Yuen, C. (2025). OR-LLM-Agent: Automating Modeling and Solving of Operations Research Optimization Problems with Reasoning LLM. (Traducción: OR-LLM-Agent: automatización del modelado y resolución de problemas de optimización de investigación de operaciones con un LLM de razonamiento). arxiv.org/abs/2503.10009
7. Trinh, T., Wu, Y., Le, Q., He, H., & Luong, T. (2024). Solving olympiad geometry without human demonstrations. (Traducción: Resolver geometría olímpica sin demostraciones humanas). Nature 625. nature.com/articles/s41586-023-06747-5
8. Hall, S., Guerrini, L., Dörfler, F., & Liao-McPherson, D. (2024). Receding Horizon Games for Modeling Competitive Supply Chains. arxiv.org/abs/2401.09853

Relacionado

• Construí el cerebro de mi empresa en 2019 y lo confundí con una lista de tareas — parte 1: la confesión, y el marco de MPC sobre el que se construye este artículo.
• Construimos una máquina que discute con nosotros — la misma disciplina de verificador-no-intuición, aplicada a las afirmaciones de entregas.
• Estrategia como código — por qué la capa del estratega es datos y compuertas, no diapositivas.

Parte 2 de la serie company-GPS. El paquete de investigación (ocho fuentes, citas verificadas textualmente mediante consulta directa al momento de la publicación) se armó el 2026-08-04. — Paul Jialiang Wu · agentic-portfolio-lovat.vercel.app