Resumo Técnico: BatchDAG

1. Definição do Problema

Os Modelos de Linguagem de Grande Escala (LLMs) são excelentes na análise de documentos individuais, mas têm dificuldade com consultas analíticas exaustivas e trans-entidade sobre conjuntos de dados de escala empresarial. Quando aplicados a tarefas que exigem o processamento de centenas ou milhares de entidades (por exemplo, analisar 50.000 transcrições de reuniões), os loops de agente único padrão enfrentam três limitações críticas:

• Estouro da Janela de Contexto: A agregação de resultados para milhares de entidades excede até mesmo as maiores janelas de contexto comerciais (ex: 1,25 milhão de tokens para 50 mil reuniões).
• Perda de Atribuição por Entidade: A busca global de top-$N$ retorna os resultados mais relevantes entre todas as entidades, mas falha em atribuir os achados a negócios ou reuniões específicos, tornando impossível responder a perguntas do tipo "para cada entidade".
• Latência Linear: Chamadas de ferramentas sequenciais fazem com que a latência cresça proporcionalmente com o número de entidades, tornando a análise de grandes corpora impraticável devido à lentidão.

Frameworks existentes (ex: ReAct, LangChain) delegam o planejamento da execução ao LLM em cada etapa, herdando gargalos sequenciais e falhando em suportar o paralelismo por nível de entidade necessário para a análise de corpus transversais.

2. Metodologia: Arquitetura BatchDAG

O BatchDAG aborda essas limitações decompondo o problema em uma fase de planejamento e uma fase de execução determinística. O sistema opera em três fases distintas:

Fase 1: Planejamento (DAG gerado por LLM)

Um LLM planejador recebe a consulta em linguagem natural do usuário, um esquema dos fontes de dados disponíveis e uma definição de tipos de operação. Em vez de gerar uma cadeia de pensamento linear, o planejador produz um Grafo Acíclico Dirigido (DAG) Tipado.

• Prompting Baseado em Objetivos: O planejador é guiado por uma arquitetura de prompt "baseada em objetivos" que descreve as características de custo e modelos de dados das operações, em vez de depender de listas exaustivas de regras ou exemplos de poucos disparos (few-shot). Isso permite que o LLM raciocine a partir de princípios fundamentais sobre quais operações compor.
• Restrições de Saída: O planejador gera um DAG em JSON estruturado com etapas tipadas e especificações de entrada explícitas (ex: referências diretas, junções de mesclagem). Um "filtro de especificação segura" remove campos desconhecidos para evitar que parâmetros alucinados quebrem o sistema.

Fase 2: Execução (Motor Determinístico)

Um motor determinístico avalia o DAG usando paralelismo de onda topológica.

• Operações Tipadas: O DAG consiste em seis tipos de operação: sql, search, transform, fan out, analyze e compare.
  • Custo Zero de LLM: sql, search, transform e compare executam via backends determinísticos (DB Relacional, Vector DB, Python Puro), exigindo zero chamadas de LLM.
  • Custo de LLM: Apenas fan out (análise por entidade) e analyze (agregação) invocam o LLM.
• Fluxo de Dados Inter-Etapas Estruturado: As etapas passam linhas JSON estruturadas entre si, nunca resumos em prosa. Isso preserva a procedência, permite junções/filtros reais no estilo banco de dados entre as etapas e evita alucinações a jusante.
• Loteamento Consciente da Entidade (Entity-Aware Batching): Uma otimização chave onde as linhas são agrupadas por entidade lógica (ex: ID da reunião) antes da etapa de fan out. Isso garante que cada chamada de LLM processe um contexto de entidade completo em vez de linhas fragmentadas, reduzindo as chamadas de LLM em até 47× comparado ao loteamento ingênuo por linha.
• Execução em Ondas: Etapas independentes executam em ondas paralelas. Etapas de fan out geram tarefas filhas paralelas com semântica de tentativa de reexecução (retry) por lote (se um lote falhar, apenas esse lote é tentado novamente).

Fase 3: Síntese

Um LLM de síntese compila os resultados estruturados do DAG em uma resposta final coerente com citações por entidade.

3. Principais Contribuições

1. Formalismo de DAG Tipado: Um sistema para decompor consultas analíticas ad-hoc em operações compostáveis com fluxo de dados inter-etapas estruturado, separando o planejamento da execução.
2. Loteamento Consciente da Entidade: Um algoritmo que agrupa dados por entidade lógica antes do fan-out, alcançando uma redução de 47× nas chamadas de LLM enquanto garante um contexto holístico.
3. Arquitetura de Planejamento Baseada em Objetivos: Um design de prompt que supera regras exaustivas e exemplos de poucos disparos ao raciocinar sobre custos de operação e modelos de dados.
4. Implantação em Produção: Um relatório sobre a implantação do BatchDAG na Brevian.ai, processando consultas sobre mais de 50.000 reuniões com custos e latência mensurados.
5. Avaliação Empírica: Um estudo controlado demonstrando que DAGs gerados automaticamente alcançam qualidade comparável a pipelines projetados por especialistas, com maior procedência e redução de alucinações.

4. Resultados Experimentais

Experimentos foram conduzidos em um conjunto de dados de desenvolvimento (46 reuniões, 62 negócios) e dados de produção (mais de 50.000 reuniões).

• Corretude do Planejador: Em 300 chamadas de planejamento, o sistema alcançou uma taxa de DAG válido de 98,8%.
• Qualidade da Resposta: Em 12 consultas intensivas em transcrições, o BatchDAG alcançou uma pontuação média de qualidade de 3,74/5, comparável a uma linha de base projetada por especialistas (S5b, 3,25/5) e superando significativamente um agente ReAct (S3, 3,09/5, $p<0,01$).
• Procedência: O BatchDAG alcançou uma taxa de evidência de transcrição de 77%, significativamente superior à linha de base (46–60%), garantindo respostas auditáveis.
• Controle de Alucinação: Um estudo de ablação mostrou que o uso de intermediários JSON estruturados reduziu as alucinações em 27% em comparação com resumos em prosa (embora a significância estatística tenha sido marginal, $p=0,107$, a tendência foi consistente).
• Eficiência:
  • Latência: O BatchDAG processou uma análise de 3.000 negócios em cerca de 60 segundos, comparado ao tempo teórico de um agente sequencial de cerca de 100 minutos.
  • Custo: Os custos por consulta variaram de $0,02 (apenas SQL) a $0,24 (fan-out intensivo em transcrições). Comparado a um pipeline fixo, o BatchDAG projetou uma vantagem de custo anual de 6,2× em uma carga de trabalho de consultas mistas.

5. Significância e Alegações

O artigo posiciona o BatchDAG não primariamente como uma melhoria de precisão sobre pipelines otimizados manualmente, mas como uma camada de orquestração de propósito geral. Sua significância reside em:

• Eliminação da Engenharia de Pipeline: Substitui a necessidade de projetar múltiplos fluxos de trabalho manuais para diferentes tipos de consulta por um único sistema que gera a estratégia de execução apropriada a partir de linguagem natural.
• Escalabilidade: Ao restringir o uso de LLM a etapas específicas de fan out e analyze e aproveitar backends determinísticos para o restante, permite a análise escalável sobre conjuntos de dados empresariais que seriam excessivamente grandes ou caros para processar de outra forma.
• Mudança Arquitetônica: A percepção central é que, para cargas de trabalho analíticas entre entidades, o LLM deve planejar, não executar. O sistema alcança alta validade e qualidade ao tratar o LLM como um compilador para grafos de execução, em vez de um executor direto de cada etapa.

Os autores observam limitações, incluindo a falta de um benchmark estabelecido para consultas entre entidades, a ausência de uma "fase de sondagem" para validar DAGs antes da execução total e a incapacidade atual de estender dinamicamente os DAGs durante a execução. No entanto, o sistema já está em produção, processando milhares de reuniões com alta confiabilidade e eficiência de custo.