Evals: cómo saber si tu sistema con LLM funciona antes de que lo descubran tus clientes

Por qué fallan las pruebas a ojo

Leer unas cuantas respuestas se siente como probar. No lo es.

La prueba habitual antes de lanzar es una demo: alguien escribe una docena de preguntas, las respuestas se ven bien y el equipo despliega. La muestra es mínima, sesgada y nunca se vuelve a correr. Cuando cambia el prompt, el modelo o el índice, nadie sabe si la calidad subió o bajó.

La percepción tampoco es confiable. En el ensayo aleatorizado de METR (julio de 2025), desarrolladores experimentados de código abierto tardaron un 19 % más con herramientas de IA de inicios de 2025, convencidos de que iban un 20 % más rápido. Los benchmarks públicos no llenan ese vacío: en febrero de 2026, OpenAI dejó de reportar SWE-bench Verified tras encontrar pruebas defectuosas en el 59,4 % de 138 tareas difíciles auditadas. Y ninguno mide el español de una aseguradora de Bogotá ni el francés de un comercio de Lyon.

Las encuestas lo confirman: en la de LangChain a 1.340 profesionales (finales de 2025), la calidad era el primer freno para llegar a producción (32 %) y el 89 % tenía observabilidad, pero solo el 52,4 % corría evals offline.

La pila de evaluación: cinco capas

Cada capa atrapa lo que la anterior deja pasar.

Anthropic agrega dos distinciones útiles. Las evals de capacidad miden lo que el sistema aún no logra y arrancan con tasas de aprobación bajas; las evals de regresión protegen lo que ya funciona y deben mantenerse cerca del 100 %. En agentes, pass@k (acierta uno de k intentos) no es lo mismo que pass^k (aciertan los k): solo el segundo mide confiabilidad.

Cómo construir el set de datos

El set de oro es el activo; las herramientas son reemplazables.

Anthropic recomienda empezar con 20 a 50 tareas tomadas de fallos reales; OpenAI, mezclar datos de producción, incluida la retroalimentación de usuarios, con casos escritos por expertos. Tu set debe parecerse a tu tráfico, no a un benchmark.

• Prompts reales de logs, tickets de soporte y conversaciones comerciales. Los logs suelen contener datos personales en el sentido de la Ley 1581 de 2012 o del RGPD: anonimízalos antes de copiarlos a un set de prueba.
• Casos límite y hostiles: pedidos ambiguos, datos sucios, herramientas caídas, preguntas fuera de alcance, instrucciones inyectadas en documentos. Anthropic insiste en el equilibrio: probar cuándo un comportamiento debe ocurrir y cuándo no.
• Casos en español y francés escritos por nativos, no traducidos: montos en COP como 1.250.000, fechas día/mes, el vous del francés formal, tildes faltantes y cambios de idioma a mitad de conversación.
• Un resultado esperado por caso: la respuesta exacta cuando existe; si no, los criterios y las fuentes permitidas.

Versiona todo junto: set, prompt, identificador fijo del modelo (no un alias), nivel de esfuerzo y juez. Reserva una porción que nunca uses para ajustar y retira los casos saturados: Anthropic advierte que una eval que todos aprueban deja de dar señal.

Calificadores, sesgos y calibración

Usa el calificador más barato que de verdad pueda decidir.

La coincidencia exacta resuelve clasificación, enrutamiento y extracción normalizada. Las verificaciones programáticas llegan más lejos de lo que muchos equipos creen: un esquema JSON, un SQL que debe ejecutarse, pruebas unitarias sobre código generado, una tolerancia numérica, una cita que debe existir entre los pasajes recuperados. Los jueces LLM con rúbrica cubren el resto, y la guía de OpenAI prefiere veredictos de aprobado o reprobado, o por pares, a las escalas numéricas.

Cómo calibrar al juez

1. Dos personas etiquetan por separado los mismos 50 a 100 casos con la rúbrica; su acuerdo es tu techo.
2. Corre el juez sobre esos casos y lee cada desacuerdo: la mayoría viene de criterios vagos, así que reescríbelos como preguntas de sí o no.
3. Confía en el juez cuando su acuerdo con los humanos se acerque al de ellos entre sí (Zheng et al. midieron más del 80 % para GPT-4, el nivel humano). OpenAI aconseja no escalar un juez antes de eso.
4. Fija la versión del juez y recalibra cuando cambie. Anthropic solo garantiza Claude Haiku 4.5 hasta el 15 de octubre de 2026 como mínimo.

Gates de regresión en CI

Una eval que no puede bloquear un despliegue es un informe, no un control.

Trata prompts y configuración como código: cada cambio pasa por un pull request que corre las evals, sea una edición de prompt, una versión nueva del modelo, otro nivel de esfuerzo, una base reindexada o un esquema de herramienta modificado.

Los modelos cambian aunque tu código no cambie. Claude Opus 5.5, lanzado el 22 de septiembre de 2026, usa por defecto el esfuerzo medium, un nivel por debajo de Opus 5: los equipos que nunca fijaron el esfuerzo obtuvieron otro comportamiento sin tocar una línea. Un gate, es decir, un umbral que bloquea el merge, convierte ese cambio silencioso en un build fallido.

• Escalona la batería: 30 a 50 casos críticos en cada pull request, el set completo cada noche y antes de cada versión.
• Define el umbral antes, por ejemplo cero fallos en casos críticos (seguridad, dinero, datos personales) y ninguna caída de más de dos puntos en la tasa de aprobación global.
• Controla el azar: corre los casos críticos varias veces y exige pass^k.
• Guarda las transcripciones junto a los puntajes: un puntaje que no puedes leer no se puede depurar.

Herramientas, según su documentación

Elige según tu stack; mantén portátil el set de datos.

La herramienta importa menos que la disciplina. Guarda sets y rúbricas en archivos simples (JSONL, YAML) en tu propio repositorio para cambiar de framework sin rehacer el set de oro. En RAG, suma las métricas de recuperación de nuestra guía de RAG.

Cuánto cuesta evaluar y cómo muestrear

Los tokens son la línea pequeña; el tiempo de las personas es la grande.

Un cálculo ilustrativo, no una medición de proyecto: 300 casos (100 en español, 100 en inglés y 100 en francés), tres intentos por caso. El sistema evaluado es Claude Opus 5.5 (USD 4 / 20 por millón de tokens) con 3.000 tokens de entrada y 700 de salida por caso, razonamiento incluido; el juez es GPT-6 Sol (USD 2 / 10), de otra familia, que lee 2.500 tokens y escribe 500.

El gasto en tokens es modesto; lo caro son las horas de quienes etiquetan, revisan y corrigen rúbricas. Y la rúbrica del juez es un prefijo estable: OpenAI descuenta un 90 % la entrada en caché en GPT-6.

Muestrear producción. La documentación de LangSmith muestra evaluadores en línea sobre una muestra, por ejemplo el 10 % de las trazas. Nosotros estratificamos: una proporción fija por ruta y por idioma, más toda traza con retroalimentación negativa, escalamiento, rechazo o longitud inusual. Las verificaciones en código pueden cubrir el 100 % del tráfico. Más palancas en el costo real de la IA.

Dónde encaja nuestro método de 30 prompts, y una checklist

Elegir modelo es una eval; producción necesita las demás.

Cada despliegue de Slash empieza con nuestro método de selección de modelos: 30 prompts fijos y versionados por cliente, cinco motores por corrida, en español, inglés y francés, midiendo calidad, fallos observados, costo por inferencia y latencia p95. Treinta está dentro del rango de 20 a 50 casos que Anthropic sugiere para un primer set.

Esa corrida decide por dónde empezar; no reemplaza el gate, el juez calibrado ni el monitoreo. Recomendamos convertir esos 30 prompts en la semilla del set de oro del cliente.

Checklist para un equipo sin evals

1. Elige una ruta y escribe qué es una respuesta correcta.
2. Reúne 20 a 50 casos reales y anonimizados, con variantes en español, en francés y hostiles.
3. Escribe primero las verificaciones en código: formato, esquema, idioma, contenido prohibido, citas.
4. Agrega un juez de aprobado o reprobado de otra familia de modelos y calíbralo con 50 etiquetas humanas.
5. Bloquea los merges con fallos críticos y corre el set completo cada noche.
6. Suma cada semana los fallos nuevos de producción y vuelve a correr todo cuando un proveedor lance un modelo.