RAG, MCP ou fine tuning: quando usar cada um na empresa

A empresa decidiu que vai usar inteligência artificial com os dados dela. A partir daí, a conversa vira vocabulário. Um fornecedor propõe RAG. Outro diz que o certo é treinar um modelo próprio. Um terceiro fala em MCP. As três palavras aparecem na mesma reunião, apresentadas como alternativas concorrentes, e ninguém na mesa consegue dizer qual delas resolve o problema que a empresa levou para lá. Quem procura quando usar RAG ou fine tuning na empresa costuma estar nesse ponto: a decisão técnica chegou antes da pergunta de negócio.

O incômodo é legítimo, e a comparação usual não ajuda. Ela explica o que cada técnica é. Quase nunca explica o que cada uma cobra depois.

As três não respondem à mesma pergunta

RAG: o modelo consulta, não aprende

RAG é recuperação. O modelo continua o mesmo, e a cada pergunta o sistema busca trechos de documentos da empresa e entrega junto com a pergunta.

O conhecimento fica fora do modelo, num acervo que a empresa controla. Atualizar a política de férias é atualizar o documento, não refazer nada. Por isso RAG é a resposta certa para conhecimento que muda, e para todo caso em que a empresa precisa saber de onde veio a resposta.

Fine tuning: o modelo muda de comportamento

Fine tuning é treino adicional sobre um modelo existente, com exemplos da empresa. Ele não serve para ensinar fatos novos de forma confiável. Serve para ensinar forma: o jeito de classificar um chamado, o formato de saída que o sistema seguinte espera, o vocabulário de um setor, a estrutura de um parecer.

A distinção útil é essa. Fato que muda vai para o acervo. Comportamento que se repete vai para o treino. Quando a empresa usa fine tuning para guardar informação, ela cria um modelo que responde com convicção sobre uma versão congelada da realidade, e sem maneira prática de mostrar a fonte.

MCP: o caminho até a ferramenta e o dado

MCP não compete com as outras duas. É um protocolo de acesso, uma forma padronizada de a IA conversar com sistemas: o ERP, o banco de dados, a pasta de arquivos, a API interna. Enquanto RAG traz texto para dentro da pergunta, MCP permite que o modelo consulte um sistema vivo ou execute uma ação.

A diferença importa quando a resposta depende de dado transacional. Saldo de estoque agora, título em aberto hoje, status de um pedido. Isso não é documento, é consulta. Colocar esse tipo de dado num acervo de texto é garantir que ele vai estar errado na semana seguinte.

O que cada escolha cobra depois

A comparação por custo de implantação engana, porque o custo relevante não está na entrega. Está na manutenção.

RAG cobra curadoria. O acervo precisa de dono. Alguém decide o que entra, o que sai, qual versão vale e quem pode ver o quê. Empresa que joga a pasta inteira do servidor dentro de um sistema de recuperação descobre depois que a IA responde com base no procedimento revogado, ou entrega para um usuário um documento que ele não deveria alcançar. O controle de permissão precisa nascer junto, não depois.

Fine tuning cobra ciclo. Todo modelo treinado envelhece quando a regra muda, e aí é preciso refazer o conjunto de exemplos, treinar de novo, comparar com a versão anterior e decidir se melhorou. Isso é trabalho recorrente, com versionamento e critério de aceite. Sem isso, a empresa fica com um modelo que ninguém sabe explicar e ninguém tem coragem de trocar.

MCP cobra governança de acesso. No momento em que a IA passa a consultar sistema e executar ação, a pergunta deixa de ser técnica. Quem autorizou, o que ela pode escrever, o que fica registrado, o que acontece quando ela erra. É a mesma conversa que já existe para acesso de usuário, aplicada a um agente que trabalha rápido e não pede confirmação por conta própria.

Nenhuma das três é um projeto que termina. As três são sistemas que passam a existir, e sistema que existe precisa de quem sustente.

Um critério de decisão que cabe numa reunião

Quatro perguntas resolvem a maioria dos casos.

A resposta certa muda com o tempo? Se muda, é acervo consultado, não treino.

A empresa precisa que a saída venha sempre no mesmo formato, ou que o modelo siga um padrão próprio de julgamento? Aí há caso para treino, e normalmente sobre exemplos que a empresa já tem guardados.

A resposta depende de dado que vive num sistema transacional? Então o caminho é acesso ao sistema, e o documento não entra na conversa.

A resposta precisa ser rastreável, com a fonte visível para quem recebeu? Recuperação entrega isso. Modelo treinado não entrega.

Na prática, o desenho mais comum numa empresa média combina recuperação para norma e procedimento, acesso a sistema para número que muda hoje, e nenhum treino próprio no primeiro ano. Treinar modelo é a decisão mais cara de reverter, e é a que menos empresas precisam tomar cedo.

Quando nenhuma das três é a resposta

Existe um caso frequente, e ele é desconfortável: o problema apresentado não é de tecnologia.

Acontece quando o conhecimento que a IA deveria consultar não está escrito em lugar nenhum, e sim na cabeça de duas pessoas. Quando o procedimento oficial é diferente do que a equipe faz de verdade. Quando não existe critério claro para a decisão que se quer automatizar. Quando o campo obrigatório do sistema virou campo de qualquer coisa.

Em todos esses casos, qualquer das três abordagens funciona na demonstração e falha em produção. A IA aprende ou consulta o que existe. Se o que existe é ambíguo, ela devolve ambiguidade com aparência de resposta pronta, que é o pior formato possível para um erro.

O passo anterior, aí, é definir o processo e organizar o dado. Não é um passo glamouroso, e é ele que decide o resultado.

O que fica

Escolher entre RAG, fine tuning e MCP não é escolher fornecedor. É responder que tipo de pergunta a empresa quer que a IA resolva: conhecimento que muda, comportamento que se repete, ou dado que vive num sistema.

O que fica com quem faz essa separação antes de contratar é a capacidade de avaliar proposta com critério próprio, e de perguntar o que falta na maioria das apresentações: depois de pronto, quem mantém, com que frequência, e como a gente descobre que parou de funcionar. Estruturar essa decisão com a TI da empresa no controle, e não como passageira do projeto, é o trabalho do Zyon Lab.