米OpenAIが2022年に発表した音声テキスト変換AI「Whisper」に、文章の一部または全部を捏造してしまういわゆる「幻覚」による重大な欠陥があると、米Associated Pressは10月26日（現地時間）、多数のエンジニアや研究者へのインタビューに基づいて報じた。
⇧何と言うか、「幻覚（ハルシネーション）」の問題については、現状のモデルの仕組み上、全てのAIに当てはまってしまうと思うんだが...
Azure Key VaultのREST APIのエラーの詳細は、ログを有効にしていないと確認できない罠
前に、
⇧ 上記の記事で、「Azure Key Vault」の用意している「REST API」を利用するために必要な情報を確認していて、オンプレミス環境から「Azure Key Vault」の用意している「REST API」を利用する場合は、
- Azure側
- オンプレミス環境側
※1 勿論、各プログラミング言語向けの「Azure SDK」を利用するのでも構わない。
※2「Azure Key Vault」のREST APIを利用するため「認証」用に必要。「サービスプリンシパル」の情報を「認証」用のリクエスト（HTTP POST）のボディ部に含める。
というような手順になりましたと。
で、「アクセストークン」が取得できたから、「Azure Key Vault」の用意している「REST API」を利用できるなぁ、と思っていたら、まさかの「403」エラー。
ちなみに、エラーになった「REST API」は、
⇧ になるのだけど、
⇧ とあったので、「エラー応答」を確認すれば解決方法が分かるのね、と思っていたら、全くの役立たずな情報であったわけです...
で、Microsoftの公式のドキュメントによると、
⇧ まさかの、別途、Azure側で「ログ」を確認できる手順を実施しないとエラーの原因が分からないという...
「REST API」の「エラー応答」が存在する意味が無いのだが...
ドキュメントによると、
- ID のアクセス ポリシーがない。
- 要求しているリソースの IP アドレスが、キー コンテナーのファイアウォール設定で承認されていない。
の2択らしいのだけど、原因の解決方法のページの参照先を載せてくれていないのが意味不明過ぎる...
2024年10月29日（火）追記：↓ ここから
まさかの、Azure Virtual MachineにSquidをインストールしていたことによる、通信の許可がされていないことによる、403でした。
⇧ 上記サイト様にありますように、Azure Virtual MachineにSquidがインストールされていた環境だったらしい。
流石に、自分の構築したサーバーではないので、どういう環境なのか把握できていなかったけども、Azure Key Vaultの公式のドキュメントの役に立たなさが際立ってしまった...
2024年10月29日（火）追記：↑ ここまで
ベストプラクティスとは言うが、代替案が無いだけの消去法になっている気がするが...
公式のドキュメントによると、
⇧ とあり、
- ログを記録する
- アラートを設定する
の2つが対応方法として上げられている。
そもそも、クラウド側で保管して欲しくないような気がするんだけど...
Azure Key VaultのREST APIのログ管理の構築が煩わしいし、追加コストもかかる話
とりあえず、公式のドキュメントの情報を整理すると、
| No | 対応方法 | 必要なAzureリソース | |
|---|---|---|---|
| カテゴリー | リソース | ||
| 1 | ログを記録する | ストレージサービス | Azure Storage アカウント |
| ストレージサービス | Azure Blob Storage | ||
| 2 | 監視ソリューション | Log Analytics ワークスペース （Azure Monitor） |
|
| 3 | アラートを設定する | 監視ソリューション | Azure Monitor |
⇧ 追加の「リソース」が必要になってきますと。
「ログを記録する」でログの保管場所を「Azure Blob Storage」とした場合、「Azure Storage アカウント」の作成が必須なのだが、「Azure Key Vault」用のREST APIの「ログ」を確認するのに、
⇧ わざわざダウンロードしないと確認することができないらしいのが辛過ぎるのですが、
⇧ プランによっては、ダウンロードの度にコストがかかりますと。
「アラートを設定する」の場合は、
⇧ ログの量によっては、かなりコストがかかりそう...
仮に、
talk-serverのリクエストログの量を例に挙げますと、ログのレコード数が1日当たり200億レコード、サイズにすると1日当たり9テラバイト、ピーク時のスループットが1秒当たり40万レコードです。本プロジェクトでは、大規模なログを抱える基幹サービスの開発者に向けてログの分析環境をインフラとして提供します。LINEサーバー開発者が、管理コストをかけずに大容量ログの分析をできるようにすることが1つの目標となります。
⇧上記のようなシステムのログの量で「Azure Monitor」の「Analytics ログ」を利用した場合、一瞬で破産しそう...
まぁ、何が言いたいかと言うと、「Azure Key Vault」の「REST API」で「エラー応答」を返すんであれば、「エラー応答」に使い物になる情報を持たせて欲しいし、ドキュメントで「原因」を載せてくれるのであれば、「原因」を解消するための「解決方法」について記載されたページの参照先のリンクを載せて欲しいということですな。
要するに「ファインダビリティ」が低過ぎるんだわ...
というか、逆に何故、ここまで適当な感じのドキュメントになってしまうのかが謎なんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
