2026-09-21 — Mejores prácticas de evaluación LLM + RAG

Fuentes: los dos exports en second-brain/data/exports/ (investigación sobre ML Test Score / testing de DeepSeek / resiliencia de producto, y estado del arte de evals 2023–2026), más lo hablado en esta sesión sobre RAG, retrieval y MLOps. Los exports cubren LLM a fondo y RAG apenas de pasada: la parte RAG de abajo la completé con el resto de la sesión.

Principio rector

Las evals de LLM son pruebas de regresión estadísticas, no binarias: versionadas en el repo, corridas en CI ante cada cambio de prompt/modelo, con intervalos de confianza y umbrales de bloqueo. El mapeo desde QA clásico es directo: Cypress → promptfoo/DeepEval/Inspect, asserts binarios → intervalos, seguridad manual → Garak/PyRIT.

1. Suite de evaluación (estructura)

1. Casos dorados propios (20–30 para empezar): entradas con salida esperada de TU producto, no del leaderboard.
2. Adversariales: límite, ambigüedad, inyección de prompt.
3. Metamórficas/invariancia: la salida no debe cambiar bajo parafraseo u orden distinto (CheckList).
4. Validación de esquema: si esperas JSON, falla si no cumple.
5. N corridas (5–10) por caso: reporta tasa de aprobación, no booleano. Umbral inicial razonable: pasa si ≥90% de corridas cumplen.
6. LLM-as-judge solo para calidad subjetiva, nunca para hechos verificables (esos van con assert duro).

2. Estadística (el punto que casi todos ignoran)

Del paper de Anthropic “Adding Error Bars to Evals” (arXiv 2411.00640):

• Errores estándar vía CLT; clusterizar si las preguntas vienen agrupadas (los errores clusterizados pueden ser hasta 3× mayores → los IC publicados suelen ser demasiado estrechos).
• Comparaciones pareadas al comparar dos modelos/prompts (reduce error gratis).
• Análisis de potencia: decide cuántos casos necesitas antes de correr.
• pass@k (al menos un éxito en k) vs pass^k (todos los k exitosos): el segundo es el relevante para confiabilidad.
• Dato duro: solo 16% de 445 benchmarks revisados hacían algún test estadístico (arXiv 2511.04703). Sin barras de error, una diferencia de 2 puntos es ruido.

3. No determinismo (cómo convivir con él)

• Temperatura 0 reduce varianza pero no garantiza idénticas salidas; la causa principal es la dependencia del tamaño de lote (batch invariance en kernels). Con vLLM se puede fijar (VLLM_BATCH_INVARIANT=1, GPU ≥8.0) a costo de ~1.6–2× latencia.
• Fija: versión de pesos (hash), cuantización, motor de inferencia, CUDA, tokenizer. Por API: versión explícita, temperature, top_p, seed.
• Canario de modelo: 10–15 prompts fijos corridos a diario; si la métrica se mueve sin cambios tuyos, el proveedor cambió algo (el “mismo” modelo cambia: GPT-4 marzo vs junio 2023; sicofancia de GPT-4o abril 2025).

4. LLM-as-judge: sesgos y mitigaciones

Sesgos documentados: position, verbosity/length, self-preference (~10% en GPT-4), family bias. Mitigación: randomizar orden, enmascarar identidades, normalizar longitud, usar juez de otra familia, validar contra etiquetas humanas periódicamente (Cohen’s κ).

5. Evaluación de RAG (completado en esta sesión)

Mide retrieval y generación por separado — es el error #1. Un fallo de respuesta puede ser fallo de retrieval o de síntesis, y se arreglan distinto.

Retrieval (con golden set de queries → documentos relevantes):

• recall@k (target >0.9 en top-20), precision@k, MRR, nDCG@k.
• Anthropic mide 1 − recall@20 (“retrieval failure rate”) y así demostró que contextual retrieval baja fallos 35%, +BM25 contextual 49%, +rerank 67%.
• Ablations obligatorias sobre el golden set: chunking, denso vs híbrido (BM25+dense+RRF), reranker on/off. Cada cambio de pipeline corre el set.

Generación (groundedness):

• Faithfulness: ¿cada afirmación está sostenida por el contexto recuperado? Juez LLM con el pasaje enfrente, validado contra humanos.
• Citation accuracy: que el pasaje citado realmente sostenga la afirmación. Con Claude Citations API los punteros son exactos por construcción (carácter/página/bloque) — úsala antes de inventar tu propio esquema.
• Answer relevance y completeness contra una respuesta de referencia.

Herramientas: Ragas (tríada clásica: context relevance, faithfulness, answer relevance), ARES, TruLens. Para el juez, mismas mitigaciones que §4.

Producción:

• Log por query: IDs recuperados + scores + respuesta + feedback (thumb). Sin esto no hay diagnóstico.
• Set canario diario contra el índice vivo (detecta drift de datos y de modelo).
• Prompt injection es superficie de ataque de RAG: los documentos recuperados pueden traer instrucciones. Pruebas tipo AgentDojo (utilidad y seguridad medidas juntas).

6. Seguridad (cuando aplique)

• Barrido: Garak (probes conocidos) → profundidad: PyRIT (multi-turno adaptativo) → regresión: promptfoo (cada hallazgo se vuelve test).
• Contenido dañino: StrongREJECT (mide voluntad + capacidad, no refusals vacíos). Jailbreaks “99% éxito” suelen ser humo.
• Ojo con la evaluation awareness (los modelos detectan que se les evalúa): cualquier eval de seguridad puede sobreestimar alineación.

7. NO (anti-patrones)

• NO una sola corrida por caso; NO sin intervalos de confianza.
• NO un solo leaderboard como verdad (Leaderboard Illusion: testing privado, duplicados hasta 26.5%).
• NO juez LLM para hechos verificables.
• NO confundir retrieval failure con generation failure en RAG.
• NO evaluar solo pre-lanzamiento: la deriva se detecta monitoreando.
• NO tratar la sicofancia (o cualquier deriva de comportamiento) como detalle estético: es launch-blocking (postmortem de GPT-4o: “no teníamos evals específicas rastreando sicofancia”).
• NO asumir que el proveedor no cambia nada: el postmortem de Anthropic (ago–sep 2025) muestra tres bugs de infraestructura degradando calidad con evals propias que no los capturaban.

8. Stack mínimo para adoptar ya

1. promptfoo (o DeepEval) con 20–30 casos dorados en YAML, en CI.
2. N=5–10 corridas por caso; umbral ≥90%; reportar IC.
3. Canario de modelo diario (10–15 prompts fijos).
4. Si hay RAG: golden set queries→docs + Ragas + log de retrieved IDs.
5. Un postmortem por incidente, sin culpa.

9. Aplicado a los proyectos de Nef

• second-brain: npm run review + rutas learn ya son el embrión de un golden set de estudio; el equivalente a evals sería fijar un set de nodos vencidos y verificar que el recall programado no se rompe al cambiar lib/.
• distributed-fraud-mvp: ya tiene split fijo + suite de métricas; añadir varianza (N corridas de los modelos con distinta seed) y, si Gemma entra, canario de modelo. El caveat temporal del dataset es la versión tabular de “medir lo que importa”.
• research assistant futuro (papers): aquí aplica TODO lo de §5 — tríada RAG, golden set, ablations de chunking/rerank, citations exactas, injection vía documentos. Es el proyecto donde estas prácticas son el producto, no un extra.