IA generativa sobre seus dados: RAG na prática

O modelo genérico não conhece a sua empresa#

Você abre um chat de IA generativa, pergunta sobre a política de reembolso da sua companhia e recebe uma resposta bem escrita, confiante e completamente inventada. O modelo não tem a menor ideia de como a sua empresa funciona. Ele foi treinado com texto público da internet até uma certa data, e a sua norma interna, o seu contrato com o cliente e o seu manual de produto simplesmente não estavam lá. Colocar IA generativa sobre seus dados é justamente resolver esse buraco: fazer o modelo responder ancorado no que a sua empresa sabe, não no que a internet sabia até o corte de treinamento.

A técnica que virou o padrão de mercado para isso se chama RAG, sigla para Retrieval-Augmented Generation, ou geração aumentada por recuperação. A ideia é direta: antes de o modelo escrever a resposta, um mecanismo de busca vai até os seus documentos, recupera os trechos mais relevantes para a pergunta e entrega esses trechos ao modelo como contexto. O modelo então gera a resposta com base naquele material, e não com base na sua memória genérica. Este artigo explica como isso funciona na prática, qual o papel do Azure OpenAI e do Azure AI Search, quando RAG vale mais que fine-tuning e o que ele resolve, e o que ele não resolve, incluindo a parte de LGPD que a maioria dos fornecedores prefere não mencionar.

RAG é busca mais geração, nessa ordem#

RAG combina duas etapas que costumam ser tratadas separadamente. Primeiro a recuperação, depois a geração. Vale destrinchar cada uma, porque a maior parte dos projetos que dão errado erra na primeira e culpa a segunda.

Na etapa de ingestão, que acontece antes de qualquer pergunta, os seus documentos são quebrados em pedaços menores, os chamados chunks. Cada pedaço passa por um modelo de embedding, que transforma o texto em um vetor numérico. Esse vetor é uma representação matemática do significado do trecho: textos com sentido parecido ficam próximos no espaço vetorial. Todos esses vetores são guardados em um índice, e aqui entra o Azure AI Search, que funciona como o índice vetorial e de busca da solução.

Na etapa de consulta, quando o usuário pergunta algo, a pergunta também vira um vetor. O sistema procura no índice os trechos cujos vetores estão mais próximos do vetor da pergunta, ou seja, os mais relevantes semanticamente. Esses trechos são então injetados no prompt que vai para o modelo de linguagem do Azure OpenAI, junto com a pergunta original e uma instrução do tipo "responda usando apenas o contexto abaixo". O modelo gera a resposta e, se a solução estiver bem feita, cita de qual documento cada afirmação saiu.

O ponto que separa uma prova de conceito bonita de um sistema que aguenta produção é a qualidade da recuperação. Se a busca traz o trecho errado, o modelo vai gerar uma resposta errada com toda a eloquência do mundo. Boa parte da engenharia de RAG está em como você quebra os documentos, qual modelo de embedding usa, se combina busca vetorial com busca por palavra-chave e como filtra por permissão de acesso antes de responder.

Etapa	O que acontece	Componente típico no Azure
Ingestão	Documentos são quebrados em chunks e viram vetores	Modelo de embedding do Azure OpenAI
Indexação	Os vetores são armazenados e ficam pesquisáveis	Azure AI Search
Recuperação	A pergunta vira vetor e busca os trechos mais próximos	Azure AI Search
Geração	O modelo escreve a resposta com base nos trechos	Modelo de linguagem do Azure OpenAI

RAG resolve o problema de dados que mudam, fine-tuning não#

Uma dúvida honesta aparece cedo em todo projeto: por que não treinar o modelo direto com os nossos dados, em vez de montar toda essa mecânica de busca? Essa é a diferença entre RAG e fine-tuning, e confundir os dois custa caro.

Fine-tuning ajusta os pesos do modelo com exemplos, mudando o comportamento dele. É bom para ensinar um formato, um tom de voz, um estilo de resposta ou uma tarefa muito específica e repetitiva. O que ele faz mal é guardar conhecimento factual que muda. Se você faz fine-tuning com a sua tabela de preços de hoje e o preço muda amanhã, o modelo continua respondendo o preço velho, com confiança total, e a única forma de corrigir é treinar de novo. Fora que fine-tuning não dá rastreabilidade: o modelo não sabe dizer de onde tirou a informação.

RAG mantém o conhecimento fora do modelo, num índice que você atualiza quando quiser. Mudou o documento, reindexa o trecho, e a próxima resposta já sai correta. Nada de retreinar. E como a resposta veio de um trecho recuperado, dá para mostrar a fonte. Para a maioria absoluta dos casos empresariais, responder perguntas sobre documentos, políticas, contratos, catálogos e bases internas, RAG é a escolha certa. Fine-tuning entra como complemento, não como substituto, quando você precisa moldar o formato da resposta.

Critério	RAG	Fine-tuning
Conhecimento que muda com frequência	Forte, basta reindexar	Fraco, exige retreinar
Rastreabilidade da fonte	Cita o documento de origem	Não informa a origem
Custo de atualização	Baixo, atualiza o índice	Alto, novo ciclo de treino
Ideal para	Responder sobre dados próprios	Ajustar formato, tom e tarefa
Controle de acesso ao dado	Filtra na recuperação	Fica embutido no modelo

Na prática, muitos projetos que a gente vê tentando fine-tuning na verdade queriam RAG. O sintoma clássico é a empresa querer que o assistente conheça os documentos internos e achar que treinar o modelo é o caminho. Não é. Se o dado muda e você precisa citar a fonte, é RAG.

RAG reduz alucinação, mas não elimina o risco#

Este é o ponto onde consultor honesto se separa de vendedor. RAG reduz alucinação porque força o modelo a responder com base em trechos reais, recuperados dos seus dados, e permite citar a fonte de cada afirmação. Isso muda o jogo em relação a um modelo solto, que inventa com naturalidade. Mas RAG não elimina o risco, e quem promete zero alucinação está vendendo ilusão.

O modelo ainda pode interpretar mal um trecho, misturar informações de dois documentos, ou responder algo plausível quando a busca não trouxe nada útil. Existe até o cenário em que a recuperação falha, não acha o trecho certo, e o modelo, em vez de dizer "não encontrei", preenche a lacuna com uma resposta inventada. Reduzir esses casos é trabalho de engenharia, não de mágica. Algumas práticas que fazem diferença real:

• Instruir o modelo a responder apenas com base no contexto recuperado e a dizer explicitamente quando não encontrar a informação.
• Sempre exibir as fontes citadas, para que a pessoa possa conferir a origem em vez de confiar cegamente.
• Cuidar da qualidade da recuperação: bom particionamento dos documentos, embeddings adequados e busca híbrida, combinando vetores com palavras-chave.
• Definir um limiar de relevância: se nenhum trecho passa de uma pontuação mínima, o sistema responde que não sabe, em vez de forçar.
• Medir com um conjunto de perguntas reais e avaliar as respostas, tratando o assistente como software que precisa de teste, não como oráculo.

A régua certa não é "acabou com o erro". É "errou menos que a alternativa, e quando errou, deu para rastrear". Um assistente que responde com fonte é auditável. Um que responde do nada, não. Essa diferença é o que torna a IA generativa aceitável em ambiente corporativo. Se o tema de confiabilidade e governança do dado que alimenta a IA interessa, vale ver como estruturamos engenharia de dados para deixar as fontes organizadas antes de qualquer projeto de IA.

Dado sensível pede LGPD desde o primeiro dia#

Colocar IA generativa sobre seus dados quase sempre significa expor documento interno a um modelo, e boa parte desse material tem dado pessoal: nome de cliente, CPF, contrato, histórico de atendimento. A Lei Geral de Proteção de Dados, a Lei nº 13.709/2018, se aplica a esse tratamento como se aplica a qualquer outro. Ignorar isso não é um detalhe técnico, é um risco jurídico.

Alguns pontos que a gente sempre coloca na mesa antes de subir um projeto de RAG:

• Base legal e finalidade. Você precisa de fundamento para tratar aquele dado com essa finalidade. Reaproveitar um documento coletado para outro fim dentro de um assistente de IA pode não estar coberto pela base original.
• Controle de acesso na recuperação. O assistente não pode responder a um usuário com base em documento que ele não teria direito de ver. O filtro de permissão tem que agir na etapa de recuperação, no índice, antes de o trecho chegar ao modelo.
• Onde o dado é processado. Rodar em Azure OpenAI dentro do seu tenant e da sua região dá muito mais controle sobre onde o dado trafega e é processado do que jogar informação sensível em uma ferramenta pública genérica.
• Minimização. Nem todo documento precisa entrar no índice. Quanto menos dado pessoal desnecessário você indexa, menor a superfície de risco.
• Registro e auditoria. Guardar o que foi perguntado, o que foi recuperado e o que foi respondido ajuda tanto na melhoria quanto na prestação de contas.

Nada disso é motivo para não fazer. É motivo para fazer direito, com o time de dados e o jurídico na mesma sala. Um projeto de IA generativa que trata a LGPD como etapa final, depois de tudo pronto, costuma virar retrabalho caro.

Como um projeto de RAG começa na prática#

A tentação é começar grande, indexar tudo e prometer um assistente que responde qualquer coisa. Erro clássico. O caminho que funciona é escolher um domínio bem delimitado, com documentação de qualidade e uma dor clara, por exemplo o suporte interno respondendo dúvidas sobre políticas, ou o comercial consultando cláusulas de contratos padrão.

Um roteiro enxuto que costuma dar certo:

1. Escolher um caso com fontes confiáveis e pergunta frequente e mensurável.
2. Organizar e limpar os documentos, porque lixo indexado gera resposta ruim.
3. Montar a ingestão, os embeddings e o índice no Azure AI Search.
4. Conectar o modelo do Azure OpenAI com instrução firme de responder pela fonte.
5. Testar com perguntas reais dos usuários e medir acerto e rastreabilidade.
6. Só então ampliar o escopo, um domínio de cada vez.

Esse tipo de projeto conversa bem com o que já existe no seu ambiente. Se você usa a stack Microsoft, o assistente pode se apoiar na mesma organização de dados que sustenta o seu analytics avançado e pode ser exposto dentro de aplicativos de negócio via Power Platform, sem construir uma interface do zero. E se a base de dados ainda está espalhada e inconsistente, vale primeiro entender se a fundação está pronta, tema que tratamos no artigo sobre Microsoft Fabric e quando ele vale a pena.

Perguntas frequentes#

RAG serve para qualquer tipo de documento?

Serve para conteúdo textual: políticas, manuais, contratos, artigos de base de conhecimento, tickets, e-mails. Para dados muito estruturados, como tabelas numéricas de um banco de dados, RAG puro nem sempre é o melhor, e pode fazer mais sentido combinar com consulta direta à base. A regra é: se a resposta está em texto que uma pessoa leria, RAG se encaixa.

Preciso de um modelo próprio para fazer RAG?

Não. RAG usa modelos prontos, como os do Azure OpenAI, sem nenhum treinamento customizado. Toda a inteligência sobre os seus dados vem da recuperação, não de treinar o modelo. Isso é justamente o que torna o RAG mais barato e mais rápido de colocar de pé do que fine-tuning.

RAG garante que a IA nunca vai errar?

Não, e desconfie de quem garantir. RAG reduz bastante a alucinação porque ancora a resposta em trechos reais e permite citar a fonte, mas o modelo ainda pode interpretar mal ou responder além do que o contexto sustenta. Por isso a exibição de fontes e o teste contínuo são parte do projeto, não enfeite.

Meus dados vão ser usados para treinar o modelo?

Depende de onde você roda. Em um ambiente como o Azure OpenAI dentro do seu tenant, o seu conteúdo não vira material de treinamento do modelo base. Esse é um dos motivos de preferir uma plataforma corporativa a uma ferramenta pública genérica quando há dado sensível envolvido. Sempre confira os termos do serviço que você contratar.

Quanto tempo leva para ter um primeiro assistente no ar?

Um piloto bem escopado, com fontes já organizadas e um domínio único, é bem mais rápido do que um projeto de fine-tuning. O que costuma consumir tempo não é a IA, é arrumar os documentos e definir o controle de acesso. Base bagunçada é o gargalo real, não a tecnologia.

RAG substitui o meu BI e meus dashboards?

Não. São coisas complementares. O BI responde perguntas sobre números e indicadores estruturados. O RAG responde perguntas sobre texto e conhecimento espalhado em documentos. Empresas maduras usam os dois: o dashboard para o "quanto" e o assistente para o "por que" e o "onde está escrito".

O caminho é começar pequeno e honesto#

IA generativa sobre seus dados deixou de ser promessa de palco e virou algo aplicável, desde que feito com engenharia de verdade e sem prometer o impossível. RAG é hoje o jeito mais sensato de ancorar um modelo nos documentos da sua empresa: reduz alucinação, dá rastreabilidade, evita retreinar o tempo todo e respeita o controle de acesso, contanto que a LGPD entre no projeto desde o começo, não no fim.

Se você quer entender qual caso da sua operação faz sentido para um primeiro piloto de RAG, e como conectar isso à sua base de dados atual sem virar bagunça, fale com a gente. A conversa começa pela dor real, não pela tecnologia.