À medida que as organizações aceleram o uso de agentes de IA para automatizar processos, atender usuários e responder perguntas complexas, um padrão se repete: cada time monta sua própria solução de RAG, com pipelines paralelos, índices isolados e lógica de recuperação duplicada. No começo funciona, mas rapidamente vira um quebra-cabeça de governança, com manutenção repetida, políticas de acesso inconsistentes, qualidade variável nas respostas e pouca rastreabilidade sobre qual conhecimento foi usado e de onde ele veio. É nesse ponto que o Foundry IQ entra como peça central, trazendo uma camada unificada que padroniza o acesso ao conhecimento corporativo e o disponibiliza para agentes e aplicações por meio de um único endpoint.

A proposta é simples e poderosa: em vez de cada projeto implementar do zero extração, chunking, embeddings, indexação, consultas híbridas e reranking, você cria knowledge bases reutilizáveis, com governança e segurança aplicadas de forma consistente. Aqui vale uma distinção importante: a knowledge base define como a recuperação deve acontecer, com estratégia, regras, formato e critérios, enquanto as knowledge sources definem o que será consultado e de onde os dados vêm, representando índices e conectores para outros recursos da Azure. Na prática, isso permite escalar agentes sem ficar refém de múltiplas variações de RAG, porque o agente passa a consumir uma base padronizada e o conhecimento passa a ser oferecido como um serviço compartilhado.

Por baixo dos panos, o Foundry IQ se apoia no Azure AI Search como motor de indexação e recuperação, aproveitando ingestão, indexação, busca híbrida, capacidades semânticas e reranking para aumentar relevância. O que muda é que o Foundry IQ organiza esse motor no contexto corporativo: facilita a ingestão de múltiplas fontes, centraliza configurações e aplica governança e controle de acesso de maneira uniforme, sem exigir que cada aplicação reconstrua tudo manualmente.

O diferencial que vai além de um RAG tradicional bem implementado é o agentic retrieval. Em vez de uma consulta única que retorna trechos, a recuperação vira um processo orientado a objetivo. A knowledge base pode decompor a pergunta em sub consultas, buscar em paralelo em diferentes sources, refinar o que encontrou e só então consolidar um contexto mais confiável, idealmente com referências. Isso é especialmente útil quando a resposta depende de informações distribuídas, como combinar uma política, um procedimento e uma tabela de SLA, e quando você quer ajustar o equilíbrio entre velocidade e profundidade.

Por fim, o Foundry IQ se destaca pela flexibilidade das origens de dados. Você pode compor knowledge sources a partir de Microsoft 365 e SharePoint, OneLake e Blob Storage, Fabric e Power BI, APIs internas e até web pública quando fizer sentido. O benefício é reduzir acoplamento: o agente faz a pergunta, a knowledge base decide como buscar, as knowledge sources determinam onde buscar e o Foundry IQ entrega um contexto consistente e governável, sem o desenvolvedor criar lógica específica para cada combinação de fontes.

A partir daqui, nesta Parte 1, vamos implementar um cenário prático para a empresa fictícia Contoso Software: criar uma base de conhecimento que consome documentos de um Blob Storage via Azure AI Search, para que um knowledge agent responda perguntas sobre classificação de severidade e tempos de resposta (SLA) usando agentic retrieval.

Para montar esse laboratório, vamos criar alguns recursos na nuvem, todos na região Central US, mantendo tudo organizado no mesmo resource group. Precisaremos de:

• Resource Group: rg-foundry-ai-iq
• Microsoft Foundry
• Storage Account
• Azure AI Search

Aqui podemos ver os recursos de nuvem criados dentro do resource group chamado rg-foundry-ai-iq.

Com o Microsoft Foundry criado, o próximo passo é fazer o deploy de um modelo gpt-4.1-mini, que será usado no fluxo do nosso knowledge agent. Para isso, vamos acessar https://ai.azure.com, selecionar o projeto, clicar em Build e depois em Models.

Em seguida, na listagem de modelos, vamos pesquisar por 4.1-mini e seguir o fluxo para realizar o deploy do modelo.

Agora vamos preparar os dados. Indo para o Storage Account, vamos criar um container chamado sla-files e fazer o upload dos arquivos disponíveis no repositório oficial desta série de artigos:
https://github.com/TallesValiatti/FoundryIqOverview/tree/main/files

A ideia é que esses documentos sirvam como nossa base inicial de conhecimento, permitindo perguntas de suporte/operacional (como classificação de severidade e prazos de resposta).

Com o modelo gpt-4.1-mini criado e os arquivos já no Blob Storage, podemos partir para o Azure AI Search. Dentro do recurso de AI Search criado, vamos configurar uma fonte de dados (Knowledge source) apontando para o Blob Storage.

Vamos selecionar o Blob Storage como origem e, no passo de configuração, informar o container sla-files recém-criado.

A partir desse ponto, o conteúdo passa a ser indexado: o serviço realiza o processamento dos documentos e cria um índice no Azure AI Search, que é o que permitirá consultas rápidas e relevantes depois. Um detalhe importante aqui é que a indexação pode ser configurada com uma frequência de atualização, definindo de quanto em quanto tempo o conteúdo do Blob Storage será indexado novamente. Isso é essencial em cenários reais, onde arquivos mudam e o agente precisa responder com informação atual.

Com a fonte de dados pronta, o próximo passo é criar a Knowledge Base dentro do AI Search. Pense nela como a “embalagem” do conhecimento que será consumido por agentes: ela conecta fontes, índice e estratégia de recuperação para oferecer uma experiência de perguntas e respostas com contexto, além de suportar capacidades como reranking e agentic retrieval.

Durante a criação da Knowledge Base, precisamos selecionar qual modelo de chat completions do Microsoft Foundry será utilizado. Aqui, vamos selecionar o gpt-4.1-mini que fizemos deploy anteriormente.

Com a Knowledge Base criada, já podemos testar o fluxo diretamente na portal web da Azure, fazendo perguntas ao knowledge agent (que vai utilizar agentic retrieval para buscar nas fontes e montar a resposta). Vamos perguntar: “tell me about te incident severity classification and their response time”

A resposta retornada foi ancorada nos documentos originais enviados ao Blob Storage, e a interface também permite ver as referências/citações do conteúdo utilizado.

Se clicarmos em Debug, conseguimos enxergar as subqueries que foram geradas e executadas em paralelo: em vez de uma busca única, o knowledge base “quebra” a pergunta em intenções menores (por exemplo, uma parte para classificação de severidade e outra para tempos de resposta), recupera evidências de pontos diferentes do conteúdo e então aplica reranking para priorizar o que faz mais sentido no contexto da pergunta. Esse fluxo de recuperação iterativa é o que torna o agentic retrieval tão útil em perguntas que dependem de mais de um documento ou de mais de um trecho relevante.

Para consolidar os conceitos, encare o Foundry IQ como a “camada de conhecimento” do Microsoft Foundry: nele, você define uma knowledge base, que descreve como a recuperação deve acontecer (estratégia, regras, formato e qualidade do retorno), e conecta uma ou mais knowledge sources, que descrevem o que será consultado. Quando o agente precisa de contexto, ele chama essa knowledge base, que executa agentic retrieval , isto é, em vez de uma busca única, ela pode quebrar a pergunta em sub consultas, consultar múltiplas fontes, combinar e ranquear os resultados e devolver o melhor contexto (idealmente com referências/citações), deixando o agente focar na decisão e na resposta final.

Na próxima parte do artigo, vamos acoplar essa base de conhecimento a um agente do Microsoft Foundry, consumindo os dados do Foundry IQ de forma programática e levando esse cenário para uma aplicação real.

Você já pode baixar o projeto por esse link, e não esquece de me seguir no LinkedIn!

Até a próxima, abraços!