7. Aserciones con el nodo Evaluation

Descripción

Al terminar esta lección vas a poder dejar de mirar la salida de order-triage a ojo y empezar a verificarla automáticamente: escribir aserciones que comprueban que el agente clasificó cada pedido como debía, correr un conjunto de casos con su resultado esperado, y obtener un veredicto de "pasa / no pasa" contra un umbral de aprobación. Vas a conocer el nodo Evaluation de n8n, sus operaciones para registrar métricas sobre resultados, cómo se arma un dataset de casos con su respuesta correcta, y qué métricas sirven para verificar una clasificación —incluida la salida de un agente de IA—.

Esto importa porque es la diferencia que instalamos en la lección 1 y que hemos ido posponiendo hasta aquí: la que separa "corrió" de "acertó". Un workflow puede terminar en verde y haber clasificado mal un pedido; "sin error técnico" no es "resultado correcto". Hasta ahora, para saber si el agente acertó, tenías que leer su salida y juzgarla tú. Eso no escala —seis casos los revisas a ojo, sesenta no— y no es reproducible —tu juicio de hoy puede diferir del de mañana—. Una aserción convierte ese juicio en una comprobación automática, objetiva y repetible.

Conexión con el módulo: este es el sexto punto del checklist, y el que le da sentido a todos los anteriores. De nada sirve correr en sandbox (2), con datos sintéticos (3), en seco (4), de forma reproducible (5) y a costo cero (6) si al final no verificas que la salida es correcta: sería probar con todo el rigor del mundo y no leer el resultado. Esta lección cierra el círculo. Se apoya en la 3 (los casos sintéticos, ahora con su respuesta esperada), en la 5 (entradas fijas para que la evaluación sea estable) y en la 6 (correr el agente gratis, para que evaluar muchos casos no cueste). En la lección 8 vas a juntar todo en una pasada completa con su veredicto.

El examen con hoja de respuestas

Piensa en cómo se califica un examen de ortografía en una escuela. El maestro no lee las respuestas de cada alumno y decide "de humor" si están bien; sería lento, subjetivo y distinto cada vez. En su lugar usa una hoja de respuestas: una lista con la palabra correcta de cada pregunta. Compara la respuesta del alumno contra la hoja, pregunta por pregunta —¿coincide?, un punto; ¿no coincide?, cero—, suma, y aplica un umbral: de veinte palabras, aprueba con dieciocho. El proceso es rápido, objetivo y produce el mismo veredicto sin importar quién lo aplique, porque la hoja de respuestas es la misma para todos.

Verificar la salida de tu workflow con aserciones es calificar con hoja de respuestas. Tienes tus casos de prueba —los pedidos sintéticos de la lección 3— y para cada uno anotas la respuesta correcta: "este pedido de 52 000 pesos debe clasificarse como manual_review". Esa es tu hoja de respuestas. Corres los casos, y en vez de leer cada salida a ojo, comparas automáticamente lo que el agente respondió contra lo que anotaste que debía responder. Coincide: pasa. No coincide: falla. Sumas, aplicas un umbral, y obtienes un veredicto objetivo y repetible.

Definamos el término. Una aserción (assertion) es una afirmación comprobable sobre el resultado, que solo puede ser verdadera o falsa. "El agente clasificó este pedido como manual_review" es una aserción: se puede comprobar mirando la salida, y da verdadero o falso, sin opinión de por medio. "El agente clasificó bien" no es una aserción —"bien" es un juicio, no una comprobación—; hay que volverla concreta: "el agente clasificó como manual_review, que es lo que esperábamos". Una aserción es la respuesta correcta de la hoja, escrita de forma que una máquina pueda comprobarla.

"Corrió" contra "acertó", una última vez

Vale la pena verlo con un caso concreto, porque es el corazón de la lección. Toma el pedido de 52 000 pesos que debe ir a revisión manual. Corres order-triage y no hay ningún error rojo: el Webhook recibió, el agente respondió, la compuerta desvió, todo verde. ¿Está bien?

No lo sabes todavía. "Todo verde" te dice que el workflow corrió —el motor funcionó, ningún nodo tronó—. No te dice que acertó —que el agente clasificó el pedido como debía—. Si el agente respondió approved en vez de manual_review, el workflow igual habría terminado en verde: técnicamente no hubo ninguna falla, solo una clasificación equivocada. Un pedido de 52 000 pesos que debía revisar un humano se habría aprobado solo, sin una sola raya roja que te avisara.

La aserción es lo que atrapa eso. Al comparar la salida del agente (approved) contra la respuesta esperada (manual_review), la aserción da falso, y ahí tienes tu aviso: el workflow corrió pero no acertó. Sin la aserción, "verde" te habría engañado. Por eso verificar la salida no es un lujo: es la única forma de distinguir un workflow que funciona de uno que solo no falla.

El nodo Evaluation de n8n

n8n trae un nodo dedicado a esto: el nodo Evaluation (evaluación). Su trabajo es ayudarte a comprobar, de forma sistemática, que tu workflow —y en particular la parte de IA— produce los resultados correctos sobre un conjunto de casos. Vamos a ver sus piezas. Antes, una advertencia que esta guía repite por principio: la interfaz de esta función evoluciona rápido. Los nombres exactos de operaciones, campos y métricas que describo abajo son los que la documentación reporta al escribir esta guía (2026); verifica en tu versión de n8n que existan con ese nombre y se comporten así antes de confiar en un detalle fino. Si algo no coincide, quédate con el concepto —comparar la salida contra una respuesta esperada, sobre un conjunto de casos, con un umbral— que es estable aunque la interfaz cambie.

El sistema de evaluación de n8n tiene tres piezas que trabajan juntas:

1. El dataset de casos. Es tu hoja de respuestas: una tabla donde cada fila es un caso, con las entradas (el pedido) y la respuesta esperada (cómo debía clasificarse). n8n guarda ese dataset en una tabla de datos (Data table) o en una hoja de Google (Google Sheet). Cada fila es un examen distinto con su respuesta correcta anotada.

2. El disparador de evaluación (Evaluation Trigger). Es un nodo que arranca el workflow una vez por cada fila del dataset, metiéndole las entradas de esa fila. En vez de mandar un pedido a mano, el disparador recorre tu hoja de respuestas fila por fila y corre el workflow con cada caso. Es el que convierte "probar un caso" en "probar todos los casos de una pasada".

3. El nodo Evaluation. Es el que califica. La documentación le reporta tres operaciones (verifica los nombres en tu versión):

• Set Metrics (registrar métricas) — calcula y guarda una puntuación del resultado: por ejemplo, "¿la clasificación del agente coincide con la esperada?". Las métricas quedan registradas en la pestaña Evaluations del workflow.
• Set Outputs (registrar salidas) — escribe resultados de la evaluación de vuelta al dataset (la tabla o la hoja), para que quede el registro de qué respondió el workflow en cada caso.
• Check If Evaluating (comprobar si se está evaluando) — ramifica el flujo según si la corrida actual es una evaluación o una ejecución normal. Sirve para que, durante una evaluación, el workflow no dispare sus efectos secundarios reales —se conecta directo con el dry run de la lección 4: "si estoy evaluando, no escribas al CRM"—.

Fíjate en lo bien que encaja esa última operación con el módulo: Check If Evaluating es, en esencia, una compuerta de dry run construida específicamente para las pruebas. Cuando el workflow corre dentro de una evaluación, esa rama apaga los efectos; cuando corre de verdad, los deja pasar.

Las métricas: cómo se califica

Una métrica es la regla con la que calificas cada caso —el equivalente de "un punto si la palabra coincide"—. La documentación de n8n reporta varias métricas integradas; estas son las que sirven para verificar una clasificación como la de order-triage (rangos según la doc de 2026; confírmalos en tu versión):

Métrica	Qué mide	Qué devuelve	Cuándo la usas en order-triage
Categorization	Si la respuesta coincide exactamente con la esperada	1 si coincide, 0 si no	La principal: ¿el agente clasificó manual_review cuando debía manual_review?
String Similarity	Qué tan parecida es la respuesta a la esperada, carácter por carácter	Entre 0 y 1	Para textos que pueden variar un poco pero deben parecerse
Correctness (con IA)	Si el significado de la respuesta concuerda con una respuesta de referencia	De 1 a 5	Para salidas en lenguaje libre, donde "igual" es de significado, no de letra
Helpfulness (con IA)	Si la respuesta responde a lo que se pidió	De 1 a 5	Para evaluar una respuesta redactada al cliente
Tools Used	Si la ejecución usó herramientas o no	Entre 0 y 1	Para verificar que el agente usó (o no) la herramienta esperada

Y puedes definir métricas propias (Custom Metrics): calculas la puntuación que quieras dentro del workflow y la mapeas al nodo Evaluation con la operación Set Metrics. Así no estás limitado a las integradas.

Para order-triage, la métrica reina es Categorization: la clasificación es un conjunto cerrado de etiquetas —approved, manual_review, missing_info—, así que "coincide exactamente con la esperada" es justo la pregunta correcta, y devuelve 1 o 0 limpio. Las de IA (Correctness, Helpfulness) son para cuando el agente redacta texto libre, donde la comparación letra por letra no sirve.

Ejemplo trabajado: evaluar la clasificación de order-triage

Veámoslo de punta a punta. Quieres verificar que el agente clasifica bien tus seis casos sintéticos.

Paso 1 — Arma la hoja de respuestas. Creas el dataset (una Data table o una Google Sheet) con una fila por caso: las entradas del pedido y una columna expected con la clasificación correcta.

case	order_id	amount	customer_name	expected
happy-path-approve	ORD-TEST-001	1200	Café Aurora	approved
large-order-manual-review	ORD-TEST-002	52000	Tostaduría del Sur	manual_review
missing-customer-name	ORD-TEST-003	900	(vacío)	missing_info
dirty-amount-as-string	ORD-TEST-004	"3,500.00"	Rincón del Café	approved
edge-zero-amount	ORD-TEST-006	0	Café Aurora	missing_info

Paso 2 — Conecta el disparador de evaluación. Pones el Evaluation Trigger para que corra order-triage una vez por cada fila, metiendo las entradas de esa fila al workflow. Apuntas el agente al modelo local de Ollama (lección 6), para que evaluar los casos no cueste.

Paso 3 — Califica con el nodo Evaluation. Después del agente, pones un nodo Evaluation con Set Metrics y la métrica Categorization, comparando la clasificación que produjo el agente contra la columna expected de la fila. Y usas Check If Evaluating para que, durante la evaluación, el workflow no escriba al CRM.

Paso 4 — Corre la evaluación y lee el veredicto. Disparas la evaluación. n8n recorre las cinco filas, corre el workflow con cada una, califica cada resultado, y agrega las puntuaciones en la pestaña Evaluations.

Qué esperar: ves una tabla de resultados, un caso por fila, con su puntuación de Categorization —1 donde el agente acertó, 0 donde falló— y un agregado (por ejemplo, "4 de 5" o "80%"). Si el agente clasificó mal el dirty-amount-as-string —interpretó "3,500.00" como 3.5 y lo aprobó cuando debía... bueno, ese sí debía aprobarse; digamos que lo mandó a missing_info por confundirse con el formato—, ese caso sale en 0, y lo ves de inmediato, sin haber leído ni una salida a ojo. La evaluación te señala exactamente dónde el agente no acertó, sobre todos los casos, de una pasada. Eso es verificar la salida.

El umbral de aprobación

Calificar cada caso no basta; necesitas una regla que diga, mirando el agregado, "esto pasa" o "esto no pasa". Ese es el umbral de aprobación (pass threshold): la nota mínima para dar la prueba por buena, como el "aprueba con dieciocho de veinte" del examen.

Elegir el umbral tiene más matiz del que parece, y depende de qué tan crítico sea cada caso:

Para los casos críticos, el umbral es 100%. Hay clasificaciones donde equivocarse es inaceptable, y ahí no hay "casi". Que un pedido de 52 000 pesos vaya a revisión manual no es negociable: si ese caso falla, la prueba falla, aunque todos los demás pasen. Los casos de seguridad —los que evitan un daño real— se evalúan con umbral perfecto: cero tolerancia.

Para los casos donde cabe algo de variación, el umbral puede ser menor. Un agente de IA es probabilístico (lección 6): incluso con temperatura baja, puede que en un caso ambiguo acierte 9 de cada 10 veces. Para clasificaciones no críticas, un umbral de, digamos, 90% puede ser razonable —reconoces que el agente no es perfecto y decides cuánta imperfección toleras—. La clave es que tú eliges el umbral a conciencia, no que lo dejas al azar.

La forma práctica de combinarlos: separa tus casos en críticos (umbral 100%, cualquier fallo hunde la prueba) y normales (umbral agregado, digamos 90%). La prueba pasa si todos los críticos pasan y el agregado de los normales supera su umbral. Así proteges lo que no admite error sin exigirle una perfección imposible a lo que sí tolera algo de ruido.

Una nota honesta sobre el determinismo: como el agente puede variar entre corridas, una evaluación que hoy da 100% podría dar 95% mañana con los mismos casos. Por eso el umbral y la temperatura baja (lección 6) trabajan juntos: bajas la variación tanto como puedes, y el umbral absorbe la que queda. Si un caso crítico "a veces pasa y a veces no", eso es un fallo —un caso crítico tiene que pasar siempre—, y la señal de que el prompt del agente necesita más trabajo, no de que bajes el umbral.

Las aserciones como red de regresión

Hay un uso de las aserciones que trasciende esta única prueba y que conviene ver desde ya, porque es donde más valor tienen a la larga: son tu red de regresión. Una regresión es cuando un cambio nuevo rompe algo que antes funcionaba —arreglas una cosa y, sin querer, descompones otra—. Es uno de los fallos más traicioneros, porque nadie lo busca: estabas concentrado en lo nuevo, y lo viejo se rompió a tus espaldas.

Un conjunto de aserciones es la defensa contra eso. Una vez que tienes tus seis casos con su respuesta esperada, cada vez que toques order-triage —cambies el prompt, agregues una regla, ajustes la compuerta— vuelves a correr la evaluación completa. Si tu cambio rompió la clasificación de un caso que antes pasaba, la aserción de ese caso pasa de 1 a 0, y lo ves de inmediato. Sin la red, esa regresión viajaría silenciosa hasta producción; con la red, la atrapas en la corrida siguiente, gratis (modelo local, lección 6). Por eso las aserciones no son un gasto de una sola vez: son un activo que se acumula. Cada caso que agregas es un guardia más que vigila para siempre que ese comportamiento no se rompa. Un workflow con veinte aserciones es un workflow que veinte guardias protegen de las regresiones en cada cambio.

Evaluaciones ligeras y evaluaciones por métricas

n8n distingue dos formas de usar este sistema, y conviene saber cuál te toca en este módulo. La documentación las llama evaluaciones ligeras (light evaluations) y evaluaciones por métricas (metric-based evaluations).

Una evaluación ligera es la que haces durante el desarrollo, contra un puñado de casos que elegiste a mano —tus seis maniquíes sintéticos—. Es rápida, corre unos pocos casos cuidadosamente escogidos, y responde "¿mi cambio rompió algo de lo que ya funcionaba?". Es exactamente lo de este módulo: pruebas de pre-producción sobre casos representativos.

Una evaluación por métricas es más pesada: corre un dataset grande y usa puntuaciones agregadas para vigilar la calidad de forma continua, típicamente ya en producción o cerca de ella. Responde "¿la calidad general se está manteniendo con el tiempo, sobre muchos casos?". Eso se acerca más al monitoreo de calidad —que, como dijimos, vive en la guía de mantenimiento en producción— que a la prueba de pre-producción de este módulo.

Para el checklist de pre-producción, tu herramienta es la evaluación ligera: pocos casos, elegidos a mano, cada uno con su respuesta esperada, corridos antes de promover. No necesitas un dataset de miles para saber si tu cambio rompió la clasificación de los pedidos grandes; necesitas el caso del pedido grande, bien escrito, y su respuesta correcta. La evaluación por métricas es a dónde escalas después, cuando pases a vigilar la calidad en el tiempo; por ahora, seis casos afilados valen más que mil sin curar.

Una aserción sin el nodo Evaluation (el respaldo que siempre funciona)

Como esta función evoluciona y su disponibilidad puede variar entre versiones, vale la pena que sepas armar una aserción sin depender del nodo Evaluation, con nodos básicos que existen en cualquier n8n. Porque el concepto —comparar la salida contra lo esperado y contar aciertos— es más importante que el nodo, y si el nodo no está o cambió, la idea sigue siendo tuya.

El patrón manual tiene tres piezas:

1. Comparar caso por caso con un IF. Después del agente, un nodo IF evalúa si la clasificación del agente es igual a la columna expected del caso. La salida true es un acierto; la false, un fallo. Es la métrica Categorization hecha a mano: coincide o no coincide.

2. Marcar cada resultado. Un nodo Edit Fields agrega a cada caso un campo passed: true/false según por dónde salió del IF. Así cada caso lleva su veredicto.

3. Contar y aplicar el umbral con un nodo Code. Un nodo Code recorre todos los casos, cuenta cuántos pasaron, calcula el porcentaje, y compara contra tu umbral. Como es generar y transformar datos en memoria, el nodo Code de n8n 2.0 lo hace sin problema —no llama a ninguna API, solo cuenta—:

// Cuenta aciertos y aplica el umbral. Recibe todos los casos ya marcados con passed.
const cases = $input.all();                       // todos los casos evaluados
const total = cases.length;
const passed = cases.filter(c => c.json.passed).length;
const rate = total === 0 ? 0 : passed / total;    // proporción de aciertos, 0 a 1

// Los casos marcados como críticos deben pasar TODOS, sin excepción.
const criticalFailed = cases.filter(
  c => c.json.critical && !c.json.passed           // crítico Y falló
);

const verdict = (criticalFailed.length === 0) && (rate >= 0.9);  // umbral 90% + críticos perfectos

return [{
  json: {
    total,
    passed,
    rate,                                          // ej. 0.8 = 80%
    critical_failures: criticalFailed.length,
    verdict: verdict ? "PASS" : "FAIL",
  },
}];

Qué esperar: el nodo Code devuelve un veredicto —PASS o FAIL— junto con cuántos casos pasaron, el porcentaje y cuántos críticos fallaron. Es la misma lógica del umbral por criticidad de arriba, escrita a mano: los críticos deben pasar todos (criticalFailed.length === 0) y el agregado debe superar el 90% (rate >= 0.9).

¿Cuándo usar el manual y cuándo el nodo Evaluation? El nodo Evaluation te da la integración con el dataset, el disparador que recorre las filas y la pestaña Evaluations donde queda el registro —es más completo y más limpio si está disponible en tu versión—. El patrón manual funciona en cualquier n8n, no depende de que la función exista con ese nombre, y te deja ver la mecánica sin capas. Mi recomendación: usa el nodo Evaluation si tu versión lo trae y te sirve; ten el patrón manual en el bolsillo para cuando no, o para entender qué hace el nodo por debajo. En ambos casos, lo que importa —comparar la salida contra lo esperado, contar, aplicar un umbral— es idéntico.

Errores comunes

Confundir "corrió sin error" con "la salida es correcta" (conceptual, el error central). Qué pasa: alguien corre order-triage, ve todo verde, y da la prueba por buena sin verificar qué clasificó el agente. Si el agente se equivocó, el verde lo ocultó. Por qué pasa: el color verde es muy convincente; se siente como "aprobado". Cómo detectarlo: pregúntate si comprobaste la salida contra una respuesta esperada, o solo que no hubo error técnico. Si es lo segundo, no verificaste el resultado. Cómo corregirlo: escribe aserciones. Una hoja de respuestas con la clasificación correcta de cada caso, y una comparación automática. "Verde" te dice que el motor anduvo; la aserción te dice que llegó a donde debía.

Escribir aserciones vagas que no se pueden comprobar (práctico). Qué pasa: alguien anota como "respuesta esperada" cosas como "el agente clasifica bien" o "la salida tiene sentido". Eso no es una aserción: no se puede comparar automáticamente porque "bien" y "con sentido" son juicios. Por qué pasa: es más fácil escribir un juicio que un criterio concreto. Cómo detectarlo: si tu respuesta esperada no se puede comparar con un 1/0 o una puntuación, es vaga. Cómo corregirlo: vuelve cada aserción concreta y comprobable —"clasifica como manual_review", no "clasifica bien"—. La métrica Categorization necesita un valor exacto contra el cual comparar; dáselo.

Poner el mismo umbral a todos los casos (conceptual). Qué pasa: alguien exige 100% a todo, y una prueba falla porque un caso ambiguo no crítico acertó 9 de 10; o al revés, pone 80% a todo y deja pasar un fallo en un caso de seguridad que debía ser perfecto. Por qué pasa: un solo umbral es más simple de configurar. Cómo detectarlo: si no separaste tus casos por criticidad, tu umbral no distingue lo negociable de lo que no. Cómo corregirlo: clasifica los casos —críticos (100%, sin excepción) y normales (umbral agregado)— y exige que todos los críticos pasen además del agregado. El pedido de 52 000 a revisión manual no admite el mismo trato que un caso ambiguo de formato.

Ejercicios

Ejercicio 1 — Vuelve comprobables estas aserciones. Cada una está escrita de forma vaga. Reescríbela como una aserción concreta que la métrica Categorization pueda comprobar, para un caso de order-triage. (a) "El agente maneja bien los pedidos grandes." (b) "Los pedidos incompletos se detectan." (c) "El agente no se confunde con datos sucios."

Ver solución

(a) → "Para el pedido ORD-TEST-002 de 52 000 pesos, la clasificación del agente es igual a manual_review." (b) → "Para el pedido ORD-TEST-003 sin nombre de cliente, la clasificación es igual a missing_info." (c) → "Para el pedido ORD-TEST-004 con monto "3,500.00" (texto), la clasificación es igual a approved" (porque son 3500 pesos, un pedido normal, aunque venga mal formateado).

Por qué funciona: cada versión concreta nombra un caso específico, una salida esperada exacta, y una comparación (es igual a) que Categorization devuelve como 1 o 0. La diferencia con las vagas: "maneja bien", "se detectan", "no se confunde" no se pueden comparar contra nada; "es igual a manual_review" sí. Una aserción es un juicio vuelto criterio.

Ejercicio 2 — Elige la métrica. Para cada cosa que quieres verificar en un workflow, di qué métrica de las integradas usarías y por qué: (a) que la clasificación sea exactamente una de tres etiquetas; (b) que el correo redactado al cliente diga, en esencia, lo mismo que un texto de referencia; (c) que el agente haya usado la herramienta de consulta al CRM; (d) que el resumen generado responda de verdad la pregunta del cliente.

Ver solución

(a) Categorization — la clasificación es un conjunto cerrado de etiquetas; quieres coincidencia exacta (1/0). (b) Correctness (con IA) — un correo redactado varía en las palabras exactas, pero debe concordar en significado con la referencia; comparar letra por letra fallaría con sinónimos, así que necesitas la métrica de significado (escala 1–5). (c) Tools Used — mide justamente si la ejecución usó herramientas. (d) Helpfulness (con IA) — mide si la respuesta responde a lo que se pidió, que es exactamente "¿el resumen contesta la pregunta del cliente?".

Por qué funciona: la métrica se elige por la naturaleza de la salida. Etiqueta cerrada: coincidencia exacta (Categorization). Texto libre que debe significar lo mismo: Correctness. Texto libre que debe ser útil: Helpfulness. Uso de herramientas: Tools Used. Usar Categorization en un texto libre fallaría por cada sinónimo; usar Correctness en una etiqueta cerrada sería matar una mosca a cañonazos.

Ejercicio 3 — Diseña los umbrales. Tienes seis casos: dos críticos de seguridad (un pedido enorme que debe ir a revisión, y uno sin datos que debe marcarse incompleto) y cuatro normales. Diseña la regla de aprobación de la prueba y justifícala.

Ver solución

Regla: la prueba pasa si los dos casos críticos pasan al 100% (cada uno debe salir 1, sin excepción) y el agregado de los cuatro normales supera, digamos, 90% (al menos que la mayoría acierte de forma consistente).

Justificación: los dos críticos evitan un daño real —aprobar solo un pedido enorme que debía revisar un humano, o dejar pasar uno sin datos— y ahí no hay "casi": un fallo hunde la prueba aunque todo lo demás brille. Los cuatro normales toleran algo de la variación natural del agente (lección 6), así que un umbral agregado alto pero no perfecto reconoce esa imperfección sin exigir lo imposible. Si un crítico "a veces pasa", eso cuenta como fallo: un caso de seguridad tiene que pasar siempre, y su inconsistencia es señal de que el prompt necesita trabajo.

Por qué funciona: separar por criticidad hace que el umbral proteja lo que no admite error (100% en críticos) sin castigar la naturaleza probabilística del agente en lo que sí tolera ruido (agregado en normales). Un umbral único no puede hacer las dos cosas a la vez.

Resumen y siguiente paso

En esta lección diste el salto de mirar la salida a verificarla. Una aserción es una afirmación comprobable sobre el resultado —"el agente clasificó como manual_review"— que da verdadero o falso sin opinión, tu hoja de respuestas del examen. Con ella distingues por fin "corrió" (el motor anduvo, todo verde) de "acertó" (la salida es la correcta), que es lo único que de verdad importa. Conociste el nodo Evaluation de n8n y sus tres piezas: el dataset de casos con su respuesta esperada (una Data table o Google Sheet), el Evaluation Trigger que corre el workflow una vez por fila, y el nodo Evaluation con sus operaciones —Set Metrics para puntuar, Set Outputs para registrar, Check If Evaluating para apagar los efectos durante la evaluación (un dry run integrado)—. Elegiste métricas según la salida —Categorization para la clasificación de etiquetas cerradas, Correctness/Helpfulness para texto libre, Tools Used para herramientas— y definiste umbrales de aprobación por criticidad: 100% para los casos de seguridad, un agregado alto para los que toleran la variación natural del agente. Y marcaste, como siempre, que los nombres y campos exactos hay que verificarlos en tu versión, quedándote con el concepto estable si la interfaz cambió.

Con esto marcas el sexto punto del checklist: la salida pasa aserciones.

Antes de avanzar deberías poder: explicar la diferencia entre "corrió" y "acertó" con un ejemplo; nombrar las tres piezas del sistema de evaluación de n8n; elegir la métrica correcta según el tipo de salida; y justificar por qué los casos críticos llevan umbral 100%.

Tienes las siete técnicas del checklist. La lección 8 las junta en una sola pasada de prueba completa sobre order-triage: datos sintéticos, llaves sandbox, dry run, replay y aserciones con el nodo Evaluation, todo a costo cero con el modelo local. El entregable es el checklist ejecutado con su evidencia —el artefacto de portafolio que demuestra que no solo construyes workflows, sino que los pruebas como un dueño del sistema—.

Recursos

• Evaluation node — n8n Docs — el nodo y sus operaciones (Set Metrics, Set Outputs, Check If Evaluating); verifica ahí los nombres exactos de tu versión.
• Use metrics to measure quality — n8n Docs — las métricas integradas (Categorization, Correctness, Helpfulness, String Similarity, Tools Used) con sus rangos, y las métricas propias.
• Test and improve AI workflows — n8n Docs — la sección de evaluación de workflows de IA: datasets, disparador de evaluación y la pestaña Evaluations.
• Data tables — n8n Docs — dónde puede vivir tu dataset de casos con su respuesta esperada, la hoja de respuestas de la evaluación.
• IF node — n8n Docs — para el patrón de aserción manual: comparar la salida del agente contra la respuesta esperada sin depender del nodo Evaluation.