Evaluación, KPIs y plan de piloto
Cómo saber si tu RAG funciona con números, cómo tablearlo y cómo probarlo en el mundo real sin arriesgar a nadie.
Evaluación de RAG: gold sets y métricas
Al terminar esta sesión podrás
- Explicar por qué evaluar un RAG no es lo mismo que evaluar un clasificador: hay dos etapas encadenadas.
- Construir un gold set pequeño y reconocer sus riesgos (sesgo, fuga, facilidad).
- Calcular e interpretar Precision@k, Recall@k, Hit Rate y MRR.
- Definir groundedness/faithfulness y conectarla con el SLA "groundedness ≥ 95%".
Un clasificador tiene una respuesta; un RAG tiene una cadena
Cuando evalúas un clasificador de spam hay una decisión (spam o no) y una verdad de referencia: comparas, cuentas aciertos y listo. Un RAG, en cambio, es una tubería de dos etapas. Primero la recuperación: dada la pregunta, el sistema busca en el corpus y devuelve los k fragmentos que cree relevantes. Después la generación: el LLM lee esos fragmentos y redacta la respuesta. Cada etapa puede fallar por su cuenta, y una respuesta mala no te dice cuál falló. Por eso se evalúan por separado.
Las cuatro combinaciones y el "falso éxito"
Piensa en cada consulta como el cruce de dos preguntas sí/no: ¿recuperó bien? y ¿respondió bien?
| Respondió bien | Respondió mal | |
|---|---|---|
| Recuperó bien | Caso ideal | Tenía el material y aun así falló: problema del generador (mal prompt, modelo flojo, ignoró el contexto) |
| Recuperó mal | "Acertó por suerte" o de memoria: peligroso, no es reproducible | Falló la recuperación; el generador no tenía con qué |
El cuadrante "recuperó mal pero respondió bien" es el más traicionero: parece éxito, pero el sistema acertó a pesar de su recuperación, no gracias a ella. Sobre datos nuevos, en producción, eso colapsa.
El gold set: la hoja de respuestas del examen
Un gold set (conjunto de prueba) es una colección de preguntas representativas, cada una con su verdad de referencia. Esa verdad tiene dos piezas y conviene tener ambas: la respuesta correcta esperada (para evaluar la generación) y los chunks relevantes etiquetados (para evaluar la recuperación). Sin hoja de respuestas no estás evaluando: estás adivinando si el bot te cae bien.
Antes de medir nada, fija qué significa relevante: un chunk es relevante si contiene información necesaria para responder la pregunta, no solo si "toca el tema". Para el prototipo del curso bastan 20 a 50 preguntas bien construidas; diez preguntas trampa enseñan más que cien fáciles.
Sesgo de autor
Si escribes preguntas y respuestas con las mismas palabras del documento, el recuperador acierta fácil y te engañas. Redacta con el vocabulario del cliente.
Fuga (leakage)
Si usas el mismo gold set para afinar y para juzgar, mides cuánto se ajustó al examen, no si generaliza. Separa desarrollo de prueba.
Demasiado fácil
Todo directo, una sola fuente, vocabulario idéntico infla las notas. Mete casos multi-documento, sinónimos y "no contestables".
Métricas de recuperación: ¿trajo los documentos correctos?
El sistema devuelve una lista ordenada de k resultados (el top-k). Todas estas métricas comparan "lo que trajo" contra "lo que debía traer".
| Métrica | Qué responde | Fórmula |
|---|---|---|
| Precision@k | De lo que traje, ¿cuánto sirve? (¿cuánta basura se coló?) | relevantes en top-k / k |
| Recall@k | De todo lo relevante que existe, ¿cuánto traje? | relevantes en top-k / total de relevantes |
| Hit Rate | ¿Metí al menos un relevante en el top-k? | promedio de (1 si ≥1 relevante, si no 0) |
| MRR | ¿Qué tan arriba salió el primer acierto? | promedio de 1 / (posición del 1er relevante) |
Precision es qué tan limpio es lo que traje; Recall es qué tan completo. En servicio al cliente el Recall suele importar más: si el chunk con la respuesta no llega, el bot no puede responder bien aunque el LLM sea brillante.
Groundedness / faithfulness: la métrica reina de la generación
Aquí ya no juzgamos qué se trajo, sino qué se redactó con lo traído. La groundedness (o faithfulness) responde: ¿cada afirmación de la respuesta está respaldada por el contexto recuperado? Una respuesta es fiel si no inventa nada fuera de los chunks que se le dieron. Se calcula descomponiendo la respuesta en afirmaciones atómicas y verificando cuántas se deducen del contexto.
Es la reina en servicio al cliente porque una afirmación no respaldada es una alucinación potencial. Groundedness es la medición operacional de "el bot no inventa", y es exactamente el SLA "groundedness ≥ 95%" que vimos el Día 1. Junto a ella conviven la answer relevance (¿la respuesta contesta lo que se preguntó?) y el context precision/recall (calidad del contexto que recibió el generador).
Mueve el orden de los chunks recuperados y observa cómo cambian las cuatro métricas de recuperación al instante.
Precision, Recall, Hit Rate y MRR
Marca qué chunks del top-k son relevantes; el simulador recalcula las cuatro métricas y explica cada número.
Tablero de KPIs de servicio y de modelo
Al terminar esta sesión podrás
- Explicar por qué un tablero debe mezclar métricas de servicio con métricas del modelo/RAG.
- Diseñar un tablero mínimo viable en cuatro capas: operativos, experiencia, calidad del modelo y negocio.
- Calcular KPIs de negocio: costo por contacto, ahorro por deflexión y ROI.
Por qué un tablero mezcla las dos familias
El Día 1 dijimos: "puedes ser rapidísimo y barato y aún dejar al cliente furioso". Aquí aparece su gemelo. Si miras solo métricas de modelo ("precision@k = 0.9, groundedness = 97%") pero los clientes igual abandonan o el negocio no ahorra, el modelo "bueno" es un fracaso de servicio. Y si miras solo métricas de servicio ("contención 80%, CSAT 82%") pero el bot lo logra alucinando con seguridad, el tablero miente y la organización acumula riesgo legal.
Las métricas del modelo dicen si el bot tiene razón; las de servicio dicen si al cliente le sirvió y a la empresa le conviene. Un tablero honesto necesita las dos columnas abiertas al mismo tiempo.
El valor de cruzarlas es diagnóstico: cuando un KPI de servicio se mueve, el de modelo te dice por qué.
| Síntoma (servicio) | Causa probable (modelo/RAG) |
|---|---|
| FCR baja, recontactos altos | recall bajo o groundedness baja (responde sin fuente) |
| CSAT alto pero quejas y errores reales | groundedness baja con tono seguro: "alucinación cómoda" |
| Contención alta con CES alto (mucho esfuerzo) | el bot retiene pero hace dar vueltas: revisar diseño y fallback |
| Precision@k alta pero CSAT baja | recupera bien pero redacta frío o confuso: ajustar tono |
El tablero mínimo viable: cuatro capas
Para no abrumar, agrupamos los KPIs en cuatro capas, cada una con una pregunta.
Operativos
¿Es eficiente? Contención, escalación, FCR, FRT, AHT.
Experiencia
¿Gustó? CSAT del bot, CES, NPS (relacional, lento).
Modelo / RAG
¿Tiene razón? Groundedness, recall, precision@k, "no sé" apropiado.
Negocio / costo
¿Conviene? Costo por contacto, ahorro por deflexión, ROI.
Un tablero al que le falta una capa es un tablero tuerto. Cada KPI necesita definición cerrada, meta o SLA, dueño, fuente y frecuencia. Y ojo con los relojes: lo operativo es casi en vivo, el modelo se re-evalúa por release y por muestreo, el negocio es mensual y el NPS es trimestral. Empareja KPIs para evitar incentivos perversos: contención siempre junto a CSAT/CES, para que nadie suba contención "atrapando" clientes.
| Capa | KPI | Meta / SLA | Fuente | Frecuencia |
|---|---|---|---|---|
| Operativo | Contención / deflexión | ≥ 60% | logs del bot | diaria |
| Operativo | FCR del bot | ≥ 75% | logs + recontactos | semanal |
| Experiencia | CSAT del bot | ≥ 80% | encuesta post-chat | por interacción |
| Experiencia | CES ("fácil") | ≥ 75% | encuesta post-chat | por interacción |
| Modelo / RAG | Groundedness | ≥ 95% | gold set + muestreo | por release |
| Modelo / RAG | Recall (gold set) | ≥ 0.85 | gold set | por release |
| Negocio | Ahorro por deflexión | objetivo del caso | finanzas + logs | mensual |
| Negocio | ROI del chatbot | > 0 al horizonte | cálculo | mensual/anual |
KPIs de negocio: defender el chatbot en plata
Aquí se gana o se pierde la sala de directorio. El costo por contacto es el costo total del canal entre el número de contactos: un contacto humano cuesta varios soles o dólares, uno resuelto por el bot cuesta una fracción, y esa brecha es el motor del caso de negocio. El ahorro por deflexión multiplica esa brecha por los casos desviados, y el ROI compara beneficios contra costos en un horizonte.
Solo cuentan las deflexiones genuinas, no las "falsas resoluciones" donde el cliente se rindió. Deflexión sin calidad no es ahorro: es deuda. Por eso este KPI se cruza con CSAT/CES y groundedness. Con 6,000 contenidos de los que solo 5,400 son genuinos, contar los 6,000 infla el ahorro y esconde 600 clientes frustrados que recontactan por otro canal.
Diseña tu tablero y tu plan de piloto
Al terminar esta sesión podrás
- Definir al menos un KPI por cada una de las cuatro capas, con meta, fuente y dueño.
- Diseñar un piloto controlado con alcance, usuarios, duración y evidencias.
- Elegir un diseño de comparación (shadow mode, A/B o pre/post) y escribir criterios go/no-go.
Un tablero mide; un piloto decide. Antes de soltar el chatbot a toda la base de clientes se prueba en pequeño, con red de seguridad, y se decide con datos si avanza (go) o se detiene (no-go). Un piloto sin criterios de éxito definidos antes de empezar no es un experimento: es una apuesta a ciegas. Escribe el go/no-go el día cero.
Los tres diseños de comparación
Shadow mode
El bot responde en paralelo y en silencio; el cliente no lo ve, sigue atendiendo el humano. Valida calidad (groundedness, recall) con riesgo mínimo. Primer filtro.
A/B test
Divide usuarios al azar: grupo A (humano) y grupo B (bot), ambos en vivo. Mide el efecto causal sobre CSAT, CES, FCR y costo. Necesita volumen.
Pre/post
Compara los KPIs del mes antes del bot contra el mes con bot. Más débil (pudo cambiar otra cosa), pero útil cuando no se puede aleatorizar.
Shadow mode pregunta ¿el bot tendría razón? sin tocar al cliente. A/B pregunta ¿el bot mejora el servicio? tocando a la mitad. Hazlos en ese orden: primero seguro, luego en vivo.
Pasos del taller
- Ficha de KPIs. Con el caso de sector que vienes trabajando, define al menos un KPI por capa (operativo, experiencia, modelo, negocio) con su definición operacional, meta/SLA, fuente, frecuencia y dueño. Marca el par emparejado que evita el incentivo perverso (por ejemplo contención ↔ CES).
- Plan de piloto. Acota alcance (tema, canal, horario), selección de usuarios (inclusión y exclusión), duración (2 a 6 semanas), diseño de comparación y las evidencias que recolectas.
- Criterios go/no-go. Átalos a SLAs numéricos. Distingue los bloqueantes (groundedness < 95% o cualquier incidente grave = no-go inmediato) de los graduales (contención o CSAT por debajo del umbral = iterar, no cancelar).
- Esquema de evaluación. En media página, conecta en prosa: qué KPIs miras, con qué piloto los obtienes y qué decisión tomas según el resultado.
Abre la hoja del taller con las dos plantillas →
Tiempo del taller
Para los bloques en equipo: ficha, plan y puesta en común. Elige la duración e inicia.
Ya sabes juzgar tu RAG con números en dos etapas, tablearlo mezclando servicio y modelo, y probarlo con un piloto controlado. Mañana cerramos con la pregunta que falta: ¿es responsable? Ética, gobernanza y despliegue.