Los evals son cómo sabes que la máquina puede decidir.
PRAXIS dice qué delegar. Los evals son la evidencia de que esa delegación se sostiene: antes del lanzamiento, después, y cada vez que cambia el modelo, el prompt o los datos.
Esta es una página de método: lo que PRAXIS implica cuando se encuentra con un modelo real. No hace ninguna afirmación sobre un encargo concreto.
Por qué los evals son cosa del liderazgo de producto
La mayoría de los equipos trata la evaluación como una tarea técnica: una puntuación en un benchmark, una posición en un ranking, una batería de tests que ingeniería hará cuando pueda. Así se acaba lanzando un producto con una buena demo y una corazonada.
Un eval es una decisión de producto escrita de un modo que se pueda someter a prueba. ¿Qué es una buena respuesta? ¿Qué errores son tolerables? ¿Cuáles deben ser imposibles? Son preguntas de producto, las mismas que PRAXIS hace sobre el umbral de delegación, solo que ahora tienen que sobrevivir al contacto con un sistema probabilístico, que cambia sin avisar y falla de maneras que nadie enumeró.
Por eso el dueño del eval es el dueño del producto. Ingeniería construye el arnés. El líder de producto decide qué mide y qué pasa cuando el número es malo.
Del juicio a la evidencia
Cada concepto de PRAXIS tiene un gemelo operativo. Si no se puede probar, se queda en un principio en una diapositiva.
Un mapa de autonomía por decisión: qué puede hacer el sistema solo, qué necesita a una persona, qué queda fuera de límites. Cada nivel tiene sus propios criterios de aprobado.
Mapa de autonomía + una vara por decisión
Una taxonomía de errores ponderada por gravedad. Los fallos visibles, comprensibles y reversibles se presupuestan. Los opacos, irreversibles y silenciosos, no.
Cuadro de mando ponderado por gravedad
Las líneas rojas se convierten en puertas duras. Una sola violación bloquea el lanzamiento, diga lo que diga la media.
Conjunto de pruebas de tolerancia cero
Dos preguntas: "¿acertó el modelo?" y "¿pudo la persona notarlo, entenderlo y corregirlo?". Se mide la calidad de la escalada y del control humano.
Métricas de traspaso y de corrección
El comportamiento ante la ambigüedad: ¿se abstiene, pregunta o matiza cuando no sabe, o improvisa con aplomo?
Casos de calibración y de abstención
La especificación de comportamiento, escrita antes del dataset: qué debe hacer el sistema, qué no debe hacer y qué hace cuando duda.
Especificación de comportamiento (el capítulo del PRD que suele faltar)
El bucle de evaluación
Seis movimientos, en este orden. El orden importa: la mayoría de los esfuerzos de evaluación que fracasan empiezan en el paso dos y nunca escriben el uno.
- 01
Especificar el comportamiento
Antes de cualquier dataset, escribe en lenguaje llano qué debe hacer el sistema, qué no debe hacer y qué hace cuando duda. Una especificación por cada decisión que toma. Aquí es donde se fija de verdad el umbral de delegación.
- 02
Construir el dataset desde la realidad
Parte de casos y fallos reales: tickets de soporte, casos límite, puntos donde los expertos discrepan. El optimismo sintético es un mal punto de partida. Un conjunto pequeño y curado supera a uno grande y genérico. Incluye los casos difíciles a propósito y versiona el conjunto como si fuera código.
- 03
Elegir evaluadores según lo que deben detectar
Comprobaciones en código donde la respuesta es verificable. Expertos humanos donde el juicio es el asunto. Un LLM como juez para escalar, pero solo tras calibrarlo con etiquetas humanas y conocer sus propios errores. Un juez sin verificar es solo otro modelo en el que confías.
- 04
Poner umbrales de paso, además de puntuaciones
Las medias esconden los fallos que importan. Define umbrales por clase de gravedad y fallos duros para las líneas rojas. Decide de antemano qué bloquea un lanzamiento, qué dispara una vuelta atrás y quién puede anularlo.
- 05
Ejecutarlo con cada cambio
Cambiar de modelo, editar un prompt, tocar la recuperación de información, añadir datos: cada uno es un lanzamiento. Pasa la batería de regresión en todos, compara versiones y mide coste y latencia junto a la calidad. Una calidad comprada a diez veces el coste es un trade-off que alguien tiene que decidir.
- 06
Seguir evaluando en producción
Los evals offline dicen que el sistema está listo. Producción dice que sigue acertando. Muestrea tráfico real, léelo y convierte cada fallo nuevo en un caso de prueba. Trata las correcciones de los usuarios, las escaladas y la deriva como señales.
El cuadro de mando que querría en mi mesa
Un conjunto corto de medidas, cada una atada a una decisión que alguien tiene autoridad para tomar.
- Éxito de la tarea, por tipo de decisión
- Separada por tipo de decisión. Un sistema puede ser excelente en el 90 % fácil y peligroso en el resto.
- Tasa de error ponderada por gravedad
- Errores contados por lo que le cuestan a la persona, más un recuento aparte de violaciones de líneas rojas. El objetivo de ese recuento es cero.
- Fundamentación
- En sistemas que responden a partir de fuentes: ¿cada afirmación se remonta a algo que el sistema tenía realmente delante?
- Calibración y abstención
- ¿La confianza acompaña al acierto? ¿Dice el sistema "no lo sé" cuando debe, y solo entonces?
- Calidad de la escalada
- Precisión y exhaustividad de los traspasos a una persona, y cuánto tarda alguien en detectar y corregir una salida errónea.
- Acuerdo entre evaluadores
- Acuerdo entre expertos humanos, y entre el modelo juez y los humanos. Si los expertos discrepan, la especificación no está terminada.
- Coste y latencia por tarea resuelta
- La calidad sin su precio es media métrica. Mide ambos, por versión.
- Deriva
- Cómo se mueve todo lo anterior con el tiempo y con los cambios de modelo, prompt y datos.
Dónde se tuercen los evals
Las maneras recurrentes en que un esfuerzo de evaluación produce confianza sin evidencia.
- Optimizar para el benchmark
- Los benchmarks públicos miden la tarea de otro. Tus usuarios están ejecutando la tuya.
- Un único número de precisión mezclado
- Esconde los fallos raros y graves, que son justo los que acaban en un informe de incidente.
- Un modelo juez que nadie verificó
- Escalar la evaluación con un LLM está bien, siempre que antes hayas medido sus errores.
- Un conjunto de pruebas estático
- Deja de parecerse a producción el día que lanzas. Si los fallos no vuelven al conjunto, el eval se degrada.
- Evaluar el modelo cuando el fallo vive en el producto
- La recuperación de información, los permisos, la interfaz y el traspaso también fallan. La unidad bajo prueba es el sistema completo que encuentra la persona.
- Un panel sin ninguna decisión asociada
- Si nadie tiene autoridad para bloquear un lanzamiento o revertirlo, el eval es decoración.
- La revisión humana como red de seguridad
- Cuando se le pide a la persona que atrape lo que el sistema no señala, el producto ha trasladado su responsabilidad al usuario. La revisión hay que diseñarla.
Preguntas
- ¿Qué es un eval de IA?
- Una prueba repetible de si un sistema de IA se comporta como se especificó, ejecutada sobre casos que representan un uso real y puntuada según criterios explícitos por evaluadores: código, expertos humanos o modelos calibrados.
- ¿Quién debe ser dueño de los evals de IA: producto o ingeniería?
- Producto es dueño de qué se mide y de qué pasa cuando falla. Ingeniería es dueña del arnés. Si nadie con autoridad de producto es dueño de la especificación, el eval acaba midiendo lo que era fácil de medir.
- ¿Puede un LLM juez sustituir a los evaluadores humanos?
- Puede escalar la evaluación en casos acotados y bien especificados, una vez calibrado con etiquetas de expertos. No puede decidir qué significa "bueno". Eso sigue siendo humano: la especificación del eval es donde se fija el umbral de delegación.
- ¿De qué tamaño debe ser un conjunto de evals para empezar?
- Más pequeño de lo que la mayoría de los equipos espera. Unas pocas decenas de casos reales bien elegidos, incluidos los difíciles, son más útiles que miles de casos genéricos. El conjunto debe crecer cada vez que producción te sorprenda.
- ¿Cuándo se terminan los evals?
- Nunca. Los modelos, los prompts, los datos y los usuarios cambian. Los evals son una parte permanente del producto, igual que la monitorización lo es de las operaciones.
¿Vas a lanzar una funcionalidad de IA y no sabes cómo vas a comprobar que funciona?
Definamos qué significa bueno, qué no debe pasar nunca y qué bloquea un lanzamiento, antes de que el modelo decida nada por tus usuarios.