Um elemento central de qualquer operação de recuperação de dados é o uso de um componente conhecido como recuperador. Sua função é recuperar o conteúdo relevante para uma determinada consulta.
Na period da IA, os recuperadores foram usados como parte de pipelines RAG. A abordagem é simples: recupere documentos relevantes, alimente-os em um LLM e deixe o modelo gerar uma resposta com base nesse contexto.
Embora a recuperação possa ter parecido um problema resolvido, na verdade não foi resolvida para os fluxos de trabalho modernos de IA de agentes.
Em pesquisar publicado esta semana, a Databricks apresentou o Instructed Retriever, uma nova arquitetura que a empresa afirma oferecer até 70% de melhoria em relação ao RAG tradicional em tarefas empresariais complexas e com muitas instruções de resposta a perguntas. A diferença está em como o sistema entende e usa metadados.
“Muitos dos sistemas que foram construídos para recuperação antes da period dos grandes modelos de linguagem foram realmente construídos para uso humano, não para uso de agentes”, disse Michael Bendersky, diretor de pesquisa da Databricks, ao VentureBeat. “O que descobrimos é que, em muitos casos, os erros que vêm do agente não são porque o agente não é capaz de raciocinar sobre os dados. É porque o agente não é capaz de recuperar os dados corretos em primeiro lugar.”
O que está faltando nos RAG retrievers tradicionais
O problema central decorre de como o RAG tradicional lida com o que Bendersky chama de “especificações em nível de sistema”. Isso inclui o contexto completo das instruções do usuário, esquemas de metadados e exemplos que definem como deve ser uma recuperação bem-sucedida.
Em um pipeline RAG típico, uma consulta do usuário é convertida em uma incorporação, documentos semelhantes são recuperados de um banco de dados vetorial e esses resultados são alimentados em um modelo de linguagem para geração. O sistema pode incorporar filtragem básica, mas trata fundamentalmente cada consulta como um exercício isolado de correspondência de texto.
Essa abordagem falha com dados corporativos reais. Os documentos empresariais geralmente incluem metadados avançados, como carimbos de knowledge/hora, informações do autor, classificações de produtos, tipos de documentos e atributos específicos de domínio. Quando um usuário faz uma pergunta que requer raciocínio sobre esses campos de metadados, o RAG tradicional enfrenta dificuldades.
Considere este exemplo: “Mostre-me avaliações de produtos cinco estrelas dos últimos seis meses, mas exclua qualquer coisa da Marca X.” O RAG tradicional não consegue traduzir de forma confiável essa restrição de linguagem pure em filtros de banco de dados e consultas estruturadas apropriados.
“Se você usar apenas um sistema RAG tradicional, não há como usar todos esses sinais diferentes sobre os dados encapsulados em metadados”, disse Bendersky. “Eles precisam ser repassados ao próprio agente para que ele faça o trabalho correto de recuperação”.
O problema se torna mais grave à medida que as empresas vão além da simples pesquisa de documentos para fluxos de trabalho de agentes. Um ser humano que usa um sistema de pesquisa pode reformular consultas e aplicar filtros manualmente quando os resultados iniciais erram o alvo. Um agente de IA operando de forma autônoma precisa do próprio sistema de recuperação para compreender e executar instruções complexas e multifacetadas.
Como funciona o Instructed Retriever
A abordagem do Databricks redesenha fundamentalmente o pipeline de recuperação. O sistema propaga especificações completas do sistema em todos os estágios de recuperação e geração. Estas especificações incluem instruções de usuário, exemplos rotulados e esquemas de índice.
A arquitetura adiciona três recursos principais:
Decomposição de consulta: o sistema divide solicitações complexas e compostas por várias partes em um plano de pesquisa contendo diversas pesquisas por palavras-chave e instruções de filtro. Uma solicitação de “produtos FooBrand recentes, excluindo modelos lite” é decomposta em consultas estruturadas com filtros de metadados apropriados. Os sistemas tradicionais tentariam uma única busca semântica.
Raciocínio de metadados: as instruções em linguagem pure são traduzidas em filtros de banco de dados. “Do ano passado” torna-se um filtro de knowledge, “avaliações cinco estrelas” torna-se um filtro de classificação. O sistema entende quais metadados estão disponíveis e como combiná-los com a intenção do usuário.
Relevância contextual: o estágio de reclassificação usa o contexto completo das instruções do usuário para aumentar os documentos que correspondem à intenção, mesmo quando as palavras-chave têm uma correspondência mais fraca. O sistema pode priorizar a atualidade ou tipos de documentos específicos com base nas especificações, em vez de apenas na semelhança do texto.
“A mágica está na forma como construímos as consultas”, disse Bendersky. “Nós meio que tentamos usar a ferramenta como um agente faria, não como um ser humano faria. Ela tem todas as complexidades da API e as utiliza da melhor maneira possível.”
Memória contextual vs. arquitetura de recuperação
Durante a segunda metade de 2025, houve uma mudança na indústria do RAG em direção à memória de IA agente, às vezes chamada de memória contextual. Abordagens incluindo Retrospectiva e A-MEM surgiu oferecendo a promessa de um futuro livre de RAG.
Bendersky argumenta que a memória contextual e a recuperação sofisticada servem a propósitos diferentes. Ambos são necessários para sistemas empresariais de IA.
“Não há como colocar tudo o que está em sua empresa em sua memória contextual”, observou Bendersky. “Você precisa de ambos. Você precisa de memória contextual para fornecer especificações, para fornecer esquemas, mas ainda precisa de acesso aos dados, que podem ser distribuídos em várias tabelas e documentos.”
A memória contextual é excelente na manutenção de especificações de tarefas, preferências do usuário e esquemas de metadados dentro de uma sessão. Ele mantém as “regras do jogo” prontamente disponíveis. Mas o corpus de dados corporativos actual existe fora desta janela de contexto. A maioria das empresas tem volumes de dados que excedem até mesmo janelas de contexto generosas em ordens de grandeza.
O Instructed Retriever aproveita a memória contextual para especificações em nível de sistema enquanto usa a recuperação para acessar o patrimônio de dados mais amplo. As especificações no contexto informam como o recuperador constrói consultas e interpreta os resultados. O sistema de recuperação extrai documentos específicos de potencialmente bilhões de candidatos.
Esta divisão do trabalho é importante para a implementação prática. Carregar milhões de documentos no contexto não é viável nem eficiente. Os metadados por si só podem ser substanciais ao lidar com sistemas heterogêneos em uma empresa. O Instructed Retriever resolve isso tornando os metadados imediatamente utilizáveis, sem exigir que todos se ajustem ao contexto.
Disponibilidade e considerações práticas
O Instructed Retriever já está disponível como parte do Blocos de agente do Databricks; ele está integrado ao produto Information Assistant. As empresas que usam o Information Assistant para criar sistemas de resposta a perguntas em seus documentos aproveitam automaticamente a arquitetura do Instructed Retriever sem criar pipelines RAG personalizados.
O sistema não está disponível como código aberto, embora Bendersky tenha indicado que o Databricks está considerando uma disponibilidade mais ampla. Por enquanto, a estratégia da empresa é lançar benchmarks como o StaRK-Instruct para a comunidade de pesquisa, mantendo a implementação proprietária de seus produtos empresariais.
A tecnologia mostra-se particularmente promissora para empresas com dados complexos e altamente estruturados que incluem metadados ricos. Bendersky citou casos de uso em finanças, comércio eletrônico e saúde. Essencialmente, qualquer domínio onde os documentos tenham atributos significativos além do texto bruto pode se beneficiar.
“O que vimos em alguns casos desbloqueia coisas que o cliente não pode fazer sem isso”, disse Bendersky.
Ele explicou que sem o Instructed Retriever, os usuários precisam realizar mais tarefas de gerenciamento de dados para colocar o conteúdo na estrutura e nas tabelas corretas para que um LLM recupere adequadamente as informações corretas.
“Aqui você pode simplesmente criar um índice com os metadados corretos, apontar seu recuperador para isso e tudo funcionará imediatamente”, disse ele.
O que isso significa para a estratégia empresarial de IA
Para as empresas que hoje criam sistemas baseados em RAG, a pesquisa levanta uma questão crítica: seu pipeline de recuperação é realmente capaz de seguir instruções e raciocinar metadados que seu caso de uso exige?
A melhoria de 70% demonstrada pelo Databricks não é alcançável por meio da otimização incremental. Representa uma diferença arquitetônica na forma como as especificações do sistema fluem através do processo de recuperação e geração. As organizações que investiram na estruturação cuidadosa dos seus dados com metadados detalhados podem descobrir que o RAG tradicional está a deixar muito do valor dessa estrutura em cima da mesa.
Para as empresas que procuram implementar sistemas de IA que possam seguir de forma confiável instruções complexas e compostas por fontes de dados heterogêneas, a pesquisa indica que a arquitetura de recuperação pode ser o diferenciador crítico.
Aqueles que ainda dependem do RAG básico para casos de uso de produção que envolvem metadados ricos devem avaliar se a sua abordagem atual pode atender fundamentalmente aos seus requisitos. A lacuna de desempenho demonstrada pelo Databricks sugere que uma arquitetura de recuperação mais sofisticada é agora uma aposta importante para empresas com conjuntos de dados complexos.
