Métricas de calidad de una feature de IA: qué medir y cómo leerlo
Mide una feature de IA con tasa de fallos por categoría, correcciones del usuario y resultado de la tarea. Cómo elegir métricas y evitar las de vanidad.
¿Qué diferencia hay entre métrica de modelo y métrica de producto?
Una métrica de modelo mide la respuesta: si es correcta, si tiene formato válido, si cumple un criterio. Una métrica de producto mide el resultado: si el usuario terminó lo que vino a hacer, cuántas veces tuvo que corregir y cuánto tardó.
Las dos importan, pero no dicen lo mismo. Un asistente puede responder con frases impecables y aun así hacer que la persona pida tres veces la misma cita. Un modelo con precisión mediocre puede funcionar bien si sus errores son fáciles de ver y corregir. Por eso conviene medir ambas y compararlas. Esta página se centra en la calidad de la salida; para el resultado de negocio y la adopción, mira métricas de producto para IA.
¿Qué medir?
Cuatro familias, con ejemplos de cada una:
| Familia | Qué responde | Ejemplos |
|---|---|---|
| Fallos por categoría | ¿Qué sale mal y con qué frecuencia? | Fecha inventada, herramienta no llamada, tono inadecuado |
| Correcciones del usuario | ¿Cuántas veces la persona tuvo que arreglar la salida? | Edita el texto generado, reescribe el prompt, borra y repite |
| Resultado de la tarea | ¿Se logró lo que la persona quería? | Pedido completado, cita creada, archivo exportado |
| Costo y velocidad | ¿Es sostenible? | Tokens por tarea, latencia, costo por resultado aceptado |
La primera familia viene del análisis de errores, que empieza leyendo trazas reales. Las otras tres se miden en producción. Un tablero útil tiene una métrica de cada familia, no quince de la misma.
¿Cómo se construyen las categorías de fallo?
Hamel Husain describe el análisis de errores como la actividad más importante de las evaluaciones. Primero lees trazas reales y anotas lo que sale mal con tus propias palabras; después agrupas esas notas en categorías y, al final, cuentas cuántos fallos hay en cada una. El conteo es lo que ordena las prioridades.
Para el tamaño de la muestra, su guía recomienda revisar al menos 100 trazas y seguir más allá mientras sigas aprendiendo cosas nuevas. Si las trazas salen de producción, la selección importa: tomar solo las que tienen retroalimentación negativa del usuario deja fuera los problemas que nadie reporta, así que conviene combinar varios criterios de muestreo.
¿Cómo se mide el resultado de una tarea?
La guía de Anthropic sobre evaluaciones de agentes separa dos cosas que suelen confundirse. La transcripción es el registro completo de lo que pasó (respuestas, llamadas a herramientas, razonamiento). El resultado es el estado final en el entorno: no importa que el agente diga «reservé el vuelo» si la reserva no existe en la base de datos. Para medir la calidad conviene calificar lo que el agente produjo, no el camino que siguió.
Si el sistema es no determinista, un solo intento no basta. Anthropic define dos medidas:
- pass@k: la probabilidad de obtener al menos una solución correcta en k intentos. Sube con k y sirve cuando basta un acierto.
- pass^k: la probabilidad de que los k intentos salgan bien. Baja con k. Con un 75% de éxito por intento, pasar tres veces seguidas ronda el 42%. Importa en productos de cara al cliente, donde se espera un comportamiento consistente.
El mismo texto recuerda que, una vez que tienes evaluaciones, puedes seguir la latencia, el uso de tokens, el costo por tarea y la tasa de errores sobre un conjunto fijo de tareas, y usarlos como línea base para detectar regresiones.
¿Cómo se leen los números?
Cuatro reglas prácticas:
- Ignora los puntajes sin definición. Si una escala de 1 a 5 no tiene un criterio escrito por cada número, no sirve para decidir. Los veredictos binarios con categoría de error sí.
- Mira la frecuencia antes que la intuición. Husain y Shankar priorizan los arreglos contando qué fallos aparecen más, no por intuición. El fallo más común es el primer candidato, aunque el más llamativo sea otro.
- Cruza métricas. Si la tasa de fallos baja y la tasa de correcciones sube, el modelo mejoró en algo y empeoró en otra cosa. Suele ser señal de que la interfaz no ayuda a la persona a revisar.
- Separa tendencia de ruido. Con pocas trazas, un cambio pequeño puede ser azar. Husain recomienda seguir los intervalos de confianza de las métricas de producción e investigar cuando el límite inferior cruza el umbral que te importa.
Sobre los tableros, Husain es escéptico: dice que rara vez los ha encontrado útiles porque «ponen la carga en el lector». Su alternativa es un relato corto: qué cambió, causas probables y próximos pasos.
¿Por qué le importa a un diseñador?
Porque las correcciones del usuario son datos de diseño. Cada vez que alguien edita la respuesta generada, te dice qué faltó en la interfaz: quizá el modelo no sabía el contexto, o la pantalla no mostraba la fuente, o el formato no coincidía con lo que la persona necesitaba. Si miras esa métrica junto con las trazas, puedes diseñar el arreglo correcto y no solo cambiar el prompt.
Además, medir el resultado de la tarea te obliga a definir qué significa «terminó bien». Ese paso ya es parte del diseño del producto.
¿Cuándo NO conviene?
- Cuando no tienes una definición de éxito por tarea. Sin ella, cualquier métrica es un número sin dueño.
- Cuando el tablero tiene muchas métricas genéricas y ninguna se conecta con un problema del usuario.
- Cuando el objetivo es mostrar una cifra bonita a dirección. Una métrica que no cambia ninguna decisión es decoración.
Ejemplo
Ejemplo ilustrativo: una herramienta de facturas usa IA para categorizar gastos. Su tablero inicial tenía una métrica de «precisión general» del 91%, que parecía buena. Al revisar trazas, el equipo encuentra tres categorías de fallo: confunde suscripciones con compras únicas (35% de los errores), no reconoce proveedores extranjeros (40%) y asigna mal el IVA en gastos mixtos (25%). Además, las correcciones del usuario se concentran en proveedores extranjeros: el 30% de esos gastos se edita a mano. Deciden medir tres cosas: tasa de cada fallo por semana, correcciones por cada 100 gastos y gastos categorizados sin edición. Al arreglar proveedores extranjeros, las correcciones bajan de 30 a 12 por cada 100 en cuatro semanas.
Para el método de análisis que alimenta estas categorías, lee evals como UX research. Para registrar las correcciones y los resultados en producción, observabilidad de LLMs. Y para los veredictos de aprobado o reprobado, LLM-as-judge.
Errores comunes
- Elegir métricas porque son fáciles de calcular, no porque cambian una decisión.
- Reportar solo la precisión general, sin desglose por categoría de error.
- Medir la calidad de la respuesta y olvidar si la tarea terminó.
- Probar un solo intento por caso cuando el sistema da respuestas distintas cada vez.
- Interpretar una mejora pequeña sin verificar el tamaño de muestra.
- Ignorar las correcciones del usuario, que son la métrica más barata y más honesta.