Ejecuto un gemelo digital en mi sitio web. Responde preguntas sobre mi vida y mis habilidades. Le di una regla estricta: nunca inventar cosas. Si alguien pregunta sobre una habilidad que no poseo, debe admitir que no lo sabe. Durante meses, creí que el sistema funcionaba. Lo probé manualmente de vez en cuando y las respuestas parecían sólidas. Luego construí un entorno de evaluación adecuado. Las cifras fueron un golpe duro. De 35 preguntas, nueve contenían mentiras descaradas. De ocho preguntas diseñadas para ser imposibles de responder, el modelo solo rechazó cuatro. Mi prompt anti-alucinaciones falló aproximadamente una cuarta parte de las veces. Estaba lanzando un producto que le mentía a sus usuarios.
Una configuración de recuperación extremadamente sencilla
No levanté Pinecone ni ninguna base de datos vectorial pesada. Toda la configuración reside en un simple archivo JSON. Mi código divide mi perfil en secciones discretas. Cuando llega una pregunta, el sistema calcula la similitud de coseno entre la consulta y cada fragmento de texto, selecciona las coincidencias más cercanas y las introduce en el prompt como contexto. El modelo genera entonces una respuesta basándose estrictamente en lo que ve en esa ventana.
Para un pequeño sitio personal que sirve un conjunto limitado de hechos, este enfoque es rápido y cuesta prácticamente nada. No hay ida y vuelta por la red hacia un almacén vectorial remoto, no hay sobrecarga de indexación y no hay una orquestación compleja. Lees el archivo, puntúas los fragmentos, construyes el prompt y listo. Pero la simplicidad en el backend no garantiza la honestidad en el resultado. Un pipeline ligero aún puede producir problemas graves cuando el modelo decide improvisar. La brecha entre "aquí está el contexto" y "esto es lo que diré al respecto" es donde habitan las alucinaciones. Puedes entregarle al modelo un párrafo sobre tu historial laboral y aun así recibir una fabricación convincente sobre un lenguaje de programación que nunca has tocado.
Las cifras que destruyeron mi confianza
Durante meses, consideré que las comprobaciones manuales puntuales eran una cobertura suficiente. Abría el chat, hacía una pregunta cuya respuesta ya conocía y asentía cuando la respuesta parecía correcta. Esa era mi estrategia de prueba. Parecía exhaustiva porque yo mismo utilizaba la interfaz. No lo era.
Cuando finalmente escribí un entorno de evaluación que podía ejecutarse sistemáticamente, el panorama cambió. La suite de pruebas lanzó 35 preguntas al gemelo. Nueve respuestas contenían mentiras. También incluí ocho preguntas que no tenían respuesta en ninguna parte de mi perfil. El modelo debería haberlas rechazado todas. Solo rechazó cuatro. Mi prompt anti-alucinaciones, cuidadosamente diseñado e incluyendo un lenguaje absoluto sobre nunca inventar cosas, falló aproximadamente el 25 por ciento de las veces. Uno de cada cuatro. Eso no es un error de redondeo. Eso es un producto roto.
Deja de probar con preguntas amigables
No puedes encontrar errores simplemente usando tu propio producto. Los encuentras intentando romperlo. Mis pruebas manuales eran demasiado amigables. Solo hacía preguntas donde conocía la respuesta exacta, lo que significaba que estaba guiando inconscientemente al modelo hacia terreno seguro. Nunca exploré los límites. Nunca pregunté sobre habilidades que desearía tener, o sobre experiencias que nunca ocurrieron.
Las pruebas reales requieren una intención adversarial. Tienes que diseñar preguntas destinadas a hacer que la IA falle. Quieres que cometa errores en el laboratorio para que no los cometa frente a un visitante. Una suite de pruebas que solo confirma lo que ya crees es simplemente una demostración disfrazada. Si no estás fabricando activamente casos límite y preguntas trampa, no estás probando. Estás esperando tener suerte.
Los dos errores que importaron
El prompting no es una garantía. Una instrucción larga y detallada diciéndole a una IA que no alucine es solo una sugerencia disfrazada de comando. El modelo puede seguirla la mayor parte del tiempo, pero ignorará la instrucción en el momento en que la presión estadística lo empuje hacia otro lado. La temperatura, la probabilidad de los tokens y la forma de los datos de entrenamiento pesan más que una frase en tu prompt de sistema. Debes medir la obediencia con datos, no con esperanza. Una instrucción fuerte no es un hecho verificado. Es una petición, y las peticiones pueden ser denegadas. Si toda tu estrategia de seguridad descansa en redactar tu prompt con firmeza, has construido una barrera de protección hecha de papel de seda. Necesitas un entorno de evaluación que cuente con qué frecuencia obedece el modelo, bajo qué condiciones y por qué falla cuando falla. A los números no les importa tu tono de voz.
El bucle de evaluación era defectuoso. Aquí hay una trampa sutil que casi me hace caer. Mi herramienta de pruebas original ejecutaba el proceso de recuperación dos veces. La primera ejecución recuperaba el contexto para compararlo con la verdad de referencia. La segunda ejecución recuperaba el contexto para la generación real de la respuesta. En la práctica, esto significaba que los fragmentos que veía el juez podían diferir de los fragmentos que veía el modelo. El juez estaba calificando la respuesta basándose en datos que la IA tal vez nunca hubiera recibido. Una evaluación que califica la entrada incorrecta es peor que no tener ninguna evaluación. Te da una falsa sensación de seguridad. Miras la puntuación, ves una alta tasa de aprobación y te relajas. Mientras tanto, tus usuarios están