A maioria dos pipelines RAG empresariais são otimizados para um comportamento de pesquisa. Eles falham silenciosamente nos outros. Um modelo treinado para sintetizar relatórios entre documentos não lida bem com a pesquisa de entidades orientada por restrições. Um modelo ajustado para tarefas simples de pesquisa desmorona no raciocínio de várias etapas sobre notas internas. A maioria das equipes descobre quando algo quebra.
A Databricks decidiu consertar isso com KARL, abreviação de Knowledge Agents via Reinforcement Learning. A empresa treinou um agente em seis comportamentos distintos de pesquisa empresarial simultaneamente, usando um novo algoritmo de aprendizagem por reforço. O resultado, afirma a empresa, é um modelo que corresponde a Claude Opus 4.6 em um benchmark criado especificamente com custo por consulta 33% menor e latência 47% menor, treinado inteiramente em dados sintéticos que o próprio agente gerou sem necessidade de rotulagem humana. Essa comparação é baseada no KARLBench, que o Databricks construiu para avaliar comportamentos de pesquisa corporativa.
“Muitas das grandes vitórias de aprendizagem por reforço que vimos na comunidade no ano passado foram em tarefas verificáveis onde há uma resposta certa e uma errada”, disse Jonathan Frankle, cientista-chefe de IA da Databricks, ao VentureBeat em uma entrevista exclusiva. “As tarefas nas quais estamos trabalhando para a KARL, e que são normais para a maioria das empresas, não são estritamente verificáveis da mesma forma.”
Essas tarefas incluem sintetizar inteligência através de notas de reuniões de gerentes de produto, reconstruir resultados de negócios competitivos a partir de registros fragmentados de clientes, responder perguntas sobre o histórico da conta onde nenhum documento único tem a resposta completa e gerar cartas de batalha a partir de dados internos não estruturados. Nenhum deles tem uma única resposta correta que um sistema possa verificar automaticamente.
“Fazer aprendizado por reforço em um mundo onde você não tem respostas estritamente certas e erradas, e descobrir como orientar o processo e garantir que o hacking de recompensas não aconteça – isso não é realmente trivial”, disse Frankle. “Muito pouco do que as empresas fazem no dia a dia em tarefas de conhecimento é verificável.”
A armadilha da generalização no RAG empresarial
O RAG padrão se divide em consultas ambíguas e de várias etapas, baseadas em dados internos fragmentados que nunca foram projetados para serem consultados.
Para avaliar o KARL, a Databricks construiu o benchmark KARLBench para medir o desempenho em seis comportamentos de pesquisa empresarial: pesquisa de entidades orientada por restrições, síntese de relatórios entre documentos, travessia de documentos longos com raciocínio numérico tabular, recuperação exaustiva de entidades, raciocínio processual sobre documentação técnica e agregação de fatos sobre notas internas da empresa. Essa última tarefa é o PMBench, construído a partir de notas de reuniões de gerentes de produto do próprio Databricks – fragmentado, ambíguo e desestruturado de uma forma que os modelos de fronteira não lidam bem.
O treinamento em qualquer tarefa e o teste nas outras produzem resultados insatisfatórios. O artigo KARL mostra que o RL multitarefa generaliza de uma forma que o treinamento de tarefa única não o faz. A equipe treinou o KARL em dados sintéticos para duas das seis tarefas e descobriu que ele teve um bom desempenho em todas as quatro que nunca tinha visto.
Para construir um cartão de batalha competitivo para um cliente de serviços financeiros, por exemplo, o agente tem de identificar contas relevantes, filtrar por atualidade, reconstruir negócios competitivos anteriores e inferir resultados – nenhum dos quais é rotulado em qualquer lugar dos dados.
Frankle chama o que KARL faz de “raciocínio fundamentado”: executar uma cadeia de raciocínio difícil enquanto ancora cada passo nos fatos recuperados. “Você pode pensar nisso como RAG”, disse ele, “mas como RAG plus plus plus plus plus plus plus, até 200 chamadas de banco de dados vetoriais”.
O mecanismo RL: por que o OAPL é importante
O treinamento de KARL é desenvolvido com OAPL, abreviação de política Optimal Advantage-based Policy Optimization with Lagged Inference. É uma nova abordagem, desenvolvida em conjunto por pesquisadores de Cornell, Databricks e Harvard e publicada em um papel separado uma semana antes de KARL.
O aprendizado de reforço LLM padrão usa algoritmos de acordo com a política, como GRPO (Group Relative Policy Optimization), que assumem que o modelo que gera dados de treinamento e o modelo que está sendo atualizado estão sincronizados. No treinamento distribuído, eles nunca são. As abordagens anteriores corrigiram isso com amostragem de importância, introduzindo variância e instabilidade. Em vez disso, o OAPL abraça a natureza fora da política da formação distribuída, utilizando um objectivo de regressão que permanece estável com atrasos políticos de mais de 400 passos de gradiente, 100 vezes mais fora da política do que as abordagens anteriores tratadas. Em experimentos de geração de código, ele correspondeu a um modelo treinado por GRPO usando aproximadamente três vezes menos amostras de treinamento.
A eficiência da amostra da OAPL é o que mantém o orçamento de formação acessível. A reutilização de implementações coletadas anteriormente, em vez de exigir novos dados de acordo com a política para cada atualização, significou que a execução completa do treinamento KARL durou alguns milhares de horas de GPU. Essa é a diferença entre um projeto de pesquisa e algo que uma equipe empresarial pode tentar de forma realista.
Agentes, memória e pilha de contexto
Tem havido muita discussão na indústria nos últimos meses sobre como o RAG pode ser substituído pela memória contextual, também chamada de memória agente.
Para Frankle, não se trata de uma discussão ou/ou, mas sim como uma pilha em camadas. Um banco de dados vetorial com milhões de entradas fica na base, que é grande demais para o contexto. A janela de contexto do LLM fica na parte superior. Entre eles, estão surgindo camadas de compressão e cache que determinam quanto daquilo que um agente já aprendeu ele pode transportar adiante.
Para KARL, isso não é abstrato. Algumas tarefas do KARLBench exigiam 200 consultas sequenciais ao banco de dados vetorial, com o agente refinando as pesquisas, verificando detalhes e fazendo referência cruzada de documentos antes de se comprometer com uma resposta, esgotando a janela de contexto muitas vezes. Em vez de treinar um modelo de resumo separado, a equipe deixou o KARL aprender a compactação de ponta a ponta por meio de RL: quando o contexto fica muito grande, o agente o compacta e continua, sendo o único sinal de treinamento a recompensa no final da tarefa. A remoção dessa compactação aprendida reduziu a precisão em um benchmark de 57% para 39%.
“Nós apenas deixamos o modelo descobrir como comprimir seu próprio contexto”, disse Frankle. “E isso funcionou fenomenalmente bem.”
Onde KARL fica aquém
Frankle foi sincero sobre os modos de falha. KARL tem mais dificuldades em questões com ambiguidade significativa, onde existem múltiplas respostas válidas e o modelo não consegue determinar se a questão é genuinamente aberta ou apenas difícil de responder. Esse julgamento ainda é um problema não resolvido.
O modelo também exibe o que Frankle descreveu como desistir precocemente de algumas questões – parar antes de produzir uma resposta final. Ele recusou enquadrar isso como um fracasso, observando que as consultas mais caras são normalmente aquelas que o modelo erra de qualquer maneira. Parar muitas vezes é a decisão certa.
KARL também foi treinado e avaliado exclusivamente em busca de vetores. Tarefas que exigem consultas SQL, pesquisa de arquivos ou cálculos baseados em Python ainda não estão no escopo. Frankle disse que esses recursos são os próximos no roteiro, mas não estão no sistema atual.
O que isso significa para as equipes de dados empresariais
KARL apresenta três decisões que vale a pena revisar para as equipes que avaliam sua infraestrutura de recuperação.
A primeira é a arquitetura de pipeline. Se o seu agente RAG estiver otimizado para um comportamento de pesquisa, os resultados do KARL sugerem que ele está falhando em outros. O treinamento multitarefa em diversos comportamentos de recuperação produz modelos que generalizam. Pipelines estreitos não.
A segunda é a razão pela qual a RL é importante aqui – e não é apenas um detalhe de treinamento. A Databricks testou a alternativa: destilar modelos especializados por meio de ajuste fino supervisionado. Essa abordagem melhorou o desempenho na distribuição, mas produziu ganhos insignificantes em tarefas que o modelo nunca tinha visto. RL desenvolveu comportamentos de pesquisa gerais que foram transferidos. Para equipes empresariais que enfrentam dados heterogêneos e tipos de consultas imprevisíveis, essa distinção é o jogo completo. A terceira é o que a eficiência da RL realmente significa na prática. Um modelo treinado para pesquisar melhor completa tarefas em menos passos, para mais cedo em consultas que não consegue responder, diversifica a sua pesquisa em vez de repetir consultas falhadas e comprime o seu próprio contexto em vez de ficar sem espaço. O argumento para treinar agentes de pesquisa específicos, em vez de encaminhar tudo por meio de APIs de fronteira de uso geral, não tem a ver principalmente com custos. Trata-se de construir um modelo que saiba fazer o trabalho.
