A Mistral lançou o Agentic Search, transformando a recuperação de documentos de uma busca única em uma operação de múltiplas etapas. O sistema dá ao modelo cinco ferramentas: search, open, navigate, read, grep. O modelo pode fazer uma primeira busca, abrir o arquivo encontrado para examinar, avançar até uma seção específica, e se perceber um erro após a leitura, trocar os termos e buscar de novo — só respondendo depois de confirmar.
Essa abordagem trouxe ganhos consideráveis em dois benchmarks. O FinanceBench usa documentos da SEC de empresas listadas nos EUA: a precisão subiu de 26,7% para 86%, mais que triplicando. O OfficeQA Pro usa boletins do Departamento do Tesouro dos EUA e foi de 6,3% para 51,9%, um ganho de 45,6 pontos percentuais.
Onde a recuperação única emperra
O fluxo padrão de RAG divide documentos em blocos, calcula vetores, recupera os blocos mais semelhantes à pergunta e os insere no contexto para o modelo responder. Esse pipeline funciona para perguntas do tipo "qual foi a receita da empresa em determinado ano", mas começa a falhar em algo como "liste o fluxo de caixa livre dos últimos três anos e explique as mudanças de critério contábil".
A falha já nasce na etapa de fragmentação. Um número num relatório financeiro geralmente só é lido corretamente com três elementos: o valor na tabela, a nota de rodapé abaixo dela e a explicação do critério contábil em alguma seção anterior. Esses três elementos podem estar separados por dezenas de páginas, e a recuperação por vetores ordena por similaridade semântica — notas de rodapé e explicações de critério raramente entram entre os primeiros resultados. O modelo recebe um número isolado e só pode repeti-lo, sem saber se está errado.
A recuperação em múltiplas etapas reconstrói o processo como se fosse uma pessoa folheando o documento: localizar primeiro, depois expandir, e ao encontrar "ver detalhes na nota 12", saltar até lá e voltar depois. A existência da ferramenta grep é particularmente reveladora: a busca vetorial é boa em correspondência semântica difusa, mas diante de uma string exata como "Note 12", a correspondência de texto integral à moda antiga é mais confiável — os dois métodos de busca dividem tarefas dentro do mesmo conjunto de ferramentas.
Há também um benefício facilmente ignorado aqui. Uma resposta da recuperação única não pode ser rastreada: se o modelo diz que a receita foi determinado valor, o usuário que quiser saber de qual página veio precisa voltar e procurar por conta própria. Na recuperação em múltiplas etapas, cada passo é uma chamada explícita de ferramenta — qual arquivo foi aberto, para qual seção se saltou, qual string foi encontrada, tudo fica registrado no rastro. Para cenários financeiros e jurídicos, esse próprio rastro já é parte do produto entregue: acertar a resposta não basta, é preciso também comprovar por que está certa.
Mais rodadas, e ainda assim mais barato
Intuitivamente, operar em múltiplas etapas deveria significar mais rodadas, mais tokens e mais espera. Os números da Mistral mostram o contrário: o uso de tokens caiu até 33,7% e a latência P90 caiu 39,6%, e no FinanceBench o tempo passou de 255 segundos para 154 segundos.
Esses números valem em comparação com uma linha de base específica. O RAG de recuperação única, para garantir cobertura, tende a aumentar o número de blocos recuperados, empilhando vinte a oitenta blocos no contexto, boa parte irrelevante para a pergunta. A recuperação em múltiplas etapas lê em cada rodada só o trecho necessário; as rodadas aumentam, mas a entrada de cada uma é curta, e no total o consumo cai.
A questão da latência depende mais da implementação técnica. A queda no P90 indica que os casos de cauda longa — "a recuperação falhou, o modelo inventou, a resposta saiu absurda, foi preciso refazer" — ficaram mais raros. Na recuperação única, a falha é silenciosa: o modelo não sabe que não obteve a nota de rodapé. Na recuperação em múltiplas etapas, o modelo consegue perceber que não encontrou o que precisava e busca de novo, o que encolhe essa cauda longa.
Dois obstáculos para o cenário em chinês
A Mistral disponibiliza o recurso como Search Toolkit e Libraries, já integrado ao Studio e ao Vibe, com suporte para implantação em nuvem e local. A implantação local é uma exigência inegociável para setores como finanças, saúde e governo, que não podem enviar documentos para fora — a Mistral sempre tratou isso como um diferencial frente aos fornecedores americanos.
Levar essa abordagem para documentos em chinês traz dois novos problemas. Primeiro, o grep não tem delimitação de palavras em chinês, então o ganho da correspondência exata é bem menor do que em inglês, e uma estimativa aproximada indica bem mais ruído nos resultados. Segundo, prospectos, relatórios anuais e documentos regulatórios chineses usam muito digitalizações e tabelas fora do padrão — se a etapa de read consegue ou não reconstruir a estrutura das tabelas decide diretamente se as etapas seguintes estão lendo ou apenas chutando.
Outro ponto de atenção é o próprio benchmark. FinanceBench e OfficeQA Pro são conjuntos de testes públicos, cujas perguntas e documentos já circulam há tempo na internet — qualquer empresa que teste seu sistema neles corre o risco de contaminação por dados de treinamento. O ponto de partida de 26,7% é chamativamente baixo, e o anúncio oficial não detalha a qual configuração de RAG ele corresponde, quantos blocos foram recuperados, nem qual modelo base foi usado. A direção da melhoria é crível, mas o fator de multiplicação deve ser lido com ressalvas.
O preço ainda não foi divulgado. Para compras corporativas, esse ponto pesa bastante: cada pergunta na recuperação em múltiplas etapas gera várias chamadas ao modelo, e se a cobrança for por chamada, alcançar 86% de precisão pode custar várias vezes o preço unitário — a conta precisa ser refeita.
Fontes: anúncio oficial da Mistral, CocoLoop; os números de precisão do FinanceBench e OfficeQA Pro, a redução de tokens e a latência P90 foram conferidos item a item.