8. Proyecto: construye el lazo de datos de una feature de Mercado

Descripción

Esta es tu graduación del módulo. Durante siete lecciones aprendiste a diseñar el lazo de datos de una feature de IA: el flywheel que compone, la observabilidad que ve la calidad, la captura de las tres señales de feedback, el cierre del lazo hacia el eval-set, las tres palancas de mejora, y el enrutamiento de cada fallo a su palanca. Todo eso lo viste aplicado al agente de soporte. Ahora te toca a ti, de cero, sobre una feature de Mercado distinta: la búsqueda semántica. La razón de cambiar de feature es la de siempre y es dura: si te dejara re-montar el lazo del agente de soporte, no sabría si aprendiste el método o memorizaste la tabla. Y la búsqueda semántica tiene un giro que fuerza a aplicar el método y no la memoria: su feedback no es un thumbs explícito, es implícito —los clicks de los usuarios—. La única forma de resolverlo es aplicar lo que aprendiste: montar la observabilidad con la señal de calidad correcta, capturar los clicks, convertirlos en casos de eval, y decidir la palanca. Esa es, exactamente, la prueba de que el módulo funcionó.

Tu entregable son cuatro artefactos para la búsqueda semántica: (1) la observabilidad con su señal de calidad (la relevant_click_rate); (2) el feedback_loop que captura los clicks (la señal de acción implícita); (3) el cierre del lazo —los clicks a posiciones bajas se convierten en casos del eval-set y atrapan una regresión que el eval viejo aprobaba—; y (4) un brief de decisión (estilo ADR) que responda la elección prompt vs RAG vs fine-tune para esta feature y cómo el lazo compone con las compuertas de los módulos anteriores. Ninguna parte requiere construir el LLM ni calcular embeddings: el componente se simula con un stub determinista. Es puro trabajo de arquitectura —montar el lazo, ejecutarlo, defender la decisión— que es justo lo que separa una feature de IA que mejora con el tiempo de una que se congela donde nació. Constrúyelo tú primero; leer la solución de referencia sin haberlo intentado es como leer el marcador de un partido que no jugaste.

Conexión con el módulo: este proyecto cierra el arco. La lección 2 te mostró el flywheel; la 3 la observabilidad; la 4 la captura; la 5 el cierre hacia el eval; la 6 las palancas; la 7 el enrutamiento. Aquí produces los cuatro artefactos con tus manos, de principio a fin, sobre la búsqueda semántica —y con una señal de feedback (el click implícito) que no es el thumbs de las lecciones, para que apliques el método—. Y con esta lección se cierra el módulo: al final está el resumen de las ocho lecciones y el puente hacia el módulo 8 (el capstone de la guía, que junta todo) y hacia el ecosistema de AI Engineering (donde se construyen las piezas —RAG, fine-tune, embeddings— que aquí solo decidimos y realimentamos).

El caso del proyecto: la búsqueda semántica de Mercado

La feature que te toca gobernar —tuya para resolver— es esta:

Mercado tiene una búsqueda semántica: cuando un cliente escribe "algo para escuchar música corriendo", un componente de IA entiende la intención y devuelve una lista de productos ordenada por relevancia. El equipo quiere que la búsqueda mejore con el uso: que aprenda de lo que los clientes hacen. Pero la búsqueda no tiene un thumbs up/down obvio —nadie va a calificar cada búsqueda—. Diseña su lazo de datos.

Es una feature hermana de la del agente de soporte, pero con un perfil de feedback distinto, y por eso su lazo es otro. En el agente, el feedback era explícito (thumbs) o una corrección del humano; en la búsqueda, el feedback es la acción del usuario: en qué posición del ranking hizo click. Un click en el top-3 significa que la búsqueda puso lo relevante donde el cliente lo ve; un click en una posición baja (o una reformulación de la query sin click) significa que la búsqueda enterró lo relevante —y, revelador, el producto que el usuario terminó clickeando es exactamente el que debió salir arriba—. El click es feedback implícito de alto volumen: el usuario lo produce de todos modos, sin trabajo extra, y cada búsqueda lo genera. Es la señal de acción de la lección 4 en su forma más pura.

Los hechos que te da el equipo (para que no tengas que inventarlos): tienes un click log de producción con siete búsquedas, cada una con el ranking que se mostró, la posición del click y el producto clickeado. El criterio de calidad es el mismo del proyecto del módulo 3: relevante en el top-3. El umbral de la compuerta es 0.80. El eval-set original de la búsqueda tiene 3 casos (los del módulo 3). Y hay una versión candidata: un modelo más barato (el cascade del módulo 2) que acierta los casos originales pero cuya relevancia real —revelada por los clicks— se degradó.

Lo que tienes que entregar

Sigue los pasos en orden; cada uno se apoya en el anterior.

Parte 1 — La observabilidad con la señal de calidad

Del click log, calcula la señal de calidad de la búsqueda: la relevant_click_rate (fracción de búsquedas donde el click cayó en el top-3) y la posición de click promedio. Explica por qué el click es la señal de calidad adecuada para esta feature (feedback implícito, gratis, de alto volumen) y qué revela que un log de servidor clásico no vería.

Parte 2 — El feedback_loop que captura los clicks

Diseña qué guarda el punto de captura por cada búsqueda para no perder la señal (la query, el ranking mostrado, y la posición/producto del click). Recuerda de la lección 4: lo que no capturas no se recupera —si solo guardas la query y el resultado, pierdes la posición del click, que es la señal—.

Parte 3 — Cerrar el lazo: los clicks se vuelven casos del eval-set

Convierte los clicks a posiciones bajas (fuera del top-3) en casos nuevos del eval-set: la query se vuelve el caso, y el producto clickeado se vuelve el "relevante" que debió salir arriba. Corre la compuerta con la versión candidata contra el eval-set viejo y el aumentado, y muestra cómo el aumentado atrapa la regresión que el viejo aprobaba. Simula el componente con un stub determinista.

Parte 4 — El brief de decisión (estilo ADR)

Escribe un breve documento de decisión que responda: ¿qué palanca (prompt, RAG o fine-tune) usarías para la búsqueda semántica y por qué? ¿Cómo cierra el lazo esta feature (de la señal de click a la mejora)? ¿Cómo se compone el lazo de datos con las compuertas de los módulos anteriores (presupuestos del M2, eval del M3, guardrails del M4, resiliencia del M5, cáscara del M6)? Es la justificación arquitectónica de tu diseño.

Intenta las cuatro partes antes de mirar la solución. Lo que sigue es una referencia, no la única respuesta correcta.

Solución de referencia

Partes 1, 2 y 3 — El lazo ejecutado

# Proyecto M7 — el LAZO DE DATOS de la busqueda semantica de Mercado. SIMULADO.
# Cero red, cero API, cero claves. Determinista.
#
# Feature distinta a las lecciones (agente de soporte) a proposito: la busqueda
# aprende de un feedback IMPLICITO —los CLICKS—. En que posicion hizo click el
# usuario ES la senal de relevancia: click arriba = bien; click abajo = el ranking
# enterro lo relevante, y el producto que clickeo revela lo que debio ir arriba.

CATALOG = ["earbuds", "running_shoes", "phone_case", "smartwatch", "water_bottle",
           "backpack", "sunglasses", "headphones", "yoga_mat", "power_bank"]

# --- El CLICK LOG de produccion: por cada busqueda, el ranking mostrado y en que
#     posicion (1-based) hizo click el usuario. Si clickeo abajo, el producto
#     clickeado es la "correccion" implicita (lo relevante que el ranking hundio). ---
CLICK_LOG = [
    # (query, ranking_mostrado, posicion_click, producto_clickeado)
    ("algo para escuchar musica corriendo", ["earbuds", "phone_case", "backpack"], 1, "earbuds"),
    ("tenis para correr",                    ["running_shoes", "yoga_mat", "backpack"], 1, "running_shoes"),
    ("proteger mi telefono",                 ["phone_case", "earbuds", "backpack"], 1, "phone_case"),
    # --- clicks ABAJO: el ranking enterro lo relevante (senal de fallo implicita) ---
    ("botella para el gimnasio",  ["backpack", "yoga_mat", "sunglasses", "smartwatch", "water_bottle"], 5, "water_bottle"),
    ("lentes para el sol",        ["backpack", "phone_case", "earbuds", "yoga_mat", "sunglasses"], 5, "sunglasses"),
    ("cargar el celular sin enchufe", ["backpack", "earbuds", "phone_case", "yoga_mat", "power_bank"], 5, "power_bank"),
    ("reloj que mida pasos",      ["earbuds", "phone_case", "backpack", "sunglasses", "smartwatch"], 5, "smartwatch"),
]

# ===================== PARTE 1: OBSERVABILIDAD (senal de calidad) =====================
TOP_K = 3
clicks_in_top3 = sum(1 for *_r, pos, _p in CLICK_LOG if pos <= TOP_K)
relevant_click_rate = clicks_in_top3 / len(CLICK_LOG)
avg_click_pos = sum(pos for *_r, pos, _p in CLICK_LOG) / len(CLICK_LOG)

print("=== PARTE 1 — Observabilidad de la busqueda semantica ===")
print(f"  busquedas registradas       : {len(CLICK_LOG)}")
print(f"  clicks en el top-3           : {clicks_in_top3}/{len(CLICK_LOG)}")
print(f"  relevant_click_rate (calidad): {relevant_click_rate:.0%}")
print(f"  posicion de click promedio   : {avg_click_pos:.1f}  (1.0 = ideal)")
print(f"  senal: {'OK' if relevant_click_rate >= 0.80 else 'ALERTA: el ranking hunde lo relevante'}")
print()

# ===================== PARTE 2: CERRAR EL LAZO (click -> eval-set) =====================
# El eval-set ORIGINAL de la busqueda (M3): queries con su producto relevante, criterio top-3.
EVAL_SET_V1 = [
    {"id": "s1", "query": "algo para escuchar musica corriendo", "relevant": "earbuds"},
    {"id": "s2", "query": "tenis para correr",                   "relevant": "running_shoes"},
    {"id": "s3", "query": "proteger mi telefono",               "relevant": "phone_case"},
]

# Conversion: un click FUERA del top-3 revela un caso nuevo (query -> producto clickeado).
def clicks_to_eval_cases(log, k=TOP_K, start=1):
    cases = []
    for i, (query, _rank, pos, product) in enumerate(log, start=start):
        if pos > k:   # el usuario tuvo que bajar: lo relevante estaba hundido
            cases.append({"id": f"c{i}", "query": query, "relevant": product})
    return cases

new_cases = clicks_to_eval_cases(CLICK_LOG)
EVAL_SET_V2 = EVAL_SET_V1 + new_cases

print("=== PARTE 2 — Cerrar el lazo: clicks abajo -> casos del eval-set ===")
print(f"  eval-set v1            : {len(EVAL_SET_V1)} casos")
print(f"  clicks fuera del top-3 : {len(new_cases)} -> {[c['id'] for c in new_cases]}")
print(f"  eval-set v2 (aumentado): {len(EVAL_SET_V2)} casos")
print()

# ===================== PARTE 3: EL GATE con el eval aumentado =====================
def make_search(competent_ids):
    # STUB: para los casos competentes pone lo relevante en el top-3; si no, en la pos 5.
    def search(query, case_id, relevant):
        others = [p for p in CATALOG if p != relevant]
        if case_id in competent_ids:
            return [relevant, others[0], others[1]]
        return others[:4] + [relevant]
    return search

def run_eval(search, eval_set, k=TOP_K):
    passed = 0
    for c in eval_set:
        ranking = search(c["query"], c["id"], c["relevant"])
        passed += c["relevant"] in ranking[:k]
    return passed, len(eval_set), passed / len(eval_set)

ALL_V1 = {c["id"] for c in EVAL_SET_V1}
ALL_V2 = {c["id"] for c in EVAL_SET_V2}
THRESHOLD = 0.80

# Version candidata: un modelo mas barato. Acierta las 3 faciles (v1) pero hunde
# lo relevante en los casos que los CLICKS revelaron -> el eval v2 lo atrapa.
cheaper = make_search(ALL_V1)     # solo competente en los 3 casos originales

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

p1, n1, s1 = run_eval(cheaper, EVAL_SET_V1)
p2, n2, s2 = run_eval(cheaper, EVAL_SET_V2)
print(f"=== PARTE 3 — El gate: version barata vs eval viejo y aumentado (umbral {THRESHOLD:.2f}) ===")
print(f"  vs eval-set v1 (viejo)    : {p1}/{n1} = {s1:.2f}  [{gate(s1)}]")
print(f"  vs eval-set v2 (aumentado): {p2}/{n2} = {s2:.2f}  [{gate(s2)}]")
print()
print("Los clicks de produccion se volvieron casos de eval. La version barata que")
print("el eval viejo aprobaba ahora se BLOQUEA: el lazo le dio ojos a la compuerta.")

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

=== PARTE 1 — Observabilidad de la busqueda semantica ===
  busquedas registradas       : 7
  clicks en el top-3           : 3/7
  relevant_click_rate (calidad): 43%
  posicion de click promedio   : 3.3  (1.0 = ideal)
  senal: ALERTA: el ranking hunde lo relevante

=== PARTE 2 — Cerrar el lazo: clicks abajo -> casos del eval-set ===
  eval-set v1            : 3 casos
  clicks fuera del top-3 : 4 -> ['c4', 'c5', 'c6', 'c7']
  eval-set v2 (aumentado): 7 casos

=== PARTE 3 — El gate: version barata vs eval viejo y aumentado (umbral 0.80) ===
  vs eval-set v1 (viejo)    : 3/3 = 1.00  [PASS -> deploy permitido]
  vs eval-set v2 (aumentado): 3/7 = 0.43  [FAIL -> deploy bloqueado]

Los clicks de produccion se volvieron casos de eval. La version barata que
el eval viejo aprobaba ahora se BLOQUEA: el lazo le dio ojos a la compuerta.

Lee el resultado por partes, porque es el lazo entero sobre una feature nueva.

Parte 1 — la señal de calidad revela el problema. De las 7 búsquedas, solo 3 tuvieron el click en el top-3: una relevant_click_rate de 43%, con una posición de click promedio de 3.3 (contra el ideal de 1.0). El tablero marca ALERTA. Fíjate en lo que hizo el click: sin que ningún usuario calificara nada, su comportamiento —dónde hizo click— reveló que en 4 de 7 búsquedas el ranking enterró lo relevante. Un log de servidor clásico habría visto 7 búsquedas con status 200 y latencia baja: todo verde. La señal de acción (el click) es la única que ve que la búsqueda está fallando a más de la mitad de sus usuarios. Y es la señal ideal para esta feature justo porque es implícita (el usuario ya hace click, no le pides nada extra), gratis y abundante (cada búsqueda la produce).

Parte 2 — los clicks se vuelven casos de eval. Los 4 clicks a posición baja (c4 a c7) se convierten en casos nuevos del eval-set: la query se vuelve el caso, y el producto que el usuario terminó clickeando se vuelve el "relevante" que debió salir arriba. Fíjate en lo elegante: el usuario, al hacer click en "water_bottle" tras buscar "botella para el gimnasio", te dijo cuál era la respuesta correcta —sin escribirla, solo con su click—. El eval-set creció de 3 a 7 casos, y esos 4 casos nuevos son exactamente los que la búsqueda está fallando en producción. Es la misma conversión de la lección 5, pero con feedback implícito en vez de una corrección explícita.

Parte 3 — el eval aumentado atrapa la regresión. La versión barata —el modelo económico que acierta los 3 casos originales pero enterró lo relevante en los que los clicks revelaron— se prueba contra los dos eval-sets. Contra el viejo (los 3 casos del módulo 3), saca 3/3 = 1.00: PASA, deploy permitido. Contra el aumentado (con los 4 casos de los clicks), saca 3/7 = 0.43: FALLA, deploy bloqueado. La misma versión, dos veredictos opuestos, y el aumentado es el correcto porque incluye lo que los usuarios de verdad experimentaron. Sin cerrar el lazo, esta versión barata —que en producción tenía una relevant_click_rate del 43%— se habría desplegado con la bendición del eval viejo. Los clicks convertidos en casos le dieron a la compuerta los ojos para bloquearla. El lazo se cerró: de la señal de acción (click) a la mejora verificable (regresión atrapada).

Parte 4 — El brief de decisión (estilo ADR)

Decisión: montar un lazo de datos para la búsqueda semántica que capture los clicks como señal de calidad, los realimente al eval-set, y use RAG como palanca de conocimiento; NO fine-tune.

Contexto. La búsqueda semántica opera sobre el catálogo de Mercado, que es grande (millones de productos) y cambia constantemente (productos que entran, salen, cambian de precio y de stock a diario). Su calidad —¿pone lo relevante arriba?— se degrada de forma invisible para el monitoreo clásico: responde 200 en todas las búsquedas aunque entierre lo relevante. Necesita un lazo de datos para mejorar con el uso.

Señal de calidad y captura. La señal es la relevant_click_rate: la fracción de búsquedas donde el click cae en el top-3. Es feedback implícito (el usuario ya hace click, sin trabajo extra), gratis y de alto volumen —ideal para una feature de alto tráfico sin un momento natural para pedir un thumbs—. El punto de captura guarda, por búsqueda: la query, el ranking mostrado, y la posición/producto del click. Guardar solo la query y el resultado perdería la posición del click, que es la señal; y lo no capturado no se recupera.

Cerrar el lazo. Los clicks a posiciones bajas se convierten en casos del eval-set (query → caso, producto clickeado → relevante), que atrapan regresiones que el eval viejo aprobaba (la versión barata: 1.00 contra el eval viejo, 0.43 contra el aumentado). Esos casos también señalan qué mejorar en el retrieval (los productos que se enterraron).

Palanca: RAG, no fine-tune. La elección la decide la frescura de datos (lección 6): el catálogo cambia a diario, así que fine-tune queda descartado —se congelaría con el catálogo del día del entrenamiento y habría que re-entrenar constantemente—. Y el catálogo es enorme, más de lo que cabe en un prompt. RAG es la única palanca que da frescura sobre mucho conocimiento: se actualiza el índice y el cambio se refleja en la siguiente búsqueda. (Cómo se construye el RAG —embeddings, indexado— es AI Engineering; que RAG es la palanca correcta aquí es la decisión de arquitectura.)

Composición con las compuertas anteriores. El lazo de datos no reemplaza las compuertas de los módulos previos; las complementa y las cierra en un ciclo:

• M2 (presupuestos): la observabilidad del lazo vigila el cost/latency budget en vivo (tokens, costo, latencia por búsqueda).
• M3 (eval): el eval-set es la red de seguridad a la que el lazo realimenta los fallos; el eval crece con los clicks.
• M4 (guardrails): la salida de la búsqueda sigue validándose en la frontera antes de mostrarse.
• M5 (resiliencia): cuando el modelo cae, la búsqueda degrada a keywords; el lazo mide si esa degradación afecta la relevant_click_rate.
• M6 (cáscara determinista): el lazo respeta la cáscara —el feedback mejora al modelo, pero el modelo sigue proponiendo, no disponiendo—.

Por qué el sistema mejora con el tiempo. Con este lazo, la búsqueda deja de ser una foto fija: cada click revela un fallo, cada fallo se vuelve un caso de eval y una señal de qué mejorar en el retrieval, y cada mejora se verifica con el eval aumentado. Es el flywheel de la lección 2 girando: más uso → más clicks → más casos de fallo descubiertos y corregidos → mejor búsqueda → más uso. La calidad de la búsqueda no la decide el modelo; la decide este lazo.

Consecuencias. Hay que instrumentar la captura del click desde el inicio (lo no capturado no se recupera). El eval-set crece y hay que mantenerlo representativo (diseño de evals, AI Engineering). Cada cambio del componente (modelo, retrieval) pasa por el eval aumentado antes del deploy. La palanca RAG exige mantener el índice fresco, que es su costo de mantenimiento.

Ese brief es el artefacto que justifica la decisión ante el equipo: qué señal de calidad, cómo se captura, cómo se cierra el lazo, qué palanca y por qué, y cómo el lazo compone con todo lo anterior. Con los cuatro artefactos —observabilidad, captura, cierre del lazo, y brief— tienes el lazo de datos de la búsqueda semántica montado de punta a punta.

Errores comunes

Usar un thumbs explícito donde el click implícito es la señal natural (de captura inadecuada). Qué pasa: el equipo, por costumbre del agente de soporte, agrega un botón de "¿te sirvió este resultado?" a cada búsqueda. Casi nadie lo usa —nadie califica búsquedas—, así que la señal es escasa y sesgada (solo responden los muy frustrados). Mientras tanto, la señal de acción que sí abunda —el click— no se está capturando. Por qué pasa: el thumbs es la señal más obvia y la que se usó en la feature anterior, y se aplica por inercia. Cómo detectarlo: si tu señal de calidad depende de que el usuario haga trabajo extra en una feature de alto tráfico, vas a tener pocos datos. Cómo corregirlo: para la búsqueda, la señal natural es el click (feedback implícito, gratis, abundante); captúralo en vez de pedir un thumbs que nadie da.

Guardar solo el resultado de la búsqueda y perder la posición del click (de omisión irreversible). Qué pasa: el sistema registra la query y los productos mostrados, pero no en cuál hizo click el usuario ni en qué posición. Cuando el equipo quiere calcular la relevant_click_rate, descubre que no tiene el dato —sabe qué se mostró, no qué eligió el usuario—. Toda esa señal de acción se perdió. Por qué pasa: guardar el resultado parece suficiente, y la posición del click ocurre en el front-end, en un punto que no se estaba instrumentando. Cómo detectarlo: si no puedes decir en qué posición hicieron click tus usuarios la semana pasada, no capturaste la señal. Cómo corregirlo: guarda la tripleta (query, ranking mostrado, click con su posición) en el punto de captura; y recuerda que es irreversible —los clicks que no instrumentaste no se recuperan—.

Meter la búsqueda a fine-tune "para que aprenda el catálogo" (de palanca equivocada). Qué pasa: el equipo decide entrenar un modelo con el catálogo para que la búsqueda "conozca los productos". Funciona un tiempo, pero el catálogo cambia a diario —productos nuevos, precios, stock— y el modelo entrenado se queda con el catálogo viejo, recomendando productos que ya no existen. Ahora hay que re-entrenar constantemente. Por qué pasa: fine-tune suena a "de verdad enseñarle el catálogo", y no se pensó en la frescura. Cómo detectarlo: si tu palanca para conocimiento que cambia a diario es fine-tune, vas a estar siempre desactualizado. Cómo corregirlo: para un catálogo vivo, la palanca es RAG —el índice se actualiza y el cambio se refleja de inmediato—; fine-tune se congelaría. La frescura de datos descarta fine-tune (lección 6).

Ejercicios

Ejercicio 1 — El click como corrección. En el proyecto, un click a la posición 5 sobre "water_bottle" tras la búsqueda "botella para el gimnasio" se convirtió en un caso de eval. Explica por qué el click es a la vez una señal de fallo y una corrección, y compáralo con la corrección explícita del agente de soporte (lección 5). ¿Qué ventaja tiene el click sobre pedirle al usuario que corrija?

Ver solución

El click a la posición 5 es una señal de fallo porque revela que el ranking no puso lo relevante arriba: el usuario tuvo que bajar hasta la posición 5 para encontrar lo que buscaba, lo que significa que las posiciones 1-4 no eran lo que quería. Si la búsqueda hubiera acertado, el click habría caído en el top-3. Y es a la vez una corrección porque el producto que el usuario terminó clickeando ("water_bottle") es exactamente la respuesta correcta —lo que debió salir arriba—. El usuario, con su click, no solo dijo "esto está mal" sino "esto era lo correcto", igual que la corrección explícita del agente de soporte, donde el humano reescribía la respuesta y esa reescritura se volvía el criterio del caso.

La diferencia con la corrección del agente: en el agente, la corrección era explícita —el humano editaba el texto a propósito—; en la búsqueda, la corrección es implícita —surge del comportamiento natural del usuario, sin que él sepa que está corrigiendo nada—. El usuario solo quería su botella; al hacer click en ella, sin quererlo, le entregó al sistema la respuesta correcta para esa query.

La ventaja del click sobre pedir una corrección explícita: es gratis y abundante. Pedirle al usuario que corrija (que escriba cuál era el resultado correcto) requiere trabajo de su parte, así que casi nadie lo haría, y tendrías pocos datos y sesgados. El click, en cambio, el usuario lo hace de todos modos —es parte de usar la búsqueda—, así que la señal es de alto volumen y no depende de la buena voluntad del usuario. Para una feature de alto tráfico como la búsqueda, esta abundancia es decisiva: el feedback implícito escala donde el explícito no.

Ejercicio 2 — Los dos veredictos, otra vez. La versión barata sacó 1.00 contra el eval viejo (3 casos) y 0.43 contra el aumentado (7 casos). Un compañero dice: "el eval viejo con 3 casos ya la aprobaba; agregar casos solo para reprobarla es hacer trampa". Explica por qué está equivocado, conectándolo con la relevant_click_rate del 43% que se midió en producción.

Ver solución

Está equivocado porque confunde hacer el examen más difícil arbitrariamente con hacer el examen representativo de la realidad. Los 4 casos que se agregaron no salieron de la nada ni se eligieron para reprobar a la versión barata: son las búsquedas reales que los usuarios hicieron y donde la búsqueda falló —lo sabemos porque el usuario tuvo que bajar hasta la posición 5 para encontrar lo relevante—. Agregar esos casos no es trampa; es hacer que el eval-set incluya lo que los usuarios de verdad experimentan. El eval viejo de 3 casos daba 1.00 solo porque no probaba las búsquedas que fallaban: su score perfecto era un punto ciego, no calidad.

Y hay una evidencia independiente que lo confirma: la relevant_click_rate medida en producción fue 43% —exactamente el score del eval aumentado (3/7 = 0.43)—. No es coincidencia: el eval aumentado, al incluir los casos que los clicks revelaron, converge con la realidad de producción, mientras que el eval viejo (1.00) estaba completamente desconectado de ella. El eval viejo decía "perfecto", la producción decía "43% de aciertos", y el eval aumentado (0.43) le da la razón a la producción. Agregar los casos de los clicks no reprobó injustamente a la versión barata; reveló que ya estaba reprobando en producción, donde importa. Cerrar el lazo hizo la compuerta honesta, no tramposa.

Ejercicio 3 — El lazo de otra feature. Aplica el método a una feature nueva: el generador "describe tu producto", donde un vendedor da el nombre y las specs de un producto y el LLM escribe una descripción de venta. Diseña su lazo de datos: (a) ¿qué señal de calidad capturarías (y es implícita o explícita)?, (b) ¿cómo cierras el lazo con esa señal?, y (c) ¿qué palanca (prompt, RAG o fine-tune) elegirías, considerando que Mercado tiene un tono de marca fijo y millones de productos?

Ver solución

• (a) La señal de calidad → la tasa de descripciones que el vendedor publicó sin editar (señal de acción, implícita), y cuánto editó cuando editó. Si el vendedor publica la descripción generada tal cual, sirvió; si la reescribe entera, falló. Es feedback implícito de la lección 4 (la acción): surge del flujo normal (el vendedor va a publicar de todos modos) y no requiere pedirle un thumbs. Un complemento explícito (un thumbs opcional) puede agregarse, pero la señal principal y abundante es la acción de publicar/editar.
• (b) Cerrar el lazo: las descripciones que el vendedor reescribió son las correcciones —la versión editada es lo que debió generarse—. Se convierten en casos del eval-set (input: nombre + specs; criterio: propiedades de la descripción editada, como que mencione las specs clave y respete el tono). Esos casos atrapan regresiones y alimentan la palanca de mejora. La conversión es la misma de la lección 5, con la edición del vendedor como corrección.
• (c) La palanca → aquí sí, fine-tune es un candidato serio (a diferencia de la búsqueda). El tono de marca es fijo (no cambia) y el volumen es enorme (millones de productos): cumple los criterios de la lección 6 —comportamiento estable + alto volumen—. Fine-tune hornearía el estilo de marca, con prompts cortos e inferencia barata a escala masiva, y como el tono no cambia, la rigidez de fine-tune no duele. Pero —siguiendo la escalera— primero se prueba el prompt con ejemplos del tono de marca y se mide si alcanza; muchas veces un buen prompt con few-shot logra el tono sin el costo de entrenar. Solo si el prompt no da la consistencia necesaria a ese volumen, se justifica fine-tune. Nota importante: las specs del producto (que sí cambian por producto) no van en el fine-tune —van en el prompt/entrada—; lo que se hornea es el estilo, no los datos variables. Esa distinción (estilo estable → fine-tune; datos variables → prompt/RAG) es la clave de la decisión.

El contraste con la búsqueda es la lección: la búsqueda opera sobre un catálogo vivo (frescura manda → RAG, nunca fine-tune); el generador aplica un tono fijo a alta escala (estabilidad + volumen → fine-tune es candidato). La misma familia de decisión, respuestas opuestas, porque los perfiles de la feature son opuestos.

Resumen del módulo: las ocho lecciones

Cerraste el módulo del lazo de datos y de retroalimentación. Este es el arco completo que recorriste:

Lección	Lo que te llevas
1	La tesis: un sistema AI-native mejora porque escucha su uso y lo realimenta. Las tres analogías (el restaurante, la app de mapas, la caja de sugerencias). El feedback se vuelve casos de eval, y el eval aumentado atrapa un punto ciego.
2	El flywheel: uso → datos → mejor sistema → más uso, medido —el sistema con lazo trepa de 0.60 a 1.00, el sin lazo se congela en 0.60—. La bola de nieve que compone vs la piedra que rueda sin cambiar.
3	La observabilidad para IA: tokens, costo, latencia y —lo nuevo— la señal de calidad. Un log clásico ve 100% de 2xx mientras una feature tiene 65% de approval: el motor anda, el viaje no.
4	El feedback loop como decisión de diseño: tres señales (thumbs, corrección, acción) que no coinciden (62% / 50% / 38%). La acción es la más honesta. El punto de captura es irreversible: lo no capturado no se recupera.
5	Cerrar el lazo: el feedback se vuelve casos del eval-set (M3). Una versión que pasaba el eval viejo (0.83) falla el aumentado (0.50). La lista de "nunca más" de la aviación. El error más caro: capturar y no cerrar.
6	La decisión prompt vs RAG vs fine-tune: su perfil de latencia, costo, frescura y mantenimiento. La escalera (prompt → RAG → fine-tune). La frescura decide primero; no saltes a fine-tune por prestigio.
7	El enrutamiento: el triage del feedback —agrupar por tipo, enrutar a la palanca más barata que sirva, todo al eval, verificar re-corriendo el eval (0.43 → 0.86)—. Las cuatro reglas del lazo.
8	El proyecto: el lazo de datos de la búsqueda semántica montado de punta a punta —observabilidad con la relevant_click_rate, captura del click, cierre hacia el eval, y ADR con la decisión RAG—.

La capacidad que ganaste: tomar una feature de IA y diseñar su lazo de datos completo —la observabilidad con su señal de calidad, la captura del feedback, el cierre hacia el eval-set, y la decisión de qué palanca mover para mejorarla— para que el sistema mejore con el uso en vez de congelarse. Y con la frontera clara: esto es la decisión y el lazo; construir las piezas (RAG, fine-tune, embeddings, el diseño del eval-set) es AI Engineering.

Hacia dónde seguir

El módulo 8: el capstone de la guía. Este módulo cerró la última pieza de la cáscara que rodea al componente de IA. En el módulo 8 vas a juntar todo: arquitectar una feature de IA en Mercado de punta a punta —dónde vive el componente, su latency/cost budget con model cascade (M2), su eval gate (M3), sus guardrails y frontera de confianza (M4), su fallback cuando el modelo cae (M5), la cáscara determinista que valida sus acciones (M6), y el lazo de datos que la mejora (este módulo)—. El lazo que montaste aquí es una de las siete piezas que el capstone integra.

El ecosistema AI Engineering: construir las piezas. En todo este módulo trataste RAG, fine-tune y embeddings como cajas con propiedades, y el eval-set como algo que crece pero no diseñaste. Construir esas piezas —cómo se indexa y recupera en RAG, cómo se arma el dataset y se corre un fine-tune, cómo se diseña un eval-set representativo— es el cuerpo de conocimiento del ecosistema AI Engineering. Si vas a llevar features de IA a producción de verdad, ese es el siguiente paso: este módulo te enseñó a decidir qué palanca y a cerrar el lazo; AI Engineering te enseña a construir las palancas.

architecture-decisions-and-tradeoffs-guide: la fitness function como concepto general. El eval-set que este módulo hace crecer con feedback es una fitness function —una prueba automatizada que gobierna una propiedad del sistema y frena el cambio si se degrada—. El concepto general, aplicado a cualquier propiedad arquitectónica, está en esa guía. El lazo de datos es lo que mantiene esa fitness function representativa con el tiempo.

Con esto tienes la última propiedad arquitectónica de una feature de IA: no solo contenida (M1-M6), sino capaz de mejorar con el tiempo (este módulo). Una feature de IA lista para producción no solo sobrevive a su no-determinación; la convierte en una trayectoria de mejora, y ahora sabes diseñar el lazo que la hace posible.

Recursos

• Chip Huyen — AI Engineering (O'Reilly) — el tratamiento del data flywheel, el feedback de producción y la elección entre prompt, RAG y fine-tune; la referencia para construir las piezas que este proyecto solo decide y realimenta (la frontera con AI Engineering).
• Chip Huyen — Designing Machine Learning Systems (O'Reilly) — los capítulos sobre feedback loops y monitoreo tratan el lazo de datos como una propiedad de arquitectura del sistema completo; el marco del proyecto.
• martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — el catálogo de patrones con la observabilidad, el feedback y la elección de RAG/fine-tune como piezas de diseño; el marco que enmarca este proyecto y el capstone del módulo 8. En inglés.
• Anthropic — documentación de Claude — la referencia conceptual para instrumentar una aplicación con un LLM (medir uso, capturar señales) y para elegir entre poner conocimiento en el prompt o recuperarlo; sin fijar versión de modelo. En inglés.
• Ecosistema AI Engineering (remisión) — para construir el RAG del catálogo, diseñar el eval-set representativo, y evaluar si un fine-tune de estilo se justifica; este módulo montó el lazo, AI Engineering construye lo que el lazo alimenta.