Gotchas de evaluación: cómo una medición te miente
Una eval se supone que es lo único en un sistema de IA en lo que podés confiar — el número que te dice que el prompt mejoró, que el agente no regresionó, que el modelo nuevo es seguro de lanzar. Pero una eval puede mentir: puede medir memorización en vez de capacidad, optimizar un número mientras pierde el objetivo, puntuar con un juez sesgado, o pasar offline y fallar en vivo. Diez gotchas que hacen que una medición parezca prueba cuando no lo es, cada uno con la pregunta a contestar primero y el costo de confiar en el número equivocado.
El punto entero de la evaluación es reemplazar "se veía bien" por un número que podés bancar — la medición que dice que el prompt mejoró, que el agente no regresionó, que el modelo nuevo es seguro de lanzar. Ese número es el gate entre un sistema sobre el que estás adivinando y uno que de verdad verificaste. Que es justo por qué una eval mala es más peligrosa que ninguna eval: no tener eval te deja honestamente inseguro, pero una rota te entrega confianza falsa — un dashboard en verde sobre un sistema que está silenciosamente peor, y lanzás apoyado en una medición que nunca estuvo midiendo lo que pensabas.
Diez gotchas que convierten una evaluación en teatro — un número que parece prueba y no lo es. Son las fallas que le pegan al set de eval y a la observabilidad alrededor, la red de regresión de la que cuelga todo el trabajo de agentes, grounding y prompting. Si esa red tiene agujeros, cada "lo testeamos" río arriba vale menos de lo que suena. Cada gotcha va con la pregunta a contestar antes de confiar en el número y el costo de equivocarte. Nada de esto depende del toolkit: ya sea que puntúes con el Testing Center de Agentforce y leas traces de Agentforce Observability, corras una suite offline en LangSmith, o califiques con Claude como juez sobre la Anthropic API, las mismas formas en que una medición miente aplican a las tres. Evaluación y observabilidad son una sola disciplina sobre tres superficies — la capa de plataforma, la capa de modelo, el stack de tracing off-platform — compuestas por dónde corre el sistema, no tres rivales entre los que elegís.
Los gotchas
1. Fuga del set de eval — ejemplos de test que se filtraron a dev, así medís memoria y no capacidad
El score más limpio del mundo no vale nada si el sistema ya vio las respuestas. Cuando un ejemplo de test se filtra al bloque de few-shot del prompt, a los datos de fine-tuning, o al índice de retrieval del que lee el agente, la eval deja de medir si el sistema puede hacer la tarea y empieza a medir si memorizó esta instancia de ella. El número sube; la capacidad no. La guía de Anthropic está construida sobre un test set held-out (apartado) justo por esto — apartado significa que el sistema nunca entrenó ni se ajustó sobre él.
El costo es el peor tipo de confianza falsa: un score alto en el que confiás, un lanzamiento que aprobás por él, y un sistema que se desploma con el primer input genuinamente nunca-visto porque todo lo que probaste fue recall. El arreglo es una pared estricta entre el set de eval y todo de lo que el sistema aprende — ejemplos en el prompt, datos de ajuste, el corpus de retrieval — y un chequeo periódico de que ningún caso de test la haya cruzado en silencio. La pregunta a contestar primero: ¿podés probar que este set de eval está apartado — que ni uno de estos ejemplos aparece en el prompt, en los datos de ajuste, o en algo que el sistema recupera en tiempo de ejecución?
2. Gamear una sola métrica — Goodhart se come tu objetivo
"Cuando una medida se vuelve un objetivo, deja de ser una buena medida." Elegí un número — accuracy, un score de similitud, rating promedio —, hacelo lo que todos optimizan, y el sistema va a trepar ese número por la ruta que sea más barata, incluidas rutas que abandonan el objetivo que el número tenía que representar. Un resumidor optimizado para overlap ROUGE aprende a repetir la fuente; un bot de soporte optimizado para "resuelto" aprende a cerrar tickets que el cliente reabre. La métrica sube mientras lo que te importaba cae.
El costo es un sistema que puntúa mejor cada sprint y atiende peor a los clientes — un gráfico subiendo hacia arriba y a la derecha mientras el resultado real se erosiona debajo, invisible hasta que alguien lee los transcripts. El arreglo es medir a lo largo de varios ejes que no se pueden gamear todos a la vez — los propios ejemplos de Anthropic combinan fidelidad de tarea con una tasa de no-toxicidad separada y un límite de latencia, justamente para que un número no se pueda inflar aislado — y mantener al menos una lectura cualitativa sobre salidas reales como control de las cuantitativas. La pregunta: si el sistema maximizara esta métrica por cualquier medio disponible, ¿seguiría haciendo el trabajo que de verdad querés — o le entregaste un número que puede ganar mientras pierde el sentido?
3. Sesgo del LLM-como-juez — un juez sin anclar deriva
Usar un modelo para calificar salidas es rápido, escalable y la decisión correcta para juicios con matices — Anthropic lista la calificación basada en LLM como apta justo donde la basada en código es demasiado rígida. Pero un juez es un modelo, y los modelos tienen sesgos: sesgo de posición (favorecer la respuesta que vino primero), sesgo de verbosidad (puntuar más alto la respuesta más larga y de tono más seguro sin importar si es correcta), y autopreferencia (un modelo califica con más cariño las salidas de su propia familia). Un juez sin anclar — "puntuá esto del 1 al 5" sin rúbrica — deriva en todos ellos, y tus scores miden el ladeo del juez tanto como la calidad de la salida.
El costo es un tablero que parece riguroso y ordena por verbosidad y orden — elegís el prompt "mejor" porque sus salidas eran más largas, no mejores, y el sesgo queda horneado en cada decisión que la eval manejó. La pregunta: ¿tu juez está anclado a una rúbrica explícita, se le pide razonar antes de puntuar, y está controlado por posición y verbosidad — o es un "puntuá esto" sin restricciones que en silencio califica por largo y orden?
4. Sin baseline — "mejor" sin nada contra qué ser mejor
"El prompt nuevo es mejor" no es una afirmación que podés hacer sin un antes medido. Si no puntuaste la versión vieja en el mismo set, "mejor" es una sensación, y las sensaciones sobre salidas de IA son justo lo que la evaluación existe para reemplazar. Anthropic plantea un buen criterio de éxito como un delta medible contra un baseline — "una mejora del 5% sobre nuestro baseline actual" — y el 5% no significa nada sin el número del baseline sentado al lado.
El costo es un equipo que lanza cambios que no puede defender — cada release justificado por una mejora que nadie midió, y sin forma de saber, tres sprints después, si el sistema está mejor o peor que donde arrancó. El arreglo es medir la versión actual antes de cambiar nada, guardar ese número, y reportar cada resultado como un delta contra él. La pregunta: ¿tenés un score de baseline registrado para la versión que estás reemplazando — o "mejor" es una afirmación sin ningún número debajo?
5. Demasiado pocos ejemplos — el ruido tapa la señal
Una eval de diez ejemplos no te dice casi nada. Con un set tan chico, un caso ambiguo o una adivinanza con suerte mueve el score diez puntos, y no podés distinguir una mejora real del ruido de muestreo. El principio de diseño de Anthropic es directo sobre el trade-off — priorizá volumen sobre calidad: más preguntas con calificación automatizada de señal un poco más baja le gana a menos preguntas calificadas a mano a la perfección, porque el poder estadístico viene de los números, y un porcentaje que parece seguro sobre un puñado de casos es una mentira que parece segura.
El costo son decisiones tomadas sobre ruido disfrazado de señal — "mejoraste" el score de 70 a 80 por ciento y lanzaste, cuando sobre diez ejemplos eso es un caso dándose vuelta y bien dentro del margen donde no pasó nada real. El arreglo son suficientes ejemplos para que un solo caso no pueda mover el veredicto, y — cuando escribir cientos a mano es el bloqueo — usar el modelo para expandir un set semilla, cosa que Anthropic recomienda explícitamente. La pregunta: ¿este set de eval es lo bastante grande como para que el resultado sobreviva a que unos pocos casos se vayan para cualquier lado — o estás leyendo un porcentaje armado sobre tan pocos ejemplos que es mayormente ruido?
6. Regresión silenciosa en un cambio — sin set de regresión, te avisa producción
Cambiá el prompt, cambiá la versión del modelo, editá una tool, re-chunkeá el corpus — y si no hay un set de regresión que se vuelva a correr automáticamente con el cambio, el primer lugar donde te enterás de qué se rompió es producción. Los sistemas de IA regresionan en silencio: el mismo input que funcionaba ayer devuelve hoy una respuesta sutilmente peor, sin error tirado, sin excepción logueada, solo calidad desangrándose donde nadie mira. Este es el set de eval haciendo su trabajo de mayor valor — es la red de regresión bajo cada cambio de agente, cada pipeline de retrieval, cada prompt — y sin ella cada cambio es una apuesta que liquidás frente a los clientes.
El costo es enterarte por un cliente, un pico de soporte, o una métrica tres semanas tarde de que un cambio de hace dos sprints degradó el sistema en silencio — y una cacería por todo lo que cambió desde entonces, porque nada lo marcó cuando pasó. El arreglo es un set de regresión armado con fallas reales del pasado que se vuelve a correr en cada cambio al prompt, modelo, tools, o retrieval, con un gate que bloquea el cambio si el score baja. La pregunta: ¿un cambio a cualquier parte de este sistema vuelve a correr automáticamente un set de regresión antes de salir — o te enterás de que regresionó cuando se entera la gente que lo usa?
7. Offline ≠ online — una eval offline que pasa y en vivo es peor
Una eval offline en verde es necesaria y no suficiente. La evaluación offline, como la define LangSmith, corre pre-deployment sobre un dataset curado con salidas de referencia — prueba que el sistema maneja los casos que vos juntaste. Producción corre sobre una distribución que no curaste: inputs distintos, otra mezcla, la cola larga que nunca pensaste en poner en el set. La brecha entre las dos es el distribution shift, y un sistema que se saca un diez en la suite offline igual puede degradarse en vivo porque en vivo no es el dataset.
El costo es un lanzamiento aprobado sobre un pase offline que rinde por debajo en silencio en tráfico en vivo — el dataset dijo sí, la distribución dijo no, y la brecha aparece como calidad visible para el cliente que ninguna eval atrapó. La pregunta: ¿puntuás tráfico de producción en vivo, no solo el set offline curado — y te darías cuenta si los inputs del mundo real derivaran lejos de los casos que contiene tu dataset?
8. El "vibe check" — mirar a ojo unas pocas salidas no es medir
Leer tres salidas, asentir, y lanzar es la falla por defecto de la evaluación de IA, y es seductora justo porque las salidas son fluidas — se leen bien, así que se sienten correctas. Pero "se veía bien en tres intentos" es el principio 3 enunciado como su propio anti-patrón: una sensación, no un test. Mirar a ojo no tiene baseline, no cubre los casos difíciles, no tiene un número que puedas comparar la semana que viene, y escala a exactamente cero — no podés mirar a ojo mil salidas, y las fallas viven en las que no leíste.
El costo es un sistema cuya calidad es lo que sintió la última persona que le dio una mirada ese día — indefendible, irrepetible, y ciego a cada modo de falla fuera de las dos o tres salidas que justo se miraron. El arreglo es convertir la sensación en una medición: escribí qué significa "bueno" como una rúbrica, convertilo en casos puntuados, y automatizá la calificación para que corra sobre volumen en vez de sobre sensaciones. La pregunta: ¿"funciona" está respaldado por un score sobre un set real con una rúbrica — o por alguien que leyó unas pocas salidas y quedó tranquilo?
9. Set de eval sin versionar — la regla cambia debajo de la medición
Si el set de eval mismo se mueve — ejemplos agregados, editados, o callados sacados — sin una versión encima, tus scores dejan de ser comparables a lo largo del tiempo. El 82 por ciento del mes pasado y el 88 por ciento de este mes no significan nada uno al lado del otro si el set cambió en el medio: podés tener un sistema mejorado, un test más fácil, o las dos cosas, y sin forma de separarlas. Un set de eval es un instrumento de medición, y un instrumento cuyas marcas se mueven no se puede usar para detectar cambio — que es la única cosa para la que existe.
El costo es una historia de calidad en la que no podés confiar — una línea de tendencia graficada contra una regla que siguió cambiando de largo, así que no podés distinguir progreso real de un test que se volvió más fácil, y cada comparación entre versiones es silenciosamente sin sentido. El arreglo es versionar el set de eval como código: los cambios son commits, cada score registra la versión del set contra la que corrió, y una comparación entre versiones se marca como no-peras-con-peras. La pregunta: ¿este set de eval está versionado, con cada score atado a la versión contra la que corrió — o el set está derivando debajo tuyo, haciendo que el número del mes pasado sea incomparable con el de este?
10. Loguear todo, medir nada — traces sin scores atados
Capturar cada trace y nunca puntuar ninguno se siente como observabilidad y no lo es. El principio 11 — trazá todo, no podés debuggear lo que no podés reproducir — es necesario, pero un depósito de traces crudos sin métricas ni scores atados es un pajar que solo buscás después de un incidente, a mano, una vez que ya sabés que algo anda mal. El punto de la observabilidad es hacer aflorar la degradación antes que un cliente, y los logs crudos sin nada computado encima no hacen aflorar nada — son material forense, no un monitor.
El costo es un archivo completo de traces y una degradación silenciosa que corre por semanas porque nada estaba puntuando el stream — tenés cada registro de la falla y te enteraste por un cliente igual, y después pasás días grepeando logs sobre los que podrías haber estado alertando. La pregunta: ¿tus traces están puntuados — métricas y juicios atados para que una caída de calidad dispare una alerta — o estás logueando todo y midiendo nada, sosteniendo un pajar que solo vas a buscar cuando alguien te diga que se está prendiendo fuego?
El hilo común a los diez: una medición en la que podés confiar está apartada de lo que el sistema aprendió, puntuada sobre más de un eje, juzgada por un juez anclado, comparada contra un baseline, dimensionada para que el ruido no la mueva, vuelta a correr como gate de regresión en cada cambio, validada contra tráfico en vivo, versionada para que siga siendo comparable, y atada a los traces que se supone que vigila — o es un número que parece prueba y miente. Cada gotcha de arriba es una forma en que una evaluación te dice que el sistema está bien cuando no lo está, lo que es peor que no medir, porque actuás sobre ella.
Cierre
Estos diez son las fallas de evaluación que Cleon vio con más frecuencia, tanto en builds nativos de Agentforce como externos. La disciplina que las previene es el principio 3 tomado en serio — si no podés evaluarlo, no podés lanzarlo — más la parte que la gente se saltea: una eval mala no es una versión chica de una buena, es un pasivo, porque convierte la incertidumbre honesta en confianza falsa y lanzás apoyado en eso. El set de eval es la red de regresión de la que cuelga todo el trabajo de agentes, grounding y prompting; un agujero en la red no es local a la evaluación, es un agujero bajo todo lo de río arriba. Hacé honesta la medición y la mayoría de estas no se disparan; salteala y vas a confiar en un dashboard en verde justo hasta que un cliente te diga que estaba mintiendo.
Si un gotcha de evaluación le pegó a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.
Related
- Gotchas de agentes — las fallas de agente de las que el set de eval es la red de regresión
- Gotchas de grounding — fallas de retrieval que una eval offline tiene que cubrir antes de salir
- Gotchas de prompting — la eval por cambio que puntúa una edición de prompt antes de que aterrice
- Debuggear prompts — aislar la variable, después volver a puntuar
- Principios de AI Engineering — evals (3), el modelo es la parte fácil (4), el costo es un feature (6), el no-determinismo necesita un gate (8), trazá todo (11)
- Style Guide de IA de Marketing Cloud — qué superficie de IA para qué trabajo
- Style Guide de evaluación — la vara en la que estos gotchas se destilan en un checklist
- Debuggear evals — cuando uno de estos ya mordió, cómo confirmar cuál
- Páginas compañeras de esta subcategoría — testing y observabilidad de Agentforce, tracing y monitoreo, debuggear evals, y el Style Guide de Evaluación — profundizan en cada superficie.
Reference: