しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Hack Azure! #11 - Semantic Kernel をハックしよう フォローアップ

久し振りに Hack Azure を開催しましたが、今回は少し毛色を変えて Semantic Kernel について話をしました。Azure とあまり関係なさそうに見えますが Semantic Kernel は Azure OpenAI はもちろん、それ以外の各種サービスと組み合わせての利用や、Semantic Kernel を使って実装したアプリケーションのホスティングに Azure Functions を使うことが多いはずなので、実際には関係大ありです。

今回のゲストは Microsoft の寺田さんです。ご存じの通り Java のエキスパートで、今回参加していただいたのは Microsoft Build Japan というオフラインイベントで、自分が寺田さんと Semantic Kernel についてかなり話し込んだのが切っ掛けでした。

AI MVP の横浜さんが Semantic Kernel の概要について解説し、寺田さんが Java 版の Semantic Kernel の開発状況や実際にデモを見せてくださいました。自分はシンプルに Semantic Kernel の C# 版を使って Azure Functions にデプロイする話を中心に行いました。

例によって毎回何とかフォローアップを書いているので、興味のある方は配信のアーカイブやツイートまとめと一緒に参照してみてください。

Twitter まとめと YouTube アーカイブ

イベント中に呟かれたハッシュタグ付きのツイートまとめと YouTube のアーカイブは既に公開していますので、リアルタイムでの参加が出来なかった方はこちらを見返して貰えればと思います。

Azure OpenAI を利用していますが、プロンプト周りには特に触れずに Semantic Kernel 中心に話をしています。配信でも話していますが、AOAI を使うこと自体は非常に簡単なので、それに食わせるデータを如何にして用意するかという方が重要です。

そもそも Semantic Kernel について

最初に横浜さんから Semantic Kernel の概要について話がありましたが、今の OpenAI を利用した開発では単純に Chat Completions API を 1 回叩くだけで済むものは少なく、Grounding や RAG といった文脈で外部のデータを知識として与えて、最適な回答を生成することが求められています。

必要に応じて複数のモデルを組み合わせることもありますので、そういったある意味ありきたりな部分を上手く処理してくれるのが Semantic Kernel となります。AI Orchestration と呼ばれることもあります。

Semantic Kernel は Connectors と Plugins によって機能を拡張できるようになっています。Plugins は以前は Skills と呼ばれていたものが名称変更されましたが、個人的には Skills の方が好きでした。

AI Orchestration と呼ばれる理由は Planner の存在が大きいです。Planner は入力された値から Plugins をどのような順序で呼び出すべきかを自動的に決定してくれるので、その通りに Plugins を呼び出すと求めている結果を得ることが出来ます。

Planner 自体も OpenAI を使って Plugins の呼び出し順序を決定しています。実際に OpenAI を利用したサービスを公開する際には、この Planner が生成したプランもログとして残しても面白いと思います。

Semantic Kernel の Java 版と言語ごとの機能差について

最初に Semantic Kernel がリリースされた時には C# 版と Python 版だけが用意されていましたが、最近では Alpha 版扱いになりますが追加で Java 版がリリースされました。Maven / Gradle でインストールできるので、これまで以上に既存アプリケーションに追加しやすくなったはずです。

最近の AI 関連は全て Python で書くみたいな風潮には個人的には疑問を持っていて、モデル構築や学習フェーズとは異なり LLM を使う際には REST API を叩くだけに過ぎないので、実運用アプリケーションで使われている言語で AI Orchestration は書けるべきだと考えています。特にパフォーマンスとスケーラビリティは今後重要になってくると思います。

そういった観点では Java や C# といったパフォーマンスの良い言語で書けるのが良いと思います。以下のブランチで Java 版が開発されていますが、同じように他の言語向けに開発される可能性もありそうです。

余談になりますが TypeScript 版は現時点では開発が止まっているようで、今は Node API for .NET という Interop レイヤーを使うことで Semantic Kernel の C# 版を Node.js から利用するサンプルが追加されつつあります。正直求めているものとは違うだろという感が凄いです。

配信中で寺田さんが Java 版が C# 版とほぼ同じ設計になっていると話していましたが、まずは動くものを用意するために C# 版からのポーティングに注力しているようです。Alpha 版とはいえ必要な機能はそれなりに揃ってきているように感じます。

ドキュメントも Java 版も徐々に増えてきているようなので今後に期待ですね。貢献も出来るようなので、Java に詳しい方は Pull Request を投げてみるのも良いかと思います。

Azure Functions を使って Semantic Kernel をホストする

実際に Azure OpenAI と Semantic Kernel を使って作成した機能を、どのように実際のアプリケーションに組み込んでいくかですが、素早いリリースが必要になる可能性が高いので完全に分離したリソースとして用意するのが良いと考えています。

そういったケースで簡単にリソースの作成と公開が行える Azure Functions は非常に有用でしょう。Semantic Kernel を使った API を大量に作る必要もないはずですし、イベントドリブンとの相性は良いと思っているので Azure Functions を使うのが現状ベストだと考えています。

配信でも話をしましたが、現状 Azure Functions で Semantic Kernel の C# 版を動かすためには Isolated を選択する必要があります。In-Process はちょいちょいアセンブリのバージョン問題が発生して、その度に Issue が上がっていますが Semantic Kernel の更新頻度がとても早いので素直に Isolated にするのが良いです。

Issue は上がっているので In-Process でも動くようになると思いますが、いたちごっこなので厳しいです。

少し前に Isolated 向けの ASP.NET Core Integration が GA になり、これを有効化すると Isolated でも ASP.NET Core 関連クラスが利用出来るので In-Process とほぼ同じ開発体験となります。

あまり関係ないですが、Azure Functions の Isolated について改善が色々と入ったので、検証して別途ブログにまとめようかと思っています。

Azure OpenAI や Semantic Kernel とどう向き合っていくべきか

後半で話しましたが Azure OpenAI が出てきた今でも、やることはあまり変わらないという印象です。GPT-4 が持っているデータだけで全て解決できるわけでは全然ないので、ちゃんとデータを活用できるような基盤づくりが重要となります。

そこまで構築出来て、やっと Grounding や RAG パターンが適用できるようになります。タイミングよく Azure OpenAI ワークショップが来週開催されるので、興味のある方は参加してみてください。

私も当日はメンターとして参加する予定なので、質問やディスカッションはいつでも歓迎しています。参加枠が残り僅かなので検討中の方はお急ぎください。