Reducir las alucinaciones: una lista de verificación práctica

Una alucinación es una afirmación segura que no es verdad. Los modelos de lenguaje las producen porque están construidos para generar continuaciones plausibles, y una falsedad que suena plausible es, desde el punto de vista del modelo, una continuación perfectamente válida. No puedes eliminar esta tendencia por completo a base de prompts. Lo que sí puedes hacer es reformular la tarea para que el modelo tenga menos motivos para inventar y más motivos para admitir incertidumbre. Esta es una lista de verificación de las acciones que de verdad marcan la diferencia.

Dale al modelo los hechos en lugar de pedirle que los recuerde

La mayor reducción individual de alucinaciones viene de no depender en absoluto de la memoria del modelo. Cuando le pides a un modelo que responda a partir de lo que absorbió por casualidad durante el entrenamiento, le estás pidiendo que recuerde, y el recuerdo es precisamente donde vive la invención. Cuando en cambio le proporcionas el material de referencia relevante en el prompt y le pides que responda a partir de eso, cambias la tarea de "recuerda esto" a "lee esto e informa". Leer es mucho más fiable que recordar.

Esta es la idea central detrás de los montajes con recuperación aumentada, pero no necesitas infraestructura para beneficiarte. Incluso pegar el documento relevante en el prompt para una pregunta puntual reduce drásticamente la invención, porque la respuesta está ahora frente al modelo en lugar de reconstruida a partir de una memoria difusa. Siempre que los hechos existan en algún sitio del que puedas obtenerlos, obtenlos y ponlos en el contexto.

Dile al modelo que tiene permiso para decir "no lo sé"

Los modelos inventan en parte porque nada les dijo que no lo hicieran. Ante una pregunta que no pueden responder con la información disponible, el comportamiento por defecto es producir una conjetura segura, porque una conjetura es una continuación más probable que el silencio. La solución es autorizar explícitamente la no respuesta: "Si el contexto proporcionado no contiene la respuesta, di que no consta en lugar de adivinar".

Esta única instrucción cambia el comportamiento más de lo que sugiere su sencillez. Le da al modelo una salida de emergencia autorizada, de modo que la jugada segura deja de ser inventar. Haz que la instrucción sea específica para tu situación —"no está en el documento", "información insuficiente", "fuera de alcance"— para que el modelo sepa qué tipo de no respuesta dar. Sin esto, estás pidiendo implícitamente una conjetura cada vez que la respuesta real no esté disponible.

Restringe la respuesta a la fuente

Proporcionar material de referencia ayuda; restringir la respuesta a él ayuda más. Hay una diferencia entre "aquí tienes un documento, responde la pregunta" y "responde la pregunta usando únicamente la información de este documento; no añadas conocimiento externo". El segundo planteamiento le dice al modelo que el documento es el límite, no solo una pista. Cualquier cosa que el modelo quiera decir que no esté respaldada por la fuente queda, por instrucción, fuera de los límites.

Combina esto con una petición de fundamentar las afirmaciones en la fuente: que señale la parte del documento de la que procede cada afirmación. El acto de atribuir una afirmación obliga al modelo a comprobar si la afirmación está realmente presente, y las afirmaciones que no pueden atribuirse son justamente las que tienen más probabilidades de ser inventadas. La fundamentación es a la vez una mejora de calidad y un mecanismo de detección.

Pide razonamiento antes de la respuesta en preguntas difíciles

En preguntas que requieren conectar varios hechos o pasos, exigir una respuesta inmediata invita al modelo a comprometerse antes de haber resuelto nada, y un compromiso prematuro es terreno fértil para la invención. Pedirle al modelo que razone primero a través de la pregunta y luego enuncie su conclusión le da espacio para advertir cuándo las piezas no respaldan realmente una respuesta.

El beneficio es doble. El razonamiento a menudo produce una mejor respuesta, porque el modelo puede detectar sus propias lagunas sobre la marcha. Y el razonamiento es inspeccionable: cuando lees los pasos, un salto no respaldado se hace visible de un modo que una conclusión escueta no permite. Para búsquedas simples, sáltatelo: la sobrecarga no merece la pena. Para cualquier cosa que requiera síntesis, a la vez reduce y expone la invención.

Baja lo que está en juego en cada petición

Las tareas largas y dispersas invitan a más alucinación que las cortas y acotadas, porque un modelo que hace malabares con muchas subpreguntas en una sola pasada tiene más oportunidades de desviarse del camino respaldado. Dividir una petición compleja en piezas más pequeñas y bien definidas —cada una con sus propias entradas claras y una noción clara de cómo es una respuesta correcta— mantiene al modelo con una correa más corta en cada paso.

Las tareas más pequeñas también son más fáciles de verificar. Cuando una petición produce una afirmación enfocada, puedes contrastar esa afirmación con su fuente. Cuando produce un ensayo de diez párrafos que entreteje docenas de afirmaciones, la verificación se vuelve impracticable y los errores se cuelan. Acotar tiene que ver en parte con reducir la invención y en parte con hacer detectable la invención que queda.

Verifica la salida en lugar de confiar en ella

Ninguna cantidad de prompts hace que la salida de un modelo sea fiable por defecto, así que el último punto de la lista es la verificación. Para cualquier cosa que importe, la respuesta es un borrador que hay que comprobar, no un hecho que hay que publicar. La comprobación puede ser revisión humana, pero también puede automatizarse: confirmar que las fuentes citadas contienen realmente la información alegada, que los números cuadran, que los elementos referenciados existen.

Diseña el sistema para que la verificación sea posible. Las salidas que señalan sus fuentes pueden contrastarse con esas fuentes. Las salidas que indican de dónde procede un hecho pueden rastrearse. Las salidas que son prosa segura y sin atribución son inverificables por construcción, y lo inverificable es donde viven las alucinaciones no detectadas. El objetivo no es un modelo que nunca yerre —nada lo logra—, sino una canalización donde los errores que ocurren sean del tipo que puedes detectar antes de que lleguen a nadie.

En resumen

Reduces las alucinaciones cambiando la tarea, no regañando al modelo. Dale los hechos para que lea en lugar de recordar. Autorízalo a decir que no lo sabe. Restringe la respuesta a la fuente y pídele que fundamente sus afirmaciones. Déjalo razonar antes de concluir en preguntas difíciles, acota las peticiones lo bastante pequeñas como para verificarlas, y trata cada salida importante como un borrador que comprobar y no como un hecho en el que confiar. Ninguna de estas medidas elimina la alucinación —nada lo hace—, pero juntas convierten un sistema que inventa con seguridad en uno que en su mayoría admite sus límites y expone el resto para que se compruebe.