RAG e fine-tuning resolvem problemas diferentes. Em banking, onde a tolerância ao erro é praticamente zero e a informação muda mês a mês, a arquitetura que vence é RAG + APIs diretas: conhecimento atualizável sem retreinar, dados transacionais em tempo real e respostas rastreáveis por fonte. O fine-tuning fica como camada complementar de tom e terminologia.
Implementar Inteligência Artificial em um banco não é a mesma coisa que implementá-la em qualquer outra indústria. As margens de erro são praticamente nulas, a informação muda o tempo todo e as consequências de uma resposta incorreta podem ser concretas e custosas. O desafio real não é acessar um LLM poderoso: esses existem e são cada vez mais capazes. O desafio é fazer com que esse modelo saiba o que o seu banco precisa que ele saiba, no momento em que precisa. Para resolver isso, há duas estratégias principais: RAG (Retrieval-Augmented Generation) e fine-tuning. As duas abordam o problema por ângulos diferentes, e escolher errado pode comprometer todo o projeto. Neste post nós as explicamos em profundidade e argumentamos por que, no contexto de agentes bancários, a decisão é bastante clara. Primeiro: o que é um LLM e por que ele sozinho não basta Um LLM (Large Language Model) é um modelo estatístico treinado sobre quantidades massivas de texto. É a tecnologia por trás de ferramentas como ChatGPT, Gemini ou Claude, e se tornou a face mais visível da IA generativa. Mas na indústria bancária, usá-lo diretamente sem infraestrutura adicional tem limitações concretas que não dá para ignorar. A primeira é temporal: o conhecimento de um LLM tem data de corte. O que aconteceu depois do seu treinamento, para o modelo simplesmente não existe. Em banking, onde as taxas, os produtos e a regulação podem mudar de um mês para o outro, isso é um problema sério. A segunda é de alcance: o modelo não tem acesso a sistemas externos nem a dados transacionais. Não sabe o saldo de nenhum cliente, não conhece o status de uma solicitação de crédito e não consegue consultar o histórico de movimentações de uma conta em tempo real. Por mais capaz que seja o modelo base, sem integração externa sua utilidade em um ambiente bancário é limitada. A terceira é de domínio: com documentação extensa, não basta colocar tudo no prompt. E em domínios específicos, o modelo pode gerar respostas incorretas com aparente confiança, o que em banking tem consequências diretas. RAG e fine-tuning são as duas estratégias principais para atacar essas limitações. Mas fazem isso de formas muito diferentes. Fine-tuning: especializar o modelo O fine-tuning consiste em continuar o treinamento de um modelo base usando dados próprios: documentos internos, conversas de exemplo, terminologia do domínio. O resultado é um modelo que "fala" a língua da organização com mais naturalidade, entende o jargão interno e mantém um tom consistente com a marca. Tecnicamente, o processo modifica os pesos do modelo. Isso significa que o conhecimento fica gravado no momento do treinamento. Técnicas como LoRA permitem fazer isso de forma mais eficiente, modificando apenas um subconjunto de parâmetros. Ainda assim, há um risco concreto que vale a pena ter em conta: o catastrophic forgetting, que ocorre quando o modelo perde capacidades gerais ao se especializar demais. Quando o fine-tuning faz sentido? Para adaptar estilo, tom e a compreensão da terminologia interna, pode ser uma camada complementar valiosa. Mas como estratégia central de conhecimento, tem um problema fundamental: o conhecimento que ele injeta fica estático. O modelo treinado hoje não saberá nada do que mudar amanhã. Em banking, esse é o problema central. RAG: separar o conhecimento do modelo O RAG (Retrieval-Augmented Generation) funciona de uma maneira diferente: em vez de incorporar o conhecimento ao modelo, o sistema o busca no momento em que precisa dele. O fluxo é o seguinte: a consulta do usuário é convertida em um vetor, comparada contra uma base de documentos indexados e o sistema recupera os fragmentos mais relevantes. Esses fragmentos são passados ao modelo como contexto, e o modelo gera uma resposta baseada nessa informação. A base de documentos, que tipicamente vive em uma vector database como Pinecone, Weaviate ou pgvector, pode ser atualizada de forma independente do modelo. Quando a documentação do banco muda, ela é reindexada. O modelo continua sendo o mesmo. Não é preciso retreinar nada. Para consultas que exigem dados transacionais em tempo real, o RAG é complementado com chamadas diretas a APIs externas a partir do backend. O LLM recebe tanto o contexto recuperado quanto o resultado dessas consultas, e sintetiza uma resposta que combina ambas as fontes. Essa combinação, RAG + APIs diretas, é o que permite construir um agente bancário realmente funcional. Por que RAG + APIs diretas vence em banking Um agente bancário tem requisitos que definem rápido qual arquitetura é viável. Trabalha com informação que muda com frequência. Precisa acessar dados do cliente em tempo real. E tem tolerância praticamente zero ao erro: confundir um saldo ou inventar uma condição de crédito tem consequências concretas para o cliente e para o banco. O fine-tuning como estratégia central não escala bem nesse contexto. O conhecimento mais crítico é dinâmico, e o fine-tuning o congela. Mantê-lo atualizado exige retreinar periodicamente, com o custo computacional e operacional que isso implica. E mesmo assim, não resolve o acesso a dados transacionais: um modelo treinado com os produtos do banco não sabe o saldo de nenhum cliente em runtime, então a integração externa você tem que resolver de qualquer forma. A combinação RAG + APIs diretas resolve as duas dimensões do problema ao mesmo tempo. O knowledge base, produtos, condições, FAQs, regulação, é mantido em uma vector database atualizável sem tocar no modelo. As consultas em tempo real são resolvidas chamando diretamente as APIs do banco a partir do backend. O LLM atua como camada de síntese: recebe contexto recuperado mais dados transacionais e gera a resposta. Há outro fator que, em ambientes regulados, não é pouca coisa: a auditabilidade. Com RAG, cada resposta é rastreável. Dá para saber de quais documentos veio o contexto e qual versão estava indexada no momento da consulta. Isso é algo que um modelo fine-tunado não consegue oferecer com facilidade. Como o stack se parece em produção O fluxo de um agente bancário com RAG + APIs diretas funciona assim: Quando o usuário envia uma mensagem, a consulta é vetorizada para buscar contexto relevante na base documental, em paralelo com qualquer chamada de API que a consulta exija. O sistema de retrieval recupera os fragmentos mais relevantes, produtos, condições, FAQs, regulação, e se a consulta exigir dados em tempo real, são chamados os endpoints correspondentes: saldo, movimentações, status de solicitações. Por fim, o LLM recebe o contexto recuperado mais os dados de API e gera a resposta. Ele não lembra entre conversas: raciocina sobre o que recebe em cada turno. É uma arquitetura com mais peças do que um prompting simples, sim. Mas é a arquitetura que resolve o problema real. A decisão em resumo Para conhecimento documental, produtos, condições, FAQs, regulação, a resposta é RAG: atualizável sem retreinar, rastreável por fonte, sem necessidade de tocar no modelo cada vez que algo muda. Para dados transacionais, saldos, movimentações, status de processos, a resposta são APIs diretas a partir do backend: mais controle, tempo real e sem ambiguidade. Para a geração de respostas, o LLM opera como camada de síntese sobre o contexto injetado pelas duas fontes anteriores. O fine-tuning continua sendo útil como camada complementar, para que o modelo entenda a terminologia interna ou mantenha um tom consistente, mas não é a estratégia central de conhecimento em um domínio dinâmico.
Qual é a diferença entre RAG e fine-tuning? O fine-tuning continua o treinamento do modelo com dados próprios e grava esse conhecimento nos seus pesos, então ele fica estático. O RAG (Retrieval-Augmented Generation) mantém o conhecimento fora do modelo, em uma vector database, e o recupera no momento da consulta. O RAG é atualizado reindexando, sem retreinar o modelo.
Por que RAG + APIs diretas é a melhor arquitetura para um agente bancário? Porque resolve as duas dimensões do problema ao mesmo tempo: o conhecimento documental (produtos, condições, FAQs, regulação) vive em uma vector database atualizável, e os dados transacionais em tempo real (saldos, movimentações, status de solicitações) são resolvidos chamando diretamente as APIs do banco. Além disso, cada resposta é rastreável por fonte, algo essencial em ambientes regulados.
O fine-tuning serve para alguma coisa em banking? Sim, como camada complementar. É útil para o modelo entender a terminologia interna e manter um tom consistente com a marca. Mas não convém usá-lo como estratégia central de conhecimento em um domínio dinâmico, porque congela a informação no momento do treinamento.