🤖 machine learning

Code Roulette: How Prompt Variability Affects LLM Code Generation

Este artículo propone un pipeline de evaluación agnóstico para cuantificar la sensibilidad de los modelos de lenguaje grande (LLM) a las variaciones en los prompts durante la generación de código, respaldado por evidencia experimental y código abierto para la comunidad.

Autores originales: Andrei Paleyes, Radzim Sendyka, Diana Robinson, Christian Cabrera, Neil D. Lawrence

Publicado 2026-03-19

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Andrei Paleyes, Radzim Sendyka, Diana Robinson, Christian Cabrera, Neil D. Lawrence

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

¡Hola! Imagina que tienes un chef de cocina robot (un modelo de lenguaje o LLM) al que le pides que cocine un plato específico, digamos, una "tarta de manzana".

El problema que investigan en este artículo es: ¿Qué pasa si cambias un poquito la forma en que le pides la receta?

¿Si le dices "haz una tarta de manzana" en lugar de "prepara una tarta con manzanas"? ¿O si te equivocas y escribes "tarta de manzana" (con una 'a' de más)? ¿O si usas sinónimos como "postre de manzana"?

Los autores, un equipo de la Universidad de Cambridge, se dieron cuenta de que, aunque la gente con diferentes niveles de experiencia escribe estas peticiones de formas muy distintas, el robot a veces cambia drásticamente lo que cocina, incluso si la petición es casi la misma.

Aquí te explico su investigación como si fuera una historia:

1. El Experimento: "La Ruleta de la Receta"

Ellos crearon un sistema para probar la "sensibilidad" del chef robot. Imagina que tienes una receta original perfecta. Luego, empiezas a hacerle pequeños cambios a la petición, como si fueras un cliente un poco distraído:

Errores de tecleo: Cambias una letra por otra que está al lado en el teclado (como escribir "manzana" como "manzana").
Sinónimos: Cambias palabras por otras que significan lo mismo (de "hacer" a "preparar").
Parafraseo: Reescribes la frase completa con otras palabras, pero manteniendo el mismo significado.

Luego, le piden al robot que cocine la tarta con cada una de estas versiones.

2. ¿Qué descubrieron? (La Magia y el Caos)

Los errores de tecleo son peligrosos: Si el robot ve un error de escritura (como una letra mal puesta), se pone nervioso y cambia totalmente la receta. De repente, en lugar de una tarta, te hace un pastel salado o un batido. Es muy sensible a los "errores humanos".
Los sinónimos y reescrituras son más seguros: Si cambias las palabras por otras que significan lo mismo o reescribes la frase, el robot suele mantener la receta bastante estable. Es como si entendiera mejor la "idea" que las "palabras exactas".
El problema de la "memoria" (Contaminación de datos):
- Si pides al robot que haga un ejercicio de programación muy famoso (como los que hay en LeetCode), él lo hace perfecto, sin importar cómo lo escribas. ¿Por qué? Porque ya lo ha memorizado de sus libros de entrenamiento. Es como si le pidieras que recite un poema que ya sabe de memoria; no importa si cambias una coma, él lo sigue diciendo igual.
- Pero, si le pides algo nuevo y original (que no ha visto antes), ¡ahí es donde se pone interesante! Pequeños cambios en tu petición hacen que el robot cambie radicalmente su solución. Aquí es donde se nota que no es tan "inteligente" como parece, sino que está improvisando.

3. ¿Por qué importa esto?

Imagina que eres un arquitecto y usas este robot para diseñar puentes.

Si le pides "haz un puente" y te equivocas escribiendo "puente", el robot podría diseñar un puente que se cae.
Si dos personas en un equipo escriben la misma petición de forma ligeramente distinta, el robot podría darles dos diseños de puente totalmente diferentes. Esto es un caos para la seguridad y la confianza.

Ellos no están midiendo si el código (o la receta) es "correcto" o no, sino qué tan consistente es el robot. Si le das dos peticiones casi iguales, ¿te da dos resultados casi iguales?

4. La Conclusión en una frase

Este estudio nos dice que los robots de código son muy sensibles a cómo les hablamos. Si queremos confiar en ellos, necesitamos entender que un pequeño cambio en nuestras palabras (un error de dedo o una forma diferente de explicar algo) puede cambiar completamente el resultado final, especialmente cuando les pedimos cosas nuevas que no han memorizado.

En resumen: No basta con pedirle al robot que haga algo; hay que ser muy cuidadosos con cómo se lo pedimos, porque su "oído" es muy fino y a veces demasiado reactivo. ¡Es como intentar explicarle a un chef que no conoce tu gusto exacto qué quieres comer!

Resumen Técnico: Code Roulette

1. El Problema

La generación de código mediante Modelos de Lenguaje Grande (LLMs) ha democratizado el acceso a la programación, pero introduce un desafío crítico: la sensibilidad de los LLMs a las variaciones en el prompt de entrada.

Falta de Robustez: Los usuarios con diferentes niveles de experiencia, antecedentes educativos y modelos mentales de programación formulan los mismos requisitos de manera distinta (sinónimos, parafraseo, errores tipográficos).
Incertidumbre: No existe garantía de que un modelo genere el mismo código (o un código funcionalmente equivalente) ante pequeñas variaciones textuales que preservan el mismo significado semántico.
Riesgo de Confianza: Si el código generado varía drásticamente por cambios menores en la entrada, se dificulta la revisión, el mantenimiento y la confianza en la herramienta, especialmente en entornos de desarrollo profesional.
Contaminación de Datos: Muchos benchmarks existentes (como LeetCode clásico) están contaminados en los datos de entrenamiento de los LLMs, lo que infla artificialmente su rendimiento y oculta su verdadera sensibilidad a variaciones de prompts.

2. Metodología

Los autores proponen una tubería de evaluación (pipeline) agnóstica a la tarea específica y al modelo, diseñada para cuantificar la sensibilidad del código generado ante perturbaciones en el prompt.

Proceso de Evaluación:
1. Línea Base: Se generan $n$ muestras de código independientes a partir de un prompt original sin alterar.
2. Augmentación (Perturbación): Se aplica una función de aumento $F$ $F$ que modifica el prompt con una tasa $r \in [0, 1]$ $r \in [0, 1]$ . Se utilizan tres métodos de perturbación:
  - Errores de teclado (Typos): Reemplazo aleatorio de caracteres por teclas adyacentes en QWERTY.
  - Sinónimos: Reemplazo de palabras por sus sinónimos (basado en WordNet).
  - Parafraseo: Uso de un LLM (Gemini) para reescribir el prompt manteniendo la semántica pero variando el vocabulario.
3. Medición de Distancia: Para cada nivel de perturbación, se generan nuevos códigos y se calcula la distancia respecto a la línea base.
4. Métrica de Similitud (TSED): Se utiliza la Distancia de Edición de Árbol de Similitud (Tree Similarity of Edit Distance - TSED).
  - Por qué TSED: A diferencia de BLEU o BERT Score (que miden superposición de n-gramas o similitud semántica de texto), TSED mide la similitud estructural sintáctica del árbol de sintaxis abstracta (AST).
  - Justificación: El objetivo no es solo la corrección funcional, sino la consistencia estructural. Dos códigos pueden ser funcionalmente correctos pero estructuralmente muy diferentes, lo cual afecta la mantenibilidad. TSED evita los efectos de techo observados en métricas de texto general (como BERT Score > 0.98).
Modelos y Datos Evaluados:
- Modelos: GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash, Llama 3.3 70B. (Temperatura fijada en 0 para reducir estocasticidad).
- Datasets:
  1. LeetCode (Old): Tareas antiguas (probablemente contaminadas en el entrenamiento).
  2. LeetCode (New): Tareas de marzo de 2025 (fuera del corte de entrenamiento).
  3. Our Dataset: 22 tareas creadas manualmente, abiertas y diversas (simulaciones, juegos, ciencia de datos), diseñadas para no tener una única respuesta correcta y evitar contaminación.

3. Contribuciones Clave

Pipeline de Evaluación de Sensibilidad: Un procedimiento estandarizado para medir cómo la variabilidad del prompt afecta la distribución de salida de los LLMs en tareas de codificación.
Análisis Comparativo de Múltiples LLMs: Una evaluación exhaustiva de cuatro modelos populares, revelando patrones de comportamiento comunes y diferencias específicas.
Dataset y Herramientas Abiertas: Publicación de un nuevo dataset de tareas de código abiertas y el código fuente de la evaluación para que la comunidad pueda replicar y extender el trabajo.
Identificación de la Contaminación: Demostración empírica de cómo la contaminación de datos en benchmarks tradicionales enmascara la verdadera fragilidad de los modelos ante variaciones de prompts.

4. Resultados Principales

Impacto de los Tipos de Perturbación:
- Errores de Teclado (Typos): Son la perturbación más invasiva. La similitud del código (TSED) cae rápidamente entre una tasa de 0.0 y 0.6, estabilizándose en ~0.3 (código cardinalmente diferente).
- Sinónimos y Parafraseo: Son perturbaciones más débiles. Los modelos muestran mayor robustez. La similitud cae inicialmente pero luego decae muy gradualmente. Gemini 2.0 Flash fue el más robusto ante sinónimos.
Inestabilidad en Prompts No Alterados:
- Gemini 2.0 Flash y GPT-4o mini mostraron una estabilidad casi perfecta (similitud ~0.9) con prompts originales y temperatura 0.
- Llama 3.3 y Claude 3 Haiku mostraron mayor inestabilidad incluso sin perturbaciones, generando variaciones estructurales significativas.
Efecto de la Contaminación de Datos:
- LeetCode (Old): Los modelos mostraron la menor sensibilidad (máxima robustez) debido a que probablemente memorizaron las soluciones.
- LeetCode (New): La sensibilidad aumentó, pero los modelos aún mantuvieron estabilidad notable hasta alterar el 50% del prompt.
- Our Dataset (Tareas Nuevas): Se observó la mayor sensibilidad. La similitud del código cayó por debajo de 0.5 tras modificar solo el 10% del prompt. Además, incluso con prompts originales, la varianza fue alta (similitud ~0.7), indicando que para tareas no vistas en entrenamiento, los LLMs son altamente inestables ante pequeñas variaciones.
Significancia Estadística: Las pruebas de Friedman y Kruskal-Wallis confirmaron que la tasa de aumento tiene un efecto estadísticamente significativo en la similitud del código ( $p < 0.001$ ).

5. Significado e Implicaciones

Para la Industria y Usuarios: La variabilidad del prompt no es un problema menor. Pequeños cambios en cómo un usuario describe una tarea pueden resultar en implementaciones de código radicalmente diferentes, lo que complica la depuración y el mantenimiento. Se sugiere que los sistemas de generación de código deben incluir mecanismos de guía (preguntas de seguimiento) o regularización de salidas.
Para la Investigación: Los benchmarks tradicionales son insuficientes para evaluar la robustez de los LLMs. Es imperativo utilizar datasets frescos, no contaminados y tareas abiertas para medir el rendimiento real.
Futuro del Desarrollo: A medida que los LLMs se integran en el flujo de trabajo, la "programación de prompts" requiere nuevas habilidades. La comunidad debe entender que la estabilidad del modelo es tan crucial como su capacidad de generación.
Limitaciones y Futuro: El estudio se centró en interacciones de un solo paso. Futuras investigaciones deberían explorar diálogos multi-paso, propagación de incertidumbre en pipelines complejos y la inclusión de pruebas funcionales (además de TSED) para distinguir entre diversidad benigna e inestabilidad problemática.

En conclusión, "Code Roulette" demuestra que la generación de código con LLMs es inherentemente sensible a la variabilidad del lenguaje natural, y que esta sensibilidad es un factor crítico que debe ser medido y mitigado para construir sistemas de desarrollo de software confiables.