Evals para LLMs: la capa después del tracing que decide si tu modelo rinde o sólo parece rendir

Mon, 25 May 2026 07:30:00 +0200

Esta es la etapa 3 del pipeline LLMOps. Si llegas sin contexto del recorrido completo, el pipeline LLMOps de seis etapas describe dónde encaja Eval entre Tune y Deploy, y la anatomía de una petición LLM en producción muestra una eval real bloqueando la promoción de un adapter.

TL;DR

Tracing no es evaluación. Tracing te dice qué pasó; eval te dice si lo que pasó está bien. Las dos capas viven en herramientas que se solapan visualmente (Langfuse hace ambas), pero la disciplina es distinta: tracing es captura continua sobre tráfico real; eval es ejecución controlada contra un dataset estable, con métricas que tienen que fallar el CI si caen por debajo de un umbral. Sin eval, el ciclo Tune → Deploy se cierra a ciegas: el adapter v8 va a producción porque el ingeniero “vio que respondía bien” en cinco ejemplos. Con eval bien hecha, el v8 sólo entra si supera al v7 en una batería de 500 casos curados, evaluados por una mezcla de heurísticos, embeddings, un judge LLM calibrado contra humanos, y una muestra de tráfico real con anotación humana. Este post desmonta el mecanismo, las matemáticas para no engañarse, las herramientas reales en 2026 y las trampas que lo convierten en teatro.

La analogía: el tribunal académico

Un candidato a doctor defiende una tesis. No la defiende ante un solo profesor distraído: la defiende ante un tribunal mixto, con un temario fijado por adelantado (no improvisado el día del acto), y con una nota de corte explícita que separa aprobado de suspenso. El tribunal no es un único experto: es un panel que combina lectores rápidos (los heurísticos: ¿tiene el formato pedido?, ¿incluye la cita?), revisores semánticos (los embeddings: ¿se parece a la respuesta esperada?), un evaluador externo formado para el tema (el judge LLM: ¿es fiel al contexto, es relevante, suena coherente?), y miembros humanos del jurado en una muestra de los casos más sensibles. Si el candidato no llega a la nota, no se promociona: vuelve a preparar la defensa.

Esa analogía tiene tres aristas que conviene retener desde el primer minuto:

El temario es fijo, pero se actualiza activamente cuando aparece un tema nuevo en el mundo real que el candidato debe saber. Si no se actualiza, el examen mide algo cada vez más alejado de lo que pasa fuera.
El tribunal hay que formarlo: un juez LLM sin calibrar contra humanos es un examinador que se inventa los criterios.
La nota de corte se publica antes: no se decide después de ver el resultado, porque entonces no es nota de corte, es justificación.

Estas tres ideas atraviesan el resto del post. Cada herramienta y cada matemática que sigue es, en el fondo, un modo de operacionalizarlas.

El mecanismo en sí: cuatro capas de evaluadores

Una suite de evals en 2026 se compone de cuatro capas que coexisten. Ninguna sustituye a las otras; cada una mide lo que las demás no pueden medir bien y deja sin medir lo que sí miden bien las demás.

Capa 1 — Heurísticos deterministas. Reglas que devuelven true o false sin ambigüedad: el output coincide con un regex, contiene una entidad concreta, no excede una longitud, sigue un esquema JSON válido, respeta un formato pedido (markdown, función tool_call, citación obligatoria). Son baratos, rapidísimos, no necesitan judge ni embeddings, y atrapan el tipo de bug más frecuente: el modelo respondió en el formato equivocado. Su límite es obvio — no saben si la respuesta es correcta, sólo si es bien formada.

Capa 2 — Métricas semánticas con embeddings. Comparan el output del modelo con una respuesta esperada calculando similitud coseno entre sus embeddings, o midiendo si una afirmación del output está implicada por el contexto recuperado. Son baratos, deterministas dado el modelo de embedding, y muy útiles para detectar respuestas que se desvían en sentido pero no en forma. Su límite también es claro: dos respuestas pueden tener alto coseno y decir lo contrario una de otra (“el cliente puede cancelar en cualquier momento” vs “el cliente no puede cancelar en cualquier momento” comparten 80% de tokens).

Capa 3 — LLM-as-judge. Un modelo —o un ensemble— evalúa el output del modelo bajo prueba con un prompt diseñado para producir un score en una rúbrica. Los métodos canónicos en 2026 son G-Eval (chain-of-thought prompting con score numérico calibrado), Prometheus (judge open-source entrenado específicamente para evals, reporta correlación 0.897 con humanos en su release v2.5 de finales de 2025), y los panel-of-judges que promedian votos de tres modelos heterogéneos para reducir sesgo. Esta capa captura matices que las dos anteriores no ven: ¿es fiel al contexto? ¿es útil? ¿es seguro? ¿está completo? Su límite es el coste y la necesidad de calibración —tratada como sección entera más abajo—.

Capa 4 — Humanos. Anotadores formados que evalúan una muestra del eval set, no toda. Son la única capa con autoridad última sobre la rúbrica: el judge LLM se calibra contra ellos, no al revés. Son caros (≈ 0,50–2,00 € por muestra anotada cuando el dominio es técnico) y lentos (un anotador competente hace 60–120 anotaciones de calidad por jornada). El error que los equipos cometen una y otra vez es prescindir de esta capa “porque tenemos judge LLM”; sin humanos, no hay calibración, y sin calibración el judge mide lo que le da la gana.

La operación normal de un eval gate combina las cuatro: heurísticos eliminan los outputs malformados antes de gastar judge, los embeddings filtran lo manifiestamente irrelevante, el judge puntúa el resto, y los humanos anotan una muestra cada N runs para mantener el judge calibrado.

El golden dataset: temario versionado

El golden dataset es el artefacto más infravalorado del pipeline. Es el examen. Si está mal construido, todo lo demás —el judge mejor calibrado del mundo, los gates más estrictos, la suite más rápida— mide ruido. Cubierto a primer nivel en el post de data versioning como uno de los cuatro artefactos a versionar diferenciadamente; aquí entramos al detalle desde la perspectiva de Eval.

Las tres propiedades que un golden dataset tiene que cumplir son:

Representatividad estratificada. El dataset tiene que cubrir el espacio real de inputs del sistema en proporciones que reflejen producción. Si el 30% del tráfico real es en alemán, el 30% del golden tiene que ser en alemán; si el 12% de las preguntas son sobre cancelación de suscripción, esa categoría no puede ser el 60% del eval set sólo porque era fácil de anotar. La estratificación se mantiene auditable: cada ejemplo lleva tags (lang=de, category=cancellation, tenant_type=enterprise, difficulty=hard) y la suite reporta métricas por segmento, no sólo el agregado.

Holdout estricto, no contaminación con training. Esta regla es tan obvia que casi todos los equipos creen que la cumplen, y casi todos la rompen sin darse cuenta. Si el golden eval set se mezcla con el dataset de fine-tuning —porque alguien hizo un random_split mal hecho, porque un dataset comprado lo usa para entrenar otros vendors, porque el judge LLM lo vio durante su pretraining— la métrica deja de medir generalización y pasa a medir memorización. El hash del eval set se versiona aparte (cubierto en el post de fine-tuning continuo) y se ejecuta un check rutinario de leakage: si un ejemplo del golden coincide token-a-token con uno del training, alerta.

Sample size razonado, no aspiracional. ¿Cuántos ejemplos hacen falta? Hay un mínimo matemático para distinguir dos modelos con confianza. Si el modelo A acierta el 80% y el modelo B el 85% sobre el mismo set, el intervalo de confianza al 95% para esa diferencia de proporciones (sin pareo) es:

[ \Delta p \pm 1{,}96 \cdot \sqrt{\frac{p_A(1-p_A) + p_B(1-p_B)}{n}} ]

Para distinguir 80% vs 85% con confianza 95% (intervalo que no cruce cero), necesitas n ≈ 700 ejemplos. Para distinguir 90% vs 91% bajo el mismo criterio, el cálculo da n ≈ 6.500. Los “tenemos 50 ejemplos en el golden y vemos que el adapter v8 saca 90%” no significan nada estadísticamente: el intervalo de confianza es ±8 puntos. La regla práctica del campo en 2026 es mínimo 300 ejemplos para detectar diferencias gruesas, idealmente 500–1.500 si quieres detectar mejoras finas, y empezar por estratificar bien antes de obsesionarse con sample size.

A esto se suma el mantenimiento activo: el golden se enriquece con los incidentes de producción (cubierto en detalle en el post de retrain), de manera que cada queja real terminada en bug se convierte en un ejemplo curado que el siguiente candidato a deploy tendrá que aprobar. El golden no es estático: es un registro vivo de errores que el sistema ya ha cometido y no debe volver a cometer.

LLM-as-judge: cómo se calibra un examinador

La capa 3 es la que más equipos malusan. El error típico es: “usamos GPT-4 como judge porque es el más capaz”. El judge no se elige por capacidad nominal; se elige por agreement con los humanos sobre la rúbrica concreta que estás midiendo. Un judge con 60% agreement no sirve aunque sea GPT-5; un Prometheus 7B fine-tuneado para tu dominio con 88% agreement vale más.

La métrica estándar para medir agreement entre dos anotadores (humano vs judge, o dos humanos entre sí) es el kappa de Cohen, que corrige por el agreement esperado por azar:

[ \kappa = \frac{p_o - p_e}{1 - p_e} ]

donde (p_o) es la proporción de acuerdo observada y (p_e) es la proporción esperada por casualidad bajo las distribuciones marginales de cada anotador. Las interpretaciones aceptadas en la literatura son:

κ < 0,40: agreement pobre. El judge dice lo que le da la gana.
κ ∈ [0,40, 0,60]: moderado. Aceptable para señales gruesas (¿es tóxico?), pésimo para matices (¿es fiel al contexto?).
κ ∈ [0,60, 0,80]: substancial. Útil en producción para la mayoría de métricas.
κ > 0,80: casi perfecto. El judge se puede tratar como sustituto del humano para ese tipo de juicio concreto.

Numéricamente, considera una rúbrica binaria (faithful / not faithful) sobre 200 ejemplos anotados por humano y por judge. Si el humano dijo “faithful” en 150 casos y el judge en 140, y coinciden en 175 de los 200, entonces (p_o = 0{,}875); las marginales son (p_h = 0{,}75), (p_j = 0{,}70), y (p_e = 0{,}75 \cdot 0{,}70 + 0{,}25 \cdot 0{,}30 = 0{,}600). Kappa sale 0,6875: substancial pero no excelente — utilizable, con vigilancia sobre la rúbrica.

Calibrar el judge implica un proceso explícito:

Construir un calibration set — 100–300 ejemplos anotados por humanos formados, con guidelines escritas. La inter-anotador kappa entre los humanos también se mide; si los propios humanos no se ponen de acuerdo, la rúbrica está mal redactada antes de hablar de judge.
Iterar el prompt del judge hasta que el judge agreement con los humanos supere el umbral aceptado (típicamente κ ≥ 0,7 para métricas sensibles).
Fijar la versión del judge (claude-3-5-sonnet-20251022, gpt-4o-2024-11, prometheus-2-7b@sha256:…): cualquier cambio invalida la calibración.
Re-calibrar periódicamente — cada vez que cambia el judge, el prompt del judge, o la rúbrica. La frecuencia recomendada por el campo en 2026 es trimestral mínimo, mensual si la rúbrica es nueva.
Persistir todo en lineage — un score “faithfulness 0,87” sin trazabilidad de qué judge, qué prompt, qué calibration set y qué humano lo validó, es decorativo.

El post sobre prompt versioning cubre cómo se materializa el versionado del prompt del judge. La consecuencia práctica es que el judge se versiona como cualquier otro modelo: tu eval suite tiene judge_id = prometheus-2.5@v3 igual que tiene adapter_id = customer_support_v7.

Las dos cadencias: CI gate y platform regression

Las suites de eval viven en dos sitios y se ejecutan con dos cadencias distintas. Los equipos que confunden ambas convierten una de las dos en teatro.

CI gate (pre-merge, bloqueante). Se ejecuta en cada pull request que modifica prompts, adapters, configuración de RAG, o cualquier artefacto que pueda mover la salida del modelo. Se ejecuta contra el golden dataset versionado al hash que está en main. El gate falla el merge si:

la métrica crítica cae más de X puntos porcentuales absolutos respecto al baseline (típicamente X = 2);
alguna métrica de seguridad (toxicidad, leakage de PII) cruza un umbral duro (típicamente tox > 0,02);
algún segmento estratégico (un idioma, un tenant tipo enterprise) cae más de Y puntos aunque el agregado mejore.

Esta cadencia tiene que ser rápida (idealmente < 10 minutos sobre 500 ejemplos) y barata (judge LLM batch-mode, embeddings cacheados, heurísticos en local). El CI gate no es exhaustivo: es la línea de defensa baja-latencia.

Platform regression (post-deploy, continua). Se ejecuta de manera programada (típicamente nightly o weekly) sobre tráfico de producción muestreado, no sobre el golden estático. Detecta drift: el modelo no ha cambiado, el golden no ha cambiado, pero los usuarios sí han cambiado, y la calidad sobre tráfico real cae. Esta cadencia es más cara (judge sobre miles de samples, anotación humana sobre cientos), tolera latencias de horas, y su consumidor principal no es CI sino el dashboard de observabilidad y los humanos del equipo de producto que deciden si abrir un ciclo de retrain.

Ambas cadencias persisten resultados en el mismo store (Langfuse, MLflow, o equivalente) y los conectan por model_id, prompt_id, dataset_hash y judge_id. Sin ese pegamento de identificadores, la métrica que pasa CI no se puede correlacionar con la que falla en producción tres semanas después.

Las matemáticas mínimas que importan

Más allá del kappa y del intervalo para la diferencia de proporciones —los dos ya cubiertos arriba— hay otras tres piezas matemáticas que cualquier equipo que opere evals en serio acaba usando.

Intervalo de confianza para una métrica continua. Si tu métrica es un score continuo (faithfulness ∈ [0, 1]) y mides la media muestral (\bar{x}) sobre n ejemplos con desviación s, el intervalo de confianza al 95% para la media poblacional es:

[ \bar{x} \pm 1{,}96 \cdot \frac{s}{\sqrt{n}} ]

Para n = 300 y s ≈ 0,2 (típico de un score 0-1 con varianza no degenerada), el margen es ±0,023. Esto significa que diferencias por debajo de 2 puntos centesimales no se distinguen del ruido con ese sample size. Si tu equipo persigue mejoras de “+0,5 pp” sobre 100 ejemplos, está optimizando ruido.

Coste del judge en función del sample size y la rúbrica. El coste de una pasada de eval con LLM-as-judge sobre n ejemplos, con m métricas evaluadas en una sola llamada por ejemplo, y precio por token (c_{in}, c_{out}) en el modelo judge, es:

[ C \approx n \cdot (t_{in} \cdot c_{in} + t_{out} \cdot c_{out}) ]

donde (t_{in}) es el número de tokens de entrada (incluye contexto, output del modelo bajo prueba, rúbrica completa) y (t_{out}) el de salida (incluye CoT del judge + score). Para n = 500, (t_{in}) ≈ 4.000, (t_{out}) ≈ 300, judge GPT-4o con precios de mayo 2026, una pasada cuesta del orden de 8–15 USD por suite. Si la pasada se dispara en cada PR y hay 30 PRs/día, son 240–450 USD/día sólo en CI gates. Multiplicado por la regression continua, los equipos que no controlan esto se gastan cuatro cifras al mes en judge sin darse cuenta. La mitigación canónica es mezcla de capas: heurísticos y embeddings filtran primero, judge sólo se invoca sobre lo que las capas baratas no pueden resolver, y para platform regression se usa un judge open-source self-hosted (Prometheus 7B sobre el plano GPU propio) en lugar de un modelo comercial.

Distinción entre métrica agregada y métrica por segmento. La falacia clásica del eval es la media oculta. Si tu suite reporta faithfulness = 0,87 y el equipo lo lee como “sube 2 puntos respecto al adapter anterior”, puede estar pasando esto: el adapter nuevo sube 4 puntos en inglés (donde está el 70% del eval set) y baja 6 puntos en alemán (donde está el 30%). La media agregada mejora, la experiencia en alemán empeora. Cualquier suite seria reporta breakdown por segmento estratégico (idioma, tipo de tenant, categoría de pregunta, longitud del contexto). El gate de CI también puede tener thresholds por segmento, no sólo agregados.

El stack 2026: herramientas dominantes

Herramienta	Capa principal	Licencia	Mantenedor	Cuándo elegirla
DeepEval	CI gate	Apache 2.0	Confident AI	“Evals como pytest” — assertions en código Python, integración trivial con GitHub Actions. Default razonable.
Promptfoo	CI gate	MIT	Promptfoo Inc.	YAML declarativo, matriz prompts × providers × assertions, diff vs baseline. DevOps-friendly.
RAGAS	Métricas RAG-specific	Apache 2.0	Exploding Gradients	Faithfulness, context relevancy, answer relevancy. La pieza canónica si tu sistema es RAG.
Inspect AI	Safety/capability evals	MIT	UK AI Safety Institute	Suite con foco en safety y capability. Útil para gates regulatorios bajo EU AI Act.
Langfuse Evals	Platform regression	MIT (OSS) / EE	Langfuse GmbH	Integrado con tracing — datasets, runs y scores en la misma UI que las trazas de producción.
MLflow GenAI Evals	Registry + evals	Apache 2.0	Databricks/LF AI	Bueno cuando ya tienes MLflow para modelos clásicos; “GenAI dashboard” desde 3.10.
Phoenix (Arize)	Eval + drift visual	Elastic License 2.0	Arize AI	Foco en debugging visual de embeddings y drift; complemento, no sustituto, de Langfuse.
Prometheus 2.5	Judge OSS self-hosted	Apache 2.0	KAIST + LG AI	Judge fine-tuneado, alta correlación con GPT-4 a coste cero por token cuando se hostea.
G-Eval / JudgeLM	Métodos de prompting	— (técnicas)	académica	Frameworks de prompting para LLM-as-judge — se aplican sobre cualquier modelo judge.

El catálogo OSS por etapas entra al detalle ficha-a-ficha; el catálogo paralelo OSS vs hyperscalers compara con Bedrock Evaluations, Vertex AI Eval Service y Azure AI Evaluation.

El patrón canónico en 2026 es híbrido: DeepEval o Promptfoo para CI gates + Langfuse Evals para platform regression + Prometheus 2.5 como judge self-hosted + anotación humana sobre Argilla o Label Studio para el calibration set. Sustituir cualquiera de estos pilares por equivalentes (W&B Weave en lugar de Langfuse, Inspect en lugar de DeepEval) es estilo, no funcionalidad — lo importante es que las cuatro funciones estén presentes y conectadas.

Aplicado a hardware on-premise típico

Para un despliegue on-premise que quiera evitar enviar outputs sensibles a un judge LLM comercial (por soberanía de datos, ENS, NIS2 o equivalentes), el judge se hostea sobre el propio plano GPU. Las cifras de referencia para mayo 2026, sobre la base de Prometheus 2.5 (Llama-3.1-8B fine-tuneado como judge) servido en vLLM:

RTX 4090 (24 GB, Ada Lovelace): viable para suites pequeñas (< 200 ejemplos) y para correr el judge en modo offline durante desarrollo. Latencia por evaluación ≈ 1,5–3 s con BF16; throughput agregado del orden de 25–40 evaluations/min con batching. Útil para CI gates locales del desarrollador, no para platform regression.
Configuración genérica 4×H100 SXM (320 GB total, NVLink): ejecuta el judge en paralelo en TP=2 sobre dos GPUs, dejando dos libres para servir el modelo bajo prueba. Throughput agregado del orden de 200–350 evaluations/min, suite completa de 500 ejemplos en 2–3 min. Esto permite gates de PR sin esperas perceptibles y platform regression nightly sobre miles de samples sin coste por token.

Las cuentas del coste comparado son tozudas: hostear Prometheus 2.5 amortiza una H100 en aproximadamente 6 meses si el equipo dispara ≥ 30 PRs/día con gates de eval. Por debajo de ese volumen, el judge comercial sigue ganando salvo que la soberanía sea requisito —y en ENS / NIS2 lo es—.

Las siete trampas que matan esta etapa

Trampa 1 — Golden dataset envejecido. No se enriquece con incidentes de producción. Al cabo de meses, mide un mundo que ya no existe. La métrica sube tranquilamente mientras los usuarios reales se quejan más.

Trampa 2 — Judge contaminado o no calibrado. El judge LLM evalúa con criterios que se inventa él. Sin calibration set humano de referencia, no hay forma de saber si su 0,89 es generoso, severo o aleatorio.

Trampa 3 — Sample size insuficiente. Suite de 50 ejemplos, diferencias de 1 punto que el equipo trata como significativas. El intervalo de confianza es ±10 puntos. Están midiendo ruido y tomando decisiones reales sobre él.

Trampa 4 — Coste runaway. Judge con GPT-4 batch-mode disparado en cada PR sobre 1.000 ejemplos, sin filtrado previo con capas baratas. La factura del eval pasa la del serving en producción. Ocurre con más frecuencia de la que se admite.

Trampa 5 — Métrica agregada que oculta segmentos. Media global mejora 2 puntos, alemán cae 6, tenants enterprise caen 3. Sin breakdown explícito por segmento, el gate aprueba lo que no debería.

Trampa 6 — Judge con versión flotante. Modelo judge actualizado sin recalibrar la rúbrica. Los thresholds pierden significado estadístico. Las regresiones del último mes no son comparables con las de hace dos.

Trampa 7 — Eval gate que no se aplica. El gate existe en la documentación pero no en el workflow real: la suite tarda 30 minutos, los desarrolladores la skippean con --no-verify, los managers piden excepciones puntuales que se vuelven la norma. El eval gate sin aplicación es ornamento.

Las siete son operacionales, no técnicas. La capa de Eval no se rompe porque las matemáticas estén mal: se rompe porque la disciplina se relaja. Es lo mismo que ocurre con los tests unitarios en cualquier proyecto que crece — sólo que aquí, sin la disciplina, el sistema mejora sus métricas mientras empeora, y eso convierte la degradación en invisible hasta que ya es ingobernable.

Lo que no hemos cubierto (próximos posts)

Guardrails y safety online: la capa de eval inline que filtra outputs en tiempo real, no en CI. Conceptualmente prima de Eval, pero con restricciones de latencia muy distintas. Cubierto en el post sobre guardrails cuando se publique.
Judge ensembles y agreement entre múltiples judges: cómo reducir sesgo combinando tres modelos heterogéneos como panel, qué función de agregación funciona (mayoría simple, media trimmed, judge calibrado meta-judge).
Meta-eval: cómo se evalúa la propia suite. Si el eval mejora del adapter v7 al v8 no se traduce en mejora real para el usuario, la suite está mal — y eso también se mide, con correlación métrica-eval vs métricas-producto.
Metamorphic testing: evaluar robustez frente a perturbaciones del input (typos, paraphrasing, idioma alternativo) como gate adicional. Más allá del agreement nominal, mide consistency.
Evals adversariales con red teaming: introducir ataques de prompt injection y jailbreak como parte del gate.
Privacidad en el judge: cómo evitar que outputs sensibles del modelo bajo prueba viajen a un judge externo cuando la regulación lo prohíbe — judge homomorphic, judge en TEE, o sencillamente judge self-hosted.

Ver también

El pipeline LLMOps de seis etapas — el mapa maestro donde Eval encaja entre Tune y Deploy. La sección “Etapa 3 — Eval” da el resumen estructurado que este post desarrolla.
Anatomía de una petición LLM en producción, mayo 2026 — el tour forense de una request que cruza las seis etapas; el momento en que se invoca la suite de evals para promocionar el adapter v7→v8 es la materialización del gate descrito aquí.
Prompt versioning: el contrato que evita que un cambio de cinco palabras hunda tu sistema — los prompts del judge se versionan con los mismos mecanismos que cualquier otro prompt. El prompt_id viaja en lineage.
Data versioning: DVC, lakeFS y el reto del golden dataset reproducible — el golden eval set es uno de los cuatro artefactos a versionar diferenciadamente. Sin holdout estricto, la métrica mide memorización.
Fine-tuning continuo en producción — las eval gates que en aquel post aparecen como predicados SQL son la materialización concreta del framework descrito aquí.
Retrain: cerrar el bucle entre el incidente en producción y el adapter que lo arregla — el golden se enriquece con incidentes que vienen del bucle Retrain; sin ese flujo el dataset envejece y las trampas 1 y 5 se activan solas.
El catálogo OSS para LLMOps en seis etapas — fichas ficha-a-ficha de DeepEval, Promptfoo, RAGAS, Langfuse, Phoenix.
El catálogo paralelo: OSS vs AWS / GCP / Azure — cómo se traduce la etapa Eval a Bedrock Evaluations, Vertex AI Eval Service y Azure AI Evaluation.

Referencias

G-Eval: Liu et al., “G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment” — el paper de referencia del método de judge LLM con chain-of-thought.
Prometheus: Kim et al., “Prometheus 2: An Open Source Language Model Specialized in Evaluating Other Language Models” — judge OSS con correlación reportada 0.897 vs humanos.
RAGAS: Es et al., “RAGAS: Automated Evaluation of Retrieval Augmented Generation” — el paper que estandariza faithfulness, context relevancy y answer relevancy.
Cohen’s kappa: Cohen, J. (1960). “A Coefficient of Agreement for Nominal Scales.” Educational and Psychological Measurement — la métrica clásica para inter-anotador agreement, todavía la referencia operativa.
DeepEval docs: https://docs.confident-ai.com/
Promptfoo docs: https://promptfoo.dev/docs/
Langfuse Evals: https://langfuse.com/docs/scores
Inspect AI: https://inspect.ai-safety-institute.org.uk/
EU AI Act, artículos relevantes sobre evaluación obligatoria de sistemas de alto riesgo — pendiente de publicación de los technical standards de CEN/CENELEC sobre conformity assessment para GenAI.

Promptfoo on lo0 — Blog Técnico