Llevo tiempo viendo la misma pregunta repetida en foros y grupos de trabajo: "¿qué prompt uso para que deje de alucinar?". La pregunta está mal planteada de raíz. No existe una frase mágica que elimine las alucinaciones. Existe un proceso que las reduce, y ese proceso rara vez pasa solo por el texto del prompt.

El primer error: tratarlo como un problema de redacción

Cuando un modelo se inventa un dato, la reacción instintiva es reescribir el prompt: añadir "sé preciso", "no inventes información", "verifica antes de responder". Estas frases no hacen prácticamente nada por sí solas. El modelo no tiene un interruptor interno de "modo preciso" que se active con la palabra correcta. Genera texto probable dado el contexto que tiene, y si ese contexto no contiene el dato real, lo probable es que rellene el hueco con algo plausible.

Si el dato no está en el contexto del modelo, ningún prompt lo va a sacar de la nada de forma fiable, por muchas veces que le pidas que sea preciso.

Lo que sí reduce alucinaciones

Dale el dato, no le pidas que lo recuerde. Si necesitas una cifra concreta, un precio, una versión de una librería, no confíes en que el modelo la sepa de memoria y la tenga actualizada. Pásasela en el contexto —documento, resultado de una búsqueda, respuesta de una API— y pídele que trabaje sobre eso. Es la diferencia entre pedirle que recuerde y pedirle que lea.

Reduce el alcance de la pregunta. Preguntas amplias y abiertas ("háblame de X") producen respuestas más propensas a rellenar huecos con generalidades inventadas. Preguntas acotadas, con criterios claros de qué información necesitas y de dónde debe salir, dejan menos margen de improvisación.

Pide que distinga entre lo que sabe y lo que no. Una instrucción que funciona razonablemente bien es pedir explícitamente que marque como "sin dato" o "no verificado" cualquier afirmación que no pueda respaldar con el contexto dado, en vez de dejar que rellene con lo más probable. No es infalible, pero cambia el comportamiento por defecto de "siempre contesto algo" a "puedo decir que no lo sé".

Añade un paso de verificación separado. En vez de pedir la respuesta final de una sola pasada, separa generación y verificación. Genera la respuesta y, en un paso distinto —otra llamada, otro prompt—, pide que revise las afirmaciones concretas contra las fuentes disponibles. Un modelo revisando texto ya escrito detecta contradicciones e invenciones mejor que generando y verificando a la vez.

Baja la temperatura cuando el output debe ser factual. No es magia, pero en tareas donde necesitas precisión y no creatividad, una temperatura baja reduce la varianza de las respuestas y, con ella, parte del margen para inventar.

Dónde de verdad se libra la batalla

La mejora más grande no viene de ningún prompt: viene de darle al modelo acceso a la información correcta en el momento correcto. Esto es básicamente lo que hace cualquier sistema de recuperación de información —RAG, herramientas de búsqueda, consultas a una base de datos—: mueve el problema de "que el modelo recuerde bien" a "que el sistema le entregue lo correcto antes de que tenga que inventar nada".

Si tu aplicación depende de datos que cambian —precios, disponibilidad, estado de algo—, la solución no es un prompt mejor. Es una arquitectura donde el modelo no tiene que recordar ese dato porque se lo das fresco en cada llamada.

No pruebes a ciegas

Aquí está el consejo que de verdad ahorra tiempo: no cambies el prompt a base de intuición y vuelvas a probar a mano una y otra vez, cambiando una palabra y mirando si "parece" que ha mejorado. Monta un set pequeño de casos reales donde sepas cuál es la respuesta correcta, y compara versiones del prompt contra ese set de forma sistemática. Diez casos bien elegidos, comprobados cada vez, valen más que cien intentos sueltos con una sola pregunta cambiando el adjetivo de turno.

Esto es lo mismo que se aplica a cualquier sistema no determinista: sin un criterio de evaluación repetible, cada cambio es una opinión, no un dato. Y las opiniones sobre si un prompt "ha mejorado" son notoriamente poco fiables cuando las formas uno mismo, sin comparar nada.

Un caso concreto: cifras y fechas

Un patrón que veo constantemente: pedirle a un modelo una cifra de mercado, un precio actual o una fecha de lanzamiento sin darle ninguna fuente, y esperar que acierte. No va a acertar de forma fiable, porque su conocimiento tiene un corte temporal y porque los precios y las cifras de mercado cambian constantemente. Si necesitas ese dato, búscalo tú (o dale al modelo una herramienta de búsqueda) y pásaselo como contexto. No se lo pidas de memoria y luego te sorprendas de que se lo haya inventado.

El caso de las herramientas frente al conocimiento memorizado

Otra distinción que ayuda: hay tareas donde el modelo necesita razonar sobre información que ya tiene (resumir un texto que le has pasado, comparar dos opciones que describes en el prompt) y tareas donde necesita un dato externo que cambia con el tiempo. Confundir ambas es una fuente frecuente de alucinaciones evitables. Si la tarea es del segundo tipo, dale acceso a una herramienta —búsqueda, base de datos, API— en vez de confiar en que lo recuerde bien. No es un matiz menor: es la diferencia entre un sistema que falla de forma predecible cuando le faltan datos y uno que falla de forma silenciosa inventando algo plausible.

La conclusión incómoda

Las alucinaciones no se "arreglan" del todo. Se reducen. Cualquiera que te venda un prompt que las elimina por completo te está vendiendo humo. Lo que puedes controlar es cuánta información real le das al modelo, cuánto margen de improvisación le dejas, y si tienes un proceso para detectar el error antes de que llegue al usuario final.

Relacionado: Automatizar tareas sin perder el control del resultado