Uma arquitetura RAG com Azure OpenAI e Azure AI Search é o caminho mais direto para fazer um modelo de linguagem responder com base nos documentos da sua empresa. O padrão RAG (retrieval-augmented generation, ou geração aumentada por recuperação) busca os trechos relevantes do seu conteúdo e os envia junto com a pergunta para o modelo. A resposta sai ancorada em política interna, contrato, manual técnico ou base de conhecimento, com citação da origem, algo que projetos de inteligência artificial corporativa passaram a tratar como requisito mínimo.
A pressão por esse tipo de solução acompanha o ritmo de adoção. Segundo o Gartner, mais de 80% das empresas terão usado APIs de IA generativa ou colocado aplicações com IA generativa em produção até 2026, contra menos de 5% em 2023. A mesma consultoria estima que cerca de 30% dos projetos de IA generativa sejam abandonados depois da prova de conceito, por qualidade de dados insuficiente, controles de risco frágeis, custo crescente ou valor de negócio pouco claro. Quem já levou IA agêntica para produção reconhece esse roteiro.
Provisionar os serviços leva uma tarde. Sustentar respostas confiáveis exige decisão de engenharia em cada etapa: como quebrar os documentos, qual modelo de embedding usar, como combinar busca vetorial com busca por palavra-chave, como impedir que alguém veja um documento fora do seu perímetro de acesso e como medir se a resposta está ancorada no conteúdo recuperado. Esse conjunto de escolhas separa um piloto bonito de uma arquitetura de dados que sobrevive ao segundo trimestre.
O que compõe uma arquitetura RAG com Azure OpenAI e Azure AI Search
O desenho se divide em seis camadas, cada uma com uma responsabilidade única. Essa separação é o que permite trocar uma peça sem refazer o resto, princípio que vale para qualquer projeto de engenharia de dados bem estruturado: se o modelo de embedding mudar no ano que vem, só o skillset e o índice são recriados.
| Camada | Recurso no Azure | O que faz | Decisão que pesa |
|---|---|---|---|
| Ingestão | Indexer e data source (Blob Storage, ADLS Gen2, Azure SQL, OneLake, SharePoint) | Busca o conteúdo bruto e dispara o pipeline | Frequência de atualização e indexação incremental |
| Preparação | Skillset com Text Split skill, Document Layout ou Content Understanding | Extrai o texto e quebra os documentos em chunks | Tamanho do chunk e sobreposição |
| Vetorização | Azure OpenAI Embedding skill com text-embedding-3-small ou 3-large | Gera os embeddings de cada chunk | Modelo, número de dimensões e quantização |
| Recuperação | Azure AI Search com BM25, HNSW e ranker semântico | Seleciona os trechos que vão para o modelo | Consulta híbrida com RRF e reranking L2 |
| Geração | Azure OpenAI, modelos de chat | Redige a resposta a partir dos trechos e cita a fonte | Prompt de grounding e orçamento de tokens |
| Governança | Microsoft Entra ID, filtros de segurança, private endpoints | Garante que cada identidade veja apenas o que pode | ACL herdada da origem ou filtro em tempo de consulta |
Há dois caminhos de recuperação no serviço, e a escolha define boa parte do código. O RAG clássico envia uma consulta única ao índice e sua aplicação orquestra a chamada ao modelo, com latência baixa e poucos componentes. O agentic retrieval usa um LLM para decompor a pergunta em subconsultas paralelas e devolve resposta estruturada com citações; as knowledge bases chegaram à versão geral na API 2026-04-01, enquanto planejamento de consulta e síntese de resposta seguem em preview. Para times que já mantêm agentes de IA em operação, o segundo caminho encurta a orquestração.
Como implementar a arquitetura RAG passo a passo
Passo 1: prepare o conteúdo antes de pensar em embeddings
Qualidade de recuperação começa no chunking, a divisão dos documentos em pedaços que possam ser encontrados de forma independente. Um PDF de 80 páginas indexado como um único registro nunca gera resposta precisa, porque o trecho útil se dilui no vetor médio do documento inteiro. A documentação da Microsoft aponta cerca de 512 tokens como referência para chunking por tokens, com uma sobreposição pequena entre pedaços para preservar continuidade, disciplina parecida com a de qualquer pipeline de dados bem construído.
O tipo de documento muda a estratégia. Contratos e manuais com estrutura clara se beneficiam de chunking por layout, que respeita seções, títulos e tabelas em vez de cortar por contagem de caracteres. Vale testar duas ou três configurações e comparar a recuperação com perguntas reais dos usuários, prática que sustenta projetos de ciência de dados com resultado mensurável.
Passo 2: use vetorização integrada no lugar de um pipeline paralelo
A vetorização integrada coloca chunking e geração de embeddings dentro do próprio indexer, via skillset. O ganho é operacional: quando o documento muda na origem, o indexer reprocessa a mudança do começo ao fim, sem código de sincronização escrito à mão. A Text Split skill não tem custo adicional, então o consumo se concentra nas chamadas ao modelo de embedding, detalhe que ajuda no planejamento de custo da solução no Azure.
Dois cuidados evitam retrabalho. O vectorizer configurado no índice precisa apontar para o mesmo modelo usado na indexação, caso contrário a consulta compara vetores de espaços diferentes e a relevância desaba sem nenhum erro aparente. Como os limites de tokens por minuto do Azure OpenAI valem por modelo e por assinatura, rodar o indexer em uma agenda curta permite reprocessar o que foi limitado por throttling, comportamento típico de um processo de orquestração de dados resiliente.
Passo 3: consulte com busca híbrida e ranker semântico
Busca vetorial encontra o que é conceitualmente próximo da pergunta. Busca por palavra-chave acerta o exato: código de produto, número de norma, nome de pessoa, jargão interno. A consulta híbrida executa as duas em paralelo e funde os resultados com Reciprocal Rank Fusion, e a documentação oficial do Azure AI Search recomenda essa combinação como base de qualquer implementação de RAG, reforçada pelo ranker semântico, um reordenador L2 que reavalia os melhores resultados com modelos de compreensão de linguagem.
Um detalhe de configuração muda o resultado mais do que parece: ao usar o ranker semântico, defina k igual a 50 na consulta vetorial, porque o reordenador trabalha sobre os 50 primeiros resultados e um k baixo entrega pouco material para ele avaliar. Scoring profiles ajudam a valorizar documentos recentes ou fontes prioritárias, algo que também importa em times que cuidam de camada semântica para agentes de IA.
Passo 4: orquestre a geração no Azure OpenAI
A camada de geração recebe pergunta, histórico e trechos recuperados, e devolve a resposta. O prompt de sistema precisa ser explícito em três pontos: responder apenas com base nos trechos fornecidos, citar o identificador de cada trecho usado e declarar quando a informação não está disponível. Sem isso, o modelo completa lacunas com conhecimento de treinamento e o resultado deixa de ser auditável. Retornar só os campos legíveis necessários, limitar a quantidade de chunks e instrumentar a chamada com traços e métricas mantém latência e custo sob controle, no mesmo espírito da observabilidade aplicada a agentes de IA.
Passo 5: trate segurança e avaliação como parte da arquitetura
Abrir conteúdo interno para um modelo cria uma superfície de risco nova. O Azure AI Search suporta controle de acesso em nível de documento, com permissões herdadas de ADLS Gen2 e do SharePoint em recursos hoje em preview, filtros por identidade em tempo de consulta para as demais origens e private endpoints para isolar a rede, tema central em qualquer discussão de governança de LLMs em ambiente regulado.
Avaliação fecha a implementação. Monte um conjunto de 50 a 100 perguntas reais com respostas esperadas e meça duas coisas separadamente: se a recuperação trouxe o trecho certo e se a resposta gerada se sustenta nesse trecho. Separar os sinais mostra onde investir, já que resposta ruim com recuperação correta pede ajuste de prompt, enquanto o inverso pede revisão de chunking, embedding ou consulta, lógica que vale para qualquer sistema de RAG em produção.
Erros comuns ao implementar RAG no Azure
Quatro falhas concentram a maior parte da frustração nas primeiras semanas de um projeto de RAG sobre dados corporativos:
- Indexar o documento inteiro como um registro. O vetor de um documento longo representa uma média de assuntos e não recupera o parágrafo específico que responde à pergunta. Chunking com sobreposição resolve a maior parte dos casos.
- Usar apenas busca vetorial. Perguntas com código, sigla, número de contrato ou nome próprio dependem de correspondência exata, e é aí que o BM25 da consulta híbrida entra.
- Ignorar o
krecomendado com ranker semântico. Umkbaixo limita o material que o reordenador L2 avalia e desperdiça o recurso que mais melhora a ordenação dos resultados. - Postergar o filtro de segurança. Modelar permissão depois que o índice está populado costuma exigir reindexação, com impacto direto em prazo e custo.
Custo é o risco silencioso. Cada dimensão de vetor ocupa espaço no índice, e um corpus grande com embeddings de 3.072 dimensões cresce rápido; o serviço aceita até 4.096 dimensões por campo vetorial e oferece truncamento de dimensões e quantização para reduzir armazenamento com perda controlada de precisão. O modelo de cobrança serverless, em preview, muda o cálculo para cargas intermitentes, o que vale considerar antes de dimensionar o ambiente, do mesmo modo que se avalia custo de licenciamento em plataformas de dados.
Uma arquitetura RAG confiável no Azure é resultado de decisões pequenas e verificáveis: chunk no tamanho certo, embedding coerente entre índice e consulta, recuperação híbrida com reordenação, prompt que exige citação e permissão aplicada desde o primeiro documento indexado. A BIX Tecnologia trabalha com múltiplas plataformas de dados e nuvem, e o desenho ideal muda conforme volume de conteúdo, nível de regulação e maturidade do time que vai operar a solução de IA no dia a dia.
Se sua empresa está estruturando IA generativa sobre dados corporativos e precisa de uma arquitetura que sustente isso em produção, nossos especialistas podem ajudar a desenhar o caminho certo para o seu contexto. Fale com a nossa equipe e avance na maturidade dos seus dados. ⬇️
FAQ: arquitetura RAG com Azure OpenAI e Azure AI Search
O que é uma arquitetura RAG com Azure OpenAI e Azure AI Search? É o desenho em que o Azure AI Search indexa e recupera os trechos relevantes do conteúdo da empresa e o Azure OpenAI redige a resposta com base nesses trechos. O modelo responde ancorado em documentos internos, com citação da origem, sem depender apenas do que aprendeu no treinamento.
Qual a diferença entre busca vetorial e busca híbrida no Azure AI Search? A busca vetorial encontra conteúdo conceitualmente parecido com a pergunta, mesmo sem palavras em comum. A híbrida executa busca vetorial e busca por palavra-chave em paralelo e funde os resultados com Reciprocal Rank Fusion, o que aumenta a cobertura em consultas com código, sigla ou nome próprio. A documentação da Microsoft recomenda a híbrida com ranker semântico para RAG.
Qual o tamanho ideal de chunk para RAG no Azure? A documentação da Microsoft aponta cerca de 512 tokens como referência para chunking por tokens, com uma sobreposição pequena entre pedaços para preservar contexto. O valor ideal depende do tipo de documento e dos modelos usados, então teste duas ou três configurações com perguntas reais antes de fixar o parâmetro.
Como garantir que cada usuário veja apenas os documentos autorizados? O Azure AI Search oferece controle de acesso em nível de documento, com permissões herdadas de ADLS Gen2 e do SharePoint em recursos ainda em preview, filtros por identidade em tempo de consulta para as outras origens e private endpoints para isolamento de rede. Modele a permissão antes de popular o índice, porque incluí-la depois normalmente exige reindexação.
Quando usar agentic retrieval em vez do RAG clássico? O agentic retrieval faz sentido quando o cliente é um agente ou chatbot, as perguntas são conversacionais e você quer respostas estruturadas com citações. O RAG clássico se encaixa quando o requisito é usar apenas recursos em versão geral, com latência mínima e controle fino sobre cada etapa da consulta.
