RAG ou MCP? A pergunta errada. Cole o prompt e monte os dois

Pessoal, a gente não está deixando o harness nem o LLM mais inteligente. Nem com RAG, nem com MCP, nem com fine-tuning.

É disciplina: contexto direcionado na hora certa. Aí a predição acerta mais. RAG, fine-tuning ou MCP? A pergunta já nasce torta. Não compete. Cada um mora numa camada.

RAG é a knowledge base. Logseq, Notion, Confluence, o doc do time. Política, contrato, runbook. Na hora da pergunta, a busca devolve o trecho. Com fonte. Precisa apontar o arquivo? Isso já é RAG. Quando a página muda, você atualiza a base. Não retreina o modelo.

Essa base não entra sozinha no IDE. MCP é o conector: o harness pede um trecho à busca. Sem o conector, a gente cola a nota no chat. Sem a base, o conector não tem o que buscar. O MCP não é o Logseq. É como o IDE chega nela.

Fine-tuning não é gravar a base nos pesos. É o jeito de escrever (tom, formato), se prompt e schema já não derem conta.

Ordem: base (Logseq e os outros) → busca (RAG) → o IDE chama a busca (MCP) → se o formato ainda vazar, aí sim fine-tuning.

O erro é pular etapa. Página velha no índice não se resolve treinando. Colar a nota no chat não é MCP. Um conector que além de buscar também grava, sem gente no meio, vira incidente.

Quatro perguntas abaixo. Negócio para aí. Quem constrói segue no código. A conta é a mesma.

Tabela de Conteúdo

• 1. Nomeia o problema antes da ferramenta
• 2. RAG: a knowledge base, não o peso
• 3. MCP: o conector até essa base
• 4. Fine-tuning: forma, não catálogo
• 5. Cole isto no seu agente
• 6. Context window grande não é desculpa pra jogar o repositório inteiro
• 7. Não use o mesmo modelo (LLM) para tudo
• 8. O que ganhamos com isso
• 9. Se for ligar no harness, lê isto depois

1. Nomeia o problema antes da ferramenta

Antes de ligar mais uma ferramenta, pergunta:

1. Você precisa de um texto que já existe (política no Notion, ADR, README, o contrato do webhook) e só quer o trecho certo? Isso muda em dias. É RAG, e o IDE pede pelo MCP. Ou você precisa do agora: o pipeline passou, o PR está aberto, o teste quebrou, o banco tem o registro? Isso não está na wiki. Está no CI, no git, no banco.
2. Se o agente errar, o pior é uma frase ruim no chat, ou ele pode gravar de verdade: merge, apagar arquivo, disparar pagamento, fazer deploy? Consultar e gravar podem ir no mesmo conector. Gravar precisa de gente no meio.
3. O trecho certo já está na conversa (você vê o arquivo, a regra, o JSON) e o que sai torto é só o formato: mistura finding com palpite, tom errado, label errada? Aí não falta fato. Falta jeito. Fine-tuning, depois de prompt e schema.
4. Vocês estão colando o repositório inteiro no chat para achar dois arquivos? Isso não é busca. É dump. Janela grande não acha o handler. Acha o meio.

Se o time grita fine-tuning e o fato nem entrou na conversa, vocês estão no item 1 fingindo que é o 4.

Quem constrói confere no histórico da conversa. Qual foi a primeira ferramenta que o agente usou nesta rodada? A tabela abaixo é o mesmo diagnóstico, em código.

No seu último chat de código, agora: qual foi a primeira ferramenta que o agente usou? Busca na knowledge base, Read/gh, algo que grava, ou “vamos treinar”? Se não foi o barato da tabela, a camada estava errada. As cenas mais abaixo são pedagógicas. A prova é esse histórico teu. O caso real de dez Read vs mapa está neste post.

Cartão + prompt: Antes de ligar RAG, MCP ou LoRA: vê a primeira ferramenta que o agente usou.

2. RAG: a knowledge base, não o peso

Logseq, Notion, Confluence, o README do retry. Mesma conta: o fato está na base. RAG recupera o trecho. Não treina o doc de novo.

Você pergunta: quantas tentativas no webhook?

Isso mora no ADR, no runbook, no comentário do handler. Não mora no gh pr view de agora. Busca a regra no doc. Consulta o PR aberto na ferramenta. Inverter é inventar política ou procurar ADR na API do GitHub.

Na prática (cena pedagógica: o padrão, não um PR teu):

você:    quantas tentativas no webhook?
agente:  3, linear  (citou README.md, seção Retry)
você:    abre o controller
código:  backoff exponencial, 5 tentativas, PR da sprint passada

O modelo não é burro. Ele leu o trecho que a busca entregou. A busca que foi no arquivo morto.

O mesmo vale pro timeout do client HTTP. README diz 30 segundos. Você abre o código: 5. Citação bonita. Doc morto. Fine-tuning não atualiza README. Tool de GitHub também não, se ninguém reindexou.

Modelo sabe muito de HTTP. Não sabe o contrato deste serviço, a não ser que esteja na base. RAG é isso: knowledge base + busca na pergunta. Logseq, Notion, Confluence, o README. Não é treinar de novo cada vez que o time muda o retry.

O que RAG não é: o status do Actions agora. Se muda a cada push, o índice mente educado.

O que você ganha: fato que atualiza sem treinar de novo, e dá pra apontar o arquivo. No trabalho: o modelo busca menos pra fora. Decide no contexto do time.
O que você paga: alguém tem que cuidar da base. Nota de janeiro no índice, política de março no jurídico: citação bonita, regra morta.

A base ainda não chegou no IDE. Isso é o próximo passo.

3. MCP: o conector até essa base

O Logseq não anda sozinho até o chat. O MCP é o conector: o harness chama o servidor de busca e pede o trecho. O RAG continua sendo a base. O conector leva até a busca. Outra tool no mesmo conector pode gravar. Não mistura as duas contas.

Sem esse conector, você cola a nota no chat. Com o conector, a tool de retrieve entra no turno. Se o servidor está verde e o transcript ainda começa em dez Read, você não ligou o RAG. Só instalou o conector.

Um host, duas tools?