Módulo 7: El lazo de datos y de retroalimentación

7. Enrutar la señal de feedback a la palanca correcta

Siguiente →

Descripción

Al terminar esta lección vas a saber armar el lazo de datos completo, uniendo todo lo del módulo en un flujo que funciona: el feedback se agrupa por tipo de fallo, cada grupo se enruta a la palanca que le corresponde —prompt, retrieval o considerar fine-tune—, todo fallo va también al eval-set como red de seguridad, y el eval verifica que el arreglo mejoró sin regresar. Es la síntesis del módulo porque junta las piezas: la captura (lección 4) produce el feedback, cerrar el lazo hacia el eval (lección 5) es la red de seguridad universal, y las palancas (lección 6) son las herramientas de arreglo. Lo que faltaba era el enrutamiento: dado un fallo concreto, ¿qué palanca lo arregla? La tesis es que el tipo de fallo determina la palanca —no todos los fallos se arreglan igual—, y que la regla operativa es empezar por la palanca más barata que sirva.

Esto importa porque un lazo sin enrutamiento es un lazo que aplica la misma herramienta a todos los problemas —el martillo para todo—, y eso desperdicia esfuerzo y a veces no arregla nada. Un fallo donde el dato correcto existía pero no se recuperó no se arregla tocando el prompt; se arregla mejorando el retrieval. Un fallo de tono o formato sistemático no se arregla agregando documentos al índice; se arregla en el prompt. Un fallo que es una clase entera de comportamiento que ni el prompt ni el retrieval logran, y que es estable y de alto volumen, es el raro caso donde considerar fine-tune tiene sentido. Enrutar bien es diagnosticar el tipo de fallo y mandarlo a su palanca; enrutar mal es gastar semanas en un fine-tune para un problema que un ajuste de prompt resolvía en una tarde.

Conexión con el módulo: esta es la lección que cierra el arco. Recorriste el flywheel (2), la observabilidad (3), la captura (4), el cierre hacia el eval (5) y las palancas (6); aquí los ensamblas en el lazo de datos completo y ejecutable. Y prepara el proyecto: en la lección 8 vas a montar este lazo entero sobre la búsqueda semántica. La frontera sigue firme: cómo se implementa cada palanca (indexar el retrieval, entrenar el fine-tune) es AI Engineering; enrutar el feedback a la palanca correcta y verificar con el eval es de aquí.

Analogía: el triage de urgencias

En una sala de urgencias de un hospital hay un proceso que decide todo lo demás: el triage. Cuando llegan pacientes, una enfermera experimentada no los atiende en orden de llegada ni los manda a todos al mismo especialista. Los clasifica por tipo y gravedad, y enruta cada uno a donde corresponde: el hueso roto va a traumatología, el dolor de pecho va a cardiología con prioridad máxima, el resfriado va a consulta general y puede esperar. El triage no cura a nadie —eso lo hacen los especialistas—; su trabajo es diagnosticar el tipo y mandar cada caso a la palanca correcta, en el orden correcto. Un hospital sin triage, que atendiera a todos igual y en orden de llegada, colapsaría: mandaría el infarto a esperar detrás del resfriado y el resfriado a ocupar a un cardiólogo.

Cerrar el lazo de datos es exactamente un triage del feedback. Los thumbs_down que llegan no son todos el mismo problema: unos son "el dato existía pero no se recuperó" (van a retrieval), otros son "el tono está mal en todas las respuestas" (van al prompt), otros son "hay una clase entera de tarea que el sistema no domina" (van a considerar fine-tune). Tu trabajo al cerrar el lazo no es aplicar el mismo arreglo a todos —eso es el hospital sin triage—; es clasificar cada fallo por su tipo y enrutarlo a la palanca que lo cura. Y como en el hospital, hay un orden de prioridad: se atiende primero lo más barato y lo que le duele a más gente, y se reserva la palanca más cara (fine-tune, la cirugía) para los casos que de verdad la necesitan.

La analogía también ilumina la red de seguridad. En un buen hospital, además de curar a cada paciente, se registra cada caso en el historial —para detectar patrones, para que el mismo error no se repita, para aprender—. Ese registro es el eval-set: pase lo que pase con el triage, cada fallo queda anotado permanentemente, de modo que si vuelve a aparecer, el sistema ya lo reconoce. Curar (la palanca) y registrar (el eval) son cosas distintas, y las dos son necesarias.

Ejemplo trabajado: el triage del feedback, ejecutado de punta a punta

No vamos a describir el lazo completo: lo vamos a ejecutar. Modelamos el cierre del lazo del agente de soporte de punta a punta: tomamos el feedback etiquetado por tipo de fallo, lo agrupamos, enrutamos cada grupo a su palanca, metemos todos los fallos al eval-set, aplicamos las palancas baratas y reversibles, y re-corremos el eval para probar que el sistema mejoró sin regresar. Fíjate en el score subiendo al final: esa es la prueba de que el lazo se cerró de verdad.

# Leccion 07 (M7) — enrutar la SENAL de feedback a la palanca correcta. SIMULADO.
# Cero red, cero API, cero claves. Determinista.
#
# El feedback no se arregla de una sola forma. Se AGRUPA por tipo de fallo y cada
# grupo se enruta a su palanca: prompt / retrieval(RAG) / eval-solo / considerar-finetune.
# Y SIEMPRE, pase lo que pase, los casos fallidos entran al eval-set (la red de seguridad).

# El feedback_loop, ya etiquetado por TIPO DE FALLO (el diagnostico):
#   retrieval_miss : el dato correcto EXISTE pero no se recupero/mostro
#   prompt_gap     : problema sistematico de tono/formato/instruccion
#   knowledge_gap  : clase entera de comportamiento estable que prompt+RAG no cubren
FEEDBACK_LOG = [
    {"id": "f1",  "input": "politica de devolucion de electronicos", "failure": "retrieval_miss"},
    {"id": "f2",  "input": "garantia de un producto reacondicionado", "failure": "retrieval_miss"},
    {"id": "f3",  "input": "horario de atencion en feriados",        "failure": "retrieval_miss"},
    {"id": "f4",  "input": "responde muy cortante y sin saludo",     "failure": "prompt_gap"},
    {"id": "f5",  "input": "no usa el formato de lista que pedimos", "failure": "prompt_gap"},
    {"id": "f6",  "input": "traducir jerga legal de contratos B2B",  "failure": "knowledge_gap"},
    {"id": "f7",  "input": "clasificar 40 subtipos de reclamo raros", "failure": "knowledge_gap"},
    {"id": "f8",  "input": "no encontro el manual del producto X",   "failure": "retrieval_miss"},
]

from collections import Counter
clusters = Counter(r["failure"] for r in FEEDBACK_LOG)

# El router: mapea un tipo de fallo a la palanca arquitectonica adecuada.
# NOTA DE FRONTERA: como se IMPLEMENTA cada palanca (indexar, entrenar) es AI Eng.
def route(failure_type):
    return {
        # El dato existe pero no llego: mejora la RECUPERACION (RAG).
        "retrieval_miss": ("retrieval (RAG)", "el dato existe; falta recuperarlo/mostrarlo"),
        # Tono/formato/instruccion sistematico: se arregla en el PROMPT.
        "prompt_gap":     ("prompt",          "instruccion/formato: barato y reversible, empieza aqui"),
        # Clase entera estable que prompt+RAG no cubren: CONSIDERA fine-tune (con sus costos).
        "knowledge_gap":  ("considerar fine-tune", "estable + volumen; pesar costo de re-entrenar (L6)"),
    }[failure_type]

print("=== Feedback agrupado por tipo de fallo, y su palanca ===")
print(f"{'tipo de fallo':<16}{'casos':>6}   palanca -> razon")
for ftype, count in clusters.most_common():
    lever, reason = route(ftype)
    print(f"{ftype:<16}{count:>6}   {lever}  ->  {reason}")
print()

# La red de seguridad: TODOS los casos fallidos entran al eval-set, se arreglen como se arreglen.
new_eval_cases = [r["id"] for r in FEEDBACK_LOG]
print(f"Red de seguridad: los {len(new_eval_cases)} casos fallidos entran al eval-set "
      f"(M3), sin importar la palanca.")
print(f"  {new_eval_cases}")
print()

# --- El lazo, cerrado y VERIFICADO: aplicar las palancas y re-correr el eval. ---
# Modelo: el sistema "resuelve" un caso si su palanca fue aplicada. El eval mide
# la fraccion de casos (viejos + nuevos) resueltos, antes y despues de cerrar el lazo.
BASE_SOLVED = 6      # el sistema ya resolvia 6 casos base del eval-set original
BASE_TOTAL = 6

# Antes de cerrar el lazo: el eval-set aumentado incluye los 8 fallos, sin resolver.
before_solved = BASE_SOLVED
before_total = BASE_TOTAL + len(FEEDBACK_LOG)

# Aplicamos las palancas baratas y reversibles YA (prompt + retrieval); fine-tune
# queda como propuesta a evaluar, no se aplica en esta iteracion.
applied_now = {"retrieval_miss", "prompt_gap"}
fixed = sum(1 for r in FEEDBACK_LOG if r["failure"] in applied_now)
deferred = sum(1 for r in FEEDBACK_LOG if r["failure"] not in applied_now)

after_solved = BASE_SOLVED + fixed
after_total = BASE_TOTAL + len(FEEDBACK_LOG)

THRESHOLD = 0.80
def gate(s):
    return "PASS" if s >= THRESHOLD else "FAIL"

s_before = before_solved / before_total
s_after = after_solved / after_total
print("=== El lazo cerrado y verificado por el eval (umbral 0.80) ===")
print(f"  antes de cerrar el lazo : {before_solved}/{before_total} = {s_before:.2f}  [{gate(s_before)}]")
print(f"  tras aplicar prompt+RAG : {after_solved}/{after_total} = {s_after:.2f}  [{gate(s_after)}]")
print(f"  casos aun sin resolver  : {deferred}  (los knowledge_gap: decision de fine-tune pendiente)")
print()
print("El lazo completo: observar -> capturar -> agrupar -> enrutar a la palanca")
print("mas barata que sirva -> re-correr el eval para PROBAR que mejoro sin regresar.")

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

=== Feedback agrupado por tipo de fallo, y su palanca ===
tipo de fallo    casos   palanca -> razon
retrieval_miss       4   retrieval (RAG)  ->  el dato existe; falta recuperarlo/mostrarlo
prompt_gap           2   prompt  ->  instruccion/formato: barato y reversible, empieza aqui
knowledge_gap        2   considerar fine-tune  ->  estable + volumen; pesar costo de re-entrenar (L6)

Red de seguridad: los 8 casos fallidos entran al eval-set (M3), sin importar la palanca.
  ['f1', 'f2', 'f3', 'f4', 'f5', 'f6', 'f7', 'f8']

=== El lazo cerrado y verificado por el eval (umbral 0.80) ===
  antes de cerrar el lazo : 6/14 = 0.43  [FAIL]
  tras aplicar prompt+RAG : 12/14 = 0.86  [PASS]
  casos aun sin resolver  : 2  (los knowledge_gap: decision de fine-tune pendiente)

El lazo completo: observar -> capturar -> agrupar -> enrutar a la palanca
mas barata que sirva -> re-correr el eval para PROBAR que mejoro sin regresar.

Lee la salida en tres partes, porque juntas son el lazo completo.

El triage: agrupar y enrutar. La primera tabla es el triage en acción. Los ocho fallos capturados se agruparon por tipo, y cada grupo se enrutó a su palanca. Los cuatro retrieval_miss —casos donde el dato existía pero no se recuperó (la política de devolución, la garantía, el horario de feriados, el manual del producto)— van a retrieval (RAG): el arreglo es asegurarse de que esos documentos estén en el índice y se recuperen. Los dos prompt_gap —tono cortante, formato incorrecto— van al prompt: son problemas de instrucción, y se arreglan ahí, que es lo más barato. Los dos knowledge_gap —traducir jerga legal, clasificar 40 subtipos raros— van a considerar fine-tune, con la advertencia de la lección 6: solo si son estables y de volumen suficiente para justificar el costo. Fíjate en que el enrutamiento diagnostica cada fallo en vez de aplicar la misma herramienta a todos: es el triage que manda el hueso roto a traumatología y el dolor de pecho a cardiología.

La red de seguridad: todos al eval-set. La línea del medio es la regla universal de la lección 5, aplicada sin excepción: los ocho casos fallidos entran al eval-set, se arreglen con la palanca que se arreglen. El fallo de tono va al eval (con un criterio de tono), el dato faltante va al eval (con un criterio de presencia de la política), la tarea especializada va al eval (con su criterio). Curar es la palanca; registrar es el eval. Los dos son necesarios, y el eval es universal: ningún fallo se cierra sin dejar su caso en la compuerta, para que no pueda regresar.

La verificación: el score sube, y se prueba. La última parte es lo que distingue un lazo cerrado de una buena intención. Antes de arreglar nada, el eval-set aumentado —que ahora incluye los ocho fallos— da 6/14 = 0.43: FALLA. Eso es honesto: el sistema resuelve los seis casos base, pero falla los ocho que el feedback reveló. Luego aplicamos las palancas baratas y reversibles (prompt + retrieval, que arreglan seis de los ocho) y dejamos pendiente la decisión de fine-tune para los dos knowledge_gap (que exige más análisis de costo). Re-corremos el eval: 12/14 = 0.86: PASA. El score subió de 0.43 a 0.86, y —esto es lo crucial— no lo afirmamos, lo medimos con el eval aumentado. El lazo se cerró y se probó que se cerró. Los dos casos que quedan sin resolver son los de fine-tune, correctamente diferidos: no se saltó a la palanca cara por prisa, se aplicó primero todo lo barato y se dejó la decisión costosa para un análisis aparte.

La lección en una frase: el lazo se cierra con un triage —agrupa el feedback por tipo, enruta cada grupo a la palanca más barata que sirva, registra todo en el eval— y se verifica re-corriendo el eval, que prueba que mejoraste sin regresar.

El flujo del lazo completo, y las reglas que lo gobiernan

El ejemplo ejecutó el lazo; vale la pena verlo como el flujo completo del módulo entero, con las reglas que lo hacen funcionar.

flowchart TD
    U["Uso (produccion)"] --> O["Observabilidad<br/>(senal de calidad, L3)"]
    O --> C["Captura de feedback<br/>(thumbs / correccion / accion, L4)"]
    C --> G["Agrupar por tipo de fallo<br/>(el triage)"]
    G --> R{"Enrutar<br/>por tipo"}
    R -->|"dato falto"| RAG["retrieval / RAG"]
    R -->|"tono / formato"| PR["prompt"]
    R -->|"clase estable +<br/>alto volumen"| FT["considerar fine-tune (L6)"]
    G --> EV["TODO al eval-set<br/>(red de seguridad, L5)"]
    RAG --> RE["Re-correr el eval<br/>(verificar: mejoro sin regresar)"]
    PR --> RE
    FT --> RE
    EV --> RE
    RE --> U

Regla 1: diagnostica el tipo de fallo antes de elegir la palanca. El enrutamiento correcto depende de clasificar bien. Un fallo de "el modelo no tenía el dato" y uno de "el modelo tenía el dato pero lo dijo con mal tono" se ven parecidos en la queja del cliente, pero van a palancas distintas (retrieval vs prompt). El triage empieza por el diagnóstico: ¿qué tipo de fallo es? Esto suele hacerse agrupando los thumbs_down por patrón —muchos casos parecidos revelan un tipo de fallo sistemático—.

Regla 2: empieza por la palanca más barata que sirva. Es la escalera de la lección 6, aplicada al enrutamiento. Ante un fallo, el orden de preferencia es prompt (barato, instantáneo) → retrieval (frescura/volumen) → fine-tune (caro, rígido). En el ejemplo, aplicamos prompt y retrieval de inmediato (baratos y reversibles) y diferimos fine-tune. No es que fine-tune esté prohibido; es que se reserva para cuando las palancas baratas no alcanzan, y su decisión merece un análisis de costo aparte (¿el comportamiento es estable?, ¿el volumen justifica re-entrenar?).

Regla 3: todo fallo va al eval-set, pase lo que pase. La red de seguridad universal. Curar el fallo (con la palanca) y protegerse de que vuelva (con el eval) son cosas distintas y las dos son obligatorias. Un fallo arreglado en el prompt pero no registrado en el eval puede regresar el día que alguien toque el prompt; un fallo en el eval está protegido para siempre.

Regla 4: verifica re-corriendo el eval. Un arreglo sin verificar es una esperanza, no un hecho. Después de mover la palanca, re-corres el eval aumentado y confirmas dos cosas: que los casos arreglados ahora pasan, y que no rompiste ningún otro caso (una regresión colateral). El score que sube (0.43 → 0.86) es la prueba ejecutada de que el lazo se cerró de verdad. Sin esta verificación, no sabrías si tu arreglo funcionó ni si causó daño en otro lado.

Estas cuatro reglas son el lazo de datos completo, y son la capacidad que te llevas del módulo: observar, capturar, agrupar, enrutar a la palanca más barata que sirva, registrar todo en el eval, y verificar con el eval que mejoraste sin regresar. Ese ciclo, repetido, es el flywheel de la lección 2 girando de verdad.

Errores comunes

Aplicar la misma palanca a todos los fallos (de falta de triage). Qué pasa: el equipo tiene una palanca favorita —normalmente el prompt, a veces fine-tune— y la aplica a todo el feedback sin diagnosticar el tipo de fallo. Mete al prompt información que debería estar en el retrieval (y el prompt crece hasta reventar la ventana de contexto), o entrena un fine-tune para un problema de tono que un ajuste de prompt resolvía. Arregla algunos fallos por suerte y otros no, porque la herramienta no corresponde al problema. Por qué pasa: es más fácil aplicar la herramienta que dominas que diagnosticar cada caso; es el hospital sin triage que atiende a todos igual. Cómo detectarlo: si todos tus arreglos usan la misma palanca sin importar el fallo, no estás enrutando. Cómo corregirlo: clasifica cada fallo por tipo antes de elegir la palanca —dato faltante → retrieval, tono/formato → prompt, clase estable → considerar fine-tune—.

Saltar a la palanca cara sin agotar las baratas (de orden invertido). Qué pasa: ante un fallo, el equipo va directo a fine-tune (o a un RAG complejo) sin probar primero el prompt. Invierte semanas en la palanca cara para un problema que la barata resolvía en horas. Es lo mismo que la sobreingeniería de la lección 6, pero visto desde el enrutamiento: el triage mandó el resfriado a cirugía. Por qué pasa: la palanca cara tiene prestigio y da sensación de "resolver de verdad"; el orden de esfuerzo está invertido respecto al de prestigio. Cómo detectarlo: si estás aplicando una palanca cara y no probaste la barata para ese mismo fallo, invertiste el orden. Cómo corregirlo: sube la escalera —prompt primero, retrieval si necesitas frescura/volumen, fine-tune solo si los dos no alcanzan—; aplica lo barato y reversible de inmediato, y defiere la decisión cara a un análisis de costo (como los knowledge_gap del ejemplo).

Arreglar sin verificar y creer que el lazo se cerró (de proceso). Qué pasa: el equipo mueve la palanca —ajusta el prompt, agrega documentos al retrieval— y da el fallo por cerrado sin re-correr el eval. No sabe si el arreglo de verdad resolvió el caso, ni si causó una regresión en otro lado. A veces el arreglo del caso A rompió el caso B, y nadie se entera hasta que un cliente se queja de B. Por qué pasa: mover la palanca se siente como terminar; re-correr el eval es un paso extra que parece opcional. Cómo detectarlo: si tus arreglos no terminan con un eval que sube (y sin casos que bajen), no cerraste el lazo, solo lo intentaste. Cómo corregirlo: verifica siempre re-corriendo el eval aumentado —el score que sube sin que otros casos bajen es la prueba de que el arreglo funcionó y no dañó nada—.

Ejercicios

Ejercicio 1 — El triage. Explica, con la analogía de urgencias, por qué enrutar el feedback por tipo de fallo es mejor que aplicar la misma palanca a todos. Luego, para estos tres thumbs_down del agente de soporte, di a qué "especialista" (palanca) los enrutarías y por qué: (a) "preguntó por la política de reembolso de un producto digital y el agente dijo que no la conocía, aunque esa política existe en nuestra documentación"; (b) "el agente contestó bien pero tuteó al cliente cuando nuestra marca usa un tono formal"; (c) "el cliente pidió que el agente redactara la respuesta en el dialecto legal de un contrato B2B, algo que hacemos miles de veces al mes con un formato muy específico".

Ver solución

Enrutar por tipo de fallo es mejor que aplicar la misma palanca a todos por la misma razón que el triage es mejor que atender a todos igual: cada tipo de problema tiene un tratamiento distinto, y aplicar el tratamiento equivocado no cura y desperdicia recursos. Mandar un dato faltante al prompt (cuando debía ir a retrieval) infla el prompt sin resolver la raíz; entrenar un fine-tune para un problema de tono (cuando bastaba el prompt) gasta semanas en algo que se arreglaba en horas. El triage manda cada caso a la palanca que lo cura.

  • (a) Política que existe pero el agente no conoció → retrieval (RAG). El dato existe en la documentación pero no llegó al modelo: es un retrieval_miss. El arreglo es asegurar que ese documento esté en el índice y se recupere. No es un problema de prompt (el modelo razona bien, le falta el dato) ni de fine-tune (no hace falta hornear nada, solo recuperar el documento correcto).
  • (b) Tuteó cuando la marca es formal → prompt. Es un problema de tono/formato sistemático: un prompt_gap. Se arregla agregando una instrucción de tono al prompt ("usa siempre trato formal de usted"). Barato, instantáneo, reversible. No necesita retrieval (no falta información) ni fine-tune (es un ajuste de instrucción simple).
  • (c) Redactar en dialecto legal B2B, miles de veces al mes, formato muy específico → considerar fine-tune. Es un knowledge_gap: una clase entera de comportamiento (un estilo legal muy específico) que el prompt puede aproximar pero quizá no con la consistencia necesaria, y es estable (el formato legal no cambia) y de alto volumen (miles al mes). Cumple los criterios de la lección 6. Aun así, "considerar" no es "hacer": primero se prueba el prompt con ejemplos y se mide; solo si no alcanza, se pesa el costo de fine-tune.

Ejercicio 2 — La verificación que faltó. Un equipo agrupó su feedback, enrutó cada grupo a su palanca, aplicó los arreglos, y anunció "cerramos el lazo, la calidad mejoró". Pero no re-corrió el eval. Explica qué no pueden saber por haberse saltado la verificación, y describe qué habría pasado si el arreglo de un fallo hubiera roto otro caso que antes pasaba.

Ver solución

Por haberse saltado la verificación, el equipo no puede saber dos cosas: primero, si sus arreglos de verdad resolvieron los fallos (mover la palanca es una hipótesis; que funcionó es un hecho que solo el eval confirma); y segundo, si algún arreglo causó una regresión —rompió un caso que antes pasaba—. Anunciaron "la calidad mejoró" como una creencia, no como un dato. Podría ser cierto, podría ser falso, y no tienen forma de distinguirlo.

Si el arreglo de un fallo hubiera roto otro caso, esto es lo que habría pasado sin verificación: el equipo cree que subió la calidad (arregló los fallos que veía), pero en realidad la movió de lugar —un ajuste de prompt para arreglar el tono, por ejemplo, podría haber cambiado cómo el modelo responde otra categoría de preguntas y romperla—. Como no re-corrió el eval aumentado, el caso roto pasa desapercibido hasta que un cliente se queja de ese nuevo problema, semanas después. El daño es doble: introdujeron una regresión y la creyeron una mejora.

Con verificación, esto no pasa: al re-correr el eval aumentado (que incluye tanto los casos viejos como los nuevos del feedback), un caso roto haría bajar el score o aparecería como un caso que ahora falla, y el equipo lo vería antes de desplegar. La regla es que un arreglo no está cerrado hasta que el eval sube y ningún caso previo baja. El score que sube sin regresiones (0.43 → 0.86 en el ejemplo, sin romper los 6 base) es la única prueba de que el lazo se cerró de verdad. Anunciar la mejora sin ese número es cerrar el lazo con los ojos vendados.

Ejercicio 3 — El lazo completo en una feature nueva. Mercado lanza un nuevo asistente que recomienda productos complementarios ("compraste una cámara, ¿quieres una funda?"). Después de un mes, el feedback muestra tres patrones de fallo: (a) recomienda accesorios que no son compatibles con el producto comprado (dato de compatibilidad que existe en la ficha del producto pero el asistente no consultó); (b) sus mensajes son demasiado insistentes y los usuarios se quejan del tono; (c) para una categoría entera de productos técnicos (equipo de fotografía profesional), sus recomendaciones son consistentemente pobres porque no entiende ese dominio especializado, y esa categoría representa una fracción pequeña del tráfico. Diseña el cierre del lazo: enruta cada patrón, di qué va al eval-set, y da el orden de prioridad.

Ver solución

Enrutamiento de cada patrón:

  • (a) Recomienda accesorios incompatibles, con el dato de compatibilidad existiendo en la ficha → retrieval (RAG). Es un retrieval_miss: la información existe (la ficha del producto tiene la compatibilidad) pero el asistente no la consultó. El arreglo es asegurar que la compatibilidad se recupere y se le pase al modelo antes de recomendar. No es prompt (el modelo razona bien, le falta el dato) ni fine-tune (no hay que hornear nada).
  • (b) Tono demasiado insistente → prompt. Es un prompt_gap: un problema de tono sistemático. Se arregla con una instrucción de tono en el prompt ("recomienda de forma sutil, sin insistir"). Barato, reversible.
  • (c) Recomendaciones pobres en fotografía profesional, categoría de tráfico pequeño → NO fine-tune (por ahora). Aunque es un knowledge_gap (un dominio especializado que el modelo no domina), no cumple el criterio de volumen de la lección 6: la categoría es una fracción pequeña del tráfico, así que el costo de entrenar un fine-tune no se amortiza. La mejor opción probablemente es RAG (agregar documentación de fotografía profesional al índice) o mejorar el prompt con contexto de dominio; si ni eso alcanza y la categoría creciera en volumen, entonces se reconsideraría fine-tune. Diagnosticar bien el knowledge_gap no significa saltar a fine-tune: significa pesar sus criterios (aquí, el volumen no lo justifica).

Qué va al eval-set: los tres patrones, con su criterio (compatibilidad correcta para a, tono sutil para b, calidad de recomendación en fotografía para c), sin excepción. La red de seguridad es universal.

Orden de prioridad: primero (b) —el prompt es lo más barato y el tono insistente afecta a todos los usuarios—; luego (a) —el retrieval de compatibilidad, que afecta a muchas recomendaciones y es un arreglo de esfuerzo medio—; y (c) al final —afecta poco tráfico y su mejor palanca (RAG de dominio) requiere más trabajo, así que se atiende después de lo barato y de alto impacto—. El orden sigue las reglas: la palanca más barata y lo que le duele a más gente, primero; la cara y de bajo impacto, después. Y todo verificado re-corriendo el eval tras cada arreglo.

Resumen y siguiente paso

En esta lección armaste el lazo de datos completo, la síntesis del módulo: el feedback se agrupa por tipo de fallo, cada grupo se enruta a su palanca —prompt, retrieval o considerar fine-tune—, todo fallo va al eval-set como red de seguridad, y el eval verifica que el arreglo mejoró sin regresar. Lo viste con la analogía del triage de urgencias —clasificar cada caso y enrutarlo al especialista correcto, en el orden correcto, registrando todo en el historial— y lo ejecutaste de punta a punta: los ocho fallos se agruparon y enrutaron (retrieval, prompt, considerar fine-tune), los ocho entraron al eval-set, y al aplicar las palancas baratas (prompt+RAG) y diferir fine-tune, el score subió de 0.43 a 0.86, medido y probado por el eval aumentado. Entendiste las cuatro reglas del lazo: diagnostica el tipo antes de elegir la palanca, empieza por la más barata que sirva, todo va al eval, y verifica re-corriendo el eval.

Antes de avanzar deberías poder: hacer el triage de un conjunto de fallos (clasificar por tipo y enrutar a la palanca); explicar por qué el orden es prompt → retrieval → fine-tune; justificar por qué todo fallo va al eval-set aunque se arregle en otra palanca; y explicar por qué la verificación (re-correr el eval) es lo que distingue un lazo cerrado de una buena intención.

Lo que sigue es el proyecto, donde montas este lazo completo con tus manos sobre una feature nueva: la búsqueda semántica, que aprende de un feedback distinto —los clicks de los usuarios—. Vas a construir la observabilidad con su señal de calidad, capturar los clicks, cerrar el lazo convirtiéndolos en casos del eval-set, y escribir el ADR de la decisión prompt vs RAG vs fine-tune para un catálogo vivo. Es el paso de "entiendo el lazo de datos" a "monté el lazo de datos de una feature de punta a punta, y lo probé ejecutándolo".

Recursos

  • Chip Huyen — AI Engineering (O'Reilly) — el tratamiento de cómo el feedback de producción se analiza, se clasifica por tipo de fallo, y alimenta las distintas palancas de mejora (prompt, RAG, fine-tune); el respaldo de esta lección, con la mecánica de cada palanca como su frontera.
  • Chip Huyen — Designing Machine Learning Systems (O'Reilly) — el ciclo iterativo de mejora de un sistema de ML (observar, diagnosticar, actuar, verificar) que esta lección aplica al lazo de datos de una feature de IA.
  • martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — el catálogo de patrones ubica el lazo de datos, la evaluación continua y la elección de palancas en el mapa arquitectónico completo; el marco de síntesis del módulo. En inglés.
  • Ecosistema AI Engineering (remisión) — para implementar cada palanca a la que enrutas el feedback: construir el retrieval, hacer prompt engineering serio, entrenar el fine-tune. Este módulo enseña a enrutar y verificar; AI Engineering enseña a construir la palanca.
← Anterior6. Prompt vs RAG vs fine-tune como decisión arquitectónicaSiguiente →8. Proyecto: construye el lazo de datos de una feature de Mercado