Métricas de producto para features de IA: más allá de la precisión
La precisión del modelo no dice si el usuario logró su objetivo. Métricas de producto para features de IA: tareas completadas, ediciones y frustración.
¿Por qué la precisión no alcanza?
La precisión, la latencia y los puntajes de benchmark miden el comportamiento del modelo. Dicen cómo responde, no si la persona consiguió lo que vino a hacer. Un modelo puede responder bien en el laboratorio y fallar en el flujo real, por ejemplo cuando el resultado correcto llega en el paso equivocado.
Por eso el equipo necesita dos capas de métricas. Las de producto dicen si el usuario tiene éxito; las de modelo explican por qué el sistema se comporta así. Si solo se miden las de modelo, el equipo puede mejorar la exactitud mientras la función sigue fallando con usuarios reales. Para la capa de calidad de la salida (tasa de fallos por categoría, correcciones), mira métricas de calidad de una feature de IA; esta página se enfoca en el resultado del usuario.
¿Cuál es la métrica principal?
La tasa de tareas completadas (task completion rate) es el porcentaje de tareas iniciadas que terminan en un estado exitoso. El blog de Tianpan la llama lo más parecido a una métrica norte para productos de IA. Ese mismo texto sitúa la línea de un producto sano alrededor del 70%, pero no cita ningún estudio detrás, así que tómalo como regla empírica de un autor, no como estándar.
Dos advertencias importantes. Primero, “completada” debe significar que el usuario obtuvo lo que vino a buscar, no que el modelo devolvió una respuesta. Un chat que responde algo sin resolver el problema no completó nada. Segundo, la definición debe estar a nivel de producto: si “completada” significa “el modelo terminó de generar”, estás midiendo otra cosa.
¿Qué otras señales conviene medir?
Estas son las señales que describe Tianpan, con su razón de ser. Las cifras que da son del propio blog, sin estudio citado.
| Métrica | Qué indica | Advertencia |
|---|---|---|
| Tasa de tareas completadas | Si el usuario llegó al resultado | Definir “completada” a nivel de producto |
| Ediciones sobre la salida | Cuánto confía el usuario en lo que genera la IA | Pocas ediciones con alta completitud sugieren confianza; pocas ediciones con baja completitud indican abandono, no confianza |
| Regeneraciones en el tiempo | Si la calidad se degrada | Pedir otra respuesta significa que el usuario descartó la actual; una tendencia al alza suele aparecer antes que un cambio en la precisión |
| Profundidad de sesión por resultado | Si la conversación fue productiva | Los turnos promedio engañan si no separas sesiones resueltas de abandonadas |
| Activación en 7 días | Si el usuario tuvo un éxito en la primera semana | El blog la presenta como el mejor indicador temprano de retención a tres meses, sin estudio que lo respalde |
| Índice de frustración | Mensajes repetidos, aclaraciones y abandono tras una respuesta | Es compuesto; define sus pesos antes de usarlo |
| Costo de verificación | Cuánto tarda el usuario en aceptar o rechazar la salida | Difícil de medir, pero una verificación larga delata poca confianza aunque la precisión sea alta |
La tasa de aceptación de sugerencias merece mención aparte. Un estudio de GitHub (Ziegler et al., 2022) comparó la productividad que decían sentir los usuarios de Copilot con sus datos de uso, y encontró que la proporción de sugerencias aceptadas era lo que mejor se relacionaba con esa percepción. Es útil, pero mide percepción, no resultado. Tianpan agrega que una métrica más fuerte es cuánto de lo aceptado se conserva: cita que los desarrolladores de Copilot conservaban el 88% de los caracteres aceptados. Mide entonces la aceptación y también la distancia de edición entre la salida original y la versión final.
¿Cómo se separan las señales humanas de las del agente?
Userpilot propone medir dos flujos por separado. Las señales humanas son clics, grabaciones de sesión, encuestas de satisfacción y tickets de soporte. Las del agente son tasa de invocación de herramientas, reintentos y verificación de la salida. Medir solo clics no sirve cuando un agente llama a la función sin que nadie toque la interfaz.
La misma fuente ordena el éxito en cuatro escalones. Alcance: el segmento correcto llegó a ver la función. Adopción: los usuarios elegibles la probaron. Resultado: produjo lo que se construyó para producir. Impacto de negocio: movió retención, expansión o conversión. La adopción por sí sola no es éxito, y cada escalón depende del anterior.
¿Cómo se pone en práctica?
Userpilot describe un proceso de siete pasos:
- Define el evento de resultado antes de escribir la especificación: no “el usuario hizo clic”, sino “el usuario obtuvo X”.
- Instrumenta el embudo y despliega por etapas (por ejemplo 10%, 50% y 100%), lo que deja un grupo de control natural.
- Escribe la hipótesis antes del anuncio, con porcentajes esperados de invocación, resultado y satisfacción.
- Guía al usuario hasta el resultado, no hasta el botón.
- Segmenta la medición por tipo de usuario, para que los promedios no escondan diferencias.
- Encuesta al usuario después del evento de resultado, no solo tras usar la función.
- Revisa a los 30, 60 y 90 días: alcance y adopción, retención del resultado, e impacto de negocio. Agrega en cada revisión un control de estabilidad (latencia, errores), porque un resultado logrado en una pantalla lenta o inestable no cuenta como resultado real.
Ejemplo
Ejemplo ilustrativo: una app de contabilidad lanza un asistente que categoriza gastos. La precisión del modelo es alta, pero el equipo mira más allá: la tasa de tareas completadas (el gasto queda categorizado sin corrección manual) es del 60%, y el 30% de las sesiones tienen dos o más aclaraciones. Al revisar las grabaciones, descubren que el asistente pide confirmar cada gasto, y los usuarios abandonan. Cambian el diseño para categorizar en lote con opción de deshacer, y la tasa sube y la frustración baja. El modelo no cambió; cambió el flujo.
Errores comunes
- Reportar solo precisión y latencia como si fueran el éxito de la función.
- Definir “tarea completada” a nivel de modelo.
- Tomar la aceptación de sugerencias como prueba de calidad sin medir cuánto se edita después.
- Usar usuarios activos diarios o clics como indicadores de una función que los agentes invocan.
- No tener grupo de control y atribuir la mejora a la IA.
- Olvidar la verificación: si el usuario tarda más en revisar la salida que en hacer la tarea, la IA resta valor.
¿Cuándo NO conviene?
Cuando la función tiene un volumen tan bajo que las métricas son ruido, o cuando la tarea es tan subjetiva que ningún indicador la captura. En esos casos, combina métricas con entrevistas de usuario y observación directa. Para medir el retorno económico de la misma función, revisa el ROI de features de IA y, para la capa de observabilidad del modelo, la observabilidad de LLMs.