Mycelium: investigadores descomponen los benchmarks de alucinaciones en tres ejes

Lo habitual es comparar los detectores de alucinaciones de LLM con una sola cifra en un solo benchmark. En el metaestudio Mycelium (arXiv 2610.33608, publicado el 24 de octubre de 2026), Julia Belikova y Elisei Rykov muestran por qué esa cifra dice menos de lo que parece. Los benchmarks definen la alucinación de maneras distintas, obtienen los textos de los modelos por vías diferentes y etiquetan los errores en niveles diferentes. Los autores proponen tratar la detección como un problema de medición que depende de las condiciones del benchmark, e introducen una nueva métrica, Span Coverage F1.

Un solo término, muchas tareas distintas

Las alucinaciones son clave para evaluar e implantar grandes modelos de lenguaje: de la fiabilidad con que se detectan dependen los sistemas RAG, los asistentes y los pipelines corporativos. Los nuevos detectores suelen presentarse con una tabla de resultados en varios conjuntos de datos. Pero si en un conjunto se etiquetan errores factuales sin contexto y en otro se comprueba la fidelidad de la respuesta a la fuente proporcionada, se trata de dos tareas distintas con un mismo nombre. Una puntuación alta en la primera apenas garantiza nada en la segunda.

Mycelium analiza cómo las decisiones tomadas al crear el benchmark, etiquetar los datos y evaluar configuran la tarea de predicción final. Después, los autores contrastan los mecanismos y supuestos de los propios detectores con las condiciones en las que se midieron.

Tres ejes para clasificar los benchmarks

Los autores ordenan todos los benchmarks existentes en tres dimensiones:

• Provenance (origen): cómo se obtienen las salidas del modelo y cuáles son las condiciones de evidencia, es decir, de dónde proceden los textos y en qué pruebas se apoya la verificación.
• Typology (tipología): qué fallos de factualidad (factuality) y de fidelidad a la fuente (faithfulness) reflejan las etiquetas del benchmark.
• Granularity (granularidad): a qué nivel se etiquetan, se predicen y se evalúan las alucinaciones. Puede ser la respuesta completa, una oración o un fragmento concreto de texto.

Los distintos puntos de estos ejes cambian el planteamiento mismo de la tarea. Por eso, según concluyen los autores, las comparaciones entre benchmarks tienen limitaciones, y la generalización de un detector a otras condiciones debe evaluarse de forma explícita, no darse por supuesta.

Span

Coverage F1: cuando los límites del etiquetado lo deciden todo

Una sección aparte se dedica a la evaluación a nivel de spans, es decir, de fragmentos de texto marcados como alucinación. Aquí el resultado depende en gran medida de dónde trazó los límites el anotador. Un benchmark marca un sintagma nominal corto; otro, la oración entera. Un detector que haya encontrado el mismo error obtendrá puntuaciones distintas según cómo coincidan los límites.

Como complemento a las métricas existentes, los autores proponen Span Coverage F1. Se basa en la inclusión (containment): tiene en cuenta si el fragmento predicho cubre al etiquetado, y no solo el grado de solapamiento exacto. La métrica está pensada como complementaria: no sustituye a los indicadores habituales, sino que ayuda a separar la calidad real de detección de los artefactos del etiquetado.

Cómo leer las puntuaciones de los detectores

Conclusión práctica para los equipos que eligen o entrenan detectores:

• Antes de comparar dos puntuaciones, comprueba si los benchmarks coinciden en origen de los datos, tipos de error y nivel de etiquetado. Si no coinciden, las cifras miden cosas distintas.
• Para producción, elige el benchmark más cercano a tu caso de uso. Para RAG importa la fidelidad a la fuente; para preguntas abiertas, la factualidad sin contexto.
• Si el detector trabaja a nivel de spans, revisa cómo se definen los límites en el etiquetado y añade una métrica basada en inclusión, como Span Coverage F1.
• Comprueba la generalización: ejecuta el detector en benchmarks con otras condiciones e informa de la dispersión, no de una única cifra.

El código y los materiales del estudio están en el repositorio lmeribal/mycelium de GitHub. Los autores piden comentarios y debate: el trabajo está concebido como base para comparaciones más honestas en un campo donde el número de la tabla suele pesar más que el contexto en el que se obtuvo.