GPT-4 falló el 99.4% de las veces, así que dejamos de dejarle tomar decisiones

Era casi medianoche y observaba cómo nuestro agente reservaba un vuelo a la ciudad equivocada por tercera vez consecutiva.

No una ciudad equivocada distinta cada vez: la misma ciudad equivocada. Delhi en lugar de Dehradun. El usuario había escrito "Dehradun" con claridad. El LLM lo había interpretado correctamente en su razonamiento de cadena de pensamiento. Y luego, cuando generó la llamada a la API, lo sustituyó por el código de aeropuerto de Delhi. Con confianza. En silencio. Tres veces.

Mi cofundador estaba en la llamada. Dijo: "Sabe la respuesta correcta. Mira el rastro de razonamiento. Dice literalmente Dehradun. Y luego hace otra cosa."

Esa fue la noche en que dejé de creer que unos mejores prompts nos salvarían.

Habíamos estado construyendo un agente de IA para reservas de viajes: de esos que se comunican con Sistemas de Distribución Global como Amadeus y Sabre, esos antiguos backends de la era de los mainframes que impulsan cada reserva de aerolínea del planeta. Y habíamos estado haciendo lo que todos los demás hacían en 2023: envolver GPT-4 en una fina capa de orquestación, darle herramientas y rezar.

Los rezos no funcionaban.

El número que lo cambió todo

Unas semanas después de aquel incidente de Dehradun, me topé con el benchmark TravelPlanner: una rigurosa evaluación académica que pone a prueba a los LLM en la planificación de itinerarios de varios días con restricciones reales: presupuestos, transporte, comidas, alojamiento. El tipo de cosa que un agente de viajes competente hace en veinte minutos.

La tasa de éxito global de GPT-4: 0.6%.

No 60%. No 6%. Cero coma seis por ciento.

Lo leí tres veces. Luego consulté la metodología para asegurarme de que no hubieran cometido un error. No lo habían cometido. Cuando le pides al modelo de lenguaje más avanzado del mundo que planifique un viaje que respete un presupuesto, conecte vuelos con hoteles y restaurantes, y no viole la lógica temporal básica, falla el 99.4% de las veces.

Cuando se le pidió a GPT-4 que planificara viajes con restricciones del mundo real, tuvo éxito el 0.6% de las veces. Un agente neuro-simbólico que resolvía el mismo problema obtuvo un 97%.

El sistema que obtuvo un 97% no usó un modelo más inteligente. Usó una arquitectura fundamentalmente distinta: una en la que el LLM traducía la petición del usuario a datos estructurados, y luego un solucionador determinista hacía la planificación real. El LLM era el traductor. El código era el cerebro.

Ese benchmark no solo validó nuestra frustración. Nos dio un plano a seguir.

¿Por qué tu agente de IA sigue fallando?

Esto es lo que nadie en la fiebre del oro de los "agentes de IA" quiere admitir: Los LLM no razonan. Predicen.

Cuando GPT-4 "decide" llamar a una API de búsqueda, no está ejecutando lógica. Está prediciendo el siguiente token estadísticamente más probable según los patrones de sus datos de entrenamiento. En una conversación, esa predicción suele ser suficiente. ¿En un flujo de trabajo de API de diez pasos donde cada paso depende de la salida exacta del anterior? Es un desastre.

Empecé a llamar a esto el problema de la Cadena de Probabilidad. Supón que tu LLM acierta cada paso el 90% de las veces —una estimación generosa para el uso complejo de herramientas—. Aquí están las matemáticas:

• 1 paso: 90% de éxito
• 5 pasos: ~59% de éxito
• 10 pasos: ~34% de éxito

Un flujo de trabajo de reserva de vuelos —buscar, filtrar, seleccionar, tarificar, recopilar datos del pasajero, crear el PNR, validar, pagar, emitir el billete— supera habitualmente los diez pasos. Con un 34% de éxito teórico, no estás construyendo software. Estás construyendo una máquina tragamonedas.

Y el 34% es el techo. El rendimiento en el mundo real es peor debido a dos fenómenos con los que chocábamos constantemente en producción.

La cascada de alucinaciones

El primero es lo que yo llamo la Cascada de Alucinaciones. En una arquitectura encadenada, la salida del Paso 2 se convierte en la entrada del Paso 3. Si el LLM comete un error sutil al principio —leyendo mal la hora de llegada de un vuelo como 2:00 PM en lugar de 2:00 AM—, ese error no se detecta. Se propaga. El agente reserva el registro de entrada de un hotel para el día equivocado basándose en la hora alucinada. La API del GDS no conoce la intención del agente, solo su entrada, así que procesa la petición con éxito. El agente ve una respuesta 200 OK y refuerza su propio error.

Acabas con un rastro de ejecución "exitoso" que produce un resultado catastrófico en el mundo real. El agente cree que lo clavó. El cliente se presenta en el aeropuerto y descubre lo contrario.

El segundo fenómeno es la Deriva de Contexto. A medida que el agente avanza en un plan de varios pasos, la ventana de contexto se llena de datos intermedios: resultados de búsqueda, respuestas de API, mensajes del usuario. El mecanismo de atención del modelo se reparte cada vez más fino entre todos esos tokens. Para el Paso 10, ha "olvidado" efectivamente la restricción de presupuesto que había identificado correctamente en el Paso 2. Las puntuaciones de atención, gobernadas por la función softmax, se diluyen entre demasiados tokens irrelevantes.

Vi cómo esto ocurría en directo durante una demostración para un posible socio. El agente encontró un hotel dentro del presupuesto en el Paso 3. Para el Paso 8, al seleccionar un restaurante, había perdido por completo la noción del presupuesto restante. Recomendó un lugar que habría superado el límite de gasto del usuario en un 40%. El socio se volvió hacia mí y dijo: "Entonces simplemente... ¿se olvida?"

Sí. Simplemente se olvida.

¿Qué ocurre cuando la IA se encuentra con un mainframe?

Para entender de verdad por qué necesitábamos un enfoque diferente, hay que entender cómo es trabajar con los Sistemas de Distribución Global.

Amadeus, Sabre, Travelport: son la columna vertebral del transporte aéreo mundial. Se diseñaron en la era de los mainframes y se comportan como tal. Una reserva de vuelo no es una única llamada a la API. Es una máquina de estados finitos con una secuencia precisa de operaciones que no pueden reordenarse, omitirse ni aproximarse.

Te autenticas y obtienes un token de sesión. Ese token debe pasarse en cada encabezado posterior: si el LLM lo "olvida" o alucina uno nuevo, se pierde todo el contexto de la transacción. Luego buscas vuelos, y el GDS devuelve enormes cargas JSON anidadas —a menudo de más de 50KB— que contienen códigos de base tarifaria, modelos de equipaje, referencias de segmentos. El LLM necesita extraer un offerId específico de esa carga para continuar. Pero los LLM son compresores con pérdidas. Resumen. Truncan. "Amablemente" normalizan formatos de datos que el GDS exige que sean exactos, hasta el último byte.

Una noche pasamos cuatro horas depurando un fallo de reserva. El LLM había "corregido" un código de base tarifaria: cambió una letra minúscula por mayúscula, porque eso le parecía más "correcto" a un modelo entrenado con texto en inglés. El GDS lo rechazó con un error críptico: ERR 1209 - SEQUENCE ERROR. Sin explicación. Sin sugerencia. Solo un muro.

Los LLM son compresores con pérdidas. Cuando transfieren datos entre llamadas a la API, "autocorrigen" y "normalizan" de formas que rompen la integridad criptográfica que exigen los sistemas empresariales.

Y cuando el GDS devuelve un error como UC (Unable to Confirm, imposible de confirmar), el LLM no tiene ni idea de qué hacer. Está entrenado para ser servicial, así que interpreta el error como un fallo puntual y reintenta exactamente la misma petición. Una y otra vez. Vimos a agentes consumir miles de tokens y alcanzar los límites de frecuencia de la API, atascados en lo que empezamos a llamar el "Bucle de la Muerte": golpeándose una y otra vez contra un muro que no podían entender.

La noche en que le dimos la vuelta a la arquitectura

El punto de inflexión llegó durante una discusión.

Llevábamos tres meses de proyecto. Mi responsable de ingeniería quería seguir mejorando los prompts: mensajes de sistema más largos, más ejemplos, instrucciones de cadena de pensamiento. "Estamos muy cerca", repetía. "Si tan solo estructuramos mejor el prompt para el paso de creación del PNR..."

Consulté nuestros registros. La semana anterior habíamos tenido 47 intentos de reserva fallidos en nuestro entorno de pruebas. Once fueron el Bucle de la Muerte. Nueve fueron códigos de aeropuerto alucinados. Seis fueron el LLM intentando confirmar un PNR antes de añadir el campo obligatorio "Received From": un error de secuencia que ninguna cantidad de prompting parecía resolver, porque el modelo no tenía un concepto inherente del orden temporal más allá de lo que había absorbido de los datos de entrenamiento.

"No estamos cerca", dije. "Estamos en el techo. La arquitectura es el problema."

Esa semana lo reescribimos todo. Dejamos de pedirle al LLM que orquestara. Dejamos de permitir que decidiera qué paso venía después. Dejamos de darle respuestas del GDS en bruto con la esperanza de que extrajera los campos correctos.

En su lugar, construimos un grafo.

Para el desglose técnico completo de lo que construimos y por qué, escribí un artículo de investigación detallado que profundiza en la arquitectura.

¿Cómo funciona realmente la IA neuro-simbólica?

La idea central es engañosamente simple: el flujo de control no es una tarea de lenguaje.

Decidir qué hacer a continuación en un proceso de negocio rígido no debería ser cuestión de predicción de tokens. Debería ser cuestión de lógica condicional. La decisión de "solicitar el pago" solo debería activarse si "el vuelo está seleccionado" Y "el precio está confirmado". Eso es una condición booleana, no una sugerencia probabilística.

Dividimos nuestro sistema en dos capas:

El LLM se convirtió en la capa de interfaz: el traductor. Analiza el lenguaje natural del usuario ("Quiero un vuelo por la mañana a Dehradun, no demasiado caro") y lo convierte en datos estructurados: {origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}. Eso es en lo que los LLM son realmente buenos: entender la intención humana desordenada.

El grafo se convirtió en la capa de ejecución: el gestor. Recibe esos datos estructurados y ejecuta la lógica de negocio mediante código determinista. Nodos codificados de forma fija. Esquemas de estado tipados. Aristas condicionales que inspeccionan variables, no intuiciones.

Usamos LangGraph para construir esto, porque te da las primitivas que necesitas: un esquema de estado compartido (respaldado por una base de datos, no por un historial de chat), nodos que son simplemente funciones de Python y aristas condicionales que enrutan según los valores reales de las variables.

El LLM debería ser el trabajador —extrayendo datos, resumiendo texto, dando formato a JSON— mientras que el gestor debería ser software codificado de forma fija. Esta inversión de control es la característica definitoria de los sistemas agénticos robustos.

En nuestra arquitectura, el LLM literalmente no puede saltarse pasos. Es físicamente imposible que el sistema intente una reserva antes de que la variable selected_offer_id se rellene en el estado. No porque le dijéramos al LLM "no hagas eso" en un prompt, sino porque la arista del grafo no se activará. Es como intentar atravesar un muro conduciendo: el código simplemente no lo permite.

¿Qué aspecto tiene el sistema real?

Déjame guiarte por lo que ocurre cuando alguien dice: "Resérvame un vuelo de Bombay a Londres el próximo martes".

Primero, un nodo Collector —impulsado por un LLM— analiza esa frase y la convierte en campos estructurados. Usa generación guiada (JSON Mode) para producir un esquema específico. Un validador de Python comprueba si los códigos de aeropuerto son reales. "Londres" es ambiguo —¿Heathrow o Gatwick?—, así que el grafo dirige a un nodo de desambiguación. El LLM no adivina. Pregunta.

Una vez que tenemos criterios de búsqueda validados, un nodo Retriever llama a la API de Amadeus. Esto es código puro. Sin LLM de por medio. La respuesta regresa, se almacena en caché en el estado, y solo entonces un nodo Summarizer —un LLM— convierte los cinco mejores resultados en un mensaje legible para humanos. Pero está estrictamente limitado: solo puede mostrar datos presentes en el JSON almacenado en caché. No puede inventar ventajas ni cambiar precios.

El usuario elige una opción. Un nodo Selector resuelve "el segundo" al hash offer_id específico. Un nodo Gatekeeper comprueba las reglas de negocio: ¿está dentro de la política corporativa? ¿La aerolínea está en la lista negra? Si hay una violación, el grafo se suspende. Persiste su estado en la base de datos, envía una solicitud de aprobación a un responsable y espera. Horas más tarde, cuando el responsable hace clic en "Aprobar", el grafo recarga el estado exacto y se reanuda en el nodo de reserva.

Por último, un nodo Transactor ejecuta la secuencia de creación del PNR —segmentos, datos del pasajero, tarificación, confirmación— en el orden exacto que exige el GDS. Si el GDS devuelve una advertencia de cambio de precio (habitual en los viajes), el nodo se detiene y pide al usuario que confirme. No reserva automáticamente a la tarifa más alta.

Cada transición de nodo se registra. Cada decisión es rastreable. Un auditor puede leer el registro de ejecución y entender exactamente por qué el sistema reservó un vuelo concreto: no interpretando un revoltijo de tokens, sino leyendo un registro estructurado: Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL.

Escribí sobre la arquitectura completa, incluidos los diagramas interactivos, en la versión interactiva del whitepaper.

¿No es esto simplemente... ingeniería de software normal?

La gente me pregunta esto constantemente. "Entonces, ¿dices que deberíamos escribir código en lugar de usar IA? Revolucionario."

No. Digo que la industria de la IA ha estado tan embriagada por la magia de los modelos de lenguaje que olvidó los últimos sesenta años de las ciencias de la computación. Máquinas de estados, esquemas tipados, ramificación condicional, integridad transaccional: no son conceptos obsoletos. Son la razón por la que tu banco no transfiere dinero por accidente a la cuenta equivocada.

El enfoque neuro-simbólico no es anti-IA. Es pro-arquitectura. Usamos los LLM de forma agresiva: para el análisis de intenciones, para la desambiguación, para el resumen, para abordar el problema genuinamente difícil de entender lo que un humano quiere decir cuando escribe algo ambiguo. Pero no dejamos que el LLM toque el volante cuando el coche va por la autopista.

Puedes construir un chatbot que habla de hacer el trabajo, o puedes diseñar la arquitectura de un agente que hace el trabajo. La diferencia es el grafo.

También hay un argumento de coste que me sorprendió. Los agentes puramente basados en LLM son caros, no porque la inferencia sea costosa por llamada, sino por los bucles de fallo. Cuando un agente se queda atascado reintentando un error del GDS mediante la alucinación de nuevos parámetros, quema miles de tokens antes de agotar el tiempo de espera. Una sola sesión atascada puede costar $5-$10 en créditos de API. Nuestros gestores de errores codificados de forma fija capturan esos fallos con cero coste de tokens. Y como solo enviamos al LLM los 5 campos relevantes de una respuesta del GDS de 50KB en lugar de la respuesta completa, reducimos el uso de la ventana de contexto en aproximadamente un 90%.

¿Pero no llegarán los modelos a ser lo bastante buenos con el tiempo?

Puede. Realmente no sé si GPT-6 o GPT-7 serán lo bastante fiables como para orquestar flujos de trabajo de API de diez pasos sin guardrails. Pero sé dos cosas.

Primero, incluso si los modelos mejoran drásticamente, el problema de la Cadena de Probabilidad es matemático, no tecnológico. Si tu modelo es fiable al 99% por paso —un logro extraordinario—, un flujo de trabajo de diez pasos aún falla el 10% de las veces. Para las transacciones empresariales, eso sigue siendo inaceptable. El grafo elimina esto por completo porque el enrutamiento no es probabilístico.

Segundo, esperar a que los modelos mejoren es un lujo que la mayoría de las empresas no se pueden permitir. Necesitan agentes que funcionen ahora, que sean auditables ahora, que cumplan con los requisitos de transparencia de la Ley de IA de la UE ahora. El enfoque neuro-simbólico no apuesta por el futuro. Se basa en principios de ingeniería probados mientras utiliza las mejores capacidades de IA disponibles hoy.

La arquitectura es el producto

He estado en suficientes salas con inversores y compradores empresariales como para saber que la industria de la IA está empezando a despertar. La pregunta está pasando de "¿Quién tiene el modelo más inteligente?" a "¿Quién tiene el sistema más robusto?". Las demostraciones que deslumbran en una charla de conferencia —esas en las que un agente reserva un vuelo sin fallos en un entorno controlado— son baratas. Lo caro, y lo que importa, es construir algo que funcione en la petición número diez mil con la misma fiabilidad que en la primera.

Estamos entrando en una era en la que la diferenciación no será el modelo. Será el grafo. El esquema de estado. Los gestores de errores. Las aristas condicionales. La aburrida, rigurosa y determinista ingeniería de software que envuelve la magia probabilística y evita que incendie la casa.

La magia nunca estuvo en el prompt. Siempre estuvo en la arquitectura.