No dejes que un LLM tome decisiones ni ejecute lógica de negocio

Argumento central: hay que salir del LLM lo más rápido posible y no permanecer ahí mucho tiempo

• No se debe encargar al LLM la toma de decisiones ni la lógica de negocio → carece de precisión y estabilidad suficientes
• En la mayoría de los casos, el LLM solo debería actuar como la interfaz entre el usuario y la API de la aplicación
• La lógica central debe ejecutarse en sistemas o motores dedicados, y el LLM solo debe encargarse de convertir la solicitud del usuario en una llamada a la API y luego volver a convertir el resultado en lenguaje natural

¿Por qué?

• Ejemplo de un bot de ajedrez: un usuario envía por WhatsApp "captura al caballo con mi alfil" → el LLM podría mantener el estado del tablero y también jugar, pero habría muchos problemas en términos de confiabilidad, rendimiento y mantenimiento

• Rendimiento: aunque la capacidad de un LLM para jugar ajedrez es sorprendente, sigue siendo más lento y menos preciso que un motor de ajedrez especializado (por ejemplo, Stockfish)

• No se puede depurar ni ajustar: como es difícil saber por qué tomó esa decisión, también es difícil corregirlo para que funcione de la manera prevista

• Otros problemas:

  • La salida de un LLM es difícil de probar
  • Tiene bajo rendimiento en matemáticas o generación de números aleatorios
  • El control de versiones y la auditoría son difíciles
  • Mantener el estado en lenguaje natural es frágil
  • Surgen problemas como tarifas de API y límites de velocidad
  • Los límites de seguridad se vuelven difusos

La separación correcta de funciones vista con varios ejemplos

• En un juego, "quiero atacar al jugador X con la espada vorpal" → el LLM solo debería convertir esto a una forma como attack(player=X, weapon="vorpal_sword") y pasarlo a la lógica del juego
• Agente de negociación → el LLM no toma decisiones de negociación; solo empaqueta la entrada del usuario, la pasa al motor de negociación y entrega el resultado
• Generación de respuestas aleatorias → no debería elegir el LLM, sino que debe manejarse con una función aleatoria externa

En qué son buenos los LLM

• Los LLM se especializan en transformación, interpretación y comunicación
• Ejemplos:
  • "golpear al orco con una espada" → convertirlo a attack(target="orc", weapon="sword")
  • { "error": "insufficient_funds" } → explicarlo de forma natural como "No tienes suficiente oro"
  • Pueden clasificar si la entrada del usuario es un comando de combate, una consulta de inventario o una solicitud de ayuda
  • Entienden bien conceptos humanos (por ejemplo, blade = sword, smash = attack)
• La clave es que no se encargan de juicios complejos ni de la gestión del estado → solo actúan como un puente que conecta la intención del usuario con el sistema

Perspectivas futuras y principios que siguen vigentes

• La tecnología está avanzando rápidamente, así que lo que hoy es imposible pronto podría ser posible
• Sin embargo, es muy probable que sigan existiendo problemas estructurales que un LLM no puede resolver:
  • La lógica que no usa LLM es más fácil de entender y más sencilla de mantener y versionar
  • El costo de ejecución también es más bajo
• Incluso en el futuro, los LLM deberían concentrarse en el papel de interfaz, y la lógica central debería dejarse a sistemas dedicados

[GN⁺]

Opinión de Hacker News

• Hay dos tipos de lógica

  • 1. Lógica que debe ser intrínsecamente correcta y estricta
  • 2. Lógica que ha sido así por la naturaleza de las computadoras

• El tipo 1 corresponde a áreas como seguridad, finanzas y matemáticas

• Es muy probable que la IA sustituya el tipo 2

• Distintas partes de una misma aplicación pueden ser adecuadas para el tipo 1 o el tipo 2

• Hace poco, en un hackatón, creó un juego educativo

  • Usó un LLM para generar y ejecutar el juego, pero el flujo del juego no era bueno
  • Al final, gestionó el estado del juego con mucho código en Python y varios prompts
  • Lo mejor es usar el LLM como una pieza pequeña dentro de un sistema grande

• Un LLM no debería implementar la lógica

  • La lógica, la optimización y la programación con restricciones son técnicas distintas
  • El fundador de la lógica moderna es George Boole, y era el abuelo de Geoffrey Everest Hinton

• Es difícil entender las capacidades de los LLM

  • Los lectores quieren respuestas simples
  • A los LLM puede costarles escribir una máquina de estados simple
  • Los artículos de investigación están ganando popularidad, y probablemente nadie entenderá por completo los LLM ni siquiera para 2025

• Si necesitas que las respuestas del LLM sean rápidas y baratas, debes usar prompts cortos y modelos pequeños

  • Mucha información da por hecho que se usan modelos grandes
  • Una UI tradicional podría ser una mejor opción

• Es difícil hacer pruebas solo con LLM

  • El estilo de cada persona influye en la interacción
  • El costo de mantenimiento puede ser alto
  • Tiene más sentido convertirlo en llamadas a API

• Usar LLM para la lógica de negocio es riesgoso

  • Son adecuados para el procesamiento del lenguaje

• Se pueden usar imágenes generadas por IA para resumir artículos