Evaluación (Evaluation)

Por qué "funciona en mis tres ejemplos" no es una respuesta

Todo el curso ha ido dejando cabos que terminaban en la misma frase: "esto se mide en el Módulo 9". La razón de aplazarlo hasta aquí es que la evaluación solo tiene sentido cuando ya hay algo complejo que evaluar, y ahora lo hay: un equipo de agentes que recupera documentos, consulta datos, envía correos y enruta entre especialistas. La pregunta que este módulo responde es engañosamente simple: cómo saber si eso funciona.

La respuesta ingenua —probarlo con unos cuantos ejemplos y ver que responde bien— falla por dos motivos que conviene entender antes de cualquier técnica. El primero es el no determinismo del Módulo 1: el mismo prompt, ejecutado cinco veces, produce cinco respuestas ligeramente distintas, todas quizá correctas. No puedes escribir la prueba clásica del software —aseverar que la salida es exactamente esta cadena— porque no hay una cadena exacta que esperar. El segundo es la ausencia de una única respuesta correcta: a "resume la política de gastos" hay muchas respuestas buenas y muchas malas, y ninguna es la respuesta. Probar tres ejemplos a mano te dice que el sistema no está roto del todo; no te dice si acierta el 95 por ciento de las veces o el 60, ni si el cambio que hiciste ayer lo mejoró o lo empeoró.

La analogía separa dos oficios distintos. Corregir un examen de aritmética es binario: la respuesta es 42 o no lo es, y una máquina lo comprueba. Corregir un examen de redacción es graduado: hay una rúbrica, criterios de claridad y precisión, y dos correctores razonables pueden discrepar en un punto. Evaluar un agente se parece mucho más a lo segundo. Por eso la evaluación deja de ser una aserción de igualdad y pasa a ser un proceso: un conjunto de casos representativo, una batería de métricas que puntúan propiedades en lugar de exigir cadenas exactas, y una agregación estadística sobre muchos casos que convierte impresiones en números. El costo de no hacerlo no es abstracto: es enviar a producción un prompt peor que el anterior sin enterarte, porque tus tres ejemplos siguieron pasando mientras el sistema empeoraba en los cientos que no miraste.

Pregunta de comprensión: ¿por qué no puedes evaluar un agente con pruebas al estilo del software tradicional, que aseveran que la salida es igual a un valor esperado?

Porque la salida de un modelo no cumple las dos condiciones que hacen funcionar a esas pruebas: no es determinista y no tiene un único valor correcto. La prueba tradicional de igualdad exacta asume que la misma entrada produce siempre la misma salida y que existe una respuesta canónica contra la que comparar; ambas cosas son falsas aquí. El mismo prompt genera formulaciones distintas en cada ejecución por el muestreo del Módulo 1, así que una aserción de igualdad fallaría incluso con respuestas perfectamente correctas solo porque cambiaron las palabras. Y para una pregunta abierta hay muchas respuestas buenas, de modo que no existe la cadena única que la aserción necesitaría. La consecuencia es un cambio de mentalidad: en lugar de preguntar "¿es exactamente esta cadena?", preguntas "¿satisface estas propiedades?" —está anclada en la fuente, contesta lo que se preguntó, tiene el formato pedido— y las mides de forma graduada. Y como una sola ejecución es una muestra de un proceso aleatorio, la evaluación se vuelve estadística: se agrega sobre muchos casos para que el número signifique algo, en vez de leer un único acierto o fallo como si fuera concluyente.

El conjunto de evaluación

Antes de medir hace falta contra qué medir. El conjunto de evaluación —el conjunto dorado— es una colección de casos de prueba, cada uno con su entrada y con lo que se considera una buena respuesta o el comportamiento esperado. Es a la vez la clave de respuestas de un examen y la batería de pruebas de un producto: define qué significa "bien" de forma explícita, para que la máquina pueda comprobarlo.

Cada caso lleva la información que sus métricas necesitarán. Un caso de documentos incluye la pregunta, una respuesta de referencia y la fuente de SharePoint que debería citar. Un caso de datos incluye la consulta y el resultado numérico conocido. Un caso de acción incluye la petición, la herramienta que debería invocarse y los argumentos esperados. Y —esto es lo que la mayoría olvida— el conjunto incluye casos difíciles a propósito: preguntas cuya respuesta no está en el corpus, para verificar que el sistema admite el vacío en lugar de inventar; peticiones ambiguas; y casos adversariales que reproducen los ataques que los módulos anteriores enseñaron a defender.

De dónde salen los buenos casos importa tanto como cuántos hay. Los mejores no se inventan en una pizarra: vienen de los registros de uso real, donde los fallos verdaderos de usuarios verdaderos revelan los casos que un diseñador nunca imaginaría. Sobre cuántos, la aritmética es de compromiso. Con 10 casos, una diferencia de un acierto entre dos versiones es ruido; con 500, el conjunto es fiable pero caro de mantener y de ejecutar. Un punto de partida razonable son 40 o 50 casos que cubran los dominios y los bordes, que se hace crecer conforme la producción revela huecos. El conjunto dorado no es un artefacto que se escribe una vez; es un ser vivo que crece con cada fallo que descubres.

Pregunta de comprensión: ¿por qué el conjunto debe incluir casos adversariales y de borde, y no solo el camino feliz, y de dónde salen los casos más valiosos?

Porque un conjunto compuesto solo de casos fáciles produce una puntuación alta y falsa: pasa mientras el sistema falla justo en los casos que importan. Los fallos caros de un agente empresarial no ocurren en "resume la política de vacaciones", que casi siempre sale bien, sino en los bordes —una pregunta sin respuesta en el corpus que el modelo rellena inventando, una consulta ambigua que enruta al especialista equivocado— y en los ataques —una inyección indirecta en un documento, un intento de acceder a datos fuera de permiso—. Si esos casos no están en el conjunto, la evaluación es ciega precisamente donde el riesgo es mayor, y una nota de 95 sobre 100 puede convivir con una fuga de datos que nunca mediste. Por eso el conjunto debe cubrir el camino feliz para detectar regresiones generales, pero también los bordes para medir la robustez y los adversariales para verificar las defensas. Y los casos más valiosos no se inventan: salen de los registros de producción, donde los fallos reales muestran las grietas que la imaginación de un diseñador no anticipa. Cada incidente en producción es un caso de prueba nuevo que impide que ese fallo vuelva a pasar sin ser detectado.

Las familias de métricas

Con casos y referencias, falta decidir cómo se puntúa cada respuesta. Hay cuatro familias, y elegir la correcta para cada propiedad es la mitad del oficio.

Las métricas deterministas comprueban propiedades objetivas con código: si la salida es un JSON válido contra un esquema, si contiene una cadena requerida, si la herramienta invocada es la esperada, si el sistema se negó a una petición fuera de alcance. Son baratas, instantáneas y perfectamente fiables donde aplican, porque no juzgan calidad sino hechos verificables. Cuando una propiedad se puede comprobar así, se comprueba así.

Las métricas por similitud comparan la respuesta con una referencia midiendo su cercanía. Las clásicas de resumen y traducción —BLEU, ROUGE— cuentan solapamiento de palabras y sirven de poco con texto abierto, porque una respuesta correcta con otras palabras puntúa bajo. Más útil es la similitud por embeddings del Módulo 1: el coseno entre la respuesta y la referencia captura parecido de significado aunque cambien las palabras. Sirve como señal, no como veredicto.

La tercera familia es el LLM como juez, presentado en el Módulo 2 y protagonista de este. Un segundo modelo puntúa la respuesta contra una rúbrica, y es el único enfoque que escala para propiedades abiertas —anclaje, pertinencia, coherencia— que ninguna comprobación determinista captura. La cuarta es la evaluación humana: el patrón oro, caro y lento, cuyo papel principal no es puntuarlo todo sino calibrar al juez, como veremos.

Familia	Mide	Costo	Cuándo usarla
Determinista	Hechos verificables	Mínimo	Formato, herramienta correcta, negativa, JSON
Similitud por embeddings	Parecido de significado	Bajo	Señal de cercanía a una referencia
LLM como juez	Calidad abierta	Medio	Anclaje, pertinencia, coherencia sin regla fija
Humana	Todo, con criterio	Alto	Calibrar al juez, casos críticos

La regla que ordena la tabla es usar la métrica más barata que capture la propiedad. Reservar el juez para lo que solo un juicio abierto puede medir, y no gastar una llamada al modelo en comprobar si un JSON es válido, que un try de parseo resuelve gratis y sin error.

Pregunta de comprensión: si el LLM como juez es tan flexible, ¿por qué no usarlo para todo en lugar de mezclar familias de métricas?

Por tres razones que se refuerzan. La primera es costo y velocidad: el juez es una llamada al modelo por cada caso y por cada propiedad, con su latencia y su factura, mientras que una comprobación determinista —¿es JSON válido?, ¿se llamó a la herramienta X?, ¿el sistema se negó?— se resuelve en microsegundos y gratis. Gastar el juez en lo que el código verifica sin error es tirar dinero. La segunda es fiabilidad: donde existe una propiedad objetiva, la comprobación determinista es perfecta —un JSON es válido o no lo es—, mientras que el juez, al ser un modelo, tiene una tasa de error propia; introducir incertidumbre donde había certeza empeora la medición. La tercera es que el juez mismo necesita ser validado antes de confiar en él, así que no es una vara mágica sino un instrumento con su propio margen que hay que calibrar. La consecuencia práctica es una estrategia por capas idéntica a la de seguridad del curso: la comprobación más barata y fiable primero, y el juez solo para la calidad abierta que nada más puede medir. Mezclar familias no es desorden; es asignar a cada propiedad el instrumento adecuado.

Ejercicio 1: asignar la métrica

Para cada propiedad que quieres medir, indica la familia de métrica más barata que la captura bien y justifica en media línea.

La salida del agente es un JSON que respeta el esquema de la herramienta.
La respuesta está respaldada por los documentos recuperados y no contiene afirmaciones inventadas.
Ante una petición fuera de alcance, el especialista se negó en lugar de improvisar.
La respuesta transmite el mismo contenido que la respuesta de referencia aunque con otras palabras.
El supervisor enrutó la pregunta al especialista correcto.

Criterio de éxito: asignas determinista a las propiedades 1, 3 y 5, similitud por embeddings a la 4 y LLM como juez a la 2, y en cada justificación nombras por qué la familia elegida basta y una más cara sería desperdicio.

LLM como juez, a fondo

El juez basado en modelo merece su propia sección porque es el instrumento más potente y el más fácil de usar mal. Su mecánica es directa: das a un modelo la entrada, la respuesta a evaluar, opcionalmente una referencia, y una rúbrica que describe la escala de puntuación; el modelo emite una nota y, si lo pides, una justificación. Hay dos formatos. El puntual puntúa una respuesta en una escala —anclaje de 1 a 5, por ejemplo—. El comparativo enfrenta dos respuestas y dice cuál es mejor, útil para comparar dos versiones del sistema.

La rúbrica es al juez lo que la descripción de una herramienta es a un agente: un prompt del que depende todo. Una rúbrica vaga —"puntúa la calidad de 1 a 10"— produce notas inconsistentes; una rúbrica que define cada nivel de la escala con criterios concretos produce notas reproducibles. Y conviene pedir al juez que razone antes de puntuar, no después: igual que un corrector que primero anota sus observaciones y luego pone la nota es más consistente que uno que suelta un número de entrada.

RUBRICA_ANCLAJE = """Evalúa si la RESPUESTA está respaldada por el CONTEXTO.
Razona primero, luego puntúa. Devuelve JSON: {"razonamiento": str, "nota": int}
Escala:
1 = afirmaciones no respaldadas o contradichas por el contexto.
3 = mayormente respaldada, con algún detalle no verificable.
5 = toda afirmación se apoya explícitamente en el contexto.
CONTEXTO:\n{contexto}\n\nRESPUESTA:\n{respuesta}"""

El juez, por ser un modelo, arrastra sesgos que hay que conocer y mitigar. El sesgo de posición hace que, en el formato comparativo, tienda a preferir la primera respuesta que ve; se mitiga aleatorizando el orden y promediando. El sesgo de verbosidad lo lleva a premiar respuestas largas por parecer completas; se mitiga con una rúbrica que valore la concisión. El sesgo de autopreferencia hace que un modelo puntúe mejor las respuestas generadas por su propia familia. Y como el juez no es determinista, conviene ejecutarlo a temperatura cero para maximizar la reproducibilidad, sabiendo que aun así no será perfectamente estable.

Lo anterior desemboca en la regla no negociable: un juez solo es fiable si concuerda con el juicio humano. Antes de confiar en sus notas, se toma una muestra del conjunto, se etiqueta a mano y se mide cuánto coincide el juez con las etiquetas. Si concuerda el 85 por ciento de las veces, sus notas son una señal útil; si concuerda el 60, sus notas son ruido con apariencia de número, y usarlas es peor que no medir, porque dan una falsa confianza. La calibración no es un lujo: es lo que separa una métrica de un adorno.

Pregunta de comprensión: ¿por qué hay que calibrar al juez contra etiquetas humanas antes de confiar en sus notas, y qué significa una concordancia baja?

Porque el juez es él mismo un modelo falible, no determinista y con sesgos —de posición, de verbosidad, de autopreferencia—, de modo que sus notas no son medidas objetivas sino opiniones de otro sistema que también puede equivocarse. Un número tiene un aura de rigor que puede engañar: "anclaje 4,2 de 5" suena preciso aunque el juez esté puntuando mal de forma sistemática. La única manera de saber si esas notas significan algo es compararlas con el criterio humano en una muestra etiquetada a mano y medir la concordancia. Una concordancia alta —pongamos que el juez coincide con los humanos en el 85 por ciento de los casos— dice que sus notas rastrean la calidad real y se pueden usar para evaluar el resto del conjunto a escala, sin etiquetar todo a mano. Una concordancia baja —cerca del 60, poco mejor que el azar en una escala de pocos niveles— dice que las notas son ruido disfrazado de dato, y confiar en ellas es peor que no tener métrica, porque tomarás decisiones —enviar un prompt, elegir un modelo— apoyándote en un número que no mide lo que crees. La respuesta a una concordancia baja no es ignorarla: es arreglar la rúbrica, cambiar el juez o volver a la evaluación humana para esa propiedad. Un instrumento sin calibrar no se usa, se ajusta.

Ejercicio 2: calibrar a tu juez

Escribe una rúbrica de anclaje con tres niveles definidos (1, 3 y 5), pidiendo al juez que razone antes de puntuar. Prepara 15 pares de contexto y respuesta: unos correctos, otros con un detalle inventado que el contexto no respalda, y un par claramente contradichos por el contexto. Etiquétalos a mano antes de ejecutar al juez, para que su nota no contamine la tuya. Luego corre el juez a temperatura cero sobre los 15 y mide la concordancia: en cuántos casos su nota coincide con tu etiqueta.

Si la concordancia queda por debajo de 12 de 15, mejora la rúbrica —niveles más concretos, ejemplos de cada nivel dentro de la propia rúbrica— y vuelve a medir con las mismas etiquetas.

Criterio de éxito: reportas la concordancia antes y después del ajuste; señalas al menos un caso en que el juez discrepó contigo y sabes decir si el error fue del juez o de tu propia etiqueta; y puedes explicar por qué etiquetaste a mano antes de ver las notas del juez y no después.

Evaluar por componentes y de extremo a extremo

El Módulo 7 distinguió el fallo de recuperación del de generación, y el Módulo 8 el de enrutado, del de ejecución, del de consolidación. Esa idea se generaliza aquí en una regla: todo fallo tiene una localización, y medir solo la respuesta final te dice que algo salió mal sin decirte dónde.

La evaluación por componentes aísla cada etapa y la mide contra su propia referencia. Se evalúa la recuperación con las métricas de RAG; la selección de herramientas comprobando si se llamó a la correcta con los argumentos correctos; el enrutado del supervisor comprobando si mandó la pregunta al especialista adecuado; la generación con el juez de anclaje y pertinencia. La evaluación de extremo a extremo, en cambio, mide lo único que el usuario ve: si la respuesta final resolvió la tarea. Las dos son necesarias y responden preguntas distintas. La de extremo a extremo dice si el producto es bueno; la de componentes dice qué arreglar cuando no lo es.

La tríada de RAG

La calidad de un sistema RAG se descompone en tres medidas complementarias, la tríada. El anclaje —o fidelidad— mide si cada afirmación de la respuesta está respaldada por el contexto recuperado; ataca la alucinación. La pertinencia de la respuesta mide si contesta de verdad la pregunta, no si es correcta en abstracto. Y la pertinencia del contexto —con las métricas de ranking del Módulo 7, como el recall@k— mide si lo recuperado contenía la respuesta. Las tres juntas localizan el fallo: si el recall@5 es 0,60, el problema está antes del modelo, porque el 40 por ciento de las veces la fuente nunca llegó; si el recall es alto pero el anclaje es bajo, el problema es que el modelo ignora un contexto que sí recibió. Un único número global no distingue estos dos casos, que exigen arreglos opuestos.

La trayectoria de un agente

En un sistema de varios agentes, la respuesta final es la punta de una trayectoria, y esa trayectoria se evalúa por sí misma. Interesa el éxito de la tarea —¿se cumplió el objetivo?—, la corrección de las llamadas a herramientas —¿se usó la herramienta correcta con los argumentos correctos?—, la eficiencia en pasos —¿lo resolvió en tres rondas o giró en veinte?— y la corrección del enrutado del Módulo 8. Una trayectoria puede llegar a la respuesta correcta por un camino pésimo —diez llamadas donde bastaban dos—, y esa ineficiencia, invisible en la respuesta final, es un costo real que solo la evaluación de trayectoria revela.

Pregunta de comprensión: si el usuario solo ve la respuesta final, ¿por qué molestarse en evaluar los componentes por separado?

Porque una respuesta final mala no dice por qué es mala, y arreglar el componente equivocado gasta esfuerzo sin resolver nada. La misma respuesta pobre puede deberse a que la recuperación no trajo la fuente correcta, a que el modelo ignoró un contexto que sí recibió, o a que el supervisor enrutó la pregunta al especialista que no era; cada causa exige un arreglo distinto —mejorar la búsqueda, ajustar el prompt de anclaje, corregir el enrutado— y una nota global de extremo a extremo no distingue entre ellas. La evaluación por componentes actúa como un diagnóstico que localiza la avería: mide la recuperación contra su referencia, el enrutado contra la suya, la generación contra la suya, y te señala la etapa concreta que baja. La de extremo a extremo sigue siendo imprescindible porque es lo único que refleja la experiencia real del usuario y captura fallos de integración que ninguna etapa aislada muestra. Pero sin la de componentes, sabrías que el sistema falla y estarías a ciegas sobre dónde; con las dos, sabes que falla y sabes dónde mirar. Es la diferencia entre una alarma que suena y un panel que indica qué pieza se rompió.

Trazas: el sustrato de toda evaluación

No se puede evaluar lo que no se registró. Cada métrica de este módulo necesita ver qué pasó por dentro: qué se recuperó, qué herramienta se llamó con qué argumentos, qué decidió el supervisor, cuántos tokens y cuánto tiempo costó cada paso. Esa materia prima es la traza, y los módulos anteriores han ido tendiéndola sin nombrarla del todo. Los filtros de Semantic Kernel del Módulo 3, los callbacks de LangChain del Módulo 4 y los registros de escrituras, recuperaciones y trayectorias que fuiste añadiendo a los proyectos son, todos, trazas.

El estándar que unifica esto es la instrumentación con OpenTelemetry, que emite eventos estructurados de cada paso de un sistema; sobre él se apoyan plataformas como LangSmith en el mundo LangChain y el trazado de Azure AI Foundry, que aterriza en Application Insights. Con las trazas capturadas, la evaluación se bifurca en dos tiempos. La evaluación fuera de línea corre contra el conjunto dorado antes de desplegar, para decidir si un cambio mejora el sistema. La evaluación en línea observa el tráfico real en producción, mide sobre peticiones vivas y detecta la degradación que ningún conjunto fijo anticipa. Esta segunda vertiente, la observabilidad continua de un sistema en manos de usuarios reales, es terreno del Módulo 10; aquí basta con fijar que sin trazas no hay ninguna de las dos.

Advertencia honesta: el SDK de evaluación de Azure —el paquete azure-ai-evaluation—, los evaluadores de Prompt Flow y las superficies de trazado evolucionan con rapidez, y los nombres de evaluadores y sus firmas han cambiado entre versiones. El patrón es estable —instrumentar, capturar la traza, correr evaluadores fuera de línea y en línea—; los detalles de la API, no. Conviene contrastar con la documentación oficial vigente de Azure AI Foundry antes de fijar una versión.

Evaluación de seguridad y adversarial

Las defensas de los módulos anteriores no valen nada si nadie comprueba que siguen en pie. La evaluación adversarial convierte cada defensa en una prueba que intenta romperla: inyecciones indirectas escondidas en documentos, intentos de saltar la compuerta de escritura, peticiones que buscan filtrar datos fuera de permiso, jailbreaks que intentan que el sistema ignore sus reglas. Es el equipo rojo del curso, sistematizado: en lugar de confiar en que las defensas funcionan, se las ataca en cada evaluación y se mide si aguantan.

La forma concreta es tomar las defensas de seguridad que construiste y escribirlas como aserciones. El recorte por permisos del Módulo 7 se vuelve un caso que verifica que un usuario sin acceso no recupera el documento confidencial. La frontera de privilegio del Módulo 8 se vuelve un caso que verifica que el agente de documentos no puede enviar correo. La compuerta de escritura se vuelve un caso que verifica que ninguna acción irreversible se ejecuta sin confirmación. Azure AI Foundry ofrece evaluadores de seguridad y simuladores adversariales que generan estos ataques de forma automatizada, cubriendo categorías como contenido dañino, fugas de datos personales y resistencia a jailbreaks, pero el principio no depende de la herramienta: toda defensa que no se prueba se erosiona.

Pregunta de comprensión: ¿por qué convertir las defensas de seguridad en pruebas automatizadas que se ejecutan siempre, en vez de comprobarlas una vez a mano?

Porque las defensas no permanecen cerradas solas: se erosionan en silencio con cada cambio del sistema. Un ajuste al prompt de un agente, una herramienta nueva conectada a un especialista, un cambio de modelo o una modificación de la consulta de recuperación pueden reabrir un agujero que ya habías cerrado, sin que nada lo señale, porque el cambio parecía inofensivo y su efecto sobre la seguridad es lateral. Una comprobación manual verifica la defensa en un instante y en una versión concreta; no dice nada sobre la versión que desplegarás dentro de dos semanas tras veinte cambios. Solo una prueba que se ejecuta en cada modificación puede atrapar la regresión en el momento en que se introduce, antes de que llegue a producción. Por eso las defensas de los módulos anteriores —recorte por permisos, frontera de privilegio entre agentes, compuerta de confirmación— deben vivir como aserciones dentro del banco de pruebas: casos que fallan en rojo si alguien, sin querer, debilita la defensa. La seguridad no es un estado que se alcanza una vez, sino un invariante que hay que sostener a lo largo del tiempo, y el lugar donde ese invariante se sostiene es la suite de evaluación que corre en cada cambio. Un candado que nadie vuelve a probar es un candado que un día encontrarás abierto sin saber cuándo se abrió.

Regresión y rigor estadístico

La evaluación cobra su máximo valor cuando deja de ser un evento y se vuelve parte del ciclo de desarrollo. Cada vez que cambias un prompt, actualizas un modelo o modificas una herramienta, el banco de pruebas se ejecuta y compara con la línea base: eso es la prueba de regresión, la red que atrapa la mejora que rompió otra cosa. Es la misma disciplina que la integración continua del software, aplicada a un sistema cuyo comportamiento no está en el código sino en los prompts y el modelo.

Aquí acecha una trampa estadística que hay que nombrar con números. Supón que un cambio mueve la nota de extremo a extremo de 82 a 85 por ciento sobre un conjunto de 40 casos. ¿Es una mejora real o ruido? Con 40 casos, el margen de incertidumbre de una proporción ronda, a grandes rasgos, los siete u ocho puntos porcentuales; una diferencia de tres puntos cae dentro de ese margen y no distingue una mejora genuina de la variación aleatoria entre dos ejecuciones. Para afirmar que tres puntos son reales harían falta bastantes más casos —del orden de varios cientos— o una diferencia mayor. Leer una mejora de dos puntos sobre veinte ejemplos como un triunfo es el error más común de quien empieza a evaluar, y lleva a "optimizar" persiguiendo ruido. La regla: cuanto más pequeño el conjunto, mayor debe ser la diferencia para creértela.

Por último, el costo y la latencia son métricas de primera clase, no notas al pie. Un cambio que sube la nota dos puntos pero triplica los tokens o dobla la latencia puede ser una mala decisión, y solo lo sabes si el banco de pruebas mide también el gasto y el tiempo junto a la calidad. La evaluación madura no responde "¿es mejor?" sino "¿es mejor, y a qué precio?".

Ejercicio 3: ¿mejora real o ruido?

Cambiaste el prompt de anclaje y la nota de extremo a extremo pasó de 80 a 84 por ciento sobre tu conjunto de 50 casos. El costo medio por consulta subió de 4.000 a 5.200 tokens y la latencia de 3 a 4 segundos.

Argumenta si la mejora de cuatro puntos es concluyente con 50 casos, estima de forma aproximada cuántos casos necesitarías para creerte una diferencia de esa magnitud, y decide si desplegarías el cambio considerando el aumento de costo y latencia.

Criterio de éxito: reconoces que cuatro puntos sobre 50 casos está en el límite de lo distinguible del ruido y pides más casos o una diferencia mayor; tu estimación de tamaño va en la dirección correcta (más casos reducen el margen); y tu decisión de despliegue pondera explícitamente el 30 por ciento más de tokens y el segundo extra de latencia, no solo la nota.

Proyecto del módulo: un banco de pruebas para el asistente

El objetivo es dotar al Employee AI Assistant multi-agente del Módulo 8 de un banco de pruebas automatizado que mida su calidad, localice sus fallos y proteja sus defensas contra regresiones. Reutiliza las trazas que fuiste registrando en cada módulo.

Parte A: el conjunto dorado

Reúne de 40 a 60 casos que cubran los tres dominios: documentos (pregunta, respuesta de referencia y fuente de SharePoint esperada), datos (consulta y resultado numérico conocido) y acciones (petición, herramienta y argumentos esperados).
Añade casos de borde —preguntas sin respuesta en el corpus, que deben provocar la admisión del vacío— y casos adversariales —una inyección indirecta, un intento de acceso fuera de permiso, un intento de escritura sin confirmación.
Si tienes registros de uso, siembra el conjunto con casos reales, no solo inventados.

Caso de prueba: confirma que cada caso incluye lo que su métrica necesitará —referencia, fuente, herramienta o comportamiento esperado— y que al menos un quinto de los casos son de borde o adversariales.

Parte B: los evaluadores

Implementa evaluadores deterministas: validez del JSON de las herramientas, corrección de la herramienta invocada y sus argumentos, y la comprobación de que el sistema admite el vacío cuando no hay respuesta.
Implementa la tríada de RAG con un LLM como juez —anclaje, pertinencia de la respuesta— y el recall@k del Módulo 7 para la recuperación, y un evaluador de corrección del enrutado del supervisor.
Calibra el juez: etiqueta a mano una muestra y mide su concordancia; si es baja, ajusta la rúbrica antes de confiar en sus notas. Agrega todo en un cuadro de mando por componente y de extremo a extremo, con costo y latencia incluidos.

Caso de prueba: introduce a propósito una versión degradada del sistema —un prompt de anclaje peor— y confirma que el cuadro de mando lo detecta con una caída en anclaje, no solo en la nota global.

Parte C: adversarial y regresión

Convierte las defensas de los módulos anteriores en aserciones de la suite: el recorte por permisos del Módulo 7, la frontera de privilegio entre agentes del Módulo 8 y la compuerta de confirmación de escritura, cada una como un caso que pasa solo si la defensa aguanta.
Conecta la suite al ciclo de desarrollo: cambiar un prompt o un modelo la vuelve a ejecutar y compara con la línea base, marcando regresiones de calidad, de costo o de seguridad.

Caso de prueba de seguridad: debilita deliberadamente el recorte por permisos —quita el filtro de grupos de la consulta de recuperación— y ejecuta la suite. El criterio de éxito es que la aserción de recorte por permisos falle en rojo de inmediato, demostrando que la red de regresión atrapa la reapertura de un agujero de seguridad antes de que llegue a producción. Restaura el filtro y confirma que la suite vuelve a verde. Sin esta prueba, la defensa dependería de que nadie la rompa por descuido; con ella, romperla es imposible sin que la suite lo grite.

Resumen

Este módulo transformó la pregunta "¿funciona?" de una impresión sobre tres ejemplos en un proceso medible. Vimos que las pruebas de igualdad exacta del software tradicional no sirven porque la salida de un modelo no es determinista ni tiene una respuesta única, y que la alternativa es un conjunto dorado de casos con sus referencias, una batería de métricas que puntúan propiedades en lugar de exigir cadenas, y una agregación estadística sobre muchos casos. El conjunto dorado resultó ser un ser vivo que crece con los fallos de producción y que debe incluir bordes y adversariales, no solo el camino feliz, porque ahí es donde vive el riesgo.

Ordenamos las métricas en cuatro familias y fijamos la regla de usar la más barata que capture cada propiedad: deterministas para los hechos, similitud por embeddings como señal, el LLM como juez para la calidad abierta y la evaluación humana para calibrar. El juez, el instrumento central, exige rúbricas concretas, mitigación de sus sesgos y —sobre todo— calibración contra el juicio humano, sin la cual sus notas son ruido con forma de dato. Separamos la evaluación por componentes, que localiza la avería, de la de extremo a extremo, que mide la experiencia real, y concretamos ambas en la tríada de RAG y en la evaluación de trayectorias de agente heredadas de los Módulos 7 y 8. Todo ello se apoya en las trazas —los filtros, los callbacks y los registros que veníamos acumulando—, sin las cuales no hay nada que medir.

Finalmente, convertimos las defensas de seguridad del curso en aserciones que se ejecutan en cada cambio, porque una defensa que no se prueba se erosiona en silencio, e insistimos en el rigor estadístico que impide confundir una mejora de dos puntos sobre veinte casos con un triunfo, midiendo siempre la calidad junto al costo y la latencia. Con esto, el Employee AI Assistant deja de ser un sistema que parece funcionar y pasa a ser uno cuyo funcionamiento se sostiene con números y se protege contra regresiones. Ese banco de pruebas es, además, la condición para el Módulo 10: llevar un agente a producción no es desplegarlo y esperar, sino observarlo en vivo, medir su calidad sobre tráfico real y detectar su degradación antes que los usuarios, que es exactamente la evaluación de este módulo proyectada sobre un sistema en funcionamiento.