Qué modelo de IA usar en cada paso de una automatización: separa decidir de generar

¿Por qué no usar el modelo de IA más potente en todos los pasos?

Dato oficialLa guía de Anthropic para elegir modelo propone dos caminos. Uno parte por la eficiencia: empezar con Claude Haiku 4.5, probar el caso y subir de modelo solo si falta capacidad. La guía lo recomienda para tareas de alto volumen y poca complejidad y para aplicaciones sensibles a la latencia o al costo [4]. La misma documentación describe estrategias que combinan un modelo económico para el grueso del trabajo con un modelo de frontera para las decisiones difíciles, de modo que la mayoría de los tokens se cobren a la tarifa baja [5].

Probado por tercerosLa investigación académica llegó antes a la misma idea. FrugalGPT (2023) encadena modelos de menor a mayor costo y reporta igualar al mejor modelo individual con hasta un 98 % menos de costo en sus pruebas [6]. RouteLLM (2024) entrena un enrutador que decide qué consulta va al modelo fuerte y cuál al débil, y reporta costos más de dos veces menores en algunos casos sin perder calidad de respuesta [7]. Esos porcentajes valen para sus conjuntos de prueba y no se trasladan tal cual a tu flujo.

¿Qué diferencia hay entre decidir y generar?

Nuestra lecturaEn un sistema de captación la mayoría de los pasos deciden. La tabla reparte un flujo típico de entrada de contactos entre las tres manos posibles.

La última fila no depende del modelo. Mientras un borrador salga con el nombre de tu negocio, alguien responde por él, y ese alguien revisa antes de enviar.

El recorrido de un mensaje entrante, paso por paso

Con los pasos separados, el flujo queda así. Cada color marca qué tipo de inteligencia trabaja en ese punto.

El modelo caro trabaja en un solo paso de seis, y solo con los mensajes que merecen respuesta. En una bandeja con mucha publicidad y avisos automáticos, esa diferencia define cuánto contexto consumes y cuánto esperas.

¿Qué es un modelo de decisión y en qué se diferencia de un LLM?

Dato oficialJev, de TypeSafe AI, es el primer modelo de lo que su fabricante llama modelos System One: modelos que toman decisiones estructuradas para que el software las use directo [3]. Responde a tres tipos de pregunta: Choice elige una opción de una lista, Score puntúa según una rúbrica y Noul estima si una afirmación es verdadera, con un valor entre 0 y 1 [3]. Al 26 de septiembre de 2026 la versión vigente es jev-1.13.0, acepta solo texto, admite 64.000 tokens por pedido, cobra 0,042 dólares por millón de tokens de entrada y no cobra la salida. Su fabricante declara el inglés como idioma de mejor precisión, con rendimiento variable en otros idiomas [1].

La documentación trae dos indicaciones que sirven con cualquier modelo. La primera: si una decisión es compleja, hay que descomponerla y preguntar cada factor por separado, para combinar después las respuestas con lógica en código [3]. La segunda: el umbral de confianza no es un número único. Cada acción lleva el suyo según su riesgo, y el fabricante recomienda empezar conservador y ajustar con datos propios [2].

Uso Jev como caso porque separa los dos trabajos de forma extrema: este modelo no puede generar. El mismo criterio vale si decides con un LLM pequeño y una salida restringida a tu lista de opciones.

Tres pruebas propias con un modelo que solo decide

Desde ROCALDEEntre el 21 y el 22 de septiembre de 2026 usé Jev en tres flujos internos de ROCALDE. Ninguno tocó datos de clientes.

• Intención de búsqueda. Clasifiqué consultas de Search Console y candidatos a título en cinco llamadas: 49 consultas y dos tandas de 12 títulos.
• Radar editorial. Evalué en una sola llamada 12 temas candidatos a publicación, con 9 preguntas por tema.
• Calidad visual. Evalué 5 piezas propias ya revisadas por mí, con 8 preguntas por pieza, para comparar la máquina contra mi criterio.

La API registró tokens de salida en todas las llamadas, 9.378 en total. Según la documentación del fabricante esos tokens no se cobran [1]; mis registros miden tokens y latencia y no incluyen la factura.

Lo que pasó bajo el umbral

En las pruebas de SEO fijé 0,60 como umbral: sobre esa confianza la decisión pasaba directo al calendario editorial, bajo ella la revisaba yo. Siete casos cayeron bajo 0,60. Cinco comparten patrón: consultas de marca más servicio, como rocalde seo local, donde el modelo reparte la probabilidad entre intención navegacional y transaccional. Otro fue un empate entre tres títulos candidatos, con probabilidades de 0,36, 0,33 y 0,31 y confianza de 0,05. Elegí ese título con criterio editorial.

El radar editorial dio un resultado parecido. De 12 temas, el modelo y las reglas propusieron no publicar 9, dejaron 3 para revisión humana y no aprobaron ninguno de forma directa. Yo escribí las reglas que convierten sus respuestas en una propuesta, y esas reglas mandan sobre el modelo.

Una pregunta grande contra seis pequeñas

En la prueba de calidad visual comparé dos formas de preguntar sobre las mismas 5 piezas, cada una con una evaluación mía documentada antes de la prueba.

• 1 de 5 Una pregunta directa «¿La calidad es premium, correcta o deficiente?» El modelo calificó de premium tres piezas que yo había calificado de correctas.
• 4 de 5 Seis preguntas y reglas ¿Tiene mecanismo? ¿Tiene dato? ¿Tiene diferencial? Las respuestas se combinan con reglas en código. El único desacuerdo: marcó deficiente una pieza que yo había calificado de correcta.

Nuestra lecturaEl resultado coincide con lo que recomienda el fabricante: preguntas atómicas combinadas en código [3]. «Calidad» es un juicio compuesto; «¿tiene un dato?» es un juicio que alguien resuelve en segundos. Cinco piezas no alcanzan para una conclusión general, y así lo trato.

¿Dónde falla un modelo que solo decide?

• Ambigüedad real. Cuando dos opciones son válidas, como con las consultas de marca más servicio, el modelo se reparte. Ese reparto es útil: te avisa. El problema aparece si alguien sube el umbral a mano para que todo pase.
• Juicio compuesto. Una sola pregunta sobre «calidad» acertó 1 de 5. Descompón el juicio antes de delegarlo.
• Solo texto. Jev no lee imágenes, audio ni video [1]. Una foto o una nota de voz necesitan un paso previo que las convierta en texto.
• Idioma. El fabricante declara su mejor precisión en inglés [1]. Mis pruebas fueron en español y funcionaron, pero no medí la diferencia.
• Calibración. La confianza sale de la forma de la distribución de probabilidades [2]. Qué umbral sirve lo decides tú con casos reales de tu negocio.

¿Cuándo vale la pena separar decidir de generar?

Nuestra lecturaMis tres pruebas sumaron 42.001 tokens de entrada. Al precio publicado de 0,042 dólares por millón [1], equivalen a unos 0,0018 dólares. Para un negocio pequeño ese ahorro no justifica por sí solo el cambio. El beneficio que notas en la operación es el orden: la bandeja llega ordenada, lo dudoso llega marcado y el modelo caro solo lee lo que merece respuesta. El costo pesa cuando el mismo flujo atiende a muchos clientes o a miles de mensajes.

Para empezar sin herramientas nuevas, haz el ejercicio con tu propio flujo:

1. Escribe cada paso de tu flujo de entrada de contactos en una línea.
2. Marca los pasos cuya respuesta puedes listar de antemano. Esos deciden.
3. Para cada paso que decide, escribe qué pasa si la máquina duda y quién recibe el caso.
4. Reúne veinte ejemplos reales por decisión y revisa a mano qué respondería el modelo antes de automatizar la acción.

Si quieres ver cómo se arma la pieza que responde con documentos propios, la guía de RAG con n8n y Qdrant muestra ese otro lado del flujo, el que genera.

Preguntas frecuentes