Has creado una suite de evaluación. La supera. Despliegas el cambio. De inmediato, los usuarios se quejan de regresiones que la evaluación no detectó.
Este es uno de los patrones más comunes —y más desmoralizadores— al trabajar con LLM en producción: suites de evaluación que parecen impresionantes, pero pasan por alto las regresiones importantes. Generan una falsa sensación de seguridad. El equipo confía en ellas, publica cambios que perjudican la calidad y solo descubre el problema cuando los usuarios lo señalan.
Crear evaluaciones que realmente detecten regresiones es más difícil de lo que parece. Los elementos básicos —conjunto de datos, resultados esperados y puntuación— son sencillos. El verdadero trabajo consiste en convertirlos en una señal fiable.
Este artículo recoge lo que hemos aprendido al crear evaluaciones robustas para equipos que se toman en serio la calidad de la IA en producción.
Qué hacen las buenas evaluaciones
Cuando se ejecuta sobre un cambio candidato, una buena suite de evaluación responde con un alto grado de confianza a la pregunta: «¿este cambio es mejor, peor o equivalente a la versión actual?».
Sus características:
- Detecta regresiones. Cuando la calidad disminuye en patrones del mundo real, la puntuación de la evaluación disminuye.
- Detecta mejoras. Cuando la calidad mejora, la puntuación lo refleja (no solo en casos seleccionados).
- Es estable cuando no hay cambios significativos. Si nada importante ha cambiado, la puntuación se mantiene constante.
- Es fiable para tomar decisiones. Las decisiones basadas en sus puntuaciones guardan correlación con los resultados reales de los usuarios.
Cada una de estas cosas es más difícil de lo que parece.
El problema del conjunto de datos
La calidad de una evaluación depende de la de su conjunto de datos. Este es el origen de la mayoría de los fallos.
Fallos comunes en el conjunto de datos
Fallo 1: Casos sencillos seleccionados de forma sesgada. El conjunto de datos se creó cuando el sistema funcionaba, a menudo por la misma persona que lo desarrolló. Se eligieron casos que «tenían sentido»: ejemplos claros de cada comportamiento. El tráfico real de producción es más caótico. Los casos difíciles, ambiguos y extremos provocan la mayoría de los fallos, pero están infrarrepresentados en el conjunto de datos.
Fallo 2: Conjunto de datos obsoleto. Se creó hace seis meses. Desde entonces, ha cambiado el comportamiento de los usuarios, se han incorporado nuevas áreas funcionales y el producto ha adquirido nuevas capacidades. El conjunto de datos evalúa una versión antigua de la realidad.
Fallo 3: Falta de cobertura en áreas propensas a regresiones. La evaluación cubre bien el «caso ideal», pero no explora los límites donde realmente se producen las regresiones.
Fallo 4: Contaminación del conjunto de datos. Los ejemplos utilizados en la evaluación también aparecen en el prompt o en los datos de ajuste fino. El modelo “recuerda” los ejemplos. Las puntuaciones de prueba están infladas; el rendimiento real es peor.
Fallo 5: Distribución desequilibrada. El 80% del conjunto de datos corresponde a un tipo de entrada y solo el 5% a la larga cola. Una regresión en esta apenas altera la puntuación, aunque sea real.
Cómo crear un conjunto de datos sólido
Algunos principios que producen conjuntos de datos sólidos:
Obtén ejemplos del tráfico real de producción. Los mejores ejemplos son entradas reales de usuarios, una vez eliminada la información de identificación personal. Reflejan la complejidad que el sistema debe gestionar de verdad.
Un flujo de trabajo práctico:
- Captura una muestra de llamadas en producción (con controles adecuados de privacidad).
- Etiqueta manualmente los resultados esperados (o utiliza un LLM y verifícalos después con una persona).
- Añade el caso al conjunto de datos de evaluación.
- Actualiza el conjunto de datos regularmente (mensualmente es un buen ritmo).
Incluye diversos modos de fallo. Añade expresamente casos que hayan fallado antes en producción. Se convertirán en pruebas de regresión: cuando corrijas un error, incorpora el caso que falló para asegurarte de que no reaparezca.
Estratifica el conjunto de datos. Clasifica los casos —fáciles/medios/difíciles, por tema, tipo de usuario o longitud—. Asegúrate de que cada categoría tenga una cobertura significativa. Sigue las puntuaciones por categoría, no solo la cifra global.
Combina distintos grados de dificultad. Incluye casos fáciles —para detectar regresiones catastróficas—, medios —la mayoría del tráfico real— y difíciles —los casos extremos—. Un conjunto compuesto únicamente por casos difíciles fluctúa mucho ante pequeños cambios; uno que solo contiene casos fáciles no reacciona ante regresiones reales.
Elige un tamaño adecuado. Si es demasiado pequeño, las estadísticas tendrán mucho ruido; si es demasiado grande, las ejecuciones serán lentas y costosas. Tamaños habituales:
- Clasificación: 200-500 casos.
- Generación: 50-200 casos.
- Flujos complejos de agentes: 20-50 casos.
Siempre puedes empezar con menos casos y ampliar el conjunto después.
Disciplina de actualización. Programa una revisión mensual del conjunto de datos. Añade nuevos modos de falla. Retira casos obsoletos. Actualiza las salidas esperadas si el comportamiento deseado ha cambiado.
El problema de las métricas
Lo que midas determina lo que optimizarás. Elegir métricas malas es el segundo fallo más común en las evaluaciones.
Fallos comunes en las métricas
Fallo 1: Los resúmenes de una sola cifra ocultan problemas. Una precisión global del 90% puede esconder que una categoría importante ha caído del 95% al 70% mientras otras han mejorado. La media parece correcta.
Solución: desglose por categoría. Siempre.
Fallo 2: La métrica mide algo equivocado. Una métrica de «exactitud» aplicada a respuestas de atención al cliente puede pasar por alto que una respuesta es correcta, pero descortés. La métrica no contempla el tono.
Solución: puntuación multidimensional. Mide por separado exactitud, tono, longitud y formato.
Fallo 3: Insensibilidad a la gravedad. Una respuesta incorrecta se trata igual si es un error trivial o una alucinación peligrosa.
Solución: puntuación ponderada. Los errores graves deben pesar más. Algunos puntúan 0 —infracciones de seguridad— y otros -1 —fallos catastróficos, peores que no responder—.
Fallo 4: Sensibilidad bimodal. La puntuación cambia de 100% a 99% (imperceptible) o de 100% a 50% (catastrófico). Las regresiones sutiles no se muestran.
Solución: puntuación gradual. Puntúa cada resultado en una escala continua (1-5 o 0-1), no de forma binaria.
Fallo 5: Agregación entre poblaciones. La media de todos los usuarios oculta que el rendimiento se ha desplomado en un subgrupo del 10%.
Solución: desglosa los resultados por segmentos relevantes —nivel de usuario, tipo de consulta o configuración regional—.
Cómo crear métricas sólidas
Multidimensionales. Cada resultado recibe varias puntuaciones: exactitud, tono, formato, seguridad, longitud o cualquier otro aspecto importante.
Ponderadas. Algunas dimensiones importan más que otras. Refleja su peso en cualquier métrica compuesta.
Gravedad calibrada. Dentro de cada dimensión, distingue entre errores menores y graves. Una respuesta objetivamente falsa es peor que otra que solo presenta una pequeña imprecisión.
Métricas por categoría. Presenta puntuaciones desglosadas por segmentos relevantes: fácil/medio/difícil, tema o tipo de usuario.
Tendencia temporal. Una puntuación aislada aporta poco; una tendencia sí. Representa las puntuaciones a lo largo del tiempo para detectar desviaciones.
Alineadas con los usuarios. Las métricas deben correlacionarse con lo que realmente importa a los usuarios. Si los usuarios se quejan de grosería, mide grosería. Si se quejan de longitud, mide longitud.
El problema del juez
Cuando utilizas un LLM como juez —un LLM que puntúa el resultado de otro—, ese juez es quien determina la puntuación. Si presenta sesgos o se equivoca, las evaluaciones no sirven.
Fallos comunes del juez
Fallo 1: Sesgo por longitud. Los LLM que actúan como jueces tienden a preferir respuestas largas. Puntúan mejor una respuesta más extensa incluso cuando contiene información superflua.
Fallo 2: Sesgo por formato. Los jueces prefieren salidas estructuradas (puntos, encabezados) sobre prosa, independientemente de qué sea mejor para la tarea.
Fallo 3: Preferencia por la propia familia. Cuando el juez pertenece a la misma familia que el modelo evaluado, tiende a puntuar mejor los resultados de dicha familia.
Fallo 4: Complacencia. Los jueces tienden a aceptar el enfoque que se les plantea. Decirle al juez «la versión anterior era mala; puntúa la nueva» infla la puntuación de esta última.
Fallo 5: Falta de criterios objetivos. Los jueces puntúan según impresiones, no conforme a criterios concretos. Un mismo prompt recibe puntuaciones distintas en ejecuciones diferentes.
Cómo crear jueces sólidos
Calibra con evaluaciones humanas. Selecciona una muestra de puntuaciones y pide a una persona que vuelva a evaluarlas. Cuando no coincidan, refina el prompt del juez o acepta que esa dimensión requiere revisión humana.
Utiliza modelos jueces diferentes. Cuando sea posible, elige un juez de una familia distinta a la del sistema evaluado para reducir la preferencia por la propia familia.
Explicita los criterios. El prompt del juez debe definir con ejemplos qué se considera bueno y malo. Los criterios vagos producen puntuaciones imprecisas.
Evita planteamientos sesgados. No le digas al juez «puntúa esto en una escala en la que la mayoría de los resultados son buenos». Vincula la puntuación a comportamientos concretos.
Rúbricas con criterios de referencia. Puntúa conforme a una rúbrica definida y con ejemplos para cada nivel. «Puntuación 5: objetivamente correcta, específica y bien estructurada. Puntuación 4: correcta en su mayor parte, aunque puede faltar un detalle. Puntuación 3: …». Con estas referencias, el juez es coherente; sin ellas, se desvía.
Exige una salida estructurada. El juez debe producir puntuaciones estructuradas —por dimensión y con justificación—, no texto libre. Así resulta más fácil agregarlas y auditarlas.
Un prompt de juez sólido se parece a:
You are evaluating an AI assistant's response.
User query: {query}
Assistant response: {response}
Score on the following dimensions, on a scale of 1-5:
1. Factual accuracy: Are all claims correct? (5 = all correct, 4 = mostly correct with minor issues, 3 = some incorrect, 2 = many incorrect, 1 = mostly wrong)
2. Relevance: Does the response address the user's actual question? (5 = perfectly addresses, 1 = doesn't address)
3. Completeness: Does the response contain enough information? (5 = complete, 1 = severely incomplete)
4. Tone: Is the response appropriately professional? (5 = perfect tone, 1 = inappropriate)
For each score, provide:
- The score
- A one-sentence specific reason
- The specific text in the response that supports your score
Output JSON: {"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}
Ejecuta el juez sobre un conjunto de calibración —ejemplos puntuados por personas— y ajústalo hasta que coincida con ellas dentro de un margen aceptable.
Diseño de suites de evaluación para producción
Algunos patrones que funcionan en producción:
Suite 1: La suite de regresión
Un conjunto definido de casos de prueba (200-500) que el sistema debe superar antes de cualquier despliegue. Se selecciona a partir de fallos reales, casos extremos y patrones que se sabe que funcionan. No cambia con frecuencia.
Esta es la suite que «no debe romperse». Integración con CI: se ejecuta en cada PR y bloquea la fusión si detecta una regresión.
Suite 2: La prueba de humo
Un subconjunto pequeño (10-30 casos) que se ejecuta con frecuencia. Proporciona información rápida durante el desarrollo y detecta de inmediato las regresiones catastróficas.
Integración: hook de pre-commit o una prueba de humo rápida antes de la evaluación principal.
Suite 3: La suite de descubrimiento
Un conjunto de datos más amplio y diverso (más de 1000 casos) obtenido mediante muestreo del tráfico real de producción. Se ejecuta con menos frecuencia (¿semanalmente?) y busca patrones que las suites más pequeñas puedan haber pasado por alto.
Integración: tarea programada. Los resultados se revisan en reuniones semanales de calidad.
Suite 4: La suite en línea
Una muestra del tráfico real de producción, puntuada automáticamente por un LLM juez o mediante señales de usuarios. Detecta desviaciones que las evaluaciones sin conexión pasan por alto.
Integración: continua y basada en paneles.
Suite 5: La suite de flujo de usuario
Pruebas end-to-end que recorren flujos de usuario completos, no solo llamadas individuales a un LLM. Son adecuadas para sistemas de agentes y flujos de trabajo de varios pasos.
Integración: antes de desplegar cambios importantes.
Un sistema de producción maduro tiene las cinco. Empieza con la suite de regresión; añade otras a medida que crece la capacidad.
Disciplina de costes y tiempos
Las evaluaciones cuestan dinero (llamadas a LLM) y tiempo (ejecutarlas, revisarlas).
Una evaluación de 500 casos con un modelo juez de gama alta puede costar €5-20 por ejecución. Si se ejecuta en cada PR (10/día), el gasto será de €50-200/día. Es asumible, pero real.
Estrategias:
Ejecuta pruebas de humo en las PR y las suites completas al fusionar. Así evitas gastar en PR que no se fusionarán.
Guarda los resultados en caché. Si no han cambiado ni el prompt ni el modelo, no es necesario repetir la ejecución. Utiliza como clave (versión del prompt, modelo, versión del conjunto de datos).
Usar jueces más baratos cuando sea posible. Un modelo juez más barato con buena calibración suele ser aceptable.
Paralelizar. Las ejecuciones de evaluación son paralelizables. Usa concurrencia.
Muestrea en lugar de ejecutar el conjunto completo. Para las comprobaciones rutinarias, selecciona 50 casos de un conjunto de 500. Reserva la ejecución completa para los cambios importantes.
En cuanto al tiempo, la pregunta suele ser «¿cuánto puede esperar una PR?». Intenta que la evaluación completa tarde <15 minutos. Si tarda más, las personas que desarrollan cambian de contexto y pierden productividad.
Patrones operativos
Algunas prácticas que distinguen programas de evaluación maduros:
Patrón 1: Despliegues condicionados por evaluaciones
Los resultados de las evaluaciones condicionan los despliegues de producción que afectan a un LLM. ¿La puntuación ha caído por debajo del umbral? Se bloquea el despliegue y se investiga la causa.
El umbral suele ser relativo: «la puntuación debe mantenerse a menos de un 2% de la referencia». Esto admite cierto ruido, pero detecta regresiones significativas.
Patrón 2: Investigación cuando se mueven las puntuaciones
Cualquier cambio significativo en la puntuación —al alza o a la baja— se investiga. ¿Ha subido? ¿Por qué? ¿Ha mejorado el sistema o se ha vuelto más fácil la prueba? ¿Ha bajado? ¿En qué casos exactamente? ¿La regresión se limita a un segmento?
No celebres ni te alarmes ante movimientos agregados: investígalos.
Patrón 3: Curación continua del conjunto de datos
El conjunto de datos no se construye una sola vez; se mantiene de forma continua. Proceso:
- El usuario se queja de una respuesta → añade al conjunto de datos como prueba de regresión.
- Se publica una nueva funcionalidad → añade casos que la cubran.
- El comportamiento del modelo sorprende a alguien → si se trata de un fallo real, añádelo.
- Los casos dejan de ser pertinentes → retíralos.
Una reunión mensual funciona bien. El conjunto de datos se trata como un activo vivo.
Patrón 4: Revisión basada en el diff
Al revisar los resultados de una evaluación, céntrate en las diferencias respecto a la referencia:
- Casos donde la nueva versión obtuvo una puntuación más alta que la base (mejoras).
- Casos donde la nueva versión obtuvo una puntuación más baja (regresiones).
- Casos donde la puntuación permaneció igual (sin señal).
El diff contiene la señal. Revisar 500 casos uno por uno no es práctico; revisar 30 diferencias sí lo es.
Patrón 5: Revisión humana de desacuerdos del juez
Periódicamente (¿cada semana?), selecciona casos a los que el juez haya asignado puntuaciones altas y bajas. La revisión humana debe responder: ¿coincides con el juez?
Los desacuerdos revelan:
- Sesgos del juez: calibra su prompt.
- Problemas reales de calidad: corrige el sistema.
- Problemas del conjunto de datos: el resultado esperado del caso es incorrecto.
Así se mantiene la calidad del juez a lo largo del tiempo.
Patrón 6: Revisión trimestral de evaluaciones
Realiza una revisión trimestral del propio programa de evaluación:
- ¿Qué regresiones reales detectó la suite de evaluación este trimestre?
- ¿Qué regresiones reales omitió?
- ¿Qué falsas alarmas produjo?
- ¿Qué lagunas de cobertura conocemos?
- ¿Qué cobertura ofrece el conjunto de datos de los comportamientos actuales en producción?
Esto es metaevaluación: evaluar la propia evaluación. Sin ella, el programa se degrada.
Un ejemplo práctico: evaluación de soporte al cliente
Veamos una configuración concreta de evaluación de producción para un sistema de atención al cliente basado en IA.
Objetivo: garantizar que las respuestas de la IA a las consultas de los clientes sean exactas, útiles, coherentes con la marca y seguras.
Conjuntos de datos:
-
Suite de regresión (300 casos):
- 50 casos fáciles (políticas claras, respuestas simples).
- 100 casos medios (complejidad típica).
- 100 casos difíciles (ambiguos, sensibles, de múltiples partes).
- 50 casos de fallos conocidos (situaciones que han sufrido regresiones anteriormente).
-
Suite de descubrimiento (1000 casos): Muestreo mensual del tráfico real de producción, sin información de identificación personal.
-
Suite adversarial (50 casos): Prompts diseñados específicamente para intentar extraer información, conseguir reembolsos en casos no admisibles o manipular a la IA.
Métricas:
Para cada caso, el juez puntuará en:
- Precisión factual (1-5)
- Cumplimiento de políticas (1-5)
- Adecuación del tono (1-5)
- Completitud (1-5)
- Adecuación de la longitud (1-5)
- Seguridad (binario: aprobado/rechazado)
Jueces:
- Juez principal: Claude (de un proveedor diferente al del sistema evaluado, que utiliza GPT; elegir otro proveedor evita el sesgo de preferencia por el mismo modelo).
- Calibrado con una revisión humana de 100 casos de referencia.
- Recalibración trimestral.
Agregación:
- Puntuación media por dimensión y segmento (tipo de ticket, nivel del cliente e idioma).
- Tasa de aprobación en seguridad (debe ser del 100%).
- Puntuación ponderada por caso (usada para diferencias).
Operaciones:
- Prueba de humo (30 casos) en cada PR.
- Suite completa de regresión (300 casos) al fusionar una PR.
- Suite de descubrimiento (1000 casos) semanal.
- Suite adversarial (50 casos) antes de cualquier cambio de prompt o modelo.
- Muestreo en línea del 1% del tráfico en producción, juzgado en tiempo real.
Revisión:
- Reunión mensual: revisar tendencias de evaluación, nuevos modos de falla, actualizaciones del conjunto de datos.
- Reunión trimestral: meta-evaluación, calibración del juez, auditoría del conjunto de datos.
Resultados (de implementaciones reales de sistemas similares):
- ~3 regresiones detectadas al mes que se habrían desplegado sin las evaluaciones.
- ~1 falsa alarma por mes (evaluación señala una regresión que en realidad está bien).
- Detección de desviaciones dentro de días, no semanas/meses.
- Mayor confianza al desplegar cambios de prompts y modelos.
Así son las evaluaciones de producción: no un proyecto rápido de fin de semana, sino una inversión continua con un ROI real.
Puntos comunes de error
Algunos patrones que vemos repetidamente:
Error 1: Crear las evaluaciones después de publicar el producto. «Añadiremos las evaluaciones más adelante». Ese momento nunca llega. Créelas desde el primer día.
Error 2: Depender de una sola persona. Una persona crea la evaluación y nadie más la mantiene. Cuando se marcha, la evaluación se degrada. Reparte la responsabilidad.
Error 3: Tratar las evaluaciones como estáticas. Construidas una vez, nunca actualizadas. Se vuelven inútiles a medida que el producto evoluciona. Trátalas como un activo vivo.
Error 4: Confiar ciegamente en las puntuaciones. La evaluación dice que el cambio es mejor y, por tanto, lo despliegas. Sin revisión humana, puedes publicar algo que recibe una puntuación alta, pero que los usuarios detestan. Combina las evaluaciones con revisión humana en los cambios importantes.
Error 5: Optimizar para la evaluación. Ajustar prompts específicamente para obtener buenas puntuaciones. La evaluación mejora, pero la realidad no. Ten cuidado: si una mejora en la evaluación no se refleja en producción, estás optimizando para la prueba.
Error 6: Ignorar el coste de la infraestructura. Las evaluaciones a gran escala son caras: las llamadas a los LLM se acumulan. Sin seguimiento de costes, solo lo descubrirás al final del mes.
Error 7: No definir criterios claros de aprobación y rechazo. «La puntuación pasó de 4.2 a 4.0, ¿es una regresión?». Define los umbrales de antemano y respétalos.
Error 8: La suite de evaluación consume todo el esfuerzo de pruebas. Se crean evaluaciones elaboradas mientras faltan pruebas básicas de corrección. Las evaluaciones miden la deriva de la calidad; no todas las pruebas son evaluaciones.
La parte cultural
La parte más difícil de las evaluaciones de producción es la cultura. Los equipos de ingeniería y producto deben:
- Confiar lo suficiente en las evaluaciones como para bloquear despliegues basándose en ellas. De lo contrario, las evaluaciones son puro teatro.
- Mantener suficiente espíritu crítico como para investigar cualquier movimiento. La confianza ciega conduce a optimizar para la prueba.
- Invertir en la curación del conjunto de datos como trabajo continuo. No un proyecto único.
- Aceptar que las evaluaciones no sustituyen el criterio humano. Reducen la cantidad de casos que las personas deben revisar.
- Reconocer cuando una suite de evaluación no funciona. Cuando las regresiones reales se filtran, la suite de evaluación es el problema, no el usuario que se queja.
Los equipos con esta cultura despliegan con más rapidez y fiabilidad. Los demás terminan confiando demasiado en evaluaciones defectuosas o paralizados por su ausencia.
El mensaje clave
Crear evaluaciones que detecten regresiones de verdad es más difícil de lo que parece, pero es posible.
Las claves:
- Conjuntos de datos reales y diversos obtenidos de producción.
- Métricas multidimensionales y sensibles a cada segmento, alineadas con la experiencia del usuario.
- Jueces calibrados y contrastados con el criterio humano.
- Varios tipos de suites de evaluación para diferentes preocupaciones (regresión, prueba de humo, descubrimiento, en línea, end-to-end).
- Disciplina operativa: despliegues condicionados por evaluaciones, mantenimiento continuo del conjunto de datos e investigación de los cambios.
- Compromiso cultural con el uso y mejora de las evaluaciones con el tiempo.
Cuando se hacen bien, las evaluaciones se convierten en la infraestructura más valiosa de tu stack de IA. Permiten desplegar con rapidez sin sacrificar la calidad. Sin ellas, avanzas a ciegas.
Construye las evaluaciones. Confía en las evaluaciones. Mejora las evaluaciones. Así se mantiene la calidad de la IA en producción.
