💻 computer science

Learned or Memorized ? Quantifying Memorization Advantage in Code LLMs

Este artículo presenta un método basado en perturbaciones para cuantificar la ventaja de memorización en modelos de lenguaje de código, revelando que el riesgo de memorización varía significativamente según el modelo y la tarea, y que benchmarks comunes como CVEFixes y Defects4J dependen más de la generalización aprendida que de la memorización directa.

Autores originales: Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

Publicado 2026-04-16

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

Artículo original bajo licencia CC BY 4.0 (http://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

¡Claro que sí! Imagina que los Modelos de Lenguaje Grandes (LLMs) para programar son como estudiantes universitarios superdotados que han leído millones de libros de código. La pregunta que se hacen los investigadores es: ¿Están estos estudiantes realmente aprendiendo a programar, o simplemente se han aprendido de memoria los ejercicios de los exámenes anteriores?

Aquí te explico el paper "Learned or Memorized?" (¿Aprendido o Memorizado?) usando una analogía sencilla:

1. El Problema: ¿Estudio o Copia?

En el mundo de la programación con Inteligencia Artificial, hay un gran misterio. Los modelos se entrenan con datos públicos (como GitHub), pero nadie sabe exactamente qué libros leyeron.

La preocupación: Si un modelo resuelve un problema de un examen famoso (un "benchmark"), ¿lo hizo porque entendió la lógica de la programación (generalización) o porque ya había visto ese mismo problema en su entrenamiento y solo lo repitió (memorización)?
El riesgo: Si solo memorizan, fallarán estrepitosamente si les cambias una sola coma o el nombre de una variable. Sería como un estudiante que sabe la respuesta "42" de memoria, pero si le preguntas "¿cuánto es 6 por 7?", se queda en blanco porque no entendió la multiplicación.

2. La Prueba: El "Juego del Cambiadito" (Perturbación)

Para descubrir la verdad, los autores no preguntaron al modelo directamente. En su lugar, jugaron a "El juego del cambiadito".

Imagina que le das al estudiante una pregunta de examen:

"Escribe un código para sumar los números del 1 al 10."

El modelo responde correctamente. Ahora, los investigadores le hacen una pequeña trampa (una perturbación) que no cambia el significado, pero sí la forma:

"Crea una función que calcule la suma de los primeros 10 números naturales."

Si el modelo es un "Genio que aprendió": No le importa el cambio. Sigue respondiendo bien porque entendió el concepto de "suma".
Si el modelo es un "Memorizador": Se bloquea o da una respuesta terrible. Como se había aprendido la frase exacta de memoria, cualquier cambio en la redacción lo confunde.

A esto lo llamaron "Ventaja de la Memorización": Cuanto más se cae el modelo cuando cambias ligeramente la pregunta, más probable es que solo estuviera memorizando.

3. Los Resultados: Sorpresas y Realidades

Los investigadores probaron a 8 modelos diferentes (como StarCoder, CodeLlama, Qwen, etc.) con 19 tipos de exámenes distintos. Aquí están las conclusiones más interesantes:

🏆 El Campeón de la Comprensión: La Resumenización

Cuando pidieron a los modelos que resumieran código (explicar de qué trata un programa en lenguaje normal), ¡todos fueron excelentes!

Analogía: Fue como pedirles que explicaran la trama de una película. Casi todos entendieron la historia, sin importar cómo se les preguntara. Esto sugiere que, en esta tarea, realmente han aprendido, no solo memorizado.

📉 El "Falso" Problema de Fugas de Datos

Había dos exámenes famosos (llamados Defects4J y CVEFixes) de los que todo el mundo sospechaba que los modelos se los habían "copiado" porque los resultados eran demasiado buenos.

La sorpresa: Al aplicarles el "juego del cambiadito", los modelos no fallaron. Mantuvieron su rendimiento incluso con cambios.
Conclusión: ¡No estaban copiando! Estaban entendiendo realmente los errores de seguridad y los bugs. La comunidad se equivocó al pensar que era una fuga de datos; en realidad, es un buen aprendizaje.

⚠️ El Problema de los "Exámenes Trampa"

Sin embargo, en tareas como generar pruebas de software (crear tests para verificar código) o arreglar bugs complejos, los modelos se volvieron muy frágiles.

Analogía: Fue como si les cambiaras el orden de las palabras en una pregunta de matemáticas y el modelo dejara de saber sumar.
El caso de StarCoder: Este modelo se comportó muy bien en la mayoría de las cosas, pero en un examen llamado APPS (problemas de programación competitivos), se comportó como un "memorizador puro". Si cambiabas una sola palabra en la pregunta, su rendimiento se desplomaba. Esto sugiere que, para ese examen específico, probablemente se lo sabía de memoria.

4. ¿Qué nos dice esto para el futuro?

No todo lo que brilla es oro: Un modelo que saca 100/100 en un examen famoso no necesariamente es inteligente. Podría estar "chuleando" (memorizando).
La arquitectura importa: Dos modelos del mismo tamaño (mismo número de "neuronas") pueden comportarse de forma totalmente diferente. Uno puede ser un genio que entiende y otro un robot que memoriza, dependiendo de cómo fueron diseñados y entrenados.
Necesitamos exámenes más difíciles: Los investigadores sugieren que debemos dejar de usar los mismos exámenes de siempre (porque los modelos ya los conocen) y empezar a crear exámenes dinámicos que cambien constantemente, o usar el "juego del cambiadito" para verificar si realmente están aprendiendo.

En resumen

Este paper nos dice que la Inteligencia Artificial en programación está aprendiendo de verdad en muchas áreas (como resumir código o arreglar bugs comunes), pero aún es frágil en otras (como crear pruebas complejas).

La lección final es: No juzgues a un estudiante solo por su nota en un examen antiguo. Hay que ver si puede resolver problemas nuevos cuando le cambias un poco las reglas. Y, afortunadamente, parece que nuestros "estudiantes de IA" están empezando a entender las reglas del juego, no solo a recitar las respuestas.

1. Problema y Motivación

La falta de transparencia en los conjuntos de datos utilizados para entrenar los Modelos de Lenguaje Grande (LLM) de código crea desafíos significativos para detectar, evaluar y mitigar la fuga de datos (data leakage). Existe una preocupación recurrente en la comunidad de que el rendimiento superior reportado por estos modelos en benchmarks estándar no se debe a una verdadera capacidad de generalización, sino a la memorización de ejemplos específicos presentes en sus datos de entrenamiento.

El problema central es la dificultad para distinguir entre:

Memorización: El modelo reproduce contenido verbatim o casi verbatim de su entrenamiento.
Generalización: El modelo ha aprendido patrones subyacentes y principios para generar nuevas soluciones.

Sin datos transparentes sobre el entrenamiento, es difícil evaluar si las mejoras de rendimiento son genuinas o infladas por la exposición previa a los datos de evaluación.

2. Metodología

Los autores proponen un enfoque basado en perturbaciones de entrada para cuantificar la "ventaja de memorización" (memorization advantage).

Hipótesis de Sensibilidad a la Perturbación (PSH): Se basa en la premisa de que los modelos que han memorizado contenido específico son altamente sensibles a pequeñas alteraciones en la entrada (perturbaciones), sufriendo una degradación brusca en el rendimiento. Por el contrario, los modelos que han generalizado correctamente mantienen un rendimiento estable ante variaciones sintácticas o semánticas menores.
Definición de Ventaja de Memorización ($ma$): Se define como la diferencia en el rendimiento entre cuando el modelo maneja datos "vistos" (o muy similares) frente a datos "no vistos" (perturbados).
$ma(M, x, y) = |p_\theta(y|x) - p_\theta(y|x'(x))|$
Donde $x'$ es una secuencia similar pero no vista (perturbada).
Procedimiento Experimental:
1. Se seleccionan 8 LLMs de código de última generación (ej. StarCoder, CodeLlama, DeepSeek-Coder, QwenCoder, etc.).
2. Se evalúan sobre 19 conjuntos de datos de referencia (benchmarks) divididos en 4 categorías de tareas: Generación de código, Comprensión de código, Detección de vulnerabilidades y Identificación de errores (Program Repair).
3. Técnicas de Perturbación:
  - Para NL2Code (Generación): Se usan paráfrasis controladas mediante el modelo BART para alterar las instrucciones en lenguaje natural.
  - Para Code2Code/Code2NL (Reparación/Resumen): Se realiza un renombrado aleatorio de identificadores (variables) para alterar la sintaxis manteniendo la semántica.
4. Se mide la caída de rendimiento (sensibilidad) a medida que aumenta la intensidad de la perturbación.
5. Se utilizan pruebas estadísticas (Mann-Whitney U, Kruskal-Wallis) para determinar la significancia de las diferencias en las distribuciones de sensibilidad.

3. Contribuciones Clave

Marco Empírico: Aplicación de análisis de sensibilidad a perturbaciones para distinguir entre memorización y generalización en LLMs de código.
Evaluación a Gran Escala: Análisis de 8 modelos de última generación en 19 benchmarks que cubren generación, reparación, pruebas y detección de vulnerabilidades.
Desafío a Suposiciones Previas: Resultados estadísticos que cuestionan la creencia de que benchmarks ampliamente utilizados como CVEFixes y Defects4J sufren de contaminación de datos masiva, revelando una baja ventaja de memorización.
Variabilidad Arquitectónica: Identificación de que, incluso con conteos de parámetros similares, las decisiones de diseño arquitectónico y las metodologías de entrenamiento impactan drásticamente en la capacidad de generalización.
Insights Específicos por Tarea: Demostración de que la generación de pruebas y la reparación de programas dependen del contexto presentan los mayores desafíos de generalización, mientras que el resumen de código muestra la mayor robustez.

4. Resultados Principales

Variación entre Modelos:
- StarCoder: Muestra una sensibilidad inusualmente alta (hasta 0.8) en el benchmark APPS, sugiriendo una fuerte memorización o contaminación de datos en ese conjunto específico.
- QwenCoder y CodeLlama: Mantienen valores de sensibilidad consistentemente bajos (<0.4) en la mayoría de los benchmarks, indicando una mejor generalización.
Diferencias por Tarea:
- Resumen de Código (Code Summarization): Muestra la menor sensibilidad (<0.3) en todos los modelos, indicando una generalización robusta.
- Generación de Pruebas (Test Generation): Exhibe una sensibilidad significativamente más alta (0.4-0.7), lo que sugiere que es una tarea más difícil de generalizar para los modelos actuales.
- Reparación de Programas: Los errores dependientes del contexto (ConDefect) presentan los mayores desafíos (sensibilidad ~0.7), mientras que Defects4J muestra una sensibilidad sorprendentemente baja (0.2-0.4), desafiando las sospechas de fuga de datos en este benchmark.
Detección de Vulnerabilidades:
- El dominio de seguridad muestra la mayor variabilidad (de <0.1 a >0.8).
- CVEFixes presenta una robustez excepcional (sensibilidad <0.1) en todos los modelos, lo que sugiere que los modelos han generalizado patrones comunes de vulnerabilidad en lugar de memorizar instancias específicas.

5. Significado e Implicaciones

Reevaluación de Benchmarks: Los hallazgos desafían la narrativa de que un alto rendimiento en benchmarks públicos implica necesariamente fuga de datos. Algunos benchmarks (como CVEFixes y Defects4J) pueden ser válidos para evaluar la generalización real.
Necesidad de Nuevos Marcos de Evaluación: Se requiere pasar de métricas estáticas de rendimiento a evaluaciones dinámicas que incluyan análisis de sensibilidad a perturbaciones.
Diseño de Modelos: La variabilidad en la sensibilidad entre modelos de tamaño similar indica que la arquitectura y el método de entrenamiento son más críticos para la generalización que simplemente escalar el tamaño del modelo.
Seguridad y Confiabilidad: En dominios críticos como la seguridad, la alta sensibilidad a perturbaciones indica que los modelos pueden ser frágiles y confiar en patrones memorizados en lugar de una comprensión profunda, lo cual es un riesgo para su despliegue en entornos reales.

En conclusión, el artículo proporciona una herramienta metodológica crucial para auditar la "memoria" de los LLMs de código, sugiriendo que, aunque existe memorización, muchos modelos también han desarrollado capacidades de generalización genuinas, especialmente en tareas de resumen y en benchmarks específicos de seguridad y reparación de bugs.