Victor Lopes

Posted on Oct 10

RAG ou fine-tuning: a pergunta errada para quem constrói sistemas de IA

#ai #architecture #llm #rag

Um time de plataforma está validando um assistente baseado em LLM, ainda em fase de testes, para responder dúvidas de arquitetura dos desenvolvedores, com acesso aos ADRs (Architecture Decision Records) e à documentação interna. Numa rodada de avaliação, o próprio time percebe que o assistente recomendou um padrão de autenticação entre serviços que a empresa abandonou no ano passado e, de quebra, sugeriu chamar um endpoint de uma API interna já marcada como obsoleta. A resposta era plausível, bem escrita e tecnicamente defensável em termos gerais. Só contrariava uma decisão vigente.

A falha foi pega antes de chegar a qualquer usuário, e é justamente aí que a conversa seguinte importa. Duas propostas aparecem na mesa. A primeira: "Precisamos fazer fine-tuning com os nossos ADRs, para o modelo aprender as nossas decisões." A segunda: "Precisamos de RAG sobre os ADRs, para ele consultar a decisão vigente." As duas são razoáveis, e cada uma parte de uma teoria sobre o que falta ao modelo: uma supõe que falta aprender o conteúdo, a outra que falta consultar o conteúdo. Mas existe uma pergunta anterior que nenhuma das duas responde: o que, exatamente, deu errado nessa resposta?

Essa pergunta importa mais do que parece, porque a mesma recomendação desatualizada pode ter origens bem diferentes. O ADR que substituiu o padrão antigo pode nunca ter sido indexado. O ADR antigo, com status "superseded", pode ter sido recuperado no lugar do novo. Os dois podem ter sido recuperados e o modelo ter ignorado o contexto, respondendo a partir do que aprendeu sobre o padrão em documentação pública. Ou a pergunta pode ter sido genérica e a instrução do sistema nunca ter pedido para priorizar a decisão vigente. Cada causa pede uma correção diferente, e nenhuma delas se resolve, por si só, com a técnica que ganhou a discussão. Um fine-tuning com os ADRs de hoje, por exemplo, não ajuda quando a decisão for substituída amanhã. Isso não é exclusivo do nosso cenário: um relato de engenharia sobre sistemas RAG identificou sete pontos de falha distintos ao construir esse tipo de sistema.

Para entender como chegamos a esse debate, vale lembrar o contexto. Desde a chegada do ChatGPT, no fim de 2022, as organizações tentam colocar LLMs na frente do que antes vivia em wikis, pastas compartilhadas e documentos operacionais, com a promessa de tornar esse conhecimento mais acessível a quem precisa dele. No caminho, duas técnicas que eram tema de pesquisa viraram vocabulário do dia a dia: a geração aumentada por recuperação (RAG), proposta por Lewis et al. em 2020, e o fine-tuning, que métodos eficientes em parâmetros como o LoRA tornaram bem mais barato de executar. Quando duas ferramentas poderosas chegam juntas e resolvem o mesmo tipo de "dor" aparente, é natural que o mercado as coloque frente a frente. Assim nasceu o enquadramento padrão: RAG ou fine-tuning?

O problema desse enquadramento é que ele pede para escolher a resposta antes de combinar a pergunta. Existe pesquisa comparando as duas abordagens lado a lado, e ela merece uma leitura cuidadosa, não um slogan. O guia da OpenAI sobre otimização de acurácia, por exemplo, trata as duas como respostas a problemas diferentes e como abordagens "aditivas, não exclusivas". A pergunta, portanto, não deveria partir da técnica. Deveria partir da falha.

Figura 1. A diferença entre as duas conversas não está na técnica escolhida, e sim na etapa que foi pulada.

Este artigo defende essa inversão e propõe uma forma prática de fazê-la, separando o que um sistema precisa saber, como precisa se comportar e o que precisa fazer. É o primeiro passo de uma série sobre as decisões que acontecem além do modelo, onde um sistema de IA se torna confiável, ou deixa de ser.

1. O problema

Voltemos ao assistente de arquitetura. As duas propostas que apareceram na mesa têm algo em comum: ambas começam por uma técnica e só depois procuram o problema que ela resolveria. É uma inversão sutil, porque a conversa soa técnica e madura. Mas o caminho habitual da engenharia é o contrário: observar o sintoma, formular uma hipótese sobre a causa, testar e só então intervir. Em sistemas baseados em LLMs, o diagnóstico costuma ser a etapa mais fácil de pular.

Por que ele é pulado? Pela minha observação, podemos pensar em várias razões, mas três parecem as mais plausíveis. Primeiro, técnicas são tangíveis: têm ferramentas, tutoriais, orçamento e um nome que cabe num roadmap. Segundo, diagnosticar dá trabalho: exige abrir os traces, separar o que foi recuperado do que foi gerado, reproduzir a falha e entender em qual etapa ela nasceu. Terceiro, "RAG ou fine-tuning?" é uma pergunta que se responde com opinião, enquanto "o que causou esta falha?" só se responde com evidência.

O custo de escolher a técnica antes do diagnóstico aparece de pelo menos três formas.

A falha original continua lá. Se o problema era o ADR antigo sendo recuperado no lugar do novo, treinar o modelo com os ADRs não muda nada: o conteúdo errado continua chegando ao contexto. Se o problema era o modelo ignorar o contexto recuperado, recuperar mais contexto também não resolve. A intervenção é entregue, o time dá o problema por resolvido, e a recomendação desatualizada volta a aparecer na rodada de testes seguinte.

A intervenção pode piorar o sistema. O próprio guia da OpenAI sobre otimização de acurácia traz um exemplo em que o RAG "confundiu" o modelo ao adicionar ruído e reduziu a nota em quatro pontos. Do lado do fine-tuning, um estudo controlado de perguntas e respostas sem consulta externa mostrou que exemplos com conhecimento novo são aprendidos mais devagar e, depois de aprendidos, aumentam a tendência do modelo a alucinar. Esse resultado vale para aquele cenário específico e não deve ser estendido a todo fine-tuning. Ainda assim, mostra que "mais uma técnica" não é uma aposta sem risco.

A complexidade passa a ser sua. Cada técnica traz uma superfície nova de manutenção. O RAG exige indexação, atualização, ranqueamento e controle de permissões. O fine-tuning exige dados de treinamento, versionamento, reavaliação a cada mudança de modelo base e um plano para quando o conteúdo mudar. Se a causa real era uma instrução ambígua, o time pagou esse custo para resolver algo que um ajuste na instrução resolveria. Não por acaso, o mesmo guia da OpenAI recomenda começar pela engenharia de prompt.

Nada disso significa que uma das técnicas seja a vilã. A evidência é mista, e isso é parte do problema. Em comparações diretas de injeção de conhecimento, o RAG superou o fine-tuning não supervisionado, tanto para conhecimento já visto quanto para conhecimento novo (Ovadia et al., 2023). Já um estudo mais recente, com perguntas de múltiplos saltos sobre conhecimento novo, encontrou a maior acurácia geral no fine-tuning supervisionado. Ambos são preprints, com benchmarks pequenos ou sintéticos, e nenhum deles responde à pergunta do nosso time. Eles mostram que cada técnica tem o seu território, e que descobrir em qual território a falha está é o trabalho que a pergunta "RAG ou fine-tuning?" dispensa. Voltamos a esses estudos, com mais detalhe, na seção 5.

2. A hipótese de engenharia

Se o problema é começar pela técnica, a alternativa precisa ser algo que possa ser testado, e não apenas uma preferência de método. Proponho a seguinte hipótese de trabalho:

H1. Grande parte das falhas observáveis em um assistente como o nosso pode ser atribuída a uma de três categorias, conhecimento, comportamento ou execução, e cada categoria responde melhor a uma intervenção diferente.

Isto é uma hipótese, não um resultado. Ela não foi testada para este artigo. Para testá-la, um time poderia coletar as falhas de uma rodada de avaliação, pedir a revisores independentes que classifiquem cada uma e medir a concordância entre eles. Em seguida, aplicaria a intervenção indicada para cada categoria e compararia o resultado com a alternativa. A hipótese enfraquece se a concordância entre revisores for baixa, se a maioria das falhas não couber nas três categorias ou se todas pedirem a mesma intervenção. Os próximos artigos da série voltam a esse desenho experimental.

Há, porém, um refinamento que o nosso cenário sugere, e que costuma ficar de fora da discussão. Voltemos ao ADR substituído. Em seu texto original sobre o formato, Michael Nygard recomenda que decisões revertidas não sejam apagadas: elas ficam registradas e marcadas como "superseded", porque "ainda é relevante saber que aquela foi a decisão, mas que não é mais a decisão". Ou seja, um repositório de ADRs saudável contém, por desenho, conhecimento obsoleto. O que distingue o vigente do obsoleto é o status, a data e a relação entre os registros, e não o texto em si. Um modelo que só vê o texto não tem como saber.

Isso leva a uma segunda hipótese, complementar à primeira:

H2. Parte das falhas classificadas como "conhecimento" não é falta de conhecimento. É falha de curadoria: a informação certa existe, mas a organização do acervo não permite distinguir o vigente do obsoleto, e nenhuma técnica sobre o modelo corrige isso.

Se H2 for verdadeira, a primeira pergunta diante de uma falha de conhecimento deixa de ser "RAG ou fine-tuning?" e passa a ser "o acervo está em condições de ser consultado?". Curadoria, nesse sentido, é um conjunto de decisões de engenharia sobre o conhecimento, antes de qualquer decisão sobre o modelo. Quatro formas, em ordem crescente de custo:

Forma de curadoria	O que ela trata no nosso cenário	Custo e risco
Metadados e ciclo de vida	Status (proposto, aceito, depreciado, substituído), data, responsável e referência ao registro que o substitui; filtro dessas informações na hora da recuperação	Baixo. Exige disciplina de preenchimento e atualização
Fonte canônica e deduplicação	Garante uma única fonte de verdade por decisão, em vez de cópias divergentes em wikis e pastas	Médio. Exige dono e processo de revisão
Relações explícitas	Registra que o ADR 31 substitui o ADR 12 e que um padrão se aplica a um conjunto de serviços	Médio a alto. Exige modelar o domínio
Ontologia e grafo de conhecimento	Representa conceitos (decisão, padrão, API, serviço) e relações de forma consultável e verificável	Alto. Exige modelagem, construção e manutenção contínuas

Os dois últimos itens merecem um comentário, porque entram no território de ontologias. A definição clássica de Gruber descreve uma ontologia como uma especificação formal de uma conceitualização, ou seja, um acordo explícito sobre quais conceitos existem em um domínio e como se relacionam. No nosso caso, isso significaria declarar que "Decisão", "Padrão", "API" e "Serviço" são tipos de coisa, e que "substitui", "depende de" e "se aplica a" são relações entre elas. Com isso, a pergunta "qual é a decisão vigente para autenticação entre serviços?" deixa de ser uma busca por similaridade de texto e passa a ser uma consulta com resposta verificável.

A literatura sobre a combinação de LLMs com grafos de conhecimento aponta tanto o potencial quanto o custo. Pan et al. defendem que grafos de conhecimento guardam conhecimento factual de forma explícita e podem ajudar os LLMs com informação externa e interpretabilidade, e que os dois são complementares. Os mesmos autores lembram que esses grafos são difíceis de construir e estão em constante evolução. Na linha prática, o GraphRAG propõe usar um LLM para derivar um grafo de entidades a partir dos documentos e, com ele, responder a perguntas sobre o corpus inteiro, para as quais o RAG convencional tem dificuldade. Os autores relatam melhorias em abrangência e diversidade das respostas em conjuntos de dados de cerca de um milhão de tokens. Vale a ressalva: o GraphRAG foi desenhado para perguntas globais de síntese, e não para o problema de resolver qual decisão está vigente. Ele mostra que dar estrutura ao acervo pode ajudar, mas não demonstra que resolve o nosso caso. Essa continua sendo uma hipótese a testar.

Em resumo, a pergunta do artigo ganha duas camadas. A primeira é a de H1: em qual categoria a falha está? A segunda é a de H2: se for conhecimento, o acervo está curado o bastante para ser usado? Só depois dessas duas respostas faz sentido discutir RAG, fine-tuning ou ferramentas.

3. Três eixos: conhecimento, comportamento e execução

Se H1 for útil, ela precisa de categorias que um time consiga aplicar a uma falha real, sem depender de interpretação. Proponho três eixos, cada um definido por uma pergunta que se pode fazer ao sistema.

Figura 2. Cada tipo de falha aponta para uma capacidade diferente.

Conhecimento: o modelo tem acesso à informação certa?

É o eixo da recomendação desatualizada. O sintoma típico é uma resposta que cita uma decisão inexistente, vencida ou substituída. O teste diagnóstico é simples: se colocarmos manualmente o ADR vigente no contexto, o modelo acerta? Se acerta, o problema não é de capacidade do modelo, e sim de acesso à informação, e a conversa passa a ser sobre recuperação e curadoria (H2). Esse é o território que o guia da OpenAI atribui à otimização de contexto: o caso em que o modelo não tem conhecimento por ele não estar nos dados de treinamento. A intervenção natural é o RAG, com a ressalva de que ele próprio tem vários pontos de falha, da indexação à geração.

Comportamento: tendo a informação, o modelo a usa do jeito esperado?

Aqui o modelo tem o ADR certo no contexto e ainda assim responde mal. Ele não segue o formato exigido pelo time, não cita o status da decisão, mistura recomendação com opinião ou perde a estrutura esperada em respostas longas. O teste diagnóstico muda: com contexto correto e instrução clara, o erro de forma persiste de modo consistente? Se persistir, e só depois de esgotar instrução e exemplos, o fine-tuning passa a ser um candidato. O mesmo guia da OpenAI o associa a resultados inconsistentes ou com formato incorreto. Há uma sustentação conceitual para essa divisão: Gekhman et al. concluem que os modelos adquirem a maior parte do conhecimento factual no pré-treino, e que o fine-tuning ensina principalmente a usá-lo melhor. O RAFT mostra um uso concreto: treinar o modelo para ignorar documentos irrelevantes recuperados e citar os trechos relevantes, ou seja, o fine-tuning moldando como o modelo usa a recuperação, e não o que ele sabe.

Execução: a tarefa exige consultar um sistema ou agir?

Algumas perguntas não deveriam ser respondidas por texto, nem do modelo nem de um documento. Se a dúvida é "esta API está obsoleta hoje?", a fonte de verdade é o catálogo de APIs, não um ADR escrito meses atrás. O sintoma é uma resposta que mistura memória do modelo ou texto desatualizado com um dado que existe em um sistema consultável. A intervenção é uma ferramenta: o modelo chama o catálogo, recebe o status atual e responde com base nele. Trabalhos como o ReAct, que combina raciocínio e ação, e o Toolformer, em que o modelo aprende quando e como chamar APIs como calculadora e busca, mostram que ferramentas atacam o que o modelo não consegue manter por conta própria. Há uma fronteira porosa com o eixo do conhecimento, porque uma consulta a um catálogo também é acesso à informação. A diferença prática está na fonte: um acervo de documentos que precisa ser curado, de um lado, e um sistema autoritativo, consultável e atual, do outro. Ferramentas também trazem riscos próprios. A especificação do MCP, por exemplo, trata ferramentas como execução arbitrária de código e orienta tratar descrições de comportamento de ferramentas como não confiáveis, a menos que venham de uma fonte confiável.

O que fica fora dos três eixos

Os três eixos não cobrem tudo, e é importante dizer isso. Uma instrução ambígua e um raciocínio insuficiente também geram respostas erradas, e nenhuma das três capacidades resolve isso. Por isso a árvore de decisão da seção 7 começa por um passo zero, antes de qualquer técnica: melhorar a especificação da tarefa, decompô-la ou usar um modelo mais capaz. Isso também é coerente com o conselho da OpenAI de começar por engenharia de prompt. Essa limitação é uma das razões pelas quais H1 fala em "grande parte das falhas", e não em todas.

Há ainda um ponto sobre combinações. Os eixos descrevem a causa de uma falha, não uma escolha exclusiva de solução. O RAFT é um exemplo de fine-tuning (comportamento) trabalhando a serviço da recuperação (conhecimento), e o mesmo guia da OpenAI descreve as abordagens como aditivas, não exclusivas. O ganho de pensar em eixos é saber qual alavanca puxar primeiro e como saber se ela funcionou.

4. A arquitetura

Figura 3. O modelo é um componente. Conhecimento, comportamento e ações têm lugares diferentes no sistema.

Os três eixos da seção anterior ganham sentido prático quando os colocamos em uma arquitetura. A Figura 3 mostra o assistente de ADRs do nosso cenário e indica onde cada capacidade vive. A ideia central é que o modelo é um componente entre vários, e que cada eixo corresponde a um lugar diferente do sistema onde se pode intervir.

Siga o caminho de uma pergunta como "qual padrão de autenticação devemos usar entre serviços?".

Recuperação. A pergunta passa por um bloco que busca nos documentos e aplica filtros, por exemplo descartar ADRs com status substituído. É aqui que o eixo do conhecimento se manifesta no tempo de execução.
Base de conhecimento. Por trás da recuperação está o acervo, e é nele que a curadoria da seção 2 acontece: status, relações, fonte canônica. Uma recuperação ótima sobre um acervo mal curado continua devolvendo respostas desatualizadas.
Modelo. Recebe a pergunta e o contexto e gera a resposta. O eixo do comportamento vive aqui: instrução, exemplos e, quando justificado, um modelo adaptado por fine-tuning.
Ferramentas. Em vez de confiar em texto, o modelo pode consultar um sistema autoritativo, como o catálogo de APIs, e voltar com o dado atual. É o eixo da execução.
Resposta. O resultado volta ao usuário, idealmente com a fonte e o status das decisões usadas.

Essa leitura é coerente com uma tendência descrita na literatura de engenharia de IA. O grupo de Berkeley, em um post que descreve os "compound AI systems", argumenta que resultados de ponta vêm cada vez mais de sistemas com vários componentes, como chamadas ao modelo, recuperadores e ferramentas, e não de um modelo isolado, e que iterar no sistema costuma ser mais rápido do que retreinar o modelo. O guia da Anthropic sobre agentes parte da mesma ideia e recomenda buscar a solução mais simples possível, lembrando que muitas aplicações precisam apenas de uma única chamada bem otimizada ao modelo. A arquitetura da Figura 3 é, portanto, um teto de complexidade, não uma meta. Nem todo sistema precisa de todos os blocos, e começar sem eles é uma escolha legítima.

Duas observações sobre o diagrama. A primeira é que os blocos têm donos e ciclos de vida diferentes. O acervo muda quando uma decisão muda, o modelo muda quando o provedor muda ou quando há retreino, e as ferramentas mudam com os sistemas que elas consultam. Misturar essas camadas em uma só, por exemplo treinando o modelo com conteúdo que deveria viver no acervo, é o tipo de decisão que a seção 1 chamou de "complexidade que passa a ser sua". A segunda é que a figura omite, de propósito, a camada que atravessa todos os blocos: avaliação e observabilidade. Sem registrar o que foi recuperado, o que o modelo recebeu e qual ferramenta foi chamada, o diagnóstico das seções anteriores não é possível, e voltamos a escolher técnica por opinião. Esse tema merece artigo próprio dentro da série.

5. O que diz a evidência

Antes de propor uma árvore de decisão, vale perguntar o que a pesquisa já mostrou. A resposta curta é que existe evidência útil, mas ela é mais limitada do que os debates fazem parecer. Os estudos abaixo comparam as duas abordagens para injetar conhecimento. Esta seção se baseia nos resumos (abstracts) dos estudos, não nos artigos completos, então só cito os resultados que os próprios resumos declaram.

Estudo	Cenário	O que os autores relatam
Ovadia et al. (2023)	Tarefas intensivas em conhecimento, com conhecimento já visto e novo	Fine-tuning não supervisionado melhora um pouco, mas o RAG é melhor em ambos os casos. Os modelos têm dificuldade em aprender fatos novos por esse caminho
Soudani et al. (2024)	Perguntas e respostas sintéticas sobre conhecimento pouco popular, em doze modelos	O fine-tuning melhora em todos os níveis de popularidade, mas o RAG o supera por ampla margem, principalmente nos fatos menos populares
Balaguer et al. (2024), Microsoft	Estudo de caso em agricultura, com Llama2-13B, GPT-3.5 e GPT-4	O fine-tuning elevou a acurácia em mais de 6 pontos percentuais, e o RAG somou cerca de 5 pontos por cima. Os efeitos se acumularam
Zhang et al. (2024), RAFT	Adaptação a domínios específicos com RAG	Treinar o modelo para ignorar documentos irrelevantes e citar os relevantes trouxe ganhos consistentes em três conjuntos de dados
Mecklenburg et al. (2024), Microsoft	Eventos esportivos recentes	O fine-tuning supervisionado consegue injetar fatos, desde que os dados de treino sejam bem construídos. A cobertura foi desigual com escala por tokens e mais uniforme com escala por fatos
Yang et al. (2026)	Perguntas de múltiplos saltos sobre conhecimento novo, em três modelos de 7B	O RAG deu ganhos consistentes, mas o fine-tuning supervisionado teve a maior acurácia geral
Abonizio et al. (2025)	Injeção de conhecimento com poucos dados	A injeção por RAG tendeu a degradar o desempenho em conjuntos de controle mais do que os métodos paramétricos

O que dá para afirmar com cuidado. Para fatos novos ou raros, o fine-tuning não supervisionado sobre texto bruto é um caminho fraco, e o RAG foi superior em todas as comparações diretas que li. Ao mesmo tempo, o fine-tuning supervisionado com dados bem construídos consegue acrescentar conhecimento e, em um estudo de 2026, teve a melhor acurácia geral. E os efeitos podem se somar, como no caso da agricultura. A leitura mais honesta é de que as técnicas atuam em lugares diferentes, o que sustenta H1, e não de que uma vence a outra.

O que a evidência não diz. Há quatro limites que o leitor deve ter em mente:

Qualidade da evidência. Quase todos os estudos acima são preprints, e a maioria usa benchmarks pequenos ou sintéticos, como agricultura, eventos esportivos e entidades inventadas. Não há razão para supor que os resultados se transfiram para um acervo corporativo.
Nenhum deles testa o nosso problema. Os estudos medem se o modelo aprende ou recupera fatos. Nenhum mede a distinção entre decisão vigente e obsoleta, que é o centro do cenário do artigo, e portanto nenhum testa H2.
RAG não é sempre melhor. Além do estudo de Abonizio, o exemplo do guia da OpenAI mostra um caso em que o RAG reduziu a nota por ruído. O ganho depende de a recuperação trazer o conteúdo certo.
Efeitos de fine-tuning dependem do cenário. O aumento de alucinação relatado por Gekhman et al. foi medido em perguntas e respostas sem consulta externa, com conhecimento novo. Não se estende a fine-tuning para formato ou estilo.

Em resumo, a pesquisa justifica a tese de que as duas abordagens não competem no mesmo terreno, mas não substitui um teste no seu próprio acervo e com as suas falhas reais. É por isso que um dos próximos artigos da série trata do experimento.

6. Os trade-offs

Escolher uma capacidade é aceitar um conjunto de custos que não aparecem no slide da proposta. A tabela abaixo compara as três capacidades em seis dimensões, aplicadas ao assistente de ADRs. É uma comparação qualitativa: este artigo não mediu latência nem custo, e deixo essas medições para um artigo futuro da série, em vez de repetir números de origem duvidosa.

Dimensão	Recuperação (RAG)	Fine-tuning	Ferramentas
Atualização	Reindexar o que mudou. Quando um ADR é substituído, basta atualizar o acervo	Retreinar para refletir a mudança, e reavaliar	Imediata: a ferramenta consulta o sistema atual
Custo recorrente	Infraestrutura de indexação e mais texto de contexto a cada consulta	Dados de treino, treinamento, avaliação e nova rodada a cada mudança de modelo base	Integração e manutenção de cada ferramenta e do seu contrato
Latência	Acrescenta pelo menos uma etapa de busca antes da geração	Em geral não acrescenta etapas na inferência	Acrescenta idas e voltas a cada chamada
Auditabilidade	Permite apontar a fonte, mas a citação precisa ser verificada	Conhecimento difuso nos pesos, difícil de rastrear ou remover	Chamadas registráveis e reproduzíveis
Segurança	Permissões e vazamento entre contextos precisam ser tratados na recuperação	Dados de treino passam a fazer parte do modelo	Ferramentas são execução de código e exigem confiança e limites
Manutenção	Curadoria contínua do acervo (H2)	Atrelamento ao modelo base e ao ciclo de vida do provedor	Versionamento e compatibilidade das integrações

Alguns pontos da tabela merecem uma explicação.

Atualização e custo seguem a velocidade da mudança. No nosso cenário, decisões de arquitetura mudam com frequência razoável. Um ADR substituído hoje exige, no RAG, atualizar o acervo, e no fine-tuning, retreinar e reavaliar o modelo para que ele esqueça a decisão anterior. Quanto mais volátil o conteúdo, mais o custo recorrente do fine-tuning pesa. Por outro lado, métodos eficientes em parâmetros reduzem o custo do treino em si: o LoRA relata cerca de 10.000 vezes menos parâmetros treináveis e cerca de 3 vezes menos memória de GPU, em comparação com o ajuste completo do GPT-3 175B com Adam. Isso baixa a barreira de entrada, mas não elimina o custo de dados, avaliação e manutenção.

Auditabilidade não é o mesmo que verificabilidade. O RAG permite mostrar de onde veio a resposta, e isso é uma vantagem real sobre conhecimento difuso nos pesos. Mas citar uma fonte não garante que a fonte sustente a afirmação. Em uma auditoria humana de buscadores generativos, apenas 51,5% das frases estavam totalmente sustentadas pelas citações, e 74,5% das citações sustentavam a frase correspondente. São sistemas de 2023 e não assistentes corporativos, então o número não se transfere, mas o aviso permanece: uma citação precisa ser verificada, não apenas exibida.

Segurança entra pela recuperação. O OWASP trata vetores e embeddings como risco próprio no seu Top 10 de 2025 (LLM08), inclusive o vazamento de contexto entre usuários em bancos vetoriais compartilhados, e recomenda armazenamento com controle de acesso por permissão e registros imutáveis das recuperações. Em um assistente de ADRs, nem todo ADR deve ser visível a todos os times. Esse tema merece um artigo próprio na série.

Fine-tuning prende você ao ciclo de vida do modelo base. Provedores aposentam modelos. A Anthropic informa um aviso de pelo menos 60 dias antes da aposentadoria de modelos públicos, e a OpenAI, de pelo menos 6 meses para modelos de disponibilidade geral e cerca de 2 semanas para prévias, segundo as páginas consultadas em outubro de 2026. Um modelo ajustado sobre uma base que sai de linha precisa ser refeito. É uma inferência do autor, não uma regra documentada para todos os casos, mas é um custo que merece entrar na conta desde o início.

O ponto de equilíbrio entre essas dimensões depende do caso. Em geral, e esta é uma regra de bolso do autor e não um resultado de pesquisa, um acervo estável, com latência apertada e formato rígido de saída, pende para o fine-tuning, enquanto um acervo que muda toda semana e exige rastreabilidade pende para recuperação e ferramentas. O que a tabela entrega é a lista de perguntas a fazer antes de decidir, e é com ela que a árvore de decisão da próxima seção é construída.

7. O framework de decisão

$Árvore de decisão: da falha à intervenção. Passo 0: instrução ambígua ou raciocínio fraco levam à especificação da tarefa, decomposição ou modelo mais capaz. Passo 1: informação privada ou mutável leva a RAG e curadoria. Passo 2: forma e estilo levam a fine-tuning. Passo 3: cálculo ou ação levam a ferramentas.$
Figura 4. Da falha à intervenção. Síntese do autor, para validar com dados próprios.

A Figura 4 transforma as seções anteriores em um procedimento. Antes de usá-la, uma ressalva: ela é uma síntese do autor, construída a partir dos eixos da seção 3 e da divisão que a OpenAI faz entre contexto e comportamento. Não é uma taxonomia publicada nem foi validada empiricamente. Trate-a como ponto de partida para o seu time, não como regra.

Como usar. A árvore parte de uma falha concreta, já observada e registrada, nunca de uma preferência. A árvore tem um passo zero e três passos. Para cada pergunta, o teste diagnóstico da seção 3 diz como responder com evidência em vez de opinião:

A instrução é ambígua ou o raciocínio é insuficiente? Ajuste a especificação da tarefa (instrução, critérios de sucesso e formato de saída), decomponha a tarefa ou considere um modelo mais capaz. É o passo mais barato de verificar, e o guia da OpenAI recomenda começar pela engenharia de prompt.
A resposta depende de informação privada, recente ou mutável? Faça o teste do contexto manual: com a informação certa à mão, o modelo acerta? Se sim, o caminho é recuperação, e a primeira checagem é a curadoria do acervo (H2) antes de mexer no retrieval.
O conteúdo está certo, mas forma, estilo ou formato falham? Se o erro persiste com contexto e instrução corretos, fine-tuning é candidato, mas só depois de provar que instrução e exemplos não bastam. Esse "provar" é o tema de um dos próximos artigos da série.
A tarefa exige cálculo, consulta a um sistema ou ação? Prefira uma ferramenta que consulte a fonte autoritativa a uma resposta baseada em texto.

O passo zero vem primeiro porque corrigir a especificação da tarefa é o mais barato e porque nenhuma capacidade compensa uma tarefa mal especificada. Depois de cada correção, reavalie a falha original antes de seguir. E se nenhuma pergunta receber "sim", a conclusão é voltar ao diagnóstico: a falha pode ter mais de uma causa, ou a causa pode ainda não ter sido identificada.

Aplicando ao nosso cenário. A tabela mostra como quatro falhas hipotéticas do assistente de ADRs percorreriam a árvore. São exemplos ilustrativos, não resultados.

Falha observada	Teste diagnóstico	Caminho na árvore	Intervenção
O ADR que substituiu o padrão antigo nunca foi indexado	Com o ADR novo no contexto, o modelo acerta	Passo 1: sim	Indexar e corrigir o processo de ingestão
O ADR antigo, "superseded", é recuperado no lugar do novo	O modelo acerta quando só o ADR vigente é fornecido	Passo 1: sim	Curadoria: status e relação de substituição, filtro na recuperação
O modelo recebe o ADR certo e ainda recomenda o padrão antigo	Com contexto e instrução claros, o erro persiste, ou some com uma instrução melhor?	Passo 0 primeiro; depois passo 2	Reforçar a instrução de priorizar a decisão vigente; fine-tuning só se persistir
A pergunta é se uma API ainda está ativa hoje	A fonte de verdade é o catálogo, não um documento	Passo 3: sim	Ferramenta que consulta o catálogo de APIs

Observe o que as quatro linhas têm em comum: nenhuma pede, como primeiro passo, que se escolha entre RAG e fine-tuning. Três delas se resolvem sem tocar nos pesos do modelo. É exatamente o que a tese do artigo antecipa, mas vale repetir o limite: são quatro cenários escolhidos para ilustrar o procedimento, e não uma estimativa de com que frequência cada causa aparece na prática.

Checklist antes de agir. Em qualquer equipe, antes de aprovar uma intervenção, vale conseguir responder:

Qual é a falha, e ela está registrada com entrada, saída esperada e saída obtida?
Qual teste diagnóstico confirmou a categoria da causa?
Qual é a alternativa mais barata que já foi tentada?
Como saberemos que a intervenção funcionou, com qual conjunto de avaliação e qual critério definido antes de rodar?

8. O princípio de engenharia

Voltemos, uma última vez, ao time que viu o assistente recomendar um padrão arquitetural abandonado. Na versão da conversa que começa pela técnica, eles saem com uma decisão: fine-tuning ou RAG. Na versão que começa pela falha, saem com uma pergunta respondida: o que, exatamente, deu errado nessa resposta? A segunda versão é mais lenta no primeiro dia e mais barata em todos os outros.

O princípio que este artigo propõe cabe em uma frase: diagnostique a falha antes de escolher a técnica. Para aplicá-lo, três ideias:

Separe saber, comportar-se e fazer. Conhecimento, comportamento e execução são problemas diferentes (H1), e cada um aponta para uma capacidade diferente: recuperação, adaptação do modelo ou ferramentas. Antes deles, confirme que a tarefa está bem especificada.
Cure o acervo antes de culpar o modelo. Uma parte das falhas de conhecimento é falha de curadoria (H2): o acervo contém, por desenho, o vigente e o obsoleto, e nenhuma técnica sobre o modelo distingue um do outro sem status, datas e relações explícitas.
Exija evidência antes de intervir. Registre a falha, confirme a categoria com um teste diagnóstico, tente a alternativa mais barata e defina, antes de rodar, como saberá que funcionou.

Uma ressalva final, por coerência com o que o artigo pede. H1 e H2 são hipóteses de trabalho, não resultados: a pesquisa que revisamos mostra que as técnicas atuam em lugares diferentes, mas nenhum dos estudos testa a distinção entre decisão vigente e obsoleta, e a árvore de decisão é uma síntese do autor. O valor dela está em oferecer um procedimento que o seu time pode testar e corrigir com os seus próprios dados, não em substituir esse teste.

A pergunta "RAG ou fine-tuning?" não está errada por ser inútil. Está errada por chegar cedo demais. Quando o diagnóstico vem antes, ela volta como uma pergunta melhor: qual destas capacidades a minha falha está pedindo?

A série Beyond the Model

Este é o primeiro artigo da série Beyond the Model, sobre as decisões que transformam modelos de linguagem em sistemas de software confiáveis. Nos próximos, a série aprofunda os dois pontos que ficaram em aberto aqui:

Stop Adding RAG to Everything detalha a taxonomia de falhas: como uma resposta errada se classifica em conhecimento, recuperação, instrução, raciocínio, ferramentas ou comportamento, e por que cada causa aponta para uma intervenção diferente.
Before You Fine-Tune an LLM, Prove That You Need To mostra como transformar a decisão em experimento: baseline, conjunto de avaliação, métricas e critério de decisão definidos antes de treinar.

Se você já passou por uma conversa como a do início deste artigo, conte nos comentários qual foi a falha que motivou a discussão e qual intervenção o time escolheu. Esses casos são exatamente o material de que os próximos artigos precisam.