Resumen
La detección de alucinaciones en código generado por IA admite hoy dos grandes familias de aproximaciones: las que verifican contra una fuente de verdad externa (deterministas) y las que infieren la probabilidad de error mediante modelos (generativas). Este artículo revisa ambas a partir de la literatura reciente y de experiencias publicadas en DEV Community, y sitúa el caso concreto de la verificación de paquetes y APIs de Python contra PyPI. La conclusión provisional es que ninguna familia cubre el problema completo: las deterministas ofrecen evidencia objetiva pero un alcance acotado; las generativas amplían la cobertura pero introducen incertidumbre. La elección depende del tipo de error que se quiera atrapar y del coste que se esté dispuesto a asumir.
1. El problema: tres fallos con el mismo nombre
Saurav Bhattacharya sostiene en un artículo reciente que la detección de alucinaciones es un problema de instrumentación, no de calidad del modelo . Su argumento central es que, en sistemas con agentes, la palabra “alucinación” agrupa al menos tres fallos distintos:
-
Fuga paramétrica: el agente responde desde su memoria de entrenamiento en lugar de usar el resultado de la herramienta que se le proporcionó. La respuesta puede ser correcta, pero lo es por casualidad, no porque esté fundamentada.
-
Fundamentación fabricada: el agente cita una fuente, un identificador o un número que no aparece en el contexto recuperado. Es el caso más peligroso porque tiene la apariencia de una afirmación documentada.
-
Síntesis no soportada: cada hecho individual está en el contexto, pero la conclusión que extrae el agente no se sigue de la fuente.
La implicación práctica es que estos tres fallos requieren detectores distintos. Un único “score de alucinación” que los mezcle produce una cifra que nadie puede interpretar .
2. La crítica a los métodos generativos
El mismo artículo señala una debilidad conocida de los detectores basados en modelos: la auto-consistencia (muestrear varias veces y comprobar si las respuestas coinciden) detecta alucinaciones inestables, pero falla con las estables. Si un agente reproduce sistemáticamente el mismo dato erróneo desde su memoria paramétrica, las muestras coinciden y el detector reporta alta confianza. El modelo es reproduciblemente incorrecto, y la consistencia era la señal .
La literatura académica respalda esta cautela. Un estudio sobre métodos de análisis estático para alucinaciones de librerías señala que las herramientas de inferencia de tipos, como Pyright, resultan más fiables que el juicio de un LLM en la detección de errores de importación y de tipo . El mismo trabajo reconoce, no obstante, que el análisis estático tiene límites: las operaciones de flujo de datos y de control son las vías más prometedoras para ampliar su cobertura, pero los tipos pueden mutar durante la ejecución y escapar a la detección .
3. La propuesta determinista: verificar contra la fuente
La alternativa que defiende Bhattacharya es mecánica y explicable: extraer las afirmaciones verificables del output y comprobarlas contra el texto que el agente realmente recuperó. El requisito es conservar ese texto (la traza de ejecución); sin él, cualquier verificación es una adivinanza .
En el dominio del código, esta idea se ha materializado de varias formas. La herramienta libhallubench evalúa la generación de código de LLM frente a un benchmark de librerías inexistentes, usando la lista de paquetes de PyPI como fuente de verdad . El proyecto vibe-check detecta patrones típicos de código generado por IA, incluidos los imports inventados, mediante coincidencia de patrones, sin recurrir a modelos ni a servicios en la nube . Un artículo de la misma comunidad describe cómo ESLint y TypeScript no detectan un import inventado porque el linter valida sintaxis, no la existencia del paquete en el registro, y el compilador de tipos solo comprueba tipos si existen definiciones instaladas, que no pueden instalarse para un paquete que no existe .
En este panorama, la verificación de paquetes y APIs de Python contra el wheel real de PyPI se sitúa en la tradición determinista: no infiere, comprueba pertenencia a un conjunto. La ventaja es que no requiere instalar el paquete ni ejecutar el código analizado; la limitación es que solo cubre la existencia de símbolos, no la corrección de su uso.
4. La propuesta generativa: detectar spans con modelos entrenados
La familia generativa ha avanzado de forma notable. LettuceDetect v2 es un detector entrenado sobre un benchmark unificado de 74.285 ejemplos etiquetados a nivel de span, que abarca código, salidas de herramientas y documentos . El modelo generativo (Qwen 3.5-2B) devuelve los spans alucinados como JSON estructurado, tipados por categoría (contradicción, adición no soportada, referencia fabricada) y subcategoría (entidad, temporal, numérico, identificador, atributo) . En el conjunto de prueba unificado, alcanza 0,689 span-F1; en respuestas de agentes de código, 0,602 .
La ventaja de este enfoque es la cobertura: detecta errores que un verificador de existencia no puede atrapar, como una condición lógica incorrecta o un valor numérico equivocado. La limitación es la inherente a todo modelo probabilístico: no ofrece una explicación determinista y su rendimiento varía según el dominio y la fuente de fundamentación .
5. El hueco que ninguno cubre: lógica y recursos
La taxonomía de CodeHalu, citada en la documentación del proyecto que nos ocupa, distingue cuatro categorías: nomenclatura, mapeo, recursos y lógica. Los verificadores deterministas contra registros cubren razonablemente las dos primeras. Las dos últimas quedan fuera de su alcance por definición: requieren analizar el flujo de datos, las condiciones o la complejidad algorítmica, no solo la existencia de un símbolo.
La literatura confirma este límite. Un análisis de los fallos estructurales en código generado concluye que la mayoría de ellos escapa al type checking, a los tests y al análisis estático de seguridad . Otro trabajo describe el caso de una función de descuento cuyos tipos son correctos pero cuya semántica es errónea porque la unidad del porcentaje no coincide con la que usa el resto del código: el compilador no puede detectarlo porque los tipos cuadran .
Los detectores generativos como LettuceDetect v2 intentan cubrir parte de ese hueco, pero no ofrecen garantías deterministas. La brecha entre “el símbolo existe” y “el código hace lo que debe” sigue siendo, en buena medida, un problema abierto.
6. Consideraciones para el diseño de un detector
A partir de lo anterior, pueden extraerse algunas observaciones provisionales:
La verificación determinista es barata y explicable. Comprobar la existencia de un paquete o de una función contra un registro no requiere ejecutar el código del usuario ni instalar dependencias. El coste es acotado y el resultado es una pertenencia a un conjunto, no una probabilidad.
La cobertura determinista es necesariamente parcial. Se limita a los errores que pueden expresarse como una comprobación de pertenencia o de firma. Los errores de lógica, de flujo de datos o de complejidad quedan fuera.
Los métodos generativos amplían la cobertura pero introducen incertidumbre. Su rendimiento depende del benchmark de entrenamiento y no ofrecen una explicación determinista del fallo.
La combinación es plausible. Un detector determinista para la existencia de símbolos y un detector generativo o semántico para la lógica podrían cubrir capas complementarias. La cuestión abierta es cómo integrarlos sin que la incertidumbre del segundo contamine la fiabilidad del primero.
7. Limitaciones de este análisis
Este texto se basa en una revisión no sistemática de literatura y de artículos de la comunidad. No se ha realizado una evaluación empírica comparativa de los enfoques descritos. Las cifras citadas provienen de los trabajos originales y no han sido replicadas en el contexto específico de la verificación de paquetes de Python. La taxonomía de CodeHalu se ha utilizado como marco descriptivo, no como benchmark validado en este análisis.
Referencias
-
Bhattacharya, S. (2026). Hallucination Is Not a Vibe: How to Actually Detect Ungrounded Claims in Agent Output. DEV Community.
-
libhallubench (2026). PyPI.
-
5 Code Smells Only AI Creates (And How to Detect Them). DEV Community.
-
ESLint can’t catch this: 5 failure modes unique to AI-generated code. DEV Community.
-
LettuceDetect v2 in Semantic Router: Generative Hallucination Detection as a vLLM Endpoint. GitHub.
-
KRLabsOrg. LettuceDetect. GitHub.
-
The verification gap in agent-written code: what actually breaks. GitHub.
-
The Patchwork Problem in LLM-Generated Code. arXiv.
-
For mitigation, we use three metrics. OpenReview.