Cómo evaluar alucinaciones de LLM: checklist práctica

La palabra alucinación agrupa defectos distintos, por lo que una única hallucination rate no es un contrato fiable. Closed-book factuality pregunta si una afirmación es correcta frente a un hecho externo verificado. Groundedness comprueba si la fuente proporcionada respalda la afirmación. Instruction faithfulness detecta desviaciones del input y self-consistency detecta contradicciones dentro de una misma respuesta. Una respuesta puede estar grounded en un documento erróneo o ser factual por memoria del modelo aunque el contexto suministrado no la respalde.

Empieza con un decision contract: escenario, tipos de claims, fuentes permitidas, fecha de corte del conocimiento, coste del error, abstention correcta y acción tras un resultado incierto. NIST usa el término más preciso confabulation para contenido falso presentado con seguridad y subraya que el riesgo es especialmente relevante en respuestas largas y complejas por dominio. El eval debe nombrar el failure mode concreto en vez de atribuir intención humana al modelo.

• Factuality → el claim coincide con un hecho externo autorizado en una fecha fijada.
• Groundedness → un evidence span específico respalda todo el alcance del claim.
• Consistency → la respuesta no se contradice a sí misma, al historial ni al input estructurado.
• Calibration → la confidence o la decisión de responder coincide con la frecuencia real de errores.

Para tareas fact-seeking breves, utiliza preguntas con una respuesta inequívoca y estable junto con un evidence record que incluya URL o document ID, span exacto, revision, verifiedAt y reviewer. SimpleQA muestra un diseño estrecho útil: respuesta corta y verdicts separados para correct, incorrect y not attempted. Pero este benchmark no demuestra calidad en respuestas long-form, RAG ni en tu dominio; un conjunto público es una baseline, no un certificado de release.

Añade slices propios: hecho conocido, hecho raro, pregunta ambigua, false premise, información posterior al cutoff, documento obsoleto, conflicto de fuentes, no-answer y preguntas con varias formas válidas. En workflows grounded incluye context supportive, irrelevant, partially supportive y contradictory. No generes todas las preguntas desde los mismos chunks sin revisión: los datasets sintéticos suelen repetir el lenguaje de la fuente y hacen retrieval y grading artificialmente fáciles.

Un único verdict para un párrafo oculta respuestas parcialmente correctas. El claim extractor debe identificar afirmaciones verificables externamente, números, fechas, entidades, relaciones causales y attribution, conservando scope y qualifiers. Para cada claim, el grader devuelve supported, contradicted, unverifiable o not-in-context junto con evidence IDs. La existencia de una citation no es prueba: el span debe implicar la afirmación concreta y no limitarse a ser temáticamente cercano.

Mide por separado claim coverage, factual precision, unsupported critical claims y contradiction rate. El completeness extractor también necesita calibración: si omite una fecha inventada, el downstream score quedará falsamente alto. Etiqueta manualmente un slice representativo, mide el agreement entre reviewers y analiza la disagreement taxonomy. Un model grader escala bien, pero su prompt, versión, orden de evidencias y retry policy forman parte del eval versionado, no de infraestructura invisible.

El eval debe ofrecer una salida segura: pedir aclaración, indicar que faltan pruebas o escalar a una persona. Cuenta correct, incorrect y abstained como outcomes separados y construye una curva risk-coverage que muestre cómo cambia el error cuando el sistema atiende una mayor proporción de consultas. Una accuracy alta tras rechazar casi todo no es útil sin coverage, y un answer rate alto puede ocultar conjeturas peligrosas.

No dependas solo de la confidence declarada por el modelo. Calíbrala en held-out cases con reliability bins o Brier score y compárala con señales simples: suficiencia de evidence, disagreement entre varias samples y verifier verdict. Semantic entropy estudia variación a nivel de significado y puede detectar confabulations, pero sus autores la distinguen de errores sistemáticos y consistentes. Un uncertainty detector complementa la verificación factual, no la sustituye.

Compara candidate y baseline sobre los mismos frozen cases, separados por idioma, dominio, longitud, freshness, fuente, disponibilidad de retrieval y daño del error. El score agregado puede subir gracias a trivia sencilla mientras empeoran fechas financieras o qualifiers médicos. Para slices high-risk define critical invariants: ninguna entidad, cifra o citation inventada debe llegar al resultado final sin verificación o human review.

Prueba algo más que el modelo. Fija versiones de corpus, retriever, search API, prompt, citation resolver, claim extractor, verifier y renderer. Inyecta empty retrieval, stale cache, broken source, partial document, revisions contradictorias y verifier timeout. Si no hay evidence, la UI no debe transformar un claim unverifiable en una respuesta segura. Conserva un redacted trace desde el input hasta el output renderizado para distinguir retrieval miss, generation defect, grader error y presentation bug.

• Dataset health → label agreement, source freshness, leakage y slice coverage.
• Answer quality → correct, incorrect, abstained y critical failures ponderados por riesgo.
• Evidence quality → claim coverage, citation entailment y unsupported-claim rate.
• Operations → latencia, grader disagreement y coste por respuesta verificada.

El decision record fija dataset revision, fuentes, modelo, prompt, versiones del pipeline, primary metric, segment thresholds, critical failures, owner y known-good rollback bundle. Promote exige paired non-regression con importancia práctica, superar los critical slices y un coste aceptable por respuesta verificada. No declares un threshold seguro universal ni una victoria del modelo por un vendor benchmark: tus fuentes, idiomas, traffic mix y consecuencias del error son distintos.

El rollout empieza con offline replay, pasa a shadow evaluation, un canary pequeño y después a producción limitada por riesgo. Una user correction confirmada puede convertirse en regression fixture tras privacy review; un clic implícito o la ausencia de queja no demuestran factuality. Si un critical unsupported claim llega al usuario, reduce coverage, desactiva el modelo o la retrieval revision afectada, restaura el known-good bundle y revisa respuestas ya emitidas cuando el dominio lo exija. Production monitoring debe usar la misma taxonomy que el eval offline.