「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 本番はExamTopics?みたいな難易度が多いらしいが、取り合えずMS公式やUdemyの模擬で対策。
- 模擬対策で追加調査や、暗記を行い、傾向を把握して、後はMS Learnの検索方法に慣れておく。
- Microsoft の「Open Book（Learn 参照可）」試験に該当
- AI‑102 試験の「参照可能な Learn ドキュメント内検索」で使える検索エンジンは Bing のみ。
- 検索は Microsoft Learn 内の検索バーのみ利用可能でGoogle など他の検索エンジンは使用できない。
- ただ、検索バーの検索能力は低過ぎるので、Microsoft Learn TopからAzure→「AI + 機械学習」と辿った方が良い。
サービス名と機能 †
サービスの構成 †
- AzML、AzAIService、AzOpenAI、AzAISearch
- AzAI：言語（LLM＝AzOpenAI含む）、画像、情報抽出
- AzAI Foundryは、AzAIService、AzOpenAI、AzAISearchの統合プラットフォーム（旧AzAIStudio）
- マルチ サービス リソースとシングル サービス リソースがある。
- HubリソースとProjectリソースがある（AzAI系リソースはまた別）。
Available Foundry Tools †
事前構築済みの拡張ツール群
- Foundry 内で使えるツール化されたAzure AI Service
- 複数機能を組合せてユーザ向け機能を提供するための建付け。
※ 例えばエージェント（Agent Service）でLLM（OpenAI）とRAG（AI Search）を使うとか。
画像 †
Computer Vision、AI Face、AI Custom Vision、Video Indexer
言語 †
Language（Q&A、分類、NER、CLU）、Translator、Speech、LLM
情報抽出 †
Content Understanding、Document Intelligence、AI Search
OCR †
LLM †
- OpenAI、Agent Service
- マルチモーダル
生成モデル †
- LLM（RAG、Agent（Tool））
- 画像生成AI
Content Safety †
- Microsoft Foundry Content Safety
言語 †
Azure AI Language - Language Service †
- Custom Question Answering：チャットのRAGなのでLLMやAI Searchも使う
- Custom text classification & extraction - テキスト分類：2 種類のプロジェクト（単一ラベル分類、複数ラベル分類）
- Custom Named Entity Recognition - カスタムの名前付きエンティティ認識 (NER)：テキスト分類というより、単語の分類という感じ。
- Conversational language understanding - 会話言語理解（CLU）：概要、固有表現認識、PII検出、キー フレーズ抽出、感情分析、言語検出など
Azure AI Translator - Translators †
翻訳
- 言語検出：detection
- 翻訳：translation
- 音訳：transliteration
Azure AI Speech - Speech service †
音声→（機能）→文字→（機能）→翻訳→（機能）→音声
- 音声認識（Speech-to-Text）
- 翻訳（Translators）
- 音声合成（Text-to-Speech）
音声LLM †
（Phi-4-multimodal-instruct）
Voice Live †
リアルタイム対話型音声ソリューション用
- 音声認識（Speech-to-Text）
- LLM 推論（GPT‑4o Realtime など）
- 音声合成（Text-to-Speech）
画像 †
Azure AI Vision - Computer Vision †
- Computer Vision
- 読み取り可能なテキストを抽出
- 画像に関するタグを識別
- 自然言語で画像のキャプションを生成
- 検出オブジェクトの境界ボックスを返す
- 検出オブジェクトの詳細なキャプションを生成
- 検出された人物の境界ボックスを返す
- 対象領域での指定した縦横比の境界ボックスを返す
- 抽出/識別の用語
- 「ランドマーク」とは要するに有名なモノの意味。
- 「（コンテンツ）モデレーション」とは違法・有害コンテンツからユーザーを保護すること
Azure AI Vision - Face †
顔検出と分析
Azure AI Custom Vision †
画像分類と物体検出
Video Indexer †
ビデオ
- Transcript（音声文字起こし）
- OCR（画面内テキスト）
- Speakers（話者識別）
- Insights ペイン
- 出演人物
- 話題（Topics）
- オブジェクトラベル
- ブランドや人物などのエンティティ
- キーシーン
- キーワード
- 感情分析（Sentiment）
- 3ステップ
- ビデオをアップロード
- ビデオ インデックスを取得
- 各キーフレームのサムネイルを取得
- カスタマイズ
- ブランド モデル
- 言語モデル
- 人物モデル
- 音声モデル
- グローバル顔グループ化
画像LLM（gpt-4o） †
マルチモーダルのLLM
画像生成(dall-e-3） †
マルチモーダルの生成モデル（画像）
情報抽出 †
Azure Content Understanding †
- 請求書（PDF）/スライド画像（JPG）/音声（MP3）/ビデオ（MP4）の分析
- タスク作成、スキーマ定義、分析の実行
Azure Document Intelligence †
- 特定のフォーム：請求書、領収書、米国税、ID ドキュメント、...
- 特定ではないフォーム：読み取りモデル、一般ドキュメント モデル、レイアウト モデル
- カスタムモデル
Azure Document Intelligence Studio を使用してラベル付けとトレーニング（教師あり機械学習）
Azure AI Search †
≒ ナレッジ マイニング（主に情報抽出と検索機能による）
その他 †
Content Safety †
- 有害なコンテンツ検出
- Prompt Shield（不正使用検出アルゴリズム）
- カスタム・コンテンツ・フィルター
- 調整
- 重大度レベルを調整
- カスタム カテゴリ API を使用して有害なパターンを構成
- Content Safety Studio で組み込みのブロックリストを有効化
模試系 †
Language全般 †
- テキスト依存の検証、テキストに依存しない検証
言語系のサービスで使用される検証機能
- テキスト依存の検証
テキストを使って検証
- 正規表現
- 辞書・キーワード照合
- 数値の整合性チェック
- LLM による意味的検証
- 音声の場合はテキスト化した後の検証
- テキストに依存しない検証
テキストを使用せずに検証
- レイアウト構造
- 表の位置・行数・列数の検証
- チェックボックスの ON/OFF
- ロゴの有無（画像マッチング）
- 音声の場合は音での感情、話者などの検証
NERとCLUの違い †
| 項目 | NER | CLU |
| 主目的 | テキストから固有表現を抽出 | 発話の意図を理解し、必要情報を抽出 |
| 使う場面 | 文書解析、情報抽出 | チャットボット、対話システム |
| 出力 | エンティティの種類と位置 | インテント＋エンティティ |
| カスタム性 | カスタムNERあり | 完全にカスタムモデル |
| 例 | 「東京で会議があります」→ 東京（場所） | 「明日東京に行きたい」→ 旅行予約インテント＋東京（目的地） |
- NER：カスタムの名前付きエンティティ認識 (NER)：
- CLU：概要、固有表現認識、PII検出、キー フレーズ抽出、感情分析、言語検出など
- キー フレーズ抽出：発話の中から 重要な語句（キーフレーズ） を抽出、意図分類やスロット抽出を補助する。
- PII検出のエンティティ・タイプとか、沢山ある（Geolocation（...）、Personal（Address、Age、Email...）、...）。
- エンティティ定義コンポーネント
- A Prebuilt component：事前定義
- A List component：エンティティのリストを定義
- A Regex component：正規表現で抽出
- A ML component：機械学習で抽出
- 感情分析
- 戻り値（positive、negative、mixed、neutral）オプション（opinionMining、loggingOptOut?、StringIndexType?）、
- opinionMiningは文全体ではなく、局面単位に感情分析を行う（mixedが発生しうるr）。
- CLUのトレーニング方法：標準および高度のみ
- 標準：意図分類と （カスタムの名前付き）エンティティ抽出を学習
- 高度：特に CLU Intent Router（LLMベースのルーティング） を使う場合に利用
- Azure CLU の最新アーキテクチャはLLMをベースにしたファインチューニング方式
- 多言語対応では、
- 言語毎のトレーニングは不要だが言語の発話は追加する必要がある。
- 多言語モデルは意味空間を共有しているが、言語固有の表現は学習しない。
- 調整で例文を削除すると、ダッシュボードに意図間のデータ不均衡が表示される。
Orchestration Workflow †
- Azure Language の Orchestration Workflow は、複数の言語モデルをまとめて 1 つのエンドポイントとして扱える仕組み。
- 例えば、1つのボットからCLUモデル、Q&Aを統合的に利用するためのオーケストレーション ワークフローを構築する。
- Language リソース（Foundry Tools サービス）にCLUプロジェクト、Q&Aプロジェクト、Orchestration Workflow プロジェクトを格納し接続。
Translator †
- ソース言語を指定
- 正しければ翻訳の品質が上がる。
- from パラメタで指定する。
- 言語検出は行われない。
- 信頼度スコアは返らない。
- Detect Language API
- countryHintパラメータは、テキストの発信国に関するヒントを提供
- カスタム翻訳モデル：トレーニング資料に使用すべき素材によって「寛容に。」「厳密に。」がある。
- 寛容に：バイリンガル トレーニング ドキュメント（用語とスタイルを教える）
- 厳密に：チューニング ドキュメント、テスト ドキュメント、句辞書、文辞書
Speech †
- 雑音環境：カスタム音声テキスト変換
- ワード誤り率 (WER) が高い場合、誤って識別された単語を認識するようにカスタム モデルをトレーニング
- SSML（Speech Synthesis Markup Language）（音声合成マークアップ言語）（音声合成の微調整）
- Conversation Transcription（会話の文字起こし、複数の話者の区別）
- using var synthesizer = new SpeechSynthesizer?(speechConfig, audioConfig);
- speechConfig：テキスト→音声
- audioConfig：オーディオ出力
OpenAI †
- デプロイ：Microsoft Foundry リソースをプロビジョニング、カタログから モデル を選択・デプロイ
- グローバル標準：世界の空きリソースに飛ぶ、スタンダード：固定
- 「Max response」はモデルの応答のトークン数制限を設定するパラメタ
- 前提：モデル バージョンが提供終了日に達すると自動でバージョンが更新される（無効化不可）。
- 要件：
- モデル更新によって動作が変わらないようにしたい（安定性）
- 新しいモデルバージョンを本番適用前にテストしたい（検証）
- 対策：「特定バージョンを選択」し「新しいバージョンをテスト」
- RAGさせるには。
- Azure OpenAI On Your Dataと言う。
- Embeddings API を統合し、AI Search を使用。
- .txt、.md、.html、.docx、.pptx、.pdfをサポート
- チャンク化はAzAI Studioで行う。
- ベクトル化はAI Searchで行う。
- セマンティック検索は要ベーシックプラン
- デプロイ方法にはWebチャットUIとAPIがある。
- エージェントを構成する3要素
エージェント名、モデルデプロイ、指示
- Foundry エージェント
・Microsoft Foundry ポータルで作る。
・Microsoft Foundry SDK と Azure AI Agent Service SDKで使う。
- 独自エージェント（Foundryと直接関係しない）
・MAF（AutoGen?とSemantic Kernelの知見を統合）
・AutoGen?（研究的マルチエージェント）
・Semantic Kernel（ツール・ワークフロー）
- 外部 API と対話し、応答にリアルタイム データを使用するようにエージェントを構成
Bing検索ツールを構成、API アクセス用のツールを定義、Azure SDK を使用してエージェントをデプロイ
Q&A †
- 複数の言語をサポート（なにか追加することはしなくて良い）
- アクティブ ラーニングは、少なくとも 30 分待ってから提案を確認
- FAQ ドキュメントのインポートで抽出されるデータの種類は、書式設定されたテキスト、URL、箇条書きおよび番号付きリストのみ
- メンテ：「既存のペアをリンク」オプションを使用し、フォローアッププロンプトを追加。新しい質問と回答のペアを追加。
- コストへの影響：必要なスループット、ナレッジ ベースのサイズと数
Bot Service †
- LLMのチャットより、ボットの開発と展開に重点を置いている。
- chit-chat（雑談機能）は 予め雑談に使える質問と回答をセット。
- Composerは多言語機能をサポート
- ローカリゼーションタブは、言語を管理
- ロケールは、ユーザーの言語を定義するパラメタのセット
- 言語毎、コンテンツのコピーを作成
- コンテンツの翻訳を手動で提供
- Dialog
- Waterfall Dialog：一連のステップを順番に実行する「線形フロー型」ダイアログで
- Adaptive Dialog：ユーザの発話やコンテキストに応じて動的に会話を制御するイベント駆動型ダイアログ
- Prompt dialog：（Waterfall Dialog や Adaptive Dialog の中で）ユーザー入力を求め、結果を返すためにどのダイアログ
- TextPrompt?：テキスト入力を受け取る
- NumberPrompt?：数値入力を受け取る
- DateTimePrompt?：日付・時間を受け取る
- ChoicePrompt?：選択肢から選ばせる
- ConfirmPrompt?：Yes/No を確認する
- AttachmentPrompt?：ファイルや画像の添付を受け取る
- OAuthPrompt?：OAuth 認証フローを扱う
- Component Dialog / Dialog Container：複数のダイアログをまとめたコンポーネント
- その他
- Dialog Stack：ダイアログをスタック構造で管理
- DialogContext?：現在のダイアログ状態を管理
- State Management（状態管理）：ダイアログと密接に関係（UserState?/ConversationState?/Memory Scopes（Adaptive Dialog で重要）
- Recognizer：Adaptive Dialog では特に重要
- LUIS Recognizer
- Regex Recognizer
- Intent Recognizer
- QnA Recognizer（旧 QnA Maker）
- Triggers：Adaptive Dialog 特有
- OnBeginDialog?
- OnIntent?
- OnMessageActivity?
- OnEventActivity?
- 基本ボット：ユーザー入力に効果的に応答
- フォームボット：ガイド付き会話を使用してユーザーからの入力を構造化された方法で収集
- 質問応答ボット：主にユーザーの質問に答える
- Language Understanding Bot：LUIS を使った意図認識ボット
- Echo Bot：入力をそのまま返す
- QnA Bot（旧 QnA Maker）：質問応答ボットの一種だが、テンプレートとして独立
- Authentication Bot：OAuthPrompt? を使った認証付きボット
- Bot Framework CLIを使用したローカルテストでは、.luと.jsonの両方のファイル形式がサポートされる
- マルチターン会話において、ウォーターフォール ダイアログを開始し、
参照されたダイアログの新しいインスタンスをスタックのトップにプッシュするために使用するメソッド（Begin、Prompt）
Immersive Reader †
- Azure Applied AI Service の 1 つである Azure AI Immersive Reader
- 利用する2つの機能はTranslation, Text-to-speech（翻訳と音声読み上げ）
- 学習に違いのある個人がテキストコンテンツにアクセスする場合などに良い
（年齢や能力に関係なく読み書きを改善するための実証済み手法）
Vision全般 †
Vision †
- 画像分類や物体検出にドメイン特化モデルがあるが、コンパクト ドメインというのはエッジ向けらしい。
- Read APIはAzure AI VisionのOCRらしい。
Custom Vision †
- SDKを使って画像分類プロジェクトを作成実行（リソースは作成済み前提）
- Step 1: Custom Vision SDKをインストール
- Step 2: （リソースから）トレーニングと予測のキーを取得
- Step 3: サンプル画像の取得
- Step 4: コードの追加
- Step 5: Custom Visionプロジェクトを作成
- Step 6: プロジェクトにタグを作成
- Step 7: 画像のアップロードと（事前に作成した）タグ（と紐）付け
- Step 8: プロジェクトのトレーニングと公開
- Step 9: 予測エンドポイントの使用
- Step 10: アプリケーションの実行
※ AI Searchにも同じようなことをヤる演習があるので、各サービスにコレ系SDKは用意されている。
Face †
- detection_01 → detection_02 → detection_03... と精度が上がってるらしい。
- recognition_01モデルは、Azure AI Faceサービスが提供するデフォルトの認識モデル
Image Analysis API †
聞いたこと無いわ（笑）...廃止らしい。→ Azure Vision APIっぽい（read と description）
- 配色を検出で返る色：黒、青、茶、グレー、緑、オレンジ、ピンク、紫、赤、青緑、白、黄
Video Indexer †
- sourceLanguage：multi-language detection
- 自動音声認識の言語モデルをカスタマイズできる。
- インサイト（音声プロファイルを構成）
- Transcript（音声文字起こし）
- OCR（画面内テキスト）
- Speakers（話者識別）
- Insights ペイン
- 出演人物
- 話題（Topics）
- オブジェクトラベル
- ブランドや人物などのエンティティ
- キーシーン
- キーワード
- 感情分析（Sentiment）
Video Analyzer †
- 空間分析（ビデオから人を検知、個人でなく人間的な意味での）
- 現在は非推奨で Azure Percept や Vision AI モデルに移行らしいが...
REST API †
- Azure AI Video Indexerで人の動きを検出追跡した際のレスポンスJSON
"observedPeople": [{"id": 1, "thumbnailId": "GUID", "clothing": [], "matchingFace": {}, "instances": []
情報抽出全般 †
Document Intelligence †
- S0 インスタンスレベルの制限は 500 MB と 2,000 ページ
- ファイルの形式：（TXT系はサポートしない）
- PDF
- 画像系（JPG、PNG、BMP、TIFF、HEIF）
- Microsoft Office ファイル（事前構築済み、汎用ドキュメント、カスタム抽出ではサポートされない）
- 非定型フォーム
- 読み取りモデル（ページ、段落、テキスト、行、単語）
- レイアウト モデル（読み取りモデル＋選択マーク、テーブル、図表、セクション）
- 一般ドキュメント モデル（テキスト、キー・値、エンティティ、および選択マーク）
- カスタム系モデル
- カスタムモデル：レイアウトが毎回同じ → テンプレート モデル、レイアウトがバラバラ → ニューラル モデル
- カスタムモデルを使う場合、初めはニューラル モデルの方がMS推奨らしい（柔軟性が高く、総合的に高精度）。
- 作成済みモデル：複数の カスタム テンプレート モデル を まとめ複数の帳票を扱える統合モデル。
- カスタム分類モデル：複数種類のドキュメントを自動で“どのタイプの文書か”判別するためのモデル。
- 独自フォーマットの請求書に最も適合するのは「一般ドキュメント モデル」または「カスタム（抽出）モデル」
AI Search †
- データソース：Blob、Table、Cosmos DB、Azure SQL、Data Lakeと、ソコに配置したファイル。
- 検索種類：フルテキスト検索、ベクトル検索、ハイブリッド（フルテキスト＋ベクトル）検索
- セマンティック・ランキング、rerankerScore にリランクされた値が格納される（0-4）。
- その他検索：逐次検索（検索候補・オートコンプリート）、スコアリングプロファイルと結果のブースト、類義語辞書
- インデクサー：Document Cracking、Field Mappings、Skillset Execution、Output Field Mappings、Push into Index
- 何気にIndex、Skillsets、Indexerの作成は別
- Indexのfields属性：name、searchable、filterable、sortable、facetable、key、retrievable、analyzer、searchAnalyzer、indexAnalyzer、normalizer、synonymMaps、dimensions、vectorSearchProfile?
- IndexerのfieldMappingsプロパティは、srcとdstを紐つける。また、テキストコンテンツのIndexerに必須でない。
- スキルセット定義の最小セクション：name、description、skills
- スキルセットで使われるスキル（Skill）の種類を表す識別子は、@odata.type Microsoft.Skills....
- ナレッジストアとはスキルセットの「エンリッチメント結果」のインデックス以外の保存先
- Blob：Tables（行列形式）、Objects（JSON）、Files（画像、バイナリファイル）
- フルテキスト検索クエリのqueryType”には“simple”、“full”がある。
- simple：AS-IS検索、full：ワイルドカード、あいまい一致、正規表現、フィールド指定検索
- 関連性フィルター（フルテキストでもベクトルでも使える）処理に「厳密度」なるパラメタがある模様。
- 料金プラン：最大検索ユニット数に影響、無料プランにCMKは無し。ストレージ最適化プランは、標準より高レイテンシ。
- インデックスを作成後にインデクサーを作成し、データをロードしてから、インデクサを実行すると考えると、手順説明がなかなかアレになる。
つまり、インデックスのスキーマ作成時点では、インデックスの実体は作成されていないみたいな話（笑）
- レプリカ
- インデックスのコピーデータ
- レプリカ数を増やすことで負荷分散と高可用性を確保
- 読み取りクエリは各レプリカ間で負荷分散される
- 1つのレプリカが失敗しても、他のレプリカが引き続きサービス提供
- パーティション
- インデックスに対する読み取り/書き込み操作のための物理ストレージ
- インデックス内のデータは複数のパーティションに分割して保持
- 各パーティションは独立して書込可能で書込パフォーマンスが向上
- 検索ユニット(SU)
- AI Searchの課金単位
- レプリカ数とパーティション数によって決まる
- インデックスサイズが180GBの場合、8つのパーティションが必要
レプリカ数が3の場合、検索ユニットの合計数は24（8つのパーティション x 3つのレプリカ）
S1ティアに検索ユニットを追加するには6000ドル必要でStandard S2ティアにアップグレードするより高額。
その他 †
- Azure Machine Learning手順
- 新しいパイプラインを作成
- デフォルトのコンピュートターゲットを設定（コンピュータリソースを追加）
- データをインポート
- データを準備
- トレーニングする（準備する）
- パイプラインを提出する（実行する）
Azure †
Azure AI †
- 「キーとエンドポイント」ページは各AI系リソースの左メニューにあるキーとエンドポイントから確認できる。
- Azure AI Services = 旧来の API 群（Foundry とは別系統）マルチ サービス リソースとシングル サービス リソース
- シングル サービス リソース：利用機能が明確（単体）
- サービスの無料ティア利用。
- サービス指向の一意のキーとエンドポイント
- サービスごとにリージョン、SKUが異なる
- マルチ サービス リソース：複数機能を横断的に使う
- 単一のキーとエンドポイントで複数サービスにアクセス可能。
- リージョン、SKU（＝Standard）は 1 つに固定される。
- 利用中のサービスに無料ティアは存在せず、課金（請求書）を統合できる。
Bing †
後継のAI Searchと関係がある。一部バックエンド化されているらしいが、あまり明確化されていない。
- Bing Visual Search：入力が画像で類似画像検索
- Bing Image Search API：テキストで画像DBを検索
- Bing Video Search；ネット上の動画検索
- Bing Custom Search API：ネット上のユーザーが検索するドメインやウェブサイトを検索
- Bing Entity Search API：検索キーワードに関連するエンティティを構造化データとして返す（ナレッジグラフに近いデータ）
- リアルタイム検索提案
- エンティティの曖昧さ解消
- 場所を見つける
エンドポイント確認 †
az cognitiveservices account show --name XXXX --resource-group YYYY
ネットワーク †
- ファイアウォール規則を有効にしたら、
- ファイアウォールのなんらかのアクセスを許可をする必要がある。
- クラウド外からのアクセスなら、インターネット IP 範囲へのアクセスなどを使用できる。
- クラウド内からのアクセスなら、IPアドレスではなく仮想ネットワーク、サービスタグなどを使用できる。
- パブリックなインターネットルートに依存しないSaaS/PaaSへの送信にはプライベートエンドポイントを使用
- 逆パターンのSaaS/PaaSからの送信では、内部的にプライベート エンドポイントを使用する共有プライベートリンクを使用する。
- プロビジョニングしたAzure OpenAI をAzureからのみ使用できるようにする：
インターネット経由のアクセスを無効化し、プライベート エンドポイント接続でアクセスの確立を許可する。
認証 †
- WebAPIの認証
- APIキー系とAzAD（Microsoft Entra ID）系がある。
- リソースによって（エンドポイントと）キーが異なるので注意
- サービス間の認証
- マネージド ID：ダブルホップではなく、自身の ID（＝マネージド ID）でトークンを取得
- アプリのマネージド ID を有効にし、RBACアクセス許可を Microsoft Foundry に割り当て。
- Foundryインスタンスのシステム割り当てマネージド ID を有効にし、Azure Blob Storageにロールを割り当てなど。
ログ †
- 診断ログの 2 つの前提条件
- Log Analytics ワークスペース
- Azure Storage アカウント
- トレースを有効にしフィードバックを収集
Application Insights の診断設定を構成
ストレージ †
- 基本は、Azure Storage アカウント（Blob、Document）
- Azure Data Lake Storageはあまり出てこない。
- RAGの場合、AI SearchでVDBなどでてくる。
コンテナで †
※ Billing（＝Endpoint）、ApiKey?、、Eula（license）
- コンテナ実行前にモデルやアプリを仕込む簡易な手順の問題がある。
（このページを「コンテナ」で検索すると色々出てくる。）
App → Key Vault のアクセス †
- 接続文字列などではなく、Azure AD 認証 + アクセスポリシーで行う。
- Azure CLIまたはAzure PowerShellのいずれかを使用する
CMK †
customer-managed key
- Azure Key Vaultを使用する
- サービスのキーURIに、キー識別子URIの値を使用する（つまり、Key VaultのキーのURIを指定する）
- Key Vaultがキーを取得し、Key Vault内で暗号化・復号化の処理を行う。
- CMKの交換時に、キーを使用しているAzure AIサービスの更新が必要な場合がある。
DLP †
Data Loss Prevention
Azure AI Servicesのデータ損失防止（DLP）を有効化（アウトバウンドの制御）
- restrictOutboundNetworkAccess? の値を true
- 許可されたURLのリストを allowedFqdnList? プロパティに維持する
IoT †
- Azure Blob Storage on IoT Edge：エッジストレージソリューション
- Azure IoT edge stream device：IoTデバイスからクラウドにデータをストリーミングするデバイス
- Azure IoT Edge parallel storage：IoT Edge環境における分散処理の概念（製品名にはない）
Compliance Manager †
データコンプライアンス遵守と適切な保管を確保
AIだ †
メトリック系 †
- 分類問題：混同行列
- BLEU（0-100）：Azure Translator で 40 - 60 は、高品質の翻訳を示す。
パラメタ系 †
プロンプト・エンジニアリング †
- 解り易くする、具体的にする、順序が重要（小さくする必要はない）
- 概要要約生成でプロンプトを絞り込み、キーの詳細を指定
- ペルソナ...
RAG †
- OK：低リスク、支援、生産性に重点を置いたシナリオをサポートするユース ケース
- NG：
- ライセンスを取得した専門家と説明責任を必要とする高リスクの規制ドメイン
- 商品レコメンドはプライバシーとセキュリティ、公平性、包括性、説明責任的に難あり。
- 模試ではないが結局、何が似通っていて何処が違うのか？
- 信頼性と安全性・プライバシーとセキュリティ：「AI が[正しく動く]こと」・「データが[守られる]こと」
- 公平性・包括性：「結果が[偏らない]こと」・「誰もが[使える]こと」
- 透明性・アカウンタビリティ：「AI の判断が[見える]こと」・「問題が起きたとき責任が明確なこと」
多変量異常検出ソリューション †
- 単変量モデルは、センサー毎の異なる次元間の相関や相互作用を見落とす可能性がある。
- 多変量モデルを、センサー毎に構成することは、複雑さやメンテナンスの負担が増す。
- すべての次元に対して固定の感度閾値を使用することは理想的ではない。
- 歴史的データを使用して異常検出の閾値を動的に調整するメカニズムを開発。
- 各センサータイプの特定の特徴やパターンを効果的に捉え異常検知プロセスをカスタマイズ。
ITだ †
REST API †
- つーか、URIってヘッダなんだな。知ってたけど、あんまそう言わんし。
ググれ †
REST API †
- イメージ生成モデル
- ヘッダ：API のバージョン、Azure OpenAI リソース名、デプロイ ID
- リクエスト
{
"prompt": "A badger wearing a tuxedo",
"n": 1,
"size": "1024x1024",
"quality": "hd",
"style": "vivid"
}
- レスポンス
{
"created": 1686780744,
"data": [
{
"url": "<URL of generated image>",
"revised_prompt": "<prompt that was used>"
}
]
}
ExamTopics? †
まぁ解る系 †
チャットボットを構築 †
以下の要件を満たすチャットボットを構築する必要があります。
- 雑談、ナレッジベース、多言語モデルをサポート
- ユーザーメッセージの感情分析を実行
- 最適な言語モデルを自動選択
チャットボットに何を統合すべきですか？
- QnA Maker、言語理解、ディスパッチ
- Translator、音声認識、ディスパッチ
- 言語理解、テキスト分析、QnA Maker（最多投票）
- テキスト分析、Translator、ディスパッチ
帳票読込 †
- あなたの会社は、従業員が経費精算書に領収書を記入する時間を短縮したいと考えています。
- 領収書はすべて英語で書かれています。
- 領収書から、ベンダーや取引合計額といったトップレベルの情報を抽出する必要があります。
- ソリューションは開発労力を最小限に抑える必要があります。
どのAzureサービスを使用すべきでしょうか？
- カスタムビジョン
- パーソナライザー
- フォーム認識機能（最多投票）
- コンピュータービジョン
※ 機能階層的なものをイメージしておく。
コンテナ、解る。 †
Anomaly Detector APIをコンテナでデプロイ †
- Anomaly Detector API のコンテナー化されたバージョンを、テスト用のローカルデバイスとオンプレミスのデータセンターで使用する予定です。
- コンテナー化されたデプロイメントが以下の要件を満たしていることを確認する必要があります。
- コンテナを実行するデバイスのコマンドライン履歴に課金情報と API 情報が保存されないようにします。
- Azure RBACを使用して、コンテナ・イメージへのアクセスを制御します。
- アクション
- カスタム Dockerfile を作成
- Anomaly Detector コンテナー イメージをプル
- イメージをビルド
- Azure コンテナ レジストリにイメージをプッシュ
※ そりゃそーだ（笑）
LUISアプリをコンテナにデプロイ †
- コンテナにデプロイされた app1 という Language Understanding アプリケーションを使用する予定。
- app1は、lu1 という Language Understanding オーサリングリソースを使用して開発された。
| Version | Trained date | Published date |
| V1.2 | None | None |
| V1.1 | 2020-10-01 | None |
| V1.0 | 2020-09-01 | 2020-09-15 |
- コンテナにデプロイできる Language Understanding (LUIS) アプリのバージョンは
「学習済み (Trained) である必要があるが、公開 (Published) されている必要はない」
- アクション
- vx.x を選択（デプロイ可能な最新バージョン）。
- 「コンテナ用にエクスポート（GZIP）」オプションを使用してモデルをエクスポート
- コンテナを実行し、モデル・ファイルをマウントする。
※ 同じ様な方式は、Azure AI Custom Visionなどでも採用されているらしい。
難易度高目 †
- あなたは、一般向けウェブサイトからの動画とテキストを処理する新しい販売システムを開発しています。
- この販売システムを監視し、ユーザーの所在地や経歴に関わらず公平な結果が得られるようにする予定です。
- 監視要件を満たすための指針となる、責任あるAI原則を2つ挙げてください。正解はそれぞれ解決策の一部を示しています。
- 透明性
- 公平性（最多投票）
- 包括性（最多投票）
- 信頼性と安全性
- プライバシーとセキュリティ
※ 暗記が必要。...ってか、やっぱ「公平性」と「包括性」って被ってるのね。
そんなン知るか系 †
要件XXXでリソース作成 †
- 感情分析と光学式文字認識（OCR）を実行するために使用する新しいリソースを作成する必要があります。
- ソリューションは以下の要件を満たす必要があります。
- 単一のキーとエンドポイントを使用して複数のサービスにアクセス
- 将来使用する可能性のあるサービスの課金を統合する。
- 将来的にComputer Visionの使用をサポート
- 新しいリソースを作成するためのHTTPリクエストをどのように完了すればよい？
PUT https://management.azure.com/subscriptions/XXXXXXXX-XXXX-XXXXXXXXXXxx/resourceGroups/RG1/providers/Microsoft.CognitiveServices/accounts/CS1?api-version=2017-04-18
{
"location": "West US",
"kind": "CognitiveServices",
"sku": {
"name":
"SO"
},
"properties":{},
"identity": {
"type": "SystemAssigned"
}
}
※ PUT、CognitiveServices?
LUISのフレーズ †
- それぞれに独自の言語理解モデルを持つチャットボットが100個あります。
- 各モデルに同じフレーズを頻繁に追加する必要があります。
- 新しいフレーズを追加するには、言語理解モデルをプログラムで更新する必要があります。
- コードはどのように完成させるべきでしょうか？
var phraselistId = await client.Features.AddPhraseListAsync
(
appId,
versionId,
new PhraselistCreateObject
{
EnabledForAllModels = false,
IsExchangeable = true,
Name = "PL1",
Phrases = "item1,item2,item3,item4,item5"
}
);
※ AddPhraseListAsync?、PhraselistCreateObject?
※ この文脈での「フレーズ」とは、チャットボットの言語理解モデル（例：LUIS）に対して「重要な語や言い回し」として教える文字列の集合
参考 †
対策情報 †
模擬試験 †
Tags: :.NET開発, :構成管理ツール, :CI, :BI/AI
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
