Módulo 7: El lazo de datos y de retroalimentación
4. El lazo de retroalimentación como decisión de diseño
Descripción
Al terminar esta lección vas a entender que el feedback no es una sola cosa, sino tres señales distintas, y que capturarlas es una decisión de arquitectura que se toma antes de necesitarlas —porque no se puede recuperar el feedback que no capturaste—. En la lección 3 montaste la observabilidad y viste que necesitas una "señal de calidad"; esta lección abre esa señal y descubre que dentro hay tres fuentes muy distintas, cada una midiendo algo que las otras no ven: el thumbs up/down explícito que el usuario da a propósito, la corrección que hace cuando edita la propuesta del modelo, y la acción que toma tras la sugerencia —si la mandó tal cual, la reescribió, o escaló a otra persona—. Las tres son feedback, pero no coinciden entre sí, y la más valiosa suele ser la que menos se instrumenta.
Esto importa porque el punto donde capturas el feedback es una decisión de diseño con consecuencias irreversibles. Si no pusiste el botón de thumbs, no tienes thumbs. Si no registraste el texto que el agente humano terminó enviando, no puedes saber qué corrigió. Si no guardaste en qué resultado hizo click el usuario, la señal de acción se perdió para siempre. A diferencia de un bug, que puedes arreglar cuando lo descubres, el feedback no capturado no se recupera: el usuario ya se fue, la interacción ya pasó, y ningún cambio futuro te devuelve el dato que no guardaste. Por eso la captura de feedback no es una feature que agregas "cuando haya tiempo"; es una decisión que la arquitectura tiene que tomar desde el diseño, igual que decides desde el diseño qué campos guarda tu base de datos.
Conexión con el módulo: esta lección arma la materia prima del lazo. La lección 2 te dio la motivación (el flywheel), la lección 3 el instrumento para ver la calidad (la observabilidad); aquí construyes el mecanismo que produce esa señal de calidad —el feedback_loop que captura lo que los usuarios dicen y hacen—. Es la pieza que alimenta a la siguiente: la lección 5 toma este feedback capturado y lo cierra convirtiéndolo en casos del eval-set, y la lección 7 lo enruta a la palanca correcta. Sin una captura bien diseñada, no hay nada que cerrar ni que enrutar. Y una conexión con el módulo 6 (la cáscara determinista): el punto donde el humano revisa y corrige la propuesta del modelo antes de enviarla es, a la vez, la capa de contención del M6 y el punto de captura de feedback de este módulo —la misma revisión humana que impide que el modelo mande una respuesta mala genera la corrección que mejora al modelo—.
Analogía: el mesero que observa tres cosas distintas
Vuelve al restaurante de la lección 1, pero mira más de cerca cómo el buen mesero lee a sus comensales. No se queda con una sola señal; observa tres, y sabe que dicen cosas distintas.
La primera es lo que el comensal dice explícitamente: si al final le pregunta "¿todo bien?" y el comensal responde "excelente" o "el plato estaba salado". Es directo y claro, pero tiene un problema: mucha gente dice "todo bien" por cortesía aunque no haya quedado satisfecha. Es el thumbs up/down: la señal más explícita, pero también la más contaminada por la cortesía y el sesgo de quien se molesta en darla.
La segunda es lo que el comensal corrige: pide la carne más cocida, aparta la cebolla, agrega sal. No dijo "el plato está mal", pero su corrección revela exactamente qué le faltó. Es la corrección: más específica que el thumbs, porque no solo dice "no me gustó" sino "así debió ser". Cuando un comensal pide algo distinto de lo que le sirvieron, te está entregando la respuesta correcta en bandeja.
La tercera —y la más honesta— es lo que el comensal hace: si se comió todo el plato o lo dejó a la mitad, si volvió la semana siguiente o no volvió nunca, si recomendó el lugar o no lo mencionó. La acción no depende de que el comensal se moleste en opinar ni de su cortesía: es lo que de verdad pasó. Un comensal puede decir "todo bien" (thumbs up) y dejar medio plato (acción negativa); la acción es la que no miente. El mejor mesero pesa las tres, pero cuando el thumbs y la acción se contradicen, le cree a la acción.
Tu componente de IA tiene las mismas tres señales. El thumbs up/down es lo que el usuario dice explícitamente. La corrección es cuando el usuario (o un agente humano) edita la propuesta del modelo —te entrega la respuesta correcta—. Y la acción es lo que el usuario hace: manda la respuesta tal cual, la reescribe, hace click en el resultado 5 en vez del 1, escala a un humano. Diseñar el lazo de retroalimentación es decidir cuáles de estas tres capturas y dónde las capturas —y la lección de esta clase es que las tres importan, que no coinciden, y que la acción, la más difícil de instrumentar, es la más honesta—.
Ejemplo trabajado: las tres señales que no coinciden
No vamos a decir que las tres señales difieren: lo vamos a ver. Modelamos el feedback_loop del agente de soporte de Mercado, donde un agente humano revisa cada propuesta del modelo antes de enviarla al cliente. Por cada interacción capturamos las tres señales —el thumbs del cliente, si el humano corrigió el texto, y qué acción tomó el humano— y derivamos las métricas de cada una. Fíjate en cómo los tres números salen distintos, y qué revela esa diferencia.
# Leccion 04 (M7) — el FEEDBACK LOOP como decision de diseno. SIMULADO.
# Cero red, cero API, cero claves. Determinista.
#
# El feedback no es una cosa: son TRES senales distintas, y cada una hay que
# DISENARLA en el punto de captura (no se puede recuperar lo que no capturaste):
# 1) EXPLICITO : el usuario da thumbs up/down.
# 2) CORRECCION : el humano edita la propuesta del modelo antes de usarla.
# 3) ACCION : que hizo el humano tras la sugerencia (la mando tal cual,
# la reescribio, o escalo). El feedback mas honesto: no opina, actua.
# El feedback_loop: una fila por interaccion del agente de soporte. El humano
# (un agente de Mercado) revisa la propuesta del modelo antes de enviarla al cliente.
# Campos: input, propuesta del modelo, thumbs del cliente, texto final que se envio,
# y la accion del humano (sent_as_is / edited / rewrote / escalated).
FEEDBACK_LOG = [
# (id, input, proposal, customer_thumbs, final_sent, human_action)
("i1", "donde esta mi pedido", "Puedes ver el tracking en tu perfil.",
"up", "Puedes ver el tracking en tu perfil.", "sent_as_is"),
("i2", "cuanto tarda el envio", "El envio tarda de 3 a 5 dias habiles.",
"up", "El envio tarda de 3 a 5 dias habiles.", "sent_as_is"),
("i3", "el producto llego roto", "Lo siento, no tengo informacion sobre eso.",
"down", "Lamentamos eso. Puedes pedir un reembolso desde el pedido.", "rewrote"),
("i4", "mi cupon no funciona", "Los cupones siempre funcionan.",
"down", "Revisa la vigencia del cupon; quiza ya expiro.", "rewrote"),
("i5", "puedo pagar en cuotas", "Si, puedes pagar en cuotas.",
"up", "Si, puedes pagar en cuotas sin interes con tarjeta.", "edited"),
("i6", "no recibi mi factura", "No manejamos facturas.",
"down", None, "escalated"),
("i7", "como devuelvo un producto", "Entra a tu pedido y pulsa Devolver.",
"up", "Entra a tu pedido y pulsa Devolver.", "sent_as_is"),
("i8", "quiero cancelar", "Puedes cancelar si aun no se envio.",
"up", "Puedes cancelar el pedido si aun no fue enviado.", "edited"),
]
N = len(FEEDBACK_LOG)
# --- Senal 1: EXPLICITA (approval_rate desde los thumbs del cliente). ---
ups = sum(1 for r in FEEDBACK_LOG if r[3] == "up")
approval_rate = ups / N
# --- Senal 2: CORRECCION (que fraccion el humano tuvo que tocar el texto). ---
corrected = sum(1 for r in FEEDBACK_LOG if r[5] in ("edited", "rewrote"))
correction_rate = corrected / N
# --- Senal 3: ACCION (que hizo el humano: la senal que no miente). ---
from collections import Counter
actions = Counter(r[5] for r in FEEDBACK_LOG)
accepted = actions["sent_as_is"]
acceptance_rate = accepted / N
print("=== El feedback_loop: 3 senales capturadas por interaccion ===")
print(f"{'id':<4}{'thumbs':<8}{'accion_humano':<14}input")
for r in FEEDBACK_LOG:
print(f"{r[0]:<4}{r[3]:<8}{r[5]:<14}{r[1]}")
print()
print("=== Las 3 senales derivadas (cada una mide algo distinto) ===")
print(f" 1) EXPLICITA approval_rate : {ups}/{N} = {approval_rate:.0%} (thumbs up del cliente)")
print(f" 2) CORRECCION correction_rate : {corrected}/{N} = {correction_rate:.0%} "
f"(el humano edito o reescribio)")
print(f" 3) ACCION acceptance_rate : {accepted}/{N} = {acceptance_rate:.0%} "
f"(mando la propuesta tal cual)")
print()
print(" desglose de acciones del humano:")
for act, cnt in actions.most_common():
print(f" {act:<12}: {cnt}")
print()
# Las senales NO coinciden, y ahi esta el valor: un thumbs_up con edicion
# esconde una correccion (i5, i8). La accion revela lo que el thumbs no dice.
edited_but_up = [r[0] for r in FEEDBACK_LOG if r[3] == "up" and r[5] in ("edited", "rewrote")]
print(f" casos con thumbs_up PERO que el humano tuvo que corregir: {edited_but_up}")
print(" -> el approval_rate solo se veria 'bien', pero la accion delata trabajo humano oculto.")Qué esperar. Al correrlo, la salida es exactamente esta:
=== El feedback_loop: 3 senales capturadas por interaccion ===
id thumbs accion_humano input
i1 up sent_as_is donde esta mi pedido
i2 up sent_as_is cuanto tarda el envio
i3 down rewrote el producto llego roto
i4 down rewrote mi cupon no funciona
i5 up edited puedo pagar en cuotas
i6 down escalated no recibi mi factura
i7 up sent_as_is como devuelvo un producto
i8 up edited quiero cancelar
=== Las 3 senales derivadas (cada una mide algo distinto) ===
1) EXPLICITA approval_rate : 5/8 = 62% (thumbs up del cliente)
2) CORRECCION correction_rate : 4/8 = 50% (el humano edito o reescribio)
3) ACCION acceptance_rate : 3/8 = 38% (mando la propuesta tal cual)
desglose de acciones del humano:
sent_as_is : 3
rewrote : 2
edited : 2
escalated : 1
casos con thumbs_up PERO que el humano tuvo que corregir: ['i5', 'i8']
-> el approval_rate solo se veria 'bien', pero la accion delata trabajo humano oculto.
Lee los tres números —62%, 50%, 38%— porque su desacuerdo es el corazón de la lección.
Las tres señales dan tres números distintos, y todos son ciertos. El approval_rate (señal explícita) es 62%: cinco de ocho clientes marcaron thumbs_up. La correction_rate (señal de corrección) es 50%: en cuatro de ocho, el agente humano tuvo que editar o reescribir la propuesta del modelo. La acceptance_rate (señal de acción) es 38%: solo en tres de ocho el humano mandó la propuesta tal cual, sin tocarla. No hay contradicción entre ellos; cada uno mide algo distinto. El approval_rate mide la satisfacción del cliente final; la correction_rate mide cuánto trabajo tuvo que hacer el humano encima del modelo; la acceptance_rate mide qué fracción de las propuestas fueron directamente útiles. Tres preguntas distintas, tres respuestas distintas.
La acción es la señal más honesta, y es la más dura. Fíjate en el orden: 62% (thumbs) → 50% (corrección) → 38% (acción). La señal de acción da el número más bajo, y no es casualidad: es la más exigente porque no depende de opiniones ni de cortesía, sino de lo que de verdad pasó. El thumbs del cliente puede ser generoso ("respondió, le doy up") aunque el agente humano haya tenido que reescribir la respuesta entera antes de enviarla. La acción del humano —¿la mandó tal cual?— no tiene esa generosidad: si la editó, la editó, y eso queda registrado. Por eso, cuando quieres saber qué tan útil es de verdad tu componente, la acción te da la respuesta más sincera.
El caso revelador: thumbs_up que escondían una corrección. Mira las dos últimas líneas de la salida. Los casos i5 y i8 tienen thumbs_up del cliente —el cliente quedó contento— pero el agente humano tuvo que editar la propuesta antes de enviarla ("puedo pagar en cuotas" → el modelo dijo la mitad, el humano completó "sin interés con tarjeta"). Si solo miraras el approval_rate, estos casos contarían como éxitos limpios. Pero la señal de acción los delata: hubo trabajo humano oculto que el thumbs no captura. Esto tiene una consecuencia práctica enorme —si estás midiendo el ahorro que te da el agente de soporte, el approval_rate te haría creer que el modelo resolvió i5 e i8 solo, cuando en realidad un humano tuvo que intervenir—. La señal de acción es la que te dice cuánto trabajo humano de verdad ahorraste, y es justo la que la mayoría de los equipos no instrumenta.
La lección en una frase: captura las tres señales, porque cada una responde una pregunta distinta, y cuando se contradicen, créele a la acción.
Las tres señales, y por qué el punto de captura es una decisión de arquitectura
El ejemplo mostró las tres señales; vale la pena entender qué hace a cada una útil y por qué capturarlas es una decisión que se toma en el diseño, no después.
La señal explícita (thumbs up/down): barata de pedir, cara de conseguir. Es la más fácil de instrumentar —un botón— y la más directa —el usuario te dice sí o no—. Su debilidad es doble: primero, el sesgo de quien responde —la gente que se molesta en marcar suele ser la muy contenta o la muy enojada, así que el approval_rate no representa a la mayoría silenciosa—; segundo, la cortesía y la fatiga —mucha gente marca up por inercia, o no marca nada—. Es una señal valiosa pero hay que leerla sabiendo de dónde viene. Decisión de arquitectura: dónde pones el botón, si es obligatorio u opcional, y cómo evitas que el sesgo domine.
La señal de corrección: la respuesta correcta, servida. Cuando el usuario o un agente humano edita la propuesta del modelo, no solo te dice que estaba mal —te da la versión correcta—. Esta es la señal más rica para cerrar el lazo, porque la corrección se convierte casi directamente en un caso de eval (input → la corrección es el criterio; lección 5) o en un ejemplo de prompt. Su requisito de captura es exigente: tienes que registrar tanto la propuesta del modelo como el texto final que se usó, para poder comparar y detectar que hubo corrección. Si solo guardas el texto final, no sabes si el modelo lo generó o el humano lo reescribió. Decisión de arquitectura: guardar la propuesta original junto al resultado final —muchos sistemas guardan solo el final y pierden la señal de corrección para siempre—.
La señal de acción: lo que de verdad pasó, gratis pero difícil de instrumentar. La acción —mandó tal cual, editó, reescribió, escaló, hizo click aquí, reformuló la búsqueda— es la señal más honesta porque no requiere que el usuario opine: surge de su comportamiento natural. Y muchas veces es gratis en el sentido de que el usuario ya la produce (ya hace click, ya edita, ya escala) sin trabajo extra. Su dificultad es de instrumentación: hay que diseñar el sistema para capturar la acción, y esa acción a veces ocurre en un lugar del flujo que no estabas registrando (¿guardas en qué resultado se hizo click?, ¿registras que el humano escaló?). Decisión de arquitectura: identificar las acciones que son señal y asegurarte de capturarlas en el punto donde ocurren.
Y el principio que las une, que es la tesis de la lección: no puedes recuperar el feedback que no capturaste. Esto hace la captura distinta de casi cualquier otra decisión de software. Un algoritmo lo puedes cambiar mañana; un esquema de base de datos lo puedes migrar; pero el thumbs que el usuario habría dado ayer, si no pusiste el botón, no existe y no existirá. Por eso el diseño del lazo de retroalimentación es una decisión temprana y deliberada: cuando diseñas la feature de IA, decides qué señales vas a capturar y dónde, sabiendo que las que no captures se pierden. Es el mismo tipo de decisión que "¿qué campos guarda esta tabla?": lo que no guardas hoy, no lo tienes mañana.
El punto de captura, en el flujo del agente de soporte:
cliente ──pregunta──► [ modelo ] ──propuesta──► [ humano revisa ] ──respuesta──► cliente
│ │ │
(guarda tokens, (guarda la accion: (guarda el thumbs
costo, latencia) sent_as_is/edited/ up/down del cliente)
│ rewrote/escalated, │
│ Y el texto final) │
▼ ▼ ▼
┌──────────────────────── feedback_loop ───────────────────────────┐
│ cada senal se captura EN SU PUNTO. Lo que no se captura ahi, │
│ se pierde: no hay forma de recuperarlo despues. │
└───────────────────────────────────────────────────────────────────┘
Errores comunes
Capturar solo el thumbs y creer que es "el feedback" (de alcance). Qué pasa: el equipo pone un botón de thumbs up/down, mide el approval_rate, y da por hecho que ya tiene el lazo de retroalimentación. Se pierde las otras dos señales —más ricas—: no sabe cuánto corrigen los humanos (porque no guarda la propuesta original) ni qué acciones toman (porque no las instrumenta). Su approval_rate, además, está sesgado por quién se molesta en marcar. Resultado: una foto parcial y optimista de la calidad, como en el ejemplo, donde el thumbs decía 62% pero la acción decía 38%. Por qué pasa: el thumbs es lo más fácil de agregar y lo más obvio, así que se toma como "el feedback" a secas. Cómo detectarlo: si tu única señal de calidad es el thumbs, no ves el trabajo humano oculto ni tienes las correcciones para cerrar el lazo. Cómo corregirlo: captura las tres señales —thumbs, corrección y acción—; cada una responde una pregunta que las otras no.
Guardar solo el resultado final y perder la corrección (de omisión irreversible). Qué pasa: el sistema registra la respuesta que se envió al cliente, pero no la propuesta original del modelo. Cuando un agente humano reescribe la respuesta, el sistema guarda la versión reescrita como si el modelo la hubiera generado. Se pierden dos cosas: la señal de que hubo corrección (no puedes calcular la correction_rate) y —peor— la corrección misma, que era la respuesta correcta lista para volverse un caso de eval. Por qué pasa: guardar solo el resultado final parece suficiente ("es lo que el cliente vio") y ahorra almacenamiento. Cómo detectarlo: si no puedes comparar lo que el modelo propuso con lo que de verdad se usó, no puedes ver las correcciones. Cómo corregirlo: guarda la propuesta del modelo junto al resultado final; la diferencia entre las dos es la corrección, y la corrección es oro para cerrar el lazo (lección 5). Y recuerda: esto es irreversible —las correcciones que no guardaste este mes no se recuperan—.
Instrumentar la captura "después", cuando ya se necesita (de proceso). Qué pasa: el equipo lanza la feature sin captura de feedback ("primero que funcione, el feedback lo agregamos después"), y cuando meses más tarde quiere mejorar la feature con datos de uso, descubre que no tiene ninguno —todo ese uso pasó sin dejar rastro—. Tiene que empezar a capturar desde cero y esperar meses más para acumular datos, habiendo desperdiciado todo el tráfico anterior. Por qué pasa: la captura no es visible para el usuario (no es una feature vendible) y compite por prioridad con cosas que sí se ven. Cómo detectarlo: si tu feature de IA lleva tiempo en producción y no tienes un historial de feedback, ya perdiste esos datos. Cómo corregirlo: diseña la captura desde el inicio, como parte de la arquitectura de la feature —es tan fundamental como decidir qué guarda tu base de datos, porque el feedback no capturado no se recupera—.
Ejercicios
Ejercicio 1 — El mesero y las tres señales. Para cada una de las tres cosas que observa el buen mesero, di qué señal del feedback de IA representa, qué la hace valiosa y cuál es su debilidad. Luego explica por qué, cuando el thumbs y la acción se contradicen, hay que creerle a la acción.
Ver solución
- Lo que el comensal dice ("todo bien" / "estaba salado") → la señal explícita (thumbs up/down). Valiosa porque es directa y clara. Debilidad: contaminada por la cortesía (mucha gente dice "todo bien" por educación) y por el sesgo de quién se molesta en responder (los muy contentos o los muy enojados).
- Lo que el comensal corrige (pide la carne más cocida, aparta la cebolla) → la señal de corrección. Valiosa porque no solo dice "estuvo mal" sino "así debió ser" —te entrega la respuesta correcta—. Debilidad: requiere capturar tanto lo que se sirvió (la propuesta) como lo que se pidió corregir (el resultado), y solo aparece cuando el usuario se toma el trabajo de corregir.
- Lo que el comensal hace (se comió todo o dejó medio plato, volvió o no) → la señal de acción. Valiosa porque es lo que de verdad pasó, sin depender de opiniones ni cortesía —la más honesta—. Debilidad: la más difícil de instrumentar, porque hay que diseñar el sistema para capturar la acción en el punto donde ocurre.
Cuando el thumbs y la acción se contradicen, hay que creerle a la acción porque el thumbs es lo que el usuario dice y la acción es lo que hace, y las palabras se pueden dar por cortesía o inercia mientras que la acción refleja la realidad. En el ejemplo, i5 e i8 tenían thumbs_up pero el humano tuvo que editar la propuesta: el thumbs decía "bien", la acción decía "tuve que corregirlo". La acción reveló el trabajo humano que el thumbs escondía. Un comensal que dice "excelente" y deja medio plato no está mintiendo por maldad; simplemente su cortesía y su conducta no coinciden, y la conducta es la que cuenta.
Ejercicio 2 — El ahorro que no era. El equipo de Mercado reporta: "el agente de soporte tiene un approval_rate de 62%, así que resuelve solo la mayoría de los tickets y nos ahorra mucho trabajo humano". Con los datos del ejemplo (approval_rate 62%, correction_rate 50%, acceptance_rate 38%), explica por qué esa conclusión sobreestima el ahorro, y qué número deberían usar para medir el trabajo humano que de verdad se ahorró.
Ver solución
La conclusión sobreestima el ahorro porque usa el approval_rate (62%) para medir algo que el approval_rate no mide. El approval_rate dice qué fracción de clientes quedó contenta, no qué fracción de respuestas el modelo resolvió sin ayuda humana. Y esas dos cosas difieren mucho: en el ejemplo, casos como i5 e i8 tienen approval_rate positivo (cliente contento) pero requirieron que un agente humano editara la propuesta. El cliente quedó contento porque el humano intervino, no porque el modelo resolviera solo.
El número que mide el trabajo humano de verdad ahorrado es la acceptance_rate: 38% —la fracción de propuestas que el humano mandó tal cual, sin tocar—. Solo en esos casos el modelo hizo el trabajo completo y el humano no tuvo que intervenir. En el otro 62% (editó, reescribió, o escaló), hubo trabajo humano: el modelo dio un borrador que ayudó, pero no ahorró el humano por completo. Así que el ahorro real está más cerca del 38% que del 62%.
La moraleja de arquitectura: para medir el ahorro de un asistente que un humano supervisa, la señal correcta es la de acción (¿cuánto mandó sin tocar?), no la explícita (¿cuánto le gustó al cliente final?). Usar el approval_rate para estimar ahorro es el error del ejemplo, y solo se detecta si capturaste la señal de acción. Un equipo que solo mide thumbs no puede corregir este error porque no tiene el dato.
Ejercicio 3 — Diseña la captura para la búsqueda semántica. La búsqueda semántica de Mercado no tiene un agente humano que revise, ni un botón obvio de thumbs. Diseña su lazo de retroalimentación: (a) ¿qué señal de acción puedes capturar del comportamiento natural del usuario?, (b) ¿qué tendrías que guardar en el punto de captura para no perder esa señal?, y (c) ¿por qué la señal de acción es especialmente adecuada para esta feature?
Ver solución
- (a) La señal de acción de la búsqueda es el click: en qué posición del ranking hizo click el usuario (y señales relacionadas: si reformuló la query sin hacer click, si no hizo click en nada, si volvió a buscar lo mismo). Un click en el top-3 = la búsqueda puso lo relevante arriba; un click en la posición 5, o una reformulación sin click, = la búsqueda enterró lo relevante. El comportamiento del usuario ES la señal; no hace falta pedirle que opine.
- (b) En el punto de captura hay que guardar, por cada búsqueda: la query, el ranking completo que se mostró, y en qué posición (y sobre qué producto) hizo click el usuario —o que no hizo click—. Si solo guardas la query y el resultado, pierdes la posición del click, que es la señal. Necesitas la tripleta (query, ranking mostrado, click) para saber si el ranking acertó. Y como toda captura, es irreversible: los clicks de las búsquedas que no instrumentaste se perdieron.
- (c) La señal de acción es especialmente adecuada aquí porque la búsqueda no tiene una revisión humana ni un momento natural para pedir un thumbs —nadie va a marcar up/down en cada búsqueda—. El click, en cambio, ocurre de todos modos: el usuario ya hace click como parte de usar la búsqueda, así que la señal es gratis (no requiere trabajo extra del usuario) y abundante (cada búsqueda la produce). Es feedback implícito de alto volumen, ideal para una feature de alto tráfico. Esta es exactamente la señal que usa el proyecto de la lección 8.
Resumen y siguiente paso
En esta lección construiste la materia prima del lazo: el feedback_loop que captura la señal de calidad. Viste que el feedback no es una sola cosa sino tres señales distintas —la explícita (thumbs up/down), la corrección (el humano edita la propuesta), y la acción (lo que el humano hace: la manda tal cual, la reescribe, escala)— con la analogía del mesero que observa las tres. Y las mediste: 62% de approval, 50% de correction, 38% de acceptance —tres números distintos, todos ciertos, cada uno respondiendo una pregunta distinta—, con el detalle revelador de que la acción es la más honesta (delató casos con thumbs_up que en realidad requirieron corrección humana). Entendiste la tesis de arquitectura: el punto de captura es una decisión de diseño temprana e irreversible, porque no se puede recuperar el feedback que no capturaste —guardar solo el resultado final pierde la corrección para siempre—.
Antes de avanzar deberías poder: nombrar las tres señales del feedback y qué mide cada una; explicar por qué la acción es la más honesta y cuándo créele a ella sobre el thumbs; reconocer que capturar solo el thumbs deja ciega la mayor parte del lazo; y justificar por qué el punto de captura se diseña desde el inicio (el feedback no capturado no se recupera).
Lo que sigue es el corazón del módulo: cerrar el lazo. Ya sabes por qué el flywheel importa (lección 2), cómo ver la calidad (lección 3) y cómo capturar el feedback (esta lección). En la lección 5 vas a hacer que ese feedback regrese a algo que mejora el sistema: los casos con thumbs_down y su corrección se van a convertir en casos nuevos del eval-set —el del módulo 3—. Vas a ejecutar la conversión y ver cómo el eval-set aumentado atrapa una regresión que el viejo dejaba pasar. Es el paso de "capturé el feedback" a "el feedback capturado hizo mejor al sistema, y lo puedo probar".
Recursos
- Chip Huyen — Designing Machine Learning Systems (O'Reilly) — el capítulo sobre feedback loops distingue el feedback explícito del implícito (la señal de acción) y trata el diseño del punto de captura como una decisión de arquitectura; la fuente conceptual de esta lección.
- Chip Huyen — AI Engineering (O'Reilly) — el tratamiento de cómo el feedback de usuario (thumbs, correcciones, comportamiento) alimenta la mejora de una aplicación de IA, y los sesgos de cada tipo de señal.
- martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — ubica la captura de feedback en el patrón del lazo de datos de una app con LLM; el marco arquitectónico. En inglés.
- Anthropic — documentación de Claude — la referencia conceptual sobre cómo instrumentar una aplicación con un LLM (registrar entradas, salidas y señales de uso) para poder evaluar y mejorar; sin fijar versión de modelo. En inglés.