• La evaluación de los LLM sigue estancada en el nivel de la "puntuación del SAT" — MMLU, HumanEval y SWE-bench comparten el paradigma de una sola sesión y una sola respuesta correcta. Pero los agentes de código reales trabajan a lo largo de varias sesiones, aprenden de sus errores y leen convenciones existentes. Eso no es un problema de conocimiento (knowledge), sino de comportamiento (behavior).
• Cuando contratamos personas, no miramos solo las calificaciones, sino "cómo piensan" — ¿por qué no hacemos eso en la evaluación de los LLM? Ahora mismo estamos detenidos en la etapa de "verificar el GPA", donde todos los modelos marcan percentiles por encima del 90.
• Incluso al corregir el mismo bug, el enfoque puede ser completamente distinto — El Modelo A hace grep y aplica un parche en 30 segundos (tipo prototipado), el Modelo B divide el problema en subtareas y lo aborda de forma sistemática (tipo arquitectura), y el Modelo C aprende de precedentes en git log antes de corregirlo (tipo mantenimiento). Los tres corrigen el bug. La puntuación es la misma. Pero la adecuación al rol es completamente distinta.
• Se proponen 4 dimensiones para observar el comportamiento — Decomposition (¿descompone el problema o ejecuta de inmediato?), Approach (¿busca patrones o razona desde principios?), Recovery (cuando se atasca, ¿cambia de estrategia o insiste?), Consistency (¿muestra el mismo enfoque ante problemas similares?).
Evaluación de conocimiento vs evaluación de comportamiento
| Benchmark existente | Qué mide | Qué deja fuera |
|---|---|---|
| MMLU | Cantidad de conocimiento memorizado | Criterio de aplicación, "conciencia de lo que no sabe" |
| HumanEval | Tasa de acierto en el primer intento | Depuración, iteración y proceso de adaptación |
| SWE-bench | Si el parche pasa o no | Ruta de aproximación, comprensión de arquitectura, aprendizaje entre sesiones |
2026: las preguntas que de verdad necesitamos
Ahora que los agentes de código ya no son una demo, sino herramientas reales para equipos, la pregunta que deberíamos hacernos no es "¿qué puntuación tiene?":
- "¿Qué modelo encaja mejor en el mantenimiento de sistemas legacy?"
- "¿Qué estilo de depuración funciona mejor para pair programming con desarrolladores junior?"
- "¿Qué modelo muestra el comportamiento más predecible a lo largo de semanas?"
Estas son preguntas de adecuación al rol. Son preguntas de contratación. Y nosotros seguimos intentando responderlas con puntuaciones tipo SAT.
No se presenta el framework como algo definitivo. Con una postura de "corríjanme si estoy equivocado", el autor deja explícitamente abiertas cuatro hipótesis e invita a debatir en los comentarios. El paper de Tang et al. de abril de 2026, "In-Situ Behavioral Evaluation for LLM Fairness", también apunta en una dirección similar.
Aún no hay comentarios.