🎯 Cuándo gana el enfoque de paralelizar y fusionar
El ensemble no es gratis (viste el costo N+1 en el módulo anterior), así que necesita pagar el precio en sí. Gana exactamente cuando el el costo de equivocarse es alto e no hay respuestas correctas para verificar: decisiones abiertas, redacción de alto riesgo, análisis en los que el punto ciego de un modelo pasaría desapercibido.
La lógica: cuando la tarea tiene alta variabilidad — los buenos modelos a veces aciertan y a veces fallan; ejecutar varios y dejar que el juez elija reduce la posibilidad de que te quedes con un fallo de un solo modelo. La diversidad compra robustez, no genialidad.
🆕 Tres términos de decisión
- Costo del error: cuánto duele una respuesta incorrecta (desde «lo rehago en 5 min» hasta «perdí un cliente»).
- Verificable: ¿existe una prueba/solución que indique si la respuesta es correcta (código que se ejecuta, hecho verificable)?
- Variabilidad: cuánto varía la calidad de la respuesta de un mismo modelo entre ejecuciones.
🥇 Cuándo basta con 1 modelo potente
El default honesto es incómodo para quien ama orquestar: en la mayoría de las tareas, un modelo de primer nivel por sí solo ya basta. Si lo resuelve, el ensamble solo agrega costo y espera sin cambiar el resultado. Eso fue exactamente lo que mostraron las 38 pruebas de la Trilha 2: 36 de 38 terminaron en empate técnico, y el modelo solo fue más rápido y barato.
El ensemble es el último escalón, no el primero. La pregunta no es "¿cómo orquesto?", sino "¿necesito orquestar?".
📊 Señales de que 1 modelo es suficiente
- La tarea es verificable (tiene una prueba/respuestas correctas) — entonces pruebas directamente la salida de 1 modelo.
- Un modelo top ya alcanza la meta de calidad en el caso común.
- La velocidad o el costo importan: el ensemble añade minutos y multiplica la cuenta.
🛠️ Hacerlo tú mismo: el patrón del "juez"
No necesitas una API especial para usar el patrón Fusion. El patrón es tuyo, y Claude Code ya abre sub-agents en paralelo. Pide N respuestas desde ángulos diferentes y un agente juez que fusiona. Ensamble manual, con control total y el costo visible antes de pagar.
💡 Practica: ensemble + juez en acción
Objetivo: ejecutar tú mismo el patrón Fusion (N candidatas → el juez las combina), en Claude Code. Pega, cambia los <...> y ejecuta.
Tarefa: <descreva a tarefa — ex.: "proponha um nome e tagline para o produto X"> Use o padrão ENSEMBLE + JUIZ: 1. Abra 3 sub-agents em PARALELO. Cada um resolve a tarefa INTEIRA, mas por um ângulo diferente: - agente 1: ângulo <ex.: "ousado / memorável"> - agente 2: ângulo <ex.: "claro / descritivo"> - agente 3: ângulo <ex.: "técnico / sério"> 2. Depois, um agente JUIZ lê as 3 propostas, compara segundo <critério — ex.: "memorabilidade + clareza">, e produz UMA resposta final (escolhendo a melhor OU sintetizando um híbrido). O juiz deve justificar a escolha em 2 linhas.
Cómo verificar: verás los 3 agentes ejecutándose al mismo tiempo (el fan-out / paralelo) y, al final, una única respuesta con la justificación del juez (la fusión). Esto es Fusion, sin ninguna API de Fusion.
✓ Por qué hacerlo a mano
- ✓Eliges los enfoques y el criterio del juez
- ✓Consulta el costo (N agentes) antes de iniciar
- ✓Actívalo solo cuando la tarea requiera robustez
✗ Precauciones
- ✗Ángulos parecidos = candidatos parecidos (sin ganancia)
- ✗Un juez débil elige mal: dale criterios explícitos
- ✗No lo uses en tareas que 1 agente ya puede resolver
💰 Economía unitaria de la orquestación
Economía unitaria es el costo (y el retorno) de una unidad — aquí, una respuesta entregada. La pregunta correcta no es "¿cuál modelo es el más inteligente?", sino "¿cuál es el costo por resultado aceptable?". A veces, 3 modelos baratos + un juez superan a 1 modelo caro por el mismo dinero, y a veces no.
Es la métrica que usa el autor de la prueba de campo para decidir: optimizar la economía unitaria, no la vanidad del benchmark. Recuerda los números de la Ruta 2: el orquestador salió 5× más caro (US$ 53,60 vs US$ 10,66) y 4,5× más lento para el mismo resultado. Ahí, la economía por unidad es pésima; en otro contexto, excelente.
| Estrategia | Costo relativo | Cuándo tiene sentido |
|---|---|---|
| 1 modelo potente | 1× | tarea verificable / basta con el modelo de punta |
| 3 modelos baratos + juez | ~3–4× (pero barato por unidad) | robustez por diversidad a bajo costo |
| 3 modelos caros + juez | ~4× del caro (alto) | solo si el error cuesta más que la cuenta |
| Orquestador cerrado | 5× (Fugu, prueba de campo) | conveniencia + cobertura, el costo no importa |
📊 La cuenta que cambia la decisión
Pregunta por la respuesta: $ por buen resultado = costo total ÷ tasa de aciertos. Un modelo barato con un 90 % de aciertos puede tener una mejor economía unitaria que uno caro con un 95 %: depende de cuánto cuesta ese 5 % adicional y del precio de cada error.
🛡️ Cobertura ante proveedores: no quedar atado a 1 provider
Dependencia de un proveedor es quedar atado a un solo proveedor: si sube el precio, deja de funcionar o el modelo empeora, no tienes adónde ir. Usar varios providers, a través de una sola API como hace OpenRouter, es un cobertura: un seguro contra ese riesgo.
El detalle ingenioso: ese beneficio no depende de que el ensemble mejore la respuesta. Incluso cuando varios modelos dan el mismo resultado, poder cambiar de proveedor sin reescribir nada ya tiene valor: pura resiliencia operativa.
🛡️ Lo que te da el hedge
- •Continuidad: si un modelo falla, tu app sigue con los demás.
- •Poder de negociación: no depende de un solo precio; puedes migrar.
- •Adaptación: ¿aparece un modelo nuevo mejor? Lo conectas sin reescribir.
⚖️ Hedge ≠ calidad adicional
No confundas las dos ventajas de Fusion. Una es calidad (el ensemble + el juez aciertan más) y exige diversidad real. La otra es resiliencia (cobertura ante fallas del proveedor) y vale incluso sin ninguna mejora de calidad. Decide cuál estás comprando; a veces es solo la segunda.
🔮 La skill del futuro: orquestar teniendo en cuenta los costos
Al unirlo todo, aparece la habilidad que el curso quería desarrollar: saber cuándo orquestar, qué patrón usar y a qué costo. No se trata de memorizar productos, sino de tener criterio para aplicar la escalera de decisión y elegir entre descomponer (Fugu), replicar y fusionar (Fusion) o simplemente usar un solo modelo.
La idea central del autor de la prueba de campo resume bien: la idea es el futuro — no quedar atado a un provider, optimizar la economía unitaria y usar el modelo más barato que no sacrifique calidad. Pero hoy, para mucho trabajo, todavía no compensa. La habilidad consiste precisamente en distinguir el «hoy» del «cuándo».
🎯 La lista de verificación del orquestador consciente
- 1.¿Necesito orquestar? ¿Un modelo potente ya no resuelve? (por defecto: usa solo 1)
- 2.¿Qué patrón? ¿La tarea requiere partes especializadas (descomponer) o robustez mediante diversidad (ensemble)?
- 3.¿A qué costo? ¿El costo por un buen resultado justifica el N+1 y la espera?
- 4.¿Compro calidad o una cobertura? Sé honesto sobre qué beneficio estás pagando.
Repaso rápido (opcional): ¿cuál es la primera pregunta del orquestador consciente?
✅ Resumen del módulo
Completaste el curso:
Fundamentos → Fugu (descompone) → Fusion (ensemble). Ahora tú orquestas —o no— con conciencia de los costos.