Designing and Implementing a Microsoft Azure AI Solution

Os analisadores personalizados do Azure AI Search permitem que você defina seu próprio pipeline de análise de texto combinando um tokenizer, zero ou mais token filters e zero ou mais character filters. Isso é essencial quando você precisa de um processamento de texto específico por idioma, como tratar a tokenização do japonês de forma diferente do inglês. O Azure AI Search oferece analisadores internos (incluindo os específicos por idioma, como `ja.microsoft` e `ja.lucene`), mas quando você precisa de controle fino sobre como o texto é dividido em tokens e transformado, define um analisador personalizado na definição do índice.

Um analisador personalizado é declarado no esquema do índice, na coleção `analyzers`, e faz referência a:

• Um tokenizer (por exemplo, o tokenizer `ja.lucene` para análise morfológica do japonês)
• Token filters (por exemplo, minúsculas, stop words, stemming)
• Character filters (por exemplo, mapeamento ou substituição de padrões aplicada antes da tokenização)

Isso dá controle total sobre como os campos de texto são indexados e consultados.

Por que cada opção errada está incorreta:

• A (Suggesters): Os suggesters habilitam type-ahead (autocompletar) e sugestões de pesquisa. Eles não controlam a análise de texto nem a tokenização.

• B (Synonym maps): Os synonym maps definem termos equivalentes (por exemplo, 'car' = 'automobile') para ampliar a correspondência das consultas. Eles não lidam com tokenização nem com pipelines de análise de texto específicos por idioma.

• D (Scoring profiles): Os scoring profiles personalizam como os resultados da pesquisa são classificados, dando mais peso a certos campos ou aplicando funções (por exemplo, atualidade, distância). Eles não têm nenhum papel na análise de texto ou na tokenização.

(Fonte: https://learn.microsoft.com/en-us/azure/search/index-add-custom-analyzers)

A seção Playground do portal do Microsoft Foundry (antigo Azure AI Studio) é o ambiente interativo em que você pode testar e iterar prompts com os seus modelos do Azure OpenAI implantados. O Playground oferece modos diferentes, incluindo o Chat playground para modelos conversacionais (por exemplo, GPT-4, GPT-4o), o Completions playground para conclusão de texto e o playground de geração de imagens para modelos DALL-E. Dentro do Playground, você pode ajustar parâmetros como temperature, max tokens, top_p e as penalidades de frequency/presence, adicionar mensagens de sistema, testar prompts few-shot e ver o consumo de tokens.

Por que as outras opções estariam erradas (se fossem apresentadas):

• Deployments — Esta seção serve para gerenciar implantações de modelos (criar, escalar e excluir implantações), não para testar prompts de forma interativa.
• Models catalog — Esta seção permite navegar e descobrir os modelos de IA disponíveis, mas não foi feita para testes iterativos de prompts em um modelo implantado.
• Evaluations — Esta seção é usada para avaliar sistematicamente a qualidade do modelo com conjuntos de dados e métricas de avaliação, não para testes e iterações pontuais de prompts.
• Prompt flow — É uma ferramenta de desenvolvimento para criar, testar e implantar fluxos de trabalho/pipelines de IA, algo mais complexo do que o simples teste de prompts.

O Playground foi projetado justamente como a área de testes interativa em que desenvolvedores podem experimentar rapidamente prompts e parâmetros diferentes antes de integrar o modelo às suas aplicações.

(Fonte: https://learn.microsoft.com/en-us/azure/foundry/)

O Custom Vision é a escolha adequada quando uma organização precisa detectar ou classificar objetos específicos de um domínio que não são cobertos pelos modelos pré-criados disponíveis no Azure AI Vision Image Analysis 4.0. O Custom Vision permite treinar seus próprios modelos de classificação de imagens e detecção de objetos com seus próprios dados rotulados, o que o torna ideal para cenários especializados (por exemplo, detectar defeitos de fabricação específicos, identificar determinadas espécies de plantas etc.).

Por que “Quando precisa detectar objetos específicos de um domínio que os modelos pré-criados não cobrem…” está correta: O Custom Vision foi feito justamente para cenários em que os modelos pré-criados e de uso geral do Image Analysis 4.0 não cobrem os objetos ou categorias relevantes para o seu domínio de negócio. Você envia suas próprias imagens de treinamento, rotula essas imagens e treina um modelo personalizado sob medida.

Por que “Quando precisa de remoção de fundo” está errada: A remoção de fundo é um recurso nativo do Azure AI Vision Image Analysis 4.0 (especificamente a Segment API). Isso não exige o Custom Vision — já vem pronto para uso.

Por que “Quando precisa de recursos de OCR” está errada: O OCR (Optical Character Recognition) é um recurso pré-criado do Azure AI Vision Image Analysis 4.0 (e da Read API). Não é preciso usar o Custom Vision para extrair texto de imagens.

Por que “Quando precisa de legendagem geral de imagens” está errada: A legendagem geral de imagens é um recurso pré-criado do Azure AI Vision Image Analysis 4.0. Os recursos Dense Captions e Caption fornecem descrições automáticas do conteúdo da imagem sem nenhum treinamento personalizado.

O conceito central é entender a diferença entre recursos de IA pré-criados (Image Analysis 4.0) e modelos treinados sob medida (Custom Vision). Use modelos pré-criados quando eles cobrirem o seu cenário; use o Custom Vision quando precisar de detecção ou classificação específicas de um domínio.

(Fonte: https://learn.microsoft.com/en-us/azure/ai-services/computer-vision/overview e https://learn.microsoft.com/en-us/azure/ai-services/custom-vision-service/overview)

Implementar a interpretabilidade do modelo e criar notas de transparência é a abordagem correta para garantir que as decisões da IA possam ser explicadas às partes interessadas. Os princípios de IA responsável da Microsoft destacam a transparência e a explicabilidade como pilares centrais. As notas de transparência são documentos publicados pela Microsoft para os seus serviços de IA que ajudam as partes interessadas a entender como a tecnologia de IA funciona, quais escolhas os responsáveis pelo sistema podem fazer que influenciam o desempenho e quais são as limitações da tecnologia. Ferramentas de interpretabilidade de modelos (como InterpretML, SHAP e LIME, disponíveis no Azure Machine Learning) permitem que desenvolvedores e partes interessadas entendam por que um modelo fez determinada previsão. Juntas, essas práticas garantem que as decisões da IA não sejam opacas e possam ser justificadas para as partes interessadas do negócio, reguladores e usuários finais.

Por que cada opção incorreta está errada:

A) Usar apenas modelos caixa-preta — Modelos caixa-preta são o oposto da IA explicável. Eles produzem resultados sem dar visibilidade sobre como as decisões são tomadas, o que torna mais difícil (e não mais fácil) explicar as decisões da IA às partes interessadas.

B) Aumentar a complexidade do modelo — Maior complexidade do modelo normalmente reduz a interpretabilidade. Modelos mais complexos (por exemplo, redes neurais profundas com muitas camadas) são mais difíceis de explicar, o que vai contra o objetivo de tornar as decisões da IA compreensíveis.

C) Remover todo o registro em log e o monitoramento — Remover o registro em log e o monitoramento elimina as trilhas de auditoria e a prestação de contas, que são componentes essenciais da governança de IA responsável. Sem logs, não há como revisar ou explicar decisões passadas da IA.

(Fonte: https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai e https://learn.microsoft.com/en-us/legal/cognitive-services/openai/transparency-note)