MS_AzureAI102Prep - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
- 戻る(AzureのAI系サービス)
- Azure AI 資格(AI-900)
-
Azure AI 資格(AI-102)
- Azure AI 資格(AI-102)対策
補足(本ページの位置づけ): AI-102 の学習記録が MS Learn の学習パスをたどったものであるのに対し、 こちらは 模擬試験を解いて詰まった点を潰していく作業ノートである。 節の構成もそれを反映しており、
- 「サービス名と機能」= 紛らわしいサービス名の整理
- 「模試系」= 公式プラクティス評価・Udemy で出た論点
- 「ExamTopics」= 難易度別に分類した所感
という並びになっている。 見出しの「そんなン知るか系」「ググれ」といった表現は 元ページのままである(学習の実感を残すため)。
補足(模擬試験サイトの扱い): 参考に挙がっている ExamTopics は、 実際の試験問題が投稿されている場合がある。 Microsoft 認定資格試験の受験者規約(NDA)に抵触する恐れがあるため、 対策には 公式のプラクティス評価と 学習ガイドを主に使うのが安全である (Azure AI 資格(AI-900)、 GitHub Foundations模擬試験にも 同じ注意を記載している)。
- 本番はExamTopicsみたいな難易度が多いらしいが、取り合えずMS公式やUdemyの模擬で対策。
- 模擬対策で追加調査や、暗記を行い、傾向を把握して、後はMS Learnの検索方法に慣れておく。
- AzML、AzAIService、AzOpenAI、AzAISearch
- AzAI:言語(LLM=AzOpenAI含む)、画像、情報抽出
- AzAI Foundryは、AzAIService、AzOpenAI、AzAISearchの統合プラットフォーム(旧AzAIStudio)
- マルチ サービス リソースとシングル サービス リソースがある。
- HubリソースとProjectリソースがある(AzAI系リソースはまた別)。
事前構築済みの拡張ツール群
- 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
- 画像:Computer Vision、Video Indexer
- 情報抽出:Content Understanding、Document Intelligence、AI Search
Translator以外にも以下に機能がある。
- Speech
- Azure OpenAI
- Video Indexer
- Immersive Reader
- AI Search の TextTranslationSkill
- OpenAI、Agent Service
- マルチモーダル
- 音声LLM
- 画像LLM
- LLM(RAG、Agent(Tool))
- 画像生成AI
- Custom Question Answering:チャットのRAGなのでLLMやAI Searchも使う
- Custom text classification & extraction - テキスト分類:2 種類のプロジェクト(単一ラベル分類、複数ラベル分類)
- Custom Named Entity Recognition - カスタムの名前付きエンティティ認識 (NER):テキスト分類というより、単語の分類という感じ。
- Conversational language understanding - 会話言語理解(CLU):概要、固有表現認識、PII検出、キー フレーズ抽出、感情分析、言語検出など
翻訳
- 言語検出:detection
- 翻訳:translation
- 音訳:transliteration
音声→(機能)→文字→(機能)→翻訳→(機能)→音声
- 音声認識(Speech-to-Text)
- 翻訳(Translators)
- 音声合成(Text-to-Speech)
(Phi-4-multimodal-instruct)
リアルタイム対話型音声ソリューション用
- 音声認識(Speech-to-Text)
- LLM 推論(GPT-4o Realtime など)
- 音声合成(Text-to-Speech)
- 画像分析
- OCR
- 物体検出
- 空間認識
顔検出と分析
画像分類と物体検出
-
画像分類
- スマート ラベラー
-
物体検出
ビデオ
- Transcript(音声文字起こし)
- OCR(画面内テキスト)
- Speakers(話者識別)
- Insights ペイン
マルチモーダルのLLM
マルチモーダルの生成モデル(画像)
- 請求書(PDF)/スライド画像(JPG)/音声(MP3)/ビデオ(MP4)の分析
- タスク作成、スキーマ定義、分析の実行
-
事前構築済みモデル
-
特定のフォーム:請求書、領収書、米国税、ID ドキュメント、...
-
特定ではないフォーム:読み取りモデル、一般ドキュメント モデル、レイアウト モデル
-
-
カスタムモデル
Azure Document Intelligence Studio を使用してラベル付けとトレーニング(教師あり機械学習)
≒ ナレッジ マイニング(主に情報抽出と検索機能による)
テキスト/画像の有害コンテンツ検知とプロンプト防御(Prompt Shields)を提供するガードレールサービス
-
カスタム・コンテンツ・フィルター
-
調整
- スコア粒度(outputType)はFourSeverityLevels(0/2/4/6)または EightSeverityLevels(0–7)
- 運用側でスコアを内部ポリシーの「許可 / ログ / レビュー / ブロック」にマッピングする。
- カテゴリの明示指定:categories に ["Hate","Sexual","Violence","SelfHarm"] のように渡す(未指定なら全カテゴリ)
- カスタム カテゴリ API を使用して有害なパターンを構成:Standard(JSONLで学習)、Rapid(少数例から即時検出)
- Content Safety Studio で組み込みのブロックリストを有効化
-
テキスト依存の検証、テキストに依存しない検証
言語系のサービスで使用される検証機能-
テキスト依存の検証 テキストを使って検証
- 正規表現
- 辞書・キーワード照合
- 数値の整合性チェック
- LLM による意味的検証
- 音声の場合はテキスト化した後の検証
-
テキストに依存しない検証 テキストを使用せずに検証
- レイアウト構造
- 表の位置・行数・列数の検証
- チェックボックスの ON/OFF
- ロゴの有無(画像マッチング)
- 音声の場合は音での感情、話者などの検証
-
-
事前構築済みモデル、カスタムモデルがある。
- 事前構築済みモデル:NER・CLUなどで使われる。
- カスタムモデル:カスタムテキスト分類、カスタムNER・CLU、カスタムQ&A・オーケストレーション
リソースを作成する際に以下をオンにして作成できる。
- 感情分析
- キーフレーズ抽出
- テキストの要約
- 会話言語理解(CLU)
- 固有表現認識(NER)
- 事前構成された質問の回答
- Text Analytics for Health
| 項目 | 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をベースにしたファインチューニング方式
-
多言語対応では、
- 言語毎のトレーニングは不要だが言語の発話は追加する必要がある。
- 多言語モデルは意味空間を共有しているが、言語固有の表現は学習しない。
-
調整で例文を削除すると、ダッシュボードに意図間のデータ不均衡が表示される。
-
-
機能
- 言語
- 検出
- 翻訳
- 表記変換
- 辞書検索
- 辞書の例
-
ソース言語を指定
- 正しければ翻訳の品質が上がる。
- from パラメタで指定する。
- 言語検出は行われない。
- 信頼度スコアは返らない。
-
Detect Language API
- countryHintパラメータは、テキストの発信国に関するヒントを提供
-
カスタム翻訳モデル:トレーニング資料に使用すべき素材によって「寛容に。」「厳密に。」がある。
- 寛容に:バイリンガル トレーニング ドキュメント(用語とスタイルを教える)
- 厳密に:チューニング ドキュメント、テスト ドキュメント、句辞書、文辞書
-
機能
- Speech to text(音声テキスト変換)
- Text to speech (テキスト読み上げ)
- Speech Translation(音声翻訳)
- Speaker Recognition (話者認識)
- Intent Recognition(意図認識)
-
話者関連 | 話者認証 | 特定の人物であることを確認する(1対1) | セキュリティ、ログイン | | 話者特定 | 複数人の中から “誰が話したか” を特定する(1対多) | コールセンター、CRM | | 話者分離 | 音声の中で “誰がどこで話したか” を区間ごとに分ける | 会議録音、議事録 |
-
Config
-
using var synthesizer = new SpeechSynthesizer(speechConfig, audioConfig);
- speechConfig:テキスト→音声
- audioConfig:オーディオ出力
-
SSML(Speech Synthesis Markup Language)(音声合成マークアップ言語)(Text to speechの微調整)
-
-
カスタム モデル
-
Text to speech:自社ボイス合成
-
Speech to text:語彙ブーストや言語/音響モデル適応で精度を改善。
- 雑音環境
- ワード誤り率 (WER) が高い場合
-
-
デプロイ: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がある。
-
Agent Service
-
エージェントを構成する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 を使用してエージェントをデプロイ
-
- 複数の言語をサポート(なにか追加することはしなくて良い)
- アクティブ ラーニングは、少なくとも 30 分待ってから提案を確認
- FAQ ドキュメントのインポートで抽出されるデータの種類は、書式設定されたテキスト、URL、箇条書きおよび番号付きリストのみ
- メンテ:「既存のペアをリンク」オプションを使用し、フォローアッププロンプトを追加。新しい質問と回答のペアを追加。
- コストへの影響:必要なスループット、ナレッジ ベースのサイズと数
-
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
-
Bot template
-
基本ボット:ユーザー入力に効果的に応答
-
フォームボット:ガイド付き会話を使用してユーザーからの入力を構造化された方法で収集
-
質問応答ボット:主にユーザーの質問に答える
-
Language Understanding Bot:LUIS を使った意図認識ボット
-
Echo Bot:入力をそのまま返す
-
QnA Bot(旧 QnA Maker):質問応答ボットの一種だが、テンプレートとして独立
-
Authentication Bot:OAuthPrompt を使った認証付きボット
-
-
Bot Framework CLIを使用したローカルテストでは、.luと.jsonの両方のファイル形式がサポートされる
-
マルチターン会話において、ウォーターフォール ダイアログを開始し、
参照されたダイアログの新しいインスタンスをスタックのトップにプッシュするために使用するメソッド(Begin、Prompt)
-
Azure Applied AI Service の 1 つである Azure AI Immersive Reader
-
利用する2つの機能はTranslation, Text-to-speech(翻訳と音声読み上げ)
-
学習に違いのある個人がテキストコンテンツにアクセスする場合などに良い
(年齢や能力に関係なく読み書きを改善するための実証済み手法)
- Azure Language の Orchestration Workflow は、複数の言語モデルをまとめて 1 つのエンドポイントとして扱える仕組み。
- 例えば、1つのボットからCLUモデル、Q&Aを統合的に利用するためのオーケストレーション ワークフローを構築する。
- Language リソース(Foundry Tools サービス)にCLUプロジェクト、Q&Aプロジェクト、Orchestration Workflow プロジェクトを格納し接続。
画像分類や物体検出
-
Computer Vision
- 読み取り可能なテキストを抽出
- 画像に関するタグを識別
- 自然言語で画像のキャプションを生成
- 検出オブジェクトの境界ボックスを返す
- 検出オブジェクトの詳細なキャプションを生成
- 検出された人物の境界ボックスを返す
- 対象領域での指定した縦横比の境界ボックスを返す
-
抽出/識別の用語
- 「ランドマーク」とは要するに有名なモノの意味。
- 「(コンテンツ)モデレーション」とは違法・有害コンテンツからユーザーを保護すること
ほとんど画像分類と物体検出のカスタム学習の話。
-
ドメイン選択:用途特化の学習プリセットがある。コンパクト ドメインはエッジ向けらしい。
-
Smart Labeler:一部だけ手動ラベル → 残りを自動アノテーション、不確実順で見直しエクスポート
-
ONNX / TensorFlow / Core ML / Docker コンテナ などエッジ・オフライン推論向けに出力
-
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は用意されている。
-
detection
- detection_01 → detection_02 → detection_03... と精度が上がってるらしい。
- 01:正面顔に強い、02:小顔・角度、03:最新系。回転・小顔・ランドマーク精度
-
recognition
- recognition_01モデルは、Azure AI Faceサービスが提供するデフォルトの認識モデル
- ...
※ Face のランドマークとは目・鼻・口・輪郭などの“座標”を数十点レベルで返す機能
聞いたこと無いわ(笑)...廃止らしい。→ Azure Vision APIっぽい(read と description)
- 配色を検出で返る色:黒、青、茶、グレー、緑、オレンジ、ピンク、紫、赤、青緑、白、黄
-
sourceLanguage:multi-language detection
-
3ステップ
- ビデオをアップロード
- ビデオ インデックスを取得
- 各キーフレームのサムネイルを取得
-
インサイト(音声プロファイルを構成)
- Transcript(音声文字起こし)
- OCR(画面内テキスト)
- Speakers(話者識別)
- Insights ペイン
- 出演人物
- 話題(Topics)
- オブジェクトラベル
- ブランドや人物などのエンティティ
- キーシーン
- キーワード
- 感情分析(Sentiment)
-
カスタマイズ
- ブランド モデル
- 言語モデル
- 人物モデル
- 音声モデル
- グローバル顔グループ化
- 空間分析(ビデオから人を検知、個人でなく人間的な意味での)
- 現在は非推奨で Azure Percept や Vision AI モデルに移行らしいが...
generateThumbnail?width={width}&height={height}&smartCropping={smartCropping}&model-version={model-version}
-
Azure AI Video Indexerで人の動きを検出追跡した際のレスポンスJSON
"observedPeople": [{"id": 1, "thumbnailId": "GUID", "clothing": [], "matchingFace": {}, "instances": []
-
S0 インスタンスレベルの制限は 500 MB と 2,000 ページ
-
ファイルの形式:(TXT系はサポートしない)
- 画像系(JPG、PNG、BMP、TIFF、HEIF)
- Microsoft Office ファイル(事前構築済み、汎用ドキュメント、カスタム抽出ではサポートされない)
-
事前構築済みモデル
-
定型フォーム
- 米国のものが多い
-
非定型フォーム
- 読み取りモデル(ページ、段落、テキスト、行、単語)
- レイアウト モデル(読み取りモデル+選択マーク、テーブル、図表、セクション)
- 【下火】一般ドキュメント モデル(テキスト、キー・値、エンティティ、および選択マーク)
-
-
カスタム系モデル
- カスタムモデル:レイアウトが毎回同じ → テンプレート モデル、レイアウトがバラバラ → ニューラル モデル
- カスタムモデルを使う場合、初めはニューラル モデルの方がMS推奨らしい(柔軟性が高く、総合的に高精度)。
- 作成済みモデル:複数の カスタム テンプレート モデル を まとめ複数の帳票を扱える統合モデル。
- カスタム分類モデル:複数種類のドキュメントを自動で“どのタイプの文書か”判別するためのモデル。
-
独自フォーマットの請求書に最も適合するのは「一般ドキュメント モデル」または「カスタム(抽出)モデル」
-
データソース:Blob、Table、Cosmos DB、Azure SQL、Data Lakeと、ソコに配置したファイル。
-
検索種類:フルテキスト検索、ベクトル検索、ハイブリッド(フルテキスト+ベクトル)検索
-
その他検索:逐次検索(検索候補・オートコンプリート)、スコアリングプロファイルと結果のブースト、類義語辞書
-
インデクサー: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 ...。
-
スキル(Skill)は「エンリッチメント」を行いなんらかの情報の加工・抽出などを行い、結果はインデックス(検索)以外にナレッジストア(BI/監査)にも格納される。
-
例:DocumentExtraction → SplitSkill → OCR/Text → Language Skills →(Custom Skills)→ OutputField
-
WebApiSkill(カスタムスキルを取り込むための定義)
-
ナレッジストアはBlob:Tables(行列形式)、Objects(JSON)、Files(画像、バイナリファイル)
- フルテキスト検索(BM25)、ベクトル検索(kNN)
-
フルテキスト検索クエリのqueryType”には“simple”、“full”がある。
-
simple:AS-IS検索、full:ワイルドカード、あいまい一致、正規表現、フィールド指定検索
-
セマンティック・ランキング:rerankerScore にリランクされた値が格納される(0-4)。
-
関連性フィルター(フルテキストでもベクトルでも使える)処理に「厳密度」なるパラメタがある模様。
-
料金プラン:最大検索ユニット数に影響、無料プランにCMKは無し。ストレージ最適化プランは、標準より高レイテンシ。
-
インデックスを作成後にインデクサーを作成し、データをロードしてから、インデクサを実行する。と考えると、
手順説明がなかなかアレ。インデックス(のスキーマを)作成した時点では、インデックス(の実体は)作成されていないので(笑) -
レプリカ・パーティション
-
レプリカ
- インデックスのコピーデータ
- レプリカ数を増やすことで負荷分散と高可用性を確保
- 読み取りクエリは各レプリカ間で負荷分散される
- 1つのレプリカが失敗しても、他のレプリカが引き続きサービス提供
-
パーティション
- インデックスに対する読み取り/書き込み操作のための物理ストレージ
- インデックス内のデータは複数のパーティションに分割して保持
- 各パーティションは独立して書込可能で書込パフォーマンスが向上
-
検索ユニット(SU)数 = パーティション数 * レプリカ数
-
-
AI Searchの課金単位
- SU単価 × SU数(SKUに依存)+ AIエンリッチメント実行コスト
- インデックスサイズが180GBの場合、8つのパーティションが必要
更に、レプリカ数が3の場合、検索ユニットの合計数は24(8つのパーティション * 3つのレプリカ)
S1ティアに24ユニットを追加するには6000ドル必要でStandard S2ティアにアップグレードするより高額。
- Azure Machine Learning手順
- 新しいパイプラインを作成
- デフォルトのコンピュートターゲットを設定(コンピュータリソースを追加)
- データをインポート
- データを準備
- トレーニングする(準備する)
- パイプラインを提出する(実行する)
-
「キーとエンドポイント」ページは各AI系リソースの左メニューにあるキーとエンドポイントから確認できる。
-
Azure AI Services = 旧来の API 群(Foundry とは別系統)マルチ サービス リソースとシングル サービス リソース
-
シングル サービス リソース:利用機能が明確(単体)
- サービスの無料ティア利用。
- サービス指向の一意のキーとエンドポイント
- サービスごとにリージョン、SKUが異なる
-
マルチ サービス リソース:複数機能を横断的に使う
- 単一のキーとエンドポイントで複数サービスにアクセス可能。
- リージョン、SKU(=Standard)は 1 つに固定される。
- 利用中のサービスに無料ティアは存在せず、課金(請求書)を統合できる。
-
後継の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からのみ使用できるようにする:
インターネット経由のアクセスを無効化し、プライベート エンドポイント接続でアクセスの確立を許可する。 -
既定のアクションを「不一致は拒否」にしてホワイトリストを別途作成。
"field" : "Microsoft.CognitiveServices/accounts/networkAcls.defaultAction" "notEquals" : "Deny"
-
WebAPIの認証
- APIキー系とAzAD(Microsoft Entra ID)系がある。
- リソースによって(エンドポイントと)キーが異なるので注意
-
サービス間の認証
- マネージド ID:ダブルホップではなく、自身の ID(=マネージド ID)でトークンを取得
- アプリのマネージド ID を有効にし、RBACアクセス許可を Microsoft Foundry に割り当て。
- Foundryインスタンスのシステム割り当てマネージド ID を有効にし、Azure Blob Storageにロールを割り当てなど。
-
診断ログの 2 つの前提条件
- Log Analytics ワークスペース
- Azure Storage アカウント
-
Log Analyticsの課金
- データの取り込みに対して
- データの保持に対して
-
トレースを有効にしフィードバックを収集
Application Insights の診断設定を構成
- 基本は、Azure Storage アカウント(Blob、Document)
- Azure Data Lake Storageはあまり出てこない。
- RAGの場合、AI SearchでVDBなどでてくる。
-
実行
docker run ... mcr.microsoft.com/azure-cognitive-service/vision/<image-id> Eula=accept billing={ENDPOINT_URI}
※ Billing(=Endpoint)、ApiKey、、Eula(license)
- コンテナ実行前にモデルやアプリを仕込む簡易な手順の問題がある。
(このページを「コンテナ」で検索すると色々出てくる。)
App → Key Vault のアクセス
- 接続文字列などではなく、Azure AD 認証 + アクセスポリシーで行う。
- Azure CLIまたはAzure PowerShellのいずれかを使用する
customer-managed key
- Azure Key Vaultを使用する
- サービスのキーURIに、キー識別子URIの値を使用する(つまり、Key VaultのキーのURIを指定する)
- Key Vaultがキーを取得し、Key Vault内で暗号化・復号化の処理を行う。
- CMKの交換時に、キーを使用しているAzure AIサービスの更新が必要な場合がある。
Data Loss Prevention
Azure AI Servicesのデータ損失防止(DLP)を有効化(アウトバウンドの制御)
- restrictOutboundNetworkAccess の値を true
- 許可されたURLのリストを allowedFqdnList プロパティに維持する
- Azure Blob Storage on IoT Edge:エッジストレージソリューション
- Azure IoT edge stream device:IoTデバイスからクラウドにデータをストリーミングするデバイス
- Azure IoT Edge parallel storage:IoT Edge環境における分散処理の概念(製品名にはない)
データコンプライアンス遵守と適切な保管を確保
- 分類問題:混同行列(AIプロジェクトのマネジメントの該当節を参照)
- BLEU(0-100):Azure Translator で 40 - 60 は、高品質の翻訳を示す。
- LLMの温度パラメタ(上げるほど揺らぐ)
- 解り易くする、具体的にする、順序が重要(小さくする必要はない)
- 概要要約生成でプロンプトを絞り込み、キーの詳細を指定
- ペルソナ...
- セマンティック検索
- ベクター検索
-
OK:低リスク、支援、生産性に重点を置いたシナリオをサポートするユース ケース
-
NG:
- ライセンスを取得した専門家と説明責任を必要とする高リスクの規制ドメイン
- 商品レコメンドはプライバシーとセキュリティ、公平性、包括性、説明責任的に難あり。
-
模試ではないが結局、何が似通っていて何処が違うのか?
- 信頼性と安全性・プライバシーとセキュリティ:「AI が[正しく動く]こと」・「データが[守られる]こと」
- 公平性・包括性:「結果が[偏らない]こと」・「誰もが[使える]こと」
- 透明性・アカウンタビリティ:「AI の判断が[見える]こと」・「問題が起きたとき責任が明確なこと」
- 単変量モデルは、センサー毎の異なる次元間の相関や相互作用を見落とす可能性がある。
- 多変量モデルを、センサー毎に構成することは、複雑さやメンテナンスの負担が増す。
- すべての次元に対して固定の感度閾値を使用することは理想的ではない。
- 歴史的データを使用して異常検出の閾値を動的に調整するメカニズムを開発。
- 各センサータイプの特定の特徴やパターンを効果的に捉え異常検知プロセスをカスタマイズ。
※ Azure AI Anomaly Detector ※2026年廃止予定
- つーか、URIってヘッダなんだな。知ってたけど、あんまそう言わんし。
- イメージ生成モデル
-
ヘッダ: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>" } ] }
-
以下の要件を満たすチャットボットを構築する必要があります。
- 雑談、ナレッジベース、多言語モデルをサポート
- ユーザーメッセージの感情分析を実行
- 最適な言語モデルを自動選択
チャットボットに何を統合すべきですか?
- QnA Maker、言語理解、ディスパッチ
- Translator、音声認識、ディスパッチ
- 言語理解、テキスト分析、QnA Maker(最多投票)
- テキスト分析、Translator、ディスパッチ
- あなたの会社は、従業員が経費精算書に領収書を記入する時間を短縮したいと考えています。
- 領収書はすべて英語で書かれています。
- 領収書から、ベンダーや取引合計額といったトップレベルの情報を抽出する必要があります。
- ソリューションは開発労力を最小限に抑える必要があります。
どのAzureサービスを使用すべきでしょうか?
- カスタムビジョン
- パーソナライザー
- フォーム認識機能(最多投票)
- コンピュータービジョン
※ 機能階層的なものをイメージしておく。
-
Anomaly Detector API のコンテナー化されたバージョンを、テスト用のローカルデバイスとオンプレミスのデータセンターで使用する予定です。
- コンテナー化されたデプロイメントが以下の要件を満たしていることを確認する必要があります。
- コンテナを実行するデバイスのコマンドライン履歴に課金情報と API 情報が保存されないようにします。
- Azure RBACを使用して、コンテナ・イメージへのアクセスを制御します。
-
アクション
- カスタム Dockerfile を作成
- Anomaly Detector コンテナー イメージをプル
- イメージをビルド
- Azure コンテナ レジストリにイメージをプッシュ
※ そりゃそーだ(笑)
-
コンテナにデプロイされた 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つ挙げてください。正解はそれぞれ解決策の一部を示しています。
- 透明性
- 公平性(最多投票)
- 包括性(最多投票)
- 信頼性と安全性
- プライバシーとセキュリティ
※ 暗記が必要。...ってか、やっぱ「公平性」と「包括性」って被ってるのね。
-
感情分析と光学式文字認識(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
-
それぞれに独自の言語理解モデルを持つチャットボットが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)に対して「重要な語や言い回し」として教える文字列の集合
-
Azure AI エンジニア アソシエイト AI-102の学習メモ #資格 - Qiita
https://qiita.com/tomiyou/items/3d93b59a3838ef6863d6 -
【合格体験記】AI-102:Azure AI Engineer Associate #資格 - Qiita
https://qiita.com/HotDogs/items/c8dce0029b0e7e9fab4b\ 重要なのはMicrosoft Learnを使いこなすこと!!!! -
AI-102 (Azure AI Engineer Associate) 合格(不合格)体験記
https://zenn.dev/ch0c0/articles/3878491bbe273e -
今アツい!AI-102(Azure AI Engineer Associate)合格体験記|AvaKansai
https://note.com/avakansai/n/ncc226be1221f -
AI-102 (Azure AI Engineer Associate) を取得してみた|クラウドテクノロジーブログ|ソフトバンク
https://www.softbank.jp/biz/blog/cloud-technology/articles/202412/ai-102/
-
https://udemy.benesse.co.jp/development/qualification/ai-102.html
- AI-102 Microsoft Azure AI Engineer Associate Exam
https://www.udemy.com/course/ai-102-microsoft-azure-ai-engineer-associate-exam/?couponCode=MT251203JP - AI-102: Azure AI Engineer:模擬試験問題集 | Udemy
https://www.udemy.com/course/ai-102-azure-ai-engineer/?couponCode=MT251203JP
- AI-102 Microsoft Azure AI Engineer Associate Exam
-
AI-102 Exam - Free Actual Q&As, Page 1 | ExamTopics
https://www.examtopics.com/exams/microsoft/ai-102/view/
Tags: .NET開発, 構成管理ツール, CI, BI/AI