7.4K Views
November 23, 24
スライド概要
2024/11/23開催のFullstack AI Dev &Raycast Summit(https://devx.jp/mt202411)で登壇したセッションの資料
「AIエージェントは本当に人間の仕事を代替できるのか?」旅行領域における実践的なマルチエージェント開発の最前線をお話します。複数のAIエージェントを組み合わせ、どのように人間と協調させながらサービスを作り上げていくのか。その設計思想から実装の詳細、そして直面した課題まで。編集者AI、ライターAI、チェッカーAIなど、実際に稼働している記事生成システムにおける複数エージェントの連携や、現在進行形の旅行相談システムの開発から得られた学びもご紹介。
令和トラベル プロダクトマネージャーやってます。
AI旅行記事生成PJから学んだ マルチエージェントの本質と可能性 旅行スタートアップの生成AI開発ナレッジシェア 営業資料 20○○年○月○日 株式会社 令和トラベル MLラボリーダー 宮田 大督
自己紹介 みやっち / 宮田 大督 株式会社令和トラベル - NEWT MLラボ リーダー 前職 メルカリ、エクサウィザーズ、Gaudiy... スキル プロダクトマネジメント、UXデザイン、生成 趣味 AIエンジニア... サブカル、アニメ、特撮...
令和トラベル以前のAIプロジェクト エクサウィザーズでの介護士支援AI開発 介護士の記録や連絡を補助する単機能音声AI LLM以前のML的なシンプルな機能 十分実務にはこれで役立つ 引用 ハナスト https://hanasuto.carekarte.jp/ GaudiyでのSNS自動返信ボット開発 アイドルイベントSNSでのバーチャルアイドルボットの実装 キャラ設定を持ち、参加者の発言に自律的に返信。やりとりを記憶し投稿に反映する。 エンタメ要素として盛り上がる 引用 Generative Agents論文を参考にした長期記憶機構をもつLLMエージェント×非同期コミュニケーションの実装 https://techblog.gaudiy.com/entry/2023/09/20/091704
Generative Agents論文: 25体のマルチエージェントを使った 仮想環境のシミュレーションで集団行動が発生 マルチエージェントの面白さ 各エージェントは異なる個性と目的を持ち、現実世界のような日常生活を再現 します。その結果、特に事前に設定したわけではないのに、各エージェント同 士のコミュニケーションが生まれ、誕生日会や村長選挙などが発生。 めちゃくちゃ面白いが実務でどう活用するか? シミュレーションゲームのような面白さ。ここからエンタメコンテンツとして はいくらでも想像できるが、現実的に業務に活用できるイメージはわかなかっ た。 引用 【”Generative Agents”】スタンフォード大学のAI研究をまとめてみた×非同期コミュニケーションの実装 https://gomezblog.com/generative-agents-by-stanford-research/
エージェントってなんかやくにたつ? エージェントの定義 自律性(not 応答性) 人間の確認なしで自律的に 動作 独自の判断で行動を選択 目標思考(not 汎用性) 自ら特定のゴールを認識 戦略的に行動を計画 初期の懸念点 1.エンタメとしてはいいが業務アプリケーションでの実用性? 2.高度な自律性もたなくても単機能AIでも十分役立つのでは? 3.もしくはChatGPTのような汎用AIでもいいのでは?
令和トラベルでのAIプロジェクトの一例 旅行記事生成システムの開発 施策概要 観光地・ホテルの魅力など旅行情報を自動で記事化 メジャー・マイナー問わない多用な記事生成の実現 人間のエディターと連携し品質を確保 主な成果 安心安全なカスタマーの旅行計画のお手伝い 効率的なコンテンツ生成速度向上 Webサイトへの流入増加
どんな感じでやっていったのか 初期アプローチ ChatGPT Difyの活用 単純な長文プロンプト 品質がでない・どこを直し たらどう変わるか予測つか ない 記事生成サンプルを参考 に、ワークフロー設計 2段階プロセスでクオリティ アップ
Difyワークフロー 2段階構成のメリット ワークフローの2段階構成 Step1 記事構成の 設計をするブロック Step2 構成にもとづき 実際に執筆するブロック まずは運用面が楽だった。一発プロンプトはどこをどうかえたらいいかがさっぱりわからない。構成まで がおかしいのか、その後記事生成がおかしいのか、区別がつきやすい
他にもメリットが! クオリティの向上 一発生成より明らかに高品質・高生産性 人の介入を最小限に 最初に1度人間がこういう記事を 書きたいとお願いする チャットのように何度もやり取り せずともよい CoTによるクオリティUP 記事生成というゴールに対し、良 い構成を考えるという戦略を検討 これが自然とCoT(思考連鎖)に なり、クオリティ向上が実現
これはエージェントの定義と一致してるのかも? 人の介入を最小限に 最初に1度人間がこういう記事を 書きたいとお願いする チャットのように 何度もやり取りせずともよい 自律性 人間の確認なしで自律的に動作 独自の判断で行動を選択 CoTによるクオリティUP 記事生成というゴールに対し、 良い構成を考えるという戦略を検討 これが自然とCoT(思考連鎖)になり、 クオリティ向上が実現 目標思考 自ら特定のゴールを認識 戦略的に行動を計画 エージェントとは目的ではなく、クオリティ向上の結果そうなっているものだった
実装例:旅行記事システム Step1. 企画 Step2.構成作成 Step3. XML分解 Step4. 段落執筆 人間 XML形式での要件定義書を作 成 LLM Step1のXMLを効率よく理解 し戦略を考え記事構成をXML で出力 プログラム ちょうどいいサイズの複数の XMLに分解し出力 Step5. 全体マージ Step6.記事チェック Step7.最終確認 LLM Step2で生成された記事構成 XMLで全体像を把握しつつ、 3で生成された段落ごとの小 XMLを元に具体的な表現方 法・制約条件を理解し、イテ レーションで段落ごとに HTML形式で出力 プログラム Step4 で う ま れ た 複 数 の HTMLをつなぎあわせ出力 LLM Step5で生成された記事にフ ァクトチェック。点数・ファ クトチェックの方法を明記し たマークダウンを出力 人間 Step6で生成されたファクト チェックの方法に従って実際 にチェックをし必要があれば 修正をする
改善の中の気づき、これマルチエージェント? 専門化された機能ブロックの追加 調査系ブロック チェック系ブロック 書きたいテーマに必要な情 報を収集してくるステップ 最適な検索クエリ生成し、 そのクエリで検索エンジン で調査。内容をまとめる 生成された記事に対し、ク オリティやファクトが怪し い箇所を抽出 点数付けし、その検証方法 もアウトプットし、その手 段に従って最後は人間が確 認 もはや、各ブロックはステップではなく、一つ一つがエージェント 全体はマルチエージェントシステムといえるのでは?
マルチエージェントが必要な理由 個別エージェントの直接利用の 課題 マルチエージェントの利点 人間による複数エージェント管理は非 効率 人間はゲートウェイとなるエージェン トにお願いするだけ かといって汎用AIはやっぱりエージェ ントに比べて性能が落ちる ゲートウェイエージェントが自動振り 分けし、複数の専門エージェントを効 率的に活用 マルチエージェントも目的ではなく クオリティ向上の結果そうなっているものだった
実装例:旅行記事システム Step1. 企画 Step2.構成作成 Step3. XML分解 Step4. 段落執筆 人間 XML形式での要件定義書を作 成 LLM Step1のXMLを効率よく理解 し戦略を考え記事構成をXML で出力 プログラム ちょうどいいサイズの複数の XMLに分解し出力 Step5. 全体マージ Step6.記事チェック Step7.最終確認 LLM Step2で生成された記事構成 XMLで全体像を把握しつつ、 3で生成された段落ごとの小 XMLを元に具体的な表現方 法・制約条件を理解し、イテ レーションで段落ごとに HTML形式で出力 プログラム Step4 で う ま れ た 複 数 の HTMLをつなぎあわせ出力 LLM Step5で生成された記事にフ ァクトチェック。点数・ファ クトチェックの方法を明記し たマークダウンを出力 人間 Step6で生成されたファクト チェックの方法に従って実際 にチェックをし必要があれば 修正をする
XMLはある種の要件定義書(企画書) 要件定義プログラミング的な考え方になってた(結果的に) 段落定義書 構成仕様書 段落ごとに種別IDを振り、ライターへの指 示・段落内の構成・注意事項などを記述 段落定義書で定義された段落を、実際に記事 としてどう組み合わせるかの方針
構造化された文章が重要 XML/YAML形式などの構造化ドキュメントが 「3方良し」 Good 01 Good 02 Good 03 人間の読みやすさ/書きや すさ LLMでのクオリティ向上 プログラムでの解読の容易 さ(ここがポイント)
エージェントはLLMだけではない。 人間もプログラムもLLMもエージェント? 人間エージェント 責任が必要なタスク (ファクトチェック) プログラムエージェント 定型的で複雑なタスク (複雑な計算処理) LLMエージェント 柔軟なタスク (記事の構成の検討) 発想力が必要なタスク (初期アイデアの提供) 確実な処理が 求められるタスク (予約や購入などの サービスAPIの実行) ある程度のミスが 許容されるタスク (人間に表示する文章作成) これらをつなぎ合わせてマルチエージェントのシステムができると考えていいのでは
なぜ構造化された文書がマルチエージェントに必要か 「目標思考」をもった高速で「自律的」システムに なってなければエージェントシステムではない シームレスかつ高速なエージェント間の連携の必要性 人間→LLM :長い文章は理解を間違える 人間→プログラム :自然言語は理解不能 エージェント間の 「共通言語」が必要 プログラム/LLM→人間:出力は可読性大事
実装例:旅行記事システム Step1. 企画 Step2.構成作成 Step3. XML分解 Step4. 段落執筆 人間エージェント XML形式での要件定義書を作 成 LLMエージェント Step1のXMLを効率よく理解 し戦略を考え記事構成をXML で出力 プログラムエージェント ちょうどいいサイズの複数の XMLに分解し出力 Step5. 全体マージ Step6.記事チェック Step7.最終確認 LLMエージェント Step2で生成された記事構成 XMLで全体像を把握しつつ、 3で生成された段落ごとの小 XMLを元に具体的な表現方 法・制約条件を理解し、イテ レーションで段落ごとに HTML形式で出力 プログラムエージェント Step4 で う ま れ た 複 数 の HTMLをつなぎあわせ出力 LLMエージェント Step5で生成された記事にフ ァクトチェック。点数・ファ クトチェックの方法を明記し たマークダウンを出力 人間エージェント Step6で生成されたファクト チェックの方法に従って実際 にチェックをし必要があれば 修正をする
プロ向けはそれでいいがC向けはどうするの 自然言語から構造化された文書へのコンバートエージェントを用意 ユーザーに XMLかいても らうわけには いかない 自然言語をもと にXMLを出力さ せるコンバータ ーエージェント 社内でも、このシステムを業務委託メンバーにやってもらって るが、やっぱりXMLはハードルが高い。 書きたい記事の内容を自然言語である程度書いたら、良質な記 事になるように細かい指示まで含めたxml記事要求定義書を作成 それをもとにそのあと複数のエージェントたちが正確に指示を 理解 良質な記事を作っていく
旅行相談AIシステム これまでのマルチエージェントのナレッジを活用 お客さんの要望をヒアリングするエージェン ト、それを聞きながらおすすめのツアーを探 すエージェント、旅行情報を同時に検索する エージェント…
旅行相談でのマルチエージェントの工夫の必要性 直列ではない並列で非同期的なマルチエージェントを目指すことに? エージェントたちの連携が直列ではなく、逆流し たり、並行したり、協調しながら進む? 記事生成 記事生成のように、戦略・構成を作って、実行・執筆するという シンプルな話ではない 旅行相談 情報をヒアリングして、おすすめを探す、という順番だけじゃな く、逆流で、おすすめをさがしているうちに、もっとここを聞 いてほしいとヒアリングエージェントにお願いするかもしれな い
まとめ エージェント、マルチエージェントはエンタメのためのものでも、SFのもの でもなく、有効だからこそ結果的にそうなっている、というもの。 エージェントは、人間やプログラム、そしてこれからはきっと ロボットとか、ただの絵とか、そういうものもあわせた、シス テムのことを指すのが結果的にはよい そして、それらの唯一の重要性は、高速性。 そしてそのための媒介となる共通言語の工夫。