MÓDULO 3.1

⚖️ Mesmo prompt, N modelos, um juiz

O mecanismo da Fusion ponta a ponta: um prompt replicado para vários modelos, um juiz que funde, a teoria que explica por que melhora, o contraste com o Fugu, os parentes acadêmicos e o custo do paralelo.

6
Tópicos
~30
Minutos
Inter.
Nível
0%
0 de 6
1

📨 O que a Fusion faz: 1 prompt → N modelos

A OpenRouter Fusion tem um gesto central simples de descrever: pegue um único prompt e mande-o, sem mudar nada, para vários modelos diferentes ao mesmo tempo. Cada modelo recebe a tarefa inteira e a resolve por conta própria. No fim, você tem N respostas concorrentes para a mesma pergunta.

A palavra-chave é ensemble: um conjunto de modelos respondendo a mesma coisa. Não é divisão de trabalho — é repetição. Ninguém recebe "só o pedaço de código" ou "só o resumo". Todos veem o pedido completo, e a diversidade entre eles é justamente o que a Fusion quer explorar.

🆕 Novo aqui? Três termos

  • Ensemble: juntar vários modelos (ou execuções) e combinar as saídas — em vez de confiar em um só.
  • Fan-out: disparar a mesma requisição para muitos destinos em paralelo de uma vez.
  • Candidato: cada resposta individual que volta de um modelo, antes de o juiz escolher/fundir.
Mesmo prompt
idêntico p/ todos
Em paralelo
todos ao mesmo tempo
N candidatos
N respostas inteiras
Sem pedaços
ninguém divide a tarefa
2

⚖️ O juiz que funde as respostas

N respostas soltas não servem de nada — você quer uma. É aí que entra o juiz: um modelo que lê todos os candidatos e produz a resposta final. Esse padrão tem nome próprio na literatura — LLM-as-judge: usar um modelo para avaliar/escolher entre saídas de modelos.

candidato A candidato B candidato C candidato N … ⚖️ Juiz avalia e funde Resposta final uma só

Os candidatos (ciano) convergem no juiz, que entrega uma resposta única. O juiz pode escolher a melhor, votar, ou reescrever um híbrido.

🎯 Três jeitos de o juiz fundir

  • 1.Pick-best: lê todas e escolhe a melhor resposta inteira, descartando o resto.
  • 2.Votar: quando há resposta "certa" curta, fica com a que mais modelos produziram (maioria).
  • 3.Sintetizar: reescreve uma resposta nova, costurando o melhor de cada candidato.
LLM-as-judge
modelo avalia modelos
Pick-best
escolhe a melhor
Votar
maioria vence
Sintetizar
híbrido novo
3

🌈 Por que isso melhora: perspectivas diversas

A intuição é antiga e vem da estatística: se vários "votantes" erram de jeitos independentes, juntar os votos cancela boa parte dos erros e deixa o acerto comum sobressair. É a "sabedoria das multidões". Modelos diferentes — treinados por empresas diferentes — tendem a errar em pontos diferentes.

Mas há uma condição crítica, que muita gente esquece: os erros precisam ser descorrelacionados. Se você roda cinco cópias do mesmo modelo, elas erram quase igual — o ensemble não ajuda. O ganho da Fusion depende de diversidade real entre os modelos do ensemble.

📊 A regra do ensemble em uma frase

Ensemble só ajuda quando os participantes são, ao mesmo tempo:

  • Bons o bastante — cada um acerta mais do que erra (senão você só soma ruído).
  • Diversos o bastante — erram em lugares diferentes (senão erram juntos e o juiz não tem o que salvar).
  • Julgáveis — o juiz consegue distinguir a melhor resposta (senão escolhe mal).

✓ Onde a diversidade ajuda

  • Modelos de vendors distintos (forças diferentes)
  • Tarefa com muitos caminhos válidos
  • Erro de um modelo é raro mas caro

✗ Onde não adianta

  • Cinco cópias do mesmo modelo
  • Todos os modelos têm a mesma lacuna
  • Um modelo forte já acerta sozinho
4

🔀 Fusion × Fugu: ensemble × decomposição

Os dois usam vários modelos — e param de se parecer aí. O Fugu decompõe: um gerente quebra a tarefa em partes e dá cada parte a um especialista (quem é bom em código faz o código). A Fusion replica: a tarefa inteira vai a todos, e o juiz funde respostas concorrentes. Decompor é dividir; replicar é repetir.

FUGU · decompõe tarefa quebrada parte: código parte: dados parte: texto pedaços DIFERENTES → juntar FUSION · replica prompt inteiro modelo A · tarefa toda modelo B · tarefa toda modelo C · tarefa toda MESMA tarefa → juiz funde

À esquerda, Fugu reparte pedaços diferentes. À direita, Fusion manda a tarefa inteira a cada modelo. Mesma matéria-prima (vários modelos), arquitetura oposta.

Dimensão 🐡 Fugu (decompõe) ⚖️ Fusion (ensemble)
O que cada modelo recebeum pedaço da tarefaa tarefa inteira
Quem decide o splitum gerente/conductorninguém — não há split
Como fundejunta partes complementaresjuiz escolhe/funde concorrentes
Ganho esperadoespecialização por parterobustez por diversidade
Pergunta "quem faz"divide entre especialistastodos fazem tudo
5

👪 Os parentes da Fusion

A Fusion não inventou "paralelo + agregar" — ela empacota um padrão bem estudado. Conhecer os parentes ajuda a ver que isso é técnica madura, não mágica de produto. São três que valem o nome:

1

Self-consistency

Pergunte a mesma coisa ao mesmo modelo várias vezes (com aleatoriedade) e fique com a resposta mais comum. É ensemble "de um modelo só", explorando a variância das próprias amostras. Barato e surpreendentemente eficaz em raciocínio.

2

LLM-as-judge

Usar um modelo para avaliar as saídas de outros — dar nota, ranquear, escolher a melhor. É exatamente o "juiz" da Fusion, e também a base de muitos sistemas de avaliação automática de qualidade.

3

Mixture-of-agents (MoA)

Vários modelos em camadas: a primeira camada responde, a segunda lê as respostas da primeira e refina, e assim por diante. É a Fusion "em profundidade" — agregar não só uma vez, mas em rodadas.

💡 O fio que une os três

Todos respondem à segunda pergunta da orquestração — "como as respostas se combinam" — gerando múltiplos candidatos e agregando. A Fusion é a versão cross-provider, atrás de uma API; o padrão em si você pode montar na mão (você faz isso no Módulo 3.2).

Self-consistency
votar amostras
LLM-as-judge
avaliar saídas
Mixture-of-agents
camadas que refinam
Em comum
gerar + agregar
6

🧾 O custo do paralelo: N respostas + juiz

Aqui está o contrapeso. Rodar N modelos custa N respostas completas — cada um lê o prompt e escreve uma resposta inteira, e você paga por todos. Some a chamada do juiz, que ainda lê todas as N respostas. A conta cresce para algo na ordem de N+1 execuções para entregar uma resposta só.

Latência tem uma boa e uma má notícia. A boa: como os modelos rodam em paralelo, o tempo é o do mais lento, não a soma. A má: o juiz só começa depois que o último termina — então você sempre espera o pior do grupo, mais o passo de fusão.

📊 A aritmética do ensemble

  • Custo ≈ (custo de 1 resposta) × N  +  (custo do juiz lendo N respostas)
  • Tempo ≈ (resposta mais lenta entre os N)  +  (tempo do juiz)
  • Comparação: 3 modelos + juiz ≈ 4 chamadas pagas por uma resposta

⚠️ A armadilha mental

"Perguntar a todo mundo" parece de graça porque cada resposta isolada é barata. Mas você multiplica por N e ainda paga o juiz. Se um modelo forte já acerta, esse N+1 é dinheiro queimado — exatamente o ladder de decisão que a Trilha 2 mostrou nos 38 testes.

Custo N+1
N respostas + juiz
Tokens do juiz
lê todos os candidatos
Latência do pior
espera o mais lento
Custo × benefício
a pergunta final

Recuperação rápida (opcional): qual é a diferença central entre Fusion e Fugu?

Resumo do módulo

1 prompt → N modelos — o mesmo pedido inteiro, em paralelo, para todos. Ensemble, não divisão.
O juiz funde — LLM-as-judge escolhe, vota ou sintetiza uma resposta final.
Diversidade é a condição — só melhora se os erros forem descorrelacionados.
Fusion × Fugu — replicar a tarefa toda vs decompor em pedaços.
Custo N+1 — N respostas mais o juiz; só vale quando 1 modelo não basta.

Próximo módulo:

3.2 — Fusion na prática e o futuro da skill