1. Presentación del módulo: el lazo de datos y de retroalimentación

Descripción

Al terminar esta lección vas a entender la idea que sostiene todo el módulo, y que marca un giro respecto a los seis anteriores: un sistema AI-native bien diseñado no solo contiene la no-determinación del componente de IA, sino que la mejora con el tiempo, porque escucha a su propio uso y realimenta lo que escucha. En los módulos 1 a 6 construiste la cáscara determinista que protege al sistema del componente de IA: lo ubicaste tras una frontera, le pusiste presupuestos, una compuerta de eval, guardrails, resiliencia y una capa que valida sus acciones. Este módulo hace lo complementario: usa lo que el sistema aprende de sus usuarios para que el componente de IA sea cada vez mejor. Es la diferencia entre un sistema congelado —tan bueno el día de su lanzamiento como el día de su muerte— y uno que compone mejoras y se separa de sus competidores con el tiempo.

Esto importa porque la mejora de un sistema de IA rara vez viene de un modelo más grande; viene de un lazo de datos bien diseñado. El uso genera datos (¿qué preguntó el usuario?, ¿le sirvió la respuesta?, ¿qué hizo después?), esos datos revelan dónde falla el sistema, y esas fallas —una vez que las capturas y las realimentas— se vuelven las mejoras del sistema. Ese ciclo que se retroalimenta —uso → datos → mejor sistema → más uso— se llama flywheel, una rueda de inercia que, una vez que empieza a girar, cuesta cada vez menos mantener en movimiento. Pero el flywheel no aparece solo: hay que diseñarlo, con tres piezas que son el contenido del módulo —la observabilidad que te deja ver la calidad, el lazo de retroalimentación que captura la señal del usuario, y el acto de cerrar el lazo realimentando esa señal a algo que mejora el sistema—.

Conexión con el módulo: esta lección es el mapa, no el territorio. Aquí no construyes el lazo todavía; entiendes por qué las seis lecciones que siguen van en el orden que van. Primero la motivación: la lección 2 mide el flywheel —dos sistemas idénticos, uno con lazo y otro sin él, divergiendo con el tiempo—. Luego la precondición: la lección 3 monta la observabilidad para IA, porque no puedes mejorar lo que no ves, y un log de servidor clásico no ve la calidad. Luego la captura: la lección 4 diseña el lazo de retroalimentación —las tres señales del feedback y el punto donde se capturan—. Después el corazón: la lección 5 cierra el lazo convirtiendo el feedback en casos del eval-set del módulo 3. La lección 6 abre la decisión arquitectónica prompt vs RAG vs fine-tune —qué palanca mover, con qué perfil de latencia, costo y frescura—. Y la lección 7 es la síntesis: enrutar cada tipo de feedback a su palanca. La lección 8 —el proyecto— te pone a montar el lazo de datos de una feature de Mercado de punta a punta.

Tres analogías: el restaurante, la app de mapas y la caja de sugerencias

Antes de bajar al código, tres imágenes cotidianas que vas a reconocer en cada lección del módulo. Cada una captura una parte del lazo de datos.

El restaurante que anota qué platos se devuelven y ajusta el menú. Piensa en un restaurante bien llevado. No solo cocina y sirve; observa qué pasa con cada plato. ¿Cuáles se devuelven a la cocina a medio comer? ¿De cuáles pide la gente la receta? ¿Cuál se queda siempre en el menú sin que nadie lo ordene? El chef que presta atención convierte esa observación en cambios: retira el plato que nadie termina, sube al frente el que todos elogian, ajusta la sazón del que vuelve frío. El restaurante mejora porque escucha al comensal, no porque el chef sea un genio aislado. Y aquí está lo importante: esa escucha es deliberada —alguien decidió anotar qué se devuelve, alguien decidió preguntar—. Un restaurante que sirve y no mira nunca sabrá por qué su clientela se va. Ese acto de observar el uso y ajustar en consecuencia es el lazo de datos: el sistema mejora porque tiene un mecanismo para escuchar a quien lo usa y actuar sobre lo que oye.

La app de mapas que aprende de millones de recorridos. Cuando abres una app de mapas y te dice "esta ruta está congestionada, toma esta otra", no lo sabe por magia: lo sabe porque millones de personas que ya recorrieron esas calles le dieron datos —cuánto tardaron, dónde frenaron, qué desvío tomaron—. Cada recorrido tuyo, a su vez, alimenta a la app para el próximo conductor. Esa es la forma más pura del flywheel: más usuarios producen más datos de tráfico, más datos hacen mejores rutas, mejores rutas atraen más usuarios. La app no es útil a pesar de tener muchos usuarios; es útil porque los tiene —el uso es literalmente la materia prima que la mejora—. Una app de mapas recién lanzada, sin recorridos, es apenas un dibujo de calles; con millones de recorridos, es un oráculo del tráfico. La diferencia entre las dos no es el mapa; es el lazo de datos que convierte el uso en mejora.

La caja de sugerencias que de verdad se lee y se actúa. Casi toda oficina tiene una caja de sugerencias. En la mayoría, es decoración: la gente mete papelitos, nadie los lee, nada cambia, y con el tiempo dejan de meter papelitos porque aprendieron que no sirve. En unas pocas, alguien abre la caja cada semana, lee las sugerencias y actúa —arregla la impresora que todos se quejaban, cambia el café, ajusta el horario—. La diferencia entre las dos cajas no es la caja; es si el lazo se cierra. Capturar feedback y no usarlo es peor que no capturarlo: gastas el esfuerzo de recolectar y no obtienes la mejora, y encima entrenas a tus usuarios a no molestarse en dar feedback. Este es el error más caro del módulo, y esta analogía es la que lo nombra: una caja de sugerencias que nadie lee es exactamente un sistema de IA que captura thumbs up/down y nunca los realimenta. El feedback solo vale si cierra el lazo.

Junta las tres y tienes el módulo entero. El restaurante es el lazo de datos como decisión (escuchar deliberadamente y ajustar). La app de mapas es el flywheel (el uso compone la mejora). La caja de sugerencias es la advertencia (el lazo solo vale si se cierra). Todo lo demás son detalles de cómo montar esas tres cosas sobre una feature real.

El caso: el agente de soporte de Mercado

Bajemos a Mercado, el marketplace del ecosistema. De sus features de IA, el protagonista de este módulo es el agente de soporte al cliente: responde dudas frecuentes y propone respuestas que un agente humano revisa antes de enviarlas. Es el caso ideal para el lazo de datos por una razón concreta: genera feedback rico y natural. Cada vez que el agente propone una respuesta, pasan cosas medibles —el cliente la marca con thumbs up/down, el agente humano la manda tal cual o la corrige, el ticket se resuelve o se escala—. Ese torrente de señales es exactamente la materia prima del flywheel: nos dice, sin que tengamos que adivinar, dónde el agente responde bien y dónde falla.

Y hay una conexión directa con el módulo 3 que va a ser la columna vertebral de este módulo: el agente de soporte ya tiene un eval-set —el conjunto de casos con criterio que montamos como compuerta de calidad—. La idea central de aquí es que ese eval-set no debe ser estático. Cuando un cliente marca thumbs_down y el agente humano corrige la respuesta, acabamos de descubrir un caso donde el sistema falla que no estaba en el eval-set. Meterlo al eval-set es cerrar el lazo: el fallo reportado por un usuario real se vuelve un caso que la compuerta va a vigilar para siempre. La búsqueda semántica —que mejora con los clicks de los usuarios— aparece en el proyecto, porque su feedback es implícito (en qué resultado hiciste click) y sirve para ver el lazo desde otro ángulo.

No vamos a construir el agente ni a decidir cómo se entrena con estos datos —eso es AI Engineering—. Vamos a diseñar el lazo: observar el uso, capturar el feedback, y realimentarlo al eval-set (y al prompt, y al retrieval) para que el sistema mejore. Y para arrancar, veamos el módulo entero condensado en un bloque ejecutado. Fíjate bien, porque aquí está la tesis en acción.

Ejemplo trabajado: el feedback de producción se vuelve el eval-set

No vamos a decir que cerrar el lazo mejora el sistema: lo vamos a ejecutar. Modelamos un fragmento del lazo del agente de soporte —el sistema registra sus interacciones con el feedback del usuario, los casos con thumbs_down se convierten en casos nuevos del eval-set, y volvemos a correr la compuerta— y observamos algo revelador: la misma versión del agente que pasa el eval-set viejo falla el aumentado. El feedback de producción atrapó un punto ciego que el eval-set original no veía.

# Leccion 01 (intro M7) — el modulo en miniatura: el lazo de datos cerrado.
# Todo SIMULADO. Cero red, cero API, cero claves. Salida determinista.
#
# 1) El sistema REGISTRA sus interacciones con el feedback del usuario
#    (thumbs up/down). Eso es observabilidad: una senal de CALIDAD, no solo logs.
# 2) Los casos con thumbs_down se CONVIERTEN en nuevos casos del eval-set.
# 3) Una version candidata PASA el eval-set viejo (que no cubria esos casos) pero
#    FALLA el eval-set aumentado -> el lazo atrapo un punto ciego que antes no se veia.

# --- El eval-set ORIGINAL del agente de soporte (de M3): 6 casos "faciles". ---
EVAL_SET_V1 = [
    {"id": "q1", "question": "donde esta mi pedido",      "must_contain": "tracking"},
    {"id": "q2", "question": "como devuelvo un producto", "must_contain": "devolucion"},
    {"id": "q3", "question": "cuanto tarda el envio",     "must_contain": "3 a 5 dias"},
    {"id": "q4", "question": "puedo pagar en cuotas",     "must_contain": "cuotas"},
    {"id": "q5", "question": "quiero cancelar mi pedido", "must_contain": "cancelar"},
    {"id": "q6", "question": "como contacto a un vendedor", "must_contain": "mensajes"},
]

# --- El LOG DE PRODUCCION: interacciones reales con feedback del usuario. ---
# Cada fila: input del usuario, propuesta del modelo, feedback (up/down) y, si el
# usuario corrigio, la correccion (el dato correcto que el agente debio dar).
# NOTA DE FRONTERA: como se disena la captura de feedback y como se entrena con el
# es AI Engineering; aqui el LAZO como decision de arquitectura.
PROD_LOG = [
    # (input, propuesta_del_modelo, feedback, correccion_o_None)
    ("donde esta mi pedido",       "Puedes ver el tracking en tu perfil.",          "up",   None),
    ("cuanto tarda el envio",      "El envio tarda de 3 a 5 dias habiles.",         "up",   None),
    # --- casos que el usuario marco MAL (thumbs_down) con su correccion: ---
    ("el producto llego roto",     "Lo siento, no tengo informacion sobre eso.",    "down", "reembolso"),
    ("mi cupon no funciona",       "Los cupones siempre funcionan.",                "down", "vigencia"),
    ("no recibi mi factura",       "No manejamos facturas.",                        "down", "correo"),
    ("puedo pagar en cuotas",      "Si, puedes pagar en cuotas sin interes.",       "up",   None),
]

# --- Observabilidad: la senal de CALIDAD que un log de servidor clasico no tiene. ---
ups = sum(1 for *_r, fb, _c in PROD_LOG if fb == "up")
downs = sum(1 for *_r, fb, _c in PROD_LOG if fb == "down")
approval_rate = ups / (ups + downs)

print("=== Observabilidad: la senal de calidad (no basta el log de servidor) ===")
print(f"  interacciones registradas : {len(PROD_LOG)}")
print(f"  thumbs_up / thumbs_down    : {ups} / {downs}")
print(f"  approval_rate              : {approval_rate:.0%}")
print()

# --- Cerrar el lazo: los thumbs_down se vuelven NUEVOS casos del eval-set. ---
new_cases = []
for i, (q, _proposal, fb, correction) in enumerate(PROD_LOG, start=1):
    if fb == "down":
        new_cases.append({"id": f"fb{i}", "question": q, "must_contain": correction})

EVAL_SET_V2 = EVAL_SET_V1 + new_cases

print("=== Cerrar el lazo: los thumbs_down se vuelven casos del eval-set ===")
print(f"  eval-set v1 (original)  : {len(EVAL_SET_V1)} casos")
print(f"  casos nuevos del feedback: {len(new_cases)}  -> {[c['id'] for c in new_cases]}")
print(f"  eval-set v2 (aumentado) : {len(EVAL_SET_V2)} casos")
print()

# --- El STUB del agente: responde bien SOLO los casos "faciles" del v1. ---
# Es la version que hoy esta en produccion: nunca aprendio los casos que el
# usuario reporto como malos (llego roto, cupon vencido, factura por correo).
GOLD_FACIL = {
    "donde esta mi pedido":      "Puedes ver el tracking en tu perfil.",
    "como devuelvo un producto": "Para una devolucion, entra a tu pedido y pulsa Devolver.",
    "cuanto tarda el envio":     "El envio estandar tarda de 3 a 5 dias habiles.",
    "puedo pagar en cuotas":     "Si, puedes pagar en cuotas sin interes con tarjeta.",
    "quiero cancelar mi pedido": "Puedes cancelar el pedido si aun no fue enviado.",
    "como contacto a un vendedor": "Escribe al vendedor desde la seccion Mensajes.",
}

def agent(question):
    # Responde bien lo que ya sabia; para lo demas, respuesta pobre que falla el criterio.
    return GOLD_FACIL.get(question, "Lo siento, no tengo informacion sobre eso.")

def run_eval(eval_set):
    passed = sum(case["must_contain"] in agent(case["question"]).lower() for case in eval_set)
    return passed, len(eval_set), passed / len(eval_set)

THRESHOLD = 0.80
p1, n1, s1 = run_eval(EVAL_SET_V1)
p2, n2, s2 = run_eval(EVAL_SET_V2)

def verdict(score):
    return "PASS -> deploy permitido" if score >= THRESHOLD else "FAIL -> deploy bloqueado"

print(f"=== La MISMA version del agente contra los dos eval-sets (umbral {THRESHOLD:.2f}) ===")
print(f"  contra el eval-set v1 (viejo)    : {p1}/{n1} = {s1:.2f}   [{verdict(s1)}]")
print(f"  contra el eval-set v2 (aumentado): {p2}/{n2} = {s2:.2f}   [{verdict(s2)}]")

Qué esperar. Al correrlo, la salida es exactamente esta:

=== Observabilidad: la senal de calidad (no basta el log de servidor) ===
  interacciones registradas : 6
  thumbs_up / thumbs_down    : 3 / 3
  approval_rate              : 50%

=== Cerrar el lazo: los thumbs_down se vuelven casos del eval-set ===
  eval-set v1 (original)  : 6 casos
  casos nuevos del feedback: 3  -> ['fb3', 'fb4', 'fb5']
  eval-set v2 (aumentado) : 9 casos

=== La MISMA version del agente contra los dos eval-sets (umbral 0.80) ===
  contra el eval-set v1 (viejo)    : 6/6 = 1.00   [PASS -> deploy permitido]
  contra el eval-set v2 (aumentado): 6/9 = 0.67   [FAIL -> deploy bloqueado]

Lee la salida con calma, porque ahí está el módulo entero en miniatura, en tres actos.

Acto 1: la observabilidad revela lo que el log de servidor esconde. El sistema registró 6 interacciones, y de ellas 3 recibieron thumbs_up y 3 thumbs_down: un approval_rate de 50%. Detente en ese número. Si este agente viviera solo con monitoreo clásico, verías status HTTP 200 en las 6 interacciones —el servidor respondió, todo "verde"—. Pero la mitad de las respuestas fueron malas, y solo la señal de calidad (el approval_rate) lo revela. La observabilidad para IA es lo que convierte "el servicio respondió" en "el servicio respondió bien".

Acto 2: el feedback se vuelve casos del eval-set. Los 3 casos con thumbs_down —"el producto llegó roto", "mi cupón no funciona", "no recibí mi factura"— traían la corrección del usuario (el dato correcto que el agente debió dar). El lazo los convierte en 3 casos nuevos del eval-set (fb3, fb4, fb5): el input se vuelve la pregunta, y la corrección se vuelve el criterio. El eval-set del agente pasó de 6 casos a 9. Fíjate en lo que acaba de pasar: los fallos que usuarios reales reportaron ahora son parte permanente de la compuerta de calidad. El eval-set dejó de ser una foto fija y empezó a crecer con la realidad.

Acto 3: el eval-set aumentado atrapa un punto ciego. Y aquí está el golpe. La misma versión del agente —la que hoy está en producción, que solo sabe responder los 6 casos fáciles— se mide contra los dos eval-sets. Contra el viejo, saca 6/6 = 1.00: perfecto, deploy permitido, todo en verde. Contra el aumentado, saca 6/9 = 0.67: por debajo del umbral de 0.80, deploy bloqueado. Es el mismo agente, con dos veredictos opuestos. ¿Cuál es cierto? El del eval-set aumentado, porque incluye los casos que los usuarios de verdad tuvieron. El eval-set viejo daba una falsa tranquilidad —"1.00, estamos perfectos"— precisamente porque no probaba lo que fallaba. Cerrar el lazo le dio ojos a la compuerta: ahora ve el punto ciego que antes la hacía aprobar un agente que en producción tenía un approval_rate del 50%.

No entiendas todavía cómo funciona cada pieza —para eso son las lecciones—. Quédate con la forma del resultado: el uso generó feedback, el feedback se volvió casos de eval, y el eval-set aumentado reveló que el sistema era peor de lo que el eval-set viejo decía. Eso es exactamente lo que significa "el lazo de datos como arquitectura": un mecanismo que convierte el uso en una compuerta cada vez más honesta, y a la larga, en un sistema cada vez mejor.

El mapa de las seis lecciones

Las seis lecciones que siguen van en este orden porque cada una arma la pieza que la siguiente necesita.

Lección	Qué te da	Por qué va aquí
2	El flywheel: por qué el lazo de datos compone (uso → datos → mejor sistema → más uso), medido	Instala la motivación: sin lazo, el sistema se congela; con lazo, se separa de la competencia
3	La observabilidad para IA: tokens, costo, latencia y —lo nuevo— la señal de calidad	No puedes cerrar el lazo si no ves la calidad; es la precondición de todo lo demás
4	El lazo de retroalimentación: las tres señales (thumbs, corrección, acción) y su captura	La materia prima del lazo; hay que diseñar el punto donde se capturan las señales
5	Cerrar el lazo: el feedback se vuelve casos del eval-set del módulo 3	El corazón: donde la señal capturada se convierte en mejora verificable
6	La decisión prompt vs RAG vs fine-tune: su perfil de latencia, costo, frescura	Cuando el feedback pide un cambio, hay que saber qué palanca mover y qué implica
7	El enrutamiento: cada tipo de fallo a su palanca, con el eval como red de seguridad	La síntesis: junta la captura (4), el eval (5) y las palancas (6) en un lazo completo

El arco es: primero ves por qué el lazo importa (2), luego montas la observabilidad que lo hace posible (3), luego capturas el feedback (4), luego lo cierras realimentándolo al eval (5). Con el lazo básico funcionando, la lección 6 abre las palancas para mejorar (prompt, RAG, fine-tune) como decisión arquitectónica, y la lección 7 enruta cada señal a su palanca. La lección 8 —el proyecto— junta todo sobre la búsqueda semántica, una feature que arquitectas de cero, para que confirmes que aprendiste el método y no memorizaste una tabla.

Lo que este módulo NO toca

Conviene marcar la frontera desde ahora, porque hay temas vecinos que parecen de aquí y son de otra parte del ecosistema. Esta frontera es dura: crúzala solo para remitir.

La mecánica de RAG, fine-tuning y embeddings es de AI Engineering, no de aquí. Esta es la frontera más importante del módulo. En la lección 6 vas a decidir entre prompt, RAG y fine-tune como opciones arquitectónicas, y en la 7 vas a enrutar feedback hacia ellas. Pero cómo se construyen esas piezas —cómo se indexa un vector store, cómo se eligen y calculan embeddings, cómo se arma un dataset de entrenamiento, cómo se corre y evalúa un fine-tune, qué métrica de recuperación usar— es un cuerpo de conocimiento profundo, y es del ecosistema AI Engineering. Este módulo no lo enseña: trata esas piezas como cajas con propiedades (latencia que agregan, costo, frescura de datos, mantenimiento) y te enseña a elegir entre ellas y a cerrar el lazo con ellas. La regla mental: si la pregunta es "¿cómo construyo el RAG o cómo entreno el fine-tune?", es AI Engineering; si la pregunta es "¿debo usar prompt, RAG o fine-tune para esta feature, y cómo realimento el feedback?", es de aquí.

El diseño del eval-set es de AI Engineering; usarlo y hacerlo crecer con feedback es de aquí. El módulo 3 ya marcó esta frontera: elegir los casos y el criterio de un eval-set (cobertura, representatividad, calibrar un juez) es AI Engineering. Este módulo añade una vuelta: los casos que surgen del feedback de producción se agregan al eval-set. Convertir un thumbs_down en un caso de eval es del lazo de datos (de aquí); decidir si ese caso es representativo del universo real de fallos, o cómo balancear el dataset, es diseño de evals (AI Engineering). Nosotros cerramos el lazo; ellos diseñan el conjunto.

La ingeniería de datos y las pipelines de ML a fondo son de otras guías. Un lazo de datos serio en producción involucra pipelines de captura, almacenamiento, etiquetado y reentrenamiento que son toda una disciplina. Aquí el lazo es el mínimo necesario para mostrar la decisión arquitectónica: dónde se captura el feedback, a qué se realimenta, y cómo el eval verifica que la mejora fue real. No construimos la pipeline; mostramos la forma del lazo y las decisiones de diseño que lo definen.

Errores comunes

No capturar feedback y volar a ciegas (de omisión). Qué pasa: el equipo lanza la feature de IA y mide solo lo que mide un servidor —¿respondió?, ¿en cuánto tiempo?—, sin ninguna señal de si las respuestas fueron buenas. La feature puede estar degradándose durante semanas y nadie lo sabe, porque el tablero está todo en verde. El primer aviso son las quejas de clientes o la caída de una métrica de negocio, cuando el daño ya está hecho. Por qué pasa: capturar la señal de calidad cuesta trabajo de diseño (¿dónde pongo el thumbs?, ¿cómo registro la corrección?), y el monitoreo de servidor viene gratis con la infraestructura. Cómo detectarlo: si no puedes decir en un número cuál es el approval_rate de tu feature de IA hoy, estás volando a ciegas. Cómo corregirlo: monta la observabilidad para IA (lección 3) antes de necesitarla —la señal de calidad es la precondición de todo el lazo—.

Loguear como un servidor clásico, sin señal de calidad (de modelo mental). Qué pasa: variante del anterior. El equipo sí tiene observabilidad —logs, latencias, tasa de error— pero es la de un servicio clásico: mide disponibilidad, no calidad. Un componente de IA que responde HTTP 200 con una alucinación cuenta como "éxito" en ese tablero. La feature se ve sanísima —100% de 2xx, latencia baja— mientras entrega respuestas malas. Por qué pasa: el instinto es reusar el monitoreo que ya se tiene, y ese monitoreo nunca tuvo que medir "¿estuvo bien la respuesta?" porque los componentes clásicos no fallan de esa forma. Cómo detectarlo: si tu tablero no tiene una columna de calidad (approval_rate, o similar), no estás observando la parte que importa de una feature de IA. Cómo corregirlo: agrega la señal de calidad al tablero (lección 3); el status HTTP dice si el servicio respondió, la señal de calidad dice si respondió bien.

Cerrar mal el lazo: capturar feedback y nunca usarlo (de proceso). Qué pasa: el equipo pone el thumbs up/down, la gente lo usa, y los datos se acumulan en una tabla que nadie mira. Es la caja de sugerencias que nadie abre: gastaste el esfuerzo de recolectar y no obtienes ninguna mejora, y peor, los usuarios aprenden que su feedback no cambia nada y dejan de darlo. Por qué pasa: capturar es un cambio visible de producto (aparece un botón); realimentar es trabajo invisible de arquitectura (convertir el feedback en casos de eval, en ejemplos de prompt, en documentos de retrieval) que nadie prioriza. Cómo detectarlo: si tienes un mes de thumbs_down guardados y ni uno se convirtió en un caso de eval, en un ajuste de prompt o en un documento de retrieval, tu lazo está abierto. Cómo corregirlo: cierra el lazo (lecciones 5 y 7) —cada thumbs_down debe tener un destino: al eval-set, al prompt o al retrieval—.

Ejercicios

Ejercicio 1 — Traduce las analogías al diseño. Para cada analogía del módulo, di qué pieza del lazo de datos representa y da un ejemplo concreto en el agente de soporte de Mercado. (a) El restaurante que anota qué platos se devuelven y ajusta el menú. (b) La app de mapas que aprende de millones de recorridos. (c) La caja de sugerencias que de verdad se lee y se actúa.

Ver solución

• (a) El restaurante que anota y ajusta → el lazo de datos como decisión deliberada. Observar el uso (qué platos se devuelven) y actuar sobre ello (ajustar el menú). Ejemplo en Mercado: registrar cada thumbs_down del agente de soporte y usarlo para mejorar —no basta con cocinar (responder), hay que anotar qué se devuelve (qué respuestas fallaron) y ajustar—. La clave: la escucha es deliberada; alguien decidió medir.
• (b) La app de mapas que aprende de recorridos → el flywheel. Más uso produce más datos, más datos mejoran el sistema, mejor sistema atrae más uso. Ejemplo en Mercado: mientras más clientes usen el agente y la búsqueda, más feedback se genera, más casos de fallo se descubren y se corrigen, mejor queda la feature, y más gente la usa. El uso no es un costo; es la materia prima de la mejora.
• (c) La caja de sugerencias que se lee y se actúa → cerrar el lazo. El feedback solo vale si regresa a algo que mejora el sistema. Ejemplo en Mercado: los thumbs_down no se acumulan en una tabla muerta; se convierten en casos del eval-set, en ejemplos del prompt o en documentos de retrieval. La advertencia: una caja que nadie abre (feedback que nadie realimenta) es peor que no tener caja.

Lo importante: el restaurante es cómo decides escuchar, la app de mapas es por qué escuchar compone (el flywheel), y la caja de sugerencias es la advertencia de que capturar sin realimentar no sirve.

Ejercicio 2 — Los dos veredictos del mismo agente. En el ejemplo trabajado, la misma versión del agente sacó 1.00 contra el eval-set viejo y 0.67 contra el aumentado. Un compañero dice: "entonces el eval-set aumentado es más 'injusto', porque baja el score de un agente que estaba en 1.00". Explica por qué esa lectura está al revés, y qué número refleja de verdad la calidad del agente en producción.

Ver solución

La lectura está al revés porque confunde el score con la realidad. El eval-set viejo no es más "justo"; es más ciego. Daba 1.00 no porque el agente fuera perfecto, sino porque solo probaba los 6 casos que el agente ya sabía responder —nunca probaba "el producto llegó roto", "el cupón no funciona" ni "no recibí mi factura", que son casos donde el agente falla en producción—. Un examen que solo te pregunta lo que ya sabes siempre te da 100; eso no te vuelve sabio, vuelve al examen inútil.

El número que refleja la calidad real es el del eval-set aumentado (0.67), y hay una evidencia independiente que lo confirma: el approval_rate de producción fue 50%. El agente que el eval viejo declaraba "perfecto" tenía a la mitad de sus usuarios reales marcando thumbs_down. El eval aumentado (0.67) está mucho más cerca de esa realidad (50%) que el viejo (1.00). Cerrar el lazo no "bajó el score" de un buen agente; descubrió que el agente no era tan bueno como el eval viejo pretendía. La compuerta se volvió más honesta, no más injusta. Y esa honestidad es justo lo que evita desplegar un agente malo pensando que es perfecto.

Ejercicio 3 — ¿Lazo de datos o mecánica de AI Engineering? Para cada actividad, di si cae dentro de este módulo (la decisión arquitectónica y el lazo) o en la frontera de AI Engineering (la mecánica), y por qué. (a) Convertir los thumbs_down de la semana en casos nuevos del eval-set. (b) Elegir el algoritmo de embeddings y la dimensión del vector para el índice de RAG. (c) Decidir que la búsqueda semántica debe usar RAG y no fine-tune porque el catálogo cambia a diario. (d) Armar el dataset de entrenamiento y correr el fine-tune del modelo.

Ver solución

• (a) Convertir thumbs_down en casos de eval → este módulo. Es cerrar el lazo: realimentar el feedback de producción al eval-set del módulo 3. La esencia de la lección 5.
• (b) Elegir el algoritmo de embeddings y la dimensión del vector → frontera (AI Engineering). Es la mecánica de cómo se construye el RAG. Este módulo trata RAG como una caja con propiedades (frescura, latencia); cómo se implementa por dentro no es de aquí.
• (c) Decidir RAG y no fine-tune porque el catálogo cambia a diario → este módulo. Es la decisión arquitectónica de la lección 6: elegir la palanca según el perfil de la feature (aquí, la frescura de datos manda). No estamos construyendo el RAG; estamos eligiéndolo.
• (d) Armar el dataset y correr el fine-tune → frontera (AI Engineering). Es la mecánica del entrenamiento. Este módulo decide si fine-tune conviene y qué implica para el sistema; cómo se entrena es AI Engineering.

La regla que separa: si la actividad decide qué palanca o realimenta el feedback (a, c), es de aquí; si construye o entrena la pieza por dentro (b, d), es AI Engineering.

Resumen y siguiente paso

En esta lección conociste la tesis del módulo: un sistema AI-native bien diseñado mejora con el tiempo porque tiene un lazo de datos —escucha su propio uso y realimenta lo que escucha—. Viste las tres piezas que hacen girar el flywheel: la observabilidad que te deja ver la calidad, el lazo de retroalimentación que captura la señal del usuario, y el acto de cerrar el lazo realimentando esa señal a algo que mejora el sistema. Las tres analogías te dieron el marco: el restaurante que anota qué platos se devuelven (el lazo como decisión), la app de mapas que aprende de millones de recorridos (el flywheel que compone), y la caja de sugerencias que de verdad se lee y se actúa (la advertencia: capturar sin realimentar no sirve). Y en el bloque ejecutado viste la tesis en acción: el feedback de producción se volvió casos del eval-set, y la misma versión del agente que el eval viejo declaraba perfecta (1.00) el eval aumentado la reveló insuficiente (0.67) —el lazo le dio ojos a la compuerta, y esa honestidad coincidió con el 50% de approval_rate real—.

Antes de avanzar deberías poder: explicar el flywheel (uso → datos → mejor sistema → más uso) y por qué compone; nombrar las tres piezas del lazo (observabilidad, captura de feedback, cerrar el lazo); reconocer el error más caro (capturar feedback y nunca usarlo); y separar la decisión y el lazo (este módulo) de la mecánica de RAG/fine-tune/embeddings (AI Engineering), que está fuera de la frontera.

Lo que sigue es entender por qué el lazo importa tanto, porque hasta que no veas el flywheel componer no vas a apreciar por qué vale la pena diseñarlo. En la lección 2 vas a ejecutar dos sistemas idénticos al arrancar —uno con lazo de datos, otro sin él— y vas a medir cómo divergen ronda tras ronda: el del lazo trepa de 0.60 a 1.00 aprendiendo de lo que los usuarios reportan, mientras el sin lazo se queda congelado en 0.60. Es el paso de "el lazo de datos suena bien" a "el lazo de datos es la diferencia entre un sistema que mejora y uno que muere donde nació".

Recursos

• Chip Huyen — AI Engineering (O'Reilly) — el tratamiento sistemático del data flywheel y del monitoreo de aplicaciones con modelos de fundación; el libro de cabecera para las piezas (RAG, fine-tune, evals) que este módulo toma como cajas con propiedades. La frontera con AI Engineering.
• Chip Huyen — Designing Machine Learning Systems (O'Reilly) — el capítulo sobre feedback loops y monitoreo trata el lazo de datos como una decisión de arquitectura del sistema, no como un detalle de ML; el marco conceptual del módulo entero.
• martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — el catálogo de patrones de arquitectura para apps con LLM, con la observabilidad, el feedback y la elección de RAG/fine-tune tratados como piezas de diseño; el marco ensayístico de todo el módulo.
• Anthropic — documentación de Claude — la referencia conceptual para la observabilidad de una aplicación con un LLM (qué medir de una llamada al modelo: tokens, uso, latencia) y para la elección entre poner el conocimiento en el prompt o recuperarlo; sin fijar versión de modelo. En inglés.
• Ecosistema AI Engineering (remisión) — para la mecánica de RAG, fine-tuning, embeddings y diseño de datasets de evaluación: cómo se construyen las piezas que este módulo decide y realimenta. Este módulo enseña la decisión y el lazo; AI Engineering enseña a construir.