Feedback del usuario en IA: pulgares, correcciones y qué significan de verdad
El feedback del usuario en IA incluye pulgares, reportes y correcciones. Cómo diseñarlo para que sirva, leerlo sin engañarte y combinarlo con muestreo.
¿Qué tipos de feedback existen?
Conviene separar tres grupos, porque cada uno dice algo distinto:
| Tipo | Ejemplos | Qué revela | Limitación |
|---|---|---|---|
| Explícito | Pulgar arriba o abajo, reporte de contenido, encuesta | Que algo no gustó, a veces por qué | Pocas personas lo usan |
| Implícito | Copiar, regenerar, editar, cerrar sin usar | Que la respuesta sirvió o no, en la práctica | Ambiguo: regenerar puede ser curiosidad |
| Corrección | Reescribir una parte, cambiar una categoría, deshacer | Exactamente qué faltó | Solo aparece cuando la persona usa la salida |
Las correcciones son las más útiles para diseño. Cuando alguien cambia la categoría de un gasto o reescribe la primera frase de un correo, está diciendo qué debía ser distinto, sin que tengas que preguntarle.
¿Por qué el pulgar no basta?
Un pulgar abajo sin motivo es una señal pobre. No distingue entre “la respuesta estaba mal”, “no era lo que quería” y “me equivoqué de botón”. Además, el feedback explícito solo llega de quien se toma la molestia.
La recomendación de Hamel Husain es usar el feedback para encontrar trazas que revisar, no como la medida final. Lo dice con claridad: el feedback sirve para acotar problemas, pero deja fuera los que nadie reporta. Por eso propone mantener trazas aleatorias en cada lote de revisión, para descubrir fallos que las señales actuales no describen.
Anthropic llega a una conclusión parecida en su guía sobre evals de agentes: el feedback de usuarios descubre problemas que no anticipaste y trae ejemplos reales, pero es escaso y autoseleccionado, tiende a mostrar los problemas graves y rara vez explica por qué falló algo. Su recomendación es combinarlo con monitoreo de producción, revisión manual de transcripciones (por ejemplo, leer una muestra cada semana) y pruebas A/B.
Esto tiene una consecuencia de diseño: si confías solo en los pulgares, tu producto solo mejora en lo que a sus usuarios más expresivos les molesta.
¿Cómo se diseña un feedback útil?
La biblioteca HAX de Microsoft, dedicada a la interacción humano-IA, tiene una guía llamada «Encourage granular feedback» (fomentar el feedback granular). Sus patrones son especialmente útiles aquí:
- Pedir feedback explícito sobre salidas individuales, o sobre salidas seleccionadas, en lugar de sobre toda la conversación.
- Reportar contenido inapropiado como un camino aparte.
Traducido a decisiones concretas:
- Pregunta el motivo al pulgar abajo. Un menú corto con tres o cuatro categorías: incorrecto, incompleto, no aplica, otro. Que tome cinco segundos.
- Ata el feedback a la respuesta. Cada pulgar debe quedar asociado a un mensaje concreto, con su contexto.
- Haz que corregir sea barato. Editar en línea, cambiar una categoría con un clic, deshacer. Cada corrección debe guardarse con la versión original.
- Explica qué pasa con el feedback. Una línea que diga si la respuesta se revisa o si el sistema aprende de ella. Si no lo sabes, no lo prometas.
- Aclara la privacidad. Si el feedback se usa para entrenar o evaluar, dilo y ofrece salirse. Ese tema tiene su propia página: consentimiento para entrenar con datos del usuario.
¿Cómo se lee sin engañarse?
Hay cuatro trampas comunes:
- Sesgo de expresividad: los usuarios que dan pulgares no son todos los usuarios.
- Ambigüedad del implícito: regenerar una respuesta puede significar que quería otra, o que la anterior tenía un error menor. Hay que mirar qué pasó después.
- Sesgo hacia lo grave: según Anthropic, el feedback de usuarios tiende a señalar los problemas severos y deja pasar los pequeños.
- Acumulación sin categoría: diez mil pulgares abajo sin motivo no dicen qué arreglar.
La lectura correcta combina tres fuentes: el feedback explícito para acotar, las correcciones para entender, y un muestreo aleatorio para descubrir lo que nadie reportó.
¿Cuándo NO conviene pedir feedback?
- Cuando el usuario tiene que interrumpir su tarea para dar feedback en cada respuesta. Eso se vuelve ruido.
- Cuando no vas a leer el feedback. Un botón que no cambia nada erosiona la confianza.
- Cuando el feedback puede exponer datos personales sin que la persona lo sepa.
Ejemplo
Ejemplo ilustrativo: un asistente que redacta respuestas a clientes de una tienda en línea tiene pulgares en cada respuesta. Al principio, el 4% de las respuestas recibe pulgar abajo, sin motivo. El equipo agrega un menú de tres opciones al pulgar abajo: “dato incorrecto”, “tono”, “no era lo que pedí”. En dos semanas, el 60% de los pulgares elige “dato incorrecto”, y casi todos son fechas de envío. Además, el equipo revisa 40 respuestas al azar cada semana, porque el feedback no captura casos donde el cliente simplemente no respondió. Descubren que el asistente promete descuentos que no existen, algo que ningún usuario reportó porque no lo notó. Ese hallazgo llega solo por el muestreo aleatorio.
Para el registro técnico de las trazas y su relación con el feedback, lee observabilidad de LLMs. Para decidir qué medir con ese feedback, métricas de calidad de una feature de IA. Y para cómo se muestra la incertidumbre que puede motivar correcciones, cómo mostrar incertidumbre.
Errores comunes
- Poner pulgares sin preguntar el motivo, y luego no saber qué arreglar.
- Tratar el feedback como la única fuente de calidad.
- Dejar que las correcciones se pierdan y no quede la versión original.
- Usar el feedback para entrenar sin avisar al usuario.
- Mostrar el botón en todas las respuestas, incluidas las triviales, y generar ruido.