O que é RAG: vantagens, como acessar e como criar agentes com RAG

Introdução

RAG virou uma das palavras mais repetidas em projetos de IA corporativa. Mas, como costuma acontecer com termos que ganham tração rápido, muita gente usa RAG para significar coisas diferentes: upload de arquivos, busca vetorial, base de conhecimento, agente com documentos, chatbot interno, copiloto corporativo ou até integração com ERP.

Na prática, RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação. É um padrão de arquitetura em que um modelo de linguagem não responde apenas com base no que aprendeu no treinamento. Antes de responder, ele busca informações relevantes em uma fonte externa, injeta esses trechos no contexto e gera uma resposta fundamentada nesses dados.

Em português simples:

RAG é a forma de fazer uma IA responder usando os seus dados, documentos e conhecimento corporativo, sem precisar retreinar o modelo.

Para empresas que usam Microsoft Dynamics 365 Finance & Operations, RAG é especialmente importante. Projetos D365 F&O têm documentação funcional, desenhos técnicos, gaps, FDDs, TDDs, atas, decisões de arquitetura, regras fiscais, manuais de operação, tickets, runbooks, evidências de teste e conhecimento espalhado em SharePoint, Teams, Azure DevOps, PDFs, Word, Excel e wikis internas.

Um agente com RAG pode ajudar a responder perguntas como:

• “Qual foi a decisão de arquitetura para integração de fornecedores?”
• “Onde está documentada a regra de bloqueio de crédito?”
• “Quais testes funcionais validam a customização de pedidos de venda?”
• “O que o time decidiu sobre OData versus integração recorrente?”
• “Quais riscos foram registrados para o batch de faturamento?”

Mas existe uma diferença fundamental:

RAG é ótimo para conhecimento. Para dados vivos, transações e ações no ERP, você normalmente precisa combinar RAG com ferramentas, APIs, conectores, MCP ou agentes.

Este artigo explica o que é RAG, por que ele é útil, como acessá-lo nas principais plataformas e como aplicá-lo em agentes corporativos com governança.

O Que é RAG?

RAG combina três ideias:

1. Retrieval: buscar informações relevantes em uma base externa.
2. Augmentation: adicionar essas informações ao contexto enviado ao modelo.
3. Generation: gerar uma resposta usando o modelo de linguagem.

O fluxo básico é:

Pergunta do usuário
        ↓
Busca em documentos, índices ou bases de conhecimento
        ↓
Recuperação dos trechos mais relevantes
        ↓
Envio da pergunta + trechos recuperados para o modelo
        ↓
Resposta fundamentada, idealmente com citações

Sem RAG, o modelo responde com base em conhecimento pré-treinado e no contexto que você escreveu no prompt.

Com RAG, o modelo recebe evidências externas antes de responder.

Isso é essencial quando a resposta depende de:

• Documentos privados.
• Conteúdo recente.
• Políticas internas.
• Base de conhecimento do cliente.
• Regras de projeto.
• Manuais operacionais.
• Histórico de decisões.
• Documentação técnica específica.

Exemplo Simples

Imagine que você pergunta a uma IA:

Como funciona o processo de aprovação de pedidos de compra no nosso D365 F&O?

Sem RAG, a IA pode responder com conhecimento genérico sobre compras.

Com RAG, o sistema primeiro busca documentos internos:

• Desenho funcional de Procurement.
• Manual do usuário.
• Decisão de arquitetura sobre workflow.
• Ata da reunião de aprovação.
• Casos de teste.

Depois, o modelo recebe trechos desses documentos e responde:

No projeto Minoru, a aprovação de pedidos de compra acima de R$ 50.000 segue o workflow PO-APP-002. A regra considera centro de custo, grupo de fornecedores e limite de alçada. A exceção para compras emergenciais está documentada no FDD de Procurement, seção 4.3...

Essa resposta é muito mais útil porque está fundamentada em conhecimento do projeto.

Como RAG Funciona Por Dentro

Uma arquitetura RAG normalmente tem duas fases: ingestão e consulta.

1. Ingestão

A ingestão prepara o conteúdo para busca.

Fluxo típico:

Arquivos e fontes
        ↓
Extração de texto
        ↓
Limpeza e normalização
        ↓
Divisão em chunks
        ↓
Geração de embeddings
        ↓
Indexação

2. Consulta

A consulta usa o índice para encontrar contexto relevante.

Fluxo típico:

Pergunta do usuário
        ↓
Reescrita ou expansão da pergunta
        ↓
Busca lexical, vetorial ou híbrida
        ↓
Reranking
        ↓
Seleção dos melhores trechos
        ↓
Prompt com grounding
        ↓
Resposta do modelo
        ↓
Citações, fontes e logs

O ponto crítico: a qualidade da resposta depende muito da qualidade da recuperação.

Se o sistema recupera trechos ruins, incompletos ou fora de contexto, o modelo tende a responder mal.

O Que São Chunks?

Chunks são pedaços menores de conteúdo.

Um documento de 80 páginas não é enviado inteiro para o modelo a cada pergunta. Ele é dividido em partes menores, como seções, parágrafos ou blocos semânticos.

Exemplo:

Documento: FDD - Contas a Pagar

Chunk 1: Visão geral do processo
Chunk 2: Cadastro de fornecedores
Chunk 3: Política de aprovação
Chunk 4: Exceções fiscais
Chunk 5: Casos de teste

Chunking ruim é uma das principais causas de RAG fraco.

Se o chunk é grande demais, vem ruído. Se é pequeno demais, perde contexto.

Boas práticas:

• Dividir por seção lógica, não apenas por número fixo de caracteres.
• Manter títulos junto do conteúdo.
• Preservar metadados: fonte, data, área, módulo, projeto, versão, confidencialidade.
• Usar overlap quando necessário.
• Criar resumos ou campos auxiliares para documentos longos.

O Que São Embeddings?

Embeddings são representações numéricas de significado.

Quando você transforma uma frase em embedding, ela vira um vetor. Frases semanticamente parecidas ficam próximas nesse espaço vetorial.

Exemplo:

"aprovação de pedido de compra"
"workflow de purchase order"
"alçada para compras"

Mesmo usando palavras diferentes, essas frases podem ficar próximas porque falam de conceitos relacionados.

É isso que permite a busca semântica: encontrar conteúdo relevante mesmo quando a pergunta não usa exatamente as mesmas palavras do documento.

Busca Lexical, Vetorial, Híbrida e Semântica

RAG não é apenas busca vetorial. Em projetos reais, a melhor estratégia costuma ser híbrida.

Tipo de busca	Como funciona	Quando ajuda
Lexical	Procura palavras exatas ou similares	Códigos, nomes, IDs, termos específicos
Vetorial	Procura proximidade semântica	Perguntas conceituais e linguagem natural
Híbrida	Combina lexical + vetorial	Melhor equilíbrio para conteúdo corporativo
Semantic ranking	Reordena resultados com compreensão semântica	Aumenta relevância dos trechos finais

Exemplo em D365 F&O:

• Para buscar CustAccount, busca lexical é ótima.
• Para buscar “regra de aprovação de cliente com crédito bloqueado”, busca vetorial ajuda.
• Para perguntas reais de usuário, híbrida costuma ser melhor.

Principais Vantagens de Usar RAG

1. Respostas baseadas em dados privados

O modelo não precisa conhecer seus documentos de projeto no treinamento. O RAG recupera esse conteúdo em tempo de execução.

Isso é útil para:

• SharePoint.
• Wikis internas.
• PDFs.
• Documentos Word.
• Planilhas.
• Manuais.
• Tickets.
• Runbooks.
• Documentação de arquitetura.

2. Atualização sem retreinar modelo

Se uma política muda, você atualiza a fonte ou o índice. Não precisa treinar um novo modelo.

Isso torna RAG adequado para conteúdos que mudam com frequência:

• Procedimentos internos.
• Políticas.
• Catálogo de serviços.
• Documentação de produto.
• Decisões de projeto.
• Conteúdo regulatório.

3. Redução de alucinações

RAG não elimina alucinações, mas reduz o risco quando bem implementado.

O modelo passa a ter evidências específicas. Além disso, você pode instruí-lo a responder:

Se a resposta não estiver nos documentos recuperados, diga que não encontrou evidência suficiente.

4. Citações e rastreabilidade

Um bom RAG retorna fontes.

Isso é essencial em empresas porque o usuário precisa saber:

• De onde veio a resposta.
• Qual documento foi usado.
• Qual versão do documento.
• Qual seção suporta a conclusão.

Em ERP, essa rastreabilidade é crítica. Ninguém deveria alterar um processo fiscal, financeiro ou operacional com base em uma resposta sem fonte.

5. Menor custo que fine-tuning para conhecimento

Fine-tuning pode ser útil para comportamento, formato e estilo. Mas, para conhecimento que muda, RAG costuma ser melhor.

Regra prática:

• Use RAG para fatos, documentos e conhecimento atualizável.
• Use fine-tuning para comportamento, tom, formato e padrões de resposta.

6. Governança e segurança

RAG pode respeitar permissões, filtros, metadados e políticas de acesso.

Exemplo:

Um usuário de Finance pode ver documentos de Finance, mas não documentos de RH ou M&A.

Isso exige arquitetura correta. Não basta jogar todos os documentos em um índice único sem controle.

7. Melhor experiência para suporte e consultoria

Um agente com RAG pode acelerar:

• Suporte N1/N2.
• Onboarding de consultores.
• Busca em documentação de projeto.
• Preparação de testes.
• Análise de tickets.
• Explicação de customizações.
• Comparação de decisões passadas.

Limitações do RAG

RAG não é magia.

Problemas comuns:

• Documentos ruins geram respostas ruins.
• Índice desatualizado gera resposta desatualizada.
• Chunking ruim quebra o contexto.
• Busca vetorial pode ignorar códigos exatos.
• Busca lexical pode perder intenção semântica.
• Falta de metadados dificulta filtragem.
• Sem segurança, usuários podem acessar conteúdo indevido.
• Sem avaliação, ninguém sabe se melhorou.
• Sem citações, a confiança fica fraca.

Em resumo:

RAG é tão bom quanto o pipeline de conhecimento que alimenta o agente.

RAG Não é a Mesma Coisa que Acesso a Sistema

Este ponto é crucial.

RAG responde com base em conhecimento indexado. Ele não é, por si só, uma integração transacional com o ERP.

Exemplo:

Pergunta: qual é a política de aprovação de pedido de compra?

RAG é adequado, porque a resposta vem de documentos.

Agora:

Pergunta: qual é o saldo atual do fornecedor 1001?

Aqui, talvez RAG não seja adequado. O saldo atual está no sistema transacional. O agente deve usar:

• API.
• OData.
• Data entity.
• SQL autorizado.
• Conector.
• MCP server.
• Função/tool específica.

Outro exemplo:

Cancelar o pedido de compra 000123.

Isso não é RAG. Isso é ação. Precisa de ferramenta, permissão, validação, confirmação humana e auditoria.

Arquitetura madura separa:

• RAG: conhecimento e contexto.
• Tools/APIs/MCP: dados vivos e ações.
• Agente: orquestra quando buscar, quando chamar ferramenta e quando pedir confirmação.

Como Acessar RAG na Prática

Você não “acessa o RAG” como se fosse uma única tela universal. Você acessa RAG por meio de plataformas, ferramentas e padrões.

1. ChatGPT e GPTs com arquivos

Para usuários de negócio, o caminho mais simples é criar um GPT ou usar conhecimento com arquivos.

Fluxo típico:

1. Criar um GPT.
2. Adicionar arquivos de conhecimento.
3. Habilitar recuperação.
4. Fazer perguntas.

Por trás, a plataforma quebra arquivos em chunks, cria embeddings, armazena em um índice vetorial e recupera trechos relevantes.

Vantagem:

• Simples.
• Rápido.
• Bom para protótipos e uso individual.

Limite:

• Menos controle sobre pipeline, segurança, atualização e integração corporativa.

2. OpenAI API com vector stores e file search

Para desenvolvimento com código, a OpenAI oferece vector stores e ferramenta file_search.

Fluxo:

1. Criar um vector store.
2. Fazer upload de arquivos.
3. Aguardar processamento.
4. Criar uma resposta usando file_search.
5. O modelo decide buscar nos arquivos e usa o conteúdo recuperado.

Uso típico:

• Base de suporte.
• Documentação de produto.
• Assistente interno.
• Pesquisa em documentos.
• Agente com arquivos do usuário.

Vantagem:

• Menos infraestrutura própria.
• Busca semântica e keyword search gerenciadas.
• Integração direta com modelos e agentes.

Limite:

• Menos controle que uma arquitetura customizada com Azure AI Search ou banco vetorial próprio.

3. Azure AI Search

Para empresas, Azure AI Search é um dos caminhos mais fortes para RAG.

Ele oferece:

• Índices de busca.
• Busca textual.
• Busca vetorial.
• Busca híbrida.
• Semantic ranker.
• Filtros por metadados.
• Segurança e integração com Azure.
• Agentic retrieval para cenários mais avançados.

Fluxo:

1. Escolher fontes: SharePoint, Blob Storage, banco, PDFs, wikis, documentos.
2. Extrair conteúdo.
3. Dividir em chunks.
4. Gerar embeddings.
5. Criar índice no Azure AI Search.
6. Consultar o índice.
7. Enviar trechos ao modelo.
8. Gerar resposta com citações.

É uma boa escolha quando você precisa de:

• Controle corporativo.
• Escala.
• Segurança.
• Filtros.
• Integração com Microsoft Entra ID.
• Busca híbrida e ranking semântico.
• Observabilidade.

4. Azure AI Foundry

Azure AI Foundry permite criar soluções e agentes com modelos, ferramentas e fontes de conhecimento.

Para RAG, ele pode usar:

• Índices.
• Azure AI Search.
• File Search.
• Ferramentas de grounding.
• Agentes com knowledge tools.

É um caminho interessante quando você quer construir agentes corporativos com governança, avaliação, observabilidade e integração com serviços Azure.

5. Microsoft Copilot Studio

Copilot Studio permite adicionar conhecimento aos agentes por meio de knowledge sources e generative answers.

Fontes podem incluir:

• Sites.
• SharePoint.
• Dataverse.
• Dados do Power Platform.
• Dados Dynamics 365.
• Sistemas externos.

É útil para cenários low-code, especialmente quando o objetivo é criar agentes de atendimento, suporte interno, FAQ corporativo ou copilotos departamentais.

6. Solução customizada

Em projetos mais sofisticados, você pode criar seu próprio pipeline:

• Extração com Document Intelligence ou Content Understanding.
• Embeddings com OpenAI/Azure OpenAI.
• Indexação em Azure AI Search, PostgreSQL + pgvector, Cosmos DB, Redis, Pinecone, Weaviate ou outro mecanismo.
• API própria de retrieval.
• Modelo de linguagem.
• Camada de agente.
• Observabilidade e avaliação.

Esse caminho dá mais controle, mas exige mais engenharia.

RAG Clássico vs Agentic RAG

RAG clássico normalmente faz uma busca por pergunta.

Fluxo:

Usuário pergunta
        ↓
Sistema busca no índice
        ↓
Modelo responde

Agentic RAG é mais sofisticado.

O agente pode:

• Entender a intenção.
• Quebrar a pergunta em subperguntas.
• Fazer múltiplas buscas.
• Consultar fontes diferentes.
• Comparar evidências.
• Pedir mais contexto.
• Usar ferramentas.
• Produzir resposta com citações.

Exemplo:

Pergunta: O que mudou no processo de faturamento após a decisão de arquitetura do projeto?

Um RAG clássico pode buscar documentos que contenham “processo de faturamento”.

Um Agentic RAG pode decompor:

1. Buscar decisões de arquitetura sobre faturamento.
2. Buscar FDD/TDD relacionado.
3. Buscar atas recentes.
4. Buscar casos de teste impactados.
5. Comparar antes e depois.
6. Responder com fontes.

Isso é muito mais próximo de como um consultor trabalha.

O Que é um Agente com RAG?

Um agente com RAG é um agente que usa recuperação de conhecimento como uma de suas capacidades.

Ele pode combinar:

• RAG para buscar contexto.
• Ferramentas para consultar sistemas.
• APIs para executar ações.
• Regras para pedir confirmação.
• Memória para continuidade.
• Avaliação para medir qualidade.

Exemplo de arquitetura:

Usuário
  ↓
Agente
  ├─ RAG: buscar documentação e decisões
  ├─ API: consultar status atual no ERP
  ├─ Ferramenta: abrir ticket
  ├─ Política: pedir confirmação antes de ação
  └─ Resposta: explicar, citar fontes e registrar auditoria

No contexto D365 F&O:

Pergunta: Posso reprocessar este pedido com erro?

Agente:
1. Usa RAG para buscar runbook de reprocessamento.
2. Usa ferramenta para consultar status do pedido.
3. Usa RAG para buscar regra de exceção.
4. Responde com recomendação e fontes.
5. Se houver ação, pede confirmação humana.

Quando Usar RAG e Quando Usar Ferramentas

Necessidade	Melhor abordagem
Explicar política interna	RAG
Buscar decisão de arquitetura	RAG
Responder com base em manual	RAG
Consultar saldo atual	API/tool
Criar pedido	API/tool com confirmação
Cancelar transação	API/tool com governança
Comparar regra documentada com dado atual	RAG + tool
Investigar ticket com runbook e status atual	RAG + tool

Regra prática:

Se a resposta está em documentos, use RAG. Se a resposta depende do estado atual de um sistema, use ferramenta. Se precisa dos dois, use agente com RAG e tools.

Exemplos de Agentes com RAG

1. Agente de suporte D365 F&O

Fontes RAG:

• Runbooks.
• Base de conhecimento.
• Tickets resolvidos.
• Documentação funcional.
• Guias de operação.

Ferramentas:

• Consulta de status de batch.
• Consulta de incidentes.
• Criação de ticket.

Perguntas:

• “Como reprocessar o batch de integração?”
• “O que fazer quando a importação de fornecedores falha?”
• “Qual é o procedimento para erro de nota fiscal?”

2. Agente de onboarding de consultores

Fontes RAG:

• FDDs.
• TDDs.
• Decisões de arquitetura.
• Mapa de processos.
• Glossário do projeto.

Perguntas:

• “Explique o processo de contas a pagar deste cliente.”
• “Quais customizações existem em Sales Order?”
• “Onde está documentada a integração com o WMS?”

3. Agente de revisão técnica

Fontes RAG:

• Padrões de desenvolvimento.
• Guidelines X++.
• Decisões de arquitetura.
• Checklist de segurança.
• Histórico de PRs.

Ferramentas:

• Leitura de diff.
• Busca em repositório.
• Execução de testes.

Perguntas:

• “Esta alteração segue o padrão de extensibilidade?”
• “Existe decisão anterior sobre esse tipo de integração?”
• “Quais testes precisam ser adicionados?”

4. Agente fiscal/localização Brasil

Fontes RAG:

• Documentação fiscal.
• Decisões de localização.
• Manuais internos.
• Pareceres.
• Regras de parametrização.

Ferramentas:

• Consulta de configuração.
• Consulta de documentos fiscais.
• Validação de status.

Perguntas:

• “Esta alteração impacta NF-e?”
• “Qual parametrização foi definida para retenção?”
• “Quais testes fiscais precisam ser executados?”

Como Desenhar um RAG de Qualidade

1. Comece pelas perguntas

Não comece pelos documentos. Comece pelas perguntas que o usuário fará.

Exemplos:

• “Como resolver erro X?”
• “Qual regra se aplica ao caso Y?”
• “Onde está documentado Z?”
• “Qual decisão foi tomada sobre W?”

Depois selecione as fontes que respondem a essas perguntas.

2. Escolha fontes confiáveis

Não indexe tudo sem critério.

Classifique fontes:

• Oficiais.
• Rascunhos.
• Obsoletas.
• Confidenciais.
• Por área.
• Por projeto.
• Por versão.

O modelo deve saber diferenciar uma decisão aprovada de uma anotação antiga.

3. Use metadados

Metadados são essenciais.

Exemplos:

• project
• module
• document_type
• version
• owner
• confidentiality
• effective_date
• language
• source_url
• legal_entity

Metadados permitem filtros e melhor governança.

4. Faça busca híbrida

Na maioria dos cenários corporativos, híbrido funciona melhor que só vetorial.

Use vetorial para intenção. Use lexical para termos exatos.

5. Exija citações

Resposta sem fonte deve ser tratada como hipótese, não como verdade.

Prompt de sistema:

Responda apenas com base nas fontes recuperadas.
Inclua citações.
Se não houver evidência suficiente, diga que não encontrou base documental.

6. Avalie

Crie uma base de perguntas e respostas esperadas.

Métricas úteis:

• O trecho correto foi recuperado?
• A resposta usou a fonte correta?
• A resposta inventou?
• A citação suporta a conclusão?
• O usuário conseguiu agir com segurança?

Checklist Para Implantar RAG

Antes de colocar RAG em produção, valide:

• Quais perguntas o sistema deve responder?
• Quais fontes são oficiais?
• Quem é dono de cada fonte?
• Como o conteúdo será atualizado?
• Como documentos obsoletos serão removidos?
• Como permissões serão respeitadas?
• Qual estratégia de chunking será usada?
• Qual modelo de embedding será usado?
• Busca será vetorial, lexical, híbrida ou agentic retrieval?
• Haverá citações?
• Haverá avaliação automatizada?
• Haverá logs de pergunta, fontes e resposta?
• Como lidar com conteúdo confidencial?
• Como o agente responde quando não sabe?
• Como escalar para múltiplas áreas?

RAG em Projetos D365 F&O

Em projetos D365 F&O, RAG pode organizar uma parte enorme do conhecimento que normalmente fica disperso.

Fontes candidatas:

• FDD.
• TDD.
• FRD.
• Desenhos de integração.
• Catálogo de interfaces.
• Plano de testes.
• Evidências.
• Runbooks.
• Atas de decisão.
• Backlog.
• Manuais de usuário.
• Documentação fiscal.
• Documentação de segurança.
• Padrões X++.
• Guidelines de ALM.

Perguntas úteis:

• “Qual entidade de dados foi definida para integração de clientes?”
• “Por que o time decidiu não usar OData nesse cenário?”
• “Qual batch processa este arquivo?”
• “Quais roles permitem executar esta rotina?”
• “Qual teste valida a regra de bloqueio?”
• “Qual customização afeta SalesTable?”

Esse tipo de agente não substitui consultores. Ele reduz tempo de busca e preserva memória do projeto.

Arquitetura Recomendada Para ERP

Para cenários ERP, eu gosto de uma arquitetura em camadas:

Camada 1: Conhecimento
- Documentos oficiais
- Decisões
- Runbooks
- Padrões técnicos
- Testes

Camada 2: Retrieval
- Índice
- Busca híbrida
- Filtros por permissão
- Reranking
- Citações

Camada 3: Agente
- Planejamento
- RAG
- Tools/APIs
- Confirmação humana
- Auditoria

Camada 4: Sistemas
- D365 F&O
- Azure DevOps
- SharePoint
- ServiceNow
- SQL
- APIs

RAG fica na camada de conhecimento. Agente fica na orquestração. ERP fica protegido por APIs, permissões e auditoria.

Conclusão

RAG é um dos padrões mais importantes para levar IA generativa para o mundo corporativo.

Ele permite que modelos respondam com base em conhecimento privado, atualizado e rastreável. Em vez de tentar colocar tudo no prompt ou retreinar modelos a cada mudança, você cria uma camada de recuperação que busca o contexto certo na hora certa.

Mas RAG sozinho não resolve tudo.

Para agentes corporativos, especialmente em ambientes como D365 F&O, a arquitetura madura combina:

• RAG para conhecimento.
• Busca híbrida para relevância.
• Citações para confiança.
• Permissões para segurança.
• Ferramentas para dados vivos.
• APIs/MCP para ações.
• Avaliação para qualidade.
• Auditoria para governança.

O melhor RAG não é o que responde mais bonito. É o que encontra a evidência correta, explica com clareza, mostra a fonte e sabe dizer quando não tem base suficiente para responder.

Fontes Oficiais Consultadas

• Microsoft Learn — Retrieval augmented generation and indexes in Microsoft Foundry
• Microsoft Learn — Retrieval-augmented generation in Azure AI Search
• Microsoft Learn — Semantic ranking in Azure AI Search
• Microsoft Learn — Build a RAG solution with Azure AI Content Understanding
• Microsoft Learn — Microsoft Foundry Agent Service
• Microsoft Learn — File search tool for Microsoft Foundry agents
• Microsoft Learn — Knowledge sources in Microsoft Copilot Studio
• OpenAI Docs — File search
• OpenAI Docs — Retrieval
• OpenAI Help Center — Retrieval Augmented Generation and Semantic Search for GPTs