Evals como UX research: leer conversaciones reales para encontrar fallos

Tratar los evals como UX research es leer conversaciones reales, anotar fallos y agruparlos antes de escribir métricas. Cómo funciona el análisis de errores.

info Definición Rápida
Tratar los evals como UX research es empezar por conversaciones reales con el producto, anotar en cada una qué salió mal y agrupar esas notas en temas, antes de escribir cualquier métrica. Las métricas automáticas vienen después, y sirven para medir lo que la investigación ya encontró.

¿Por qué empezar por la investigación y no por la métrica?

Es tentador abrir un proveedor de evals, elegir métricas con nombres atractivos como «alucinación» o «toxicidad» y ver números. Hamel Husain y Shreya Shankar, que enseñan evals a equipos de producto, advierten contra eso. En su guía de preguntas frecuentes sobre evals escriben que las evaluaciones genéricas hacen perder tiempo y crean falsa confianza cuando se usan como medida de calidad. Su ejemplo son puntajes de utilidad o coherencia, y métricas de similitud de texto como BERTScore y ROUGE.

En otro texto, «A Field Guide to Rapidly Improving AI Products» (marzo de 2025), Husain describe el riesgo con una imagen: un equipo celebra que sube un puntaje de «utilidad» mientras los usuarios siguen sin poder completar tareas básicas. Es como optimizar el tiempo de carga de un sitio cuyo pago está roto.

La alternativa es la que usaría cualquier investigador de UX: observar comportamiento, anotarlo y buscar patrones de abajo hacia arriba. Lo que cambia es el material. En vez de sesiones de usabilidad, tienes trazas: el registro completo de lo que ocurre desde una consulta del usuario hasta la respuesta final, con mensajes, llamadas a herramientas y datos recuperados.

¿Qué es el análisis de errores?

Husain y Shankar lo llaman la actividad más importante de los evals y cuentan que han dedicado entre el 60 % y el 80 % del tiempo de desarrollo a análisis de errores y evaluación en los proyectos en que han trabajado. Tiene tres pasos:

  1. Open coding (codificación abierta). Una persona lee cada traza y escribe notas libres sobre cualquier problema que vea. Lo comparan con llevar un diario: observación primero, sin categorías todavía. Recomiendan partir de unas 100 trazas diversas y anotar tú mismo al menos las primeras 30 antes de revisar sugerencias de un agente.
  2. Agrupación. Las notas se agrupan en una taxonomía de fallos y se cuentan. Los temas se convierten en modos de fallo concretos, que se pueden evaluar como sí o no: «inventó una fecha de entrega», «no pidió confirmación antes de cancelar». Prefieren etiquetas binarias a escalas de 1 a 5, porque obligan a pensar con más claridad y a etiquetar de forma más consistente.
  3. Seguir hasta saturar. Se continúa revisando mientras las trazas nuevas sigan revelando fallos o cambiando los que ya tienes. Pasadas las 100, sigue si todavía estás aprendiendo.

Un detalle práctico: al empezar, anota solo el primer fallo de cada traza. Un error temprano suele causar los siguientes, y corregir el origen simplifica todo lo demás.

¿Cómo se ve en un caso real?

En la guía de campo de Husain, un equipo empezó con una hoja de cálculo donde cada fila era una conversación, escribió notas abiertas sobre las conductas no deseadas y luego construyó con ayuda de un LLM una taxonomía de fallos. Al contar la frecuencia de cada problema, tres de ellos explicaban más del 60 % de los errores. El manejo de fechas fallaba el 66 % de las veces; tras arreglos dirigidos, el éxito subió del 33 % al 95 %. Husain los presenta como resultados de ese equipo, no como cifras generales.

Esa guía también recomienda construir un visor de datos propio, con todo el contexto de una conversación en una sola pantalla y feedback de un clic, y lo considera la inversión de mayor impacto para estos equipos. Para quien diseña, es una herramienta de investigación: igual que un tablero de afinidad, existe para que mirar los datos sea barato.

¿Cómo se aplica en el diseño?

El método se parece mucho a una sesión de hallazgos. Cada nota es una observación con evidencia; cada tema es un patrón que merece una decisión de producto o de diseño. Y contar importa: sin frecuencias, todos los temas parecen igual de urgentes.

También cambia lo que diseñas. Si el análisis muestra que el asistente inventa plazos de entrega, el arreglo puede estar en la interfaz: mostrar de dónde sale la fecha o pedir confirmación antes de prometerla. El eval solo mide si el arreglo funcionó.

Hay además una razón teórica para mirar antes de medir. En «Who Validates the Validators?» (Shankar y otros, 2024), un estudio cualitativo describe la criteria drift: las personas necesitan criterios para calificar las salidas, pero calificarlas las ayuda a definir esos criterios. Algunos criterios dependen de las salidas concretas que se ven y no se pueden fijar por adelantado. Por eso conviene leer primero y definir después qué significa «bien».

¿Cuándo NO conviene?

  • Cuando no tienes trazas reales. Los datos sintéticos sirven para empezar o para probar fallos raros, pero no dicen qué tan frecuente es un fallo en producción. Compáralos con datos reales en cuanto los haya.
  • Cuando nadie del equipo conoce el dominio. Un revisor sin contexto anota ruido. Husain y Shankar dicen que subcontratar el análisis de errores suele ser un gran error, y recomiendan que una persona experta del dominio tome las decisiones finales de calidad.
  • Cuando el análisis se queda en un documento. La agrupación tiene que terminar en decisiones y en evals concretos.

Ejemplo

Ejemplo ilustrativo: un equipo de producto de un servicio de citas revisa 100 conversaciones de su asistente. La persona de producto lee cada una y escribe una nota sobre el primer fallo. Al agrupar, aparecen tres temas: el asistente confirma citas en horarios cerrados (23 casos), no pregunta la zona horaria (14) y responde en inglés a usuarios que escriben en español (6). Eligen el primero: lo corrigen en el prompt y en la interfaz, y solo entonces escriben un eval para ese modo de fallo.

Para el marco general, lee qué son los evals. Para ver cómo se usan modelos como jueces, LLM-as-judge. Para el conjunto de casos que resulta de este análisis, golden datasets. Y para la parte de investigación con personas, cómo investigar productos que usan IA.

Errores comunes

  • Empezar con métricas genéricas de alucinación o toxicidad porque son fáciles de activar.
  • Subcontratar el análisis de errores a alguien sin contexto del producto.
  • Anotar todo lo que se ve, sin priorizar el primer fallo de cada traza.
  • Agrupar sin contar.
  • Olvidar que el análisis es continuo. Cuando cambia el producto, cambian los fallos.

Fuentes

Preguntas frecuentes

¿Qué significa tratar los evals como UX research?
Empezar leyendo conversaciones reales con el producto, anotando qué salió mal en cada una y agrupando esas notas en temas, antes de escribir cualquier métrica automática. Es el mismo método de investigación cualitativa aplicado a salidas de IA.
¿Cuántas conversaciones hay que revisar a mano?
Hamel Husain y Shreya Shankar recomiendan revisar al menos 100 trazas diversas, anotando tú mismo las primeras 30 antes de mirar sugerencias de un agente, y seguir mientras sigas aprendiendo.
¿Qué es el análisis de errores o open coding en evals?
Es que una persona lea cada traza y escriba notas abiertas sobre los problemas que ve. Después esas notas se agrupan en categorías y se cuentan para decidir qué arreglar primero.
¿Quién debe anotar los fallos?
Un experto del dominio, por ejemplo la persona de producto o soporte que conoce el negocio. Los autores advierten que subcontratar el análisis de errores suele ser un gran error.