Resumo Técnico: Brick - Roteamento de Capacidade Espacial para o Paradigma de Mistura de Modelos (MoM)

1. Declaração do Problema

O artigo aborda o desafio de rotear consultas de forma eficiente através de um pool heterogêneo de Grandes Modelos de Linguagem (LLMs) durante a inferência. A dificuldade central reside em definir "dificuldade" empiricamente: a complexidade de uma consulta não é determinada por características superficiais como contagem de tokens ou rótulos de domínio, mas pelos requisitos específicos de capacidade da tarefa em relação aos pontos fortes e fracos de um modelo.

As estratégias de roteamento existentes baseiam-se em roteamento superficial (baseado em domínio ou em comprimento/palavras-chave), o que falha em capturar a variância intra-domínio. Por exemplo, uma consulta curta pode visar um problema não resolvido que exige um modelo de fronteira, enquanto um prompt longo e burocrático pode envolver uma tarefa trivial que pode ser resolvida por um pequeno modelo de pesos abertos. Isso leva a duas ineficiências:

1. Ineficiência de Custo: Enviar consultas fáceis para modelos de fronteira caros (ex: Kimi 2.6) desperdiça orçamento, já que modelos locais de pesos abertos (ex: Qwen 3.5-9B) costumam ser suficientes.
2. Trade-offs de Latência e Precisão: O roteamento em cascata (testando modelos do mais barato para o mais caro) acarreta um overhead significativo em fluxos de trabalho de agentes, onde uma única requisição do usuário dispara múltiplas chamadas de LLM, acumulando o custo das tentativas "baratas" rejeitadas.

O objetivo é despachar cada consulta para o modelo mais barato que a responderá corretamente, equilibrando custo, latência e precisão sem depender de heurísticas superficiais.

2. Metodologia: O Roteador Brick

Os autores propõem o Brick, um roteador multimodal que opera dentro do paradigma de Mistura de Modelos (MoM). Diferente da Mistura de Especialistas (MoE), que ativa sub-redes dentro de um único modelo, o MoM despacha consultas inteiras para modelos distintos e independentes.

2.1 O Paradigma MoM

O Brick utiliza um pool de três modelos heterogêneos:

• Qwen3.5-9B: Um modelo de estado da arte com pesos abertos (<10B parâmetros).
• DeepSeek-V4-Flash: Um modelo de estado da arte com pesos abertos (<500B parâmetros).
• Kimi2.6: Um competidor de código aberto de fronteira.

O pool abrange diferentes faixas de preço (variando de aproximadamente ~$0.001 a ~$0.03 por chamada) e perfis de capacidade, permitindo que o roteador explore a complementaridade de capacidade (ex: um modelo pode recusar uma consulta que outro resolve).

2.2 O Espaço de Capacidade Seis-Dimensional

O Brick enquadra o roteamento como uma decisão geométrica em um espaço de capacidade de seis dimensões. As dimensões são:

1. Codificação (Coding)
2. Síntese Criativa (Creative Synthesis)
3. Seguimento de Instruções (Instruction Following)
4. Raciocínio Matemático (Math Reasoning)
5. Planejamento/Agêntico (Planning/Agentic)
6. Conhecimento de Mundo (World Knowledge)

O Pipeline:

1. Estimativa de Capacidade: Um classificador ModernBERT ajustado mapeia a consulta para um vetor de probabilidade $p(x)$ sobre as seis dimensões.
2. Estimativa de Complexidade: Um classificador separado estima um score de dificuldade $\tau_q$ (misturado a partir de âncoras "fácil/médio/difícil").
3. Calibração da Matriz de Habilidades: Uma matriz de habilidades $S$, calibrada offline, armazena as taxas de sucesso empíricas ($s_{m,c}$) de cada modelo $m$ em cada capacidade $c$, derivadas de um conjunto de dados rotulado.
4. Matemática de Roteamento Geométrico:
   • Requisito: O vetor de requisito da consulta $r_{q,c}$ é derivado de $p(x)$ e do logit de dificuldade $z_q$.
   • Capacidade: O vetor de capacidade do modelo $v_{m,c}$ é derivado de $p(x)$ e do logit de habilidade do modelo $\text{logit}(s_{m,c})$.
   • Resíduos: O roteador calcula resíduos assimétricos: subcapacidade ($u$, modelo muito fraco) e sobrecapacidade ($o$, modelo excessivo).
   • Pontuação: Um score total $J_m$ é computado como uma distância euclidiana ponderada dos resíduos mais uma penalidade de custo:
     $$J_m = \sqrt{\sum_c (u_{m,c}^2 + \lambda o_{m,c}^2)} + \beta a_m$$
     Onde $a_m$ é o custo normalizado, $\lambda$ penaliza a sobrecapacidade e $\beta$ controla o trade-off entre custo e qualidade.
5. Decisão: O modelo com o menor $J_m$ é selecionado.

2.3 O Botão de Preferência ($r$)

O Brick introduz um botão de preferência contínuo $r \in [-1, 1]$ que permite aos operadores alternar entre perfis de "máxima qualidade" e "máxima economia". Este botão modula os quatro escalares de roteamento ($\mu, b, \beta, \lambda$) via uma lei de potência calibrada, transformando o trade-off entre custo e qualidade em um parâmetro de implementação, em vez de uma mudança no código.

3. Principais Contribuições

1. Formulação MoM: O artigo enquadra o roteamento de modelos inteiros através de pools heterogêneos como o paradigma MoM, demonstrando que ele recupera 24% do headroom alcançável entre o melhor modelo único e um oráculo teórico de três modelos.
2. Rejeição do Roteamento Superficial: Demonstra empiricamente que o roteamento baseado em domínio e em comprimento/palavras-chave falha em capturar a dificuldade intra-domínio, apresentando desempenho inferior até mesmo a uma simples linha de base "sempre-Kimi".
3. Roteador Brick: Um roteador MoM calibrado com uma representação explícita de vetor de capacidade e um botão de preferência para o usuário.
4. Eficiência Agêntica: O artigo argumenta que o roteamento de etapa única pura (como o Brick) é estruturalmente superior ao roteamento em cascata para fluxos de trabalho agênticos, pois evita o acúmulo do custo das etapas de cascata rejeitadas em cada passo de uma trajetória de agente.

4. Resultados Experimentais

Avaliado no Dataset A (5.504 consultas através de seis dimensões de capacidade):

• Precisão vs. Custo:

  • Perfil de Máxima Qualidade ($r=+1$): O Brick atinge 76,98% de precisão, superando o melhor modelo único (Kimi 2.6 com 75,02%) e todos os roteadores externos (RouteLLM, FrugalGPT, Cascade Routing). Ele o faz com um custo 28% menor ($0,022 vs $0,031 por chamada).
  • Perfil Neutro ($r=0$): Atinge 74,11% de precisão com um custo 4,71× menor do que o "sempre-Kimi", com uma perda de apenas 0,91 ponto percentual de precisão. Supera o Cascade Routing em +0,71 pp com custo comparável.
  • Perfil Baixo ($r=-0,5$): Atinge 71,62% de precisão, superando o FrugalGPT (69,42%) em +2,20 pp com custo comparável.
  • Perfil de Custo Mínimo ($r=-1$): Empata com o modelo mais barato (Qwen) em 63,17% de precisão, mas com um custo 22,15× menor do que o "sempre-Kimi".

• Latência:

  • A mediana da latência de ponta a ponta para o Brick (perfil max) cai de 51,2s (sempre-Kimi) para 22,8s. Isso ocorre porque o Brick roteia ~31% das consultas para o modelo mais rápido DeepSeek-V4-Flash, mesmo na configuração de máxima qualidade.

• Limite do Oráculo (Oracle Bound):

  • O teto teórico (Oráculo de Três Modelos) é de 83,25%. O Brick captura uma parte significativa da lacuna entre o melhor modelo único e este oráculo, embora um resíduo de 6,27 pp permaneça não extraído pelos atuais recursos de capacidade.

5. Significância e Alegações

O artigo afirma que o Brick demonstra a viabilidade do paradigma MoM como um padrão de implantação de primeira classe. Sua significância reside em:

• Validação Empírica: Provar que o roteamento baseado em um espaço de capacidade calibrado supera o roteamento heurístico e as linhas de base de modelo único.
• Flexibilidade Operacional: Fornecer um botão contínuo para operadores ajustarem o trade-off entre custo e qualidade sem necessidade de retreinamento ou mudanças de código.
• Escalabilidade Agêntica: Estabelecer que o roteamento puro é o único design que escala eficientemente para fluxos de trabalho agênticos, evitando as penalidades lineares de custo e latência inerentes ao roteamento em cascata.
• Complementaridade: Destacar que os pools de modelos oferecem conjuntos de erros complementares (ex: lidar com "recusas honestas" vs. alucinações), o que um roteador consciente da capacidade pode explorar para melhorar a confiabilidade geral do sistema.

Os autores mantêm a modéstia, reconhecendo que o resíduo da lacuna em relação ao oráculo (6,27 pp) representa informações que o roteador atual ainda não extrai, e que trabalhos futuros devem focar em suavização Bayesiana para pools esparsos e estimativa de complexidade condicionada ao domínio.