Incorporar feedback y revisión continua

El feedback de producción es valioso y sesgado. Quien pulsa «mal» no representa necesariamente a toda la población, y una valoración negativa no explica por qué falló el sistema.

El objetivo es convertir señales incompletas en casos reproducibles.

Captura feedback útil

Opciones:

• útil;
• incorrecta;
• incompleta;
• fuente;
• formato;
• unsafe;
• tool incorrecta.

Permite añadir corrección.

No obligues a escribir un ensayo.

Vincula con ejecución

Guarda:

• response_id;
• trace_id;
• version;
• timestamp;
• category.

Evita copiar prompt y respuesta completa si no es necesario.

Muestrea sin feedback

La ausencia de queja no significa calidad.

Muestrea:

• tareas críticas;
• nueva versión;
• nuevos usuarios;
• abstenciones;
• casos caros;
• low-confidence proxies;
• tool-heavy.

Compara feedback explícito y muestra aleatoria.

Clasifica causa

Taxonomía:

data
retrieval
prompt
model
tool
policy
UX
user expectation
provider

No arregles todo cambiando prompt.

Convierte fallo en eval

Proceso:

signal → reproduce → label → add case → fix → regression → deploy

No añadas automáticamente cualquier queja al dataset.

Primero valida:

• estaba mal;
• cuál era el esperado;
• se puede usar el dato.

Evita contaminación

Si el equipo optimiza continuamente sobre la misma muestra, pierde valor como test.

Promueve:

• casos nuevos a regression;
• conserva holdout;
• renueva audit set.

Revisión temporal

Programa:

• semanal: issues;
• mensual: quality sample;
• trimestral: dataset;
• por release: regression;
• por proveedor: deprecations.

La frecuencia depende del sistema.

Cambios externos

Reabre evaluación cuando cambia:

• modelo;
• proveedor;
• índice;
• datos;
• tool;
• política;
• regulación;
• usuarios.

No esperes feedback para detectar una deprecation.

Feedback y entrenamiento

No asumas que puedes reutilizar interacciones para entrenamiento.

Define:

• finalidad;
• consentimiento/base;
• acceso;
• retención;
• proveedor.

Separar «mejora del producto» de «entrenamiento de modelo» evita decisiones implícitas.

Métricas del ciclo

• time to triage;
• time to reproduce;
• % convertido en regression;
• repeat incidents;
• backlog crítico;
• reviewer disagreement.

No optimices «número de tickets cerrados».

Ejemplo

Diez usuarios marcan «mala respuesta».

Clasificación:

• 4 fuente obsoleta;
• 3 pregunta ambigua;
• 2 output correcto pero formato malo;
• 1 model hallucination.

Soluciones distintas.

Cierra el loop con producto

No todo feedback requiere cambio técnico.

Puede indicar:

• expectativa incorrecta;
• onboarding;
• copy;
• UX.

Involucra producto.

Disagreement review

Si revisor humano y usuario discrepan, no etiquetes automáticamente uno como correcto.

Revisa evidencia y política.

Feedback adversarial

Un usuario puede intentar influir en el sistema.

No uses un comentario:

«siempre responde X»

como memoria de verdad.

Valida antes de persistir.

Active learning

Puedes priorizar revisión de casos:

• raros;
• inciertos;
• discrepantes.

No significa entrenar automáticamente.

Es una estrategia de muestreo.

Aging

Un caso de regresión puede quedar obsoleto.

Marca:

• current;
• deprecated.

No borres historia sin motivo.

Métricas de mejora

Mide:

• recurrence;
• regression catch rate;
• escape rate.

Escape: fallo que llegó a producción.

Si sube, la suite no representa bien el sistema.

Backlog

Prioriza por:

• severity;
• frequency;
• leverage.

No FIFO.

Change review

Una corrección puede empeorar otro segmento.

Toda mejora vuelve a gates.

Documenta no-fix

A veces decides no corregir:

• coste alto;
• edge fuera de scope.

Registra la decisión y limitación.

Comunica known limitations

Los usuarios deben conocer límites relevantes.

No presentes un backlog conocido como «sistema fiable» sin contexto.

Artefacto: registro de mejora reproducible

Para cada señal que merece trabajo, crea una entrada mínima:

signal_id
trace_id
category
severity
reproduction
expected_behavior
owner
fix_version
regression_case
status

Este registro evita que feedback, incidente y cambio queden desconectados. Un ticket no se considera resuelto únicamente porque se cambió el prompt: debe existir evidencia de reproducción, corrección y no regresión cuando el caso lo justifique.

Mantén una muestra de control

Además de casos nacidos de quejas, conserva una muestra aleatoria o estratificada de producción. Sirve para detectar fallos que los usuarios toleran, no identifican o nunca reportan.

Compara periódicamente:

• feedback explícito;
• muestra de control;
• segmentos críticos;
• holdout.

Si solo mejoras lo que recibe votos negativos, el sistema puede optimizarse para usuarios muy activos y degradarse en poblaciones silenciosas.

Ejercicio

Toma 20 señales ficticias.

Para cada una:

• categoría;
• reproducible;
• expected;
• dataset;
• owner;
• change;
• regression.

Construye un dashboard de backlog por riesgo y antigüedad.

Resultado de la lección

Debes terminar con un ciclo de mejora donde producción alimenta la evaluación sin convertir feedback crudo en verdad. La última lección integrará todo en una revisión de readiness y un plan de operación.