Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code

En el mundo moderno del desarrollo de software, los programadores suelen confiar en asistentes de inteligencia artificial para escribir código. Estos sistemas, conocidos como modelos de lenguaje extensos, actúan como compañeros incansables que pueden sugerir funciones enteras o corregir errores en segundos. Para que sus sugerencias funcionen, estos modelos frecuentemente recomiendan añadir paquetes de software externos —colecciones de código preescrito que gestionan tareas específicas como conectarse a una base de datos o crear un gráfico. El problema surge cuando la inteligencia artificial inventa un nombre de paquete que suena perfectamente real pero que en realidad no existe en ninguna biblioteca de software oficial. Este fenómeno se denomina alucinación de paquetes. Si un desarrollador confía ciegamente en la sugerencia e intenta instalar este paquete inexistente, puede descargar inadvertidamente un archivo malicioso creado por un hacker que registró el nombre falso. Esto crea una puerta trasera peligiente en la cadena de suministro de software, permitiendo que atacantes inyecten código dañino en aplicaciones que millones de personas podrían usar.

Un equipo de investigadores se propuso comprender con qué frecuencia ocurren estas alucinaciones y si técnicas específicas podrían detenerlas antes de que el código esté siquiera terminado. Se centraron en modelos de inteligencia artificial de código abierto más pequeños, los cuales son ampliamente utilizados porque son menos costosos de ejecutar, aunque son más propensos a cometer errores que sus contrapartes más grandes. Los investigadores probaron estos modelos en cuatro lenguajes de programación diferentes: Python, JavaScript, Ruby y Rust. Descubrieron que los métodos anteriores para medir estos errores eran defectuosos. Muchos estudios previos contaban herramientas estándar integradas que vienen con un lenguaje de programación como alucinaciones simplemente porque esas herramientas no figuran en las bibliotecas de paquetes externos. Al corregir este error de conteo, el equipo encontró que la tasa de alucinaciones para Python era en realidad más baja de lo que se pensaba anteriormente, aunque seguía siendo significativa.

El núcleo de su trabajo consistió en probar siete estrategias diferentes para ver si podían reducir el número de nombres de paquetes falsos que generaban los modelos. Algunas de estas estrategias implicaban cambiar la forma en que el modelo selecciona su siguiente palabra, mientras que otras pedían al modelo que revisara su propio trabajo o consultara información en una base de datos verificada antes de responder. Los investigadores descubrieron que ningún método único funcionaba mejor en todas las situaciones. Una técnica llamada Generación Aumentada por Recuperación (Retrieval-Augmented Generation), que obliga al modelo a consultar una base de datos real de paquetes existentes antes de hablar, resultó ser altamente efectiva para la mayoría de los lenguajes, reduciendo significamente la tasa de error. Sin embargo, esta misma técnica a veces empeoraba las cosas para JavaScript, lo que sugiere que la solución depende fuertemente del lenguaje de programación específico utilizado. Otro enfoque, donde se le pide al modelo que critique y reescriba sus propias sugerencias, funcionó bien para los modelos más grandes pero falló para los más pequeños, que a menudo no podían reconocer sus propios errores.

El equipo también introdujo una nueva forma de medir si las sugerencias del modelo eran realmente útiles, no solo correctas. Descubrieron que algunas estrategias que lograban detener las alucinaciones también detenían al modelo de sugerir cualquier paquete en absoluto, dejando al desarrollador sin nada que usar. El enfoque más equilibrado, que reducía los errores pero seguía proporcionando sugerencias útiles, fue un método directo donde el modelo simplemente elige la palabra siguiente más probable cada vez, en lugar de arriesgarse con opciones menos probables. Este enfoque "codicioso" (greedy) ofreció el mejor equilibrio entre seguridad y utilidad para los modelos que probaron.

Quizás el hallazgo más sorprendente surgió cuando los investigadores probaron estas defensas contra un entorno hostil. Crearon instrucciones (prompts) que intentaban engañar deliberadamente a los modelos para que recomendaran paquetes falsos, incrustando los nombres falsos directamente en las instrucciones. Bajo estas condiciones adversarias, las tasas de error se dispararon, aumentando hasta en 45 puntos porcentuales en comparación con las solicitudes normales. En este entorno hostil, los trucos simples de cambiar cómo el modelo elige las palabras fallaron por completo. Solo los métodos que dependían de verificar contra una base de datos real o de obligar al modelo a doble revisar su propio trabajo pudieron resistir el ataque. Los investigadores concluyeron que, si bien los ajustes simples pueden ayudar en el uso normal, proteger el software de atacantes decididos requiere un sistema que pueda verificar hechos contra el mundo exterior o revisar rigurosamente su propia lógica. El estudio destaca que la mejor defensa no es una solución única para todos, sino una elección emparejada cuidadosamente con la amenaza específica y el lenguaje de programación involucrado.