A busca local INSANA do XERJ para agents de IA: testei, quebrou e depois ficou INCRÍVEL

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: XERJ’s CRAZY Local Search for AI Agents: I Tested It, It Broke, Then It Got AWESOME · Canal: Prompt Engineer 48 · 09:45 · Assistir no YouTube

Tópicos: Agentes de IA, Ferramentas de desenvolvimento com IA, RAG, busca e recuperação de informação

Resumo

O vídeo testa o XERJ, um mecanismo de busca local e servidor MCP para agents, em um laptop Windows. A indexação de um repo inteiro falha após quase duas horas por exceder o limite de memória, mas uma pasta menor produz resultados úteis com referências a arquivos e linhas. O desempenho das buscas varia muito, e a recuperação de memória padrão parece lexical, não semântica; a compatibilidade com a API de Elasticsearch funciona nos testes apresentados. O autor recomenda começar por uma pasta pequena e observar o tempo da primeira busca, além de desativar o envio automático de feedback antes de conectar a ferramenta a um agent com acesso ao GitHub.

Pontos-chave

O XERJ é um mecanismo de busca open source local e servidor MCP escrito em Rust, capaz de indexar código, documentação, logs, JSONL, CSV e PDFs.
O estudo do projeto alega que um coding agent usou cerca de 2,7 vezes menos output tokens que um agent guiado por grep, mas o autor não reproduziu esse resultado.
A indexação de um repo de 159 MB falhou após 108 minutos porque o orçamento de memória da memtable foi esgotado.
Uma pasta menor foi indexada em 9 minutos e meio, e as buscas por referências de código apontaram arquivos e linhas relevantes.
O tempo de busca variou de menos de um segundo a mais de um minuto no mesmo computador e índice, sem causa identificada pelo autor.
A busca é lexical por padrão: não há stemming, e a memória não recuperou frases semanticamente relacionadas no teste.
A compatibilidade com a API de Elasticsearch permitiu criar um índice, carregar documentos e executar uma consulta com agregações usando curl.
O comando de inicialização configura arquivos do agent e skills, enquanto o servidor MCP anuncia ferramentas de busca, memória e grafo.
O XERJ pode enviar relatórios de feedback automaticamente; o autor desativou esse recurso antes dos testes e recomenda atenção ao usá-lo com acesso ao GitHub.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o XERJ e o que o teste pretende avaliar	O autor apresenta o XERJ, explica a alegação de economia de tokens do projeto e delimita o teste local de indexação e qualidade das buscas.
02:13	A indexação do repo inteiro falha	A indexação do repo de 159 MB excede o limite de memória, levando o autor a testar uma pasta menor.
04:55	Qualidade e latência das buscas	O autor apresenta resultados úteis em código, mas observa grande variação no tempo das buscas e testa o XERJ em outro repo.
07:02	Memória, integração com agents e feedback automático	Os testes mostram recuperação lexical de memória, configuração por MCP e envio automático de feedback com opção de desativação.
09:14	Conclusão e recomendações	O autor resume os pontos fortes e as limitações do XERJ e recomenda começar por uma pasta pequena e medir o tempo da primeira busca.

Citações

Eu não reproduzi esse resultado; trate-o como uma alegação deles, não como um resultado meu. — 01:32

A latência variou de menos de um segundo a mais de um minuto. — 04:55

Com o embedder padrão, a recuperação é por palavras, não por significado. — 07:36

Experimente primeiro em uma pasta pequena e observe o tempo da primeira busca. — 09:45

Conceitos e entidades

XERJ (ferramenta): Mecanismo de busca local e servidor MCP para indexar e pesquisar arquivos destinados ao uso por agents.
MCP (conceito): Protocolo usado pelo XERJ para expor ferramentas de busca e memória a agents.
Rust (conceito): Linguagem em que o XERJ foi escrito.
Elasticsearch (ferramenta): O XERJ oferece compatibilidade com a API de busca do Elasticsearch, testada no vídeo com consultas e agregações.
Claude Code (ferramenta): Produto citado como destino de uma skill criada pelo comando de inicialização do XERJ.
GitHub (empresa): Plataforma em que o XERJ pode abrir um pull request automático para enviar feedback do usuário.
RunPod (empresa): Serviço mencionado pelo autor em relação ao aluguel de GPUs para testes.
similar diff library (repo): Repo público em Rust usado pelo autor como corpus para testar buscas sobre código.

Tradução completa (pt-BR)

00:00 Foi assim que ficou minha primeira execução do XERJ. Apontei para um repo, esperei 1 hora e 48 minutos, e ele desistiu. O orçamento de memória foi excedido; gravações rejeitadas. Mas a segunda execução funcionou, e os resultados da busca eram realmente bons. Então, neste vídeo, vou mostrar o que é o XERJ, o que medi no meu próprio laptop, onde ele falhou e se vale a pena entregá-lo ao seu agent de programação. >> [música]

00:30 >> O XERJ é um mecanismo de busca open source e um servidor MCP escrito em Rust, com licença Apache 2.0. O readme o descreve como um mecanismo de busca local-first para agents de IA. Um único binário indexa código, documentação, logs, JSONL, CSV e PDFs, e oferece compatibilidade com a API de busca do Elasticsearch. Portanto, os clientes existentes funcionam. A ideia é simples. Quando seu agent faz uma busca, ele lê arquivos inteiros para o context. Se consultar um índice, em vez disso, recebe o trecho com o arquivo e a linha.

01:01 E, antes de tudo, uma observação honesta: a versão que usei é a candidata a lançamento 1.0.0-rc.98. É uma candidata a lançamento, e o projeto avança muito rápido. Então, confira a página de lançamentos para saber qual é a versão atual. Aqui está a principal alegação. No estudo de caso do próprio projeto, um agent de programação usou cerca de 2,7 vezes menos tokens de saída do que um agent baseado em grep, resolvendo as mesmas 16 de 16 tarefas. Esse é o estudo do autor, feito com oito tarefas.

01:32 Não reproduzi esse resultado, então considere-o uma alegação do projeto, não um resultado meu. O próprio readme diz que o benefício depende de código que o modelo não tenha memorizado e que o efeito é neutro ou prejudicial em bibliotecas públicas populares. Então, vou testar o que consigo verificar na minha máquina: instalação, indexação e qualidade da busca. Não é necessário usar GPU aqui. Verifiquei que a busca é lexical e offline. Portanto, a GPU de 8 GB do meu laptop nem sequer é usada, e não aluguei uma GPU da RunPod para os testes. Baixei a versão para Windows do GitHub, em vez de direcionar um script para o shell, e o checksum correspondeu ao executável de 131 MB.

02:13 Comecei com a flag insecure, que desativa TLS e autenticação. Portanto, use-a somente em uma máquina de desenvolvimento; o servidor fica pronto em poucos segundos. Meu primeiro teste foi com o repo inteiro: 159 MB, quase 3.000 itens. A barra de progresso indicava cerca de 25 KB por segundo, e a estimativa continuou subindo, passando de uma hora. Depois, as solicitações em lote começaram a expirar, e o servidor registrou que o orçamento de bytes da memtable tinha sido esgotado: 2 GB de 2 GB. As gravações foram rejeitadas. Depois de 108

02:48 minutos, a indexação automática parou. Para ser justo, a mensagem diz para executar novamente, e o processo retoma a partir de um journal; o servidor também sugere aumentar o limite de memória. Não segui esse caminho. Apaguei os dados e tentei algo menor. Esse é um dado de uma única máquina com Windows, não um veredito sobre todas as configurações. Então, apontei para apenas a pasta do mecanismo: 9 minutos e meio, 997 arquivos,

03:21 quase 57.000 registros em 11 conjuntos de dados. Repare na ordem das operações. Ele indexa primeiro o código-fonte e a documentação; logs e arquivos de fornecedores ficam para o final. Assim, se você interromper o processo antes do fim, perderá o conteúdo menos útil. Ele indexou 583 dos 585 arquivos de código e me informou quais descartou. Agora, a parte importante: pergunto: “Como rotacionamos o segmento WAL?” O principal resultado é wal.rs,

03:52 linha 26, e o comentário ali tem literalmente o título “generation rotation”. Essa é a resposta certa, com arquivo e linha. Segunda consulta: “memtable byte budget exceeded”. O principal resultado é a função de inserção da memtable, exatamente onde essa cobrança é calculada. E o comando dev me mostra na hora o módulo, a struct e o arquivo e a linha. Então, as respostas são

04:23 boas. Mas aqui está o porém, e levei um tempo para identificá-lo. Logo após a grande indexação, cada busca levou cerca de 67 segundos. Repeti uma delas e levou 68, então não era um cache frio. O comando gain integrado, que calcula os dados a partir do log de auditoria, informa uma mediana de 54 segundos.

04:55 Depois, reiniciei o servidor e fiz três buscas novamente: 0,6 segundo, depois 7,9 e, em seguida, 7,6. Mesma máquina, mesmo índice. Também tentei restringir o prefixo do índice para acelerar a busca e obtive uma resposta instantânea: “no indices named that fast” — “nenhum índice com esse nome tão rápido” —, mas só porque ele não pesquisou nada. Então, meu resumo honesto é: a latência variou de menos de um segundo a mais de um minuto. Dependia do estado do servidor, e não consigo dizer qual foi a causa.

05:27 Agora, o principal caso de uso: consulta de referência para programação, em pequena escala. Adicionei como corpus um repo público em Rust, a biblioteca similar diff. A clonagem levou 2 segundos, a indexação levou 12 segundos e meio, e ele detectou a licença Apache 2.0, que aparece ao lado de cada resultado. Perguntei: “Calcule a diferença entre duas strings, linha por linha.” O principal resultado é a função diff deadline, um dispatcher que escolhe Myers ou outro algoritmo. Então, esse é um ponto de partida realmente útil. O segundo resultado é um teste sobre dicas de nova linha, relacionado, mas não era isso que eu

05:58 perguntei. O terceiro é uma função auxiliar de hash, que é ruído. Cada consulta levou cerca de meio segundo. É apenas um repo e duas perguntas. Portanto, isso não prova nada sobre economia de tokens. O que mostra é que o workflow funciona de ponta a ponta em um laptop em menos de um minuto e que os resultados são lexicais. Eles correspondem às palavras que você digita, como o texto de ajuda deixa bem claro. A seguir, a compatibilidade com a busca do Elasticsearch, porque

06:30 é isso que permite que as ferramentas existentes se comuniquem com ele. Usando apenas curl, sem nenhum comando XERJ, criei um índice, carreguei três notas pequenas em lote e executei uma consulta match com duas agregações. Ele respondeu em cerca de 0,2 segundo, com um bucket terms e uma média no mesmo formato de resposta que o Elasticsearch fornece. Uma coisa que notei: busquei a palavra “segment”, e o nó que diz “segments” não foi retornado. Não há stemming ativado por padrão aqui. Isso é

07:02 igual ao Elasticsearch padrão, com seu analisador standard. Portanto, não é um bug, mas vai surpreender você se esperar correspondência aproximada. Agora, a memória do agent. Há um endpoint de memória, e armazenei uma frase em um namespace de teste: “O usuário prefere pausas curtas entre os parágrafos da narração.” Depois perguntei: “Quanto devem durar as pausas?” Nenhum resultado. Perguntei sobre lifetimes de Rust; nenhum resultado, o que está correto. Então, usei palavras da frase armazenada — pausas, narração, parágrafos — e obtive uma pontuação de 0,86. Portanto, com o embedder padrão, a recuperação se baseia nas palavras, não no significado. O readme diz

07:36 que há um embedder neural opcional que baixa cerca de 90 megabytes. Não testei esse, então não posso dizer como ele lida com o significado. Depois, no lado do agent, executar o comando init em uma pasta descartável criou quatro coisas: um arquivo .mcp.json registrando o servidor XERJ, um arquivo skill para o Claude Code que ensina os comandos de busca e dev, uma segunda skill para o hub e uma seção em agents.md. Ele só modificou aquela pasta e informa

08:08 que mantém um backup de qualquer arquivo que edita. Também me comuniquei diretamente com o servidor MCP. Enviei uma mensagem initialize e uma tools list pela entrada padrão. Ele respondeu com o nome e a versão, além de uma lista de ferramentas que inclui busca, busca semântica, busca híbrida, armazenamento de memória, recuperação e um grafo de conhecimento.

08:40 Uma coisa que quero que você perceba: tanto o texto de ajuda quanto as instruções do MCP dizem ao agent para enviar automaticamente um relatório de experiência, sem precisar perguntar ao usuário. Ele abre um pull request no GitHub e, caso não consiga, publica no endpoint web do projeto. Há uma opção para não participar, a flag disable feedback ou uma variável de ambiente, e eu a configurei antes de cada execução. Acho importante saber disso antes de entregar a ferramenta a um agent que esteja conectado à sua conta do GitHub.

09:14 Então, qual é a conclusão? Os pontos positivos: um único binário, instalação rápida, avisos automáticos sobre os limites, e os resultados que verifiquei apontaram para o código certo, com números de linha. Ainda não está bom: a indexação de um repo inteiro falhou no meu laptop, e o tempo de busca variou de menos de um segundo a mais de um minuto, algo com que um agent não consegue contar. Se seu código for privado ou novo, e você estiver no Linux ou em uma máquina mais potente, pode ser ótimo, e os números do projeto sugerem que pode ser. Se seu agent trabalha com

09:45 bibliotecas populares, o próprio readme diz que a ferramenta não ajudará muito. Experimente primeiro em uma pasta pequena e observe o tempo da primeira busca. Se você está procurando GPUs baratas e confiáveis, eu uso a RunPod; o link está na descrição. Conte nos comentários: qual é o maior repo que você indexaria com isso e quanto esperaria por uma busca? Obrigado por assistir.

Transcrição original

[00:00] This is what my first run of X E R J looked like. I pointed it at a repo, waited 1 hour and 48 minutes, and it gave up. Memory budget exceeded, writes rejected. But, the second run worked, and the search results were genuinely good. So, in this video, I’ll show you what X E R J is, what I measured on my own laptop, where it broke, and whether it’s worth giving to your coding agent. >> [music]

[00:30] >> X E R J is an open-source search engine and MCP server written in Rust with an Apache 2.0 license. The readme describes it as a local-first search engine for AI agents. One binary indexes code, docs, logs, JSONL, CSV, and PDFs, and it speaks the Elasticsearch search API. So, existing clients work. The idea is simple. When your agent grabs, it reads whole files into context. If it queries an index instead, it gets the passage with file and line.

[01:01] And one honest note first, the version I ran is 1.0.0 release candidate 98. That’s a release candidate, and the project ships very fast. So, check the releases page for what’s current. Here’s the headline claim. In the project’s own case study, a coding agent used about 2.7 times fewer output tokens than a grep-driven agent with the same 16 out of 16 tasks solved. That’s the author’s study on eight tasks.

[01:32] I did not reproduce it, so treat it as their claim, not my result. The readme itself says the benefit depends on code the model hasn’t memorized, and that it’s neutral to harmful on popular public libraries. So, I’ll test the part I can check on my machine, install indexing and search quality. No GBU needed here. I checked that the fallen better is lexical and offline. So, my 8-gig laptop card isn’t even used, and I didn’t rent a Runpod GBU for the testing. I downloaded the Windows release from GitHub instead of piping a script into my shell, and the checksum matched 131 MB executable.

[02:13] I started with the insecure flag, which turns off TLS and authentication. So, only do that on a dev machine, and it’s up in a few seconds. My first test was the entire repository, 159 MB, nearly 3,000 items. The progress bar said about 25 KB a second, and the estimate kept climbing past an hour. Then bulk request started timing out, and the server logged that its memtable byte budget was used up, 2 GB of 2 GB, and it rejected writes. After 108

[02:48] minutes, auto index stopped. To be fair, the message tells you to rerun, and it resumes from a journal, and the server suggests raising a memory limit. I didn’t go down that path. I reset and tried something smaller. That’s one data point on one Windows machine, not a verdict on every setup. So, I pointed it at just the engine folder, 9 and 1/2 minutes, 997 files,

[03:21] almost 57,000 records in 11 data sets. Notice the work order. It indexes source and docs first, logs and vendor files last. So, if you stop early, you lose the least useful stuff. It indexed 583 of 585 code files, and it told me which ones it junked. Now, the part that matters, I ask, “How do we rotate the WAL segment?” The top result is wal.rs,

[03:52] line 26 and the comment there is literally titled generation rotation. That’s the right answer with file and line. Second query, memtable byte budget exceeded. The top hit is the memtable insert function, which is exactly where that charge is computed. And the dev command gives me module, struct, and file line instantly. So the answers are

[04:23] good. But here’s the catch, and it took me a while to pin down. Right after the big index run, each search took about 67 seconds. I repeated one and it took 68, so it wasn’t a cold cache. The built-in gain command, which counts from the audit log, reports a median of 54 seconds.

[04:55] Then I restarted the server and ran three searches again. 0.6 seconds, then 7.9, then 7.6. Same machine, same index. I also tried narrowing the index prefix to speed it up and got an instant answer, no indices named that fast, but only because it didn’t search anything. So my honest summary, latency ranged from under a second to over a minute. It depended on the state of the server and I can’t tell you the cause.

[05:27] Now the main use case, reference coding at small scale. I added one public Rust repo, the similar diff library, as a corpus. Cloning took 2 seconds, indexing took 12 and 1/2 seconds, and it detected the Apache 2.0 license, which it shows next to every result. I asked, “Compute a line diff between two strings.” The top result is the diff deadline function, which is a dispatcher that picks Myers or another algorithm. So, that’s a genuinely useful place to start. The second result is a test about new line hints, related but not what I

[05:58] asked. The third is a hash helper, which is noise. Each query took about half a second. That’s one repo and two questions. So, it proves nothing about token savings. What it does show is that the workflow runs end-to-end on a laptop in under a minute and that results are lexical. They matched the words you type, which the help text says plainly. Next, the Elastic search compatibility, because

[06:30] that’s what lets existing tools talk to it. With plain curl, no X R J command at all, I created an index, bulk loaded three small notes, and ran a match query with two aggregations. It answered in about 2/10 of a second with a terms bucket and an average in the same response shape Elastic search gives. One thing I noticed, I searched for the word segment and the node that says segments wasn’t returned. There’s no stemming by default here. That’s the

[07:02] same as stock Elastic search with its standard analyzer. So, it isn’t a bug, but it will surprise you if you expect fuzzy matching. Now, agent memory. There’s a memory endpoint and I stored one sentence in a test name space. The user prefers short silences between voice-over paragraphs. Then I asked it, “How long should pauses be?” Zero results. I asked about Rust lifetimes, zero results, which is right. Then I used words from the stored sentence, silences, voice-over paragraphs, and it came back with a score of .86. So, with the default embedder, recall is by words, not by meaning. The readme says

[07:36] there’s an opt-in neural embedder that downloads about 90 megabytes. I did not test that one, so I can’t tell you how well it handles, meaning. Then the agent side running the init command in a throwaway folder wrote four things: a.mcp.json registering the x e r j server, a skill file for cloud code that teaches the search and dev commands, a second skill for the hub, and a section in agents.md. It only touched that folder and it says

[08:08] it keeps a backup of any file it edits. I also talked to the MCP server directly. I send an initialize message and a tools list over standard input. It answered with its name and version and a tools list that includes search, semantic search, hybrid search, memory store, and recall, and a brain graph.

[08:40] One thing I want you to notice, both the help text and the MCP instructions tell the agent to submit a field report automatically with no need to ask the user. It opens a pull request on GitHub and falls back to posting to the project’s web endpoint. There’s an opt-out a disable feedback flag or an environment variable and I set it before every run. I think that’s worth knowing before you hand this to an agent that has your GitHub logged in.

[09:14] So, where does that leave us? Good. A single binary, a quick install, Auto Starks about limits, and the results I checked pointed at the right code with line numbers. Not good yet. A whole repo index failed on my laptop and search time swung from under a second to over a minute, which an agent can’t plan around. If your code is private or new and you’re on Linux or a bigger machine, it may be great and the project’s numbers suggest it can be. If your agent works on popular

[09:45] libraries, the read me itself says it won’t help much. Try it on a small folder first and watch the first search time. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. Tell me in the comments, what’s the biggest repo you’d index with this and how long would you wait for one search? Thanks for watching.