As equipes de dados que constroem agentes de IA continuam no mesmo modo de falha. Perguntas que exigem a união de dados estruturados com conteúdo não estruturado, números de vendas junto com avaliações de clientes ou contagens de citações junto com artigos acadêmicos quebram os sistemas RAG de giro único.
Uma nova pesquisa da Databricks atribui um número a essa lacuna de falha. A equipe de pesquisa de IA da empresa testou uma abordagem de agente de várias etapas em relação às linhas de base RAG de giro único de última geração em nove tarefas de conhecimento empresarial e relatou ganhos de 20% ou mais no conjunto de benchmark STaRK de Stanford, juntamente com melhorias consistentes na estrutura de avaliação KARLBench da própria Databricks, de acordo com a pesquisa. Databricks argumenta que a lacuna de desempenho entre RAG de turno único e agentes de múltiplas etapas em tarefas de dados híbridos é um problema de arquitetura, não um problema de qualidade do modelo.
O trabalho se baseia na pesquisa anterior de recuperação instruída do Databricks, que mostrou melhorias na recuperação de dados não estruturados usando consultas com reconhecimento de metadados. Esta pesquisa mais recente adiciona fontes de dados estruturados, tabelas relacionais e armazéns SQL no mesmo ciclo de raciocínio, abordando a classe de perguntas que as empresas mais comumente não conseguem responder com as atuais arquiteturas de agentes.
“RAG funciona, mas não é escalável”, disse Michael Bendersky, diretor de pesquisa da Databricks, ao VentureBeat. “Se você deseja tornar seu agente ainda melhor e entender por que há queda nas vendas, agora você precisa ajudar o agente a ver as tabelas e os dados de vendas. Seu pipeline RAG se tornará incompetente nessa tarefa.”
A recuperação de volta única não pode codificar restrições estruturais
A principal conclusão é que os sistemas RAG padrão falham quando uma consulta mistura um filtro estruturado preciso com uma pesquisa semântica aberta.
Considere uma pergunta como “Quais de nossos produtos tiveram vendas decrescentes nos últimos três meses e quais problemas potencialmente relacionados são levantados nas avaliações dos clientes em vários sites de vendedores?” Os dados de vendas ficam em um armazém. O sentimento de revisão reside em documentos não estruturados nos sites dos vendedores. Um sistema RAG de turno único não pode dividir essa consulta, encaminhar cada metade para a fonte de dados correta e combinar os resultados.
Para confirmar que se trata de um problema de arquitetura e não de qualidade do modelo, a Databricks refez as linhas de base STaRK publicadas usando um modelo de base de última geração. O modelo mais forte ainda perdeu para o agente de múltiplas etapas em 21% no domínio acadêmico e 38% no domínio biomédico, segundo a pesquisa.
STaRK é um benchmark publicado por pesquisadores de Stanford que cobre três domínios de recuperação semiestruturados: dados de produtos da Amazon, o Microsoft Academic Graph e uma base de conhecimento biomédico.
Como o Agente Supervisor lida com o que o RAG não consegue
A Databricks construiu o Agente Supervisor como a implementação de produção desta abordagem de pesquisa, e sua arquitetura ilustra por que os ganhos são consistentes em todos os tipos de tarefas. A abordagem inclui três etapas principais:
Decomposição paralela de ferramentas. Em vez de emitir uma consulta ampla e esperar que os resultados cubram necessidades estruturadas e não estruturadas, o agente dispara chamadas SQL e de pesquisa vetorial simultaneamente e, em seguida, analisa os resultados combinados antes de decidir o que fazer a seguir. Essa etapa paralela é o que permite lidar com consultas que cruzam os limites do tipo de dados sem exigir que os dados sejam normalizados primeiro.
Autocorreção. Quando uma tentativa inicial de recuperação chega a um beco sem saída, o agente detecta a falha, reformula a consulta e tenta um caminho diferente. Em uma tarefa de benchmark STaRK que requer encontrar um artigo de um autor com exatamente 115 publicações anteriores sobre um tópico específico, o agente primeiro consulta SQL e pesquisa vetorial em paralelo. Quando os dois conjuntos de resultados não mostram nenhuma sobreposição, ele se adapta e emite um SQL JOIN em ambas as restrições e, em seguida, chama o sistema de pesquisa vetorial para verificar o resultado antes de retornar a resposta.
Configuração declarativa. O agente não está sintonizado com nenhum conjunto de dados ou tarefa específica. Conectá-lo a uma nova fonte de dados significa escrever uma descrição em linguagem simples do que essa fonte contém e que tipos de perguntas ela deve responder. Nenhum código personalizado é necessário.
“O agente pode fazer coisas como decompor a pergunta em uma consulta SQL e uma consulta de pesquisa pronta para uso”, disse Bendersky. “Ele pode combinar os resultados de SQL e RAG, raciocinar sobre esses resultados, fazer consultas de acompanhamento e então raciocinar sobre se a resposta final foi realmente encontrada.”
Não se trata apenas de recuperação híbrida
A distinção que o Databricks traça não tem a ver com técnica de recuperação, mas sim com arquitetura.
“Quase não vemos isso como uma recuperação híbrida onde você combina embeddings e resultados de pesquisa, ou embeddings e tabelas”, disse ele. “Vemos isso mais como um agente que tem acesso a múltiplas ferramentas”.
A consequência prática desse enquadramento é que adicionar uma nova fonte de dados significa conectá-la ao agente e escrever uma descrição do que ela contém. O agente lida com roteamento e orquestração sem código adicional.
Os pipelines RAG personalizados exigem que os dados sejam convertidos em um formato que o sistema de recuperação possa ler, normalmente pedaços de texto com incorporações. As tabelas SQL precisam ser niveladas, o JSON precisa ser normalizado. Cada nova fonte de dados adicionada ao pipeline significa mais trabalho de conversão. A pesquisa da Databricks argumenta que à medida que os dados corporativos crescem para incluir mais tipos de fontes, essa carga torna os pipelines personalizados cada vez mais impraticáveis em comparação com um agente que consulta cada fonte em seu formato nativo.
“Basta levar o agente aos dados”, disse Bendersky. “Basicamente, você dá ao agente mais fontes e ele aprenderá a usá-las muito bem.”
O que isso significa para as empresas
Para os engenheiros de dados que estão avaliando se devem construir pipelines RAG personalizados ou adotar uma estrutura de agente declarativo, a pesquisa oferece uma direção clara: se a tarefa envolve questões que abrangem dados estruturados e não estruturados, construir uma recuperação personalizada é o caminho mais difícil. A pesquisa descobriu que em todas as tarefas testadas, as únicas coisas que diferiram entre as implantações foram as instruções e as descrições das ferramentas. O agente cuidou do resto.
Os limites práticos são reais, mas administráveis. A abordagem funciona bem com cinco a dez fontes de dados. Adicionar muitas de uma vez, sem selecionar quais fontes são complementares e não contraditórias, torna o agente mais lento e menos confiável. Bendersky recomenda dimensionar de forma incremental e verificar os resultados em cada etapa, em vez de conectar todos os dados disponíveis antecipadamente.
A precisão dos dados é um pré-requisito. O agente pode consultar formatos incompatíveis, feeds de revisão JSON junto com tabelas de vendas SQL, sem exigir normalização. Ele não pode corrigir dados de origem que estejam factualmente errados. Adicionar uma descrição em linguagem simples de cada fonte de dados no momento da ingestão ajuda o agente a encaminhar as consultas corretamente desde o início.
A pesquisa posiciona isso como um passo inicial em uma trajetória mais longa. À medida que as cargas de trabalho de IA corporativa amadurecem, espera-se que os agentes raciocinem em dezenas de tipos de fontes, incluindo painéis, repositórios de código e feeds de dados externos. A pesquisa argumenta que a abordagem declarativa é o que torna esse escalonamento tratável, porque adicionar uma nova fonte continua sendo um problema de configuração e não de engenharia.
“Isso é como uma escada”, disse Bendersky. “O agente irá lentamente obter mais e mais informações e, então, melhorar lentamente no geral.”
