El drift: la degradación silenciosa

Descripción

Todos los fallos que has visto hasta ahora ocurren en un instante: el modelo se cae ahora, se cuelga ahora, aluvina en esta respuesta. Hay un momento en que puedes decir "aquí falló". El drift es distinto y por eso es traicionero: no ocurre en ningún momento; ocurre a lo largo de semanas. El modelo o los datos cambian poco a poco, y la calidad del sistema se degrada de forma tan gradual que nunca hay un "se rompió" —hoy acierta el 94%, la semana que viene el 93%, en un mes el 79%, y como cada paso es minúsculo, nadie lo nota—. No lanza una excepción, no aparece en un log de errores, no dispara ninguna alarma de las que has puesto. Es una alucinación distribuida en el tiempo. Esta lección instala el último modo de fallo del módulo y su única defensa posible: como el drift es silencioso y lento, la única forma de detectarlo es medir la calidad de forma continua —correr el eval del módulo 3 en producción, semana a semana, y disparar una alerta cuando el score cae—.

En la lección 2 clasificaste el drift como el fallo temporal (silencioso, lento). Aquí lo desarrollas. Vas a ver, ejecutado, el eval de la búsqueda semántica de Mercado bajar de 0.94 a 0.75 en siete semanas —a medida que llegan queries de categorías de producto nuevas que el modelo maneja peor— y un monitor que detecta la caída y dispara una alerta en la semana 4, dos semanas antes de que los usuarios empiecen a quejarse. La diferencia entre enterarte por una métrica o enterarte por un reclamo.

Conexión con el módulo. Esta lección cierra el catálogo de modos de fallo: junto con la disponibilidad (L4-L6, ruidosos) y la alucinación (L3, silencioso e instantáneo), el drift completa el mapa como el fallo silencioso y lento. Y tiende un puente al módulo 7: el monitoreo del drift es la primera puntada del lazo de datos —observar la calidad en producción para saber cuándo el sistema necesita mantenimiento—. Reusa directamente el eval del módulo 3: aquel eval era una compuerta que corría al cambiar el prompt o el modelo; aquí el mismo eval corre de forma continua en producción, como un monitor de salud. La frontera con AI Engineering: aquí el drift como propiedad arquitectónica a monitorear; la mecánica estadística de detectar distribución que cambia, y cómo reentrenar, es de AI Engineering.

Una analogía: la rana en la olla y el medidor de temperatura

Hay una metáfora vieja sobre una rana en una olla de agua: si el agua se calienta de golpe, la rana salta y se salva; si se calienta muy despacio, grado a grado, la rana no percibe el cambio en ningún momento —cada instante se siente casi igual al anterior— y no salta hasta que es tarde. Sea o no cierto de las ranas, describe con precisión cómo un equipo se pierde el drift: ningún día el sistema está notablemente peor que el día anterior, así que ningún día suena una alarma en la cabeza de nadie, y para cuando la degradación es evidente, ya llevas semanas sirviendo calidad mala. El fallo repentino (el agua hirviendo de golpe) te hace saltar; el fallo gradual (el agua calentándose despacio) te cuece sin que lo notes.

¿Qué salva a la rana? No una mejor intuición —la intuición es exactamente lo que falla con los cambios graduales—. La salva un termómetro: un instrumento que mide la temperatura objetivamente, número a número, y una regla clara ("si pasa de 40 grados, salta"). El termómetro no se deja engañar por lo gradual del cambio, porque no compara cada instante con el anterior (donde el cambio es imperceptible); compara contra una referencia fija (los 40 grados, o la temperatura inicial). Grado 38, 39, 40 —y suena la alarma— aunque cada paso individual fuera de un solo grado.

Aquí está el punto: el drift te cuece como a la rana, y la única defensa es el termómetro —una medición continua de la calidad contra una referencia fija, con una alerta clara—. No puedes detectar el drift "prestando atención" ni "revisando de vez en cuando", porque la degradación es demasiado gradual para la intuición y demasiado lenta para una revisión ocasional. Necesitas correr el eval (tu termómetro de calidad, del módulo 3) de forma automática y periódica en producción, comparar cada medición contra la baseline (la calidad con la que salió el sistema, tu referencia fija), y disparar una alerta cuando la caída cruza un umbral. En Mercado, es la diferencia entre un dashboard que te avisa "la búsqueda cayó de 0.94 a 0.88, revisa" y un ticket de un cliente enojado tres semanas después preguntando por qué la búsqueda "ya no encuentra nada".

Ejemplo trabajado: el monitor que atrapa el drift

Vamos a simular siete semanas de operación de la búsqueda semántica. Cada semana corremos el eval en producción y obtenemos un score. El score baja poco a poco —de 0.94 a 0.75— porque está pasando algo real: llegan cada vez más queries de categorías de producto nuevas (Mercado agregó categorías que el modelo no manejaba bien), y esa fracción sube de 2% a 45%. Ese es el input drift que causa el output drift: los datos que entran cambian, y la calidad de la salida se degrada.

El monitor compara cada score contra dos reglas: una absoluta (alerta si el score cae por debajo de 0.85) y una relativa (alerta si cae 5 puntos o más respecto a la baseline de 0.94). Dispara la alerta la primera semana que cruza cualquiera de las dos. Contrastamos con el escenario "sin monitoreo", donde nadie nota nada hasta que los usuarios se quejan (supongamos, la semana 6).

# Leccion 7: DRIFT. El modelo o los datos cambian con el tiempo y la calidad
# se degrada SILENCIOSAMENTE (no hay excepcion, no hay caida: solo un score
# que baja). La unica defensa es MEDIR en el tiempo: correr el eval de M3
# semana a semana en produccion y disparar una alerta cuando cae.
# Drift / monitoring a fondo: Chip Huyen, AI Engineering.

# Score del eval-gate corrido cada semana en produccion (simulado). Baja poco
# a poco: llegan categorias de producto NUEVAS que el modelo maneja peor.
WEEKLY_EVAL = [0.94, 0.93, 0.92, 0.88, 0.83, 0.79, 0.75]
# Fraccion de queries en categorias NUEVAS (la causa del drift): sube.
NEW_CATEGORY_SHARE = [0.02, 0.04, 0.08, 0.17, 0.28, 0.37, 0.45]

BASELINE = 0.94        # el score cuando el sistema salio a produccion
ABS_THRESHOLD = 0.85   # alerta si el score cae por debajo de esto
REL_DROP = 0.05        # o si cae >= 5 puntos vs baseline

# Sin monitoreo, nadie nota nada hasta que los usuarios se quejan; supongamos
# que la queja llega en la semana 6 (cuando el score ya esta en 0.79).
COMPLAINT_WEEK = 6

first_alert = None
print(f"{'semana':<8}{'eval':<8}{'nuevas(%)':<12}{'caida vs base':<15}monitor")
print("-" * 56)
for w, (score, share) in enumerate(zip(WEEKLY_EVAL, NEW_CATEGORY_SHARE), start=1):
    drop = BASELINE - score
    alert = score < ABS_THRESHOLD or drop >= REL_DROP
    status = "ALERTA" if alert else "ok"
    if alert and first_alert is None:
        first_alert = w
    print(f"{w:<8}{score:<8.2f}{share * 100:<12.0f}{drop:<15.2f}{status}")

print("-" * 56)
print(f"Con monitoreo : la alerta se dispara en la semana {first_alert} "
      f"(caida de {BASELINE - WEEKLY_EVAL[first_alert - 1]:.2f} vs baseline).")
print(f"Sin monitoreo : nadie lo nota hasta la queja del usuario en la semana "
      f"{COMPLAINT_WEEK}.")
print(f"El monitoreo detecto el drift {COMPLAINT_WEEK - first_alert} semanas antes, "
      f"con el score aun en {WEEKLY_EVAL[first_alert - 1]:.2f} (no en "
      f"{WEEKLY_EVAL[COMPLAINT_WEEK - 1]:.2f}).")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

semana  eval    nuevas(%)   caida vs base  monitor
--------------------------------------------------------
1       0.94    2           0.00           ok
2       0.93    4           0.01           ok
3       0.92    8           0.02           ok
4       0.88    17          0.06           ALERTA
5       0.83    28          0.11           ALERTA
6       0.79    37          0.15           ALERTA
7       0.75    45          0.19           ALERTA
--------------------------------------------------------
Con monitoreo : la alerta se dispara en la semana 4 (caida de 0.06 vs baseline).
Sin monitoreo : nadie lo nota hasta la queja del usuario en la semana 6.
El monitoreo detecto el drift 2 semanas antes, con el score aun en 0.88 (no en 0.79).

Lee la tabla semana por semana, porque muestra el drift sucediendo.

Ningún salto brusco, solo un descenso. Mira la columna eval: 0.94, 0.93, 0.92, 0.88, 0.83, 0.79, 0.75. En ningún par de semanas consecutivas hay una caída dramática —la mayor es de 0.92 a 0.88, apenas 4 puntos—. Si compararas cada semana solo con la anterior, nunca verías nada alarmante; cada paso es "un poco peor, nada grave". Esa es la trampa de la rana: el cambio semana-a-semana es imperceptible. Pero mira la columna caida vs base, que compara contra la referencia fija (0.94): 0.00, 0.01, 0.02, 0.06, 0.11, 0.15, 0.19. Contra la baseline, la degradación es innegable —para la semana 7, el sistema perdió casi 20 puntos de calidad—. La lección del termómetro: compara contra una referencia fija, no contra el paso anterior, porque el drift solo es visible en la distancia acumulada.

La causa está a la vista: el input drift. La columna nuevas(%) cuenta por qué baja la calidad: la fracción de queries en categorías nuevas sube de 2% a 45%. El modelo no cambió (es el mismo), pero los datos que le llegan cambiaron —Mercado creció, agregó categorías, y las queries se movieron hacia terreno que el modelo maneja peor—. Esto es clave: el drift no siempre viene de que "el modelo se degrade"; a menudo viene de que el mundo cambia y el modelo se queda fijo. La búsqueda que era excelente para el catálogo de hace seis meses es mediocre para el catálogo de hoy, sin que nadie tocara el modelo. Por eso el monitoreo mira tanto la salida (el eval) como la entrada (la distribución de queries): un cambio en la entrada anticipa la caída de la salida.

El monitor dispara en la semana 4, la queja llega en la 6. Aquí está el valor medido. El monitor cruza el umbral relativo (caída de 0.06 ≥ 0.05) en la semana 4, con el score aún en 0.88 —todavía decente—. Sin monitoreo, el equipo se entera por una queja de usuario en la semana 6, cuando el score ya está en 0.79 —una degradación grave que ya afectó a muchos clientes—. El monitoreo detectó el problema 2 semanas antes, y —más importante— lo detectó mientras la calidad todavía era recuperable, no después de semanas de mala experiencia acumulada. Esas dos semanas son la ventana para reaccionar: investigar la causa (las categorías nuevas), ajustar el sistema (mejor prompt, RAG con el catálogo nuevo, reentrenar —trabajo de AI Engineering—) antes de que el daño sea grande.

La implicación arquitectónica: el drift es el único modo de fallo que no puedes atrapar en el momento del request; solo lo atrapas midiendo la tendencia. Contra una caída pones un fallback en el request; contra una alucinación pones una verificación en el request; pero contra el drift no hay nada que poner en el request individual —cada respuesta driftea un poquito, ninguna está "rota"—. La defensa vive en otra dimensión: en el tiempo, con un monitor que corre el eval periódicamente y compara contra la baseline. Sin ese monitor, el drift es invisible por diseño.

Profundización: monitorear la salud de un componente de IA

Dos tipos de drift, una misma defensa. Conviene distinguir de dónde viene la degradación, porque cambia la respuesta:

• Data drift (drift de datos): los datos de entrada cambian de distribución. En el ejemplo, las queries se mueven hacia categorías nuevas. El modelo no cambió; el mundo sí. Es el más común y el que el ejemplo simula.
• Model drift (drift de modelo): el modelo mismo cambia de comportamiento. Ojo con un caso muy real de los sistemas AI-native: dependes de una API de modelo de un proveedor, y el proveedor actualiza el modelo detrás de la misma versión o deprecia el que usabas. Tu prompt, afinado para el modelo de ayer, rinde distinto con el de hoy —sin que tú cambiaras una línea—. Este es un modo de fallo propio de depender de un modelo servido por terceros, y solo se detecta midiendo.

La defensa es la misma para los dos: medir la calidad en el tiempo con el eval. La causa difiere (y por eso también mides la distribución de entrada, para saber si es data drift), pero el detector es el mismo termómetro.

El eval del módulo 3, ahora en producción y continuo. Esta es la conexión que cierra el arco. En el módulo 3, el eval era una compuerta que corría cuando tú cambiabas algo (un prompt nuevo, un modelo nuevo) —una fitness function que bloqueaba un deploy que bajaba la calidad—. Aquí el mismo eval corre sin que tú cambies nada, de forma continua en producción, porque el drift degrada la calidad aunque tú no toques nada. Es el mismo instrumento con dos usos: en CI, atrapa la regresión que tú introduces; en producción continua, atrapa la regresión que el tiempo introduce. Un buen sistema AI-native corre su eval en los dos lugares.

Cómo se pone el umbral: absoluto y relativo. El monitor del ejemplo usa dos reglas, y vale entender por qué las dos:

• Umbral absoluto (score < 0.85): "por debajo de esta calidad, el sistema no es aceptable, sin importar de dónde venga". Es un piso duro.
• Umbral relativo / caída vs baseline (caída ≥ 0.05): "cayó demasiado respecto a como salió, aunque siga sobre el piso". Atrapa el drift temprano, mientras el score absoluto todavía es decente. En el ejemplo, la regla relativa disparó en la semana 4 (0.88, aún por encima del piso de 0.85); la absoluta no habría disparado hasta la semana 5 (0.83). La regla relativa te da la ventana extra.

Juntas: la relativa te avisa temprano de una tendencia, la absoluta marca el punto de "esto ya es inaceptable". El drift se caza mejor con la relativa, porque ataca el problema —la degradación gradual— en su propio terreno: la distancia acumulada contra la referencia.

Qué se monitorea, más allá del score. El eval es el corazón, pero un buen monitoreo de un componente de IA mira varias señales, y esto tiende el puente al módulo 7 (observabilidad para IA):

• Calidad: el score del eval (lo central de esta lección).
• Distribución de entrada: ¿están cambiando las queries? (el nuevas(%) del ejemplo) —un cambio aquí anticipa la caída de calidad—.
• Disponibilidad: tasa de fallos ruidosos, timeouts, 429 (de las lecciones 4-6).
• Proporción degradada: qué fracción de respuestas se sirvió por fallback (de la lección 5) —un pico sostenido es una señal de problema—.
• Costo y latencia: tokens y ms por request (del módulo 2) —un drift de costo también existe—.

El drift de calidad es el foco de esta lección, pero todas estas señales viven en el mismo dashboard, y el módulo 7 las integra en el lazo de datos completo.

Errores comunes

No monitorear la calidad en producción. Qué pasa: el equipo corre el eval una vez antes del lanzamiento, sale 0.94, lo declara bueno, y nunca más lo mide en producción; seis meses después la calidad es 0.75 y nadie lo sabe hasta que las quejas se acumulan. Por qué pasa: se piensa el eval como una prueba de lanzamiento (¿está listo?) y no como un monitor continuo (¿sigue sano?). El sistema pasó la prueba una vez y se asumió estable. Cómo detectarlo: no tienes un score de calidad reciente de tu componente de IA en producción; el último eval es del día del lanzamiento. Cómo corregirlo: corre el eval de forma periódica y automática en producción, guarda la serie, y alerta cuando cae. El ejemplo lo mide: el monitor atrapó el drift 2 semanas antes que las quejas.

Comparar solo con el paso anterior (y no ver el drift). Qué pasa: el equipo sí mira el score semanal, pero solo compara cada semana con la anterior —"bajó de 0.92 a 0.88, apenas 4 puntitos, normal"— y nunca contra la baseline, así que la degradación acumulada pasa desapercibida semana tras semana. Por qué pasa: la comparación paso-a-paso es la intuición natural, y es justo la que el drift derrota (cada paso es pequeño). Cómo detectarlo: tu alerta se basa en el cambio respecto a la medición anterior, no respecto a una referencia fija. Cómo corregirlo: compara siempre contra la baseline (la calidad de referencia), no contra el paso anterior —es el termómetro que mide contra los 40 grados, no contra el grado de hace un minuto—. El ejemplo usa la regla relativa vs baseline justo por esto.

Confundir un blip con drift (o viceversa). Qué pasa: dos errores simétricos. Uno: una caída puntual de un día (un blip por un pico de tráfico raro) dispara una alarma de drift y el equipo persigue un fantasma. Dos: se ignora una caída sostenida creyendo que "seguro es ruido" hasta que es tarde. Por qué pasa: no se distingue una variación puntual de una tendencia. Cómo detectarlo: tu monitor reacciona a un solo punto, o ignora una serie descendente sostenida. Cómo corregirlo: el drift es una tendencia sostenida, no un punto —usa una media móvil o exige que la caída persista varias mediciones antes de alertar de drift, y reserva la alerta de "un punto malo" para caídas grandes—. La estadística de distinguir señal de ruido en una serie es territorio de AI Engineering; para arquitectura, basta retener que el drift es una tendencia, y que el monitor debe mirar la serie, no el punto.

Ejercicios

Ejercicio 1 — Absoluto vs relativo. En el ejemplo, la alerta disparó en la semana 4 por la regla relativa (caída de 0.06 ≥ 0.05), no por la absoluta (0.88 aún está por encima del piso de 0.85). Explica qué habría pasado si el monitor solo tuviera la regla absoluta, en qué semana habría disparado, y por qué tener la regla relativa es valioso para cazar drift.

Ver solución

Si el monitor solo tuviera la regla absoluta (alerta si score < 0.85), habría disparado en la semana 5, que es cuando el score (0.83) cae por primera vez por debajo del piso de 0.85 —en la semana 4 el score es 0.88, todavía por encima, así que la regla absoluta no dispara—.

Tener la regla relativa es valioso para cazar drift porque detecta la tendencia antes de que el score cruce el piso absoluto. El drift es una degradación gradual; para cuando el score cae por debajo de un piso "inaceptable" (0.85), ya llevas semanas degradándote. La regla relativa mira la distancia acumulada desde la baseline (0.94), así que salta en cuanto la caída es significativa (0.06), aunque el valor absoluto siga siendo decente. Eso te da la ventana extra —en el ejemplo, una semana antes; en un drift más lento, podrían ser varias— para investigar y reaccionar mientras la calidad todavía es buena. La regla absoluta te dice "ya es inaceptable"; la relativa te dice "vas en mala dirección, atiéndelo antes de que sea inaceptable". Para el drift, la segunda es la que importa.

Ejercicio 2 — La causa detrás del score. El ejemplo muestra dos series: el eval (que baja) y nuevas(%) (que sube). Explica la relación causal entre ambas, por qué el modelo "no cambió" pero la calidad sí bajó, y qué acción de diseño tomarías al ver esta correlación (recuerda la frontera: la mecánica de la solución es AI Engineering, pero la decisión es arquitectónica).

Ver solución

La relación causal: la fracción de queries en categorías nuevas (nuevas(%)) sube de 2% a 45%, y el modelo maneja peor esas categorías nuevas (no estaban bien representadas cuando se diseñó/afinó el sistema), así que a medida que más queries caen en terreno que el modelo maneja mal, el eval promedio baja. La entrada driftea (data drift) y arrastra la calidad de la salida.

El modelo "no cambió" —es literalmente el mismo modelo con el mismo prompt— pero la calidad bajó porque el mundo cambió alrededor del modelo: Mercado creció, agregó categorías, y las queries de los usuarios se movieron hacia ese terreno nuevo. La calidad de un sistema de IA no es una propiedad solo del modelo; es una propiedad del modelo frente a la distribución de datos que realmente le llega, y esa distribución cambia con el tiempo aunque el modelo esté congelado. Un sistema excelente para el catálogo de enero puede ser mediocre para el de julio sin que nadie lo tocara.

La acción de diseño al ver esta correlación (la decisión arquitectónica): reconocer que el sistema necesita actualizarse para cubrir las categorías nuevas, y decidir cómo a nivel de diseño —¿mejor prompt con ejemplos de las categorías nuevas?, ¿RAG que le dé al modelo el contexto del catálogo actual?, ¿reentrenar/fine-tune con los datos nuevos?—. Esa elección entre prompt/RAG/fine-tune es exactamente la decisión arquitectónica del módulo 7. La mecánica de implementarla (cómo se construye el RAG, cómo se hace el fine-tune) es AI Engineering. Lo arquitectónico aquí es: (1) tener el monitor que detecta el drift, (2) mirar la señal de entrada para diagnosticar la causa, y (3) decidir la estrategia de actualización. El drift no se "arregla" una vez: se monitorea para saber cuándo el sistema necesita mantenimiento, lo cual es el lazo del módulo 7.

Ejercicio 3 — Drift del proveedor. Un caso de drift propio de depender de una API externa: tu proveedor de modelos actualiza silenciosamente el modelo detrás de la versión que usas, o deprecia la que usabas y te migra a otra. Explica cómo este "model drift" se manifestaría en tu monitor (¿gradual o de golpe?), por qué tu eval continuo lo atraparía aunque tú no cambiaras nada, y qué práctica de diseño reduce el riesgo de una migración forzada.

Ver solución

Cómo se manifestaría: a diferencia del data drift (gradual), un cambio de modelo del proveedor tiende a manifestarse de golpe —hay un día antes y un día después—: el eval está estable en, digamos, 0.92 durante semanas, y de un día para otro salta a 0.85 (o incluso sube, si el modelo nuevo es mejor para tu caso, pero cambia). Es un escalón, no una pendiente. Tu prompt, afinado para el comportamiento del modelo viejo, rinde distinto con el nuevo.

Por qué el eval continuo lo atraparía aunque tú no cambies nada: justamente porque el eval mide la calidad de la salida en producción, no "si tú desplegaste algo". El monitor no sabe ni le importa por qué cambió la calidad; detecta que el score cayó (o cambió) respecto a la baseline y alerta. Como el cambio fue del proveedor y no tuyo, no habría ningún deploy tuyo que lo delatara —sin el eval continuo, sería un fallo completamente invisible: nada en tu historial cambió—. El eval continuo es la única cosa que mira el resultado real y no solo tus propios cambios.

Práctica de diseño que reduce el riesgo: fijar (pin) la versión del modelo explícitamente en vez de usar un alias que apunta a "el último", y probar una versión nueva contra tu eval-set antes de migrar (la compuerta del módulo 3). Así, cuando el proveedor saca un modelo nuevo o va a deprecar el tuyo, tú controlas cuándo migras y validas la migración contra tu eval antes de que llegue a producción —conviertes una migración forzada y silenciosa en una migración planeada y verificada—. Combinado con el eval continuo (que atrapa lo que se te escape) y un aviso de deprecación del proveedor, reduces el riesgo de despertar un día con la calidad cambiada sin saber por qué. Es la misma disciplina de "modelos agnósticos, versión controlada" que la guía usa en todo su código.

Resumen y siguiente paso

En esta lección instalaste el último modo de fallo del módulo, el más traicionero: el drift —la degradación silenciosa y lenta— cuya única defensa es medir la calidad de forma continua contra una referencia fija. Lo viste con la rana en la olla (que el cambio gradual cuece sin que salte) y el termómetro que la salvaría, y lo mediste: el eval de la búsqueda bajó de 0.94 a 0.75 en siete semanas a medida que las queries de categorías nuevas subían de 2% a 45%, y el monitor disparó la alerta en la semana 4 —dos semanas antes de que los usuarios se quejaran, con el score aún en 0.88—. Retuviste las claves: comparar contra la baseline (no contra el paso anterior), usar umbral relativo y absoluto (el relativo caza el drift temprano), mirar la entrada para diagnosticar la causa, y correr el eval del módulo 3 ahora de forma continua en producción —el mismo termómetro, un uso nuevo—.

Antes de avanzar deberías poder: explicar por qué el drift es invisible para las defensas por-request (fallback, verificación) y solo se atrapa midiendo la tendencia; distinguir data drift de model drift; poner un umbral relativo contra baseline y explicar por qué caza el drift mejor que uno absoluto; y reconocer el drift de un proveedor que actualiza el modelo. La estadística fina de la detección de drift es AI Engineering; aquí la decisión de monitorear y cuándo actualizar es lo arquitectónico.

Con la lección 7 completaste el catálogo entero de modos de fallo de la IA y sus defensas. La lección 8 es el capstone: tomas la búsqueda semántica de Mercado y le construyes la cáscara de resiliencia completa —timeout + circuit breaker + fallback en cascada + degradación— sobre el modelo simulado, y mides su disponibilidad con y sin la cáscara (63.3% → 100%). Vas a integrar todo lo del módulo en una feature ejecutada, con su diagrama, su código, y un ADR que justifica por qué el fallo del modelo ya no tumba el sistema. La síntesis de todo lo que construiste.

Recursos

• Chip Huyen, AI Engineering (O'Reilly, 2024) y Designing Machine Learning Systems (O'Reilly, 2022). Los capítulos sobre monitoreo y observabilidad y sobre data distribution shifts son la referencia central de esta lección: tipos de drift (data, concept, model), cómo detectarlos, y por qué el monitoreo continuo de la calidad es parte del diseño de un sistema con ML/IA. En inglés.
• Anthropic, documentación de Claude — docs.anthropic.com. Consulta las páginas de versiones de modelo y deprecaciones para entender el "model drift del proveedor" —por qué fijar la versión y validar antes de migrar reduce el riesgo—, a nivel conceptual y sin fijar una versión concreta. En inglés.
• architecture-for-ai-native-systems-guide, Módulo 3 (el eval como fitness function) — el eval que aquí corre de forma continua en producción se diseñó allá como compuerta de CI; esta lección es su segundo uso. Y Módulo 7 (el lazo de datos y de retroalimentación), hacia donde apunta el monitoreo. En español.
• Martin Fowler y Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. Trata la evaluación y el monitoreo continuos de un componente de IA como patrones de operación. En inglés.