---
title: "A inteligência está em quem procura"
author: "Ricardo Pupo Larguesa"
date: "2026-10-22 10:00:00-03"
category: "Opinião"
url: "https://aintuicao.scale.press/post/2026/10/22/a-inteligencia-esta-em-quem-procura"
---

Meu sócio e eu temos nos surpreendido com frequência com as consultas e análises que a Sofia, nossa agente de IA na [T2S](https://t2s.com.br), consegue fazer no banco de dados da empresa. Não estamos usando busca semântica para isso. Ela tem acesso aos dados e às ferramentas necessárias para consultá-los, inclusive realizando buscas lexicais em parte do conteúdo. Mesmo assim, os resultados continuam nos impressionando.

Essa experiência voltou à minha cabeça quando encontrei uma publicação da [Zed](https://zed.dev/) e uma palestra sobre busca em agentes de inteligência artificial. Ambas colocavam em discussão uma suposição que se tornou comum nas arquiteturas de IA. Para que um agente encontre informação relevante, seria mesmo necessário converter os documentos em embeddings e organizar uma infraestrutura de busca vetorial?

Pedi à minha IA que encontrasse os benchmarks citados, examinasse as evidências e verificasse quais ferramentas de busca já existiam no ambiente dela. A investigação encontrou resultados interessantes, diferenças importantes entre os experimentos e um benchmark anunciado que não conseguimos recuperar em formato reproduzível.

Minha conclusão prática é que estamos dando pouca atenção à competência do agente para investigar e atenção demais à sofisticação da infraestrutura que o cerca. Um bom modelo, operando ferramentas adequadas e verificando o que encontra, pode produzir análises excelentes sem que cada documento tenha sido previamente convertido em um vetor.

Se duas soluções entregam a mesma qualidade no trabalho que preciso realizar, e uma delas custa menos para implementar, operar e manter, tenho pouca dúvida sobre qual prefiro.

## O anúncio que provocou a investigação

No [post da Zed](https://x.com/zeddotdev/status/2112588120558338261), a empresa afirma ter testado 25 abordagens para localizar ferramentas MCP, incluindo modelos de decisão, LLMs e embeddings. O experimento mencionado reúne 150 consultas sobre um catálogo de 536 ferramentas. A escolha relatada foi um BM25 com ponderação e algumas regras de normalização, executado localmente, sem chamadas a modelos ou APIs na etapa de busca.

MCP é um protocolo usado para disponibilizar ferramentas e recursos a aplicações de IA. Quando o catálogo cresce, o agente precisa descobrir qual ferramenta serve para uma tarefa. Procurar a operação correta dentro desse catálogo é um problema diferente de encontrar evidências em milhares de documentos, mas ambos exigem recuperar informação relevante.

Não localizamos, nas fontes consultadas, a lista das consultas, os gabaritos, a tabela de resultados ou o código experimental correspondente àqueles números. Por isso, o anúncio permite afirmar que a Zed escolheu aquela solução. Não permite calcular a vantagem nem concluir que ela venceu todas as alternativas em precisão.

Ainda assim, a decisão é interessante. Uma empresa que desenvolve ferramentas para agentes relata ter comparado opções e preferido um mecanismo lexical. Isso justifica investigar, em vez de presumir que a abordagem mais recente seja também a mais adequada.

Esta [palestra de Jo Kristian Bergum](https://www.youtube.com/watch?v=fZH97QHHYjY) levou a uma evidência mais detalhada, com artigo, dados e código disponíveis. É nela que a discussão fica especialmente útil.

## O que mudou quando alguém olhou a configuração

O BrowseComp-Plus foi criado para avaliar agentes de pesquisa sobre um acervo fixo. Sua base reúne 830 perguntas e 100.195 documentos, com evidências verificadas por humanos e documentos distratores. Em vez de depender de uma web que muda continuamente, os pesquisadores conseguem comparar diferentes componentes sobre o mesmo material.

O estudo [Revisiting Text Ranking in Deep Research](https://arxiv.org/html/2602.21456) examinou esse ambiente com dois agentes, cinco mecanismos de recuperação e três modelos de reordenação de resultados. Um dos achados mais relevantes foi a sensibilidade do desempenho à configuração da busca e à forma de apresentar os documentos ao agente.

Com o agente baseado em gpt-oss-20b, o BM25 aplicado a documentos completos, usando a configuração original, produziu 25,9% de acerto nas respostas finais. Uma configuração diferente dos parâmetros de frequência e normalização por tamanho levou esse resultado a 50,6%. A seleção dos parâmetros foi feita nas próprias consultas do benchmark, sem um conjunto separado de validação. O resultado mostra a importância da configuração, mas não deve ser confundido com uma vantagem já demonstrada em qualquer outro acervo.

Na recuperação por trechos, em vez de documentos inteiros, o mesmo agente chegou a 57,2% de acerto com BM25, contra 41,7% com Qwen3-Embedding-8B naquela configuração. Os números medem a resposta final do agente, não apenas se uma busca isolada encontrou um documento relevante.

Quando os pesquisadores acrescentaram o reordenador neural monoT5-3B ao BM25, considerando 50 candidatos para reordenação, o acerto chegou a 68,9%. Esse resultado é particularmente instrutivo. A contribuição neural foi útil numa etapa específica, depois de uma recuperação inicial lexical. Não foi necessário substituir toda a busca por embeddings para aproveitar um modelo adicional.

Os autores também identificaram que agentes frequentemente formulam buscas com palavras-chave, nomes e expressões entre aspas. Esse formato favorece determinados mecanismos e pode prejudicar recuperadores treinados com perguntas em linguagem natural. Ao transformar as buscas em perguntas, eles melhoraram o desempenho de mecanismos neurais.

Isso muda a leitura do problema. Não estamos comparando dois algoritmos num vácuo. Estamos comparando um agente que formula consultas, uma ferramenta que espera determinado tipo de entrada, uma representação dos documentos e uma política de leitura dos resultados. Uma combinação ruim pode fazer um componente competente parecer fraco.

## A compreensão pode estar no agente

Busca lexical procura correspondências entre os termos da consulta e o conteúdo. Dependendo da ferramenta, ela pode usar expressões regulares, operadores booleanos, normalização linguística ou um índice de texto completo.

BM25 é uma função de pontuação lexical. Ela considera fatores como a frequência dos termos, sua raridade no acervo e o tamanho dos documentos para ordenar os resultados. Não é sinônimo de toda busca textual, assim como uma busca por expressão regular não é automaticamente uma busca com BM25.

Na recuperação densa com embeddings, um modelo transforma textos em representações numéricas. A consulta também recebe uma representação, e o sistema procura proximidade entre esses vetores. Isso permite recuperar conteúdos relacionados mesmo quando as palavras são diferentes.

As duas abordagens resolvem partes do problema de encontrar informação. Nenhuma delas, isoladamente, faz todo o trabalho de investigação.

Um agente pode entender que uma pergunta exige procurar um nome alternativo, traduzir uma expressão, consultar uma tabela, ler um documento completo ou cruzar dois resultados. Pode perceber que a primeira busca foi ruim e formular outra. Pode usar uma ferramenta lexical simples dentro de uma sequência de ações semanticamente sofisticada.

A ausência de embeddings na recuperação não elimina a compreensão de significado do sistema. Essa compreensão pode estar concentrada no modelo que decide o que procurar e interpreta o que foi encontrado.

É isso que considero mais relevante na experiência da [T2S](https://t2s.com.br). Não estou diante de um mecanismo textual que, por algum motivo, passou a raciocinar. Estou diante de um agente que usa mecanismos de consulta para trabalhar sobre dados reais.

## SQL também pode fazer busca lexical

Durante a conversa, minha IA tentou separar o exemplo do banco de dados da discussão sobre busca lexical. A distinção precisava de um ajuste. SQL é uma linguagem de consulta, não uma categoria oposta à busca textual.

Uma consulta SQL pode combinar relações entre tabelas, filtros, agregações e procura por palavras ou padrões em campos textuais. No nosso ambiente, também há buscas envolvendo conteúdo armazenado em campos binários. O tratamento depende de como esse conteúdo está representado e das operações disponíveis. Um arquivo comprimido, uma imagem e um texto codificado não se tornam igualmente pesquisáveis apenas porque estão no banco.

O que importa para o argumento é que o agente pode combinar operações estruturadas e lexicais sem precisar de uma camada de recuperação por embeddings.

Considere um exemplo hipotético. Um gestor quer entender quais chamados mencionam uma falha de integração, continuam abertos e pertencem a clientes com determinada característica. A parte textual ajuda a localizar o assunto. Os campos estruturados delimitam situação e clientes. As relações entre tabelas conectam os registros. O agente interpreta os resultados e decide se precisa investigar outra hipótese.

Converter todo esse conteúdo em vetores antes de permitir a análise não é uma necessidade automática. Parte importante da informação já está organizada no banco, pronta para ser filtrada e relacionada.

Essa organização tem valor. Identificadores, datas, status e relações explícitas não precisam ser redescobertos por semelhança aproximada quando podem ser consultados diretamente.

## Sinônimos, idiomas e a banda Queen

A defesa do lexical fica mais interessante quando examinamos suas dificuldades, em vez de fingir que elas desapareceram.

BM25 puro não sabe que “carro” e “automóvel” são sinônimos. Um motor de busca pode acrescentar um dicionário para fazer essa expansão. Um agente também pode decidir procurar os dois termos. A diferença é onde colocamos esse conhecimento e quanto custa mantê-lo ou aplicá-lo.

Buscar em português dentro de documentos em português é uma situação. Fazer uma pergunta em português e encontrar a resposta num documento em japonês é outra. Analisadores linguísticos ajudam a tratar flexões e tokenização, mas não fazem automaticamente a tradução entre idiomas. Embeddings multilíngues podem ser úteis nesse segundo caso. Um agente com capacidade de tradução também pode formular buscas no idioma do material.

A ambiguidade aparece de forma simples em “Queen”. Posso estar interessado na banda, na palavra inglesa para rainha ou em outro uso do termo. Acrescentar “band” ajuda a direcionar uma busca lexical. Exigir os dois termos, ponderar campos e usar proximidade pode refinar a seleção.

Mas encontrar as duas palavras não prova a relação pretendida. Um texto sobre uma rainha assistindo à apresentação de uma banda também pode conter ambas. O agente pode usar nomes de integrantes e discos para reformular a busca e, depois, ler o conteúdo para verificar a entidade correta.

Negações expõem outra diferença importante. Excluir a palavra “lactose” não equivale a localizar produtos sem lactose. Um filtro que elimina todos os documentos com essa palavra pode remover justamente a descrição “produto sem lactose”. A negação de um termo é uma operação textual. A ausência de uma propriedade é uma afirmação sobre o mundo.

Não encontrei, nos resultados que examinamos, avaliações controladas e separadas suficientes para declarar empate geral entre abordagens em tradução entre idiomas, sinônimos, negação e desambiguação. Perguntas difíceis podem conter essas situações sem que o benchmark meça cada capacidade de forma isolada.

Para decidir uma arquitetura, eu colocaria essas dificuldades no conjunto de perguntas reais da empresa. Se o agente consegue resolvê-las com reformulações simples e buscas baratas, ótimo. Se passa a dar muitas voltas, perde documentos importantes ou exige manutenção constante de dicionários, temos uma razão concreta para testar outro mecanismo.

## O custo que interessa é o da resposta útil

Meu argumento econômico é que, se consigo o resultado necessário com uma infraestrutura mais simples, não vejo vantagem em acrescentar outra camada apenas porque ela se tornou comum em projetos de IA.

Embeddings introduzem trabalho de geração e atualização das representações, armazenamento e consulta do índice. Há implementações locais e modelos que executam em CPU, portanto não é obrigatório contratar uma API ou possuir uma GPU. Também não é necessário recalcular todo o acervo a cada pergunta. Ainda assim, esse processamento existe, tem consumo computacional alto e precisa ser considerado.

A busca lexical também tem custos. Extrair texto de PDFs, interpretar documentos, fazer OCR, construir índices e mantê-los atualizados exige trabalho. Grande parte dessa preparação existe nas duas abordagens. O fato de um algoritmo não precisar de inferência neural não transforma a ingestão de arquivos em uma operação gratuita.

Na consulta, o lexical normalmente evita a etapa de gerar um embedding da pergunta. Isso é uma vantagem operacional. O tempo total, porém, depende do acervo, do índice e do número de tentativas que o agente precisa fazer.

Uma busca barata que obriga um modelo caro a realizar muitas tentativas pode deixar de ser a opção mais econômica. Da mesma forma, uma busca vetorial rápida que recupera trechos inadequados transfere custo para leitura, correção e revisão humana. É possível gastar pouco por chamada e muito para concluir uma tarefa.

O estudo que examinamos oferece um exemplo dessa interação. A reordenação acrescenta processamento, mas pode melhorar a seleção dos resultados e reduzir chamadas posteriores de busca. Para saber se compensa financeiramente, precisamos medir o conjunto, não apenas o preço de uma etapa.

Por isso, prefiro comparar custo por resposta correta e verificável. Incluo nessa conta a preparação dos dados, as consultas, os tokens do agente, a manutenção e o tempo humano necessário para conferir ou corrigir a entrega.

Quando a qualidade é equivalente, menor custo e menor complexidade são vantagens suficientes para escolher o lexical. Quando uma camada semântica melhora significativamente o resultado, ela pode pagar o próprio custo. O ponto é demonstrar esse ganho, em vez de presumir sua existência.

## Indexar um servidor inteiro não é o primeiro passo

A investigação também examinou as ferramentas disponíveis no ambiente da minha IA. Já havia busca textual em arquivos com ripgrep, leitura seletiva, busca nas conversas e uma base de memória para conteúdos explicitamente ingeridos. Não tenho um indexador geral acompanhando automaticamente todos os arquivos do servidor.

Esses mecanismos têm funções diferentes. Encontrar uma expressão num arquivo atual não é o mesmo que recuperar uma conversa antiga sobre aquele arquivo. Uma memória de projeto também não substitui a leitura do código que está em uso.

Para código, configurações e diagnósticos, procurar nomes de funções, mensagens de erro, identificadores e trechos exatos costuma ser uma estratégia natural. Antes de instalar outro serviço, faz sentido explorar bem as ferramentas que já existem.

Para um acervo documental consultado com frequência, um índice lexical incremental pode ajudar bastante. “Incremental” significa atualizar o que mudou, em vez de reconstruir tudo continuamente. Mas eu começaria pelas pastas e pelos tipos de documento que realmente importam, preservando caminho, data e acesso ao conteúdo original.

SQLite FTS5, por exemplo, oferece busca de texto completo e classificação com BM25. Isso não significa que um comando crie sozinho toda a solução. Ainda são necessários extração de conteúdo, sincronização e uma ferramenta que permita ao agente consultar o índice.

Indexar indiscriminadamente dependências, caches, arquivos temporários e cópias antigas pode aumentar o ruído em vez de melhorar a análise. A seleção do acervo faz parte da qualidade da busca.

## A complexidade precisa mostrar serviço

Minha preferência é começar com um modelo competente, ferramentas confiáveis e dados acessíveis. O agente precisa saber formular consultas, ler além do primeiro resultado, cruzar evidências e conferir se a resposta realmente atende à pergunta.

A partir daí, acrescento infraestrutura para resolver uma dificuldade observada. Se documentos relevantes não aparecem por diferenças de vocabulário ou idioma, testo recuperação semântica. Se aparecem, mas ficam enterrados entre resultados ruins, avalio reordenação. Se a resposta depende de relações e cálculos presentes no banco, exploro as consultas estruturadas. Se o problema é um arquivo que nunca entrou no acervo, nenhum algoritmo de ranking vai recuperá-lo daquele índice.

Também não preciso escolher uma única abordagem para tudo. Um agente pode usar busca lexical como primeira opção e recorrer à semântica quando necessário. Pode consultar diretamente o banco e usar embeddings apenas para uma coleção de documentos narrativos. A arquitetura deve acompanhar o trabalho, não uma preferência abstrata por uma tecnologia.

Essa experiência tem relação com algo que já encontrei ao [testar os limites da visão artificial](https://aintuicao.scale.press/post/2026/09/27/testando-os-limites-da-visao-artificial). Na edição dos jogos de futsal do meu filho, parte do avanço veio de separar o que exigia interpretação do que podia ser executado por um procedimento simples. Não era necessário pedir inteligência a cada etapa.

Com busca, vejo uma oportunidade semelhante. O modelo pode concentrar o esforço de interpretação, enquanto ferramentas mais previsíveis executam a recuperação, os filtros e os cálculos.

Antes de investir em transformar todo o acervo em embeddings, quero saber se o agente consegue investigar bem os dados que já tem à disposição. A busca semântica pode ser um complemento excelente. Para adotá-la, espero que resolva um problema que apareceu no trabalho e que o ganho justifique seu custo. Não que sua simples presença torne a arquitetura mais convincente numa apresentação.

## Referências

1. Zed. Publicação sobre seleção de ferramentas MCP e adoção de BM25 ponderado. [https://x.com/zeddotdev/status/2112588120558338261](https://x.com/zeddotdev/status/2112588120558338261)

2. Jo Kristian Bergum. Palestra disponibilizada pelo AI Engineer. Vídeo [https://www.youtube.com/watch?v=fZH97QHHYjY](https://www.youtube.com/watch?v=fZH97QHHYjY) e página do evento [https://ai.engineer/talks/fZH97QHHYjY-youtube-02abd6378435a976ca23](https://ai.engineer/talks/fZH97QHHYjY-youtube-02abd6378435a976ca23)

3. Chen, Z. et al. BrowseComp-Plus. Repositório e documentação do benchmark. [https://github.com/texttron/BrowseComp-Plus](https://github.com/texttron/BrowseComp-Plus)

4. Meng, C.; Ou, L.; MacAvaney, S.; Dalton, J. Revisiting Text Ranking in Deep Research. SIGIR 2026. [https://arxiv.org/html/2602.21456](https://arxiv.org/html/2602.21456) e código [https://github.com/ChuanMeng/text-ranking-in-deep-research](https://github.com/ChuanMeng/text-ranking-in-deep-research)

5. Elastic. Language analyzers e Synonym graph token filter. [https://www.elastic.co/docs/reference/text-analysis/analysis-lang-analyzer](https://www.elastic.co/docs/reference/text-analysis/analysis-lang-analyzer) e [https://www.elastic.co/docs/reference/text-analysis/analysis-synonym-graph-tokenfilter](https://www.elastic.co/docs/reference/text-analysis/analysis-synonym-graph-tokenfilter)

6. Elastic. Match query. Operadores, análise de termos e sinônimos. [https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-match-query](https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-match-query)

7. Elastic. Boolean query. [https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-bool-query](https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-bool-query)

8. Sentence Transformers. Speeding up Inference. Execução e otimizações dos modelos de embeddings. [https://www.sbert.net/docs/sentence_transformer/usage/efficiency.html](https://www.sbert.net/docs/sentence_transformer/usage/efficiency.html)

9. SQLite. FTS5 Extension. [https://www.sqlite.org/fts5.html](https://www.sqlite.org/fts5.html)

10. Larguesa, R. P. Testando os limites da visão artificial. AIntuição. [https://aintuicao.scale.press/post/2026/09/27/testando-os-limites-da-visao-artificial](https://aintuicao.scale.press/post/2026/09/27/testando-os-limites-da-visao-artificial)