Azure Open AI におけるインフラエンジニアの役割

最近はAzure Open AI関連のプロジェクトが多い。
私はインフラエンジニア目線で感じていることを記す。

まず、Open AIを利用するにあたり利用申請が必要である。
Microsoftにフォームを送って、１，２週間で認可が下りるプロセスだ。

次に、リソースを作る。
これはどのようなアプリケーションを作るのかによるし、規模にもよるが、私が担当しているのは、AIに事前の特定の資料の情報を渡し、例えば会社の製品のマニュアルとか、会社の規定とか社則とか何百ページにもなるものをを何百部分とかを読み込んでもらい、それについて回答をもらうシステム。これを機械学習ではなく、生成AIでやってもらうのである。マニュアルのアップデートや追加などに容易に対応できるためだ。

今回のデモレベルのものだが、このようなリソースになった。

Azure Open AIを利用し、App ServiceでAppを起動しChatをする

今や、サーバー立てて、アプリインストールして、Networkを設定して、ストレージ設定して、、なんていうプロセスは一切ない。

サーバーの代わりに、App Serviceを利用し、アプリケーションをPushし、Ready to Go。である。バックアップもできるし、なんならスケーリングもしてくれる。
Networkの設定もない。VNetすらいらない。
デプロイすれば基本このリソース内のサービスにならそのままつながってしまう設定にDefaultでなっている。
App ServiceにPublicからのアクセスもDefaultでできる。DefaultではAzureのオリジナルドメインだが、カスタムDomainも利用できる。

この案件ではレポジトリはGitHubを利用している。Azure Dev Opsを利用してもよい。Azureの方が親和性が高いと思う。

Langfuseなるものがあるが、これは生成AIのRAGを構築する上で、生成AIがなぜその解答にたどり着いたのかを可視化してくれる便利なものである。
通常、生成AIがどうしてその解答にたどり着いたのか見えないものだが、ちゃんとベクトル化されている数値まで見えるようで、何かヘンテコな回答をしても、ログを終えるってこと。
私は使っていないが開発エンジニアが使っているのを横目で見ているだけなので、正しくはないかも。あくまでインフラ目線。

BlobはPDFやHTMLなどのマニュアルをストアするために利用する。
ストレージはRAG内の過去の学習内容ややり取りの内容を一次記憶しておくもの。
Email communication Serviceはメールを飛ばし、ログイン画面で認証するもの。

もちろん、エンタプライズレベルだったり、セキュリティをちゃんとやれ。とか言われたらこのじゃダメだけど。一旦使えればいいし、社内のクローズドの環境で使いたいとかなら、こんなんでもいいとは思うけどね。

最近のクラウドサービスはPaaSやSaaSがしっかり整備されてきて、インフラエンジニアの出番が少なくなってきてる気がする…。でも、これも時代の流れだし、逆にクラウドの進化を楽しむのもアリかなと思う。