Alucinación en IA: qué significa y cómo reconocer una respuesta sin respaldo

Definición: una salida que no está respaldada

En inteligencia artificial, una alucinación es una salida que presenta información incorrecta, inventada o no respaldada por la evidencia disponible para la tarea. La definición es operativa: describe la relación entre lo que produce el sistema, lo que se le pidió y las fuentes o datos que debía utilizar. No implica que el sistema tenga una experiencia consciente, que perciba algo inexistente ni que decida engañar a quien lo consulta.

La expresión se usa con variaciones en la investigación. Algunos trabajos se centran en la falta de fidelidad a una fuente o a un contexto proporcionado; otros, en afirmaciones falsas o no verificables. Por eso conviene especificar qué criterio se está aplicando. Una respuesta puede ser contradictoria con un documento, carecer de respaldo en las fuentes disponibles o ser factualmente falsa. Son problemas relacionados, pero no idénticos.

La distinción entre «falso» y «sin respaldo» es importante. Si una respuesta asegura que un contrato contiene una cláusula que no aparece en el documento, esa atribución está sin respaldo y puede comprobarse contra el texto. En cambio, si una respuesta plantea una afirmación para la que no se aportaron fuentes, quizá no se pueda decidir solo con el contexto si es falsa: puede ser cierta, falsa o indeterminada. No contar con evidencia suficiente no demuestra automáticamente lo contrario.

En esta ficha, «alucinación» designa una afirmación presentada como fiable cuando no se sostiene según el criterio y la evidencia pertinentes. Ese criterio puede ser la correspondencia con un texto, la validez de un cálculo, la existencia de una función en una biblioteca o la concordancia con fuentes autorizadas. La evaluación debe indicar qué se verificó, no limitarse a calificar una respuesta entera como verdadera o falsa.

Cómo puede aparecer y qué parte del sistema puede fallar

Un sistema generativo produce una respuesta a partir de la entrada, el contexto y los patrones que ha aprendido. La salida puede parecer coherente aunque incluya detalles que no se desprenden de esos elementos. Una pregunta ambigua, información insuficiente o una instrucción que presupone algo falso pueden dificultar una respuesta fundamentada. Estos factores no explican todos los casos por sí solos y no permiten inferir una causa concreta únicamente a partir del texto final.

En un sistema con recuperación de información, o RAG, se buscan documentos o fragmentos para incorporarlos al contexto del modelo. La cadena puede fallar en más de un punto: la búsqueda puede no encontrar la fuente pertinente, recuperar material inadecuado o presentar fragmentos sesgados; después, el modelo puede interpretar mal lo recuperado, añadir afirmaciones que no aparecen allí o atribuir una idea a la fuente equivocada. Por tanto, un error de respuesta no prueba por sí solo que el modelo generador haya sido la única causa.

También puede haber herramientas externas: una calculadora, una búsqueda, una base de datos o un programa ejecutado. El resultado puede ser incorrecto porque la herramienta devolvió datos inadecuados, porque se usó mal, porque el sistema leyó mal la salida o porque la respuesta final describió algo que la herramienta no confirmó. La responsabilidad de evaluar el resultado exige examinar la ruta completa cuando se dispone de ella.

En tareas multimodales se suman las entradas de imagen, audio u otros formatos. Una descripción puede atribuir a una imagen un detalle que no se distingue, transcribir mal una palabra o tratar una interpretación como si fuera un dato observado. La evaluación debe apoyarse en la entrada correspondiente y distinguir lo que realmente aparece de lo que el sistema infiere.

Distinciones que evitan diagnósticos imprecisos

Una falsedad factual es una afirmación que contradice hechos comprobables. Una afirmación sin respaldo es aquella para la que no se ha establecido evidencia suficiente en el material pertinente. Puede resultar falsa, pero también puede ser verdadera y estar simplemente sin demostrar en el contexto examinado. Para detectar una contradicción se necesita una referencia adecuada; para señalar falta de respaldo basta con mostrar que la fuente o el documento que debía sostener la afirmación no la contiene, siempre que ese sea el criterio de la tarea.

Una inferencia inválida da un paso que no se sigue de las premisas, incluso si cada premisa es correcta. Un error de atribución asigna una frase, una conclusión o un dato a una fuente que no lo respalda. Una cita inexistente es un caso especialmente comprobable: se puede buscar el pasaje, verificar su ubicación y comprobar si dice lo que se le atribuye. Que una cita tenga formato convincente no demuestra que sea auténtica ni pertinente.

El sesgo describe patrones sistemáticos que pueden producir resultados desiguales o favorecer ciertas representaciones. No es sinónimo de alucinación: una respuesta puede estar sesgada sin inventar un hecho puntual, y una afirmación inventada puede no mostrar por sí sola un patrón de sesgo. La aleatoriedad, por su parte, se refiere a variación en las salidas. Que dos respuestas difieran no basta para establecer que una de ellas alucina; hay que evaluar su contenido y la evidencia.

La desinformación suele implicar la difusión de información falsa o engañosa y, en ciertos usos, una intención de engañar. Llamar «alucinación» a una salida de un modelo no prueba intención. El término describe el resultado observado, no un propósito humano del sistema. Del mismo modo, un desacuerdo entre fuentes no demuestra automáticamente que una respuesta sea inventada: puede reflejar definiciones distintas, fechas diferentes o una controversia real.

Un fallo de recuperación tampoco es idéntico a una alucinación de generación. Si el sistema encuentra documentos irrelevantes y contesta fielmente a esos documentos, el problema puede estar en la recuperación o en el corpus, aunque la respuesta sea inadecuada para la pregunta. Si el modelo añade datos ausentes, hay además un problema de respaldo o fidelidad. En escenarios reales ambos fallos pueden combinarse.

Tres ejemplos aplicados

Los siguientes casos son ilustraciones hipotéticas, no incidentes documentados ni recomendaciones profesionales. En los tres, lo decisivo es comparar una afirmación concreta con la evidencia adecuada para la tarea.

blocks

[]

Ejemplo en salud: una contraindicación que no aparece en la fuente

Supongamos que una persona consulta un resumen de información farmacológica y el sistema afirma que un medicamento está contraindicado junto con otro. La palabra «contraindicado» tiene consecuencias potencialmente importantes: no basta con que la frase suene médica o incluya un nombre de fármaco correcto. La comprobación tendría que identificar el producto y la fuente aplicable, localizar la advertencia exacta y evaluar si el alcance de la afirmación coincide con el texto.

Si el material consultado no menciona esa contraindicación, se puede decir que la afirmación no está respaldada por ese material. Para concluir que es falsa habría que consultar evidencia clínica pertinente y actualizada, no deducirlo del silencio de un fragmento aislado. Tampoco se debe convertir el ejemplo en consejo al paciente: ante una posible interacción o contraindicación real, corresponde recurrir a un profesional sanitario o a información autorizada.

La evaluación puede descomponer la respuesta: ¿nombró correctamente los medicamentos?, ¿atribuyó una advertencia a una fuente concreta?, ¿esa fuente contiene la advertencia?, ¿la formulación exagera una precaución o presenta una posibilidad como prohibición absoluta? Un benchmark médico puede ayudar a comparar sistemas en tareas definidas, pero un resultado en un conjunto de pruebas no resuelve la corrección de una respuesta particular ni sustituye la revisión proporcional al riesgo.

Ejemplo en contratos: atribuir una cláusula ausente

Imaginemos una herramienta que resume un contrato y asegura que existe una cláusula de renovación automática con un plazo concreto. La forma más directa de evaluar esa afirmación es buscar en el documento el texto que la sostendría y examinar las secciones pertinentes. Si la cláusula no aparece, el sistema no debe presentarla como contenido del contrato. La conclusión apropiada puede ser «no se encuentra en el documento proporcionado», que es más precisa que asegurar que no existe en ningún otro anexo o versión.

También puede haber una interpretación discutible sin que se haya inventado una cláusula. Por ejemplo, una frase ambigua puede admitir más de una lectura jurídica. En ese caso hay que diferenciar el texto literal, la interpretación del sistema y cualquier conclusión legal. Citar un número de sección tampoco prueba que la sección exista ni que sostenga el resumen: hay que comprobar la referencia y su contexto.

El caso muestra por qué el alcance de la fuente importa. Si solo se recibió una página, la ausencia de una cláusula en esa página no permite afirmar que falta en el contrato completo. Si se recibió el documento entero, aún pueden existir anexos o documentos externos no incluidos. Una evaluación rigurosa informa qué material se revisó y evita convertir una búsqueda incompleta en una conclusión universal.

Ejemplo en programación: explicar una función inexistente

Supongamos que un asistente describe una función de una biblioteca y entrega una llamada que parece razonable, pero esa función no existe en la versión que usa el proyecto. La plausibilidad del nombre y de los argumentos no basta para considerarla válida. Se puede comprobar la documentación de la versión pertinente, inspeccionar el código disponible o ejecutar una prueba mínima en un entorno controlado.

La versión y el contexto son esenciales. Una función podría existir en una versión más reciente, en una extensión o en un módulo diferente. Por ello, encontrar que no aparece en la documentación de una versión concreta permite acotar la afirmación; no demuestra que nunca haya existido. También hay que diferenciar una explicación falsa sobre una API de un error de entorno, una dependencia ausente o una configuración incorrecta.

Si la respuesta atribuye el método a una documentación determinada, se puede verificar la cita por separado. Si no menciona fuente alguna, aún se puede probar el código, pero el resultado de una prueba cubre solo las condiciones ensayadas. Un fragmento que funciona para un caso no garantiza que sea correcto, seguro o compatible en todos los proyectos.

Cómo evaluar una posible alucinación

No existe una única comprobación que resuelva todos los tipos de tarea. La evaluación empieza por descomponer la respuesta en afirmaciones verificables. Una respuesta extensa puede mezclar datos correctos, inferencias razonables, detalles no respaldados y citas erróneas. Juzgarla como un bloque hace más difícil identificar qué debe corregirse y qué evidencia falta.

Después se define el estándar de respaldo: ¿la respuesta debía ceñirse a un documento?, ¿contestar con información actual?, ¿ejecutar un cálculo?, ¿describir una imagen?, ¿resumir resultados recuperados? Cada propósito requiere una prueba distinta. Para una pregunta documental, el cotejo de pasajes puede ser adecuado; para código, una prueba ejecutable aporta evidencia sobre el comportamiento ensayado; para hechos actuales, puede ser necesario consultar fuentes actualizadas y autorizadas.

En sistemas RAG, es útil comprobar si cada afirmación tiene apoyo en los fragmentos recuperados y si estos son pertinentes y suficientes. Un verificador de procedencia puede ayudar a asociar afirmaciones con fragmentos, pero esa asociación no demuestra por sí sola que el fragmento sea verdadero, actual o la fuente más adecuada. Tampoco resuelve necesariamente afirmaciones implícitas, razonamientos complejos o información que no está en el corpus.

Las citas y referencias deben validarse como objetos concretos: comprobar que existen, que pertenecen a la fuente indicada y que respaldan la afirmación con el alcance que se les atribuye. Una cita auténtica puede ser irrelevante, estar desactualizada o haber sido interpretada fuera de contexto. A la inversa, una afirmación puede ser correcta aunque la cita que la acompaña esté mal atribuida; son fallos distintos.

La revisión humana es especialmente importante cuando un error puede afectar a la salud, los derechos, las finanzas, la seguridad o decisiones difíciles de revertir. La intensidad de la revisión debe guardar proporción con el impacto y con la posibilidad de comprobar el resultado. Para una tarea de bajo riesgo puede bastar una prueba directa; para una decisión de alto impacto, la respuesta automatizada no debe tratarse como verificación independiente.

Mitigaciones: útiles, pero no garantías

La recuperación de fuentes puede mejorar la disponibilidad de evidencia para responder y facilitar el cotejo de afirmaciones. Sin embargo, recuperar información no asegura que se haya encontrado la fuente correcta ni que el modelo la use fielmente. Los documentos pueden estar incompletos, ser irrelevantes o discrepar; el sistema puede seleccionar mal, interpretar de forma defectuosa o añadir contenido que no aparece en ellos.

Pedir al modelo que diga que no sabe o que se abstenga cuando no tenga confianza puede reducir algunas respuestas especulativas, pero no convierte la abstención en un detector infalible. El sistema puede abstenerse cuando sí hay evidencia o contestar con seguridad cuando no la hay. La instrucción es una medida de comportamiento, no una prueba independiente de verdad.

Los verificadores automáticos pueden señalar inconsistencias, revisar citas o comparar una respuesta con un conjunto de fuentes. Sus resultados dependen de la tarea, los datos y el método. Un verificador puede pasar por alto un error sutil, compartir limitaciones con el generador o aceptar una fuente inadecuada. Las evaluaciones y benchmarks permiten medir comportamientos bajo condiciones definidas; no certifican todas las respuestas futuras en otros contextos.

Una publicación de investigación de un proveedor de modelos propone que determinados incentivos de entrenamiento y evaluación pueden favorecer respuestas adivinadas frente a reconocer incertidumbre. Es una hipótesis explicativa presentada por ese proveedor, no una explicación universal ni un consenso independiente demostrado para cada caso. Conviene separar una propuesta sobre causas posibles de la evidencia concreta que permite evaluar una salida particular.

Conceptos relacionados y criterios prácticos

La alucinación se relaciona con otros conceptos del glosario, pero no los sustituye. La ficha sobre grounding trata de cómo una respuesta se apoya en información o contexto identificable; el concepto de RAG describe una arquitectura que recupera material para incorporarlo a la generación. Ninguno de los dos nombres implica que las afirmaciones sean necesariamente correctas.

La incertidumbre concierne a los límites de lo que se puede determinar o a la confianza con que se sostiene una conclusión. Expresarla con claridad puede ayudar, pero una frase de duda no garantiza que la respuesta esté bien calibrada. Fact-checking es el proceso de contrastar afirmaciones con evidencia; puede descubrir errores, aunque su calidad depende de la selección de fuentes y de la pregunta evaluada. La página de alucinación del índice del glosario permite encontrar estas entradas relacionadas y distinguir sus enfoques.

Como criterio práctico, antes de aceptar una respuesta pregúntese: ¿qué afirmación concreta necesito usar?, ¿qué fuente o prueba podría confirmarla?, ¿la fuente es pertinente al caso y a la fecha?, ¿la cita respalda realmente lo que se afirma?, ¿qué partes siguen sin determinarse? Si no se puede contestar a esas preguntas, es más preciso decir que la respuesta no está verificada que asignarle una etiqueta concluyente.

Para documentar una revisión, registre la afirmación, el material examinado, el método de comprobación y el resultado. Use categorías acotadas: respaldada por la fuente revisada, contradicha por ella, no respaldada en ese material o no evaluable con la evidencia disponible. Añada el alcance: por ejemplo, «en el documento proporcionado» o «en la versión probada». Esta formulación permite corregir errores sin asegurar más de lo que la revisión demuestra.

La regla final es sencilla: la fluidez, la seguridad del tono, el detalle y una cita con apariencia formal no equivalen a evidencia. La confianza razonable procede de una comprobación adecuada a la tarea, con fuentes pertinentes y límites explícitos.

Conceptos relacionados