2. El flywheel: el uso se vuelve un mejor sistema

Descripción

Al terminar esta lección vas a entender —y a haber medido— la idea que motiva todo el módulo: un sistema con lazo de datos compone mejoras con el tiempo, y uno sin lazo se queda congelado donde nació. El módulo 1 te dio la lección de que un LLM no es una función normal; esta te da una lección igual de importante sobre el sistema que lo rodea: su calidad no es un valor fijo que se decide el día del lanzamiento, sino una trayectoria que depende de si la arquitectura tiene un mecanismo para aprender de su uso. Dos equipos pueden lanzar la misma feature, con el mismo modelo, el mismo día; seis meses después, el que diseñó un lazo de datos tiene una feature notablemente mejor, y el que no, tiene exactamente la misma del primer día. La diferencia no está en el modelo; está en el lazo.

El nombre técnico de ese fenómeno es flywheel —rueda de inercia—, y la metáfora es precisa: una rueda de inercia cuesta mucho empezar a girar, pero una vez en movimiento, cada empujón se acumula sobre el impulso anterior y la rueda gira cada vez más rápido con cada vez menos esfuerzo. El flywheel de datos gira así: el uso genera datos (feedback sobre qué funciona y qué no), los datos permiten mejorar el sistema, el sistema mejor atrae más uso, y más uso genera más datos. Cada vuelta hace la siguiente más fácil. Y la propiedad que lo hace poderoso es que compone: la mejora de esta semana se apila sobre la de la anterior, así que la ventaja no crece de forma lineal sino que se acumula —por eso los sistemas con flywheel se separan de sus competidores de una forma que un competidor sin flywheel no puede alcanzar solo con un modelo más grande—.

Conexión con el módulo: esta lección instala la motivación del módulo entero. En la lección 1 viste el lazo en miniatura —el feedback se volvió casos de eval—; aquí ves por qué vale la pena montar todo lo que viene: la observabilidad (lección 3), la captura de feedback (lección 4) y el cierre del lazo (lección 5) no son adornos, son las piezas que hacen girar este flywheel. Todo lo que hagas en las próximas lecciones es, en el fondo, construir y acelerar la rueda que vas a medir aquí. Y la frontera es la de siempre: aquí el flywheel es la decisión de arquitectura (montar el lazo); cómo entrenar un modelo con los datos que el flywheel acumula es AI Engineering.

Analogía: la bola de nieve que baja la ladera

Ya viste la app de mapas en la lección 1; añade ahora esta, que captura la parte de composición. Imagina una bola de nieve en la cima de una ladera. Al principio es pequeña y hay que empujarla con esfuerzo. Pero en cuanto empieza a rodar, pasa algo que no pasa con una piedra: al girar, recoge más nieve, y al ser más grande, recoge todavía más en cada vuelta. Su crecimiento no es constante; se acelera, porque cada vuelta la hace más grande y una bola más grande barre más superficie en la siguiente vuelta. Una piedra que rueda por la misma ladera llega abajo del mismo tamaño con que empezó: rodar no la cambia. La bola de nieve llega abajo convertida en un alud.

Esa es exactamente la diferencia entre un sistema con lazo de datos y uno sin él. El sistema sin lazo es la piedra: rueda (se usa) pero no cambia; el uso pasa por él sin dejar rastro, y llega al final del año igual que empezó. El sistema con lazo es la bola de nieve: cada uso recoge datos, cada dato lo mejora, y un sistema mejor atrae más uso que recoge más datos. El crecimiento compone. Y hay una consecuencia competitiva dura: si tú tienes la bola de nieve y tu competidor tiene la piedra, la brecha entre ustedes no se mantiene constante —se abre cada vuelta—. Por eso el lazo de datos no es una optimización menor; es, muchas veces, la ventaja arquitectónica que define quién gana un mercado de IA.

Un detalle honesto de la analogía: la bola de nieve solo compone si de verdad recoge nieve en cada vuelta. Una bola sobre hielo pelado rueda sin crecer. En nuestros términos: el flywheel solo gira si el lazo está cerrado —si el feedback recogido de verdad se realimenta al sistema—. Un sistema que captura feedback pero nunca lo usa es una bola sobre hielo: se mueve, parece que debería crecer, pero no crece. Esa es la advertencia de la caja de sugerencias de la lección 1, vista desde el flywheel.

Ejemplo trabajado: dos sistemas idénticos, uno con lazo y otro sin él

No vamos a afirmar que el flywheel compone: lo vamos a ejecutar y a medir. Modelamos dos sistemas idénticos el día de su lanzamiento —el mismo agente de soporte, que arranca sabiendo responder solo los 4 tipos de pregunta más comunes— y les damos rondas de uso. El sistema A tiene lazo de datos: cada ronda, el feedback de los usuarios le revela los tipos de pregunta que más fallan, y el equipo los arregla (y los mete al eval-set). El sistema B no tiene lazo: el uso pasa por él sin dejar rastro, y su cobertura nunca cambia. Medimos la calidad de cada uno ronda tras ronda, donde la calidad es la fracción del tráfico real que el sistema resuelve bien.

# Leccion 02 (M7) — el FLYWHEEL: el uso se vuelve un mejor sistema. SIMULADO.
# Cero red, cero API, cero claves. Determinista.
#
# La tesis: uso -> datos (feedback) -> mejor sistema -> mas uso. Modelamos DOS
# sistemas identicos al arrancar; uno tiene el lazo de datos y el otro no, y
# medimos como diverge la calidad ronda tras ronda.

# La distribucion REAL de preguntas que llegan al agente de soporte de Mercado:
# 12 tipos de pregunta, cada uno con su frecuencia (que tan seguido lo preguntan).
# Suman 1.0. NOTA: elegir esta distribucion es diseno de datos (AI Eng); aqui el LAZO.
TRUE_DISTRIBUTION = {
    "tracking":        0.20,
    "envio_tiempo":    0.16,
    "devolucion":      0.13,
    "cuotas":          0.11,
    "cancelar":        0.09,
    "producto_roto":   0.08,
    "factura":         0.07,
    "cupon":           0.06,
    "cambio_direccion": 0.05,
    "contacto_vendedor": 0.03,
    "cambio_talla":    0.01,
    "producto_faltante": 0.01,
}

# El sistema arranca sabiendo responder solo los 4 tipos mas comunes (los "faciles").
INITIAL_KNOWN = {"tracking", "envio_tiempo", "devolucion", "cuotas"}

def quality(known):
    # El score = fraccion del TRAFICO real que el sistema resuelve bien
    # (suma de frecuencias de los tipos que sabe responder).
    return sum(freq for t, freq in TRUE_DISTRIBUTION.items() if t in known)

def rank_unknown_by_frequency(known):
    # El feedback surge primero en lo que MAS gente pregunta y falla: los tipos
    # desconocidos ordenados por frecuencia (los thumbs_down mas voluminosos).
    unknown = [(t, f) for t, f in TRUE_DISTRIBUTION.items() if t not in known]
    return sorted(unknown, key=lambda tf: tf[1], reverse=True)

ROUNDS = 6
LEARN_PER_ROUND = 2   # cada ronda, el lazo aprende los 2 tipos mas frecuentes que fallan

# --- Sistema A: CON lazo de datos. Cada ronda aprende de lo que el usuario reporto. ---
known_loop = set(INITIAL_KNOWN)
# --- Sistema B: SIN lazo. Nunca captura feedback; su cobertura no cambia. ---
known_noloop = set(INITIAL_KNOWN)

print(f"{'ronda':<7}{'CON lazo':>12}{'SIN lazo':>12}   tipos aprendidos esa ronda (del feedback)")
print("-" * 78)
for r in range(ROUNDS):
    s_loop = quality(known_loop)
    s_noloop = quality(known_noloop)
    to_learn = [t for t, _f in rank_unknown_by_frequency(known_loop)[:LEARN_PER_ROUND]]
    print(f"{r:<7}{s_loop:>12.2f}{s_noloop:>12.2f}   {to_learn if to_learn else '(ya cubre todo)'}")
    # El lazo cierra: los tipos que el usuario reporto se arreglan (y entran al eval-set).
    known_loop.update(to_learn)

print("-" * 78)
print(f"{'final':<7}{quality(known_loop):>12.2f}{quality(known_noloop):>12.2f}")
print()
print("El flywheel, en numeros:")
print(f"  arranque (ambos)     : score {quality(INITIAL_KNOWN):.2f}")
print(f"  CON lazo tras {ROUNDS} rondas: score {quality(known_loop):.2f}"
      f"  (+{(quality(known_loop)-quality(INITIAL_KNOWN))*100:.0f} puntos)")
print(f"  SIN lazo tras {ROUNDS} rondas: score {quality(known_noloop):.2f}"
      f"  (+{(quality(known_noloop)-quality(INITIAL_KNOWN))*100:.0f} puntos)")
print(f"  brecha final CON vs SIN lazo: {(quality(known_loop)-quality(known_noloop))*100:.0f} puntos")

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

ronda      CON lazo    SIN lazo   tipos aprendidos esa ronda (del feedback)
------------------------------------------------------------------------------
0              0.60        0.60   ['cancelar', 'producto_roto']
1              0.77        0.60   ['factura', 'cupon']
2              0.90        0.60   ['cambio_direccion', 'contacto_vendedor']
3              0.98        0.60   ['cambio_talla', 'producto_faltante']
4              1.00        0.60   (ya cubre todo)
5              1.00        0.60   (ya cubre todo)
------------------------------------------------------------------------------
final          1.00        0.60

El flywheel, en numeros:
  arranque (ambos)     : score 0.60
  CON lazo tras 6 rondas: score 1.00  (+40 puntos)
  SIN lazo tras 6 rondas: score 0.60  (+0 puntos)
  brecha final CON vs SIN lazo: 40 puntos

Lee la tabla con calma, porque ahí está el flywheel hecho número.

Los dos sistemas arrancan idénticos. En la ronda 0, ambos tienen un score de 0.60: los dos saben responder los cuatro tipos de pregunta más comunes (tracking, tiempo de envío, devolución, cuotas), que juntos son el 60% del tráfico. Este es el punto de partida honesto: el mismo día, el mismo modelo, la misma cobertura. Si te quedaras solo con esta foto, dirías que las dos features son iguales. Y lo son —ese día—.

El sistema con lazo trepa; el sistema sin lazo se queda plano. A partir de la ronda 1, las trayectorias divergen. El sistema con lazo escucha su uso: el feedback le grita que "cancelar" y "producto_roto" son los tipos más frecuentes que está fallando (son el 9% y el 8% del tráfico), así que el equipo los arregla y los mete al eval-set. Su score sube a 0.77. La ronda siguiente aprende "factura" y "cupón" (0.90); luego "cambio_direccion" y "contacto_vendedor" (0.98); luego los dos raros que faltaban (1.00). En cuatro rondas cubre todo el tráfico. El sistema sin lazo, mientras tanto, se queda clavado en 0.60 todas las rondas: sin captura de feedback, nunca se entera de qué está fallando, así que nunca lo arregla. El uso pasa por él y no deja rastro. Es la piedra que llega abajo del mismo tamaño.

La brecha final es la ventaja competitiva. Después de seis rondas, el sistema con lazo resuelve el 100% del tráfico y el sin lazo el 60%: una brecha de 40 puntos entre dos features que el día del lanzamiento eran idénticas. Grábate esa cifra, porque es el argumento entero del módulo: la calidad de una feature de IA no la decide el modelo que elegiste, la decide si diseñaste el lazo que la mejora. Y fíjate en un detalle del orden en que el lazo aprendió: siempre atacó primero lo más frecuente que fallaba —cancelar (9%) antes que cambio_talla (1%)—. Eso no es casualidad; es la propiedad más útil del feedback real: el volumen de thumbs_down te ordena las fallas por impacto, así que arreglas primero lo que le duele a más gente. El lazo no solo te dice qué está roto; te dice qué arreglar primero.

Por qué el flywheel compone (y qué lo puede frenar)

El ejemplo tocó, sin desarrollarlas del todo, las propiedades que hacen del flywheel una decisión arquitectónica y no un adorno. Vale la pena verlas explícitas.

El uso es la materia prima, no un subproducto. En un sistema clásico, el uso es algo que soportas —más tráfico es más carga, más costo, más cosas que pueden fallar—. En un sistema con lazo de datos, el uso es además el insumo que te mejora: cada interacción es un dato potencial sobre qué funciona y qué no. Este cambio de perspectiva es el corazón del módulo: dejas de ver el uso como un costo a soportar y empiezas a verlo como la fuente de tu mejora. Por eso una feature de IA con pocos usuarios está en desventaja doble —no solo tiene menos ingresos, tiene menos datos para mejorar—.

La mejora se acumula, no se reinicia. El sistema con lazo no vuelve a cero cada ronda; parte de donde quedó. La cobertura de la ronda 3 (0.98) incluye todo lo aprendido en las rondas 1 y 2. Por eso el crecimiento es la bola de nieve y no la piedra: cada vuelta se apila sobre las anteriores. Y esto tiene una consecuencia sobre la brecha con un competidor: no se mantiene, se abre. Si tú compones y tu competidor no, cada ronda tu ventaja crece, y llega un punto en que el competidor no puede alcanzarte solo con esfuerzo puntual —tendría que montar su propio flywheel y esperar a que gire—.

El flywheel se frena si el lazo no se cierra. Aquí está el gancho con las lecciones que vienen. En el modelo, el sistema con lazo mejoró porque el feedback se realimentó —los tipos fallidos se aprendieron—. Si el sistema hubiera capturado el feedback pero nunca lo hubiera usado (la caja de sugerencias cerrada), su curva sería idéntica a la del sistema sin lazo: plana en 0.60. Es decir, capturar no basta; hay que cerrar. Por eso las próximas lecciones importan tanto: la observabilidad (3) te deja ver qué falla, la captura (4) te deja recoger el feedback, y el cierre del lazo (5) es lo que de verdad hace girar la rueda. Un flywheel con cualquiera de esas piezas rota no gira.

El flywheel del lazo de datos:

        ┌──────────────┐
        │     USO      │
        │ (mas trafico)│
        └──────┬───────┘
               │ genera
               ▼
        ┌──────────────┐         El lazo CERRADO hace girar la rueda.
        │    DATOS      │         Si se rompe cualquier flecha —no se
        │  (feedback)   │         capturan datos, o se capturan y no se
        └──────┬───────┘         realimentan— la rueda se detiene y el
               │ mejoran         sistema se congela (la piedra, no la
               ▼                 bola de nieve).
        ┌──────────────┐
        │ MEJOR SISTEMA│
        │(mas cobertura)│
        └──────┬───────┘
               │ atrae
               ▼
           (mas USO) ──► la rueda da otra vuelta, mas rapido

Errores comunes

Tratar el uso como costo y no como materia prima (de modelo mental). Qué pasa: el equipo diseña la feature de IA como diseñaría un servicio clásico —minimizar el costo por request, aguantar el pico de tráfico— y nunca se pregunta qué datos produce ese tráfico ni cómo usarlos. Optimizan la feature para soportar el uso, no para aprender de él. Resultado: una feature eficiente que nunca mejora, porque el uso pasa por ella sin dejar rastro. Por qué pasa: el instinto de sistemas clásicos ve el tráfico como carga; la idea de que el tráfico es tu insumo de mejora es nueva y hay que adoptarla deliberadamente. Cómo detectarlo: si nadie en el equipo puede decir qué se hace con el feedback que genera cada interacción, estás tratando el uso como costo. Cómo corregirlo: diseña el punto de captura del feedback (lección 4) como parte de la arquitectura, no como un extra —el uso es la nieve que la bola necesita para crecer—.

Creer que un modelo más grande sustituye al lazo (de estrategia). Qué pasa: cuando la feature no mejora, el reflejo es "cambiémosla a un modelo más potente". A veces ayuda, pero no monta el flywheel: un modelo más grande te da un salto puntual de calidad, no una trayectoria de mejora. La feature con modelo grande y sin lazo sigue siendo la piedra —mejor piedra, pero piedra—: se queda donde el nuevo modelo la dejó. Por qué pasa: cambiar de modelo es una acción concreta y visible; montar un lazo de datos es trabajo de arquitectura difuso. Cómo detectarlo: si tu plan para mejorar la feature es una lista de modelos a probar y ningún mecanismo para aprender del uso, te falta el flywheel. Cómo corregirlo: el modelo te da el punto de partida; el lazo te da la pendiente. Necesitas los dos, pero la pendiente es la que compone —y la que un competidor no puede copiar comprando el mismo modelo—.

Capturar feedback y no cerrarlo, creyendo que el flywheel gira solo (de proceso). Qué pasa: el equipo pone el thumbs up/down, ve que los usuarios lo usan, y asume que "ya tenemos el flywheel". Pero los datos se acumulan sin realimentarse: la bola está sobre hielo, se mueve pero no crece. La curva de calidad es plana como la del sistema sin lazo, y el equipo no entiende por qué "teniendo feedback" la feature no mejora. Por qué pasa: capturar es visible (aparece un botón) y se confunde con cerrar (que es invisible). Cómo detectarlo: si tienes semanas de feedback guardado y tu curva de calidad es plana, tu lazo está abierto. Cómo corregirlo: cierra el lazo (lecciones 5 y 7) —el feedback debe llegar al eval-set, al prompt o al retrieval, o la rueda no gira—.

Ejercicios

Ejercicio 1 — La bola de nieve y la piedra. Explica, con la analogía de la bola de nieve, por qué la brecha entre el sistema con lazo y el sistema sin lazo se abre en vez de mantenerse constante. Luego responde: en el ejemplo trabajado, ¿en qué ronda la brecha empezó a abrirse, y por qué el sistema con lazo atacó "cancelar" y "producto_roto" antes que "cambio_talla"?

Ver solución

La brecha se abre porque el sistema con lazo compone y el sin lazo no. La bola de nieve (con lazo) recoge más nieve cada vuelta y, al ser más grande, recoge todavía más en la siguiente —su crecimiento se acumula—. La piedra (sin lazo) rueda pero no cambia de tamaño. Como uno crece y el otro se queda igual, la distancia entre ellos no es constante: aumenta cada ronda. En términos del sistema: cada mejora del sistema con lazo se apila sobre las anteriores (la cobertura de la ronda 3 incluye todo lo de las rondas 1 y 2), mientras el sin lazo se queda en su punto de partida para siempre.

En el ejemplo, la brecha empezó a abrirse en la ronda 1: ahí el sistema con lazo subió a 0.77 y el sin lazo se quedó en 0.60, abriendo 17 puntos; en las rondas siguientes la brecha creció hasta 40 puntos. El sistema con lazo atacó "cancelar" (9% del tráfico) y "producto_roto" (8%) antes que "cambio_talla" (1%) porque el volumen de feedback ordena las fallas por impacto: los tipos más frecuentes generan más thumbs_down, así que aparecen primero y más fuerte en el feedback. Arreglar primero lo más frecuente maximiza la mejora de cada ronda —subes 17 puntos atacando cancelar+roto, subirías apenas 2 atacando los dos tipos raros—. El lazo no solo dice qué está roto; el volumen dice qué arreglar primero.

Ejercicio 2 — El flywheel frenado. Un equipo capturó thumbs up/down durante tres meses pero nunca convirtió ninguno en un caso de eval, ni ajustó el prompt, ni tocó el retrieval. Dibuja (con palabras) cómo se vería su curva de calidad comparada con las dos del ejemplo, y explica con la analogía de la bola de nieve por qué. Luego di qué mínimo tendrían que hacer para que la rueda empiece a girar.

Ver solución

Su curva de calidad se vería plana, idéntica a la del sistema sin lazo del ejemplo (0.60 en todas las rondas), no a la del sistema con lazo. Con la analogía: es una bola de nieve sobre hielo pelado —está rodando (capturando feedback, generando datos) pero no recoge nieve (no realimenta nada), así que no crece—. El movimiento da la ilusión de que debería mejorar ("tenemos feedback, ¿no?"), pero sin cierre del lazo, capturar es indistinguible de no capturar en términos de calidad: la curva es la misma.

El mínimo para que la rueda empiece a girar es cerrar el lazo: tomar los thumbs_down acumulados y realimentarlos a algo que mejore el sistema —lo más directo, convertirlos en casos del eval-set (lección 5), y de ahí enrutar cada tipo de fallo a su palanca: prompt, retrieval o considerar fine-tune (lección 7)—. En cuanto un thumbs_down se convierte en un caso de eval que un arreglo hace pasar, la bola recogió su primer puñado de nieve y la curva empieza a subir. La lección dura: capturar sin cerrar no mueve la aguja; el flywheel gira solo cuando el lazo se cierra.

Ejercicio 3 — ¿El modelo o el lazo? Dos features de Mercado tienen el mismo problema: su calidad se estancó. Para la feature X, el equipo propone "subir a un modelo más potente"; para la feature Y, "montar un lazo de datos que aprenda del feedback". Explica qué le da cada opción (un salto puntual vs una trayectoria) y en qué situación cada una es la respuesta correcta. ¿Puede una feature necesitar las dos?

Ver solución

Subir a un modelo más potente (feature X) da un salto puntual de calidad: la feature mejora de golpe hasta donde el nuevo modelo la lleva, y ahí se queda. Es la respuesta correcta cuando el techo de calidad del modelo actual es el problema —la feature ya aprendió todo lo que su modelo da de sí y necesita más capacidad bruta—. Pero no monta el flywheel: es una mejor piedra, no una bola de nieve. Si el modelo grande y sin lazo se estanca de nuevo, no hay mecanismo para seguir mejorando.

Montar un lazo de datos (feature Y) da una trayectoria de mejora: la feature sube ronda tras ronda a medida que aprende de su uso, y sigue subiendo mientras el lazo esté cerrado. Es la respuesta correcta cuando el problema es cobertura o casos no vistos —la feature falla en cosas que el feedback puede revelar y que un arreglo de prompt/retrieval puede resolver—, que es la mayoría de los casos reales. El lazo compone; el modelo grande no.

Sí, una feature suele necesitar las dos, y en un orden: el modelo te da el punto de partida (la altura desde la que arrancas), el lazo te da la pendiente (qué tan rápido mejoras). Un modelo excelente sin lazo arranca alto y se queda ahí; un modelo modesto con lazo arranca más abajo pero trepa. Lo ideal es un buen modelo con lazo: arranca alto y sigue subiendo. Y la parte estratégica: el modelo lo puede comprar cualquier competidor (todos tienen acceso a los mismos modelos), pero el lazo —los datos acumulados de tu uso— es tuyo y no se compra. Por eso, a la larga, la pendiente vence a la altura.

Resumen y siguiente paso

En esta lección mediste la motivación del módulo entero: un sistema con lazo de datos compone mejoras y se separa de la competencia; uno sin lazo se congela donde nació. Lo viste con la analogía de la bola de nieve (que recoge nieve y acelera) frente a la piedra (que rueda sin cambiar), y lo cuantificaste: dos sistemas idénticos el día del lanzamiento (0.60 los dos) terminaron, seis rondas después, en 1.00 el del lazo y 0.60 el sin lazo —una brecha de 40 puntos que el día uno no existía—. Viste las tres propiedades que hacen del flywheel una decisión de arquitectura: el uso es materia prima (no costo), la mejora se acumula (no se reinicia), y la rueda solo gira si el lazo está cerrado (capturar no basta). Y viste una propiedad práctica del feedback real: su volumen ordena las fallas por impacto, así que arreglas primero lo que le duele a más gente.

Antes de avanzar deberías poder: explicar el flywheel y por qué compone; distinguir el salto puntual de un mejor modelo de la trayectoria que da un lazo; reconocer una bola de nieve sobre hielo (feedback capturado y no cerrado); y ubicar la frontera dura (aquí el flywheel como decisión; entrenar con los datos es AI Engineering).

Lo que sigue es la primera pieza que hace girar la rueda: la observabilidad. No puedes mejorar lo que no ves, y —esto es lo importante— un componente de IA necesita una observabilidad que un log de servidor clásico no da. En la lección 3 vas a ejecutar un tablero de dos vistas: la clásica, que dice "todo verde, 100% de respuestas exitosas", y la de IA, que agrega la señal de calidad y revela una feature degradada que el monitoreo de servidor dejaba completamente invisible. Es el paso de "el lazo de datos compone" a "para que componga, primero tengo que ver qué está fallando".

Recursos

• Chip Huyen — AI Engineering (O'Reilly) — el tratamiento del data flywheel como el motor de mejora de un sistema de IA; la fuente conceptual de esta lección, con el detalle de cómo los datos de uso se convierten (mecánica, AI Eng) en un mejor sistema.
• Chip Huyen — Designing Machine Learning Systems (O'Reilly) — los capítulos sobre feedback loops y el ciclo de vida de un sistema de ML tratan el lazo de datos como una propiedad de arquitectura, no como un detalle; el marco de por qué la calidad es una trayectoria, no un valor fijo.
• martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — el catálogo de patrones de apps con LLM, con el lazo de datos y la evaluación continua ubicados en el mapa arquitectónico completo. En inglés.
• Ecosistema AI Engineering (remisión) — para cómo entrenar un modelo con los datos que el flywheel acumula, y cómo diseñar el dataset que representa el uso real; este módulo enseña a montar el lazo, AI Engineering enseña a explotar los datos que produce.