Tools ou RAG: quando usar cada um
Num projeto usei tools para consultar dados que mudavam o dia todo; no meu site uso RAG sobre texto que quase não muda. O que decide entre os dois, e quando vale juntar.
Os dois sistemas de IA que mais conheço resolvem o mesmo problema de jeitos opostos. No case da CEDAE, a IA respondia perguntas sobre mais de 10 mil vistorias chamando funções prontas, as tools. No Nox, o chat deste site, ela responde sobre mim lendo trechos que a busca escolheu, o RAG. Nos dois casos o modelo precisa de informação que não estava no treino. A diferença está em que tipo de informação é essa.
Os dois mecanismos, em uma frase cada
- Tools (function calling): você descreve funções para o modelo, ele decide qual chamar e com quais parâmetros, o seu código executa e devolve o resultado. O modelo pede; quem busca é você.
- RAG (retrieval-augmented generation): antes de chamar o modelo, você busca no seu conteúdo os trechos mais parecidos com a pergunta e coloca no prompt. O modelo só lê o que você escolheu.
Quando tools ganham
Na CEDAE, as perguntas mais comuns se repetiam: quem é o proprietário deste imóvel, qual técnico fez esta vistoria, existe endereço duplicado, qual a situação de pagamento. Os dados por trás mudavam várias vezes por dia e a resposta precisava ser exata. RAG seria a ferramenta errada: indexar uma tabela que muda o tempo todo exige reindexar sem parar, e busca por semelhança devolve o parecido, não o certo. "Mais ou menos o proprietário" não serve.
Com tools, cada pergunta repetitiva virou uma função pronta. O modelo só escolhia a função e preenchia os parâmetros; algumas já levavam a própria consulta SQL. A consulta livre ficou para o que fugia do padrão. Ganhei três coisas: respostas exatas, porque vêm do banco na hora; menos espaço para o modelo inventar, porque ele não monta a consulta do zero; e controle, porque a função só faz o que eu escrevi. Tudo isso sobre um banco separado e só de leitura, então nenhuma tool podia alterar dado, por permissão e não por pedido no prompt.
Quando RAG ganha
O Nox responde sobre um conteúdo pequeno, em texto corrido, que muda quando eu publico algo: trajetória, cases, stack, notas. As perguntas são abertas ("por que ele saiu do Direito?") e quase nunca têm um campo exato para buscar. Aqui o RAG encaixa: gero os embeddings do site no build, busco por semelhança a cada pergunta e entrego os trechos mais próximos. Não há tabela, não há consulta, e o modelo não tem poder nenhum: ele só lê.
O ponto fraco apareceu na avaliação: o conteúdo estava em primeira pessoa e as perguntas vinham em terceira, e a busca não aproximava os dois. A correção foi dar a cada trecho um título em terceira pessoa. É o tipo de problema que só existe em RAG, porque depende de como o texto é recortado e descrito.
O critério que uso hoje
- O dado muda com frequência? Tools, consultando a fonte na hora.
- A resposta precisa ser exata (um número, um nome, um status)? Tools.
- As perguntas se repetem num formato previsível? Tools prontas para cada uma.
- O conteúdo é texto, muda pouco e as perguntas são abertas? RAG.
- O modelo vai ter poder de agir? Então a pergunta certa é qual o menor poder possível, e isso vale para os dois.
E quando juntar
Os casos mais interessantes pedem os dois. Na CEDAE, hoje eu colocaria RAG sobre o que é texto (os resumos das vistorias, os manuais da operação) e manteria tools para o que é dado estruturado. E deixaria o próprio RAG virar uma tool: o modelo decide quando buscar, em vez de eu buscar sempre. O passo seguinte é expor essas tools por um protocolo padrão, o MCP, para que qualquer assistente possa usá-las. Fiz isso neste site: as mesmas informações que o Nox usa estão disponíveis como ferramentas em /api/mcp.