Resumo Técnico: Opti-Q: Um Framework de Otimização Baseado em Restrições para Planejamento de Perguntas Multi-LLM

1. Declaração do Problema

A implantação de Grandes Modelos de Linguagem (LLMs) para Resposta a Perguntas (QA) enfrenta desafios significativos em relação ao não determinismo, perfis de recursos heterogêneos (custo financeiro, latência, energia) e desempenho variável entre diferentes tipos de perguntas. Embora trabalhos recentes sugiram que a colaboração coordenada multi-LLM pode superar modelos únicos "melhores", estratégias de execução ingênuas (por exemplo, sempre consultar todos os modelos ou usar cascata fixa) frequentemente levam ao uso ineficiente de recursos, custos mais altos e qualidade de resposta subótima.

Frameworks de orquestração atuais (ex: LangChain, DSPy) frequentemente dependem de fluxos de trabalho roteirizados por desenvolvedores ou decisões miopes e dinâmicas feitas no momento da execução, sem considerar as consequências subsequentes. Há uma falta de sistemas que tratem a orquestração multi-LLM como um problema de planejamento de consulta baseado em custo e multi-objetivo, onde o plano de execução ideal (sequencial, paralelo ou híbrido) é selecionado antes da execução com base em restrições especificadas pelo usuário (orçamento, latência, energia) e a qualidade desejada da resposta (QoA).

2. Metodologia: O Framework OPTI-Q

O OPTI-Q é um otimizador baseado em custo e inspirado em bancos de dados que implementa um paradigma de "planejar antes de executar" para QA multi-LLM. Ele modela o problema como uma tarefa de Otimização Multi-Objetivo (MOO), onde o objetivo é encontrar planos Pareto-ótimos equilibrando QoA contra custo financeiro, latência e energia.

A. Modelagem e Formalização

• Modelo de Pergunta: Uma pergunta $Q$ é definida por um prompt, tópico e restrições do usuário ($F_{max}, L_{max}, E_{max}, QoA_{min}$) e um vetor de pesos $W$ para priorização de objetivos.
• Modelo de Plano: Planos são representados como Grafos Acíclicos Dirigidos (DAGs) onde os nós são invocações de LLM (operadores físicos) e as arestas representam o fluxo de dados.
  • Operadores Sequenciais: Passam respostas intermediárias como contexto para modelos subsequentes.
  • Operadores Paralelos: Executam múltiplos modelos simultaneamente.
  • Operadores de Mistura (Blending): Mesclam saídas de ramos paralelos usando um modelo "misturador" dedicado.
• Objetivo de Otimização: Maximizar $[QoA(\pi), -Financeiro(\pi), -Latência(\pi), -Energia(\pi)]$ sujeito às restrições do usuário.

B. Componentes Principais

1. PERFDB (Catálogo de Estatísticas):

   • Um banco de dados de desempenho populado offline e incrementalmente a partir de benchmarks e rastros de execução.
   • Armazena estatísticas (QoA, custo, latência, energia) para LLMs individuais e subplanos compostos, indexados pelo contexto de execução (tópico, tipo de operador, modelo).
   • Permite a estimativa pré-execução das métricas do plano sem rodar o plano. Ele lida com a estocasticidade armazenando estimativas de variância e intervalos de confiança.

2. Estimativa de Custo-Benefício:

   • Estimativa de Tokens: Prediz contagens de tokens de entrada/saída baseando-se em tokenizadores específicos de cada modelo e comprimentos históricos de saída para estimar custos.
   • Estimativa de QoA: Utiliza uma busca condicionada ao tópico no PERFDB. Para planos compostos, aplica fatores de efeito relativo multiplicativos (para etapas sequenciais) e fatores de mudança relativa de média (para mistura) derivados de rastros históricos para estimar a qualidade do plano completo.
   • Estimativa de Recursos: Calcula o custo financeiro (fixo + variável por token), energia (proporcional aos tokens) e latência (linear com o volume de tokens, ramos paralelos levam o tempo máximo).

3. Geração de Planos e Busca:

   • Codificação: Planos são codificados de forma compacta como um mapa de conectividade (matriz de adjacência) e um vetor de atribuição de modelos.
   • Espaço de Busca: O espaço de possíveis planos é combinatório e NP-difícil de otimizar exaustivamente.
   • Motores de Otimização: O OPTI-Q suporta um motor "plugável" com três estratégias:
     • Programação Dinâmica (DP): Solucionador exato para instâncias pequenas; utiliza poda para gerenciar a explosão do espaço de estados.
     • Hill Climbing (HC): Heurística gulosa leve para busca local rápida.
     • NSGA-II: Um algoritmo evolucionário multi-objetivo usado como padrão para grandes espaços de planos para aproximar a fronteira de Pareto.
   • Seleção: O otimizador gera um conjunto de planos não dominados viáveis. O plano final é selecionado com base nos pesos do usuário $W$ aplicados aos objetivos normalizados.

C. Implementação

• Sistema: Framework modular integrando um otimizador com um motor de execução.
• Modelos: Testado com cinco modelos de código aberto (Gemma-3:27B, LLaMA3-ChatQA, Qwen2.5, Phi-4, Mistral) rodando localmente via Ollama.
• Mistura (Blending): Utiliza o Gemma-3:27B como o misturador designado, superando componentes especializados como o GenFuser na validação.
• Prompting: Emprega prompting Zero-Shot com prompts específicos de contexto e mistura para guiar o comportamento do modelo.

3. Principais Contribuições

1. Formulação de Custo/Benefício: Uma formalização do planejamento de QA multi-LLM como um problema de otimização multi-objetivo restrito, equilibrando explicitamente QoA, custo, latência e energia.
2. Otimizador Baseado em Estatísticas: Um sistema que enumera e poda fluxos de trabalho sequenciais/paralelos/híbridos, estimando qualidade e custos de recursos antes da execução usando um catálogo de estatísticas histórico (PERFDB).
3. Sistema Integrado: Um protótipo funcional que roteia perguntas dinamicamente entre LLMs de código aberto, selecionando grafos de execução ótimos em tempo real.

4. Resultados Experimentais

O framework foi avaliado nos benchmarks MMLU-Pro (múltipla escolha) e SimpleQA (aberto) contra quatro baselines de estado da arte (ThriftLLM, LLM-Ensemble, FrugalGPT, LLM-Blender).

• Ganhos de Desempenho: Sob orçamentos especificados pelo usuário, o OPTI-Q melhorou a QoA média em ≈58% no SimpleQA e ≈41% no MMLU-Pro em comparação com os baselines mais fortes conscientes de orçamento em custos equivalentes por pergunta.
• Escalabilidade: O NSGA-II forneceu o melhor equilíbrio entre escalabilidade e qualidade, mantendo uma qualidade de fronteira de Pareto próxima à de referência com tempos de planejamento na casa de dezenas de segundos (ex: 21s para $k=5$ operações).
• Robustez à Escassez de Dados: Em cenários de "cold-start" (cobertura de Nível 0 do PERFDB), o OPTI-Q ainda superou os baselines. À medida que os dados históricos aumentaram (Níveis 1–4), a QoA melhorou significativamente (ex: +66,7% no MMLU-Pro) e os erros de estimativa de recursos diminuíram drasticamente.
• Aderência ao Orçamento: O sistema manteis uma alta aderência ao orçamento (88–96%), com excessos impulsionados principalmente pelo custo, não pela latência.
• Comparação com APIs Comerciais: O OPTI-Q alcançou maior QoA que modelos comerciais (ex: Claude Opus 4.6, GPT 5.4) no SimpleQA, custando significativamente menos (37,8× e 14,5× menos, respectivamente, ao contabilizar custos de servidores externos). No MMLU-Pro, alcançou qualidade competitiva (0,82 vs. 0,871 para Gemini 3.5 Flash) por uma fração do custo.

5. Significância e Alegações

O artigo alega que o planejamento no estilo de banco de dados produz melhores trocas de qualidade-recurso para QA multi-LLM em comparação com a orquestração dinâmica/míope ou ensembles fixos.

• Mudança de Paradigma: Demonstra que tratar a orquestração de LLM como um problema de planejamento declarativo, em vez de uma tarefa de script procedural, permite uma adaptação dinâmica específica para cada pergunta que maximiza a utilidade sob restrições.
• Viabilidade Prática: Os resultados sugerem que o planejamento estruturado e baseado em estatísticas fornece uma base prática para a orquestração adaptativa de LLM, permitendo que sistemas equilibrem desempenho e eficiência sem depender de APIs comerciais caras e de alta capacidade.
• Potencial Futuro: Os autores postulam que esta abstração de "planejar antes de executar" pode se estender além do QA para fluxos de trabalho de Geração Aumentada de Recuperação (RAG) e agentes mais ricos, desde que novos operadores possam ser caracterizados com perfis de custo-benefício semelhantes no catálogo de estatísticas.