Sistemas de IA compostos: Arquitetar soluções empresariais confiáveis multimodelo

Confiar em um único modelo de fronteira para executar IA empresa raramente funciona na produção. O envio de consultas de negócios complexas e multi-passos diretamente para um modelo emblemático proprietário leva a custos imprevisíveis, altas latências de cauda e taxas de alucinações que falham acordos de nível de serviço (SLAs).

Executar IA de forma confiável na produção se resume à engenharia de sistemas distribuídos em vez de engenharia rápida. Configurações confiáveis usam sistemas de IA compostos: arquiteturas que coordenam modelos especializados (LLMs de fronteira, modelos de linguagem de pequeno porte e motores de incorporação específicos de domínio) ao lado de lógica de negócios determinística, roteadores dinâmicos e camadas de verificação.

Em Lidex Soluções Digitais, construímos dados empresariais e aplicamos plataformas de IA que tratam modelos de fundação como microservices probabilísticos em funcionamento dentro de sistemas de software determinísticos. Este guia abrange como as equipes de engenharia constroem e escalam sistemas de IA compostos para ambientes de produção.

---

Por que os LLMs monolíticos atingiram limites na produção empresarial

Pesquisadores do laboratório Berkeley Artificial Intelligence Research (BAIR) e Databricks mostraram que os parâmetros do modelo de escalagem produzem retornos decrescentes em fluxos de trabalho empresariais complexos. Enquanto um modelo de fronteira escreve prosa convincente, ele se depara com três problemas estruturais principais na execução de operações de negócios:

1. Propagação de erro estocástico: Em fluxos de trabalho multi-step, cada passo probabilístico compõe a chance de falha. Uma alucinação intermédia corrompe todas as decisões a jusante, extracção ou recorte de código gerado.
2. Opacidade da caixa preta: Quando um modelo grande interpreta mal uma regra de conformidade ou traduz um código interno de ERP, encontrar a causa raiz é difícil. Os engenheiros lutam para isolar se o problema foi má recuperação, mal-entendido semântico, ou erros de formatação de saída.
3. Degradação da janela de contexto: Janelas de contexto grandes frequentemente sofrem de degradação da atenção "perdida no meio", acompanhada por custos de computação quadrática e maior latência ao ingerir grandes cargas.

A telemetria de produção reflete esses problemas. No seu relatório de 2024 sobre Estado dos Dados e IA, a Databricks observou que mais de 60% das implantações de IA generativas das empresas utilizam a Geração Aumentada por Retrieval (RAG) e mais de 30% dependem de cadeias compostas multi-step. A arquitetura em torno do modelo impulsiona o desempenho prático, não a contagem de parâmetros sozinho.

FactSet documentou esta dinâmica em fluxos de trabalho do mercado financeiro. Ao testar consultas complexas de análise financeira, enviar prompts diretamente para um modelo de fronteira comercial produziu 55% de precisão. A decomposição da carga de trabalho em um oleoduto composto com motores de recuperação especializados, analisadores de dados determinísticos e nós de validação modular elevaram a precisão para 85%. Esse foi um ganho de 30 pontos percentuais alcançado sem reciclagem ou ajuste dos pesos de base.

---

Redução da latência e dos custos com roteamento dinâmico e cascatas

Um erro comum nas implementações de IA empresarial é tratar todo o tráfego igualmente. Enviando consultas simples como buscas de documentos ou extrações de campos para modelos high-end como Claude 3.5 Sonnet ou GPT-4o API orçamentos e aumenta a latência da cauda. Ao mesmo tempo, executar todas as tarefas operacionais em modelos de linguagem pequena (SLMs) leva a falhas em casos de borda e raciocínio complexo.

Sistemas compostos abordam este trade-off com roteamento dinâmico e cascatas de modelo. Frameworks como RouteLLM (desenvolvido por LMSYS, UC Berkeley e Anyscale, publicado em ICLR 2025) colocam roteadores de preferência leves na borda antes de consultas baterem em um motor de inferência.

Esses roteadores avaliam a complexidade da consulta através da incorporação de similaridade, causal LLM marcadores, ou classificadores de fatorização de matriz. Os pedidos são então encaminhados para um modelo local de baixo custo (como um modelo 8B de pesos abertos ou um modelo destilado) API) ou um motor de raciocínio de fronteira:

• Redução de custos em benchmarks: RouteLLM reduziu os custos em mais de 85% em MT-Bench, 45% em MMLU e 35% em GSM8K em comparação com o uso de GPT-4 sozinho, mantendo 95% da qualidade de referência do modelo de fronteira.
• Envio seletivo: Um roteador matricial-factorization manteve 95% da qualidade da fronteira, enviando apenas 26% das solicitações para o modelo caro.

Incoming Request
       │
       ▼
┌──────────────────────────────────────────────┐
│   Edge Classifier / Intent Router (<100ms)   │
│ (Matrix Factorization / Embedding Similarity) │
└──────┬───────────────────────────────┬───────┘
       │ (Score < Threshold)           │ (Score >= Threshold)
       ▼                               ▼
┌───────────────────────────┐   ┌───────────────────────────┐
│  Tier 1 / Tier 2 SLM      │   │  Tier 3 Frontier LLM      │
│  - Fast classification    │   │  - Complex synthesis      │
│  - Structured extraction  │   │  - Multi-step reasoning   │
│  - $0.05-$0.60 / 1M tok   │   │  - $2.50-$15.00 / 1M tok  │
└───────────────────────────┘   └───────────────────────────┘

Na prática, as plataformas organizam isso em uma topologia de roteamento de três níveis:

1. Nível 1 (menos de 100ms, 0,05 a 0,15 dólares por milhão de fichas): Classificadores locais incorporados ou modelos de parâmetros 3B a 8B em execução na premissa ou na inferência dedicada sem servidor. Este nível gerencia classificação de intenção, extração de metadados e roteamento de regras.
2. Nível 2 (raciocínio médio, de 0,15 a 0,60 dólares por milhão de fichas): Modelos destilados ou quantizados como GPT-4o-mini ou Claude 3.5 Haiku que lida com transformações estruturadas de dados, resumo intermediário e etapas de orquestração.
3. Nível 3 (nível de fronteira, $2,50 a $15,00 por milhão de fichas): Modelos de fundação grandes, chamados apenas quando ambiguidade de consulta ou dificuldade de tarefa excede um limiar de incerteza calibrado.

---

Otimização declarativa: substituição de prompts manuais por DSPy

Arquiteturas monolíticas normalmente dependem de longas prompts de sistema embalados com heurísticas de linguagem natural, exemplos de poucos tiros, e instruções de formatação. Quando uma equipe muda de modelo base ou se move de um comercial API para uma instância privada de pesos abertos, esses modelos prompt tendem a quebrar, necessitando de extensos testes manuais e ajustes prompt.

As configurações compostas substituem o pedido ad hoc com frameworks de programação declarativos, tais como o DSPy (Declarativo Self-imelhoring Python) de Stanford NLP. DSPy estrutura interações de modelos de linguagem como um código de software de estruturas de compilador:

• Assinaturas: Interfaces abstratas que especificam campos de entrada e saída (como contexto, pergunta -> resposta, citação) independentemente da redação exata do prompt.
• Predictors: Módulos que aplicam estratégias de execução sobre assinaturas, como dspy. ChainOf Thought ou 'dspy'.React.
• Otimizadores e teleprompters: Compiladores como MIPROv2 e Adaptação Genética de Prompt (GEPA) que avaliam módulos contra conjuntos de dados rotulados. Esses otimizadores geram e aperfeiçoam instruções rápidas, selecionam exemplos úteis de poucos tiros e afinam pesos de pipeline usando otimização Bayesiana e aprendizado de reforço.

Pesquisas do projeto DSPy indicam que os pipelines multi-estágios compilados pontuam 10% a 20% mais em benchmarks de precisão do que os prompts escritos manualmente, tornando as migrações de modelos simples.

As equipes têm utilizado essa abordagem para reduzir os gastos operacionais em escala. Em um sistema de alto volume, o Shopify usou DSPy e GEPA para automatizar a extração de metadados de catálogo de produtos para comerciantes. A otimização programática de modelos menores para alcançar saídas de nível de fronteira resultou em uma redução de custos de aproximadamente 550x em comparação com chamadas de fronteira não otimizadas. Da mesma forma, o Dropbox integrou o DSPy em sua plataforma Dash para refinar juízes de avaliação offline e pontuação de relevância.

---

Forçando a confiabilidade através de guardiões determinísticos e sandboxes

Sistemas que alimentam fluxos de trabalho de ERP, aplicações de fintech ou serviços de saúde regulamentados não podem depender de saída probabilística sem restrições. Arquiteturas de IA compostas reduzem o risco por meio do acoplamento de modelos neurais com sistemas determinísticos e simbólicos, semelhantes ao modo como AlphaGeometry de DeepMind combina modelos de linguagem gerativa com motores de dedução simbólica.

As equipes de engenharia normalmente constroem três mecanismos de verificação nesses gasodutos:

1. Motores de decodificação restritos

Em vez de pedir a um modelo para retornar válido JSON e esperando que ela cumpra, bibliotecas como Outlines, Instrutor e Pydantic impõem expressões e esquemas regulares durante o loop de decodificação. Ao mascarar logits no tempo de geração, tokens que violam a gramática recebem probabilidade zero. Isso garante a conformidade de sintaxe para esquemas e consultas de banco de dados antes que os tokens sejam emitidos.

2. Ciclos de verificação isolados

Uma regra básica de projeto para sistemas compostos é evitar deixar um modelo avaliar sua própria saída dentro do mesmo contexto. Quando o contexto deriva, o modelo tende a confirmar seus próprios erros. Em vez disso, a arquitetura passa a saída gerada para etapas de verificação independentes:

• Sintaxe e linters semânticos: Saídas de código e consulta são executadas através de um analisador, compilador ou banco de dados isolado EXPLAIN check.
• Verificadores de inferência de linguagem natural (NLI): As declarações geradas são passadas para modelos dedicados de NLI que comparam reivindicações diretamente contra passagens de fonte recuperadas. Se o escore de aterramento cair abaixo de um limite definido (como 0,95), o gasoduto rejeita a resposta e desencadeia um fluxo de retrocesso ou tentativa direcionada.

3. Execução estatal durável

As tarefas em várias etapas precisam de proteção contra tempo limite, limites de taxa e falhas de rede. Ao gerenciar fluxos de trabalho multi-agente através de orquestradores de máquinas de estado, como Temporal.io ou LangGraph, os sistemas mantêm pontos de controle, garantem idempotência e fornecem gatilhos de revisão humanos para processos de longo prazo.

---

Desvinculando orquestração do tempo de execução para maximizar o rendimento

Como aplicações adotam configurações multi-agentes, a orquestração do fluxo de trabalho de acoplamento diretamente ao serviço do modelo cria um gargalo maior. Quando os serviços de aplicação chamam os endpoints do modelo síncrono, os servidores de inferência ficam inativos sempre que um agente pausa para fazer um externo API request, consulte um banco de dados ou aguarde a verificação determinística. Este tempo ocioso liga a memória da GPU e impulsiona as latências do P99.

Pesquisas do projeto Murakkab ("Murakkab: Towards Resource-Efficient Compound AI Systems", publicado em ACM e arXiv) indicam que os sistemas de backend devem separar gráficos de orquestração de tempos de execução de computação. Ao modelar fluxos de trabalho de agentes como grafos acíclicos direcionados (DAGs), agendadores de clusters podem fazer pedidos em lote de ferramentas, programar inferências é executado dinamicamente e compartilhar memória GPU através de trabalhos.

As avaliações no papel Murakkab mostraram até 3,4 vezes mais tempo de conclusão do fluxo de trabalho e aproximadamente 4,5 vezes maior computação e eficiência energética sobre implementações de IA compostas padrão.

Para engenheiros de sistemas, o takeaway prático é evitar gerenciar fluxos de trabalho de agentes através de chamadas HTTP síncronas. Usando corretores de mensagens assíncronas como Kafka ou Redis Fluxos para eventos de agentes de fila e buffer mantêm as alocações da GPU de pararem enquanto as tarefas aguardam por APIs de terceiros.

---

Uma planta de cinco camadas para IA composto empresarial

Mudar de protótipos para sistemas de produção confiáveis requer práticas de engenharia de software padrão. Uma configuração de IA composta robusta geralmente usa cinco camadas separadas:

1. Camada dinâmica de roteamento: Avalia pedidos de entrada e cascatas funcionam em classificadores locais, SLMs de nível médio e modelos de fronteira usando frameworks como RouteLLM.
2. Camada declarativa do programa: Substitui strings de prompt manual com assinaturas digitadas e execução de otimização compilada usando DSPy.
3. Contexto e camada de recuperação: Combina pesquisa densa e esparsa (híbrido RAG) às respostas do modelo de base nas fontes de dados das empresas.
4. Camada de verificação determinística: Força a conformidade do esquema através do mascaramento de logits (via ferramentas como Outlines ou Pydantic), executa linters de sintaxe e verifica a atribuição factual através de verificadores NLI dedicados.
5. Camada de tempo de execução durável: Rastreia o estado de fluxo de trabalho com arquitetura orientada a eventos e motores como Temporal ou LangGraph para evitar baias de computação, garantir indempotência e lidar com repetições de forma limpa.

A engenharia de software sempre se concentrou em isolar o comportamento variável por trás de interfaces confiáveis. Os modelos de fundação fornecem compreensão flexível da linguagem, mas arquiteturas compostas fornecem o controle, custos previsíveis e confiabilidade operacional necessários para executá-los em sistemas empresariais.