💻 computer science

What Makes a Programming Problem Hard for a Language Model? An Empirical Study of Item Difficulty Across Code LLMs on Two Benchmarks

Este artículo presenta un estudio empírico que demuestra que la dificultad de los problemas en los benchmarks de generación de código es una métrica estable y transferible impulsada por características de la especificación (como ejemplos y longitud del prompt) en HumanEval y por la complejidad de la solución en MBPP, ofreciendo perspectivas críticas para mejorar la evaluación, la calificación automática y el diseño de herramientas educativas a medida que las puntuaciones agregadas de los modelos se saturan.

Autores originales: TANZIM ISLAM KHAN

Publicado 2026-07-13

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: TANZIM ISLAM KHAN

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes una biblioteca mágica de acertijos gigantesca y que has invitado a todo un zoológico de diferentes "solucionadores" de IA para intentar descifrarlos. Algunos solucionadores son pequeños hámsteres con cerebros grandes (modelos pequeños), y otros son elefantes gigantes y superinteligentes (como GPT-4). Usualmente, cuando comprobamos qué tan inteligentes son estas IA, simplemente les damos una puntuación única, como una nota final en la escuela. Pero este artículo argumenta que una nota única es aburrida y engañosa. Es como decir que un examen de matemáticas es "difícil" solo porque sacaste una C, sin preguntar: ¿Cuáles fueron las preguntas complicadas? ¿Fueron los problemas de palabras largas, o los que no tenían ejemplos?

El autor, Tanzim Islam Khan, decidió dejar de mirar la nota final y empezar a mirar los acertijos mismos. Tomó dos conjuntos famosos de acertijos de programación (llamados HumanEval y MBPP) y los pasó por un experimento masivo. Tomó las respuestas de 31 modelos de IA diferentes (que van desde modelos diminutos de 1 billón de parámetros hasta el gigante GPT-4) y volvió a ejecutar cada una de las respuestas en un entorno de pruebas (sandbox) seguro y aislado para ver si realmente funcionaba. ¡Eso son 13,400 ejecuciones!

El Gran Descubrimiento: ¿Qué hace que un acertijo sea difícil?

El artículo encontró algo sorprendente que cambia nuestra forma de pensar sobre la "dificultad".

En el conjunto HumanEval (los acertijos con descripciones largas y muchos ejemplos de respuestas), la dificultad no dependía de qué tan complicado fuera el código de la solución. Dependía enteramente de cómo estaba escrito el acertijo.

La Pista Mágica: Si el acertijo incluía ejemplos resueltos (como mostrarle a la IA: "Aquí está la entrada A, aquí está la salida B"), la IA lo resolvía fácilmente. Cuantos más ejemplos, más fácil era.
La Trampa: Si el acertijo era largo y palabrero, o si carecía de esos ejemplos útiles, la IA tenía dificultades, incluso si el código necesario para resolverlo era simple.
La Prueba: Los autores construyeron una máquina de predicción. Cuando les alimentaron solo con el texto del acertijo (el prompt), podía predecir qué tan difícil era el acertijo con un $R^2$ de 0.45 mediante validación cruzada, lo cual coincidía con el rendimiento del modelo completo. Pero cuando les alimentaron solo con la complejidad del código de la solución (como contar bucles o variables), apenas sabía nada ( $R^2$ de 0.11).

El Giro: El Otro Libro de Acertijos

Luego miraron el conjunto MBPP. Estos acertijos son diferentes; son súper cortos, como susurros de una sola frase, y no tienen ejemplos en absoluto.

¡Aquí, las reglas se invirtieron! Como cada acertijo se veía igual (corto y vago), el texto no le decía a la IA qué hacer. En su lugar, la dificultad dependía de qué tan difícil era la solución realmente.
Si el código requería una lógica compleja, la IA fallaba. Si el código era simple, la IA tenía éxito.
La Lección: Un problema es difícil para una IA basándose en la parte de las instrucciones que es más variable. Si las instrucciones varían mucho (como en HumanEval), las instrucciones mandan. Si las instrucciones son todas iguales (como en MBPP), la complejidad de la respuesta manda.

Lo que el Artículo Clarifica

El artículo argumenta explícitamente en contra de la idea de que "un código más difícil siempre equivale a un problema más difícil".

Midieron la complejidad de las soluciones de referencia (usando cosas como la "complejidad ciclomática" y el "volumen de Halstead") y encontraron que en HumanEval, estos números eran predictores mucho más débiles de la dificultad que las características del prompt. Una solución compleja no era necesariamente más difícil de generar si las instrucciones eran claras y estaban llenas de ejemplos.
También descartaron la idea de que la dificultad sea solo un golpe de suerte de qué modelos de IA se están probando. Demostraron que la dificultad es una propiedad estable del problema en sí mismo. Ya sea que pruebes a una IA del tamaño de un hámster o a una del tamaño de un elefante, los mismos acertijos siguen siendo los más difíciles y los más fáciles. Incluso comprobaron esto eliminando un modelo a la vez, y el ranking no cambió (correlación $\rho \ge 0.99$ ).

¿Qué tan seguros estamos?

Los autores están muy seguros, pero son cuidadosos con sus palabras.

Midieron esto directamente ejecutando el código 13,400 veces en un sandbox.
Demostraron la estabilidad probándolo contra una versión "fortalecida" de las pruebas (que tienen 80 veces más verificaciones para HumanEval y 35 veces más para MBPP). Incluso con estas pruebas más duras, el ranking de problemas difíciles vs. fáciles se mantuvo casi igual (correlación $\rho = 0.88$ ).
Simularon (o mejor dicho, volvieron a ejecutar) los resultados con diferentes configuraciones (como cambiar la "temperatura" para hacer a la IA más aleatoria) y encontraron que el ranking de dificultad se mantuvo constante ( $\rho = 0.87$ ).
Sugirieron que a medida que las IA se vuelvan más inteligentes y comiencen a resolver casi todo en estas pruebas antiguas (saturación), mirar qué problemas específicos siguen siendo difíciles se volverá aún más importante.

El Contexto Futuro

El artículo también echa un vistazo al "futuro" (según la línea de tiempo del artículo de junio de 2026). Observa que las IA más nuevas y superpotentes (como GPT-5.x y Claude Opus 4.8) básicamente han dejado de usar estos viejos acertijos porque son demasiado fáciles para ellas ahora. La frontera se ha movido hacia tareas de codificación del mundo real mucho más difíciles. Pero la lección sigue siendo la misma: a medida que los problemas fáciles desaparecen, entender por qué los que quedan difíciles lo son, se convierte en la clave para construir mejores herramientas.

En Resumen

Si quieres saber si un problema de codificación es difícil para una IA, no mires solo el código que necesita escribir. ¡Mira las instrucciones!

¿Instrucciones ricas con ejemplos? La IA pasará de largo sin esfuerzo, sin importar qué tan complejo sea el código.
¿Instrucciones vagas o sin ejemplos? La IA tendrá dificultades, incluso si el código es simple.
¿Instrucciones cortas, de una sola frase? Entonces la complejidad del código en sí es lo que lo hace difícil.

El artículo nos da un mapa para predecir estas dificultades sin siquiera necesidad de ejecutar la IA, simplemente leyendo el enunciado del problema. Es una herramienta para que los maestros construyan mejores ejercicios y para que los ingenieros construyan mejores benchmarks, asegurando que no solo estamos probando si una IA puede adivinar la respuesta, sino si realmente puede entender el acertijo.

Resumen Técnico: ¿Qué hace que un problema de programación sea difícil para un modelo de lenguaje?

Declaración del Problema

Las prácticas actuales de evaluación para los modelos de lenguaje de gran tamaño (LLM) generadores de código dependen en gran medida de métricas agregadas como pass@k en benchmarks como HumanEval y MBPP. Este enfoque trata todos los problemas como intercambiables, ocultando qué problemas específicos son difíciles y por qué. En consecuencia, no logra distinguir entre la capacidad general de un modelo y las características específicas de los elementos que resuelve. El artículo aborda la necesidad de tratar el problema (ítem) como la unidad de análisis, separando la dificultad del ítem de la capacidad del modelo para comprender los determinantes de la dificultad en las tareas de generación de código.

Metodología

El estudio emplea un enfoque empírico basado en datos impulsado por la Teoría de Respuesta al Ítem (IRT) y el modelado predictivo.

Fuente de Datos: Los autores utilizaron completaciones codiciosas (greedy completions) liberadas públicamente del proyecto EvalPlus. El estudio cubre 31 modelos distintos (que van desde ~1B hasta la escala de GPT-4) en HumanEval (164 problemas) y 22 modelos en MBPP (378 problemas).
Entorno de Ejecución: En lugar de confiar en puntuaciones precalculadas, los autores reejecutaron las 13,400 completaciones en un entorno Python aislado (sandboxed) con un tiempo de espera de 12 segundos. Esto generó matrices de respuesta binaria (31×164 para HumanEval; 22×378 para MBPP).
Operacionalización de la Dificultad:
- Dificultad Empírica: Definida como $1 - \text{tasa de resolución}$ (la fracción de modelos que fallan en un problema específico).
- Validación IRT: Se ajustó un modelo logístico de un parámetro (Rasch) para separar la capacidad del modelo ( $\theta$ ) de la dificultad del ítem ( $b$ ). Los autores confirmaron que la tasa de fallo bruta entre modelos correlaciona casi perfectamente ( $\rho \approx 1.00$ ) con la dificultad derivada de Rasch, validando el uso de la métrica más simple.
Extracción de Características: Se extrajeron 36 características estáticas por problema, categorizadas en:
- Características del Prompt: Longitud, legibilidad, número de ejemplos resueltos, presencia de pistas de tipo (type hints), etc.
- Características de la Solución de Referencia: Métricas de complejidad de código (complejidad ciclomática de McCabe, volumen de Halstead, recuento de nodos AST, profundidad de anidamiento, etc.).
- Características de la Suite de Pruebas: Número de aserciones, recuento de caracteres.
Análisis: El estudio utilizó análisis de correlación (Spearman/Pearson con corrección de Benjamini-Hochberg) y aprendizaje automático (regresión Ridge, Random Forests, Gradient Boosting) con validación cruzada de 10 pliegues para predecir la dificultad. La robustez se probó mediante la exclusión de un modelo (leave-one-model-out), remuestreo bootstrap, transferencia entre niveles de capacidad, re-calificación contra suites de pruebas endurecidas (HumanEval+/MBPP+) y muestreo de temperatura.

Resultados Clave

1. La dificultad es una propiedad estable y medible

Distribución: La dificultad está ampliamente distribuida, no concentrada. En HumanEval, la tasa media de resolución a través del panel de 31 modelos fue de 0.29, con algunos problemas resueltos por el 0% de los modelos y otros por el 100%.
Estabilidad: El ranking de dificultad es altamente robusto. Eliminar cualquier modelo individual deja el ranking virtualmente inalterado ( $\rho \ge 0.99$ ). El ranking también se transfiere entre niveles de capacidad (modelos débiles vs. fuertes), con correlaciones de Spearman de 0.78 (HumanEval) y 0.79 (MBPP).
Alineación con Rasch: El modelo Rasch confirma que la dificultad es una propiedad latente del ítem, independiente del panel de solvers específico utilizado.

2. La señal predictiva depende del estilo de especificación

El estudio identifica una divergencia crítica en lo que predice la dificultad entre los dos benchmarks:

HumanEval (Prompts Ricos): La dificultad es predicha principalmente por las características del prompt ( $R^2 = 0.45$ $R^{2} = 0.45$ ), lo cual coincide con el rendimiento del conjunto completo de características ( $R^2 = 0.46$ $R^{2} = 0.46$ ).
- Predictores más fuertes: El número de ejemplos de entrada-salida resueltos (correlación negativa con la dificultad) y la presencia de pistas de tipo hacen que los problemas sean más fáciles. Los prompts y docstrings más largos correlacionan con una mayor dificultad.
- Complejidad de la Solución: Las características de complejidad de la solución de referencia por sí solas explican muy poca varianza ( $R^2 = 0.11$ ).
MBPP (Prompts Tercos/Breves): La dificultad es predicha principalmente por las características de complejidad de la solución ( $R^2 = 0.13$ $R^{2} = 0.13$ ).
- Contexto: Los prompts de MBPP son uniformemente cortos, descripciones de una sola frase sin ejemplos resueltos. En consecuencia, las características del prompt tienen poca varianza para contribuir.
- Predictores más fuertes: El recuento de nodos AST y el volumen de Halstead son los correlatos dominantes. Las características de solo prompt producen un $R^2$ negativo.
Síntesis: Lo que hace que un problema sea difícil depende de qué es lo que más varía en su especificación. Si el prompt varía (HumanEval), el prompt impulsa la dificultad; si el prompt es estático (MBPP), la complejidad algorítmica impulsa la dificultad.

3. Robustez y Generalización

Pruebas Endurecidas: La re-calificación frente a HumanEval+ y MBPP+ (80x y 35x más pruebas, respectivamente) redujo las tasas de paso generales pero preservó el ranking de dificultad ( $\rho = 0.88$ y $0.82$) y la división predictiva de prompt-vs-solución.
Régimen de Decodificación: Cambiar de decodificación codiciosa a muestreo de temperatura-0.8 preservó el ranking de dificultad ( $\rho = 0.87$ ) y la distribución de la señal predictiva.
Contexto 2026: El análisis del leaderboard de EvalPlus de junio de 2026 (125 modelos) muestra que HumanEval se está saturando (modelos top >96%). Los modelos de frontera (ej. GPT-5.x, Claude Opus 4.8) han abandonado en gran medida HumanEval por benchmarks de nivel de repositorio (SWE-bench), donde el modelado de dificultad por instancia sigue siendo crítico a medida que las puntuaciones agregadas se comprimen.

Contribuciones Clave

Estudio de Ejecución Reproducible: Un conjunto de datos validado de ~68,000 ejecuciones a través de dos benchmarks, convirtiendo las completaciones públicas en matrices de respuesta binaria y escalas de dificultad.
Evidencia de Estabilidad: Prueba empírica de que la dificultad del ítem es una propiedad agnóstica al modelo que sobrevive a la eliminación de modelos, al remuestreo y a la transferencia de nivel de capacidad.
Análisis Predictivo: Demostración de que la dificultad es predecible a partir de características estáticas, con un hallazgo crucial entre benchmarks: la señal predictiva se desplaza de la especificación de lenguaje natural (HumanEval) a la complejidad de la solución (MBPP) basándose en la variabilidad del prompt.
Contextualización: Mapeo de estos hallazgos al panorama de modelos de 2026, mostrando que a medida que los benchmarks se saturan, el análisis consciente de la dificultad se vuelve más, no menos, importante.

Significado e Implicaciones

El artículo argumenta que el benchmarking consciente de la dificultad es esencial a medida que las puntuaciones agregadas se comprimen.

Para el Diseño de Benchmarks: Los reportes deben ir más allá de las puntuaciones agregadas únicas para incluir perfiles de dificultad (ej. distribución de ítems fáciles/medios/difíciles) para detectar la saturación y asegurar que los benchmarks sigan siendo discriminativos. Los predictores de dificultad estáticos ofrecen un método de bajo costo para curar benchmarks equilibrados sin ejecutar flotas de modelos.
Para la Autocalificación y la Educación: Las estimaciones de dificultad estática pueden servir como señales de confianza para la tutoría asistida por LLM. Si una especificación es marcada como "difícil" (ej. carece de ejemplos o tiene alta complejidad), un asistente puede derivar a revisión humana o solicitar aclaraciones.
Alineación Educativa: El hallazgo de que los ejemplos resueltos y las pistas de tipo facilitan las tareas para los LLM se alinea con el "efecto del ejemplo resuelto" en la teoría de la carga cognitiva. Esto sugiere que el andamiaje (scaffolding) beneficioso para programadores novatos también es beneficioso para los LLM, aunque crea un compromiso: los ejercicios diseñados para ser fáciles para los asistentes (ricos en ejemplos) pueden ser demasiado fáciles para que los estudiantes aprendan, mientras que los ejercicios escuetos pueden desafiar tanto a uno como a otro.

El estudio concluye que la dificultad no es una propiedad inherente del algoritmo por sí solo, sino que está determinada por la dimensión de la especificación que permanece más variable. Esta visión proporciona un marco para comprender y predecir el rendimiento de los LLM en diversos entornos de problemas.