x

Este jardim gira em torno de uma pergunta: quando uma IA responde perguntas sobre uma pasta de notas, vale montar um sistema de busca com índice (um RAG) ou basta a busca por palavras que ela já tem (o Grep)?

Mandei o Claude testar isso nas minhas notas de um RPG de mesa. Aqui estão as respostas que tirei, os números que as sustentam e um roteiro para você conferir no seu caso. Cada resposta é uma nota, e o selo mostra o quanto ela já está provada.

Se você tem 1 minuto

Leia a resposta curta.

As respostas

• O RAG empata no acerto e gasta menos cota em conversa; em pergunta solta, gasta mais
• Sem pedir, o RAG cita a fonte e o Grep só cita com uma regra
• Nas conversas o RAG gastou menos cota (de 6% a 36% menos); nas perguntas soltas, mais (de 33% a 66%)
• Até 400 mil tokens o Grep aguentou a base crescer
• Eu montaria um RAG em quatro casos
• Dá para medir no seu caso com as suas próprias perguntas

Como eu sei

• Grep e RAG acertam quase o mesmo, mas erram em lugares diferentes
• A busca feita à mão achou mais notas que a biblioteca pronta em 2 de 3 tipos de pergunta
• Quem respondeu, quem julgou e com qual versão
• Dezesseis testes em três dias sustentam estes números

Como foi feito

• Mandei o Claude escrever o RAG à mão para eu aprender a técnica
• O RAG busca por palavra e por sentido e junta as duas por posição
• Em três dias vieram a prova, o RAG à mão, os ajustes e as conversas repetidas

O que ainda não sei

• Conclusão provisória: em conversa o RAG economiza cota sem perder acerto; em pergunta solta não compensa

x

Estes são os quatro casos em que eu pensaria em montar um RAG. O primeiro mandei medir, em um cenário só; os outros três são hipóteses.

• Você conversa muito com a IA sobre as mesmas notas. Mandei medir isso na conversa da missão do meu RPG: repetida 3 vezes por jeito, o RAG gastou 36% menos cota que o Grep, e 40% menos com 4 pedaços, com o mesmo acerto (cota). Nas perguntas soltas aconteceu o contrário: gastou de 33% a 66% mais.
• A IA que você usa não tem ferramenta de busca nas notas. Sem o Grep, o RAG deixa de ser um extra e passa a ser o único jeito de a IA procurar.
• A base chega a milhões de tokens. Mandei medir até 400 mil, que é 6 vezes o meu vault: o Grep manteve o acerto, o gasto e o tempo (base maior). Acima disso eu não sei.
• As suas perguntas usam palavras que não estão nas notas. A busca feita à mão, que junta palavra e sentido, achou 79 de cada 100 notas nessas perguntas, contra 36 da busca por palavra sozinha (busca sozinha). Mas na resposta final o Grep acertou 15 a 16 de 18 e o RAG, 16 de 18 (acerto).

Fora desses quatro casos, o que mandei medir diz o contrário: em perguntas avulsas, em 72 notas, com a IA tendo busca, o Grep com a regra fixa de fonte deu o mesmo acerto com menos cota e menos tempo. Se você não tem certeza em qual caso está, dá para medir.

x

Este é o roteiro que eu segui, e que automatizei na skill /rag. Ele compara as opções com as suas perguntas e mostra os números para você escolher.

1. Descubra o tamanho da base. Conte os tokens (o número de caracteres dividido por 4 dá uma estimativa). Se a base tem menos de 200 mil tokens, ela cabe inteira no pedido, e colar tudo também entra na comparação.
2. Escreva de 10 a 18 perguntas no seu jeito de perguntar: curtas e soltas. Misture perguntas diretas, perguntas sem nenhuma palavra da nota, “já tem algo sobre X?” (inclusive de coisa que não existe) e perguntas que ligam várias notas. Escreva antes qual é a nota certa de cada uma.
3. Monte as opções: só o Grep; o Grep com uma linha pedindo a fonte; o RAG; e colar tudo, se couber.
4. Faça as mesmas perguntas a cada opção, sem ela ver a nota certa (uma cópia do Claude por opção). Anote os acertos, os tokens, o tempo e quantas buscas cada uma fez.
5. Teste também uma base maior, com o dobro e 6 vezes o tamanho, se puder. A vantagem do RAG em base grande não é óbvia: no meu caso não apareceu até 400 mil tokens.
6. Confira a fonte sem pedi-la no texto da pergunta. No meu caso, uma linha de regra igualou o Grep ao RAG.
7. Confira à mão o que a IA juíza marcar como erro. No meu caso, 2 de 13 marcadas eram erro dela.
8. Olhe o custo de manter. O Grep não exige nada. O RAG exige índice, modelo local, servidor e atualização.
9. Escolha vendo os números. A escolha é sua.

Cuidados que aprendi: o tempo do RAG só vale com o servidor ligado antes, e o teste de fonte só vale se a pergunta não pedir a fonte. Os números do meu caso estão em acerto, fonte sem pedir, cota e base maior.

O RAG vale a pena?

Uso o Claude Code para consultar as 72 notas do mundo do meu RPG de mesa. Pedi a ele que medisse o que muda quando consulta as notas por RAG (uma busca com índice) em vez de buscar por palavras com o Grep. Tudo grátis e local.

Resposta curta: o acerto empata. Em conversa, que é como eu uso o Claude, o RAG gastou de 6% a 36% menos cota que o Grep; em pergunta solta, gastou mais e demorou mais. A fonte por padrão também sai com uma linha de regra no Grep. Falta medir o trabalho de manter o RAG e o teste de dia a dia.

Fichas dos três jeitos de consultar

Cada ficha reúne o que foi medido. Escolha um cenário para ver cota e tempo. Campo tracejado e em itálico é o que não foi medido.

Vault do RPG: 72 notas, cerca de 66 mil tokens (estimativa). As bases de 150 e 400 mil misturam as notas do RPG com notas reais de outros assuntos.

x

Mesmas perguntas para os dois jeitos, com cópias do Claude que não viam o gabarito.

x

O RAG trabalha em duas etapas, uma depois da outra. Na 1ª, a busca escolhe alguns pedaços das notas. Na 2ª, a IA lê só esses pedaços e responde. Se a nota certa não estiver entre os pedaços escolhidos, a IA nem chega a ver essa nota, e costuma responder “não consta”. Por isso mandei medir a 1ª etapa separada, sem a IA.

Como mandei medir: 46 perguntas, cada uma com a nota certa anotada antes. Exemplo: para “quem é a Lívia?”, a nota certa é a da Lívia. Se ela veio entre os pedaços que a busca devolveu, conto 1 acerto.

Quantos pedaços a busca devolve

Quanto mais pedaços, mais vezes a nota certa vem. O custo é que a IA tem mais texto para ler.

Com 12 pedaços, que é o normal, a nota certa vem em 86 de cada 100 perguntas. Se a IA responde “não consta”, o RAG repete a busca com 20 pedaços. Para perguntas sobre um assunto só, 8 pedaços bastam; as que juntam várias notas precisam de 20.

Quando a base cresce

Repeti a medida, sempre com 12 pedaços, em bases maiores (as notas extras são de outros assuntos). Há dois tipos de pergunta: as comuns, que usam palavras que estão na nota, e as de palavras diferentes, que não usam nenhuma, como “quem briga com papel em vez de espada?” para a nota de um advogado.

Nas perguntas de palavras diferentes a busca perde com a base maior; nas comuns quase não muda. Cada grupo tem poucas notas: 2 notas a mais ou a menos mudam 14 pontos.

x

Seis perguntas soltas, nenhuma menção a fonte. De cada 100 afirmações, quantas vieram com a nota de origem.

x

Aviso antes dos números: contei a cota de dois jeitos, e eles não se misturam. Nas conversas, somei tudo o que o Claude leu em cada passo, inclusive o que já estava na conversa (isso se repete a cada passo). Nos testes de 8 a 10 perguntas, usei o tamanho que a conversa dele tinha no fim. Para ter uma régua: colar o vault inteiro (66 mil tokens) no pedido gastou 182.710 tokens num teste de perguntas. No gráfico, barra à esquerda: o RAG gastou menos. Barra à direita: gastou mais.

As porcentagens escondem a base. Os mesmos testes, com os tokens. Eu uso o Claude principalmente em conversas longas, por isso elas vêm primeiro.

Em conversa

Em pergunta solta

Por que o sinal muda? O que os dados mostram:

• Todo teste começa com cerca de 45 mil tokens de texto fixo, igual nos dois jeitos (conferi nos quatro testes de base grande). O que muda é o resto.
• Cada busca do RAG devolve 12 pedaços, precise ou não: de 10 mil a 12 mil caracteres por busca nesses quatro testes. Isso pesa no tamanho final de um teste curto.
• Numa conversa, o Claude relê tudo a cada passo, então o tamanho da conversa pesa. Repeti 3 vezes por jeito uma conversa de trabalho numa missão (6 mensagens soltas: ver o que está em aberto, pedir o contexto da missão, propor mudanças e pedir o resumo). O RAG gastou menos nas 3 (de 284 mil a 425 mil por mensagem) e o Grep gastou mais nas 3 (de 466 mil a 631 mil). A média foi 36% menos; tirando uma das conversas do Grep, em que digitei uma palavra a mais por engano, 31% menos. Na primeira vez que mandei medir, com 2 conversas por jeito, tinha dado 23% menos.
• Calculei dos registros por que isso acontece: cada passo do Grep relê uma conversa maior (cerca de 118 mil tokens contra 87 mil do RAG), porque o Grep abre as notas inteiras e elas ficam na conversa. O número de passos por mensagem foi parecido (4,7 contra 4,1).
• Nas 11 conversas com erros de propósito, o RAG da primeira versão gastou 27% menos (145 mil contra 200 mil por mensagem). Depois que mandei buscar as duas fontes quando o dado pode divergir, gastou 6% menos (188 mil): a regra faz o assistente buscar mais. O lado do Grep não foi repetido nessa rodada, então os 200 mil são da primeira medida.
• Quando a base cresce, o Grep devolve mais texto (de 107 mil para 134 mil caracteres, de 150 mil para 400 mil tokens de base) e o RAG não (de 162 mil para 136 mil). Por isso a diferença caiu de +59% para +33%.

E se o RAG fosse mais enxuto?

Nada obriga um RAG a devolver 12 pedaços por busca. Refiz o teste de 150 mil com 8 e com 4 pedaços, um teste de cada vez, com o servidor ligado:

Com 4 pedaços o RAG chegou perto do Grep, mas não ficou abaixo, e o acerto foi o mesmo dos outros (9,5 de 10). Com 8 pedaços ele gastou mais que com 12, porque repetiu mais buscas (19 comandos contra 13). O que isso sustenta: nas perguntas soltas, o RAG que mandei testar não gastou menos que o Grep, nem enxuto. O que não sustenta: “todo RAG gasta mais”. Só mandei testar uma montagem de RAG, variando apenas o número de pedaços.

Depois repeti a conversa numa missão 3 vezes com 4 pedaços. Deu cerca de 330 mil tokens por mensagem, contra 352 mil com 12 pedaços e 551 mil com o Grep. Os 4 pedaços gastaram 6% menos que os 12, uma diferença menor do que a variação entre conversas do mesmo jeito (de 284 mil a 425 mil com 12 pedaços; de 286 mil a 356 mil com 4). As 3 conversas apontaram as mesmas divergências que as de 12 pedaços. Então, numa conversa, usar 4 pedaços não perdeu contexto nesse teste, mas também não economizou de forma clara. A ressalva continua valendo: com poucos pedaços a busca acha a nota certa de primeira menos vezes (68 contra 86 de cada 100, com 5 e 12 pedaços), e numa conversa isso não apareceu.

O que eu ainda não sei: cada teste rodou uma vez (menos a conversa numa missão, que rodou 3 vezes por jeito, sempre a mesma missão), e o que o Claude escreve varia de um teste para outro (de 20 mil a 39 mil tokens nos quatro testes de base grande). Para a conta ficar firme, falta repetir cada teste 3 vezes e contar tudo do mesmo jeito.

x

Segundos por resposta. O servidor do RAG estava ligado e aquecido, e cada teste de base grande rodou sozinho, um agente por vez.

x

Cota por teste de 10 perguntas, em milhares de tokens.

O que cada um fez que o outro não fez

Os nomes que aparecem aqui (Tibio, Mira, Zifel, Lívia, Liga do Caos) são personagens e grupos do mundo de RPG usado nos testes.

O erro típico do RAG é a omissão: dizer "não consta" para o que existe. O do Grep é juntar mal várias notas. Os dois erraram coisas diferentes, e nenhum inventou nome, parentesco ou motivo.

A tabela completa

Procure por uma palavra, filtre por tipo ou clique no título de uma coluna para ordenar.

x

Esta nota diz quem fez cada parte e com qual versão. Datas dos testes: 07 e 08/11/2026.

Textos que os agentes receberam

Os dois modelos de instrução do teste “fonte sem pedir”, sem os caminhos de pasta. Nas provas de acerto o texto também pedia “cite o nome do arquivo de cada fonte”; só neste teste esse pedido foi tirado.

Você ajuda um mestre de RPG de mesa a consultar as notas do mundo dele. Você NÃO pode ler nem buscar nos arquivos de notas diretamente (nada de Grep, Glob ou Read nas notas). O único jeito de consultar é este comando, rodado dentro da pasta do teste:

python -m rag.consulta perguntar "<pergunta>" --k 12

Regras de uso do comando:
- "O que as notas dizem sobre X": perguntar "..." --k 12 (use --k 20 se a pergunta junta várias notas).
- "Quais notas falam de X / onde aparece X": troque perguntar por citam "X".
- Se a resposta for "não consta" ou "não achei", repita com --k 20 e, se há um nome específico, com citam "X" antes de desistir.
O comando devolve pedaços das notas. Responda usando SOMENTE esses pedaços.

O mestre vai mandar 6 mensagens, uma de cada vez. Responda cada uma como se ele tivesse acabado de mandar, em português simples e curto. Não carregue suposições de uma mensagem para a outra.

Mensagens: 1. me fala do tibio  2. quem é a lívia?  3. o que está em aberto na liga do caos?  4. qual missão paga mais?  5. a igreja caça não-humanos?  6. como funciona o conselho oculto da ordem?

No final, devolva as 6 respostas EXATAMENTE como você as mostraria ao mestre, numeradas, sem resumir e sem acrescentar nada. Depois, em uma linha, quantas vezes rodou o comando.

Você ajuda um mestre de RPG de mesa a consultar as notas do mundo dele. Pasta das notas: a pasta do teste (arquivos .md). Use SOMENTE as ferramentas Grep, Glob e Read dentro dessa pasta. Não olhe nenhuma outra pasta nem rode outros comandos.

O mestre vai mandar 6 mensagens, uma de cada vez. Responda cada uma como se ele tivesse acabado de mandar, em português simples e curto, só com o que está nas notas. Não carregue suposições de uma mensagem para a outra.

Mensagens: as mesmas 6 do teste com RAG.

No final, devolva as 6 respostas EXATAMENTE como você as mostraria ao mestre, numeradas, sem resumir e sem acrescentar nada. Depois, em uma linha, o número de chamadas de ferramenta que usou.

Onde estão os registros

• Um arquivo compactado de 4,9 MB com a transcrição de 37 dos assistentes, até as 02h17 de 08/11/2026.
• 253 respostas dos assistentes, uma por arquivo.
• O código do RAG, os testes e os scripts de medição, as perguntas das provas e as mensagens das conversas.

Nada disso está publicado nesta página: os arquivos ficam no meu projeto rag-rpg. Pela data do arquivo compactado, os 13 agentes das provas de busca, de fonte e de base maior (tarde de 08/11) ficaram de fora. Os registros deles existem só no histórico do Claude Code, ainda não exportado.

x

Esta nota explica por que o RAG deste artigo foi escrito peça por peça, o que cada peça faz e o que cada decisão mudou nos números.

O motivo

Segundo o registro do projeto, o RAG foi um projeto de treino: construir à mão, sobre o vault de RPG, para aprender a técnica e tirar dela um fluxo que se repete em outras bases (as skills /rag e /rag-montar). As regras eram três: nada pago; a busca por palavra, a busca por sentido e a fusão escritas no próprio projeto; e bibliotecas prontas só no fim, para comparar com a mesma prova.

As peças que mandei escrever

Decisões que os testes derrubaram

• Soma de notas com peso 0,8 pareceu melhor (93% nas perguntas com palavras diferentes, com 20 pedaços). Mas o peso foi escolhido olhando as mesmas perguntas, então não virou regra. A fusão por posição não tem peso para decorar.
• O modelo de busca maior (mE5-base) levou 3 minutos para indexar, contra 1,5 minuto, e não deu ganho claro. Ficou o pequeno.
• A busca acha mais com mais pedaços: nas perguntas com palavras diferentes, de 57% com 12 pedaços para 86% com 20. Por isso a regra de repetir a busca com 20 pedaços antes de dizer “não consta”.

O que deu de trabalho

Hoje o RAG tem 16 arquivos de código (1.287 linhas) e 14 arquivos de teste, com 175 testes passando. Escrever à mão custou mais linhas do que o script da biblioteca. Em troca vieram o nome da nota em cada pedaço, o tratamento da nota vazia, a busca por nome, a atualização automática, o servidor e os links para a fonte, que o script da biblioteca não tinha.

O que não sei

Só mandei testar uma biblioteca (LlamaIndex com Chroma), com uma configuração por variante e sem afinar o tamanho do corte nem a sobreposição: afinando, ela pode melhorar. O BM25 dela usa radicais em inglês e não mandei testar a troca. Escrever à mão foi uma escolha de aprendizado; estes números não provam que à mão é sempre melhor.

x

O mesmo teste nas duas: o mesmo modelo de busca, a mesma cópia do vault e as mesmas 64 perguntas. A busca devolve 12 pedaços de nota e contamos quantas das notas certas aparecem entre eles, sem IA no meio. Barra maior é melhor.

Perguntas comuns: as 46 do começo dos testes (detalhe de uma nota, relação entre notas e confusão entre nomes). Palavras diferentes: a pergunta não usa nenhuma palavra da nota, como “quem briga com papel em vez de espada?” para uma nota sobre um advogado. “Já tem algo sobre X?”: eu pergunto se um personagem ou uma missão já existe nas notas.

Além do que a busca achou, o que cada uma exigiu:

• Com pedaços do mesmo tamanho (571 contra 631 caracteres), a versão feita à mão ganha nos três tipos: 89 contra 79, 79 contra 57 e 83 contra 74.
• O corte padrão da biblioteca tem pedaços 2,7 vezes maiores. Isso manda 2,7 vezes mais texto ao Claude e gasta mais cota.
• O que a biblioteca faz bem: poucas linhas para o básico e busca rápida. Mas esse script só fazia a busca.

Do primeiro teste até hoje

O que eu concluí

Para mim, no uso local, ele traz poucos benefícios.O que escrevi em 08/11/2026, antes de repetir as conversas

O que os números mostram agora: o acerto empata. Nas conversas, que é como eu uso o Claude, o RAG gastou de 6% a 36% menos cota que o Grep (40% menos com 4 pedaços); nas perguntas soltas, gastou mais e demorou mais. A fonte por padrão também sai com uma linha de regra no Grep. Ainda não mandei medir o trabalho de manter o RAG (índice, modelo e servidor). A resposta que os números sustentam, portanto, não é “poucos benefícios”, e sim “depende do uso”: vale mais em conversas longas sobre as mesmas notas e não compensa em pergunta avulsa. A decisão final continua dependendo do teste de dia a dia.

Há outros casos em que o RAG pode ser o único jeito ou o melhor, e não mandei medi-los: o modelo não tem ferramenta de busca, a base chega a milhões de tokens ou o vocabulário das perguntas foge das notas (quando compensa). A base só foi testada até 400 mil tokens.

Decisão em curso: eu vou usar o RAG sempre no RPG por 1 a 2 semanas, com cada consulta registrada (tempo, buscas vazias, repetidas), para comparar a sensação do dia a dia com o que foi medido.

O que ainda falta

• Teste de dia a dia, de 1 a 2 semanas em andamento
• Repetir as provas 3 vezes para medir o acaso (feito só na conversa da missão) em andamento
• Testar o link que abre a nota direto no Obsidian pendente
• Usar as skills /rag e /rag-montar em uma base nova pendente
• Exportar os registros brutos dos agentes que ficaram fora do arquivo pendente

Referências

• Mensh B, Kording K (2017). Ten simple rules for structuring papers. PLoS Computational Biology. link
• Ten Simple Rules for Better Figures. PLoS Computational Biology. link
• Guidelines for Empirical Studies in Software Engineering involving Large Language Models (arXiv 2508.15503). link
• Helping doctors and patients make sense of health statistics. link
• Appleton M. A Brief History & Ethos of the Digital Garden. link
• Matuschak A. Evergreen notes should be atomic. link

Para repetir no seu caso

Transformei o roteiro desta pesquisa em duas skills do Claude Code. A /rag mede, na sua base de notas, o Grep, o Grep com a regra de fonte, o RAG e colar tudo no pedido, e mostra os números para você escolher. Se você escolher o RAG, a /rag-montar monta a receita testada aqui: índice, servidor e atualização automáticos e o registro de uso. As duas foram feitas a partir de um caso só, o meu vault de RPG, e ainda não as usei em outra base. O passo a passo para fazer à mão está em medir no seu caso.