Puntos ciegos en la evaluación de los LLM: ¿por qué solo miramos el ‘conocimiento’ y no el ‘comportamiento’?
(dev.to/johnonlee)• 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.
5 comentarios
Ahora que lo pienso, el examen de admisión universitaria que evalúa a las personas también termina fijándose solo en el conocimiento y no en el comportamiento.
Si mantuviera un patrón constante, vaya y pase, pero como cambia cada vez que se usa... la verdad es que no sabía cómo evaluarlo.
Sí, es cierto. No hay una respuesta correcta, pero creo que también vale la pena verlo desde esta perspectiva. Ahora mismo se le pide a un solo modelo que haga el trabajo de principio a fin, pero me da la impresión de que mañana podría venir un cambio hacia algo donde, en distintos puntos del proceso, cada modelo se encargue solo del área en la que destaca. Aunque todos estudien mucho y terminen teniendo un nivel de conocimiento parecido hasta cierto punto, según sus patrones de comportamiento pueden surgir diferencias en el resultado final.
Como no hay una respuesta correcta y el punto clave es que el criterio humano sea preciso y use pocos recursos, ¿no sería más adecuado evaluarlo por la cantidad de tokens y el nivel de logro? Si además nos metemos hasta con el método, se vuelve muy complicado...
No es que esté mal, pero ¿hay una respuesta? Incluso en la contratación real es difícil ponerle una puntuación a eso, así que también terminan contratando personas, probándolas en el trabajo y luego despidiéndolas... igual que cuando usas un modelo de IA y después lo reemplazas.