Las puntuaciones de benchmarks ocultan fallos de LLMs en tareas multietapa

La precisión de primera respuesta de los grandes modelos de lenguaje en tareas procedurales se desmorona de 61% en algoritmos de 5 pasos a 20% en algoritmos de 95 pasos, contradiciendo directamente la suposición de que las puntuaciones de benchmark sólidas señalan ejecución confiable en flujos de trabajo de producción.

El artículo "When LLMs Stop Following Steps: A Diagnostic Study of Procedural Execution in Language Models" de Sailesh Panda, Pritam Kadasi, Abhishek Upperwal y Mayank Singh evalúa 14 modelos en 55 datasets. El benchmark es simple: los modelos reciben un algoritmo aritmético paso a paso y dos entradas numéricas y deben devolver el valor computado final. La complejidad escala a través de la longitud del algoritmo y las dependencias de look-back en variables intermedias — el desafío estructural que imponen los flujos de trabajo empresariales.

El diseño del benchmark expone una brecha que las evaluaciones de razonamiento estándar oscurecen. Las métricas de precisión de respuesta final dominan la cultura de clasificaciones pero no dicen nada sobre si un modelo ejecutó fielmente cada paso. Un modelo puede llegar a una respuesta correcta a través de heurísticas de atajo o cancelaciones afortunadas y aun así fallar catastróficamente cuando esos atajos no están disponibles en trazas más largas y de muchas dependencias. El análisis a nivel de generación revela los modos de fallo: respuestas prematuras, respuestas faltantes, autocorrección tras un error inicial, trazas sub-ejecutadas y pasos alucinados más allá de lo que especifica el algoritmo.

Para arquitectos empresariales, las implicaciones son directas. Cualquier implementación que use un LLM para ejecutar un proceso determinista multietapa — canalizaciones de ETL, listas de verificación de cumplimiento, runbooks de DevOps, flujos de trabajo de reconciliación financiera — depende de un agente cuya confiabilidad se degrada a medida que aumenta la longitud del procedimiento. Con 20% de precisión de primera respuesta en tareas de 95 pasos en 14 modelos probados, este no es un caso extremo de un solo modelo. Es un modo de fallo en toda la clase. La caída de 61% a 20% abarca 90 pasos adicionales.

La exposición práctica difiere según el caso de uso. Los flujos de trabajo cortos y acotados de cinco a diez pasos se encuentran en una zona donde la precisión se mantiene por encima del 60%. Pero las capas de orquestación que encadenan herramientas, ramas condicionales o bucles iterativos rápidamente empujan la longitud de procedimiento efectiva hacia rangos donde la probabilidad de fallo domina. Los canalizaciones de RAG con lógica de recuperación de múltiples saltos, bucles de generación de código agéntentes y playbooks de respuesta a incidentes automatizados son candidatos para confiabilidad de ejecución degradada.

Si las estrategias de prompting — chain-of-thought, aplicación de scratchpad, etiquetado de pasos explícito — pueden recuperar precisión perdida a escala sigue siendo una pregunta abierta. Los autores atribuyen el fallo en parte a "la aparente habilidad de razonamiento que oculta debilidades sustanciales en la ejecución fiel de instrucciones", señalando datos de entrenamiento y funciones objetivas en lugar de ingeniería de prompts como la solución más duradera.

Para equipos que evalúan infraestructura de LLM, la acción mínima es operacional: agregar pruebas de ejecución procedural que coincidan con el recuento de pasos y la estructura de dependencia de tus flujos de trabajo reales antes de aprobar cualquier implementación agéntente. Las puntuaciones de benchmark en MMLU o GSM8K son la señal incorrecta para este problema.