Alexandre Costa

Capacitação Microsoft AI — Aula 1: Fundamentos de IA e o ecossistema Microsoft

Written by

magoolation

em

Este é o primeiro de oito artigos que acompanham as aulas da Capacitação Microsoft AI 2026, que Otávio Lourenço da Silva e eu ministramos ao vivo entre agosto e setembro. As gravações continuam no ar; os artigos existem para quem prefere ler, revisar ou copiar o código com calma.

O que a aula cobriu

A primeira aula constrói a base que todas as outras usam: o que é IA generativa e onde ela se encaixa no ecossistema Microsoft (Copilot, Microsoft Foundry, Azure), e o caminho mínimo — e correto — entre uma aplicação e um modelo hospedado no Foundry. Saímos da aula com um chat de console funcionando, e com três decisões de arquitetura que se repetem em todo o curso.

Três ideias para levar

1. Autenticação sem segredo

Não existe chave de API no código. O Foundry SDK autentica sempre por Entra ID: DefaultAzureCredential descobre quem você é a partir do ambiente (az login na sua máquina, identidade gerenciada em produção) e o mesmo código roda nos dois lugares sem alteração. Não há segredo para vazar em log, repositório ou print de tela.

O tropeço clássico vem logo depois: ser Owner da subscription não basta. O Azure separa permissões de gerenciamento (criar e apagar recursos) de permissões de dados (conversar com o modelo). Owner tem as primeiras e nenhuma das segundas — você autentica com sucesso e recebe 403 Forbidden. O papel que resolve é o Foundry User, atribuído no recurso Foundry.

2. Uma abstração entre você e o fornecedor

Entramos pelo AIProjectClient (o Foundry SDK), pegamos um cliente de Responses para o deployment do modelo e o convertemos em um IChatClient de Microsoft.Extensions.AI. Daí para cima, o código não menciona mais nem Azure nem OpenAI. Trocar o modelo por um Ollama local é mexer nestas três linhas — e em nada mais.

AIProjectClient projectClient = new(
    endpoint: new Uri(endpoint),
    tokenProvider: new DefaultAzureCredential());
ProjectResponsesClient responseClient = projectClient.ProjectOpenAIClient
    .GetProjectResponsesClientForModel(model);
IChatClient chatClient = responseClient.AsIChatClient(model);

3. Contexto mantido pelo serviço

O chat lembra o que foi dito antes, mas o programa não guarda histórico nenhum: ele guarda apenas um ChatOptions.ConversationId e o serviço cuida do resto. Na aula 2 fazemos o oposto — o histórico numa lista que cresce no cliente — com o mesmo IChatClient, justamente para comparar as duas estratégias.

Antes de rodar

  • .NET SDK 10 e Azure CLI instalados, com az login feito no tenant certo.
  • Um recurso Foundry com um modelo implantado e o papel Foundry User atribuído à sua conta.
  • As variáveis FOUNDRY_ENDPOINT (endpoint do projeto) e FOUNDRY_MODEL (nome do deployment, não o nome comercial do modelo) no seu launchSettings.json.
  • Não altere as versões dos pacotes. O projeto converge para um pivô único (OpenAI 2.9.1); subir qualquer pacote compila e quebra em tempo de execução. O README da aula explica a matriz de versões.

Se você está na trilha Python

A mesma aula existe em Python 3.12+: AIProjectClient, cliente OpenAI e contexto no serviço via previous_response_id. Em Python não existe o problema do pivô de versões do .NET, e um único endpoint do projeto serve todas as aulas — mas a regra de fixar versões no requirements.txt continua valendo.

Próximo passo

Rode o chat, faça duas perguntas encadeadas e confirme que o modelo lembra a primeira. Depois abra o Program.cs e leia os comentários — eles foram escritos para serem lidos, não só para explicar o código. Na aula 2 entramos em LLMs e engenharia de prompts: contexto no cliente, few-shot e saída estruturada.

Dúvidas ou algo que não funcionou? Deixe nos comentários ou abra uma issue no repositório.

Comentários

Deixe um comentário

More posts