2026-05-10 · Actualizado 2026-07-22

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Evaluación de RAG: Métricas para cada etapa de un sistema RAG en producción

Parte 1 de la serie de producción RAG

Un sistema RAG con filtros dañados puede seguir funcionando durante meses sin generar una alerta operativa. Aún así, proporciona respuestas y cumple con su objetivo de latencia, pero dichas respuestas se basan en evidencias incompletas. El análisis de recall@k frente al conjunto de referencia original revela esta deficiencia, algo que los paneles de control de latencia y disponibilidad no logran detectar.

La evaluación solo puede detectar una falla cuando cada etapa pipeline dispone de su propia métrica específica. En este artículo se establece una correspondencia entre los modos de fallo más habituales y dichas métricas, abarcando todo el proceso desde el análisis de documentos hasta la monitorización en producción.

[!NOTE] ¿Quieres saltarte los pasos y ejecutar el código directamente?

El código ejecutable slavadubrov/rag-evals-demo El repositorio aplica las métricas a SciFact. make eval ejecuta el conjunto de pruebas, y make benchmark Compara los métodos de chunking, embedding, y las configuraciones de LLM. Los cuadernos de trabajo del 00 al 09 presentan de forma independiente cada una de estas métricas. La demostración utiliza Qdrant integrado, por lo que no requiere Docker.

TL;DR

• La evaluación define al sistema. Una etapa sin métricas es una etapa que falla de forma silenciosa.
• Una pila de evaluación útil abarca la ingestión, la recuperación, el anclaje en la generación, la conformidad con la ontología y las señales del sistema. RAGAS, TruLens, DeepEval, Arize Phoenix, y el TREC 2024 RAG Categoría Se te proporcionan las herramientas necesarias. Ellos no eligen las métricas por ti.
• En el caso de los sistemas basados en metadatos y ontologías RAG, un etiquetado incorrecto o un predicado rígido y frágil puede reducir la tasa de recuperación a cero. La métrica estándar Recall@k permite detectar esta pérdida al conservar el conjunto de referencia original. Una métrica de filtrado por falsa exclusión identifica la causa del problema, mientras que la fiabilidad puede seguir pareciendo adecuada, ya que el modelo indica fielmente “No lo sé”.

Las secciones siguen el orden establecido por pipeline. Se debe comenzar con la tabla de decisiones y, a continuación, utilizar las secciones posteriores como referencia para cada etapa.

Tabla de decisión para la evaluación de RAG

Utilice esta tabla como punto de partida antes de seleccionar un framework. La métrica adecuada depende del modo de fallo que se pretende detectar, y no del nombre de la herramienta.

Para una comparación más breve de las herramientas, consulte Mejores herramientas y métricas de evaluación para RAG en 2026.

Parte 1: Definir el éxito antes de la arquitectura

Elabore el conjunto de evaluación antes del diagrama de arquitectura. Esto permite establecer un objetivo medible para cada elección de componente que se realice posteriormente.

No se puede elegir entre BM25 y recuperación densa, fragmentación recursiva y semántica, ni entre Cohere Rerank y BGE hasta saber qué es lo que se está optimizando. “Mejores respuestas” no es una métrica válida. Un contrato ilustrativo sería “fidelidad ≥ 0.85 en un conjunto de referencia de 200 consultas que abarque nuestras tres intenciones principales, con una latencia p95 < 1.5 s y una tasa de exclusión falsa por filtrado < 2 %”. Estos valores son solo marcadores; lo importante es que la calidad, la cobertura, la latencia y el filtrado cuenten con umbrales explícitos.

Defina el harness antes de escribir el código de recuperación. El primer harness resultará incorrecto, por lo que tendrá que modificarlo. Revisar una métrica es mucho más económico que corregir un sistema que ya se ha desplegado.

Tres capas pipeline y dos modos de ejecución

El RAG moderno es un pipeline, por lo que la evaluación debe realizarse de forma pipeline. Ningún valor numérico único puede capturar todos los modos de fallo.

La evaluación en producción cuenta con tres capas pipeline. La evaluación de ingestión verifica si el corpus y el índice conservan la información original. La evaluación en tiempo de consulta comprueba si la reescritura, el filtrado, la recuperación, reranking y la compilación del contexto permitieron encontrar las pruebas adecuadas. Finalmente, la evaluación de respuesta y producción analiza si la respuesta hace uso de dichas pruebas y si mantiene una calidad aceptable bajo tráfico real. Al combinar estas capas en una única puntuación, los errores de normalización pueden quedar ocultos dentro de un valor de respuesta considerado aceptable.

Esas capas describen el punto exacto en el que se produce una falla. Los modos offline y online indican cuándo y con qué datos se ejecuta la verificación. La evaluación offline utiliza un conjunto de datos fijo dataset acompañado de valores de referencia conocidos; es reproducible y resulta útil para la selección de componentes, las comparaciones A/B y los controles de integración continua. Por su parte, la evaluación online analiza tráfico en tiempo real y permite registrar procesos de regeneración, tiempos de permanencia, retroalimentación explícita y cambios reales en las consultas. Este método genera más ruido y resulta más difícil de instrumentar.

Cada capa pipeline puede aportar comprobaciones tanto en modo offline como en línea. Un corpus de ingestión fijo permite detectar regresiones en el analizador antes del lanzamiento, mientras que los monitores de frescura y de fallos de análisis se encargan de supervisar las actualizaciones en tiempo real. Un conjunto de consultas fijo sirve para evaluar el rendimiento de la recuperación de información antes del lanzamiento, mientras que los registros en tiempo real extraídos de forma aleatoria revelan posibles desviaciones en el entorno de producción. Las comprobaciones exclusivamente en modo offline no detectan cambios en tiempo real; por su parte, las comprobaciones exclusivamente en línea dificultan la reproducción de las regresiones.

A nivel de componente vs. de extremo a extremo

Existen dos errores comunes. Una evaluación exclusiva de tipo end-to-end solo indica que el sistema está defectuoso, pero no dónde exactamente. Por su parte, una evaluación centrada únicamente en los componentes puede mostrar que cada parte funciona correctamente, aun cuando el sistema completo siga fallando. La solución consiste en utilizar unas pocas métricas clave de tipo end-to-end para tomar decisiones de aceptación o rechazo, además de métricas específicas de cada componente con el fin de realizar un diagnóstico preciso. Las métricas de recuperación permiten detectar regresiones en el módulo encargado de buscar información. Las métricas de generación, a su vez, sirven para identificar regresiones en el módulo generador. Finalmente, la corrección de las respuestas en el nivel end-to-end permite detectar fallos en la integración del sistema.

La referencia frameworks (recorrido basado en opiniones)

Mi stack por defecto incluye RAGAS para el vocabulario de métricas, DeepEval para las puertas de control en CI, Phoenix para el rastreo en producción, además de código personalizado para métricas específicas de la ontología. Con el tiempo, cualquier solución con la que comiences resultará insuficiente. Elige el framework que facilite la implementación de métricas personalizadas.

Para benchmarks, utilice BEIR (Thakur et al., NeurIPS 2021) para la generalización en recuperación de información sin entrenamiento previo. MTEB para una calidad general de embedding. MIRACL para la recuperación multilingüe, y el TREC 2024 RAG Carrera para la evaluación de extremo a extremo de RAG.

Parte 2: Asignar los puntos de evaluación a pipeline

Un sistema RAG en entorno de producción es mucho más complejo que una simple operación de “incorporar documentos, recuperar fragmentos y llamar a un LLM”. Cualquiera de las etapas que se encuentran entre la adquisición del documento y la entrega de la respuesta puede fallar.

Cada etapa del diagrama cuenta con al menos una métrica. Una etapa que carezca de métricas puede fallar sin que nadie se dé cuenta.

La vía de las tres etapas se corresponde con los puntos en los que puede producirse la pérdida de evidencias. La vía de ingestión abarca el análisis sintáctico, la limpieza de datos, el particionamiento en bloques, embedding, e indexación. La vía de tiempo de consulta incluye la reescritura de consultas, el filtrado, la recuperación de información, reranking, y la compilación del contexto relevante. Finalmente, la vía de respuesta y producción se ocupa de garantizar la fidelidad de los resultados, verificar las fuentes citadas, analizar las señales provenientes de los usuarios, detectar desviaciones, controlar la latencia y gestionar los costes asociados.

Los errores se acumulan a lo largo de la cadena de procesamiento. Una解析 incorrecta limita la posibilidad de dividir los datos en chunks. Una mala división en chunks limita la capacidad de recuperación de información. Una recuperación deficiente limita a reranking. Un reranking inadecuado, a su vez, limita la generación del resultado. La fidelidad solo permite evaluar la respuesta final, y nunca las causas que se producen en etapas anteriores del proceso.

Parte 3: Evaluación de la ingesta

Muchas fallas en entornos de producción relacionadas con RAG tienen su origen en la fase de ingestión de datos. El sistema funciona correctamente con documentos de prueba limpios, pero falla al tratar con PDF reales, escaneos, tablas y páginas de corpus con formato desordenado.

Adquisición y análisis del documento

Qué medir:

• Completitud de la extracción de texto: extracted_chars / expected_chars en una muestra etiquetada, se calcula por clase de documento. No existe un paquete canónico; es necesario escribir un pequeño harness que compare la salida del analizador con una referencia elaborada manualmente. Hay que prestar atención a la ausencia de notas al pie, encabezados o leyendas.

• Precisión OCR: tasa de error de caracteres (CER) y tasa de error de palabras (WER), las métricas estándar para el procesamiento del lenguaje hablado/OCR:

  $$\text{CER} = \frac{S + D + I}{N}, \qquad \text{WER} = \frac{S_w + D_w + I_w}{N_w}$$

  donde $S$, $D$, $I$ representan sustituciones, eliminaciones e inserciones a nivel de carácter, y $N$ es el recuento de caracteres de referencia (con subíndice $w$ para la versión por palabra). No se debe aplicar un único límite CER a todo el corpus. Es necesario calibrarlo según la clase del documento y la pérdida en las respuestas generadas; el texto impreso, la escritura a mano y los materiales multilingües presentan perfiles de error diferentes. Realizar los cálculos con jiwer (jiwer.cer(refs, hyps), jiwer.wer(refs, hyps)) o HuggingFace evaluate. Para los corpus de evaluación, FUNSD y SROIE Son públicos benchmarks.

  from jiwer import cer, wer
  
  refs = ["Mars has two moons, Phobos and Deimos."]
  hyps = ["Mars has two m00ns, Phobos and Deirnos."]
  
  print(f"CER = {cer(refs, hyps):.3f}")  # CER = 0.105
  print(f"WER = {wer(refs, hyps):.3f}")  # WER = 0.286

• Fidelidad en la extracción de tablas: TEDS (Similaridad basada en distancia de edición de árboles) mide cuán cercano está el árbol de tabla HTML predicho al de referencia, normalizado en función del tamaño del árbol más grande. Desde Zhong et al., 2020 (PubTabNet):

  $$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

  TEDS utiliza tanto la estructura (filas, columnas y extensiones) como el contenido de las celdas; TEDS-S elimina el contenido y solo evalúa la estructura. Implementación de referencia: PubTabNet’s teds.py (utiliza) apted (dentro del motor). Para corpus de evaluación, consulte PubTabNet. FinTabNet, y SciTSR. Los analizadores ingenuos suelen fallar al procesar tablas; benchmark antes de confiar en ellos.

• Preservación del layout/estructura: orden de los encabezados, integridad de las listas y secuencia de lectura en PDFs multicolón. Utilizar DocLayNet para un benchmark etiquetado. Una comparación lista para usar puede abarcar un analizador de elementos como unstructured, una biblioteca PDF como pymupdf, y un analizador VLM como docling.

Compare diferentes familias de analizadores de texto, como por ejemplo la versión de referencia de Tesseract, un modelo basado en VLM y OCR, así como la opción propuesta por su proveedor. Utilice una muestra estratificada de clases reales de documentos a una resolución DPI fija, que incluya escaneos nítidos, fotografías, tablas, texto multilingüe, fórmulas matemáticas y texto manuscrito. Indique el CER o el WER para cada clase, además del TEDS para las páginas que contienen tablas.

Limpieza y normalización

• Precisión en la eliminación de texto genérico: precisión/recuerdo respecto a los segmentos de texto genérico etiquetados por humanos. Una eliminación excesivamente agresiva destruye contenido relevante; una eliminación demasiado laxa contamina embeddings. Herramientas para comparar: trafilatura, jusText, Resiliparse. Barbaresi (2021) benchmarks estas comparaciones cara a cara.

• Normalización Unicode: porcentaje de documentos que generan resultados idénticos con NFC y NFKC (calculado mediante la librería estándar) unicodedata.normalize)

• Precisión de detección de idioma: F1 en una muestra multilingüe etiquetada. Es fundamental para los índices multilingües. Utilizar fasttext-langdetect (Facebook’s lid.176), lingua-py, o cld3. FLORES-200 Proporciona texto de evaluación en 200 idiomas distintos, pero la combinación de idiomas de producción que utilice debe determinar el subconjunto de pruebas a aplicar.

• Efectividad de la deduplicación (MinHash / LSH): precisión/recuerdo de su detector de casi duplicados frente a un conjunto etiquetado manualmente. La idea subyacente: estimar la similitud de Jaccard J(A, B) = \frac|A ∩ B|}{|A ∪ B|${ }$ entre conjuntos de fichas de documento mediante $k$ hashes de permutación aleatoria (Broder, 1997) Y agrupar los casi duplicados mediante bandas LSH.Indyk y Motwani, 1998). Realice un análisis del recuento de hashes y del umbral de Jaccard en su corpus. Registre por separado la tasa de fusiones falsas (que dañan las respuestas) y la tasa de fusiones no realizadas (que generan desperdicio de espacio en el índice). datasketch Ofrece la implementación que se utiliza a continuación; sus parámetros son meramente ilustrativos:

  from datasketch import MinHash, MinHashLSH
  
  def shingles(text: str, k: int = 5) -> set[str]:
      text = text.lower()
      return {text[i:i + k] for i in range(len(text) - k + 1)}
  
  def to_minhash(text: str, num_perm: int = 128) -> MinHash:
      m = MinHash(num_perm=num_perm)
      for s in shingles(text):
          m.update(s.encode("utf-8"))
      return m
  
  docs = {
      "d1": "Mars has two moons, Phobos and Deimos.",
      "d2": "Mars has two moons, Phobos and Deimos!",   # near-dup
      "d3": "Curiosity rover landed on Mars in 2012.",
  }
  
  lsh = MinHashLSH(threshold=0.8, num_perm=128)
  for did, text in docs.items():
      lsh.insert(did, to_minhash(text))
  
  print(sorted(lsh.query(to_minhash(docs["d1"]))))  # ['d1', 'd2']

• Limpieza de PII: precisión y recuerdo, calculados por separado para cada tipo de entidad (correos electrónicos, números de seguro social, nombres, direcciones). Los errores de recuerdo generan riesgos de cumplimiento; los errores de precisión afectan la calidad de las respuestas. Se debe establecer el punto de operación en colaboración con el equipo legal. Entre las herramientas candidatas se encuentran Microsoft Presidio, scrubadub, o un modelo NER afinado sobre un conjunto etiquetado.

El chunking controla la calidad de la recuperación

El particionamiento en chunks puede generar una brecha en la recuperación de múltiples puntos, incluso cuando el modelo embedding permanece estable. En El proveedor de NVIDIA para 2024 benchmark,

El agrupamiento semántico organiza las oraciones adyacentes en función de la similitud embedding y realiza cortes en los límites donde dicha similitud es baja. LangChain’s SemanticChunker y los de LlamaIndex SemanticSplitterNodeParser

La división recursiva de caracteres prueba primero los saltos de párrafo, luego los saltos de oración y, finalmente, los saltos de palabra, hasta que cada fragmento cumpla con el tamaño objetivo. LangChain’s RecursiveCharacterTextSplitter Implementa la secuencia seleccionando los valores de ventana y solapamiento adecuados para la estructura de tu documento, y deja que el conjunto dorado determine los valores finales.

Métricas a seguir:

• Coherencia de los chunk: $\text{coherencia} = \overline{\cos(s_i, s_j)}_{\text{dentro}} - \overline{\cos(s_i, s_j)}_{\text{fuera del límite}}$, donde $s_i$ son las oraciones embeddings. Los chunk saludables presentan similitud interna y disimilitud en los bordes. Se calcula mediante sentence-transformers además scikit-learn’s cosine_similarity.
• Calidad de los límites: etiquetado manual con la pregunta “¿Es este un corte razonable?” para cada muestra, además de una comprobación estructural que asegure que los fragmentos no dividan tablas, listas o secciones numeradas.
• Tamaño óptimo de los fragmentos: pruebe tamaños de tokens diferentes (128, 256, 512, 1024) y trace el gráfico de Recall@k en función del tamaño en su conjunto de referencia. Elija el punto de inflexión; no siga ciegamente lo que indique la guía.
• Efectividad de la superposición: pruebe varios porcentajes de superposición y mida el valor de Recall@k. Deje de aumentarla cuando la curva de recall local se estanque o cuando el costo por duplicaciones supere los beneficios obtenidos.
• Fidelidad en la atribución de fragmentos: porcentaje de fragmentos que conservan un puntero a la fuente verificable (número de página, ancla de sección, ID del documento). La auditabilidad exige este requisito.
• Fragmentación tardía vs. temprana: Procesamiento por bloques tardío (Günther et al., 2024) incrusta todo el documento para posteriormente segmentarlo, preservando así el contexto global (implementación de referencia en jina-embeddings-v3). Recuperación contextual (Anthropic, 2024) añade al principio de cada bloque de texto un contexto generado por LLM. Ambas acciones incrementan el costo computacional. Es necesario realizar un Benchmark en su corpus antes de adoptar cualquiera de estas soluciones.

Mi opinión: el particionamiento estructural (división basada en encabezados, tablas y secciones, implementado por analizadores como unstructured.io

Extracción y enriquecimiento de metadatos

• NER precisión/recall/F1: por tipo de entidad, en un subconjunto etiquetado. Al estilo estándar CoNLL/MUC. Se calcula mediante seqeval (from seqeval.metrics import f1_score) para la versión sensible a las etiquetas BIO/IOB, o scikit-learn para comparaciones de conjuntos de intervalos. CoNLL-2003 y OntoNotes 5.0 son los corpus de referencia canónicos.
• F1 de extracción de relaciones: aún más importante en los sistemas basados en ontologías. Etiquete manualmente un conjunto estratificado por tipo de relación y clase de documento. TACRED y DocRED son recursos públicos benchmarks; entre las implementaciones candidatas se encuentran opennre y spaCy relación pipelines.
• Precisión de extracción de título/título principal: coincidencia exacta más similitud normalizada de Levenshtein ($1 - \frac{\text{edit\_dist}(a, b)}{\max(|a|, |b|)}$) en comparación con los valores de verdad real — python-Levenshtein o rapidfuzz Se pueden proporcionar ambos en una sola llamada.
• Preservación de metadatos jerárquicos: porcentaje de fragmentos que mantienen correctamente su sección padre, documento padre y ruta de ascendencia. Esta métrica determina si su RAG es capaz de responder a preguntas del tipo “¿qué dice el hijo de la política X?”.

Embedding generación

• Selección de modelo benchmarks: MTEB para capacidades generales (el indicador principal es el nDCG@10); el Paquete Python MTEB (le permite reproducir la tabla de clasificación localmente), BEIR para generalización sin entrenamiento previo. MIRACL En el ámbito multilingüe, los modelos de recuperación más avanzados se agrupan en un rango estrecho de nDCG@10, pero las puntuaciones de MTEB en inglés predicen de forma deficiente el rendimiento en lenguas con menos recursos.
• Evaluación específica del dominio: no se debe considerar un ranking general de benchmark como resultado válido para dicho dominio. Es necesario definir un conjunto de referencia del dominio a partir de su matriz de cobertura y de la incertidumbre que la decisión pueda tolerar. A continuación, se debe volver a clasificar a los modelos candidatos en función de este conjunto. ranx o pytrec_eval. Un conjunto de dominios puede invertir el orden de la tabla de clasificación; por lo tanto, se debe publicar el segmento dataset, el protocolo de recuperación y el intervalo de confianza junto con el resultado.
• Embedding detección de deriva: seguimiento de la deriva distribucional basada en el KL o en el modelo entre una ventana de referencia fija y un conjunto embeddings en producción dinámico; además, se mide la estabilidad por vecinos más cercanos para un conjunto de pruebas fijo. evidently y alibi-detect Implementar detectores basados en modelos y estadísticos. Los de Evidently. estudio comparativo Se trata de una evaluación de proveedores; compare los métodos en función de los cambios conocidos en sus propios embeddings.
• Multi-vector vs. single-vector: la interacción tardía permite conservar las representaciones a nivel de token en lugar de reducir cada documento a un único vector; ColBERT Se trata del diseño canónico, que incluye implementaciones de referencia en RAGatouille y PyLate. Dicha representación más rica incrementa el costo de indexación y recuperación. Antes de adoptarla, compare la calidad, el almacenamiento y la latencia con una línea base de vectores únicos en el mismo conjunto de dominios.

Construcción del índice

• Recall@k bajo aproximación: se compara el índice de vecino más cercano aproximado (ANN) con una línea de base de fuerza bruta exacta para el mismo valor de k — en FAISS, Eso es. IndexHNSWFlat (ó) IndexIVFFlat) vs. IndexFlatIP/IndexFlatL2. Establezca la pérdida de recuerdo aceptable según su presupuesto de calidad posterior. El ann-benchmarks El proyecto monitoriza las curvas de recall y QPS Pareto en las distintas bibliotecas.
• Ajuste de HNSW: HNSW (Mundo Pequeño Navegable Jerárquico: un grafo de proximidad por capas; véase Malkov y Yashunin, 2018, implementado en hnswlib, FAISS’s IndexHNSWFlatY la mayoría de las bases de datos vectoriales exponen tres parámetros de ajuste: M (grado de expansión del grafo) efConstruction (ancho candidato en tiempo de compilación) efSearch (ancho del candidato en tiempo de consulta). Comience con los valores predeterminados documentados por la biblioteca y, a continuación, varíe los parámetros hasta que la curva de recuerdo-latencia cumpla con los requisitos del conjunto de evaluación.
• Ajuste de IVF: IVF (Índice de archivo invertido: particionar vectores mediante k-means en nlist células; posteriormente, en el momento de la consulta, se escanean las nprobe células más cercanas; consulte la documentación de FAISS. IndexIVFFlat y IndexIVFPQ). Barrido nlist y nprobe En contraste con el recuerdo y la latencia de las búsquedas exactas, Benchmark se procesan las consultas filtradas por separado, ya que las familias de índices y las bases de datos vectoriales implementan la travesía de filtros de manera distinta.
• Retraso en la actualización de la frescura: tiempo transcurrido desde el registro del documento hasta que este se vuelve recuperable. Se debe hacer un seguimiento de los valores p50 y p99. En los sistemas sujetos a requisitos regulatorios, también es necesario registrar el porcentaje de consultas atendidas mediante índices obsoletos.

Parte 4: Evaluación en tiempo de consulta

La vía de tiempo de consulta contiene las métricas que permiten diagnosticar la ruta de recuperación. El Recall@k por sí solo no puede indicar si el fallo fue causado por la reescritura, el filtrado, reranking, o por la compilación del contexto.

Comprensión y reescritura de consultas

• Calidad de expansión de consultas: mejora en Recall@k en el conjunto de referencia, entre la consulta expandida y la original. Defina previamente el gancho útil mínimo y su incertidumbre antes de realizar las pruebas. Si la expansión no supera dicho umbral local, no justifica su latencia ni su costo. Los puntos de referencia clásicos basados en PRF (pseudo-relevance feedback) como RM3 y Bo1 Siguen siendo comprobaciones de validez útiles; la expansión basada en LLM debe superar su rendimiento.
• Evaluación HyDE: HyDE (Gao et al., 2022) genera una respuesta hipotética mediante LLM, la incrusta en el resultado y realiza búsquedas basadas en ella. Este proceso incrementa la latencia de generación y introduce una nueva superficie de fallos. Es necesario medir el Recall@10 por separado en los conjuntos de datos del dominio, fuera del dominio y aquellos con baja confianza, para decidir posteriormente si dicha respuesta debe seguir el camino predeterminado, utilizarse como solución alternativa o no incluirse en ninguno de ellos.
• Generación de múltiples consultas: Unión de Recall@k de N reescrituras frente a una única consulta. Se recorre el valor de N para seleccionar un punto en la frontera entre recall y latencia. Implementaciones: LangChain’s MultiQueryRetriever, de LlamaIndex QueryFusionRetriever.
• Precisión de clasificación de intenciones: precisión/recuerdo/F1 estándar por intención (calcular con sklearn.metrics.classification_report), pero la métrica relevante es la corrección de enrutamiento: ¿se invoca el pipeline descendente adecuado?
• Enrutamiento adaptativo: Adaptativo-RAG (Jeong et al., NAACL 2024) sostiene que no toda consulta merece aplicar la misma estrategia de recuperación. Se puede tratar la precisión del enrutador como un problema de clasificación, utilizando un conjunto etiquetado que incluya las categorías “no requiere recuperación”, “de un solo intento” e “iterativa”.

Métricas de recuperación

Estas son las métricas de referencia. Si no se registran, no es posible determinar si la recuperación de información está mejorando.

Las fórmulas, a modo de referencia (relevancia binaria con el conjunto relevante $R_q$ para la consulta $q$, y $\text{rel}_i = 1$ si el documento $i$-ésimo recuperado pertenece a $R_q$):

Para la relevancia graduada, $\text{rel}_i \in \{0, 1, 2, \dots\}$; el nDCG binario es el caso especial que se utiliza en el código a continuación. MAP representa el promedio sobre las consultas de $\text{AP}_q = \frac{1}{|R_q|}\sum_{i: \text{rel}_i = 1} \text{Precision@}i$. Véase Manning, Raghavan, Schütze, Introducción a la recuperación de información, Capítulo 8: Derivaciones.

Para el código de producción, utilice ranx, pytrec_eval, o ir_measures — Implementan toda la familia de métricas TREC y gestionan correctamente la relevancia graduada. Establezcan objetivos de lanzamiento basados en un conjunto de referencia realista, en la calidad de las respuestas generadas y en el costo asociado a un error de clasificación. No hereden los umbrales establecidos en tutoriales.

La prueba harness para estos casos es breve. Puedes ejecutarla desde un notebook incluso antes de haber seleccionado una base de datos vectorial.

from math import log2
from statistics import mean

# synthetic gold set: query_id -> set of relevant doc ids
gold = {
    "q1": {"d3"},
    "q2": {"d7", "d2"},
    "q3": {"d11"},
    "q4": {"d5"},
}

# ranked retrieval results: query_id -> ranked list of doc ids (top-10)
runs = {
    "q1": ["d8", "d3", "d1", "d4", "d2", "d9", "d6", "d10", "d12", "d13"],
    "q2": ["d2", "d6", "d4", "d7", "d1", "d3", "d8", "d11", "d5", "d9"],
    "q3": ["d11", "d2", "d3", "d4", "d1", "d6", "d7", "d8", "d10", "d12"],
    "q4": ["d1", "d2", "d3", "d6", "d8", "d9", "d10", "d12", "d13", "d14"],
}

def recall_at_k(ranked, gold_set, k):
    if not gold_set:
        return 0.0
    hit = sum(1 for d in ranked[:k] if d in gold_set)
    return hit / len(gold_set)

def reciprocal_rank(ranked, gold_set):
    # MRR contribution per query: 1/rank of the first relevant doc.
    for rank, d in enumerate(ranked, start=1):
        if d in gold_set:
            return 1.0 / rank
    return 0.0

def ndcg_at_k(ranked, gold_set, k):
    # binary relevance: rel ∈ {0, 1}
    gains = [1.0 if d in gold_set else 0.0 for d in ranked[:k]]
    dcg = sum(g / log2(i + 2) for i, g in enumerate(gains))
    # ideal DCG: all gold docs ranked first, capped by k
    n_gold_in_topk = min(k, len(gold_set))
    idcg = sum(1.0 / log2(i + 2) for i in range(n_gold_in_topk))
    return dcg / idcg if idcg else 0.0

K = 5
print(f"Recall@{K}: {mean(recall_at_k(runs[q], gold[q], K) for q in gold):.3f}")
print(f"MRR:       {mean(reciprocal_rank(runs[q], gold[q]) for q in gold):.3f}")
print(f"nDCG@{K}:  {mean(ndcg_at_k(runs[q], gold[q], K) for q in gold):.3f}")
# Recall@5: 0.750
# MRR:       0.625
# nDCG@5:    0.627

Ese es tu umbral de CI para la recuperación de datos. Conéctalo a un subconjunto rápido basado en la cobertura en cada PR y ejecuta el conjunto completo “golden” en el umbral de lanzamiento, que es más lento. Bloquea la fusión cuando una métrica preregistrada supere su presupuesto de regresión.

El repositorio complementario fija los valores exactos mencionados anteriormente.Recall@5 = 0.750, MRR = 0.625, nDCG@5 = 0.627) como una prueba de unidad en tests/test_retrieval_metrics.py; cuaderno de notas 01 Realiza análisis de Recall@k / MRR / nDCG sobre un índice real de SciFact, y la versión adaptada a entornos de producción de harness se encuentra en evaluation/retrieval.py.

Fusión híbrida de recuperación e índice de rango recíproco

BM25 es un puntuador léxico disperso que combina la coincidencia de términos exactos, el ponderado de términos y la normalización de longitud. Está disponible en rank_bm25, Elasticsearch, OpenSearch y la mayoría de los motores de búsqueda.

Fusión de rangos recíprocos (Cormack, Clarke y Buettcher, SIGIR 2009) integra BM25 con clasificaciones densas basadas en la posición. La versión original k=60 El conjunto de datos de entrenamiento constituye una línea de referencia útil. RRF es agnóstico a las puntuaciones, lo que evita la normalización entre carriles que exige la interpolación lineal. Con un conjunto etiquetado lo suficientemente grande como para estimar un delta estable, también se debe probar una combinación convexa y ajustar el valor de α.

La recuperación híbrida combinada con un codificador cruzado reranker suele mejorar la calidad de los corpus técnicos, de tipo registro o de código. El beneficio puede ser reducido en corpus con un alto grado de semántica. Es necesario comparar los resultados con los métodos que utilizan únicamente datos densos o únicamente datos dispersos, ya que una configuración deficiente de fusión puede generar rendimientos inferiores a los de cualquiera de estas alternativas.

La implementación cabe en unas pocas líneas.

from collections import defaultdict

# two retrieval lanes: dense embeddings and BM25.
dense  = ["d3", "d7", "d1", "d4", "d2", "d9", "d10"]
sparse = ["d2", "d3", "d8", "d1", "d11", "d4", "d6"]

def rrf(rankings: list[list[str]], k: int = 60) -> list[tuple[str, float]]:
    """Reciprocal Rank Fusion (Cormack et al., SIGIR 2009).

    score(d) = sum over rankings of 1 / (k + rank(d))
    Score-agnostic: only rank position matters. k=60 is the canonical default.
    """
    scores: dict[str, float] = defaultdict(float)
    for ranking in rankings:
        for rank, doc in enumerate(ranking, start=1):
            scores[doc] += 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)

fused = rrf([dense, sparse], k=60)
for doc, score in fused[:5]:
    print(f"{doc}  score={score:.5f}")
# d3  score=0.03252   <- rank 1 dense, rank 2 sparse
# d2  score=0.03178   <- rank 5 dense, rank 1 sparse
# d1  score=0.03150

Tenga en cuenta qué es lo que RRF no hace: nunca examina las puntuaciones de similitud brutas. Un recuperador denso que devuelve un valor de coseno de 0.98 y un algoritmo BM25 que da una puntuación de 17.4 no son directamente comparables. Si los normaliza con puntuaciones z o mediante escalamiento min-máx, podría terminar favoreciendo al método con la mayor varianza dentro de ese lote.

RRF utiliza únicamente el rango. Si un recuperador coloca un documento en la posición 2, ese voto tiene un valor de 1 / (60 + 2)independientemente de la puntuación bruta que lo generó.

Hybrid + RRF en SciFact: cuaderno de trabajo 02 compara densidad vs BM25 vs RRF mediante deltas por consulta. El fusionador adaptado a entornos de producción se encuentra en retrieval/hybrid_rrf.py; tests/test_rrf.py fija el canónico d3 / d2 / d1 realización de pedidos k=60.

Reranking

• ΔnDCG / ΔMRR: la única métrica fiable reranker, que mide el aumento del rendimiento respecto al caso sin reordenamiento, en el conjunto de referencia del proyecto, a la profundidad que realmente utiliza su aplicación. Se calcula ejecutando las métricas de recuperación con y sin el reranker sobre conjuntos de candidatos idénticos.
• Cross-encoder vs. bi-encoder: un bi-encoder incrusta de forma independiente la consulta y el documento (un vector por cada uno) y calcula la puntuación mediante el producto escalar; en cambio, un cross-encoder concatena consulta+documento y realiza una sola pasada forward que considera ambos elementos de manera conjunta. Los cross-encoders sacrifican una pasada forward por cada candidato a cambio de interacciones más ricas entre consulta y documento. Implementación de referencia: sentence-transformers CrossEncoder. Benchmark la relevancia y la latencia en el hardware específico, el tamaño del lote y la profundidad de los candidatos; no se debe transferir el resultado de un modelo o servicio gestionado a otro entorno.
• Por pares frente a por lista: los métodos por pares evalúan cada par (consulta, documento) de forma independiente; los métodos por lista evalúan toda la lista de candidatos conjuntamente para que el modelo pueda compararlos. Es necesario evaluar ambos en los mismos conjuntos de candidatos. Se debe calibrar umbral de puntuación por modelo y corpus, en lugar de considerar que un ejemplo publicado sea aplicable en cualquier contexto.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

query = "How do I rotate database credentials in production?"
candidates = [
    "Production database credentials are rotated via Vault every 30 days.",
    "The new logo was unveiled at the all-hands meeting.",
    "To rotate prod DB creds, run the `rotate-secrets` GitHub Action.",
]

scores = reranker.predict([(query, c) for c in candidates])
ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
for doc, score in ranked:
    print(f"{score:+.3f}  {doc}")

Un reranker constituye un candidato con alto potencial para aplicar una RAG básica de tipo pipeline, pero no representa una solución garantizada. Es necesario medir sus valores de ΔPrecision@1 y ΔnDCG en el conjunto de referencia, y conservarlo únicamente si los beneficios obtenidos superan los límites establecidos en cuanto a latencia y costo. Antes de seleccionar la siguiente optimización, se debe comparar dicho beneficio medido con los cambios menores en el proceso de recuperación de información.

ΔnDCG y ΔPrecision@1 obtenidos a partir de un cross-encoder en SciFact: Cuaderno de notas 03; módulo: retrieval/reranker.py.

Construcción de contexto y problema del intermediario perdido

Aquí es donde surgen muchos de los fallos de tipo “buena recuperación de información, mala respuesta”.

• Relevancia de contexto: puntuación de relevancia por bloque RAGAS ContextRelevancy o un codificador cruzado, agregado como media y como porcentaje de los fragmentos que están por debajo de un umbral determinado.
• Utilización de contexto: de los fragmentos incluidos en el contexto, cuántos fueron realmente citados o utilizados en la respuesta. Se calcula como \frac|\text{trozos citados}|}{|\text{trozos recuperados}|Calcula el valor de $ en una muestra etiquetada. Establece el umbral de operación en función de la calidad de la respuesta y el costo por token, en lugar de emplear un porcentaje universal.
• Detección de pérdida en el medio: evaluación sintética en la que se coloca el fragmento de referencia en las posiciones {primera, media, última} de un contexto largo y se mide la corrección de la respuesta. La degradación en forma de U es real y está documentada en Liu y colaboradores (TACL 2023). Los modelos modernos superan en rendimiento a los de la era 2023, pero el sesgo persiste. Medidas de mitigación: realizar un reclasificación y, a continuación, reordenar los resultados top-k de modo que el fragmento con la puntuación más alta aparezca primero o al final (en LangChain’s) LongContextReorder hace exactamente esto), o comprime los bloques intermedios de forma agresiva. Se debe medir mediante una evaluación estratificada por posición, y no solo con una puntuación agregada. Un ejemplo funcional de evaluación estratificada por posición listo para ejecutarse se encuentra en cuaderno de notas 06 (módulo: evaluation/lost_in_middle.py).
• Compresión de contexto: se debe informar sobre la relación de compresión (tokens de entrada / tokens de salida) junto con la corrección de la respuesta. Entre las herramientas disponibles se encuentra LangChain’s ContextualCompressionRetriever y LongLLMLingua. Se debe predefinir el límite máximo admisible de pérdida de corrección, en función del presupuesto de riesgo y de tokens de la aplicación, rechazando posteriormente aquellas configuraciones que supere dicho umbral.

Parte 5: La tasa de falsa exclusión del filtro

Esta métrica cuenta con su propia sección porque las puntuaciones de recuperación agregadas no permiten atribuir un fallo al filtro.

Un filtro de metadatos estricto como tenant_id = X AND product = Y AND locale = en-US Puede reducir el recuerdo efectivo a cero. Un Recall@k implementado correctamente detecta esta pérdida, ya que su denominador sigue siendo el conjunto original de documentos relevantes. No indica si el filtro, el recuperador o el clasificador fueron los responsables de la omisión. La fidelidad puede seguir pareciendo adecuada, puesto que evalúa la respuesta en función del contexto recuperado, que es incompleto; en este caso, el modelo respondió fielmente con “No lo sé”.

La rama roja del árbol representa el fallo más frecuente: existe el documento correcto, pero el filtro lo elimina antes de que se pueda recuperar.

La métrica

filter_false_exclusion_rate =
    (# queries where all gold docs were excluded by metadata filter) /
    (# queries with at least one gold doc)

Esta definición a nivel de consulta tiene en cuenta las exclusiones catastróficas: no queda ningún documento relevante. En el caso de consultas multi-gold, el método estándar Recall@k sigue provocando una pérdida parcial de información; si ese umbral es importante, se debe añadir una tasa de exclusión por documento. Para calcular cualquiera de estas tasas, se necesitan (a) los ID de los documentos reales correspondientes a cada consulta de evaluación y (b) herramientas de registro que registren los predicados de filtrado aplicados, y no solo los resultados finales. El valor objetivo debe establecerse en función del costo de excluir una respuesta válida y del intervalo de confianza de la muestra utilizada en producción.

He aquí una implementación funcional. Esta compara el recuerdo estándar correcto con un evaluador inválido que redefine la relevancia tras realizar el filtrado.

# A small worked example where hard filters remove relevant documents.
docs = [
    {"id": "d1", "tenant": "acme",   "locale": "en-US"},
    {"id": "d2", "tenant": "acme",   "locale": "en-GB"},
    {"id": "d3", "tenant": "globex", "locale": "en-US"},
    {"id": "d4", "tenant": "acme",   "locale": "en-US"},
    {"id": "d5", "tenant": "acme",   "locale": "de-DE"},
]

queries = [
    # the gold doc lives in en-GB but the dynamic filter forced en-US
    {"qid": "q1", "gold": {"d2"}, "filter": lambda d: d["locale"] == "en-US"},
    # the gold doc is correctly within the tenant filter
    {"qid": "q2", "gold": {"d4"}, "filter": lambda d: d["tenant"] == "acme"},
    # the gold doc is in a different tenant and gets dropped
    {"qid": "q3", "gold": {"d3"}, "filter": lambda d: d["tenant"] == "acme"},
    # the gold doc passes the filter (de-DE locale match)
    {"qid": "q4", "gold": {"d5"}, "filter": lambda d: d["locale"] == "de-DE"},
]

def filter_false_exclusion_rate(queries, docs):
    n_with_gold, n_excluded = 0, 0
    for q in queries:
        if not q["gold"]:
            continue
        n_with_gold += 1
        survivors = {d["id"] for d in docs if q["filter"](d)}
        if not (q["gold"] & survivors):
            n_excluded += 1
    return n_excluded / n_with_gold if n_with_gold else 0.0

rate = filter_false_exclusion_rate(queries, docs)
print(f"filter_false_exclusion_rate = {rate:.2%}")
# filter_false_exclusion_rate = 50.00%

# Correct Recall@k keeps the original gold set as its denominator.
def standard_recall_at_k(queries, docs, k=10):
    recalls = []
    for q in queries:
        survivors = [d for d in docs if q["filter"](d)][:k]
        survivor_ids = {d["id"] for d in survivors}
        recalls.append(len(q["gold"] & survivor_ids) / len(q["gold"]))
    return sum(recalls) / len(recalls) if recalls else 0.0

print(f"standard recall@10 = {standard_recall_at_k(queries, docs):.2%}")
# standard recall@10 = 50.00%

# INVALID: rebuilding the gold set after filtering changes the question.
# It drops queries whose relevant documents did not survive, then scores 100%.
def invalid_recall_over_filtered_gold(queries, docs, k=10):
    recalls = []
    all_doc_ids = {d["id"] for d in docs}
    for q in queries:
        all_survivors = {d["id"] for d in docs if q["filter"](d)}
        filtered_gold = q["gold"] & all_doc_ids & all_survivors
        if not filtered_gold:
            continue
        top_k_ids = set(list(all_survivors)[:k])
        recalls.append(len(filtered_gold & top_k_ids) / len(filtered_gold))
    return sum(recalls) / len(recalls) if recalls else 0.0

invalid = invalid_recall_over_filtered_gold(queries, docs)
print(f"INVALID recall (filtered gold) = {invalid:.2%}")
# INVALID recall (filtered gold) = 100.00%

assert rate == 0.5
assert standard_recall_at_k(queries, docs) == 0.5
assert invalid == 1.0

La mitad de las consultas pierden su documento de referencia debido al filtro, por lo que el Recall@10 correcto disminuye al 50 %. Esta métrica detecta el síntoma, pero no puede atribuirlo a una causa concreta. La tasa de falsa exclusión indica que el predicado eliminó dos respuestas antes de que el recuperador pudiera actuar. El evaluador intencionadamente inválido reporta un 100 % únicamente porque descarta esos fallos de su conjunto de referencia. Ningún modelo puede recuperar un documento que haya sido filtrado.

La tasa del 50 % mencionada anteriormente se reproduce como prueba de unidad en el repositorio complementario: tests/test_filter_exclusion.py::test_50_percent_exclusion_rate. Cuaderno de notas 04 lo ejecuta en SciFact con metadatos sintéticos para que pueda observar cómo un filtro real hace desaparecer el recuerdo; la métrica runtime (junto con sus indicadores complementarios de precisión-predicado/recuerdo) se encuentra en evaluation/filter_exclusion.py.

Métrica complementaria: precisión y recuerdo del predicado

Cuando el filtrado es dinámico (por ejemplo, un LLM extrae los predicados de filtrado a partir de la consulta), considere al extractor de predicados como un modelo de clasificación y éntrelo en esa categoría. Mida la precisión y el recuerdo de los predicados utilizando un conjunto etiquetado de (query, correct predicate) Pares. Una tasa de error predicativo no se corresponde directamente con la misma pérdida de puntos en el índice de recuperación y recuerdo; es necesario medir con qué frecuencia dichos errores excluyen un documento de referencia. Una vez que un filtro estricto elimina dicho documento de referencia, ninguna cantidad de reranking puede ayudar.

Refuerzo suave frente a filtro duro

Esta métrica impone una decisión de diseño. Se deben utilizar filtros estrictos cuando la corrección es binaria: jurisdicción legal, límites de ACL, estado de publicación frente a borrador. En cambio, se aplican refuerzos suaves cuando la relevancia está graduada: preferencias de ubicación, recienteidad o versión. Sin una medición de la tasa de exclusión, resulta difícil detectar la elección incorrecta.

La regla de decisión, medible:

For each filter predicate F:
  hard_recall_F  = retrieval_recall@k with F as a hard filter
  soft_recall_F  = retrieval_recall@k with F as a +0.X rerank boost
  hard_precision = relevant_in_top_k / k under hard filter
  soft_precision = relevant_in_top_k / k under soft boost
  exclusion_rate = % of queries where the gold doc was filtered out (hard)

Use hard filter only if exclusion_rate < ε AND hard_precision >> soft_precision.
Otherwise prefer soft boost.

Elija el valor de ε en función del daño que supone una exclusión errónea, del beneficio que aporta una mayor precisión y del tamaño de la muestra de evaluación. Un artículo específico de esta serie analiza con más profundidad este equilibrio.

Sección 6: Evaluación de la generación

Las métricas de recuperación indican si el sistema podría responder correctamente, pero no demuestran que lo haya hecho. Las métricas de generación cubren esa laguna.

Fidelidad y anclaje

RAGA de fidelidad Descompone la respuesta en afirmaciones atómicas (declaraciones factuales breves y autónomas) y, a continuación, verifica cada una de ellas frente al contexto recuperado mediante un juez LLM:

El porcentaje de reclamaciones respaldadas representa esa puntuación. Dicha estructura es más útil que cualquier número aislado, ya que indica cuáles reclamaciones no cuentan con soporte. El código de producción se encuentra en el ragas package — Su uso es similar a:

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

samples = Dataset.from_dict({
    "question": ["How many moons does Mars have?"],
    "answer":   ["Mars has two moons, Phobos and Deimos."],
    "contexts": [["Mars has two moons named Phobos and Deimos."]],
    "ground_truth": ["Mars has two moons."],
})

result = evaluate(samples, metrics=[faithfulness, answer_relevancy, context_precision])
print(result)

A continuación se muestra el mismo bucle desplegado con un juez sustituto determinista, para que pueda observar su estructura de extremo a extremo.

def extract_claims(answer: str) -> list[str]:
    # Production: an LLM call that decomposes the answer.
    # Demo: split on sentence-final punctuation.
    return [c.strip() for c in answer.replace("?", ".").replace("!", ".").split(".") if c.strip()]

def verify_claim(claim: str, context: str) -> bool:
    # Production: an NLI (natural-language inference) model or LLM judge.
    # Demo: a deterministic stand-in so the example runs offline.
    entailed_pairs = {
        "Mars has two moons": True,
        "Phobos and Deimos orbit Mars": True,
        "Mars has a thick atmosphere": False,  # unsupported by context
        "Curiosity landed in 2012": True,
    }
    for k, v in entailed_pairs.items():
        if k.lower() in claim.lower() or claim.lower() in k.lower():
            return v
    words = [w.lower() for w in claim.split() if len(w) > 3]
    return all(w in context.lower() for w in words) if words else False

context = (
    "Mars has two moons, Phobos and Deimos. NASA's Curiosity rover "
    "landed on Mars in 2012."
)
answer = (
    "Mars has two moons. Phobos and Deimos orbit Mars. "
    "Mars has a thick atmosphere. Curiosity landed in 2012."
)

claims = extract_claims(answer)
verdicts = [(c, verify_claim(c, context)) for c in claims]
faithfulness = sum(1 for _, ok in verdicts if ok) / len(verdicts)
for c, ok in verdicts:
    print(f"  [{'✓' if ok else '✗'}] {c}")
print(f"faithfulness = {faithfulness:.2f}")
# faithfulness = 0.75   (one unsupported claim about the atmosphere)

La estructura es fundamental. En entornos de producción, verify_claim Se convierte en un modelo de NLI o en una llamada a LLM. El resto de las etapas de harness permanece igual: extracción, verificación y agregación.

Extracción y verificación de reclamaciones de extremo a extremo en las respuestas generadas por SciFact: Cuaderno de notas 05; módulo: evaluation/faithfulness.py. El repositorio también ejecuta un verificador de tipo HHEM entre familias diferentes dentro del mismo bucle, de modo que pueda observar qué familia de jueces coincide con cuál.

Una alternativa diseñada específicamente para sustituir a LLM como árbitro. HHEM-2.1-Abierto (Hughes Hallucination Evaluation Model, Vectara), un clasificador ajustado específicamente para la detección de alucinaciones. Su ficha técnica describe el checkpoint, el límite de decisión predeterminado, así como los resultados obtenidos en AggreFact y RAGTruth. Considere dichos datos como evidencia contenida en la ficha del modelo, y no como una garantía válida para su propio conjunto de datos: calibre el umbral utilizando etiquetas locales y compárelo con el criterio de evaluación que haya seleccionado antes de implementar el sistema.

Evaluación de hechos atómicos

FActScore (Min et al., EMNLP 2023) descompone las generaciones de texto extenso en hechos atómicos, recupera la evidencia correspondiente a cada hecho y etiqueta cada uno de ellos. supported / not-supported, y muestra la fracción soportada:

Implementación de referencia: shmsw25/FActScore. Funciona de manera eficaz para biografías, resúmenes y otros tipos de outputs de formato extenso. Hay que tener cuidado: los hechos triviales repetitivos pueden elevar la puntuación, y los ataques “MontageLie” (hechos reales presentados en un orden engañoso) pueden hacer que el sistema fallen. VeriScore maneja las reclamaciones aplicando los modificadores necesarios; el Core El filtro ayuda a evitar el relleno de datos con información irrelevante.

Precisión de las citaciones

Controlar la precisión de las citaciones (es decir, que los segmentos citados realmente respalden la afirmación) y el recuerdo de las citaciones (es decir, que las afirmaciones que deben ser citadas sí lo estén):

La categoría TREC 2024 RAG define un protocolo de evaluación de soporte reproductible. Upadhyay y colaboradores (SIGIR 2025) El informe indica que GPT-4o coincide con los jueces humanos en el 56 % de los casos en evaluaciones manuales desde cero, y esa cifra aumenta al 72 % tras la edición posterior de las predicciones de LLM. Esto resulta útil como factor multiplicador dentro de sus condiciones específicas, pero no como sustituto de la evaluación humana en contextos de alto riesgo. Se trata, pues, de una aproximación automatizada. ALCE (Gao et al., EMNLP 2023) implementan la precisión y el recuerdo de citaciones mediante verificación basada en NLI.

Exactitud, exhaustividad y rechazo de respuestas

• Exactitud de la respuesta vs. verdad de referencia: cuando se dispone de ella, coincidencia exacta o F1 por tokens para tareas de respuestas cortas (evaluate.load("squad")), similitud semántica para preguntas abiertasbert-score, embedding mediante el coseno sentence-transformers, o RAGAS AnswerCorrectness).
• Completitud mediante “nuggets”: un “nugget” es un elemento de información atómico único que toda respuesta correcta debe contener (por ejemplo, para “¿Cuándo se fundó la empresa?”, los nuggets podrían ser {year: 1994, founder: Jane Doe}). Los de TREC AutoNuggetizer Extrae los elementos más valiosos de una respuesta correcta a partir de una referencia, y posteriormente calcula qué fracción del contenido aborda el sistema; se observó una fuerte correlación con la evaluación realizada manualmente en 21 temas durante 45 pruebas en TREC 2024.
• Comportamiento de rechazo: las consultas para las cuales no existe respuesta en el corpus deben generar una actitud de abstenencia, y no alucinaciones. Se debe hacer un seguimiento de la precisión de la abstenencia (los rechazos que fueron correctos) y del recuerdo de la abstenencia (las consultas fuera del alcance que provocaron un rechazo). NoMIRACL ¿Es el benchmark público en tu propio dominio? Etiqueta una porción de las consultas fuera del alcance y haz un seguimiento de la precisión de la abstención.

Verificación post-generación

Los mayores ahorros en costes relacionados con la fiabilidad suelen obtenerse mediante comprobaciones deterministas posteriores, y no a través del uso de modelos más grandes.

• Verificación de anclaje de entidades: cada entidad nominal presente en la respuesta debe aparecer en el contexto recuperado (o ser derivable de él). Se puede utilizar una comprobación sencilla con expresiones regulares más una verificación de coincidencia exacta (o spaCy’s ents Al compararlas con una cadena de contexto normalizada, este método detecta una proporción sorprendentemente alta de alucinaciones.
• Verificación de afirmaciones: se extraen las afirmaciones, se aplica la NLI contra el contexto, y se rechaza o se marca como problemática cualquier afirmación por debajo del umbral establecido. Modelos de NLI como métrica de fidelidad: cross-encoder/nli-deberta-v3-large, MoritzLaurer/DeBERTa-v3-large-mnli-fever-anli-ling-wanli. Añade latencia. Vale la pena en dominios de alta importancia.
• Autoconsistencia (Wang y colaboradores, ICLR 2023): Ejecutar múltiples generaciones de muestra a una temperatura superior a 0; informar la tasa de acuerdo (por ejemplo, la proporción de generaciones que coinciden con la respuesta modal, o el BERTScore entre pares); seleccionar el número de muestras según la curva de estabilidad–coste y marcar las respuestas con bajo grado de acuerdo para su revisión por parte de un humano.
• Calibración de confianza: se recopila la confianza expresada verbalmente (“¿Qué tan seguro está, del 0 al 1?”) y se compara con la corrección real en el conjunto de evaluación. Se traza una curva de calibración y se reporta el Error de Calibración Esperado: \text{ECE} = \sum_{m=1}^{M} \frac{|B_m|{n} |\text{acc}(B_m) - \text{conf}(B_m)|, donde $B_m$ son los intervalos de confianza. Implementaciones: netcal, torchmetrics.CalibrationError. Un modelo que muestra una confianza del 0.9 debería ser correcto en aproximadamente el 90 % de los casos comparables; es preciso medir la brecha existente en lugar de dar por sentada la calibración.

Parte 7: Evaluación basada en ontologías de RAG

Las métricas estándar mencionadas anteriormente abarcan el corpus abierto RAG. Los sistemas basados en ontologías requieren más datos para su evaluación. Si su RAG realiza búsquedas contra una ontología estructurada, una taxonomía o un grafo de conocimiento (productos en un catálogo, condiciones en SNOMED, componentes en una lista de materiales, técnicas de seguridad en MITRE ATT&CK), las métricas estándar RAG son necesarias, pero no suficientes. También es preciso medir el nivel de la capa ontológica.

Precisión de enlace de entidades

La primera tarea consiste en mapear una mención de consulta a una entidad de la ontología (“Aspirin” → wikidata:Q18216”el 737” aircraft:Boeing_737).

• Precisión/recuerdo/F1 a nivel de mención: estándar, con respecto a los intervalos de mención de referencia (calcularse mediante seqeval o un comparador de conjuntos de intervalos).
• Precisión de desambiguación: de las menciones detectadas correctamente, ¿qué fracción corresponde al ID de entidad correcto? Las referencias públicas incluyen ReFinED, REL, y GENRE; similar a benchmarks AIDA-CoNLL y BELB Demuestre que los resultados varían en función del sistema y del dominio.
• Gestión de NIL: precisión/recall para el caso de “entidad no presente en la ontología”. Se debe medir el sobreligamiento hacia entidades cercanas pero incorrectas por separado de la abstención correcta.

Evaluación consciente de la jerarquía

La precisión simple trata como idénticos los casos en que se predice “Sedán” cuando la realidad es “Hatchback”, y aquellos en que se predice “Sedán” cuando la realidad es “Submarino”. Dichos errores no son equivalentes.

• Precisión/recuerdo/F1 jerárquicos (Kosmopoulos y colaboradores, 2015): Asignar crédito a los ancestros y descendientes en el DAG de la ontología. Donde $\hat{P}_q$ representa el nodo predicho junto con todos sus ancestros, y $T_q$ al nodo real junto con todos sus ancestros:

  $$hP = \frac{\sum_q |\hat{P}_q \cap T_q|{\sum_q} |\hat{P}_q|}, \quad hR = \frac{\sum_q |\hat{P}_q \cap T_q|{\sum_q} |T_q|}, \quad hF1 = \frac{2 \cdot hP \cdot hR}{hP + hR}$$

  Implementar con networkx en el grafo de ontología; véase hierarchical-classifier-metrics Como referencia.

• Similitud Wu-Palmer entre la entidad predicha y la entidad de referencia en la taxonomía (Wu y Palmer, 1994):

  $$\text{WuP}(c_1, c_2) = \frac{2 \cdot \text{depth}(\text{LCA}(c_1, c_2))}{\text{depth}(c_1) + \text{depth}(c_2)}$$

  donde LCA es el ancestro común más bajo en la taxonomía. Está disponible de forma predeterminada en NLTK para WordNet.from nltk.corpus import wordnet as wn; wn.synset("car.n.01").wup_similarity(wn.synset("truck.n.01"))); para taxonomías personalizadas, se calcula el LCA con networkx.

• Tasa de confusión entre hermanos y padres: realizar un seguimiento por separado de las confusiones con hermanos, padres e hijos. count_sibling / total_errors, count_parent / total_errors, count_descendant / total_errors. Utilice ejemplos ya validados para comprobar si los errores entre elementos hermanos se deben a menciones ambiguas, o bien si los errores en los elementos padre provienen de una sobregeneralización.

Tasa de filtrado de falsas exclusiones (reprise; ahora crítica)

En los sistemas basados en ontologías, los filtros estrictos suelen provenir de la propia ontología (“solo recuperar documentos etiquetados con la categoría X”). La métrica de tasa de exclusión (definida en Parte 5) Se convierte en una señal principal de corrección. Una predicción errónea de categoría puede anular por completo el recuerdo; la tasa de exclusión atribuye esa pérdida al filtro.

Conformidad en la generación restringida

Cuando la salida debe cumplir con una ontología (cada nombre de entidad en la respuesta debe ser un miembro válido de la ontología; cada predicado debe provenir de un vocabulario cerrado), mida:

• Tasa de validez del esquema: porcentaje de resultados que se pueden analizar y validar con respecto al esquema de la ontología. Validar con jsonschema o pydantic. JSONSchemaBench ¿Es el benchmark público adecuado para structured output en general? Para esquemas específicos de ontologías, es necesario crear un validador propio.
• Conformidad léxica: porcentaje de entidades nombradas en la salida que corresponden a IDs de ontología válidos; se trata de una comprobación de pertenencia a un conjunto definido en una sola línea, basada en el vocabulario cerrado.
• Conformidad semántica: la validez es necesaria, pero no suficiente. Una salida sintácticamente correcta puede seleccionar una entidad válida, pero errónea. Es preciso combinar esta conformidad con la corrección de las respuestas generadas posteriormente.

Constrained decoding frameworks (Esquemas, XGrammar, Guía, OpenAI Structured Outputs) Están diseñados para garantizar la validez del esquema. JSONSchemaBench Compara la eficiencia, el grado de cobertura y la calidad entre las distintas implementaciones. Ejecuta nuevamente los casos que coincidan con tus esquemas y serving backend, ya que tanto la cobertura como la latencia dependen de ambos factores.

Auditabilidad

En los sistemas basados en ontologías donde las respuestas requieren revisión:

• Completitud de las citaciones: porcentaje de afirmaciones factuales que cuentan con al menos una citación verificable.
• Profundidad de la procedencia: porcentaje de citaciones que remiten directamente a un documento fuente con un identificador estable, y no solo a un hash de fragmento.
• Tasa de reproducibilidad: al ejecutar nuevamente la misma consulta con un snapshot fijo, se obtiene el mismo resultado. Es necesario fijar la versión del modelo, runtime, la configuración de decodificación y el seed, y luego establecer la tasa de repetición requerida según las necesidades de auditoría del flujo de trabajo. El uso exclusivo de una temperatura cero no garantiza determinismo; un error puede surgir durante la generación, en el serving runtime, o en cualquier etapa anterior del proceso.

Parte 8: Evaluación a nivel de sistema

Calidad integral de la respuesta

• LLM-como-juez (Zheng et al., NeurIPS 2023): un enfoque de evaluación basado en modelos escalable. G-Eval (un protocolo de LLM-juez que hace que el modelo genere su propia rúbrica de chain-of-thought antes de realizar la puntuación) obtiene dicha rúbrica a partir de un criterio en lenguaje natural y, posteriormente, calcula las puntuaciones mediante valores de salida ponderados por log-probabilidad. El grado de acuerdo depende del juez, de la tarea, de prompt y del conjunto de calibración.
• Preferencia entre pares: se presenta al juez la respuesta A frente a la respuesta B; se registra entonces su preferencia. Esto evita los problemas relacionados con la calibración de puntuaciones absolutas. MT-Bench Se ha reportado que la concordancia del juez GPT-4 supera el 80% tanto en relación con las preferencias humanas como con la concordancia entre personas, bajo sus condiciones benchmark; no se debe trasladar esa tasa a otro dominio sin realizar una calibración previa.

LLM-como-juez presenta sesgos reales:

• Sesgo de posición: los evaluadores prefieren la primera o segunda respuesta independientemente de su calidad. Mitigación: aleatorizar el orden, o ejecutar las dos opciones y calcular un promedio.
• Sesgo de verbosidad: los evaluadores pueden confundir la longitud con la calidad. A Estudio controlado de 2026 Se observó un comportamiento heterogéneo en las parejas de expansión: tres evaluadores prefirieron respuestas más extensas, Claude optó por respuestas concisas, y GPT-4o mantuvo una actitud aproximadamente neutra. Los cinco modelos obtuvieron buenos resultados en las pruebas de control de truncación. El resultado está sujeto a los límites establecidos por benchmark, por lo que debe indicar a sus evaluadores cómo gestionar la completitud y los elementos redundantes, y posteriormente informar sobre el rendimiento bajo control de longitud según su propia escala de evaluación.
• Sesgo de auto-preferencia: GPT-4 prefiere sus propias salidas; este sesgo está relacionado con la perplejidad de la salida (los evaluadores tienden a preferir texto que les resulte familiar). Mitigación: utilizar un conjunto de evaluadores distinto al del sistema que se está evaluando. No se debe emplear un modelo para que evalúe a sí mismo.

Receta práctica: seleccione un evaluador a partir de datos de calibración etiquetados por humanos, aleatorice el orden de las respuestas, enmascare las identidades de los modelos y especifique la política de longitud en la rúbrica. Repita los casos únicamente cuando las muestras adicionales reduzcan de manera significativa la incertidumbre. En evaluaciones de alto riesgo, compare a los evaluadores pertenecientes a diferentes familias de modelos y analice las discrepancias frente a las etiquetas proporcionadas por humanos.

Razonamiento guiado por esquemas para jueces

Razonamiento guiado por esquema (SGR) Hace que dicha rúbrica sea explícita: se definen las fases de evaluación como un esquema Pydantic, y posteriormente se controla la salida mediante Outlines, XGrammar, vLLM structured outputs, u OpenAI. response_format Por lo tanto, cada ejecución devuelve los mismos campos en el mismo orden.

Para RAG eval, el esquema descompone la evaluación en campos explícitos y auditables, en lugar de permitir que el modelo llegue directamente a un número:

from pydantic import BaseModel, Field
from typing import Literal

class FaithfulnessJudgment(BaseModel):
    extracted_claims: list[str] = Field(
        description="Atomic factual claims in the answer, one per item."
    )
    supported_claims: list[str] = Field(
        description="Subset of extracted_claims that are entailed by the context."
    )
    unsupported_claims: list[str] = Field(
        description="Subset that is NOT entailed by the context."
    )
    failure_mode: Literal[
        "none", "fabrication", "overgeneralization", "wrong_entity", "stale_fact"
    ]
    score: float = Field(ge=0.0, le=1.0)
    rationale: str

Los campos estructurados permiten que la puntuación sea recuperable. len(supported) / len(extracted) Además, se muestra con exactitud cuáles son las afirmaciones sobre las que discrepaban los dos jueces. El modelo Pydantic también permite visualizar los cambios en la rúbrica mediante un difuminio de código. Dado que la salida está sujeta a restricciones, estas solo garantizan la estructura del resultado y no una evaluación imparcial; por lo tanto, siguen siendo aplicables la aleatorización de posiciones, la inclusión de jueces de familias diferentes y la calibración humana.

Esto funciona para cualquier evaluador basado en rúbricas, no solo para la evaluación de fidelidad. La preferencia entre pares, el soporte para citaciones y la corrección en casos de rechazo se benefician todos del mismo tratamiento.

Un evaluador G-Eval / por pares / con sesgo de posición / entre familias diferentes harness reside en cuaderno de trabajo 07; módulo: evaluation/llm_judge.py. El barrido de benchmarkmake benchmark En el repositorio) conecta tres modelos de nivel avanzado — gpt-5-mini, claude-haiku-4-5, gemini-2.5-flash — transformándolo en un diseño A/B entre jueces rotativos, de modo que cada modelo evalúe a los otros dos y se refleje así numéricamente su propia preferencia.

Latencia y costo

• p50, p95, p99 en cada etapa pipeline. Se debe seleccionar el percentil del SLO y el umbral de alerta en función del recorrido del usuario, el volumen de tráfico y el presupuesto de errores disponible.
• Time-to-first-token frente al tiempo total de generación. Para una experiencia de usuario fluida mediante transmisión en tiempo real, a los usuarios les resulta crucial conocer el TTFT.
• Desglose por etapas: recuperación, reranking, generación y posprocesamiento. Es necesario utilizar el seguimiento de trazas para identificar la causa raíz del problema en lugar de suponer arbitrariamente en qué etapa se produce; además, al comparar diferentes ejecuciones, se debe registrar el dispositivo reranker y el tamaño del lote.
• Coste total por consulta = embedding más costes de recuperación, reclasificación, generación y almacenamiento, todos ellos amortizados. Es importante monitorear los valores p50 y p99, ya que es en la cola larga donde se agota el presupuesto asignado.
• Índices de acierto en caché a nivel del caché embedding, caché de recuperación y caché KV. Se deben establecer objetivos separados en función de la tasa de repeticiones observada, la política de invalidación y el ahorro económico logrado en cada capa.

Se incluye de forma integrada el cálculo del p50/p95/p99 por etapa, junto con un desglose detallado de cada etapa. cuaderno de trabajo 08 y el ejecutor en evaluation/latency.py; El informe benchmark combina la latencia con la fidelidad en una única matriz que se puede volver a ejecutar make benchmark.

Pruebas A/B

• Unidad de randomización: elige la unidad entre el estimando, la persistencia y la interferencia. Utiliza una asignación por usuario o por sesión cuando la exposición repetida pueda modificar el comportamiento o generar una experiencia de usuario inconsistente. La asignación por consulta solo es defendible cuando dichos efectos son insignificantes y los modelos de análisis tienen en cuenta las observaciones repetidas.
• Métricas principales, de control y exploratorias: regístralas con antelación. Elige la medida principal a partir del resultado del producto; los indicadores de satisfacción incluyen pulgares arriba, regeneraciones y tiempo de permanencia. Considera la latencia y el costo como métricas de control siempre que limiten la experiencia del usuario.
• Tamaño de la muestra: realiza un análisis de poder antes del lanzamiento, teniendo en cuenta el efecto mínimo detectable, la varianza de referencia, la unidad de asignación y la regla de parada.

Sección 9: Construcción del conjunto de prueba

Una métrica solo es tan buena como el conjunto de pruebas en el que se evalúa. Si su conjunto de referencia abarca tres intenciones mientras que el tráfico real incluye doce, la métrica Recall@10 solo tendrá en cuenta esas tres intenciones. Peor aún, un conjunto de pruebas que sobreajusta sus resultados a preguntas fáciles (“¿Cuál es la política de reembolso de la empresa?”) puede dar una evaluación positiva a un sistema que falla ante cuestiones más complejas (“¿Qué requisitos se aplican para obtener un reembolso por cancelación parcial según la Ley de Servicios Digitales de la UE de 2023, con facturación en euros y origen en Irlanda?”). A pesar de ello, la puntuación global aumenta, ya que el sistema sigue incumpliendo las necesidades de una parte importante del tráfico real.

El mismo problema afecta también a los datos de verdad real. Si las pymes etiquetan los documentos obvios pero pasan por alto aquellos de cola larga que son relevantes, Recall@k subestimará el rendimiento de un recuperador que, de hecho, los ha encontrado. Se optimiza en función de las etiquetas, y no en función de la verdad real.

Primero, construya el conjunto de pruebas basándose en la distribución real de consultas y su nivel de dificultad. A continuación, seleccione métricas que permitan detectar los modos de fallo deseados y ajuste el sistema en función de ellos.

Generación de consultas sintéticas

Utiliza un LLM para generar preguntas a partir de tu corpus:

• Por fragmento: “Genera 3 preguntas que un usuario podría hacer y a las cuales responde este fragmento”.
• Multihop: toma dos fragmentos y genera una pregunta que requiera información de ambos.
• Adversarial: crea preguntas con entidades engañosas, redacción casi idéntica y menciones ambiguas.

RAGAS Cuenta con una distribución integrada de tipos de preguntas (razonamiento, condicional, multicontexto). DataMorgana Genera datos sintéticos benchmarks configurables según las categorías de usuarios y consultas. Los datos sintéticos resultan útiles para los casos de inicio sin historial de interacciones y para pruebas de cobertura. No pueden sustituir a las consultas reales de los usuarios.

Construcción de tipo Golden dataset

Los datos curados por humanos sirven como anclaje para el conjunto de referencia.

1. Muestras de consultas reales de usuarios (o simuladas en caso de estar antes del lanzamiento), estratificadas por intención.
2. Hacer que los expertos técnicos respondan a cada pregunta e identifiquen qué documento(s) contienen la respuesta.
3. Determinar el tamaño del conjunto a partir de la matriz de cobertura y del intervalo de confianza necesario para tomar decisiones de lanzamiento; la cobertura es más importante que el número de consultas obtenidas.
4. Actualizar nuevamente el conjunto cuando el ritmo de lanzamientos, las señales de desviación, los riesgos del dominio y la capacidad de anotación lo justifiquen.

Conjuntos de pruebas adversariales

• Contrafactuales: se intercambian las entidades clave de la consulta. ¿Recupera el sistema los fragmentos adecuados para la consulta modificada?
• Distractores: consultas en las que el corpus contiene una respuesta plausible pero incorrecta que no debería ser recuperada. Esto es precisamente lo que RGB (Chen et al., AAAI 2024) realizan pruebas de estrés en aspectos como la robustez ante ruido, el rechazo negativo, la integración de información y la robustez contrafactual.
• Negación y cuantificadores: consultas que contienen “no”, “excepto” y “solo”. Los recuperadores densos suelen tener dificultades con este tipo de consultas.
• Fuera del alcance: consultas para las cuales no existe respuesta en el corpus. El sistema debe indicar “No lo sé”, en lugar de generar respuestas falsas. NoMIRACL Vive aquí. Evalúe de forma explícita la abstenencia en los tipos de consultas de producción que utilice.

Cobertura y evaluación continua

• Construir una matriz de cobertura: intención de consulta × tipo de documento × rama de la ontología. El objetivo es tener al menos 1 consulta por celda. Las celdas vacías representan áreas no monitoreadas donde pueden ocultarse regresiones.
• Ejecutar un subconjunto de pruebas de regresión limitado y rápido en cada PR, y el conjunto completo según un calendario más lento.
• Programar la evaluación del conjunto de referencia completo en función del ritmo de lanzamientos y los costes asociados; los candidatos a lanzamiento constituyen una etapa natural en este proceso.
• Planificar la evaluación de deriva en base al volumen de tráfico, los cambios esperados y el nivel de riesgo. Se debe utilizar una muestra dinámica de producción y estratificarla según los comentarios recibidos, en lugar de modificar silenciosamente la distribución objetivo.

Parte 10: Monitoreo en producción

El conjunto de pruebas de evaluación que se incluye describe el sistema en el momento del lanzamiento. El tráfico en producción cambia posteriormente.

Retroalimentación implícita y explícita

• Tasa de clics/aberturas en las fuentes citadas (si la interfaz de usuario las muestra).
• Tiempo de permanencia en la respuesta.
• Tasa de regeneración: porcentaje de respuestas que el usuario vuelve a solicitar o pide al sistema que vuelva a generar. Considérela como una señal de insatisfacción y cámbiela según las conversaciones analizadas.
• Tasas de copia/compartir/exportar: son una señal muy positiva.
• Patrones de seguimiento: frases como “¿Está seguro?” o “¿Pero qué pasa con X?” indican desconfianza.
• Me gusta/no me gusta con categorías opcionales de motivo (incorrecto, incompleto, fuera de tema, dañino, lento). Las ediciones directas, cuando la interfaz de usuario lo permite, constituyen la señal de retroalimentación más informativa que existe.

Detección de deriva

• Deriva de consultas: se realiza el seguimiento de la distribución de las consultas embedding en comparación con una ventana de referencia mediante la divergencia de KL, el MMD o un detector basado en modelos. Se emiten alertas ante cualquier cambio y, a continuación, se procede a su segmentación y depuración.
• Deriva de Embedding: se fija un conjunto de documentos de prueba; periódicamente se vuelven a incrustar y se mide su coseno respecto al embeddings original. Incluso una deriva pequeña entre versiones del modelo del proveedor puede dañar silenciosamente la capacidad de recuperación de información. El almacenamiento de embedding por versiones (con instantáneas inmutables para cada versión) es la solución más económica para mitigar este problema.
• Deriva de rendimiento: se monitorizan a lo largo del tiempo métricas equivalentes a las del entorno de producción (tasa de regeneración por intención). Un aumento repentino indica que algo ha fallado; una deriva lenta, en cambio, sugiere que han cambiado las condiciones externas.

Evaluación en sombra y human-in-the-loop

Ejecutar el sistema candidato en paralelo con el de producción, comparar las salidas de forma offline y evitar servirlas a los usuarios. De este modo se detectan posibles regresiones antes del lanzamiento. Aunque esto implica un consumo adicional de recursos de inferencia, no tiene ningún impacto en los clientes.

Para la revisión de human-in-the-loop (HITL):

• Incluir las salidas de baja confianza en una cola de revisión.
• Incluir una muestra aleatoria del tráfico en producción para la revisión ciega; establecer su tasa en función del volumen de tráfico, el nivel de riesgo y la capacidad de los revisores.
• Dar un peso elevado a las salidas con valor negativo.
• Utilizar las salidas ya revisadas para ampliar el conjunto de referencia.

El conjunto mínimo de medidas de protección

¡Alerta sobre estos elementos, en orden de prioridad!

1. Puntuación de fidelidad/HHEM por debajo del umbral en una muestra en tiempo real de producción.
2. Latencia p95 superior al SLO establecido.
3. Tasa de falsa exclusión filtrada por encima del umbral (basada en muestras).
4. Tasa de regeneración fuera de la banda de control calibrada localmente, la cual tiene en cuenta el tamaño de la ventana, el tráfico, la estacionalidad y el presupuesto de alertas falsas.
5. Coste/pregunta superior al presupuesto asignado.

Si se dispara una alerta sin que haya un cambio correspondiente en el código o en el modelo, lo más probable es que se trate de deriva. Si se dispara tras un cambio, es muy probable que se esté produciendo una regresión. En cualquier caso, se recibe una señal antes de que lleguen los tickets de soporte.

Precauciones

• Los objetivos son locales, no universales. Cualquier valor indicado como ilustrativo en esta guía corresponde a una configuración de ejemplo o a un resultado obtenido en pruebas, y no a un umbral oficial de publicación. Ajuste los umbrales en función de su dominio específico, las implicaciones asociadas, la incertidumbre del conjunto de evaluación y las expectativas de los usuarios.
• El framework está en constante evolución. Las versiones de HHEM, los nombres de las métricas RAGAS, las fichas técnicas de los modelos y el orden en las listas de mejores resultados pueden cambiar tras su publicación. Revise siempre la fuente correspondiente y vuelva a benchmark antes de proceder con la implementación.
• Los números de acuerdo LLM-como-juez vienen acompañados de asteriscos. La cifra del 80 % entre GPT-4 y humanos se refiere a las condiciones de MT-Bench / Chatbot Arena. En dominios especializados o casos adversariales, este porcentaje disminuye drásticamente. Utilice a los jueces como herramienta complementaria, y no como sustituto, para realizar verificaciones adicionales.
• Las mejoras prometidas por los proveedores benchmark a menudo no son reproducibles de forma independiente. Antes de dar crédito a algún número, realice pruebas con sus propios datos, especialmente en el caso de los sistemas más recientes rerankers y OCR.
• Ninguna métrica puede sustituirse por la revisión directa de las salidas. Programe revisiones ciegas de muestras aleatorias de producción en función del tráfico generado, el nivel de riesgo y la capacidad de los revisores. Las métricas solo sirven para cuantificar esa práctica; no la reemplazan.

Próximos temas en esta serie

Este era el índice. Las acciones posteriores que estoy planificando:

• Boosts suaves frente a filtros estrictos: un análisis en profundidad de la tasa de falsa exclusión por filtros, con código, ejemplos reales de producción y una decisión framework.
• El chunking como variable oculta: un experimento controlado que evalúa el chunking recursivo, semántico, tardío y estructural en tres corpus diferentes.
• Selección de Reranker en 2026: BGE frente a Cohere, ZeRank y los modelos de codificador cruzado actuales, comparados directamente en términos de costo, latencia y mejora del rendimiento.
• RAG basado en ontologías: una explicación paso a paso: cómo construir la evaluación completa harness para un sistema de recuperación basado en entidades.
• Uso de LLM como evaluador sin caer en la trampa de la preferencia propia: métodos prácticos para lograr una evaluación automática imparcial.
• Evaluación en tiempo real en entornos de producción: patrones de instrumentación, políticas de alerta y paneles de control que detectan regresiones reales.

Referencias

Frameworks y benchmarks

• Es y colaboradores, Ragas: Evaluación automática de la generación reforzada por recuperación de información, 2023.
• Documentación de RAGAS y GitHub.
• Saad-Falcon y colaboradores, ARES: Una evaluación automatizada Framework para sistemas de generación reforzada por recuperación de información., NAACL 2024.
• TruLens, DeepEval, Arize Phoenix.
• Thakur et al., BEIR: Un Benchmark heterogéneo para la evaluación sin entrenamiento de modelos de recuperación de información, NeurIPS 2021.
• Clasificación de MTEB.
• TREC 2024 RAG Carrera.
• Pradeep et al., Resultados iniciales de evaluación de nuggets para la categoría TREC 2024 RAG con el herramienta AutoNuggetizer Framework, 2024.

Recuperación y clasificación

• Cormack, Clarke, Buettcher, La Fusión de Rangos Recíprocos supera a los métodos de Condorcet y de Aprendizaje de Rangos Individuales., SIGIR 2009.
• Gao et al., Recuperación densa de cero disparos precisa sin etiquetas de relevancia (HyDE), 2022.
• Jeong et al., Adaptativo-RAG: Aprendizaje para adaptar los modelos de lenguaje grandes mejorados por recuperación según la complejidad de las preguntas, NAACL 2024.
• Anthropic, Presentación de la recuperación contextual, Septiembre de 2024.
• Günther et al., Agrupación tardía de tokens: Agrupación contextual Embeddings mediante modelos de contexto amplio Embedding, 2024.
• Sarthi y colaboradores, RAPTOR: Procesamiento Abstractivo Recursivo para la Búsqueda Organizada en Árboles, 2024.

Generación, fidelidad y evaluadores

• Min y colaboradores, FActScore: Evaluación atómica de alta precisión sobre la exactitud factual en la generación de texto extenso, EMNLP 2023.
• Liu y colaboradores, Perdido en el medio: cómo los modelos de lenguaje utilizan contextos largos, TACL 2023.
• Chen et al., Realización de pruebas de rendimiento en modelos de lenguaje grande dentro del paradigma de generación reforzada por recuperación de información (RGB), AAAI 2024.
• Vectara, HHEM-2.1-Modelo de evaluación de la alucinación abierta.
• Zheng y colaboradores, Evaluación de LLM como juez mediante MT-Bench y Chatbot Arena, NeurIPS 2023.
• Upadhyay et al., Evaluación de soporte para la categoría TREC 2024 RAG: Comparación entre jueces humanos y LLM, SIGIR 2025.
• Thakur et al., NoMIRACL: Cómo saber cuándo no se sabe para una generación reforzada por recuperación multilingüe robusta, 2023.
• Geng et al., JSONSchemaBench: Una prueba rigurosa Benchmark de Structured Outputs para modelos de lenguaje, 2025.
• Kosmopoulos et al., Medidas de evaluación para la clasificación jerárquica: una visión unificada y enfoques innovadores, 2015.

Deriva y entorno de producción

• Evidentemente, Los métodos de detección de deriva comparados Embedding.

Código complementario

• slavadubrov/rag-evals-demo — un harness ejecutable para cada métrica de este artículo basado en el corpus SciFact, además de un proceso de segmentación × embedding × LLM benchmark. Incluye los cuadernos de notas del 00 al 09, las pruebas unitarias que validan los ejemplos resueltos anteriormente, y un índice Qdrant integrado que permite su ejecución sin necesidad de Docker.