Módulo 5: Prueba en sandbox antes de producción

6. Probar workflows con nodos AI Agent a costo cero

Siguiente →

Descripción

Al terminar esta lección vas a poder probar el nodo AI Agent de order-triage cuantas veces quieras sin gastar un centavo, apuntándolo a un modelo de lenguaje local de Ollama (como Llama 3.2 o Mistral) en lugar del modelo de pago que usa producción. Vas a entender por qué probar un agente es intrínsecamente caro si no tomas precauciones, cómo el Self-Hosted AI Starter Kit del Módulo 4 ya te trae un modelo local listo, cuándo sí conviene validar contra un modelo en la nube —y por qué nunca contra uno retirado—, y cómo combinar esto con los datos fijados de la lección 5 para pruebas del agente deterministas.

Esto importa porque el nodo AI Agent es la pieza más cara de probar de todo order-triage. Cada corrida de prueba llama a un modelo de lenguaje, y en producción ese modelo cobra por llamada. Como probar bien significa correr muchas veces —ajustas el prompt y corres, agregas un caso y corres, revisas un borde y corres—, el costo de probar un agente contra un modelo de pago se dispara justo cuando más necesitas iterar. Es el "costo de dinero" de la lección 1 en su forma más aguda. El modelo local lo lleva a cero.

Conexión con el módulo: este es el quinto punto del checklist, y cierra el frente del costo que la lección 4 dejó abierto. Ahí viste que un dry run que evita escribir al CRM pero llama a un modelo de pago es solo medio dry run; esta lección tapa la otra mitad. Se apoya de lleno en el Módulo 4: el Starter Kit que levantaste ya incluye Ollama con un modelo local, así que la infraestructura está lista y aquí solo la usamos para probar. Y se conecta con la lección 5 (fijar la salida del agente para no llamarlo en cada prueba) y con la 7 (una vez que puedes correr el agente gratis, escribes aserciones sobre su salida sin que evaluar cueste).

El cocinero que ensaya con ingredientes de la casa

Piensa en un cocinero desarrollando un platillo nuevo que lleva trufa, un ingrediente carísimo. Si probara la receta con trufa de verdad cada vez —y una receta se prueba veinte, treinta veces hasta que sale— gastaría una fortuna solo en ensayos fallidos. Así que no lo hace. Ensaya la técnica —los tiempos, las proporciones, el orden de los pasos— con un ingrediente de la casa, barato, que se comporta parecido: un champiñón común en lugar de la trufa. Hace sus veinte ensayos con champiñón, gratis. Y solo cuando la receta ya está afinada, cocina una versión final con la trufa de verdad, para confirmar que con el ingrediente caro también sale bien. Ensaya barato, valida caro.

Probar un agente de IA es lo mismo. El modelo en la nube de pago es la trufa: potente, el que va a producción, pero caro en cada uso. El modelo local de Ollama es el champiñón de la casa: no idéntico, pero lo bastante parecido para ensayar la lógica —¿el prompt está bien redactado?, ¿el agente recibe bien el pedido?, ¿la salida tiene la forma que espera el resto del workflow?— gratis y sin límite. Haces tus veinte, cien o mil corridas de prueba contra el modelo local, y solo cuando la lógica ya está afinada, haces una validación final contra el modelo de la nube de verdad, en staging. Ensayas barato, validas caro.

Definamos las piezas. Un modelo de lenguaje (LLM, por Large Language Model) es el "cerebro" que usa el nodo AI Agent para clasificar el pedido: le mandas el pedido y un prompt, y te devuelve una decisión. Un modelo en la nube vive en el servidor de un proveedor, que cobra por cada llamada —lo llamas por internet, con una llave de API—. Un modelo local vive en tu máquina: lo descargas una vez y corre ahí mismo, sin internet y sin cobrar, porque el cómputo lo pone tu computadora, no el servidor de nadie. Ollama es el programa que hace fácil descargar y correr modelos locales; es una de las piezas que el Self-Hosted AI Starter Kit del Módulo 4 ya te dejó instalada.

Por qué el modelo local es gratis

Vale la pena entender por qué no cuesta, porque no es magia. Un modelo en la nube cobra porque cada llamada consume cómputo en el servidor del proveedor —sus GPUs, su electricidad, su infraestructura—, y te pasan esa cuenta. Un modelo local corre en tu propia máquina: el cómputo lo pones tú, con el procesador o la GPU que ya tienes y ya pagaste. No hay una factura por llamada porque no hay un tercero poniendo el cómputo. Descargas el modelo una vez —pesa unos cuantos gigabytes— y de ahí en adelante lo corres todas las veces que quieras sin costo por uso.

Hay un intercambio honesto, claro: un modelo local suele ser más pequeño y menos capaz que el mejor modelo de la nube, y corre más lento si tu máquina es modesta. Pero para probar la lógica del workflow —que es lo que hacemos en este módulo— eso casi nunca importa: no estamos evaluando qué tan brillante es el agente, sino que el workflow lo rodee bien. Para eso, el champiñón alcanza de sobra.

Cuánto ahorras, en órdenes de magnitud

Pongámosle números, con la advertencia de que son hipotéticos —los precios de los modelos cambian y dependen del proveedor y del tamaño de cada llamada—; tómalos como una ilustración del orden de magnitud, no como una cotización.

Imagina un ciclo de trabajo típico afinando el clasificador de order-triage. Tienes seis casos sintéticos. Afinar el prompt hasta que quede bien te toma, digamos, veinte iteraciones, y cada iteración corre los seis casos. Eso son 20 × 6 = 120 llamadas al modelo, solo para afinar. Ahora sumemos las pruebas de regresión: cada vez que tocas algo del workflow y quieres confirmar que no rompiste la clasificación, corres los seis casos otra vez; en una semana de trabajo activo, fácil son otras 100 corridas. Vas por más de 200 llamadas en pocos días, y eso es un solo desarrollador afinando un solo agente.

EnfoqueCosto de esas ~200+ llamadasEfecto en cómo trabajas
Contra el modelo de la nubeUn cargo por cada llamada; se acumula rápido y llega despersonalizado a fin de mesRacionas las pruebas: "¿de verdad necesito correr esto otra vez?"
Contra el modelo local (Ollama)Cero por llamada; solo el cómputo de tu máquina, que ya pagastePruebas sin pensarlo: corres cuantas veces quieras

El punto no es el monto exacto —que puede ser chico o grande según el modelo—, sino el cambio de comportamiento que produce. Cuando cada prueba cuesta, aunque sea poco, empiezas a racionarlas, y probar poco es justo lo que este módulo combate. Cuando probar es gratis, pruebas de más, que es exactamente lo que quieres. El modelo local no solo ahorra dinero: te quita el freno mental que te hacía probar menos de lo debido.

El Starter Kit ya te trae el modelo local

Buenas noticias del Módulo 4: no tienes que instalar nada nuevo. El Self-Hosted AI Starter Kit que levantaste incluye, en su Docker Compose, a Ollama junto con n8n, y pre-configura un modelo local —llama3.2— que se descarga solo en el primer arranque. Así que en tu entorno de prueba ya tienes un modelo corriendo, gratis, esperando a que lo uses.

Si quieres otro modelo —por ejemplo, mistral, que muchos prefieren para tareas de clasificación—, se descarga con un comando de Ollama:

# Descarga el modelo mistral a tu Ollama local. Se hace una vez.
# 'pull' significa "traer/descargar"; el modelo queda guardado en tu máquina.
ollama pull mistral

Qué esperar: Ollama descarga el modelo (unos gigabytes, tarda según tu conexión) y lo deja disponible localmente. A partir de ahí, tu instancia de n8n lo puede usar sin volver a descargarlo y sin costo por llamada. Los modelos que tengas descargados son entre los que vas a poder elegir en el nodo.

Nota de versiones: el Starter Kit pre-configura llama3.2 al momento de escribir esta guía (2026). El modelo por defecto y los nombres exactos cambian con las versiones del kit; verifica en tu Docker Compose y en tu Ollama cuáles tienes descargados. Lo estable es el patrón —Ollama corre modelos locales gratis—; el nombre del modelo del día, confírmalo tú.

Sobre la velocidad, y para calmar de antemano: cada máquina es un mundo. Si tienes una GPU, el modelo local responde rápido; si corres solo con procesador (el perfil cpu del Starter Kit), cada clasificación puede tardar varios segundos en vez de uno. Está bien. Para probar la lógica —que es lo nuestro— esa lentitud no importa: no estás sirviendo pedidos en vivo, estás iterando en tu máquina, y unos segundos por corrida es un precio ínfimo comparado con pagar por cada llamada. Si el modelo por defecto va muy lento en tu equipo, descarga uno más pequeño (Ollama ofrece variantes de distinto tamaño) y úsalo para iterar; guarda el modelo grande, o el de la nube, para la validación final. La regla de siempre: si tu máquina se comporta distinto a lo que dice la guía, ajusta el modelo a tu hardware; el patrón no cambia.

Apuntar el AI Agent al modelo local

Ahora la parte concreta: hacer que el nodo AI Agent de order-triage use el modelo local en lugar del de la nube.

En n8n, el nodo AI Agent no trae el modelo adentro; se conecta a un sub-nodo de modelo de chat que le dice qué "cerebro" usar. Un sub-nodo es un nodo auxiliar que se engancha por debajo de otro para darle una capacidad —aquí, el modelo—. En producción, ese sub-nodo es un modelo de la nube. Para probar gratis, conectas en su lugar el sub-nodo Ollama Chat Model, que apunta a tu Ollama local.

El sub-nodo Ollama Chat Model tiene, entre otros, estos campos (verifica los nombres exactos en tu versión):

  • Model — el modelo local a usar; eliges entre los que tienes descargados en Ollama (por ejemplo llama3.2 o mistral).
  • Sampling Temperature — cuánta aleatoriedad mete el modelo. Es clave para las pruebas deterministas, y vuelvo a él en un momento.
  • Una credencial que apunta a tu servidor de Ollama (su dirección local). Como Ollama corre en el mismo Docker Compose que n8n, esa dirección es interna del kit; verifica el valor exacto en la doc del Starter Kit.

Ejemplo trabajado: iterar el prompt de order-triage gratis

Veámoslo. Quieres afinar el prompt con el que el agente clasifica pedidos, y para eso vas a correrlo muchas veces contra tus seis casos sintéticos.

Paso 1 — Conecta Ollama. En tu instancia de dev, al nodo AI Agent de order-triage le conectas el sub-nodo Ollama Chat Model, con el campo Model en llama3.2 (o mistral).

Paso 2 — Fija la entrada. Fijas el pedido de prueba en el Webhook (lección 5), para que cada corrida use el mismo pedido.

Paso 3 — Itera. Corres. El agente clasifica usando el modelo local. Lees la salida, ajustas el prompt, corres de nuevo. Ajustas, corres. Diez, veinte, cincuenta veces.

Qué esperar: cada corrida clasifica el pedido en un par de segundos (o unos más, según tu máquina), y —lo importante— la factura no se mueve. Puedes correr el agente cincuenta veces afinando el prompt y a fin de mes no hay un solo cargo por esas corridas, porque el cómputo lo puso tu máquina. Compara eso con el modelo de la nube: cincuenta corridas de prueba serían cincuenta llamadas cobradas, y eso solo para un caso; con seis casos y varias iteraciones, la cuenta crece rápido. El modelo local convierte "probar el agente" de algo que racionas por su costo a algo que haces sin pensarlo.

El problema de las dos versiones (y cómo manejarlo con honestidad)

Aquí hay una tensión real que no te voy a esconder, porque es el punto más delicado de esta lección. A lo largo de la guía insistimos en que el mismo workflow, byte por byte, corre en todos los entornos, y que es el entorno —no el workflow— el que cambia el comportamiento (la credencial del CRM en la lección 2, la compuerta por entorno en la 4). Pero el modelo de chat es un sub-nodo dentro del workflow, y el sub-nodo de Ollama y el de un modelo de la nube son nodos de tipo distinto. Cambiar de uno a otro no es cambiar una credencial: es cambiar una pieza del workflow. Entonces, ¿cómo pruebo con Ollama sin que mi workflow de prueba se separe del que va a producción?

Hay dos formas honestas de manejarlo, y conviene conocer las dos:

Forma 1 — Ollama como acción temporal de desarrollo, con validación final contra el modelo real. Conectas Ollama en dev solo mientras iteras —es una acción de trabajo, no un cambio que commiteas—. El workflow que versionas y promueves conserva el sub-nodo del modelo de producción. Antes de promover, haces una pasada de validación en staging contra el modelo de la nube de verdad, para confirmar que la lógica que afinaste con el champiñón también funciona con la trufa. Es exactamente el patrón del cocinero: ensayas con Ollama (barato, muchas veces), validas con el modelo real (caro, una vez). La disciplina clave: lo que se promueve usa el modelo de producción, y pasó al menos una validación contra él.

Forma 2 — Un solo nodo que apunte a los dos, por configuración. Ollama expone un punto de acceso compatible con la API de OpenAI. Eso abre la posibilidad de usar un único sub-nodo de modelo cuya dirección base (base URL) apunte, por entorno, a tu Ollama local (en dev) o al proveedor de la nube (en prod) —el mismo truco de "una credencial por entorno" del Módulo 4, aplicado al modelo—. Con esto el workflow queda idéntico y solo cambia la credencial. Verifica en tu versión si tu sub-nodo de modelo permite sobrescribir la dirección base y si la compatibilidad de Ollama cubre lo que tu agente necesita; no todos los nodos ni todas las funciones se comportan igual por este camino, así que confírmalo antes de confiar en él.

Mi recomendación práctica, mientras no confirmes la Forma 2 en tu versión: usa la Forma 1. Es más simple de razonar y no depende de compatibilidades que quizás cambien. Y en ambos casos, la regla de oro es la misma: el artefacto que llega a producción usa el modelo de producción, y fue validado contra él al menos una vez. Ollama es para iterar barato, no para reemplazar la validación final.

Cuándo sí conviene el modelo de la nube (y nunca uno retirado)

El modelo local no reemplaza al de la nube; lo complementa. Hay dos momentos donde sí quieres el de la nube, y conviene tenerlos claros.

Para la validación final antes de producción. Un modelo local se comporta distinto que el de la nube: puede clasificar un pedido borde de otra forma, redactar distinto, entender peor una instrucción sutil. Si afinaste todo con el champiñón, tienes que confirmar con la trufa antes de servir. Esa validación final —una pasada de tus casos contra el modelo vigente de producción, en staging— es la que atrapa las diferencias que el modelo local escondió. Saltártela es como aprobar una receta que nunca cocinaste con el ingrediente de verdad.

Cuando la tarea de verdad excede al modelo local. Si tu agente hace algo que un modelo pequeño no maneja bien —razonamiento complejo, un idioma que el local domina mal—, quizás ni para iterar te sirva el local, y tengas que probar con el de la nube desde antes (cuidando el costo con datos fijados y pocas corridas). Es el caso menos común, pero existe.

Y una regla dura sobre qué modelo de la nube usar cuando lo uses: nunca uno retirado. Los proveedores retiran (deprecan y luego apagan) modelos viejos con el tiempo. Validar tu workflow contra un modelo que el proveedor va a apagar —o ya marcó como obsoleto— es construir sobre arena: el día que lo apaguen, order-triage en producción deja de clasificar, porque llama a un modelo que ya no existe. Cuando valides contra la nube, hazlo contra el modelo vigente que tu producción va a usar, no contra uno viejo "porque es más barato" o "porque ya lo conocía". Un modelo retirado no ahorra: es una falla programada con fecha.

No voy a nombrar modelos concretos de la nube en esta guía, y es a propósito: los nombres y versiones vigentes cambian rápido, y cualquier lista que escriba hoy estaría vieja en meses. La regla que sí es estable: usa el modelo vigente que corre tu producción, verifica en la doc del proveedor que no esté marcado como retirado o en camino a serlo, y trata "qué modelo" como un dato volátil que confirmas por cohorte, no como algo fijo en la guía.

Pruebas deterministas del agente: temperatura y datos fijados

Un agente es, por naturaleza, algo impredecible: a la misma entrada puede responder distinto en dos corridas (lo viste al final de la lección 5). Eso pelea contra la reproducibilidad. Tienes dos palancas para domarlo, y se combinan.

Bajar la temperatura. El campo Sampling Temperature del sub-nodo controla cuánta aleatoriedad mete el modelo al responder. En valores altos, el modelo "improvisa" más y varía entre corridas; en valores bajos —cerca de cero— tiende a dar la respuesta más estable a la misma entrada. Para pruebas, baja la temperatura: quieres que el agente responda lo más consistente posible, para que si el resultado cambia, sea por tu cambio y no por su humor. No lo vuelve perfectamente determinista —un modelo de lenguaje rara vez lo es del todo—, pero reduce mucho la variación.

Fijar la salida del agente. Cuando estás probando la lógica posterior al agente —la compuerta por entorno, la escritura al CRM—, no necesitas que el agente piense de nuevo en cada corrida; necesitas una salida suya estable. Ahí fijas la salida del nodo AI Agent (lección 5) con una respuesta buena que capturaste. Doble ganancia: la prueba se vuelve perfectamente reproducible aguas abajo, y de paso ni siquiera llamas al modelo, así que el costo es cero incluso si el sub-nodo apuntara a la nube. Fijar la salida del agente es la forma más contundente de probar todo lo que viene después de él sin depender de él.

La regla que junta todo: fija lo que no estás probando, para aislar lo que sí. ¿Pruebas al agente en sí? No fijes su salida (es lo que evalúas), pero corre contra Ollama con temperatura baja para que sea barato y estable. ¿Pruebas lo que viene después del agente? Fija su salida y olvídate de él. Cada pregunta pide congelar una parte distinta.

Y una consecuencia de privacidad que suele pasar desapercibida: como el modelo local corre en tu máquina, los datos que le mandas al agente nunca salen de tu computadora. Cuando pruebas contra un modelo de la nube, cada pedido de prueba viaja al servidor del proveedor; con datos sintéticos eso es inofensivo, pero si alguna vez probaras con datos reales (que no deberías, lección 3), estarías mandándolos a un tercero. El modelo local cierra esa puerta por diseño: el pedido entra al agente y se queda en tu máquina. Para probar, es una tranquilidad más; para ciertos entornos con reglas estrictas de datos, es directamente un requisito.

Un beneficio extra del modelo local que vale la pena nombrar: funciona sin internet. Como Ollama corre en tu máquina, puedes iterar el agente en un avión, en un café con wifi malo, o en una máquina sin salida a internet por política de seguridad. El modelo de la nube exige conexión —y una conexión estable, porque cada corrida es una llamada de ida y vuelta—; el local no depende de nada externo. Para el trabajo de prueba de este módulo, esa independencia es más valiosa de lo que parece: probar bien implica muchas corridas, y no querer que cada una dependa de que la red esté buena. Otra razón para que el ensayo barato sea también un ensayo robusto.

Errores comunes

Iterar el prompt contra el modelo de pago sin pensar en el costo (práctico y caro). Qué pasa: alguien afina el prompt de su agente corriéndolo una y otra vez contra el modelo de la nube, y a fin de mes se sorprende con la factura. Afinar un prompt son decenas de corridas; contra un modelo de pago, decenas de cargos. Por qué pasa: en dev cada corrida se siente "gratis" porque no ves el cargo en el momento; el costo llega despersonalizado, un mes después. Cómo detectarlo: si estás iterando un agente contra un modelo de pago, cada corrida cuesta, aunque no lo sientas. Cómo corregirlo: itera contra Ollama local. El Starter Kit ya te lo dio; úsalo. Guarda el modelo de pago para la validación final, no para el ensayo.

Afinar todo con el modelo local y promover sin validar contra el real (conceptual y peligroso). Qué pasa: alguien afina order-triage perfecto contra llama3.2, ve que clasifica bien sus seis casos, y lo promueve a producción —donde corre un modelo de la nube distinto que se comporta diferente—. En producción, el agente clasifica algunos bordes de otra forma, y nadie lo probó. Por qué pasa: es fácil confundir "funciona con el champiñón" con "funciona". Cómo detectarlo: si tu única prueba del agente fue contra el modelo local, y producción usa otro, no validaste lo que promueves. Cómo corregirlo: haz siempre una pasada de validación final contra el modelo vigente de producción en staging, antes de promover. Ensaya barato, pero valida caro; no te saltes el caro.

Validar contra un modelo retirado (práctico, falla con fecha). Qué pasa: alguien elige para la validación un modelo de la nube viejo, "porque es más barato" o "porque ya lo tenía configurado", sin notar que el proveedor lo marcó como obsoleto. Meses después el proveedor lo apaga, y order-triage en producción deja de funcionar de golpe. Por qué pasa: un modelo viejo parece equivalente y a veces cuesta menos; su fecha de apagado no se ve en el momento. Cómo detectarlo: revisa en la doc del proveedor si el modelo que usas está marcado como retirado, deprecado o con fecha de fin de vida. Cómo corregirlo: valida y corre en producción contra el modelo vigente. "Vigente" es un dato que verificas por cohorte, no algo que fijas una vez y olvidas.

Ejercicios

Ejercicio 1 — ¿Champiñón o trufa? Para cada situación, di si conviene el modelo local (Ollama) o el de la nube, y por qué: (a) afinar el prompt de clasificación corriendo 40 veces; (b) la validación final antes de promover a producción; (c) probar la compuerta por entorno que va después del agente; (d) demostrarle a tu jefe cómo se comportará el agente en producción.

Ver solución

(a) Local — 40 corridas de afinado contra un modelo de pago son 40 cargos; el local las hace gratis, y para afinar la redacción del prompt el champiñón alcanza. (b) Nube — la validación final debe ser contra el modelo vigente de producción, para atrapar las diferencias que el local esconde; es la trufa de confirmación. (c) Ninguno, en realidad: fija la salida del agente — si pruebas lo que viene después del agente, no necesitas que el agente piense; fija su salida (lección 5) y ni llamas al modelo. Si tuvieras que elegir uno, local; pero lo correcto es no llamarlo. (d) Nube — si el punto es mostrar el comportamiento real de producción, tiene que ser el modelo real; el local se comportaría distinto y la demo engañaría.

Por qué funciona: la decisión depende de qué estás probando. Afinar lógica: local (barato). Confirmar comportamiento real: nube (fiel). Probar lo de después del agente: fija su salida (ni lo llamas). La pregunta no es "¿cuál modelo es mejor?", sino "¿qué estoy probando y qué necesito congelar?".

Ejercicio 2 — Diseña el flujo de prueba del agente sin gastar. Escribe el plan, paso a paso, para afinar y validar el clasificador de order-triage gastando lo mínimo posible. Incluye qué modelo usas en cada paso y qué congelas.

Ver solución

Un plan de costo casi cero:

  1. Fija las entradas. Fija los seis casos sintéticos (o córrelos desde un nodo Code) para que cada iteración use los mismos pedidos (lección 5).
  2. Conecta Ollama. Apunta el AI Agent a llama3.2 o mistral local, con la temperatura baja para estabilidad.
  3. Itera gratis. Afina el prompt corriendo los seis casos cuantas veces necesites, contra el modelo local. Costo: cero.
  4. Cuando la lógica esté afinada, valida caro una vez. En staging, cambia al modelo vigente de producción y corre los seis casos una pasada, para confirmar que todo se sostiene con el modelo real. Costo: seis llamadas, una vez.
  5. Para probar lo de después del agente (compuerta, CRM), fija la salida del agente y prueba sin volver a llamar a ningún modelo. Costo: cero.

Total: cerca de cero, con una única pasada de validación de pago. Compara con afinar todo contra la nube: decenas de corridas de pago.

Por qué funciona: el gasto se concentra en el único momento donde la fidelidad importa —la validación final—, y todo lo demás (afinado, pruebas de lo posterior) se hace gratis con modelo local o con salida fijada. Ese es el patrón de costo cero del módulo aplicado al agente.

Ejercicio 3 — Encuentra el riesgo escondido. Un compañero dice: "afiné el agente con Ollama, bajé la temperatura a cero, fijé las entradas, mis seis casos pasan perfecto. Listo para producción". ¿Qué le falta antes de promover?

Ver solución

Le falta la validación final contra el modelo de producción. Todo lo que hizo está bien —iterar con Ollama, temperatura baja, entradas fijas, seis casos que pasan— pero todo fue contra el modelo local. Producción va a usar un modelo de la nube distinto, que puede clasificar los bordes de otra forma. "Pasa con el champiñón" no garantiza "pasa con la trufa".

Antes de promover debe: en staging, cambiar al modelo vigente de producción y correr los seis casos una vez. Si los seis siguen pasando con el modelo real, entonces sí está listo. Si alguno cambia, encontró justo la diferencia que el modelo local escondía, y mejor descubrirla en staging que en producción.

Segundo detalle menor: debería confirmar que el modelo de la nube que va a usar está vigente, no retirado, para que producción no se apague en unos meses.

Por qué funciona: el error clásico de esta lección es confundir "lo probé exhaustivamente" con "lo probé exhaustivamente contra lo que va a correr de verdad". La exhaustividad no sirve si fue contra el ingrediente equivocado.

Resumen y siguiente paso

En esta lección viste por qué el nodo AI Agent es la pieza más cara de probar —cada corrida llama a un modelo, y probar bien es correr muchas veces— y cómo llevar ese costo a cero: apuntar el agente a un modelo local de Ollama (llama3.2, mistral), que corre en tu máquina sin cobrar por llamada porque el cómputo lo pones tú. El Self-Hosted AI Starter Kit del Módulo 4 ya te lo trae listo. Es el patrón del cocinero: ensaya barato con el modelo local (el champiñón), valida caro una vez con el modelo vigente de la nube (la trufa) antes de promover. Enfrentaste con honestidad el problema de las dos versiones —el modelo es un sub-nodo, no una credencial— y sus dos manejos: Ollama como acción temporal de desarrollo con validación final contra el modelo real (la simple y recomendada), o un solo nodo por dirección base configurable (a verificar en tu versión). Grabaste la regla dura: valida contra el modelo vigente, nunca uno retirado, que sería una falla con fecha. Y viste cómo domar la impredecibilidad del agente para pruebas deterministas: bajar la temperatura y fijar su salida cuando pruebas lo que viene después de él.

Con esto marcas el quinto punto del checklist: el agente de IA se prueba a costo cero. Es el punto que más presupuesto salva, porque el costo del LLM crece con cada corrida, y probar bien es correr muchas veces; llevarlo a cero es lo que te permite probar sin racionar.

Antes de avanzar deberías poder: explicar por qué un modelo local es gratis y uno de la nube cobra; describir el patrón "ensaya barato, valida caro"; decir por qué nunca se valida contra un modelo retirado; y nombrar las dos palancas que vuelven deterministas las pruebas del agente (bajar la temperatura y fijar su salida).

Ya puedes correr todo order-triage —agente incluido— a costo cero y de forma reproducible. Pero hasta ahora "probar" ha sido correr y mirar la salida. La lección 7 da el salto final: dejar de mirar a ojo y verificar automáticamente que la salida es la correcta. Vas a conocer el nodo Evaluation de n8n para escribir aserciones sobre el resultado —incluida la salida del agente—, armar un conjunto de casos con su resultado esperado, y definir un umbral de aprobación. Es la diferencia entre "corrió" y "acertó", que instalamos en la lección 1 y que aquí por fin se vuelve automática.

Recursos

← Anterior5. Datos fijados y replay de ejecuciónSiguiente →7. Aserciones con el nodo Evaluation