Alucinaciones, límites y verificación
El problema no es que se equivoque. Es que se equivoca con la misma redacción impecable con la que acierta.
La fecha que estaba mal y sonaba bien
Volvamos al correo con el que abrimos el máster. El modelo le dio a Marta una fecha de presentación equivocada. Lo interesante no es el fallo: los becarios también fallan, y los socios. Lo interesante es cómo falló.
Cuando un humano no está seguro de una fecha, deja rastro. Dice "creo que era a finales de enero", mira el calendario, pregunta, o escribe una frase más vaga de lo normal. Ese rastro es lo que permite que un despacho funcione: no revisamos todo, revisamos lo que viene marcado como dudoso. El modelo no dejó ningún rastro. Escribió la fecha equivocada con la misma sintaxis limpia, el mismo tono y los mismos dos matices profesionales con los que habría escrito la correcta.
Lo que se ha roto es la señal, no la exactitud. Y como todos los procesos de revisión de una oficina están construidos sobre esa señal, meter un modelo dentro sin rediseñar la revisión no es "ir más rápido": es quitarle el detector de humo al edificio y confiar en que nadie fume. Este módulo va de volver a poner detectores, y va de cuánto cuestan.
📋 Guía docente del módulo
Objetivos
- Explicar, desde el mecanismo, por qué un modelo de lenguaje produce afirmaciones falsas con alta fluidez.
- Clasificar los tipos de error —invención factual, infidelidad al contexto, error de cálculo, omisión, adulación— y reconocer cuál es más probable en cada tarea.
- Modelar cuantitativamente cuántos errores llegan al destinatario final en función de la tasa de error y de la tasa de detección.
- Diseñar controles que aumenten la detectabilidad en lugar de confiar en la buena voluntad del revisor.
- Decidir, con criterios explícitos, qué tareas no deben automatizarse.
Resultados de aprendizaje
- RA1. Calcular el número esperado de errores que alcanzan al cliente a partir de volumen, tasa de error y tasa de detección.
- RA2. Comparar dos inversiones —reducir la tasa de error o aumentar la detección— por coste unitario de error evitado.
- RA3. Proponer al menos cuatro controles de diseño que conviertan un fallo silencioso en uno visible.
- RA4. Situar una tarea en la matriz coste-del-error contra verificabilidad y justificar la decisión de automatizar o no.
- RA5. Explicar por qué el cálculo del valor esperado subestima sistemáticamente los errores raros y graves.
Bibliografía de referencia
- Ji, Z. et al.: "Survey of Hallucination in Natural Language Generation", ACM Computing Surveys, 2023 — la revisión que ordena el fenómeno y su terminología.
- Parasuraman, R. y Riley, V.: "Humans and Automation: Use, Misuse, Disuse, Abuse", Human Factors, 1997 — el clásico sobre el sesgo de automatización, escrito décadas antes y perfectamente vigente.
- Sharma, M. et al.: "Towards Understanding Sycophancy in Language Models", 2023 — la adulación como consecuencia medible del entrenamiento con preferencias humanas.
- Mata contra Avianca, Tribunal del Distrito Sur de Nueva York, junio de 2023 — el caso de las seis sentencias inexistentes; lectura obligada de diez minutos.
- Moffatt contra Air Canada, Civil Resolution Tribunal de Columbia Británica, febrero de 2024 — quién responde de lo que dice tu asistente automático.
Carga de trabajo estimada
| Actividad | Horas |
|---|---|
| Lectura y estudio del material | 6 |
| Experimentación con el simulador | 2 |
| Ejercicios (resueltos y por cuenta propia) | 5 |
| Evaluación (quiz de módulo y repaso) | 2 |
| Total | 15 |
Por qué inventa: tres causas, ninguna misteriosa
La palabra "alucinación" es desafortunada porque sugiere una avería. No hay avería: el sistema está haciendo exactamente aquello para lo que se construyó. Hay tres razones encadenadas y todas salen de lo que ya sabes.
Primera: no hay ninguna pieza que distinga saber de sonar. El modelo calcula qué continuación es probable dado el texto anterior. "Probable" quiere decir que se parece a lo que aparecía en el entrenamiento, no que sea verdad. Una fecha inventada con formato correcto en el sitio correcto de la frase es exactamente igual de probable, mecánicamente, que la fecha correcta. No hay un módulo aparte que compruebe nada, porque no hay contra qué comprobar: no hay una base de datos dentro.
Segunda: el entrenamiento premia responder. Durante la fase de refuerzo con preferencias humanas, los evaluadores puntúan mejor las respuestas completas y seguras que las que dicen "no tengo ese dato". Es una preferencia razonable en el 95% de los casos y un desastre en el 5% restante. El sistema aprendió la regla general, incluido su borde equivocado.
Tercera: la fluidez es la tarea, no un efecto secundario. Todo lo que hace el modelo está optimizado para producir texto que fluya. Cuando el contenido falla, la fluidez no falla con él, porque son cosas independientes dentro del sistema. En un humano no lo son, y por eso nuestra intuición se equivoca aquí de forma tan sistemática.
Un apunte técnico útil: hay señales internas —la probabilidad que el propio modelo asignó a sus tokens, la entropía del simulador del módulo 1— que correlacionan algo con la fiabilidad, y hay líneas de investigación activas para explotarlas. Pero "algo" no es "bastante", y la mayoría de las herramientas comerciales hoy no te exponen esa señal. No cuentes con un semáforo de confianza fiable: cuenta con el diseño del proceso.
Los seis errores, ordenados por lo caros que salen en un despacho
| Tipo | Qué es | Ejemplo en la gestoría | Detectable a ojo |
|---|---|---|---|
| Invención factual | Un dato que no existe, con formato perfecto | Una fecha de presentación, un porcentaje de retención, un artículo de una ley | No, salvo que sepas la respuesta |
| Infidelidad al contexto | Contradice el documento que le has dado | La ficha dice estimación directa y el borrador razona en módulos | Sí, si comparas — y casi nadie compara |
| Error de cálculo | Aritmética mal hecha con aspecto correcto | Un prorrateo de IVA, la suma de doce importes | Solo si rehaces la cuenta |
| Omisión | Lo que no dice, y hacía falta | No menciona el recargo por presentación fuera de plazo | Muy difícil: no hay nada que mirar |
| Sobregeneralización | Convierte un caso particular en regla | "Los autónomos pueden deducir el 100% del portátil" | Sí, si el revisor conoce las excepciones |
| Adulación | Te da la razón porque se la has pedido | "Efectivamente, como usted apunta, el plazo era el 30" | No: parece confirmación independiente |
Las dos peores de la lista son omisión y adulación, y ninguna de las dos aparece en las conversaciones sobre alucinaciones. La omisión, porque revisar consiste en mirar lo que está escrito y ahí no hay nada que mirar. La adulación, porque el revisor suele ser la misma persona que formuló la pregunta con la hipótesis dentro, así que lee su propia idea devuelta y la interpreta como una segunda opinión. Es el peor sesgo de los seis precisamente porque se siente como validación.
Contramedida barata para la adulación, y que cuesta cero euros: formula la pregunta sin tu hipótesis y, si vas a contrastar algo, pídele que argumente en contra. "¿Qué razones habría para que este gasto NO fuese deducible?" produce un texto mucho más informativo que "esto es deducible, ¿verdad?".
Dos casos reales que ahorran una explicación larga
Mata contra Avianca (Tribunal del Distrito Sur de Nueva York, junio de 2023). Un abogado presentó un escrito con seis sentencias que respaldaban su posición. Ninguna existía: se las había generado un modelo de lenguaje. Cuando el juez pidió las copias, el abogado volvió a preguntarle al mismo modelo si las sentencias eran reales, y el modelo le dijo que sí. El tribunal impuso una sanción de 5.000 dólares al letrado, a su compañero y al bufete.
Hay dos lecciones ahí y la segunda es la importante. La primera, obvia: no cites lo que no has comprobado. La segunda: preguntarle al modelo si lo que ha dicho es verdad no es una verificación. Es otra generación de texto plausible sobre el mismo tema, con el contexto ya sesgado hacia el sí. Un sistema no puede ser su propio control de calidad si el control usa el mismo mecanismo que produjo el error.
Moffatt contra Air Canada (Civil Resolution Tribunal de Columbia Británica, febrero de 2024). El asistente automático de la web de la aerolínea le dijo a un pasajero que podía pedir la tarifa de duelo después de volar. Era falso según las propias condiciones de la compañía. Air Canada alegó, literalmente, que el chatbot era una entidad separada responsable de sus propios actos. El tribunal lo rechazó y la condenó a pagar la diferencia.
La lección jurídica cabe en una frase: lo que dice tu sistema automático lo dices tú. No hay una figura de "es que lo dijo la IA". En un despacho que emite información profesional a clientes, esto convierte la calidad del borrador en responsabilidad civil, no en una molestia de estilo.
El modelo formal: la aritmética de la revisión
Aquí está el cálculo que convierte esta discusión en una decisión de gestión. Tres números:
- V = volumen de respuestas producidas en el período. En la gestoría, 1.400 al mes.
- e = tasa de error: proporción de respuestas que contienen al menos un error relevante.
- d = tasa de detección: probabilidad de que el revisor humano encuentre ese error, sabiendo que está.
Errores que llegan al cliente = V × e × (1 − d)
Con V = 1.400 y e = 8%, hay 112 borradores con error al mes. Cuántos llegan al cliente depende enteramente de d, y ahí está el detalle que cambia la conversación:
| Tasa de detección | Errores que llegan al cliente | Cuándo se parece a esto |
|---|---|---|
| 95% | 5,6 al mes | Revisión con lista de comprobación y cifras contrastadas contra el sistema |
| 90% | 11,2 al mes | Revisión atenta de alguien que conoce al cliente |
| 60% | 44,8 al mes | Lectura de 1,5 minutos de un texto bien escrito, a las siete de la tarde, el número 90 del día |
| 30% | 78,4 al mes | El revisor ya ha visto 200 borradores correctos seguidos y ha dejado de leer de verdad |
La trampa: d no es una constante, y baja con el tiempo
Todo el mundo estima d mirando lo bien que revisa el primer día. Hay dos fuerzas que la hunden después, ambas documentadas en la literatura de factores humanos desde mucho antes de que existiera nada de esto:
El sesgo de automatización. Cuanto más fiable parece un sistema automático, menos lo vigila el operador. Y es racional a nivel individual: si 92 de cada 100 borradores están bien, leer los 100 con lupa es un uso pésimo de tu tarde. El resultado agregado es que d cae justo cuando el sistema mejora — es decir, un modelo mejor puede producir más errores que llegan al cliente, si la mejora se la come la relajación del revisor. No es una paradoja, es una multiplicación.
La fluidez desactiva la lectura crítica. Un texto bien escrito se lee más rápido y se cuestiona menos. Es el mismo motivo por el que un informe con buenas tablas convence más que uno con las mismas cifras mal maquetadas. Aquí la buena redacción es literalmente un factor de riesgo.
Consecuencia contraintuitiva y bastante importante: hay que diseñar contra la propia calidad del sistema. Si el borrador puede salir perfecto, la revisión no puede consistir en leerlo — tiene que consistir en comprobar cosas concretas contra fuentes concretas. Cambia el verbo: de "revisar" a "cotejar".
Siete controles que suben d, ordenados por lo que cuestan
| Control | Qué hace | Coste |
|---|---|---|
| 1. FALTA DATO obligatorio | Convierte la invención por hueco en una marca visible | Una frase en el prompt |
| 2. Sacar las cifras a un bloque aparte | Fechas, importes y porcentajes en una tabla al final, no enterrados en la prosa | Dos frases de formato |
| 3. Cita literal de la fuente | Obliga a que cada afirmación traiga el fragmento del documento del que sale | Tokens de salida (módulo 5) |
| 4. Lista de comprobación de cuatro puntos | El revisor comprueba cuatro cosas nombradas, no "que esté bien" | 20 segundos por correo |
| 5. Cálculos fuera del modelo | La aritmética la hace una calculadora, no el generador de texto | Desarrollo (módulo 6) |
| 6. Segunda pasada contradictoria | Otra llamada que solo busca contradicciones entre el borrador y la fuente | Duplica el coste por token, sigue siendo céntimos |
| 7. Muestreo con auditoría | Revisar en profundidad un 5% aleatorio y medir e de verdad | Horas periódicas, y es el único que te dice si los otros seis funcionan |
Fíjate en el patrón: los seis primeros son de diseño y el séptimo es de medición. Sin el séptimo, los otros seis son fe. La gestoría de Marta hace 70 correos auditados al mes —el 5%— y de ahí sale el 8% de tasa de error que usamos en todos los cálculos de este máster. Sin esa auditoría, ese 8% sería una cifra inventada, que es exactamente lo que estamos intentando evitar.
Lo que no funciona, y se intenta constantemente: pedirle al modelo que se autoevalúe ("¿estás seguro?", "puntúa tu confianza del 1 al 10"). Genera un número con aspecto de métrica que correlaciona muy débilmente con si acertó. El caso Avianca es exactamente eso. Un juez de verdad —otro modelo, con otro prompt, viendo solo la fuente y la afirmación, sin ver el razonamiento original— sí aporta algo; se ve en el módulo 7.
La matriz de decisión: dónde no se usa esto
Dos ejes bastan para decidir, y son los dos que la mayoría de las empresas no se plantean antes de comprar nada.
| Fácil de verificar | Difícil de verificar | |
|---|---|---|
| Error barato | Automatiza sin pensarlo. Clasificar facturas, resumir un correo largo, redactar un primer borrador interno. | Automatiza con muestreo. Sugerir asuntos de correo, agrupar consultas por tema. |
| Error caro | Automatiza con cotejo obligatorio. Borradores al cliente con cifras contrastadas contra el sistema. Es el caso de Marta. | No automatices. Un dictamen sobre una operación societaria, un consejo que el cliente va a ejecutar sin filtro, cualquier cosa que se presente ante un organismo firmada. |
El cuadrante de abajo a la derecha es el que produce los titulares. No es que el modelo sea peor ahí: es que ahí no hay forma barata de saber si acertó, y sin esa forma no hay proceso posible. La pregunta no es "¿lo hace bien?", es "¿cuánto me cuesta comprobar que lo ha hecho bien?". Si comprobar cuesta lo mismo que hacerlo, no has automatizado nada — has añadido un paso.
Y una asimetría que conviene tener presente: puedes mover una tarea de la columna derecha a la izquierda cambiando el formato de la salida. Un dictamen en prosa es difícil de verificar; el mismo dictamen con las cifras en una tabla, las fuentes citadas literalmente y las condiciones en una lista, es bastante más fácil. Buena parte del trabajo serio de este campo consiste en eso: no en mejorar el modelo, en rediseñar la salida para que sea comprobable.
Simulador: cuántos errores llegan al cliente
Empieza en la situación real de Bermejo & Asociados: 1.400 correos, 8% con algún error y un revisor que a 1,5 minutos por correo detecta el 60%. Son casi 45 errores al mes saliendo por la puerta. Ahora prueba dos cosas por separado: baja la tasa de error al 4% (un modelo mejor, un prompt mejor) y devuélvela al 8% para subir la detección al 90% (cotejo y lista de comprobación). Mira cuál de las dos mueve más la barra roja.
Lo que enseña la barra roja: los dos factores se multiplican, así que da igual por cuál empieces mientras muevas alguno — pero mover la detección suele ser más barato y no depende de que salga un modelo mejor. Y ojo con el último mando: ese "coste medio de un error" es la cifra más fácil de subestimar de todo el máster, porque promedia 44 erratas irrelevantes con el correo que pierde a un cliente. El ejercicio 2 va justo de eso.
✍️ Ejercicios resueltos
Ejercicio 1 — Dónde poner los 200 € del mes. Bermejo & Asociados está en V = 1.400, e = 8%, d = 60%. Marta puede hacer una de dos cosas: (a) meter cuatro ejemplos en el prompt, lo que baja e al 5% y cuesta 8,94 € al mes en tokens; o (b) rediseñar la revisión con lista de comprobación y cotejo de cifras, lo que sube d al 85% pero añade 0,4 minutos por correo. Calcula el efecto de cada una y el coste por error evitado.
Ver solución paso a paso
Paso 1 — Situación de partida. Errores que llegan = 1.400 × 0,08 × (1 − 0,60) = 1.400 × 0,08 × 0,40 = 44,8 al mes.
Paso 2 — Opción (a), bajar la tasa de error. 1.400 × 0,05 × 0,40 = 28 al mes. Evita 44,8 − 28 = 16,8 errores.
Paso 3 — Coste de (a). 8,94 € al mes en tokens. Por error evitado: 8,94 / 16,8 = 0,53 € cada uno.
Paso 4 — Opción (b), subir la detección. 1.400 × 0,08 × (1 − 0,85) = 1.400 × 0,08 × 0,15 = 16,8 al mes. Evita 44,8 − 16,8 = 28 errores.
Paso 5 — Coste de (b). 0,4 minutos × 1.400 = 560 minutos = 9,33 horas al mes. A 22 €: 205,33 € al mes. Por error evitado: 205,33 / 28 = 7,33 € cada uno.
Paso 6 — Comparación. La opción (b) evita más errores en términos absolutos (28 frente a 16,8), pero cada error evitado le sale catorce veces más caro. Y no son excluyentes: haciendo las dos, 1.400 × 0,05 × 0,15 = 10,5 errores al mes, una cuarta parte de la situación inicial, por 214 € mensuales.
La lección de gestión: el orden correcto es primero lo barato, y después lo caro hasta donde compense. Empieza siempre por los controles que cuestan frases en un prompt, porque su coste marginal es casi nulo; el tiempo humano de revisión es el recurso caro y hay que gastarlo en lo que ningún prompt puede arreglar. El error clásico de las empresas es justo el inverso: montan un comité de revisión antes de haber escrito una sola restricción en la instrucción.
Ejercicio 2 — El número que se subestima siempre. De los 44,8 errores que llegan al cliente cada mes, la experiencia del despacho dice que 1 de cada 20 provoca una queja formal que consume 3 horas de despacho, y 1 de cada 200 acaba en un recargo de la Agencia Tributaria que el despacho asume por unos 250 €. Calcula el coste esperado mensual y decide si la opción (b) del ejercicio anterior —205 € al mes— se justifica.
Ver solución paso a paso
Paso 1 — Coste de una queja formal. 3 horas × 22 € = 66 €.
Paso 2 — Coste esperado por error que llega. (1/20) × 66 + (1/200) × 250 = 0,05 × 66 + 0,005 × 250 = 3,30 + 1,25 = 4,55 €.
Paso 3 — Coste esperado del mes. 44,8 × 4,55 = 203,84 €.
Paso 4 — Lo que ahorra la opción (b). Baja los errores de 44,8 a 16,8, o sea 28 errores × 4,55 = 127,40 € de coste esperado evitado… contra 205,33 € de coste. Sale negativo por 78 € al mes. Con esta cuenta, la respuesta es no hacerla.
Paso 5 — Por qué esa respuesta es mala. Porque el paso 2 ha promediado dos cosas incomparables. Entre esos errores hay erratas que nadie nota y hay uno que puede hacer que un cliente que factura al despacho 1.800 € al año se marche, o que aparezca en una reclamación de responsabilidad profesional. La distribución tiene una cola larga: la media de 4,55 € describe fatal un fenómeno donde casi todos los casos valen cero y uno vale miles.
Paso 6 — El cálculo honesto. Añade un solo supuesto más: que 1 de cada 500 errores que llegan cueste la pérdida de un cliente, con un valor de 1.800 € anuales y una vida media de 6 años, es decir 10.800 €. Ese término solo aporta (1/500) × 10.800 = 21,60 € por error, casi cinco veces todo lo anterior junto. Coste esperado por error: 4,55 + 21,60 = 26,15 €. Los 28 errores evitados valen ahora 732 € contra 205 € de coste. La decisión se voltea entera.
La lección de gestión: el valor esperado calculado sobre incidentes frecuentes y baratos siempre infravalora los controles, porque los controles se pagan por lo que evitan y lo que de verdad hay que evitar pasa poquísimas veces. Cuando alguien te enseñe un cálculo que dice que la revisión no compensa, busca el término de la cola: casi nunca está. Es exactamente el mismo error de razonamiento que hace que las empresas no contraten un seguro hasta después del incendio.
Quiz — Alucinaciones, límites y verificación
12 preguntas — se supera con 70% o más.
Se cruza con
Este módulo se entiende mejor —o se vuelve otra cosa— junto a este otro. Cruzar dos disciplinas abre cosas que ninguna de las dos abre por su cuenta.
- Comportamiento del Consumidor · Máster de MarketingLos atajos mentales que explican por qué un texto bien escrito se cuestiona menos que uno mal maquetado.