Una respuesta de un modelo puede sonar convincente y ser incorrecta. En aplicaciones de IA, este fenómeno suele llamarse alucinación: el sistema genera una salida que no está respaldada por los datos disponibles o presenta con seguridad una inferencia que no se puede verificar.
Reducir el riesgo no consiste en pedir al modelo que sea más prudente. Hay que diseñar el flujo para comprobar qué puede afirmar y qué debe derivar a una fuente o a una persona.
Por qué aparece una respuesta no respaldada
Un modelo de lenguaje genera secuencias probables a partir de sus pesos y del contexto recibido. No consulta automáticamente una base de datos actualizada ni verifica cada afirmación. Una pregunta ambigua, un contexto incompleto o una instrucción que exige datos ausentes pueden producir una respuesta fluida sin base suficiente.
El contexto puede ayudar y también confundir
Documentos recuperados, historial y herramientas aportan información, pero el modelo puede mezclar fuentes, interpretar mal una instrucción o dar prioridad a un fragmento irrelevante. Más texto no garantiza una mejor respuesta. El contexto debe ser pertinente, reciente y claramente delimitado.
Restringir el tipo de respuesta
Define qué debe hacer la aplicación cuando no encuentra evidencia. Puede responder que no dispone de información, mostrar las fuentes recuperadas o solicitar una aclaración. Un formato estructurado ayuda a validar campos, pero no demuestra que su contenido sea correcto.
Verificación fuera del modelo
Las reglas de negocio deben comprobar identificadores, importes, permisos y estados antes de guardar o ejecutar una acción. Si un asistente propone cambiar una dirección de facturación, el backend debe verificar usuario, autorización y formato; no debe confiar solo en el texto generado.
Evaluar el riesgo real
Construye casos con respuestas conocidas, preguntas ambiguas y datos que no deberían estar disponibles. Mide afirmaciones incorrectas, omisiones, fuentes irrelevantes y solicitudes de derivación. Repite la evaluación después de cambiar modelo, prompt, contexto o proveedor.
Cuándo intervenir
La revisión humana es razonable para decisiones financieras, legales, cambios de cuenta, mensajes externos o datos sensibles. Para una clasificación interna de bajo impacto puede bastar con una muestra periódica y una ruta de corrección.
Qué no corrige una instrucción
Un prompt mejor puede reducir ambigüedad, pero no arregla datos antiguos, permisos excesivos ni una integración defectuosa. La fiabilidad depende de modelo, datos, validación, monitorización y del uso que se haga de la salida.
Qué debe quedar medido
Registra versión, contexto, latencia, errores y resultado de las comprobaciones sin conservar datos sensibles innecesarios. La velocidad o la satisfacción subjetiva no sustituyen a una evaluación de exactitud.
Fuentes y trazabilidad
Si una respuesta depende de documentos, conserva la referencia que se utilizó y muestra una fuente cuando el caso lo requiera. La aplicación puede limitarse a fragmentos recuperados y rechazar una respuesta si no alcanza un umbral de evidencia. Esto no prueba que el documento sea correcto, pero permite revisar de dónde salió la afirmación.
Acciones con más riesgo
Una respuesta informativa no tiene el mismo impacto que una orden para borrar, pagar o cambiar una cuenta. El backend debe separar generación de ejecución. El modelo puede proponer una acción, pero una regla independiente comprueba identidad, autorización, valores e idempotencia.
Medir el comportamiento
Registra abstenciones, afirmaciones sin fuente, correcciones humanas y errores por tipo de pregunta. Una reducción aparente de alucinaciones puede provenir de responder menos, por lo que mide también cobertura y utilidad. Repite los casos después de cambiar el prompt, modelo o contexto.
Respuesta segura
La aplicación debe poder decir que no dispone de información suficiente. No conviertas la petición de certeza en una instrucción para inventar. Un mensaje de derivación, una fuente oficial o una pregunta aclaratoria puede ser la salida más útil.
El sistema debe poder abstenerse
Una instrucción que pida siempre una respuesta favorece afirmaciones sin respaldo. Diseña una salida para falta de evidencia y una pregunta de aclaración. En un sistema con recuperación, exigir una fuente mínima puede limitar errores, aunque no convierte el documento recuperado en una verdad automática.
Acciones separadas de lenguaje
El texto generado no debe modificar una cuenta ni enviar un mensaje por sí solo. La aplicación valida identidad, permisos y datos antes de ejecutar. Para cambios sensibles, una persona puede confirmar la propuesta o el sistema puede exigir una regla independiente.
Pruebas de regresión
Guarda preguntas que produjeron errores y repítelas tras cada cambio de modelo, prompt o fuente. Mide también cuándo el sistema se abstiene. Responder menos no es necesariamente mejorar si se pierde información útil.
Calibrar la confianza
Una puntuación del modelo no es una probabilidad fiable de que una afirmación sea cierta. Usa señales externas: coincidencia con una fuente, validación de campos, consenso entre reglas o revisión. Explica qué ocurre cuando esas señales no están disponibles.
Seguimiento después de publicar
Revisa muestras, correcciones y derivaciones. El comportamiento puede cambiar cuando cambia el contenido de entrada, aunque no se modifique el modelo. La evaluación continua debe distinguir errores del sistema y cambios en la fuente.
La revisión humana debe centrarse en acciones de impacto y en casos donde la evidencia sea insuficiente. Un sistema puede automatizar una respuesta de bajo riesgo y derivar una reclamación o cambio de cuenta. La frontera debe estar documentada.