No último ano, quase todos os operadores de armazém com quem falei me fizeram a mesma pergunta: queremos transformar nossos SOPs, manuais de equipamentos e ordens de serviço históricas em uma base de conhecimento interna com um bot de perguntas e respostas — vamos de RAG ou fazemos fine-tuning de um modelo de linguagem grande? Parece uma decisão de tecnologia, mas por baixo há três livros-caixa: quão rápido o seu conhecimento muda, quanto custa uma resposta errada e qual abordagem a sua equipe consegue realmente sustentar.

Olhando primeiro o panorama: com base na minha revisão de relatórios públicos do setor e estudos de caso de fornecedores, entre os projetos corporativos de perguntas e respostas sobre bases de conhecimento que realmente entraram em produção entre 2024 e 2026, o RAG (geração aumentada por recuperação) se tornou a arquitetura dominante de fato. A técnica foi introduzida pela Meta em 2020 (Lewis et al.), e a ideia central é simples: em vez de enfiar o conhecimento nos parâmetros do modelo, o modelo primeiro recupera documentos relevantes e depois gera respostas fundamentadas no que recuperou. O fine-tuning segue o outro caminho: continuar treinando o modelo com seus próprios dados de perguntas e respostas para que o conhecimento fique «pressionado» nos parâmetros. Os dois caminhos funcionam, mas suas estruturas de custo, perfis de risco e limites são totalmente diferentes — e o preço de escolher errado só aparece uns seis meses depois do lançamento.

Como o RAG realmente se parece num armazém: a rastreabilidade é o seu sangue

No início de 2025, um armazém 3PL no Inland Empire da Califórnia me mostrou o projeto deles. A instalação tem cerca de 120,000 pés quadrados, atende mais de 40 marcas de e-commerce e havia acumulado dezenas de milhares de ordens de serviço históricas e registros de exceções no seu WMS, além de várias centenas de páginas de SOPs. A abordagem deles foi RAG de manual: quebrar os documentos em pedaços, vetorizá-los e, na hora da consulta, recuperar os 5–8 trechos mais relevantes para o LLM compor uma resposta a partir desses trechos — com cada resposta trazendo suas fontes, até a seção do SOP ou o número específico da ordem de serviço.

Esse design de «fontes citadas» é todo o ponto. Um armazém é um ambiente fortemente movido a conformidade e auditoria: quando um inspetor de qualidade pergunta «qual é a proporção de amostragem deste lote de entrada?», ele não quer uma resposta bonita — quer uma resposta que possa constar no registro e ser rastreada se algo der errado. Respostas de RAG trazem procedência por construção; quando uma está errada, dá para apontar qual documento ficou obsoleto e corrigir o documento, não o modelo. Seis meses depois do lançamento, o ciclo de integração de novos contratados desse 3PL tinha caído de cerca de três semanas para cerca de dez dias. Uma ressalva: essa é a métrica interna de negócio deles, e o processo de treinamento em si foi otimizado em paralelo, então nem todo o mérito é do RAG — mas a direção é clara: o conhecimento virou algo encontrável e verificável.

O RAG tem outra vantagem que importa enormemente em ambientes de armazém: atualizações de conhecimento significam «trocar documentos», não «retreinar». Quando um SOP é revisado, você requebra e reindexa; passa a valer em minutos. Para armazéns cujo conhecimento muda o tempo todo, isso é quase decisivo.

Racks de servidores na sala de TI de um armazém

O caso de fracasso do fine-tuning: ele decorou a especificação e perdeu a fonte

O fine-tuning também tem seus adeptos — e seus casos reais de fracasso. Em meados de 2025, um centro de distribuição no leste da China quis «ensinar» a um modelo seus manuais de manutenção de equipamentos e reuniu vários milhares de pares de perguntas e respostas para o fine-tuning. Durante os testes, alguém perguntou a carga nominal de uma empilhadeira trilateral específica, e o modelo respondeu com total confiança — e o número estava errado. A capacidade real era 1.5 toneladas; ele disse 2 toneladas. A autópsia revelou que uma revisão desatualizada do manual tinha entrado nos dados de treinamento, e o modelo havia «memorizado» o erro sem qualquer consciência de que era um erro.

Esse é o defeito estrutural do fine-tuning para bases de conhecimento: uma vez que o conhecimento é comprimido nos parâmetros, ele não é rastreável nem corrigível localmente. Quando você encontra um erro, não dá para simplesmente editar um documento como o RAG permite — é preciso re-preparar dados, retreinar e re-validar tudo. Pior: um modelo com fine-tuning enuncia seus erros exatamente com a mesma confiança das respostas corretas. Num armazém, onde uma resposta errada pode machucar pessoas, danificar mercadorias ou quebrar a conformidade, essa confiança inexplicável é a propriedade mais perigosa de todas.

Para ser justo, o fine-tuning tem um lugar legítimo — só não na memorização de fatos. Ele se destaca em mudar o comportamento do modelo: fixar formatos de saída, unificar o tom de voz, aprender um padrão de raciocínio específico. Se a sua necessidade é «fazer o modelo falar como o manual de serviço da nossa empresa», o fine-tuning é uma boa opção. Se a sua necessidade é «fazer o modelo lembrar três mil páginas de manuais», você está usando a ferramenta errada.

RAG vs Fine-tuning: uma matriz de decisão

Juntando tudo, aqui está uma matriz de decisão que eu uso. Mapeie a sua própria situação nessas quatro dimensões e a resposta geralmente surge sozinha:

Dimensão Puxe para o RAG Puxe para o fine-tuning
Frequência de atualização do conhecimento Alta — mudanças semanais ou até diárias (SOPs, regras de promoção) Baixa — conhecimento estável por anos (princípios de equipamentos, regulamentações)
Necessidades de precisão e rastreabilidade Alta — respostas erradas são caras, fontes devem ser citadas (qualidade, segurança) Média a baixa — o estilo importa mais que a precisão factual
Volume de dados Muitos documentos, mas poucos pares de perguntas e respostas (RAG come documentos direto) Dezenas de milhares de pares de perguntas e respostas de alta qualidade disponíveis para treino
Custo e equipe Começo leve, paga por recuperação, a manutenção é só trocar documentos Custo de GPU do treino inicial mais retreinamentos repetidos, mais o overhead de gestão de versões

A dimensão do custo merece seu próprio cálculo. Usando preços públicos de nuvem como referência, um fine-tuning completo de um modelo aberto de classe 7B costuma sair na casa das centenas a poucos milhares de dólares em aluguel de GPU (confira o site oficial de cada fornecedor para os preços atuais) — mas isso é só para uma rodada de treino. O custo real vem depois: cada ciclo de atualização do conhecimento exige, em teoria, retreinar, re-testar e re-implantar uma nova versão do modelo, o que vira uma despesa anual recorrente. A curva de custo do RAG é invertida: construir o pipeline de recuperação exige esforço inicial de engenharia, mas a manutenção do dia a dia é só «trocar documentos», com custo marginal muito baixo. Uma curva é carregada no começo, a outra no fim — a comparação que importa é o total de três anos, não a fatura do primeiro mês.

A tese contraintuitiva: para armazéns que mudam rápido, o fine-tuning é um ativo que se deprecia

Aqui vai um julgamento contraintuitivo que vale a pena enunciar claramente: para armazéns cujo conhecimento se atualiza com frequência, o fine-tuning não é um «investimento único» — é um ativo que se deprecia. Cada revisão de SOP e cada mudança de equipamento torna obsoleta parte da «memória» do modelo anterior com fine-tuning, e não dá para dizer qual parte. Então você é forçado a um ciclo de retreinar–retestar–reimplantar, gastando cada vez mais enquanto o modelo persegue para sempre um alvo em movimento. O RAG se comporta ao contrário exatamente nesse cenário: quanto mais novo, fragmentado e disperso o conhecimento, maior a vantagem da arquitetura de recuperação.

Minha leitura da tendência, então: nos próximos dois a três anos, a forma padrão das bases de conhecimento de armazém será híbrida — RAG para o quê (fatos, rastreabilidade, atualizações em tempo real) e fine-tuning leve para o como (formato, tom, fraseologia do setor). As duas abordagens nunca foram um ou outro; são uma divisão de trabalho.

Uma pergunta merece observação mais longa, porém: qualquer que seja o caminho escolhido, a qualidade da base de conhecimento em si é o teto. SOPs vagos, registros de ordens de serviço com campos faltando, manuais de equipamentos com revisões emaranhadas — nenhum pipeline de RAG e nenhuma rodada de fine-tuning conserta problemas de «governança do conhecimento». Por trás do debate de arquitetura, a verdadeira linha divisória pode ser esta: o seu armazém tem mesmo conhecimento que valha a pena uma IA aprender? Essa é uma pergunta que toda empresa construindo uma base de conhecimento terá de responder para si mesma.

Por Dr. Chen, pesquisador de cadeia de suprimentos

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.