La alucinación como modo de fallo

Descripción

De todos los fallos que puede tener un componente de IA, hay uno que no se parece a nada de lo que conocías antes de integrar un LLM: el modelo inventa un dato con total confianza. No se equivoca a gritos, no lanza una excepción, no devuelve null ni un código de error. Genera una respuesta fluida, bien redactada, con el mismo aplomo de siempre, y ese dato es falso. En Mercado, el agente de soporte le dice a un cliente "tu pedido va con la guía TRK-4521" y esa guía no existe; el modelo la produjo porque sonaba como una guía, no porque la hubiera consultado. Esta lección instala el principio para tratarla: la alucinación es un modo de fallo, no una rareza a tolerar, y se contiene igual que cualquier otro fallo —con una defensa arquitectónica—: verificar todo claim factual contra una fuente de verdad determinista antes de servirlo, y degradar cuando no se puede verificar.

En la lección 2 clasificaste la alucinación como el fallo silencioso por excelencia: el que ningún try/except atrapa. Aquí bajamos a la defensa concreta. Vas a ver, ejecutado, al agente de soporte de Mercado respondiendo preguntas sobre pedidos —a veces citando el dato correcto, a veces inventándolo— y una verificación contra la fuente de verdad (el registro real de pedidos) que separa lo real de lo inventado: lo que coincide se sirve, lo que el modelo inventó se bloquea y degrada a un "no puedo confirmarlo, te comunico con un agente".

Conexión con el módulo. La lección 2 te dio la taxonomía; esta toma la familia contenido —el fallo silencioso— y le construye su defensa. Es la contraparte de las lecciones 4, 5 y 6, que defienden los fallos ruidosos (disponibilidad): aquí, como el fallo no se anuncia, la defensa no puede ser "atrapar una excepción", tiene que ser "verificar activamente". La frontera con AI Engineering es dura y aquí importa mucho: no vamos a enseñarte a reducir las alucinaciones construyendo un buen RAG, ajustando el prompt o haciendo fine-tuning —eso es el ecosistema de AI Engineering—; vamos a tratarlas como un modo de fallo que la arquitectura debe contener, asumiendo que el modelo va a alucinar y diseñando para que ese fallo no llegue al cliente.

Una analogía: el empleado que cuando no sabe, escala en vez de inventar

Vuelve al empleado de atención al cliente de la lección 1, pero mírale de cerca la mejor virtud. Le llega un cliente y le pregunta: "¿cuándo llega exactamente mi pedido y con qué paquetería?". El empleado bueno hace algo muy específico antes de contestar: consulta el sistema. Si el sistema le muestra el estado y la guía, los da con confianza. Si el sistema no tiene el dato, o el pedido no aparece, el empleado no se lo inventa para quedar bien: dice "déjame verificar con un compañero" o escala al supervisor. La diferencia entre este empleado y uno malo no es que sepa más; es que sabe cuándo no confiar en su propia memoria y tiene la disciplina de verificar antes de afirmar, y la humildad de escalar cuando no puede.

El empleado malo, en cambio, contesta siempre. Le preguntan por un pedido que no encuentra y responde "llega el jueves, va con la paquetería exprés" —un dato que sonó razonable, dicho con seguridad, completamente inventado—. El cliente le cree, deja de esperar el jueves, y cuando el paquete no llega, el problema es más grande que el de admitir "no lo tengo a la mano, déjame confirmarlo". El empleado malo prefirió parecer útil a ser correcto.

Aquí está el punto: un LLM, por defecto, es el empleado malo —contesta siempre, incluso cuando no sabe—, y la arquitectura tiene que convertirlo en el empleado bueno. El modelo no tiene, por sí solo, el instinto de "verificar antes de afirmar" ni el de "escalar cuando no puedo": genera una respuesta plausible pase lo que pase. Ese instinto se lo pone el sistema alrededor: una capa que consulta la fuente de verdad para confirmar cada dato factual que el modelo afirma, y que degrada —escala a humano, dice "no puedo confirmarlo"— cuando el dato no se puede verificar. El modelo propone la respuesta; el sistema la confronta con la realidad antes de dejarla salir. En Mercado, la fuente de verdad es el registro de pedidos; la verificación es el jefe sensato que revisa antes de que el empleado abra la boca.

Ejemplo trabajado: verificar el claim contra la fuente de verdad

Vamos a construir la defensa. Tenemos una fuente de verdad determinista, ORDERS: el estado real de tres pedidos de Mercado (su status y su número de guía tracking). El agente de soporte (un stub) responde preguntas sobre pedidos, y en su respuesta cita un estado y una guía. A veces cita bien; a veces alucina —inventa un pedido que no existe, o un estado o una guía que no coinciden con la realidad—. Todas las respuestas suenan igual de seguras; esa es la trampa.

La función is_grounded es la defensa: toma el claim del modelo (el pedido, el estado, la guía que afirma) y lo confronta con ORDERS. Si el pedido no existe, o el estado no coincide, o la guía no coincide, el claim está desanclado de la realidad —es una alucinación— y se bloquea. Lo que no se puede verificar no se sirve: se degrada a una respuesta segura que escala a un humano.

# Leccion 3: la ALUCINACION como modo de fallo. El modelo inventa con
# confianza un dato que no existe. La contencion arquitectonica: verificar
# el claim del modelo contra una FUENTE DE VERDAD determinista antes de
# servirlo; si no se puede verificar, DEGRADAR (escalar a humano / no afirmar).
# LLM simulado; sin red.

# Fuente de verdad de Mercado (deterministic): el estado real de los pedidos.
ORDERS = {
    "A-1001": {"status": "shipped",    "tracking": "TRK-77"},
    "A-1002": {"status": "processing", "tracking": None},
    "A-1003": {"status": "delivered",  "tracking": "TRK-88"},
}

# El agente de soporte (stub) responde una pregunta sobre un pedido. A veces
# CITA correctamente; a veces ALUCINA: inventa un pedido, un estado o un
# numero de guia que NO coinciden con la fuente de verdad. Fijate: todas las
# respuestas SUENAN igual de seguras.
AGENT_REPLIES = [
    # (order_id, claim_status, claim_tracking, texto para el cliente)
    ("A-1001", "shipped",    "TRK-77", "Tu pedido va en camino, guia TRK-77."),
    ("A-1002", "shipped",    "TRK-99", "Tu pedido ya salio, guia TRK-99."),
    ("A-1003", "delivered",  "TRK-88", "Tu pedido fue entregado."),
    ("A-9999", "processing", None,     "Tu pedido A-9999 se esta preparando."),
    ("A-1002", "processing", None,     "Tu pedido se esta preparando."),
    ("A-1001", "delivered",  "TRK-77", "Tu pedido ya fue entregado."),
]

SAFE_FALLBACK = "No puedo confirmar ese dato ahora mismo; te comunico con un agente."


def is_grounded(order_id, claim_status, claim_tracking):
    # Verificacion determinista: el claim del modelo DEBE coincidir con la
    # fuente de verdad. Un dato que el modelo no puede respaldar no se sirve.
    order = ORDERS.get(order_id)
    if order is None:
        return (False, f"pedido {order_id} no existe")
    if claim_status != order["status"]:
        return (False, f"estado citado '{claim_status}' != real '{order['status']}'")
    if claim_tracking != order["tracking"]:
        return (False, f"guia citada '{claim_tracking}' != real '{order['tracking']}'")
    return (True, "verificado contra la fuente de verdad")


served = blocked = 0
print(f"{'pedido':<9}{'veredicto':<10}{'razon':<47}servido al cliente")
print("-" * 100)
for oid, cs, ct, text in AGENT_REPLIES:
    ok, reason = is_grounded(oid, cs, ct)
    if ok:
        served += 1
        out = text
        verdict = "SIRVE"
    else:
        blocked += 1
        out = SAFE_FALLBACK
        verdict = "BLOQUEA"
    print(f"{oid:<9}{verdict:<10}{reason:<47}{out}")

print("-" * 100)
print(f"{served} respuestas servidas (verificadas), "
      f"{blocked} alucinaciones bloqueadas antes de llegar al cliente.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

pedido   veredicto razon                                          servido al cliente
----------------------------------------------------------------------------------------------------
A-1001   SIRVE     verificado contra la fuente de verdad          Tu pedido va en camino, guia TRK-77.
A-1002   BLOQUEA   estado citado 'shipped' != real 'processing'   No puedo confirmar ese dato ahora mismo; te comunico con un agente.
A-1003   SIRVE     verificado contra la fuente de verdad          Tu pedido fue entregado.
A-9999   BLOQUEA   pedido A-9999 no existe                        No puedo confirmar ese dato ahora mismo; te comunico con un agente.
A-1002   SIRVE     verificado contra la fuente de verdad          Tu pedido se esta preparando.
A-1001   BLOQUEA   estado citado 'delivered' != real 'shipped'    No puedo confirmar ese dato ahora mismo; te comunico con un agente.
----------------------------------------------------------------------------------------------------
3 respuestas servidas (verificadas), 3 alucinaciones bloqueadas antes de llegar al cliente.

Lee la tabla con calma, porque cada fila es una forma distinta de alucinar y de contenerla.

Las tres respuestas servidas son las que el modelo pudo respaldar: A-1001 (dijo "shipped, TRK-77" y así es), A-1003 (dijo "delivered" y así es), y el segundo A-1002 (dijo "processing" y así es). En estos tres, el claim del modelo coincidió con la fuente de verdad, así que el texto real llegó al cliente. Fíjate: no bloqueamos al modelo por desconfianza ciega; cuando el modelo acierta y lo podemos probar, su respuesta pasa. La verificación no es un candado que apaga la feature; es una compuerta que deja pasar lo verificable.

Las tres bloqueadas son las tres formas de alucinar, cada una distinta:

• A-1002 "shipped, TRK-99": el modelo inventó tanto el estado (dijo "shipped" cuando está "processing") como una guía (TRK-99) que no existe. La verificación lo atrapó por el estado. Sin ella, el cliente habría creído que su pedido ya salió con una guía que no rastrea nada.
• A-9999: el modelo inventó un pedido entero. No existe en ORDERS. Este es el caso más elocuente: el cliente ni siquiera preguntó por A-9999 necesariamente, o el modelo confundió un número, pero el resultado es un dato sobre un pedido fantasma. La verificación lo bloquea con "pedido A-9999 no existe".
• A-1001 "delivered": el modelo dijo que un pedido en camino ya fue entregado. Es el error más caro en soporte: un cliente al que le dicen "ya te llegó" cuando no le ha llegado deja de esperar y no reclama. La verificación lo atrapa comparando el estado citado con el real.

En las tres, la respuesta que llegó al cliente no fue la alucinación: fue el SAFE_FALLBACK, "no puedo confirmar ese dato ahora mismo; te comunico con un agente". Eso es la degradación: cuando el modelo afirma algo que no se puede verificar, el sistema no sirve la afirmación —la reemplaza por una respuesta honesta que escala a un humano—. Es exactamente el empleado bueno: cuando no puede confirmar, escala en vez de inventar.

La implicación arquitectónica: 3 de 6 respuestas del modelo eran alucinaciones, y ninguna llegó al cliente, no porque el modelo mejorara —es el mismo modelo, alucina igual—, sino porque cada dato factual que afirmó se confrontó con la fuente de verdad antes de salir. La confianza en el agente de soporte no viene de que el modelo no aluvine; viene de que el sistema verifica lo que el modelo dice.

Profundización: contener la alucinación sin pretender eliminarla

La distinción que marca la frontera con AI Engineering. Hay dos preguntas muy distintas sobre la alucinación, y esta guía solo responde una. La primera es "¿cómo hago que el modelo aluvine menos?" —mejor prompt, RAG que le dé el contexto correcto, fine-tuning, un modelo más capaz—; esa es la pregunta de AI Engineering, y es real e importante. La segunda es "¿cómo diseño el sistema para que, cuando el modelo aluvine —porque va a alucinar—, ese fallo no llegue al usuario?"; esa es la pregunta arquitectónica, la de este módulo. La diferencia es la misma que entre "hacer que el elevador falle menos" (ingeniería del elevador) y "poner escaleras para cuando falle" (arquitectura del edificio). Puedes y debes hacer ambas, pero son trabajos distintos, y confundirlas es un error caro: un equipo que solo trabaja en "que aluvine menos" nunca llega a cero, y sin la contención arquitectónica, el residuo —siempre habrá residuo— llega al cliente.

Qué se puede verificar y qué no. La defensa de esta lección —verificar contra la fuente de verdad— funciona de maravilla para claims factuales sobre datos que tienes: el estado de un pedido, la existencia de un producto, un precio, un saldo. Todos esos viven en una base de datos determinista que puedes consultar. La verificación es la confrontación del claim del modelo contra ese dato. Pero no todo claim es verificable así: si el modelo redacta un texto de disculpa, no hay una "fuente de verdad" contra la cual comparar la redacción. La regla de diseño que se deriva: estructura la respuesta del modelo para separar lo verificable de lo no verificable, y verifica lo verificable. En el agente de soporte, en vez de dejar que el modelo escriba libremente "tu pedido A-1001 va con la guía TRK-77", haces que el modelo proponga los campos (order_id, status, tracking) y el sistema los verifica y rellena la plantilla con los datos reales. El modelo aporta el tono y la intención; el sistema aporta los hechos. Este patrón —el modelo propone, el sistema dispone— es exactamente lo que el módulo 6 desarrolla a fondo.

Degradar es parte de la respuesta, no un error. Cuando la verificación bloquea un claim, el sistema no se queda mudo ni lanza un error crudo al cliente: degrada a una respuesta segura. Y hay una jerarquía de degradaciones, de mejor a peor: (1) servir el dato verificado directamente de la fuente de verdad, saltándose el texto del modelo ("tu pedido está en estado: processing"); (2) decir honestamente "no puedo confirmar ese dato ahora mismo"; (3) escalar a un humano que sí puede resolver. El SAFE_FALLBACK del ejemplo combina (2) y (3). Lo que nunca se hace es servir el claim no verificado. Nota la conexión con la lección 1: esto es el empleado que escala al supervisor, y con la lección 5: es una degradación elegante —una respuesta peor pero válida en vez de una caída o una mentira—.

El costo asimétrico: por qué se verifica siempre. Un compañero podría decir "el modelo acierta el 90% de las guías, ¿de verdad hay que verificar todas?". La respuesta está en el costo asimétrico. Verificar un claim contra la base de datos cuesta una consulta —microsegundos, un índice—. Servir una alucinación cuesta la cadena entera de decisiones que el cliente toma sobre un dato falso: espera un paquete que no llega, no reclama a tiempo, pierde su ventana de devolución, se va a la competencia. La verificación es barata y el fallo silencioso es caro, así que la verificación va siempre, no solo cuando "sospechas". La tasa de acierto del modelo decide cuánto vas a degradar (si aluvina el 10%, degradarás el 10%), no si verificas.

Anatomía de la contención. Vale la pena fijar la forma, porque la vas a aplicar a cada dato factual que un componente de IA afirme:

    pregunta del cliente
            │
            ▼
   ┌─────────────────┐
   │  agente (LLM)   │   PROPONE una respuesta con claims factuales
   │  (stub)         │   (order_id, status, tracking). Puede ALUCINAR.
   └─────────────────┘
            │  claim propuesto (NO verificado)
            ▼
   ┌─────────────────┐        ┌──────────────────────┐
   │   is_grounded   │◄──────►│  ORDERS (fuente de   │
   │  (verificacion) │        │  verdad determinista) │
   └─────────────────┘        └──────────────────────┘
        │            │
    COINCIDE     NO COINCIDE
        │            │
        ▼            ▼
  sirve el dato   degrada (escala a humano / "no puedo confirmarlo")

Errores comunes

Confiar en la salida alucinada porque suena segura. Qué pasa: el agente responde "tu pedido fue entregado ayer, guía TRK-4521" con una redacción impecable, y el sistema la sirve tal cual porque no lanzó ninguna excepción y "se ve bien". El dato era inventado. Por qué pasa: la fluidez del modelo se confunde con corrección, y como el fallo es silencioso, nada lo detiene. Cómo detectarlo: tu sistema sirve datos que el modelo afirma sin confrontarlos contra una fuente de verdad. Cómo corregirlo: verifica cada claim factual contra el dato real antes de servirlo, y degrada si no coincide. El ejemplo lo ejecuta: 3 alucinaciones bloqueadas de 6 respuestas.

Pretender eliminar la alucinación en vez de contenerla. Qué pasa: el equipo invierte meses en un prompt perfecto y un RAG afinado para bajar la tasa de alucinación, la baja del 10% al 2%, y declara el problema resuelto —quita la verificación porque "ya casi no aluvina"—. El 2% restante ahora llega al cliente sin ninguna barrera. Por qué pasa: se confunde reducir la frecuencia (trabajo de AI Engineering, valioso) con contener el fallo (trabajo de arquitectura, imprescindible). Cómo detectarlo: tu única defensa contra la alucinación es "hicimos que aluvine poco"; no hay una verificación que atrape el residuo. Cómo corregirlo: reduce la frecuencia y contén el residuo con verificación —las dos cosas, porque ningún modelo llega a cero—. La contención va siempre, sin importar qué tan bueno sea el modelo.

Verificar unos claims y otros no. Qué pasa: el sistema verifica el estado del pedido contra la base de datos, pero deja que el modelo invente libremente la fecha estimada de entrega o el nombre de la paquetería, porque "esos son detalles". El cliente recibe una fecha inventada. Por qué pasa: se verifica lo que es fácil de verificar y se deja pasar lo demás, sin darse cuenta de que un solo dato inventado en una respuesta por lo demás correcta ya es una alucinación servida. Cómo detectarlo: en tu respuesta hay campos factuales que el modelo llena y el sistema no confronta contra ninguna fuente. Cómo corregirlo: estructura la respuesta para que todos los campos factuales vengan de la fuente de verdad (el sistema los rellena), y el modelo aporte solo el tono y la intención. Lo que el sistema no pueda verificar, no lo afirma. Es el patrón "el modelo propone, el sistema dispone" del módulo 6.

Ejercicios

Ejercicio 1 — Las tres formas de alucinar. En el ejemplo, las tres respuestas bloqueadas alucinaron de formas distintas. Para cada una, di qué inventó el modelo y por qué la verificación la atrapó: (a) A-1002 "shipped, TRK-99"; (b) A-9999; (c) A-1001 "delivered". Luego propón un cuarto tipo de alucinación que la verificación del ejemplo no atraparía, y cómo extenderías is_grounded para cubrirlo.

Ejercicio 2 — El modelo propone, el sistema rellena. El diseño del ejemplo deja que el modelo cite el estado y la guía, y luego los verifica. Un diseño alternativo hace que el modelo proponga solo el order_id y la intención (responder sobre el estado), y el sistema rellene el estado y la guía desde ORDERS. Escribe (en pseudocódigo o Python) ese diseño alternativo, y explica por qué elimina de raíz la posibilidad de que un estado o una guía inventados lleguen al cliente.

def answer_about_order(order_id):
    # El modelo YA NO cita datos factuales; solo identifica el pedido.
    # El sistema rellena los hechos desde la fuente de verdad.
    order = ORDERS.get(order_id)
    if order is None:
        return SAFE_FALLBACK   # el pedido no existe: degradar
    status = order["status"]        # dato REAL, no del modelo
    tracking = order["tracking"]    # dato REAL, no del modelo
    if tracking:
        return f"Tu pedido {order_id} esta en estado: {status}, guia {tracking}."
    return f"Tu pedido {order_id} esta en estado: {status}."

Ejercicio 3 — Cuándo NO alcanza con verificar. La defensa de esta lección asume que existe una fuente de verdad determinista contra la cual confrontar el claim. Da un ejemplo de una feature de IA de Mercado donde el claim del modelo no se puede verificar contra una fuente de verdad estructurada, y describe qué otra defensa arquitectónica usarías en su lugar (pista: piensa en la degradación y en la revisión humana).

Resumen y siguiente paso

En esta lección instalaste el principio para tratar la alucinación: es un modo de fallo que se contiene con una defensa arquitectónica —verificar cada claim factual contra una fuente de verdad determinista y degradar cuando no se puede verificar—, no una rareza que se tolera. Lo viste con el empleado bueno que consulta el sistema y escala cuando no sabe, frente al malo que inventa para quedar bien, y lo mediste: el agente de soporte de Mercado produjo 3 alucinaciones de 6 respuestas —un estado inventado, un pedido inexistente, un estado falsamente avanzado— y ninguna llegó al cliente, porque cada dato factual se confrontó con el registro real de pedidos y lo no verificable se degradó a "no puedo confirmarlo, te comunico con un agente". Y viste la frontera dura con AI Engineering: aquí no reducimos la alucinación (eso es RAG/prompt/fine-tuning, otro ecosistema); la contenemos, asumiendo que el modelo va a alucinar.

Antes de avanzar deberías poder: explicar por qué la alucinación es un fallo silencioso que ningún try/except atrapa; verificar un claim contra una fuente de verdad y degradar cuando no coincide; distinguir "reducir la alucinación" (AI Eng) de "contener la alucinación" (arquitectura); y reconocer cuándo un claim no es verificable y qué defensa usar en su lugar.

La lección 4 cambia de familia: de los fallos silenciosos (contenido) a los fallos ruidosos (disponibilidad). Vas a ver, ejecutado, qué pasa cuando el modelo está caído, lento o rate-limited —depender de una API externa con cuotas— y la primera defensa de esa familia: el timeout, para no esperar para siempre a una API que se colgó. Vas a medir cómo un timeout de 800 ms recorta la espera de un cuelgue de 30 segundos, y cómo el sistema, en vez de bloquearse, cae al fallback y responde. La mecánica del timeout a fondo vive en la guía de resiliencia; aquí lo aplicamos al modelo.

Recursos

• Chip Huyen, AI Engineering (O'Reilly, 2024). Los capítulos sobre confiabilidad y sobre RAG tratan la alucinación como un modo de fallo de los modelos de fundación y las estrategias para detectarla y contenerla (grounding, verificación) —el marco conceptual de esta lección—. En inglés.
• Anthropic, documentación de Claude — docs.anthropic.com. Las guías sobre reducir alucinaciones y sobre pedir salidas verificables (con citas, con salida estructurada) muestran, a nivel conceptual, cómo estructurar la respuesta del modelo para poder confrontarla con una fuente —sin fijar versión de modelo—. En inglés.
• Martin Fowler y Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. Los patrones de guardrails y de verificación de la salida alrededor de un componente de IA encuadran la contención de la alucinación como diseño. En inglés.
• Para reducir (no solo contener) la alucinación con RAG, prompting o fine-tuning, el destino es el ecosistema de AI Engineering —fuera del alcance de esta guía, que trata la alucinación como un modo de fallo arquitectónico—.