Módulo 3: El eval como fitness function

8. Proyecto: construye el eval gate de una feature de IA de Mercado

Siguiente →

Descripción

Esta es tu graduación del módulo. Durante siete lecciones aprendiste a probar un componente probabilístico sin un assert exacto: con un eval-set que produce un score, un umbral que lo vuelve compuerta, la comparación contra un baseline que atrapa regresiones, y el paso de CI que bloquea el deploy. 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 gate del agente de soporte, no sabría si aprendiste el método o memorizaste la tabla. Con una feature nueva —y, sobre todo, con un criterio de éxito distinto— la única forma de resolverlo es aplicar el método: definir el criterio, correr el eval-set, montar la compuerta, atrapar la regresión y ponerla en CI. Esa es, exactamente, la prueba de que el módulo funcionó.

Tu entregable son cuatro artefactos para la búsqueda semántica: (1) el eval-set con su criterio de éxito (dado) y por qué el criterio es el adecuado para esta feature; (2) el eval_gate ejecutado con detalle por caso, mostrando la versión A que pasa y la versión B que regresó y se bloquea; (3) el gate integrado en CI con su exit code; y (4) un brief de decisión (estilo ADR) que justifique por qué el eval es la compuerta de calidad arquitectónica y cómo se compone con las compuertas de latencia y costo del módulo 2. Ninguna parte requiere construir el LLM ni calcular embeddings: el componente se simula con un stub determinista. Es puro trabajo de arquitectura —definir la compuerta, ejecutarla, defender la decisión— que es justo lo que separa una feature de IA con calidad gobernada de una cuya calidad se degrada sin que nadie lo note. 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ó por qué el assert exacto no sirve; la 3 fabricó el score; la 4 lo volvió compuerta; la 5 la puso a atrapar regresiones; la 6 la metió en CI; la 7 abrió los tipos de criterio. Aquí produces los cuatro artefactos con tus manos, de principio a fin, sobre la búsqueda semántica —y con un criterio de éxito (relevante en el top-3) que no es el contains de las lecciones, para que apliques la lección 7—. 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 4 (guardrails y la frontera de confianza —validar la salida del modelo antes de confiar en ella—) y hacia el ecosistema de AI Engineering (donde se diseñan los evals que aquí solo usamos como compuerta).

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 ponerle una compuerta de calidad: que un cambio que empeore la relevancia de los resultados no pueda desplegarse. Móntala.

Es una feature hermana de la del agente de soporte, pero con un perfil de calidad distinto, y por eso su criterio de éxito es otro. En el agente, la respuesta era texto y el criterio era contains (¿la respuesta contiene la frase clave?). En la búsqueda, la salida es un ranking de productos, y lo que importa no es una frase sino la posición: ¿el producto relevante sale arriba, donde el cliente lo ve? Un cliente no revisa la página 3 de resultados; si lo relevante no está en los primeros, para él la búsqueda falló. Por eso el criterio natural es de top-k: la búsqueda acierta un caso si el producto relevante aparece en el top-3. Es un criterio distinto al de las lecciones —aplicas la lección 7— y es el adecuado para esta feature porque mide lo que el cliente experimenta: lo relevante, arriba.

Los hechos que te da el equipo (para que no tengas que inventarlos): el eval-set tiene 10 queries representativas, cada una con el producto relevante que debería salir arriba (te lo damos; elegir esas queries y su producto relevante es diseño de evals, de AI Engineering, no tu trabajo aquí). El criterio de éxito es relevante en el top-3. El umbral de calidad de la feature es 0.80 (el negocio decidió que al menos 8 de cada 10 búsquedas deben poner lo relevante arriba). Hay dos versiones a evaluar: la A, la candidata a producción, y la B, una que bajó a un modelo más barato para ahorrar (el cascade del módulo 2) y regresó.

Lo que tienes que entregar

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

Parte 1 — El eval-set y su criterio

Escribe (o toma como dado) el eval-set: las 10 queries con su producto relevante. Y justifica en una o dos frases por qué el criterio de top-3 es el adecuado para la búsqueda semántica —por qué la posición importa más que una frase, y por qué top-3 y no top-1 o top-10—. No inventes las queries; el punto es entender qué criterio mide la calidad de ESTA feature y por qué.

Parte 2 — El eval_gate ejecutado, con detalle por caso

Monta el gate y córrelo sobre las dos versiones. Para cada una, imprime: el detalle por caso (qué queries fallan, es decir, ponen lo relevante fuera del top-3), el score agregado, y el veredicto (PASS/deploy permitido o FAIL/deploy bloqueado). La versión A debe pasar; la versión B, regresada, debe bloquearse. Simula el componente con un stub determinista.

Parte 3 — El gate en CI

Convierte el gate en un paso de CI que devuelve un exit code (0 si pasa, 1 si falla) y muestra qué haría el pipeline con cada versión (MERGE o BLOCK). Es la lección 6 aplicada a tu feature.

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

Escribe un breve documento de decisión que responda: ¿qué compuerta pusiste y por qué? ¿Qué criterio y qué umbral, y de dónde salen? ¿Cómo se compone este eval gate con las compuertas de latencia y costo del módulo 2? ¿Por qué la no-determinación de la búsqueda queda gobernada por esta compuerta? 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

Parte 1 — El eval-set y su criterio

El eval-set son 10 queries, cada una con el producto relevante que debería aparecer arriba. El criterio es relevante en el top-3.

Por qué el criterio de top-3 es el adecuado: en una búsqueda, la salida no es una frase sino un ranking, y lo que el cliente experimenta es la posición —revisa los primeros resultados y rara vez baja—. Un contains (¿el producto está en la lista?) no serviría: el producto relevante podría estar en la posición 50 y "contarse" como presente, aunque el cliente nunca lo vea. El criterio tiene que medir posición, no mera presencia. Y top-3 (no top-1) porque exigir la posición 1 exacta sería demasiado estricto —una búsqueda buena pone lo relevante entre los primeros, no necesariamente primero—; top-10 sería demasiado flojo —lo relevante en la posición 9 es, para el cliente, casi invisible—. Top-3 captura "arriba, donde el cliente lo ve". (Cuál k exacto y cómo construir las queries es diseño de evals, AI Engineering; aquí el punto es elegir el tipo de criterio correcto —posición, no presencia— para lo que la feature promete.)

Parte 2 y 3 — El gate ejecutado y en CI

# Proyecto M3 — el eval gate de la busqueda semantica de Mercado. SIMULADO.
# Cero red, cero API, cero claves. Determinista.

# El catalogo de productos de Mercado (ids en ingles).
CATALOG = ["earbuds", "running_shoes", "phone_case", "smartwatch",
           "water_bottle", "backpack", "sunglasses", "headphones",
           "yoga_mat", "power_bank", "laptop", "coffee_mug"]

# EL EVAL-SET: cada caso = query + el producto relevante que deberia salir arriba.
# NOTA DE FRONTERA: elegir estas queries y su producto relevante es AI Engineering.
# Aqui el eval-set YA existe; lo usamos COMO COMPUERTA.
EVAL_SET = [
    {"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"},
    {"id": "s4",  "query": "reloj que mida pasos",               "relevant": "smartwatch"},
    {"id": "s5",  "query": "botella para el gimnasio",           "relevant": "water_bottle"},
    {"id": "s6",  "query": "mochila para la laptop",             "relevant": "backpack"},
    {"id": "s7",  "query": "lentes para el sol",                 "relevant": "sunglasses"},
    {"id": "s8",  "query": "cargar el celular sin enchufe",      "relevant": "power_bank"},
    {"id": "s9",  "query": "tapete para hacer yoga",             "relevant": "yoga_mat"},
    {"id": "s10", "query": "audifonos grandes para casa",        "relevant": "headphones"},
]

def make_search(competent_ids):
    # STUB del componente de busqueda: para los casos en competent_ids pone el
    # producto relevante ARRIBA (top-3); para el resto lo entierra (posicion 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]]     # relevante en el top-3
        return others[:4] + [relevant]                  # relevante en la posicion 5
    return search

def criterion_top_k(ranking, relevant, k=3):
    # El criterio de exito: el producto relevante aparece en el top-k del ranking.
    return relevant in ranking[:k]

def run_eval(search, k=3):
    passed, detail = 0, []
    for case in EVAL_SET:
        ranking = search(case["query"], case["id"], case["relevant"])
        ok = criterion_top_k(ranking, case["relevant"], k)
        passed += ok
        detail.append((case["id"], ok))
    total = len(EVAL_SET)
    return passed, total, passed / total, detail

# Version A (candidata) y B (modelo mas barato que regreso).
ALL_IDS = {c["id"] for c in EVAL_SET}
A_IDS = ALL_IDS - {"s9"}                          # 9/10 = 0.90
B_IDS = {"s1", "s2", "s3", "s4", "s6", "s8"}      # 6/10 = 0.60

THRESHOLD = 0.80

def full_gate(name, ids):
    passed, total, score, detail = run_eval(make_search(ids))
    ok = score >= THRESHOLD
    fails = [cid for cid, o in detail if not o]
    print(f"--- {name} ---")
    print(f"  score = {passed}/{total} = {score:.2f}   umbral = {THRESHOLD:.2f}")
    print(f"  queries que fallan (relevante fuera del top-3): {fails if fails else 'ninguna'}")
    print(f"  GATE: {'PASS -> deploy permitido (verde)' if ok else 'FAIL -> deploy bloqueado (rojo)'}")
    return 0 if ok else 1

print("=== EVAL GATE — busqueda semantica de Mercado (criterio: relevante en top-3) ===\n")
code_a = full_gate("version A (candidata a produccion)", A_IDS)
print()
code_b = full_gate("version B (modelo mas barato, regresion)", B_IDS)

# El gate en CI: el exit code decide MERGE o BLOCK.
print(f"\n=== En CI ===")
print(f"PR que despliega A: exit code = {code_a}  ->  {'MERGE' if code_a==0 else 'BLOCK'}")
print(f"PR que despliega B: exit code = {code_b}  ->  {'MERGE' if code_b==0 else 'BLOCK'}")

Qué esperar. Al correrlo:

=== EVAL GATE — busqueda semantica de Mercado (criterio: relevante en top-3) ===

--- version A (candidata a produccion) ---
  score = 9/10 = 0.90   umbral = 0.80
  queries que fallan (relevante fuera del top-3): ['s9']
  GATE: PASS -> deploy permitido (verde)

--- version B (modelo mas barato, regresion) ---
  score = 6/10 = 0.60   umbral = 0.80
  queries que fallan (relevante fuera del top-3): ['s5', 's7', 's9', 's10']
  GATE: FAIL -> deploy bloqueado (rojo)

=== En CI ===
PR que despliega A: exit code = 0  ->  MERGE
PR que despliega B: exit code = 1  ->  BLOCK

Lee el resultado por versión. La versión A pone el producto relevante en el top-3 para 9 de las 10 queries —solo falla s9, el tapete de yoga—: score 0.90, arriba del umbral de 0.80, así que el gate la deja pasar (verde) y en CI el PR se mergea (exit 0). La versión B —la que bajó a un modelo más barato para ahorrar— solo acierta 6 de 10: entierra el producto relevante fuera del top-3 en cuatro queries (s5, s7, s9, s10). Su score cae a 0.60, bajo el umbral, y el gate la bloquea (rojo); en CI el PR se detiene (exit 1). La regresión que el ahorro de costo introdujo —búsquedas que ahora esconden lo relevante— queda atrapada antes del deploy, sin que un humano tenga que revisar rankings a mano. Y fíjate en el detalle por caso: te dice exactamente qué queries se degradaron, así que si quisieras arreglar la versión B sabrías por dónde empezar. La compuerta decide; el detalle diagnostica.

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

Decisión: poner un eval gate como compuerta de calidad de la búsqueda semántica, integrado en CI, que bloquea el deploy si el score cae bajo 0.80.

Contexto. La búsqueda semántica es un componente probabilístico: no da el mismo ranking siempre, y su calidad —¿lo relevante sale arriba?— no se puede verificar con un assert exacto. Sin una compuerta, un cambio de prompt o de modelo puede degradar la relevancia sin que nadie lo note hasta que los clientes se quejan.

Criterio y umbral. El criterio es relevante en el top-3, porque lo que el cliente experimenta es la posición del producto, no su mera presencia en la lista. El umbral es 0.80: el negocio decidió que al menos 8 de cada 10 búsquedas deben poner lo relevante arriba. El umbral no es técnico —viene de cuánta imperfección tolera la experiencia de búsqueda—.

Composición con las otras compuertas. Este eval gate es la tercera de las tres compuertas que la feature debe pasar, junto con el latency budget (≤ 800 ms) y el cost budget (≤ $5,000/mes) del módulo 2. Las tres son ortogonales —rápida, barata y buena— y las tres deben pasar. En particular, este gate protege contra el efecto secundario del cascade: bajar a un modelo más barato ahorra dinero (pasa el cost budget) pero puede degradar la relevancia (falla el eval gate), como la versión B. El eval gate es lo que hace segura la optimización de costo: solo se abarata si la calidad se mantiene.

Por qué la no-determinación queda gobernada. La búsqueda seguirá siendo no determinista —dará rankings que varían—, pero ya no puede empeorar sin control: cualquier cambio que baje la relevancia bajo el umbral es imposible de desplegar, porque el pipeline lo bloquea. La no-determinación no se elimina; se acota con una compuerta que garantiza un piso de calidad. Ese es el rol arquitectónico del eval: la fitness function que gobierna que la calidad probabilística no se degrade.

Consecuencias. Todo cambio del componente (prompt, modelo, datos) debe pasar el eval en CI antes del deploy. El eval-set debe mantenerse representativo con el tiempo (diseño de evals, AI Engineering). El costo de correr el eval es bajo mientras el criterio sea top-k determinista; si en el futuro se usa un LLM-as-judge para medir relevancia matizada, habrá que contar su costo y su ruido (lección 7).

Ese brief es el artefacto que justifica la decisión ante el equipo: qué compuerta, con qué criterio y umbral, cómo se compone con las demás, y por qué contiene la no-determinación. Con las cuatro partes —criterio, gate ejecutado, CI y brief— tienes la compuerta de calidad de la búsqueda semántica montada de punta a punta.

Errores comunes

Usar contains (presencia) donde va top-k (posición) (de criterio inadecuado). Qué pasa: el equipo evalúa la búsqueda con "¿el producto relevante está en la lista de resultados?" y el score sale altísimo —porque el producto casi siempre está en algún lugar de la lista, aunque sea la posición 40—. El gate aprueba una búsqueda que en la práctica esconde lo relevante. Por qué pasa: contains es el criterio que venías usando en el agente, y se aplica por costumbre. Cómo detectarlo: si tu criterio de búsqueda no mira la posición, no mide lo que el cliente experimenta. Cómo corregirlo: para un ranking, el criterio tiene que ser de posición (top-k), no de presencia —aplica la lección 7: el criterio más simple que capture lo que importa, y aquí lo que importa es que salga arriba—.

Aprobar el cambio de modelo mirando solo el costo (de alcance, cruce con módulo 2). Qué pasa: la versión B bajó de modelo y ahorró dinero, y el equipo la aprueba mirando solo el cost budget —"ahorra, y las búsquedas se ven bien"— sin correr el eval. La regresión de relevancia (0.60) llega a producción. Por qué pasa: el ahorro es visible e inmediato; la caída de relevancia es invisible sin eval. Cómo detectarlo: si aprobaste un cambio de modelo sin el score del eval, te falta la compuerta de calidad. Cómo corregirlo: toda optimización de costo pasa también por el eval gate; las tres compuertas juntas, no por separado.

Montar el gate pero dejarlo como aviso en CI (de configuración). Qué pasa: el equipo pone el eval en CI pero configurado para avisar sin bloquear, así que la versión B se despliega igual con un warning que nadie lee. Por qué pasa: el modo aviso evita fricción. Cómo detectarlo: si tu gate nunca ha detenido un deploy, es decorativo. Cómo corregirlo: haz que el exit code bloquee el pipeline (lección 6); un gate que no puede decir "no" no es una compuerta.

Ejercicios

Ejercicio 1 — Cambia el criterio de top-3 a top-1. El equipo propone endurecer el criterio: en vez de "relevante en el top-3", exigir "relevante en la posición 1" (top-1). Con el stub de la solución de referencia, la versión A pone el relevante en la posición 1 para sus casos competentes ([relevant, ...]) y en la posición 5 para los demás. ¿Cómo cambia el score de la versión A con top-1 frente a top-3? Y en general, ¿qué efecto tiene endurecer el criterio sobre los scores y sobre qué versiones pasan el gate?

Ver solución

Con este stub en particular, el score de la versión A no cambia: en los casos competentes el relevante está en la posición 1 (ranking[0]), que está tanto en el top-1 como en el top-3; en los no competentes está en la posición 5, fuera de ambos. Así que A da 0.90 con top-1 y con top-3 —el stub es "todo o nada" en la posición—.

Pero la pregunta general es la que importa: endurecer el criterio solo puede bajar o mantener el score, nunca subirlo. Top-1 es un subconjunto de top-3 (todo lo que pasa top-1 pasa top-3, pero no al revés), así que con un componente realista —donde el relevante a veces cae en la posición 2 o 3— el score con top-1 sería menor que con top-3, porque los casos "relevante en posición 2" ahora fallan. Consecuencia para el gate: un criterio más estricto hace que más versiones fallen el umbral. Esto es una decisión de diseño con trade-off: top-1 exige una búsqueda casi perfecta (lo relevante primero), lo que puede ser demasiado estricto y bloquear versiones que el cliente consideraría buenas (lo relevante en el top-3 le sirve). La lección: el criterio y el umbral se calibran juntos, y endurecer el criterio sin bajar el umbral puede convertir un gate razonable en uno inalcanzable. (Cuál k es el correcto para esta feature es diseño de evals, AI Engineering.)

Ejercicio 2 — Las tres compuertas de la búsqueda. La versión B (el modelo más barato) da: latencia 180 ms (budget 800 ms), costo $2,400/mes (budget $5,000/mes), score de calidad 0.60 (umbral 0.80). Un compañero argumenta: "es rapidísima y baratísima, ahorramos mucho, despleguémosla". Responde con el análisis de las tres compuertas y explica por qué el ahorro no la salva.

Ver solución

Las tres compuertas de la versión B:

  • Latency budget: 180 ms ≤ 800 ms → PASS. Es muy rápida (más que la A, porque el modelo barato responde más rápido).
  • Cost budget: $2,400/mes ≤ $5,000/mes → PASS. Es barata (ahorra frente al presupuesto).
  • Eval gate: 0.60 < 0.80 → FAIL. Su relevancia regresó: entierra lo relevante fuera del top-3 en cuatro de diez búsquedas.

Veredicto global: no se despliega. Basta con que una compuerta falle, y la de calidad falla. El argumento del compañero mira solo dos de las tres compuertas —las operacionales (rápida, barata)— e ignora la de calidad. Y aquí está el punto: la versión B es rápida y barata precisamente porque es peor —usa un modelo más débil que ahorra recursos a costa de la relevancia—. Desplegarla sería servir una búsqueda veloz, económica y mala: el cliente busca "tenis para correr" y no ve los tenis en los primeros resultados. El ahorro es real en dólares, pero compra una degradación de la experiencia que el negocio no aceptó (fijó el umbral en 0.80). El eval gate es exactamente la compuerta que impide que "ahorramos mucho" se convierta en "degradamos la búsqueda sin darnos cuenta". Si el equipo quiere el ahorro, la salida correcta es el cascade (módulo 2): usar el modelo barato solo en las queries fáciles donde no daña la relevancia, y el fuerte en las difíciles —y verificar con el eval que esa mezcla mantiene el score sobre el umbral—.

Ejercicio 3 — El criterio para otra feature. Mercado quiere ponerle una compuerta de calidad al generador "describe tu producto" (le das el nombre y las specs de un producto, y el LLM escribe una descripción de venta). ¿Qué tipo de criterio de éxito usarías para su eval-set y por qué? Considera qué hace "buena" a una descripción de producto y qué criterio de la lección 7 lo captura.

Ver solución

Este es el caso más difícil de los tres, y la respuesta honesta empieza por reconocerlo. Una "buena" descripción de producto es genuinamente matizada: debe ser fluida, persuasiva, mencionar las specs correctas, tener el tono de marca, y no inventar características que el producto no tiene (no alucinar). Ninguna de esas propiedades se captura con un criterio mecánico simple.

Un enfoque por capas, aplicando la regla de "el criterio más simple que sirva" (lección 7):

  • Criterios baratos y deterministas para lo verificable: un contains o un criterio estructural para las propiedades objetivas —que la descripción mencione las specs clave dadas (el material, el tamaño), que no supere cierta longitud, que no incluya specs que no estaban en la entrada (una defensa barata contra alucinación de datos)—. Estos son rápidos, sin costo de modelo, y atrapan errores objetivos.
  • Un LLM-as-judge para lo matizado: la fluidez, la persuasión y el tono de marca no se miden con reglas de string; aquí sí se justifica un juez LLM que califique esas dimensiones. Pero —lección 7— con consciencia de su costo: el juez es otro ai_component (lento, caro, no determinista), así que se reserva para lo que de verdad lo necesita, y su rúbrica hay que calibrarla contra el juicio humano (eso es AI Engineering).

La moraleja: no hay un único criterio; se combinan —criterios baratos para lo objetivo, un juez para lo subjetivo—, siempre usando el más simple que capture cada propiedad. Y una nota importante: verificar que la descripción no alucine specs es en parte un problema de eval (¿el score baja cuando inventa?) y en parte un problema de guardrail —validar la salida antes de publicarla—, que es el módulo 4. La compuerta de calidad (eval) y la de confianza (guardrail) se complementan.

Resumen del módulo: las ocho lecciones

Cerraste el módulo del eval como fitness function. Este es el arco completo que recorriste:

LecciónLo que te llevas
1La tesis: un componente probabilístico se prueba con un eval-set que produce un score, y ese score contra un umbral es la compuerta de calidad —el equivalente probabilístico de la fitness function—. Las dos analogías (examen estandarizado, control de calidad de fábrica).
2Por qué el assert exacto se rompe contra un componente probabilístico, y el cambio de forma que lo salva: de igualdad a propiedad, de booleano por caso a score agregado.
3La anatomía del eval-set: casos + criterio + agregación → score. Los dos niveles de su salida (detalle por caso que diagnostica, score que decide). Por qué es reproducible y "a ojo" no.
4El corazón: el score contra un umbral es una compuerta (verde/rojo, deploy permitido/bloqueado). Es una fitness function especializada a la calidad probabilística. Un umbral flojo = compuerta inútil.
5La compuerta atrapa regresiones: el score de un cambio contra un baseline —un prompt nuevo mejora, un modelo barato regresa—. El eval verifica que abaratar (módulo 2) no rompió la calidad.
6El eval en CI: un exit code que bloquea el deploy si el score cae, como un test rojo. La compuerta deja de depender de la disciplina humana y se vuelve inevitable.
7Los tipos de criterio: exact-match, contains, LLM-as-judge, umbral estadístico. La advertencia central: el juez es otro componente de IA que recursa todas las propiedades de la guía.
8El proyecto: la compuerta de calidad de la búsqueda semántica montada de punta a punta —criterio de top-3, gate ejecutado, CI, y brief de decisión—.

La capacidad que ganaste: tomar un componente de IA y ponerle una compuerta de calidad que gobierne su deploy —definir el criterio, correr el eval-set, comparar contra un umbral y un baseline, y meterlo en CI para que bloquee las regresiones— sin caer en el assert exacto ni en el "probar a ojo". Y con la frontera clara: esto es el eval como compuerta arquitectónica; diseñar el eval —qué casos, qué criterio, cómo calibrar un juez— es AI Engineering.

Hacia dónde seguir

El módulo 4: guardrails y la frontera de confianza. El eval verifica que la calidad del componente sea buena en promedio, sobre un eval-set. Pero hay una pregunta distinta que el eval no cubre: en una petición individual de producción, ¿puedes confiar en la salida del modelo antes de usarla? La respuesta es no —la salida de un LLM es no confiable hasta validarla—, y el módulo 4 te enseña a poner guardrails: validar la entrada y la salida del modelo en la frontera (un schema, una regla), y tratar el prompt injection como un problema de frontera de confianza —el modelo que lee datos del usuario cruza una frontera de seguridad—. Si el eval es la compuerta de calidad agregada (¿es bueno en general?), el guardrail es la compuerta de confianza por petición (¿puedo usar esta salida?). Las dos son necesarias.

El ecosistema AI Engineering: diseñar los evals a fondo. En todo este módulo el eval-set vino dado: te dimos las queries, el criterio y el umbral. Construir buenos evals es un oficio profundo —elegir casos representativos sin sesgo, medir relevancia con métricas serias, calibrar un LLM-as-judge contra el juicio humano, versionar el dataset—, y es del ecosistema AI Engineering. Si vas a poner features de IA en producción de verdad, ese es el siguiente cuerpo de conocimiento: este módulo te enseñó a usar el eval como compuerta; AI Engineering te enseña a diseñarlo bien.

architecture-decisions-and-tradeoffs-guide: la fitness function como concepto general. Todo este módulo especializó una idea que allá se enseña en general: la fitness function como prueba automatizada que gobierna una propiedad arquitectónica. Si quieres el marco completo —fitness functions para latencia, acoplamiento, dependencias, tamaño de módulos, y no solo para la calidad de la IA—, esa guía es la fuente. El eval es una fitness function; ese es el concepto raíz.

Con esto tienes la tercera compuerta de una feature de IA: latencia (módulo 2), costo (módulo 2) y calidad (este módulo). Una feature de IA lista para producción pasa las tres, y ahora sabes montar la de calidad con tus manos.

Recursos

← Anterior7. Tipos de criterio de evalSiguiente →Presentación del módulo: guardrails y la frontera de confianza