Evaluación y mejora continua

🔄 En la lección anterior diseñaste prompts de tres capas y citaciones para prevenir alucinaciones. Pero hay un problema: ¿cómo sabes si tu sistema RAG es bueno? Sin métricas, estás volando a ciegas.

“Funciona bien” no es una métrica. “Los usuarios no se quejan” tampoco. Necesitas números.

Lo que aprenderás

Al terminar esta lección sabrás cómo medir la calidad de tu RAG con el framework RAGAS, cómo evaluarlo específicamente en español y cómo monitorear degradación en producción.

Las cuatro métricas que importan

El framework RAGAS (Retrieval Augmented Generation Assessment) define las métricas estándar para evaluar sistemas RAG. No necesitas inventar las tuyas.

Cómo se relacionan

Consulta del usuario
    ↓
Recuperación → Context Precision (¿trajo lo relevante?)
             → Context Recall (¿trajo todo lo necesario?)
    ↓
Generación → Faithfulness (¿se basó en el contexto?)
           → Answer Relevancy (¿contestó la pregunta?)

Si faithfulness es alta pero relevancy es baja: el modelo es fiel al contexto pero el contexto es irrelevante. Problema de recuperación.

Si relevancy es alta pero faithfulness es baja: la respuesta contesta bien la pregunta pero inventa datos. Problema de generación.

Implementación con RAGAS

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall
)

# Preparar dataset de evaluación
eval_data = {
    "question": ["¿Cuál es el plazo de devolución?"],
    "answer": ["El plazo es de 30 días naturales."],
    "contexts": [["El plazo máximo para devoluciones es de 30 días..."]],
    "ground_truth": ["30 días naturales desde la compra."]
}

results = evaluate(
    dataset=eval_data,
    metrics=[faithfulness, answer_relevancy,
             context_precision, context_recall]
)

print(results)
# {'faithfulness': 0.95, 'answer_relevancy': 0.88,
#  'context_precision': 0.82, 'context_recall': 0.79}

El ground_truth es la respuesta correcta que tú defines. Sin él, no puedes calcular context recall.

✅ Quick Check: Tu sistema tiene context precision de 0.90 pero context recall de 0.40. ¿Qué significa? (Los fragmentos que recuperas son relevantes (precision alta), pero faltan fragmentos importantes (recall bajo). Estás trayendo pocos documentos — probablemente necesitas aumentar el top-K de tu búsqueda o mejorar la cobertura de tu base de conocimiento.)

Construir un dataset de evaluación

Las métricas son tan buenas como tu dataset de evaluación. Un dataset malo te da métricas engañosas.

Estructura del dataset

Cuántas preguntas necesitas

Fuentes de preguntas:

1. Logs reales — Consultas que los usuarios ya hicieron (la mejor fuente)
2. Equipo de soporte — Preguntas frecuentes que reciben
3. Generación sintética — Un LLM genera preguntas a partir de los documentos (para arrancar rápido)

La generación sintética sirve para empezar, pero reemplázala gradualmente con preguntas reales.

Evaluación en español

Evaluar RAG en español tiene desafíos que no existen en inglés.

Problemas específicos

1. Alineación cross-lingual — Si tus documentos mezclan español e inglés, los embeddings pueden perder matices. Un documento sobre “machine learning” debería recuperarse con la consulta “aprendizaje automático.”

2. Variaciones regionales — “Computadora” (México), “ordenador” (España), “computador” (Colombia). Tu sistema necesita manejar todas.

3. Artefactos de traducción — Los LLMs a veces generan respuestas con sintaxis de inglés traducida: “Esto es debido a que…” en lugar de “Esto se debe a que…”

Datasets en español

El proyecto #Somos600M del BSC (Barcelona Supercomputing Center) impulsa la evaluación de NLP en español. Recursos:

• RagQuAS — Dataset de evaluación RAG con preguntas en español nativo (no traducidas del inglés)
• SQAC — Spanish Question Answering Corpus con contextos de Wikipedia
• Custom — Siempre complementa con preguntas de tu dominio específico

Checklist de evaluación para español

EVALUACIÓN ESPAÑOL:
- [ ] ¿El sistema recupera documentos correctos con consultas coloquiales?
      ("¿cómo devuelvo algo?" vs "procedimiento de devolución")
- [ ] ¿Maneja mezcla de idiomas en documentos?
      (docs con términos en inglés + consultas en español)
- [ ] ¿Las respuestas son en español natural, sin artefactos?
- [ ] ¿Funciona con variaciones regionales?
      ("carro"/"coche"/"auto" deberían dar resultados similares)

✅ Quick Check: ¿Por qué no basta con traducir un dataset de evaluación del inglés al español? (Porque las preguntas traducidas no reflejan cómo los hispanohablantes realmente formulan consultas. Un nativo pregunta “¿cómo devuelvo algo?” no “¿cuál es el procedimiento para efectuar una devolución?” Los patrones de búsqueda, el vocabulario coloquial y las variaciones regionales son diferentes.)

Monitoreo en producción

Evaluar una vez no es suficiente. Los sistemas RAG se degradan con el tiempo.

Por qué se degradan

Dashboard mínimo de producción

Monitorea estos indicadores semanalmente:

MÉTRICAS DE PRODUCCIÓN:
1. Tasa de "no tengo información"     → Target: 5-15%
   (muy baja = posible alucinación, muy alta = base incompleta)

2. Compliance de citaciones           → Target: > 85%
   (si baja, el prompt de sistema necesita ajuste)

3. Latencia p95                       → Target: < 3 segundos
   (incluye embedding + búsqueda + generación)

4. Feedback de usuarios               → Thumbs up/down ratio
   (la métrica más directa pero más ruidosa)

El problema de los embeddings obsoletos

Cuando actualizas documentos, los embeddings antiguos siguen en la base vectorial. Si la “Política de devoluciones v2” reemplaza a “v1” pero no regeneras los embeddings, el sistema puede recuperar fragmentos de la versión anterior.

Solución: Cada actualización de documentos debe disparar re-ingestión: parseo → chunking → embedding → reemplazo en la base vectorial.

Puntos clave

• RAGAS proporciona las cuatro métricas estándar: faithfulness, answer relevancy, context precision y context recall
• Faithfulness alta + relevancy baja = problema de recuperación. Relevancy alta + faithfulness baja = problema de generación
• Evaluar en español requiere datasets nativos (no traducidos) y verificar alineación cross-lingual, variaciones regionales y artefactos de traducción
• El monitoreo en producción es obligatorio: los sistemas RAG se degradan por documentos obsoletos, drift de consultas y crecimiento de la base
• Un buen dashboard mínimo: tasa de “no sé”, compliance de citaciones, latencia p95 y feedback de usuarios

Siguiente lección

Ya sabes cómo construir, evaluar y monitorear un RAG. En la última lección: proyecto final — construyes un sistema RAG completo de principio a fin, y exploras el futuro: GraphRAG, RAG agéntico y las tendencias que vienen.