Runtime Burden Allocation for Structured LLM Routing in Agentic Expert Systems: A Full-Factorial Cross-Backend Methodology

Este artigo propõe que o roteamento estruturado de LLMs é fundamentalmente um problema de alocação de carga de tempo de execução, demonstrando através de uma avaliação fatorial completa em múltiplos backends que não existe um modo universalmente ideal, pois o desempenho é dominado por interações específicas entre o backend e a estratégia de alocação, oferecendo assim um framework prático para equilibrar correção, latência e custo em sistemas agênticos de produção.

O essencial

Imagine que você está dirigindo um táxi inteligente em uma cidade gigante cheia de diferentes tipos de passageiros: alguns querem ir para um restaurante (chat), outros para um escritório de advocacia (dev), alguns precisam de um mapa (doc) e outros querem encomendar um pacote (task).

O seu "motorista" é a Inteligência Artificial (o LLM). O seu trabalho é garantir que o motorista leve o passageiro para o lugar certo, rápido e sem quebrar o carro no caminho.

Este artigo de pesquisa diz que, até agora, as pessoas estavam focando apenas em quem é o melhor motorista (qual modelo de IA usar). Mas eles descobriram algo muito mais importante: como você entrega o endereço ao motorista (a forma como a IA escreve o destino) é tão crucial quanto o motorista em si.

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Problema: Quem carrega a mala? (A "Carga de Trabalho")

O artigo chama isso de "alocação de carga de trabalho". Pense assim:

• Modo A (O Motorista Faz Tudo): Você pede ao motorista: "Escreva o endereço completo, com nome da rua, número, CEP e coordenadas GPS, tudo em um papel perfeito." O motorista tem que pensar no destino e na caligrafia perfeita. É seguro, mas cansa o motorista e demora mais.
• Modo B (O Passageiro Ajuda): Você diz: "Apenas me diga 'Restaurante'". O motorista diz "Restaurante", e um funcionário no banco de trás (o software local) pega essa palavra e preenche o formulário completo sozinho. É mais rápido e o motorista gasta menos energia, mas... e se o motorista tiver dificuldade em entender a palavra "Restaurante" e escrever algo errado?

2. A Grande Descoberta: Não existe um "Melhor Motorista" Universal

O estudo testou três tipos de motoristas (Google Gemini, OpenAI e Llama) com quatro formas diferentes de entregar o endereço.

A conclusão chocante foi: O que funciona perfeitamente para um motorista, pode ser um desastre para outro.

• Para os motoristas "Premium" (Gemini e OpenAI): Eles são muito bons. Eles conseguem escrever o endereço completo (Modo A) com perfeição. Se você tentar economizar tempo pedindo apenas a palavra-chave (Modo B), eles ainda funcionam bem, mas às vezes erram um pouco a direção.
• Para o motorista "Rápido e Barato" (Llama): Ele é muito rápido e barato. Se você pedir o endereço completo (Modo A), ele faz um trabalho decente. MAS, se você tentar economizar e pedir apenas a palavra-chave para ele preencher depois (Modo B), ele entra em pânico! Ele escreve "Restaurante" de um jeito que o funcionário do banco de trás não entende, e o passageiro vai para o lugar errado.

A Lição: Você não pode escolher o "Modo B" (economia de tempo/dinheiro) apenas porque é mais rápido. Você precisa ver se o seu motorista específico consegue lidar com essa economia sem errar o destino.

3. A Ilusão da "Entrega Rápida" (Streaming)

Muitas pessoas acham que receber a resposta palavra por palavra (como em um chat) é mais rápido e melhor.
O estudo diz: Não para sistemas de controle.
Imagine que você precisa de uma chave para abrir uma porta. Não adianta receber a chave "pedaço por pedaço" se você só pode abrir a porta quando tiver a chave inteira.

• No mundo dos chats, ver a resposta surgindo é legal.
• No mundo dos sistemas de IA (como este), o computador só age quando tem o documento completo. Receber pedaços não ajuda a abrir a porta mais rápido; só atrasa a espera.

4. O Mapa da Decisão (O que fazer?)

Os autores criaram um guia prático para quem constrói esses sistemas:

1. Se a segurança é o mais importante: Use o "Modo A" (peça a IA para escrever tudo certinho). É mais lento e gasta mais, mas é muito menos provável que o passageiro vá para o lugar errado. Funciona bem com a maioria dos modelos.
2. Se a velocidade e o custo são o mais importante: Você pode usar o "Modo B" (pedir apenas a palavra-chave), MAS só se você tiver testado e confirmado que o seu modelo específico (seu motorista) não erra a direção com essa economia.
3. Não confie na média: Não olhe apenas a "média de sucesso". Às vezes, o sistema funciona bem para ir ao restaurante, mas falha miseravelmente quando precisa ir para o escritório de advocacia (rotas especializadas). Se você errar a rota para o advogado, o prejuízo é grande.

Resumo em uma frase

Este artigo ensina que, ao usar Inteligência Artificial para tomar decisões, não basta escolher o modelo mais inteligente; você precisa escolher a combinação certa entre o modelo e a forma como você pede a resposta, porque o que economiza tempo para um, pode causar um acidente para outro.

É como escolher entre um carro de luxo e um carro popular: o popular é mais barato e rápido, mas se você pedir para ele fazer manobras complexas sem o piloto automático (a estrutura completa), ele pode capotar. O segredo é saber qual carro aguenta qual tipo de estrada.

Resumo técnico

Resumo Técnico: Alocação de Carga de Runtime para Roteamento Estruturado de LLMs em Sistemas Expert Agênticos

1. O Problema

O roteamento estruturado em sistemas de Inteligência Artificial (IA) agênticos é frequentemente tratado erroneamente apenas como um problema de engenharia de prompts. Os autores argumentam que, fundamentalmente, trata-se de um problema de alocação de carga de runtime (runtime burden-allocation).

Em sistemas expert reais, o controlador (ou "Diretor") deve gerar um registro de controle estruturado e legível por máquina que determine o fluxo subsequente (ex: chamar uma ferramenta, consultar memória, rotear para um subsistema). O desafio não é apenas se o modelo entende a tarefa, mas como o "peso" estrutural é distribuído entre o modelo generativo e o software determinístico local. As decisões de design atuais (ex: exigir JSON direto do modelo vs. gerar código compacto e reconstruir localmente) impactam drasticamente a precisão, a latência e o custo, mas essas interações são pouco compreendidas em cenários de produção com backends heterogêneos.

2. Metodologia

O estudo propõe uma nova metodologia baseada em um benchmark fatorial completo para avaliar como diferentes perfis de "empacotamento de runtime" afetam o desempenho.

• Estrutura Experimental:

  • Fatores: 4 Modos de Runtime $\times$ 3 Famílias de Backend $\times$ 2 Configurações de Restrição $\times$ 2 Modos de Transporte.
  • Total: 48 combinações de implantação avaliadas.
  • Volume: 15.552 solicitações roteadas (324 por combinação).
  • Backends Testados: OpenAI, Google Gemini e Llama (modelos de código aberto).

• Dimensões de Alocação de Carga:

  1. Carga de Serialização: Quanto o modelo precisa construir a estrutura final (ex: JSON completo) vs. emitir um código intermediário compacto.
  2. Semântica de Transporte: Uso de streaming (token a token) vs. não-streaming (resposta completa).
  3. Localização da Realização da Estrutura: Se a estrutura final é gerada diretamente pelo modelo ou reconstruída por software determinístico local.

• Modos de Runtime Avaliados:

  • MJ (Minimal JSON): Orçamento de tokens baixo, emissão direta de JSON.
  • SJ (High-budget JSON): Orçamento de tokens alto, emissão direta de JSON.
  • MJS (JSON + Streaming): Emissão direta de JSON com transporte em streaming.
  • MCLR (Compressed Local Reconstruction): Emissão de código compacto (texto simples) com reconstrução determinística local para o JSON final.

• Métricas Principais:

  • Conformidade de Formato (FC), Precisão de Roteamento (RA), Retenção de Estado (SR), Latência (p50/p95) e Consumo de Tokens.
  • Métrica derivada: WLC (Workflow Lower-Bound Completion), que estima a taxa mínima de conclusão segura do fluxo de trabalho.

3. Contribuições Principais

1. Reenquadramento Teórico: Propõe que o roteamento estruturado deve ser visto como um problema de alocação de carga entre o modelo e o software circundante, não apenas como uma questão de capacidade do modelo.
2. Princípio de Compatibilidade: Estabelece que não existe um "melhor modo" universal. O desempenho é dominado por interações backend $\times$ modo. Um modo eficiente em um backend pode falhar catastróficamente em outro.
3. Metodologia de Avaliação: Introduz um protocolo experimental fatorial completo que isola o impacto do "empacotamento de runtime" da identidade do modelo, permitindo que engenheiros tomem decisões de implantação baseadas em compatibilidade específica.
4. Diretrizes de Implantação: Oferece regras práticas para navegar no trade-off entre precisão, custo e latência em sistemas de produção.

4. Resultados Chave

• Interação Backend $\times$ Modo é o Fator Dominante:

  • A análise estatística (ANOVA) mostrou que a interação entre o backend e o modo de runtime é um determinante de primeira ordem para a precisão (RA) e conformidade (FC). O tamanho do efeito (partial eta squared) foi extremamente alto (0,960 para RA), indicando que a escolha do modo depende criticamente do backend.
  • Gemini e OpenAI: Mantêm alta precisão com emissão direta de JSON (MJ/SJ). O modo MCLR (reconstrução local) oferece ganhos de eficiência, mas com quedas significativas na precisão (ex: queda de ~23-27 pontos percentuais em RA).
  • Llama: Apresenta a maior incompatibilidade. Enquanto MJ/SJ mantêm ~82% de precisão, o modo MCLR colapsa para 22,84% de precisão e 53,40% de conformidade, apesar de ser o backend mais rápido em latência absoluta.

• Eficiência vs. Precisão:

  • O modo MCLR é consistentemente o mais eficiente em termos de tokens e latência em todos os backends.
  • No entanto, essa eficiência é "comprada" com perda de precisão. Em backends como Llama, a reconstrução local introduz instabilidade semântica que destrói a utilidade do roteamento.

• Streaming e Restrições são Secundários:

  • O transporte em streaming (MJS) teve impacto negligenciável na precisão do roteamento e apenas um efeito secundário na latência total. Para tarefas de controle estruturado, a latência "acionável" (tempo até a resposta completa) é mais relevante que o tempo até o primeiro token.
  • A relaxação de orçamento de tokens (SJ vs. MJ) teve pouco impacto na precisão, sugerindo que o problema não é o tamanho do prompt, mas a forma de realização da estrutura.

• Fragilidade em Rotas Especialistas:

  • A precisão agregada pode mascarar falhas críticas. Rotas de "chat" permaneceram robustas, mas rotas de "desenvolvimento" (dev) sofreram colapsos severos em modos de reconstrução local (MCLR), especialmente no Llama (0% de precisão em algumas condições).

5. Significado e Implicações

• Para Engenheiros de Sistemas Expert: O estudo demonstra que otimizar apenas o modelo ou o prompt é insuficiente. A decisão de como a estrutura é realizada (diretamente pelo modelo vs. reconstruída localmente) é uma variável de design de primeira classe.
• Regras de Implantação Sugeridas:
  1. Preservar emissão direta de JSON quando a precisão e a integridade do estado são críticas e o backend (como Gemini/OpenAI) suporta bem essa carga.
  2. Usar reconstrução local comprimida (MCLR) apenas quando a eficiência é a prioridade máxima e a compatibilidade foi validada especificamente para aquele backend.
  3. Não superestimar o streaming em tarefas de controle compacto, pois a execução downstream depende do registro completo.
• Mudança de Paradigma: O trabalho move a discussão de "qual modelo é o melhor" para "qual perfil de alocação de carga coloca este backend específico na fronteira ideal de precisão-custo-latência para esta aplicação".

Em suma, o artigo fornece uma base empírica e metodológica para projetar sistemas de roteamento robustos, alertando que a eficiência de um método não é universal, mas sim condicionada à compatibilidade semântica entre o perfil de runtime e a família de modelos utilizada.