Além do RAG: Por que os agentes multietapas estão resolvendo o dilema dos dados corporativos

Para muitas empresas, a promessa de insights baseados em IA está a atingir um muro estrutural. Embora a Geração Aumentada de Recuperação (RAG) tenha se tornado o padrão para conectar Modelos de Linguagem Grande (LLMs) a dados privados, ela está se mostrando cada vez mais inadequada para questões de negócios complexas do mundo real.

Uma nova pesquisa do Databricks sugere que a limitação não é a inteligência dos modelos em si, mas sim a arquitetura usada para consultá-los. O estudo destaca uma mudança crítica: abandonar a recuperação em um único turno e adotar fluxos de trabalho de agente em várias etapas.

O problema dos “dados híbridos”

A maior parte da inteligência de negócios requer a conexão de dois mundos diferentes:
1. Dados Estruturados: Números precisos, números de vendas e tabelas relacionais (SQL).
2. Dados não estruturados: Avaliações de clientes, trabalhos acadêmicos e documentos de suporte.

Um sistema RAG padrão foi projetado para este último. Ele é excelente para encontrar texto que “pareça” uma consulta, mas tem dificuldade para executar filtros matemáticos precisos ou unir dados em diferentes formatos.

“RAG funciona, mas não é escalável”, diz Michael Bendersky, Diretor de Pesquisa da Databricks. “Se você quiser entender por que há queda nas vendas, terá que ajudar o agente a ver as tabelas e os dados de vendas. Seu pipeline RAG se tornará incompetente nessa tarefa.”

Arquitetura vs. Inteligência: a lacuna de 21%

Para provar que o problema está na forma como os dados são acessados, e não na inteligência do modelo, a Databricks conduziu uma série de testes usando o benchmark STaRK (abrangendo produtos da Amazon, Microsoft Academic Graph e dados biomédicos).

Eles compararam um sistema RAG de giro único de alto desempenho e última geração com uma abordagem de agente em várias etapas. Mesmo ao usar um modelo de fundação significativamente mais forte, o sistema RAG de volta única perdeu por:
* 21% na área acadêmica.
* 38% no domínio biomédico.

Esta lacuna de desempenho demonstra que mesmo o modelo mais “inteligente” não consegue compensar uma arquitetura de recuperação que é fundamentalmente incapaz de preencher a lacuna entre uma planilha e um documento de texto.

Como funciona o “Agente Supervisor”

A solução da Databricks, o Agente Supervisor, afasta-se da ideia de “recuperação híbrida” (tentando mesclar embeddings e tabelas) e, em vez disso, trata o problema como orquestração de ferramentas. O agente funciona através de três capacidades principais:

• Decomposição de ferramenta paralela: Em vez de uma pesquisa massiva, o agente aciona simultaneamente consultas SQL para números e pesquisas vetoriais para texto. Em seguida, analisa os resultados combinados para formar uma resposta coerente.
• Autocorreção: Se uma pesquisa inicial não produzir resultados — como procurar um autor específico com uma contagem precisa de publicações — o agente não desiste. Ele reformula a consulta, realiza um SQL JOIN e verifica o resultado através de uma segunda busca.
• Configuração declarativa: Ao contrário dos pipelines tradicionais que exigem que os engenheiros “nivelem” ou normalizem os dados em blocos de texto, esse agente usa descrições em linguagem simples. Para adicionar uma nova fonte de dados, um engenheiro simplesmente descreve quais são os dados; o agente aprende como usá-lo.

A mudança da engenharia para a configuração

As implicações para a engenharia de dados são significativas. Em uma configuração RAG tradicional, cada nova fonte de dados requer uma enorme quantidade de “canalização de dados” – conversão de JSON, normalização de tabelas e gerenciamento de incorporações. Isso cria um gargalo que cresce à medida que a empresa se expande.

A abordagem agente inverte este modelo: “Basta trazer o agente para os dados.”

Principais conclusões para implementação:

• Escalabilidade: o modelo de agência é mais sustentável para conjuntos de dados crescentes porque adicionar uma fonte é uma tarefa de configuração, não uma tarefa de codificação.
• Limites de complexidade: embora poderosa, a abordagem funciona melhor com 5 a 10 fontes de dados. Conectar muitas fontes contraditórias ao mesmo tempo pode prejudicar a velocidade e a confiabilidade.
• Integridade de dados: embora o agente possa navegar em diferentes formatos, ele não pode consertar “entra lixo, sai lixo”. Os dados de origem devem ser factualmente precisos para que o agente seja eficaz.

Conclusão

A transição do RAG para agentes de múltiplas etapas representa uma evolução fundamental na IA empresarial: passar de sistemas que apenas encontram informações para sistemas que podem raciocinar em diversos ecossistemas de dados. Ao tratar as fontes de dados como ferramentas e não apenas como blocos de texto, as empresas podem finalmente começar a responder às questões complexas e multifuncionais que orientam as decisões de negócios.