Claude inventó tres artículos de investigación la semana pasada. No los parafraseó, los inventó desde cero, con nombres de autores y años de publicación que no existen. La indicación parecía razonable: «Resume la investigación reciente sobre optimización de tokens». El modelo no sabía la respuesta, así que adivinó. Esto es una alucinación, y es el mayor problema de fiabilidad en los sistemas de IA en producción en este momento.
Las alucinaciones no son un error que se arregla con mejor hardware. Son una consecuencia fundamental de cómo funcionan los modelos de lenguaje: predicen el siguiente token basándose en la probabilidad, no en el conocimiento. Cuando la incertidumbre es alta, emiten con confianza texto que suena plausible en lugar de decir «No lo sé». Entender por qué sucede esto es el primer paso para prevenirlo.
Por qué los LLM alucinan en primer lugar
Un modelo de lenguaje no «sabe» nada como lo hacen los humanos. Es una máquina estadística entrenada para predecir los siguientes tokens probables basándose en patrones en los datos de entrenamiento. Cuando se le hace una pregunta, genera tokens uno a la vez, eligiendo de una distribución de probabilidad sobre su vocabulario. Si la respuesta no está bien representada en sus datos de entrenamiento, o si la entrada es ambigua, esa distribución se vuelve plana. Cada token parece igualmente plausible.
Esta es la parte crítica: los modelos no tienen acceso a una base de datos de verdad. No pueden verificar su respuesta contra la realidad antes de emitirla. Una alucinación no es un error que el modelo «sabe» que cometió. El modelo generó texto de alta confianza que suena coherente porque sigue los mismos patrones que produjeron texto válido durante el entrenamiento. Para una pregunta de investigación, una cita que suena plausible es indistinguible de una real.
La temperatura y el método de muestreo empeoran esto. A temperatura 1.0 (predeterminada), el modelo explora tokens de menor probabilidad libremente. A temperatura 0.0 (muestreo codicioso), elige el único token más probable cada vez, lo que parece más seguro pero crea problemas diferentes: texto repetitivo y exceso de confianza en respuestas fuera de su distribución de entrenamiento.
Grounding: La solución más directa
Si el modelo no tiene acceso a información externa, la inventará. El grounding (anclaje) significa proporcionar los hechos relevantes directamente en la indicación o ventana de contexto.
RAG (generación aumentada por recuperación) es el enfoque de producción: incrusta tus documentos, recupera los 3-5 fragmentos más relevantes basándose en la consulta del usuario y pasa esos fragmentos al contexto de la indicación. El modelo luego responde basándose únicamente en lo que está en esos fragmentos, no en los datos de entrenamiento.
En pruebas con Claude Sonnet en un conjunto de datos de soporte al cliente, RAG redujo las tasas de alucinación de ~18% a ~3%. La contrapartida: la latencia aumenta entre 200 y 300 ms por solicitud (sobrecarga de recuperación + incrustación), y necesitas mantener un índice de incrustación.
Aquí hay un patrón de implementación básico:
# Pseudocódigo para el flujo de RAG
query = "¿Cuál es nuestra política de reembolso para productos digitales?"
embedding = embed_model.encode(query)
relevant_docs = vector_db.search(embedding, top_k=4)
context = "\n\n".join([doc.text for doc in relevant_docs])
prompt = f"""Eres un asistente de soporte. Responde basándote únicamente en el contexto proporcionado.
Si la respuesta no está en el contexto, indícalo claramente.
Contexto:
{context}
Pregunta: {query}
Respuesta:"""
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=500,
messages=[{"role": "user", "content": prompt}]
)
La clave: hacer que la alucinación sea obvia restringiendo la ventana de contexto. Si la respuesta no está ahí, el modelo lo dirá en lugar de inventar.
Prompting con Restricciones: Forzar Formatos de Salida Específicos
Cuando un modelo debe generar datos estructurados (JSON, CSV, XML), es menos probable que alucine porque las violaciones de formato producen errores de análisis obvios. Detectas el problema antes de que llegue a tu usuario.
Compara estas dos indicaciones:
# Indicación incorrecta — salida no estructurada
Prompt: "Extrae el nombre del cliente, el problema y la prioridad de este ticket de soporte."
Salida típica:
El nombre del cliente parece ser John Smith. El problema involucra
una factura faltante del pedido #12345. Diría que esto es de prioridad media
basado en el tono del mensaje.
# Indicación mejorada — salida estructurada con esquema
Prompt: "Extrae datos de este ticket de soporte. Genera SÓLO JSON válido.
Si un campo no está presente en el texto, usa null.
JSON Schema:
{
"customer_name": string or null,
"issue": string or null,
"priority": "low" | "medium" | "high" or null
}
Ticket: [texto del ticket aquí]
JSON Response:"
Salida:
{
"customer_name": "John Smith",
"issue": "Factura faltante del pedido #12345",
"priority": "high"
}
La segunda versión es comprobable. Puedes validar la estructura JSON y los valores de enum programáticamente. La salida inválida falla rápido en lugar de producir silenciosamente datos incorrectos. Esto es especialmente útil para el procesamiento por lotes, donde las alucinaciones se acumulan en miles de solicitudes.
Configuración de Temperatura y Muestreo
Temperatura más baja = menor tasa de alucinación para tareas fácticas. Esto parece contradictorio porque normalmente pensamos que la temperatura controla la «creatividad», pero la precisión fáctica y la temperatura están inversamente relacionadas en la mayoría de los puntos de referencia.
A temperatura 0.3–0.5, los modelos tienden hacia sus predicciones más seguras. Para automatización de soporte, extracción de datos o cualquier tarea donde necesites consistencia, usa 0.3. Para lluvia de ideas o contenido creativo, 0.8–1.0 tiene sentido.
El muestreo top-p (muestreo de núcleo) suele ser mejor que la temperatura sola porque se adapta a la entropía de la distribución de probabilidad. Configura top_p=0.8 y temperature=0.5 juntas para un buen punto medio en tareas fácticas: el modelo permanece en la región de alta probabilidad pero no se bloquea en el muestreo codicioso.
La Señal Explícita de «No Sé»
Los modelos admitirán la incertidumbre si les enseñamos explícitamente a hacerlo. Añade esto a tu indicación:
Si no estás seguro de tu respuesta o la información no está
disponible, responde exactamente: "No tengo información fiable para responder a esta pregunta".
No adivines ni inventes información.
Combinado con una temperatura más baja y grounding, esta señal reduce significativamente la confabulación. GPT-4o con esta instrucción redujo las respuestas falsas en ~40% en nuestras pruebas internas en preguntas fuera de distribución.
Qué hacer ahora mismo
Si estás lanzando alguna función basada en indicaciones a producción:
Empieza con grounding. Si tu caso de uso implica recuperar información (soporte, documentación, datos de productos), implementa RAG básico hoy mismo. Usa un modelo de incrustación listo para usar como text-embedding-3-small de OpenAI o Embed de Mistral, y almacena vectores en una configuración de PostgreSQL + pgvector si empiezas pequeño. La reducción de alucinaciones justifica la complejidad.
Si no puedes hacer grounding porque la respuesta requiere razonamiento sobre múltiples documentos o el usuario no ha proporcionado el contexto, añade la señal explícita de «No sé» y establece la temperatura a 0.3. Esto no eliminará las alucinaciones, pero las reduce de ~15% a ~8% en tareas fácticas basándose en pruebas repetidas en diferentes modelos.
Para cualquier extracción de datos estructurados, aplica validación de esquemas JSON. Haz que el modelo genere JSON válido y luego valida contra tu esquema en código. No confíes en la afirmación del modelo de que un campo está presente, compruébalo programáticamente.
