こんにちは、ふくちです。
2024年9月21日(土)、22日(日)に開催されたServerlessDays 2024 Tokyoへ参加してきたので、その学びや感想を書いていこうと思います。
本当は朝イチで聴きたいセッションがあったのですがド派手に寝坊したので途中から参加したものになります；；
サーバーレスと生成AIの現在
サーバーレスと相性の良い、生成AIを使う場面での話がいくつか聞くことができました。
そこで個人的に感じた、生成AIアプリケーション実装トレンドとしては、下記の3つです。
- LLMが生成した出力を、LLMで評価する
- RAG, エージェント, ファインチューニングなどユーザー側での工夫が必要
- 単一のLLMだけでアプリを構成するのではなく、マルチエージェントの利用が進んでいく
上記の要因としては、 「これまでのシンプルなユースケースだけではなく、複雑かつ高度なユースケースでの導入が進んでいるから」 だと個人的には感じました。
個人的な見解をまとめると下記のイメージです。
| ユースケース | 特徴 | 難易度 |
|---|---|---|
| 今までの生成AIアプリ (質問回答チャットボット等) |
・機能としてはシンプル ・AIから文章が生成されるだけ ・ハルシネーションはある程度許容 ・ユーザー側で内容の妥当性確認実施 |
易しい |
| これからの生成AIアプリ (GenUI、商品レコメンド等) |
・機能の多様化&複雑化 ・生成AIに仕事の一部を任せる ・ハルシネーションは許されなくなっていく ・出力内容の評価も生成AIが行う ・人間は更なる精度向上を求める ・生成AIを使いこなす技術力と知識が必要 ・AIがAIを使う時代へ |
超難しい |
このように移り変わっていくフェーズが来ている、と個人的には感じました。
ここからは、前述した3つのトレンドについて、1つずつ掘り下げていきます。
LLMが生成した出力を、LLMで評価する
例えば「オンライン薬局のLLMマルチエージェントを支えるLLM Ops」というセッションでは、患者さんとメッセージをやり取りする薬剤師さんに対して、返信のレコメンド文をLLMに出力させるという取り組みをされていました。
このサービスにおけるミッションは「漢方をお客様に販売すること」なので、虚偽・不正確な情報が入っていては困ります。
LLMが生成したメッセージを薬剤師さんがチェックしてから患者さんに送信されるとはいえ、薬剤師さんが一々「またこの情報間違ってるよ…修正しなきゃ…」となっていてはかなり負荷が高いですし、LLMを導入している意味がないですよね。
そこで、より良い回答を出力するために「LLMが生成した出力(回答)を、LLMで評価する」という仕組みを導入しているとお話しされていました。
これをLLM-as-a-Judgeと言います。
このLLM-as-a-Judgeを導入することでLLMからの回答を専門家レベルでレビューしたり、出力妥当性を数値化したりすることができるそうです。
非常に専門的な領域で、かつハルシネーションが許されない状況下での出力妥当性を向上させるためには必須となる取り組みである、と私は認識しました。
ただし、その妥当性評価が正しいものであるかどうかは、現状人の目に頼っているとのことでした。
また、このLLM-as-a-Judgeについては、Google CloudにおいてAPI化されているそうです。
Vertex AIという機械学習プラットフォームの機能として既にプレビュー版が実装されており、今後さらに必須の項目となっていくのではないか、と考えています。
LLM-as-a-Judgeに関しては、下記も参考になりそうです。自分で試してみたいときには非常に参考になるのではないでしょうか！
LLM-as-a-Judgeまとめ
・商品販売に関わる重要なシーンでも生成AIが活用されてきている
・LLMの評価は、LLMが行う！
・その評価が適切かどうかはまだ人の判断が必要！
RAG, エージェント, ファインチューニングなどユーザー側での工夫が必要
「生成 AI による新しい UI/UX 〜サーバーレスで実現する Generative UI の世界」というセッションにおいて、生成AIによるコード生成の可能性についてお話しされていました。
Generative UI(以後GenUI)のイメージとしては、ClaudeのArtifacts機能や、v0のように、生成AIがフロントエンドの画面イメージ図を作成してくれる、というようなものになります。
このセッションの中で話されていたのは、「RAGとエージェントを使えば、開発者体験は大きく向上する可能性を秘めている」ということでした。
例えば、RAGを用いて既存のコードやデザインシステムを参照した上でソースコードを生成することで、デザインに一貫性のあるUIを生成することができます。
これは言うなれば「ソースコードRAG」というもので、新規サービスの叩き台作成にはもちろん、コードのリファクタリングにも使える可能性があります。
また、開発を自律的に行う生成AI(エージェント)を用いることもできます。
これまでのGenUIでは基本的に1ファイルのみを画面上で生成するような機能でした。
しかし、ClaudeのTool Use(Function Calling)などを用いることで、複数ファイルを生成したりOS操作を可能にしたりできます。実際にディレクトリやファイルの作成まで、生成AIが実施してくれるというようなことが実装できます。
このようなエージェントを作成することで、ユーザーからの入力に応じて、その目的に最も適した機能が何か生成AIが判断し、最終的には実装まで行ってくれる、ということが実現できます。
また、先ほどの「オンライン薬局のLLMマルチエージェントを支えるLLM Ops」セッションにおいては、ファインチューニングで精度向上・コスト削減を実現していました。
1つの質問に対して、LLMによって生成された回答と、人間が考える理想の回答をデータとして持っておき、そのデータを用いてファインチューニングすることでどんどんと理想の回答を生成してくれるようにアップデートしているようです。
これによって、チューニングされていないGPT-4oよりも、チューニングされたGPT-4o-miniの方が回答精度が向上したそうです。
RAG、エージェント、ファインチューニングのまとめ
・以上のように、最早人間からの要望は、単なるチャットサービスとしての生成AI領域を超えてきつつあります。
・より高度な仕事をさせるためには、生成AIに機能を追加し、できることを増やしていく必要があります。
・そして、そのための実装は人間が行う必要があります。
・より一層、生成AIを使いこなす能力が求められていきそうですね！
単一のLLMだけでアプリを構成するのではなく、マルチエージェントの利用が進んでいく
生成AIに求める要素が多様化・複雑化してきているということはこれまでの話でなんとなく実感いただけたかなと思います。
そのようにして、より複雑なタスクを生成AIに求める場合、単一のLLMを使用するだけでは実現できないことがあります。
そこで重要になってくるのが「マルチエージェント」と「フローエンジニアリング」です。
「LLMマルチエージェントのフローエンジニアリングを支えるLLM Ops」のセッションにおいて、この両方が採用されており、私が執筆当時参加していたANGEL Dojoというハッカソンでも(たまたま)同じようなことをしていました。私たちの実装はセッションのレベルには到底及びませんが、考え方が同じだったという感じです。
これまでの生成AIアプリは単一のプロンプトで構成され、一問一答形式で成り立つような形のものが多かったです。
しかしこれからは複数のプロンプトを組み合わせ、ユーザーからの複数の回答を踏まえて答えを導き出したり、多角的な角度から意見を出したり、目的別にさまざまな情報を取得して分析したり、ということが求められるのではないかと考えています。
「マルチエージェント」と「フローエンジニアリング」を組み合わせることによるメリット・デメリットが以下のようになります。
- メリット
- 1エージェント1プロンプトとして小さなタスクを割り当てるので、プロンプトの肥大化を抑えられる(保守性の向上)
- 1つ1つのエージェントにおける役割が明確なので、回答が安定する(パフォーマンスの安定)
- 顧客側は自由に質問でき、柔軟なレスポンスを受け取ることができる(UX改善)
- デメリット
- 最終的な出力までに複数の処理が行われるので、処理全体のレスポンスが遅くなる
- 複数のLLMが動くため、コストが嵩む
複数のLLMが動くことで複雑なタスクをこなせるようになります。これはLLMがLLMに指示するようなこともあり、非常に面白いものになることが考えられます。
その一方で、コスト増加やレスポンスの遅さが課題として挙げられます。ここのトレードオフは避けられない、難しいものであるように感じています…
これらを踏まえて、具体的なユースケースとしては以下のようなものが考えられるでしょうか。
- より高度なカスタマーサポート用チャットボット
- 旅行計画作成から予約まで実施するシステム
- パーソナライズされたスケジュール管理アプリ
私の残念な発想力ではこの程度のものしか出てきませんでしたが…それでも、今までより複雑なタスクを任せられるようになると考えています。もっと面白そうな、イノベーティブなアイデアが浮かんで欲しいものです…
なんにせよ、これまでよりも複雑なタスクをこなせる生成AIアプリケーションがこれからたくさん世に出てくるのではないでしょうか！
・以上のように、これからは複数LLMを組み合わせて回答を生成させるようなシステムがどんどん開発されていく！？
・プロンプトエンジニアリングだけでなく、ソフトウェア開発の知識も大いに必要になる！
最後に
普段サーバーレスのサービスも生成AIのサービスもあまり使用しないので、たくさんのことを学べる非常に良い機会でした！
今回はその中でも最も印象に残った生成AIアプリ周りの話でしたが、それ以外でも興味深いセッションがたくさんありました！
それらについてもまた記事を作成できればと思います！
読んでいただきありがとうございました！
本記事で参照した資料はこちら！
登壇者の皆様、素晴らしい発表をありがとうございました！
当日の登壇を見られなかった方はぜひ資料をご覧ください！