マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望

最近登壇で使っていたLLM関連技術の今後について触れた50ページほどの資料を公開します。
(予測や展望は個人の見解を多分に含む点をご容赦ください。)

細かい技術説明というよりみんな気になるAgent、LLMOps周りの実際に立ち向かって死にかけた経験を赤裸々に書いた感じです。取り組む前にこの屍をよく見て反面教師にしてください。

1. 1 3つの技術トレンドで理解する生成AIの今後の展望 マルチモーダル / AI Agent / LLMOps ※ この資料は、技術トレンドを元にした個人的な予測が含まれます。あらかじめご承知おきください。 Hirosato Gamo (Microsoft Cloud Solution Architect)
2. 2 @hiro_gamo 大手SIerにてキャリアをスタート。エンタープライズブロックチェーンを活用した異業種間データ流 通プラットフォームの立ち上げなど新規技術を担当。数年間、社会インフラ関連企業を対象にし たデータサイエンティストとしての活動を経て、現在は ➢ MicrosoftのAIアーキテクトとしてAzure OpenAIを通じた LLM企業導入の技術支援を推進。 ➢ Microsoft Evangelist。著書に「Azure OpenAI Serviceではじめる ChatGPT/LLMシステム構築入門」。SpeakerDeckで「ChatGPT - Azure OpenAI 大全」などの資料が「2023 Most Viewed Deck 25」にランクイン。 ➢ 上智大学大学院 応用データサイエンス学位プログラム 非常勤講師 HIROSATO GAMO Microsoft Japan Co., Ltd. Cloud Solution Architect (Data & AI) About me 2023 - Most Viewed Decks (speakerdeck.com)
3. 3 直近で予想される AI 活用の3つの技術ブレークスルー 既にOpenAIの動きが見えてきている中、3つの大きなモメンタムに伴い新技術の台頭が見込まれる LLMはテキストベースが主流の状態から脱却 ➢ 登場から1年経過し成熟化しつつあるVisionモダリティの本格的な応用が発生 ➢ Speechモダリティが近く発表され、音声対話による新たなUIの検討が開始 ➢ モダリティ拡大に伴うプロンプティングやアプリケーション制御が複雑化 AIは稼働した後の改善サイクル(LLMOps)を回し成長させることが真骨頂 ➢ LLM挙動の監視・評価・改善パイプライン開発が発生 ➢ ユーザ挙動をデータ分析する Post Analytics が必要に ➢ 周辺の補助MLのサイクル管理(MLOps)、RAGのメンテナンス(RAGOps) 自律的に問題解決する 領域特化型AI Agent が求められる ➢ エージェント同士の協調を加味したパイプライン設計 ➢ 情報検索における複雑性が増し Advanced RAG, Graph RAG などが注目 ➢ 特化型のSLMの活用が加速し Fine tuning などの技術が再加熱 マルチモーダルの実用化 汎用リアクティブAIから プロアクティブな領域特化AIへ AIのプロダクションフェーズへの移行 主となる生成AIモメンタム 新技術テーマの台頭
4. 4 マルチモーダル/クロスモダリティの発展
5. 5 LLM のクロスモダリティ (マルチモーダル) への拡張 生成AIの今後の発展として、TextだけでなくVisionやVoiceなど形式の違うデータからの入出力が見込まれ、 既に開発が進んでいる。 マルチモーダルAI Vision Voice Text Vision Voice Text 出力を選択的あるいは 複数出力
6. 6 GPT-4 with Visionによる画像・テキストのマルチモーダル処理 GPT-4Vでは画像とテキストを入力として、テキスト生成が可能。 マニュアル解説や現場作業でのコーチング、自動運転への活用など様々な応用が見込まれる。
7. 7 動画生成・変換マルチモーダル AI Sora の登場 OpenAIが2024年2月に発表した動画生成AI「Sora」では、今まで難しいとされていたテキストから動画の生成、 動画+テキストから動画の生成を可能にしたことで大きな話題を呼んだ。 Soraで作成した動画はこちら: first impressions (openai.com) OpenAI sora technical report まとめと感想 (zenn.dev)
8. 8 GPT-4o Speech to Speech Voiceモデルの登場により、音声変換モデルを挟まずリアルタイムかつ解釈性の高いモデルが実現。 AIと対話によるコミュニケーションが活発化することが予想される。 https://youtu.be/KwNUJ69RbwY?feature=shared https://youtu.be/D9byh4MAsUQ?feature=shared&t=45
9. 9 Speech to Speech の利点 LLM Voice Text 視覚・聴覚・文字情報 を同時に加味できる Text Voice MMM Voice Text Vision Voice Text Vision テ キ ス ト モ デ ル マ ル チ モ ー ダ ル Voiceモデルの登場により、音声変換モデルを挟まずリアルタイムかつ解釈性の高いモデルが実現。 AIと対話によるコミュニケーションが活発化することが予想される。 1つ処理が増えることでレスポンスが劣化 モダリティ変換時に 感情や間の情報などが欠落
10. 10 長きに渡り君臨した「テキスト入力UI」を覆すサービスの登場を、世界は待っている スマートフォンやパソコンを使いテキスト入力が常に求められる生活さえも、 AIはいずれ根本から変えてしまうかもしれない。 従来のサービス ユーザ ユーザはテキスト入力を前提に OS・デバイス・アプリが設計されている。 アプリ デバイス OS テキスト 入力 ※個人的な予測を含みますので参考程度に
11. 11 長きに渡り君臨した「テキスト入力UI」を覆すサービスの登場を、世界は待っている スマートフォンやパソコンを使いテキスト入力が常に求められる生活さえも、 AIはいずれ根本から変えてしまうかもしれない。 従来のサービス AI機能追加 ユーザ ユーザはテキスト入力を前提に OS・デバイス・アプリが設計されている。 テキスト入力を前提に補助的に OSやアプリへAIを導入。 (かなり便利だがテキスト入力はやや大変) アプリ デバイス OS ユーザ アプリ+AI デバイス OS GPT テキスト 入力 テキスト 入力 ※個人的な予測を含みますので参考程度に
12. 12 AI前提UI デバイス・OS 長きに渡り君臨した「テキスト入力UI」を覆すサービスの登場を、世界は待っている スマートフォンやパソコンを使いテキスト入力が常に求められる生活さえも、 AIはいずれ根本から変えてしまうかもしれない。 従来のサービス AI機能追加 AGI ネイティブ UX ユーザ ユーザはテキスト入力を前提に OS・デバイス・アプリが設計されている。 テキスト入力を前提に補助的に OSやアプリへAIを導入。 (かなり便利だがテキスト入力はやや大変) 人間とデバイスを繋ぐメインUIが AIへのマルチモーダル入力に置き換わる前提で アプリのアーキテクチャが再構築。より自然に、 手を動かさずデバイスと対話可能な世界へ。 アプリ デバイス OS ユーザ アプリ+AI デバイス OS GPT ユーザ AIネイティブ アプリ GPT テキスト 入力 テキスト 入力 Vision Text Voice ※個人的な予測を含みますので参考程度に
13. 13 AI Agent
14. 14 企業における生成AI活用のトレンド 生成AI元年からの社内チャットボットから脱却し、特定用途にフィットさせるAI活用が拡大傾向に。 Mode 1 汎用的なAI Mode 2 特化型AIの拡大 社内チャットボット 特定業務の代替 サービス、製品への組み込み ➢ 用途がユーザ依存なチャットシステム ➢ MS CopilotやChatGPTなどと同等 ➢ 社内ドキュメントへRAGなどを 構成しているが多くはROIが不透明 ➢ ある特定業務の問題を解決するAI ➢ 特化型であるためAOAIのようなカスタマイズ性を持ったAIでなければ実現不可 ➢ AIに任される裁量や複雑性が高く、綿密に設計されたRAGや大規模なトークン消費が発生 AI Call Center システム開発AI支援 社内プロセスAI支援 AIナビ・自動運転応用 AI学習支援サービス 目視検査AI支援
15. 15 汎用・リアクティブから特化型・自律AIが求められつつある理由 能力格差を埋めてくれるはずのLLMだが、現状は普及までにハードルがあり知識層しか使えていない。 自分からは動かない、いわゆる「指示待ち」 ➢ 指示を送る行為は、逆に言えば指示が作れる人にしかできない Capabilityの不明瞭さ ➢ 何ができるか分からない状態で指示が出せない How to の敷居の高さ ➢ AIに対してどのように指示すべきか理解、入力が苦でなく文章能力の高い人のみ使える より用途を明確にし、表現力や知識の多寡に左右されない業務効率化が課題
16. 16 AI Agent とは 定義が曖昧だが、下記のような特徴を持つAIシステムをAIエージェントと呼ぶことが多い。 [2408.02479] From LLMs to LLM-based Agents for Software Engineering: A Survey of Current, Challenges and Future (arxiv.org) 特 徴 ① 特 徴 ② 特 徴 ③ 普通のAIチャットサービスは、ユーザーの指示に基づいて動作するのに対し、 AIエージェントは、与えられた目標に基づいて独立して行動し、 ユーザーの介入を最小限に抑える。 普通のAIチャットサービスは、シンプルな一問一答に限定されることが多い。 AIエージェントは、複雑で連続した対話の中からタスクを処理する能力を持つ。 必要に応じて複数のAgentを用意して協調し問題を解決することもある。 普通のAIチャットサービスは、ユーザーの質問に答えることに主眼を置いているのに対し、 AIエージェントは、特定の目標やタスクの達成に向けて計画を立てて行動する。 自律性 目標指向 高度な推論 特 徴 ④ チャットサービスはシステム実行など外部ツールとの連携は最小限であることが多いが、 AI Agentはタスク実行を自律的に実行する必要があるため外部連携が活発となる。 外部連携
17. 17 AI Agent によくある疑問や勘違い Agentの定義が曖昧な割に、バズワード化してる側面があることに注意してください。 AI Agent自体を目的にすることはありません。特定用途の達成のために構築されたAIシステ ムであり、あくまで目的ドリブンになります。Agentとは目的達成を目指したAIシステムの結果 として開発されるものくらいに考えた方が良いかと思います。 AI Agentかそうでないかによって、大きくクラウドのアーキテクチャが変化することはありません。 強いて言えばAIのパイプラインやその評価が複雑になるため、 そのフレームワークなどの補助ツールを活用するケースがあります。 Agentに明確な境界線はありません。自律性や目標指向などの性質は定義されていますが、 その度合いは用途によってさまざまであり、そのAgentらしさにもグラデーションがあります。 この「Agentらしさ」を「Agentic」と呼ぶケースもあります。 どこまでやれば AI Agent なの？ AI Agent を作りたい AI Agent のクラウドアーキテクチャは？ Answer Answer Answer
18. 18 簡易なAIエージェントの例 文章作成エージェントです。 どんな文章を書きたいですか？ 論文 ブログ レポート 英文メール
19. 19 簡易なAIエージェントの例 文章作成エージェントです。 どんな文章を書きたいですか？ 論文 ブログ レポート 英文メール
20. 20 簡易なAIエージェントの例 文章作成エージェントです。 どんな文章を書きたいですか？ 論文 ブログ レポート 英文メール 論文ですね。 論文の構成は一般的に～～～～ 一緒に組み立てていきましょう。 あなたの研究内容を簡単に教えてください。
21. 21 簡易なAIエージェントの例 文章作成エージェントです。 どんな文章を書きたいですか？ 大規模言語モデルのシステムプロンプトの追従性に 関する研究をしています。一般的にLLMは～～な んですが、なぜ～～できないのかが分かってません。 ～～～～～～ 論文 ブログ レポート 英文メール 論文ですね。 論文の構成は一般的に～～～～ 一緒に組み立てていきましょう。 あなたの研究内容を簡単に教えてください。
22. 22 簡易なAIエージェントの例 なるほど分かりました。背景について調査し、ベースと なる論文を生成しますので少々お待ちください。 検索中…
23. 23 簡易なAIエージェントの例 なるほど分かりました。背景について調査し、ベースと なる論文を生成しますので少々お待ちください。 検索中… 論文のベースを作成しました。 まず概要から確認していきましょう。気になるところは ありますか？ Title XXXXXXXXXXXXXXXXXXX Abstract ~~~~~~~~~~~~~ ~~~~~~~~~~~~~ 1. 緒言 … … … … … … … … … … … … … … … … …
24. 24 簡易なAIエージェントの例 なるほど分かりました。背景について調査し、ベースと なる論文を生成しますので少々お待ちください。 検索中… 論文のベースを作成しました。 まず概要から確認していきましょう。気になるところは ありますか？ Title XXXXXXXXXXXXXXXXXXX Abstract ~~~~~~~~~~~~~ ~~~~~~~~~~~~~ 1. 緒言 … … … … … … … … … … … … … … … … … 大まかに内容は合ってますが、今回使用した実験 条件は少しユニークな手法を使っているので、それを 概要には組み込みたいですね。
25. 25 単純なAgentでも状態遷移が多く発生 目的文章選択 ヒアリング 調査・ベース生成 評価・修正 単純なエージェントとのやり取りに見えたが、これを実装するだけでも4つほど状態遷移が発生。 しかもシーンに応じて更にLLM処理が発生することも。汎用サービスより定めていくべきポイントが多くなることが分かる。 選択肢があらかじめ固定の場合は LLMである必要はない。従来型のUIでも十分。 ヒアリングをインタラクティブに実施。 必須項目を聞き取り終わるまでは次の状態に遷移しない。 テキスト入力だと面倒なので音声ベースも選択肢 RAGによる情報参照。 セクションごとにマルチにLLMを用意するなどの工夫も必要。 生成後の自己評価など時間を掛けながら完成度を高める。 ユーザ指摘の吸収。 出来た文章の直接編集などにも対応できるようなつくりに。
26. 26 AIエージェントのアーキテクチャ例 ベースとしては通常のLLMシステムと似たような構成になるが、エージェントが乱立するためPost Analyticsなど管理面を厚くする必要あり。 Lake Storage Azure OpenAI PTU Agent Pipeline RAG Data Application log , Prompt Store Post Analytics Azure AI Search Cosmos DB SQL DB Cosmos DB Orchestrator Azure Machine Learning LLMOps/MLOps Pipeline App Service ほか Github Actions ほか Azure Data Factory AI エンジニア Vision Text Voice 更新 Power BI
27. 27 特化型 AI Agent による開発方針の変遷 用途が明確化することで従来の汎用システムからは考え方が大きく変わる。 汎用 業務 特化 自由記述 UI ビジネスロジックに応じ あらゆる手段で必要情報を収集 LLMに任せほぼ無指示 プロンプト 目標達成に向けた 手順や進め方のガイドを指示 汎用大型モデル モデル 特定用途へのチューニング踏まえた SLMの併用 既存資料からの情報抽出 RAGデータ 業務用、AI用に準備 リアクティブ AIの挙動 プロアクティブ
28. 28 マルチエージェント構成 複雑な推論には複数のLLMが協調し合って解決を図ることも多い。 Assistant API、Autogen Studio や LangGraph など、エージェントを支援するためのフレームワークも登場している。 AutoGen Studio 2.0: Revolutionizing AI Agents (autogen-studio.com) LangGraph (langchain-ai.github.io)
29. 29 Agent設計のポイント① ～「サービス」としてきちんと設計しよう～ ITシステムなら当たり前のことではあるが、Agentでも事前にコンセプトをきちんと定めることが重要。 汎用チャットボットが流行ったからと言って、自由度を高めることがユーザのためになるとは限らない。 何を解決したいのか あくまで作業や業務特化であることを忘れず、何のためのツールなのかを意識する。 作りたいのはAIツールではなく問題解決ツールであることを忘れなければ、 ChatUIの呪いを解き、AIに丸投げするUI/UXから脱却していくことが可能。 ユーザは何秒待てるか ユーザを待たせる時間＝LLMが思考出来る時間となる。 多重推論を伴う複雑な生成が必要な場合もあり、サービスとしてどこを目指すか が後からブレると非常にストレスの大きいシステムが出来上がる。 LLMに何を任せるか 問題解決に必要な情報は何なのかを意識する。 情報収集の方法は自由記述だけではない、最も効率の良い情報取得方法を LLMに限らずあらゆる手段から検討することを心がける。 対象の作業範囲 対象作業の少しの拡大が、AI Agentにとっては非常に大きな開発工数(コスト)の インパクトになる。安易に広い問題解決を図る前に、出来るところから始める。
30. 30 Agent設計のポイント② ～マルチ化で発生するトレードオフを認識せよ～ 人間業務を代替する場合、業務量が大きい場合が多く、実装面の負荷は破綻に繋がるため注意 少ないAgentで回すパイプライン 細かくタスクを分けたパイプライン Agentごとのタスク量 = 大 遷移の複雑性 = 小 実装は単純だが精度が悪かったり、 レスポンスやコスト面でのロスが大きい Agentごとのタスク量 = 小 遷移の複雑性 = 大 各タスクでは優秀だが適切な遷移判断が 出来ないときがある。実装面も複雑で パイプライン設計が高負荷。
31. 31 Agent設計のポイント③ ～評価環境が本体以上に難しいことを認識しておく～ LLMOpsの章で詳しく解説するが、評価プラットフォームは本体と同レベルの重要度と工数を覚悟しておく必要がある。 基本挙動 基本挙動のチェック ➢ 動作に関わるルールや手順、制約事項が守られているかどうか ➢ Function Callingが呼ばれた際に、関数が実行出来ているか ➢ RAGが機能した際に取得コンテキストを基に回答が出来ているか ➢ メッセージ表示やSTTなどとの連携時に情報が欠落したり致命的な誤解釈などが無いか ➢ 問題解決割合 Tool精度 Function Calling ➢ 実行パラメータの抽出の精度 ➢ Functionを呼ぶFunctionの選択精度 ➢ その他Toolルールの遵守 RAG ➢ クエリ化精度 ➢ 検索精度 ➢ リランク精度 ➢ 最終回答の完成度 ほか 非機能面 会話の長さ(ターン数) ➢ どれくらいのターン数で問題が解決されたか Time To First Token (TTFT) ➢ 最初のトークンが出力されるまでの時間 Time Per Output Token (TPOT) ➢ トークン1つが出力されるごとに掛かる時間 各LLM Latency ➢ 各LLMでの TTFT + TPOT * (生成トークン数) スループット ➢ 多重実行時に掛かるトークン量 検索・DBアクセス時間 ➢ RAGが実行された際の検索速度やDBアクセス時間 セキュリティ jailbreakチェック ➢ 入力に関するメタプロンプトからの脱獄行為 故意の多量トークン ➢ LLMのDDoSのような過負荷を狙った機械的な実行
32. 32 そのほかAI Agent開発に向けた重要な要素① アーキテクチャ上表現できないさまざまな課題が存在する。 LLMアプリケーションはAgenticになるほどアプリケーションのUX設計が非常に重要に。 (一般ユーザが作り始めると簡素なチャット画面になりがち) UI/UX設計 複雑なエージェントシステムを構成する場合、どの粒度でエージェントを連携・分割するかなど、 Agentに精通した技術者の支援が必要。 エージェントパイプライン設計 Azure AI Searchなどの検索エンジン、オンライン対応が可能なベクトル検索エンジン、SharePoint、 通常のデータベースなどの最適なインフラ接続。 RAGデータソース 通常のアプリケーションの他、音声マルチモーダルを前提とした音声アプリケーションや 電話システムとの連携が実際に出てきている。 アプリケーション実行環境 Webサイト、PDFなど各種データソースからの情報抜き出しおよび抽出後のデータの加工・チャンクから ベクトル化しインデックス格納するまでの工程は継続改善の仕組みやノウハウが必須。 RAG情報抽出ジョブ ユーザ入力の監視はシステム運用上必須で、 その可視化のためのデータ移行や適切なBIはじめダッシュボードづくりが必要。 ログ可視化パイプライン ログからのアドホックな分析を実行する分析環境。データサイエンスの知見が必要となる。 ログ分析テンプレート
33. 33 そのほかAI Agent開発に向けた重要な要素② 特に評価面についてはどのプロジェクトでも必ず大きな障壁となる点に注意したい。 検索やDBアクセスなど汎用性の高い関数は精度の良い関数定義をテンプレ化することで マルチエージェントプロンプトの部分的な再利用に寄与。 関数定義テンプレート 構造化したプロンプトの再利用を目的として大規模マルチエージェントの開発時に用いられる。 多くの似たLLMを使い分ける場合に有用。 Prompt Store LLMの振る舞いに関する評価をするためのパイプライン整備およびノウハウ構築。 LLM評価パイプライン 評価にLLMを用いる場合、人間評価との乖離が発生する。 その精度向上、プロンプティング、およびファインチューニング技術など。 LLM as a Judge 調整テンプレート SLMを使用する際のコンピュートリソースの整備、エンドポイント構築の手順や簡易化など。 SLMデプロイ・ファインチューニング
34. 34 LLMの主な課題から見る Agent 実現に向けた壁 LLMには一定の未解決課題があり、特にシステムプロンプトで指示をしても自律性・探索性を持たせることが難しい。 Instructionへの忠実度 In Context Learningによって実現できるタスクの広さと、複雑な指示でもそれを厳密に守る柔軟性が求められる。現行モデ ルもSystemへの指示は一定守られるが、少し複雑化すると精度が悪くなったり、トレーニングされていないようなタスクも多い Long Context 対応 Lost in the middle問題はじめ、プロンプトの肥大化や会話履歴の増大に伴い回答精度や速度性能劣化が発生する。 精度の問題とは別に、そもそもの入力コンテキストサイズを広げていくことも目下の課題となる。 マルチモーダル推論精度 Visionはじめ複数のモダリティが含まれる際に単一モダリティと比較し、精度低下が発生する。 通常の人間であれば容易に解釈可能な指示を把握できないケースもある。https://arxiv.org/abs/2409.02813 自律的・探索的な問題解決 「出力結果、調査結果を踏まえて、ダメだったら修正を施す」といった探索的な問題解決や、計画性を持って自律的に ユーザの入力から情報収集し、マルチターンで徐々に答えにたどり着くようなタスクを処理する十分な能力を有していない。 人間らしさ 出力したテキストがAIによる生成物だと分かってしまう、文章の癖や堅さが発生する。 (人間に似すぎてしまうことは好ましくないという考え方もあるが) アラインメント プロンプトリーキングやインジェクションに対して、根本的に有効な手段が確立されていない。 ファインチューニングの柔軟性 新しい語彙や言語の獲得や、タスクの習得のためにファインチューニングを施す場合、学習用のデータや環境を揃えたり instruction tuningやアラインメントの再調整が必要となるケースがありハードル高い。
35. 35 高度な reasoning 能力を持った o1 モデルの登場 推論過程の強化学習を施し、多段推論することによって、論理構成力が高まり高度な性能を獲得 Learning to Reason with LLMs | OpenAI o1 のご紹介: Azure の開発者と企業向けの OpenAI の新しい推論モデル シリーズ |Microsoft Azure ブログ マテリアル インフォマティクス トラブルシューティング ドキュメント作成 コーディング 解決が期待される用途？ (個人的な推測) Reasoning - OpenAI API
36. 36 o1の複数モデルを正しく理解する 最高性能のo1は未公開、o1プレビューは初期版、o1-miniはo1の軽量版という位置づけで、 広範な知識を要しないタスクについてはpreviewよりminiの方が安価かつ高性能なケースがある OpenAI o1-mini | OpenAI
37. 37 LLMOps
38. 38 AI・人間の違いから見る LLMOps の必要性 「成長」のインパクトが大きいことが従来システムと違うAIシステムの真骨頂。しかし放置していてもその価値を引き出せない。 記憶の強化 業務へのフィッティング 熟練者の育成 業務の問題点への対応 脳の基礎スペックの進化 基本は不変 自己反省し学ぶ モデル更新が頻繁に発生し基礎スペックが進化 手動 (In context Learning, Fine tuning) 手動 (RAG) 人ごとに教育が必要 エスカレーションする 対応品質差なく無限スケールが可能 放置 人間の労働者 AI 更新するほど価値が高い 放置してても成長しない 放置してても成長しない 品質向上のインパクト大 監視や分析の必要性 AIシステムの真骨頂を引き出すには、監視・分析・評価改善・デプロイの仕組みの構築が必須
39. 39 LLMOps とは (本資料の定義) LLMシステムを効率的に運用・改善する仕組みのこと。定義はやや曖昧さがある。 DevOps MLOps 派生 派生 LLMOps 評価 チューニング デプロイ 監視・ロギング LLMを効率的に開発・運用するためのプラクティスおよび一連のプロセス やツール群を指す。モデルのFine tuningや継続的な最適化に関しては、 MLOpsの考え方を内包しつつ、LLM特有の課題にも対応する。 Prompting、Fine tuningによるLLMの挙動制御。 本資料ではRAGもLLMシステムの範囲内と捉える。 LLMおよびRAGのチューニング結果を評価する観点、 指標決定、手段を定め実行する。 スケーリングの調整やデプロイ時テストを含む パイプライン構築など。 入出力や処理時間などの指標を可視化することで 異常を早期にキャッチする ログ分析 システムやLLMのログを分析し、ユーザ挙動から改善点を探る
40. 40 Human in the Loop を伴う LLMOps (RAGを除く) Step1 LLMアプリ運用 Step3 データ選別/加工 Step5 評価テスト/デプロイ PII、情報鮮度チェックなど 評価フロー フロントエンド Orchestrator LLM推論 ログDB ETL Data Lake メトリック監視 分析/評価 Fine tuning API Prompting Step4 チューニング 評価用データ 訓練・Shot用データ LLM as a Judge 手動評価 Tuned Model 推論結果 Step2 データ収集/監視・分析 評価 デプロイ パイプライン Step2へ Step3へ 繰り返し 検討 繰り返し 検討 再度 Step1へ 利用 利用 利用 評価 Input
41. 41 LLMシステムにおけるチューニング対象 LLMシステムにおけるチューニングは大きく4対象。STT/TTSを組み合わせる場合はそのチューニングも含まれる。 RAG LLM Fine tuning Prompting ➢ モデル選択 ➢ データセット整備 ➢ Augmentation ➢ 学習ハイパーパラメータ調整 ➢ 正則化の調整 ➢ 順序の調整 ➢ 全体の構造化 ➢ 指示の明瞭化 ➢ 軽量化 ➢ プロパティ名への情報付与 ➢ プロンプティング・関数定義(情報収集、クエリ加工) ➢ チャンクサイズ ➢ インデックス構造 ➢ Embeddingモデル調整 ➢ ハイブリッド検索 ➢ カテゴリ検索 ➢ リランク ➢ returnドキュメント数 Content Filter ➢ NG対象辞書 ➢ フィルタモデルファインチューニング https://speakerdeck.com/hirosatogamo/chatgpt-azure-openai-da-quan Prompting,RAGのチューニングは大全参照
42. 42 LLMシステムにおける Fine tuning の位置づけ LLMシステムにおいて両者は若干の位置づけの違いはあるが、評価という点では似たプロセスとなる。 LLMシステムにおける Fine tuning の位置づけ LLMシステムにおいて両者は若干の位置づけの違いはあるが、評価という点では似たプロセスとなる。 Fine tuning Prompting LLMシステムにおける用途 ➢ システムプロンプト ➢ 評価用データセット 用意するもの ➢ 学習用データセット ➢ 学習コンピューティング環境 ➢ 評価用データセット ➢ 修正・試行が容易 ➢ 調整に要する専門知識が 比較的軽い 利点 ➢ 生成が高速 ➢ 複雑な指示・ 多量なリクエストが安価に ➢ LLMシステムにおいてはFine tuningとPromptingはほぼ同じ用途 ➢ LLMの振る舞いを制御する ➢ LLMの知識やボキャブラリを強化する ➢ LLMのタスク精度を向上する ➢ 生成時のシステムプロンプト 分のトークン コスト ➢ 学習時のコンピューティング ➢ 生成環境 # Role ～～～～～ # Your task ～～～～～ # Output policy ～～～～～ # Tools ～～～～ LLMOpsはMLOpsから派生した… LLMOpsはMLOpsから派生した… LLMOpsとは何ですか？ LLMOpsとは何ですか？ トレーニング デプロイ 理想の会話履歴など System＋User Promptを 入力 User Promptを 入力 System Prompt User Prompt User Prompt System Prompt無しでも 想定の振る舞いが可能に
43. 43 プロンプトの評価 LLMに期待する動きはほぼシステムプロンプトが設計図になっているため、これをベースに評価方法を考える。 # **Role** {LLMに求める役割} # Task {業務の目標・内容やその手順の定義。} # Policy {振る舞いのルール。Taskとは切り分ける} # Input {インプットの想定} # **Output** {アウトプットの想定} # Tools {toolに関する注意。Function定義と併用} # Prerequisites {前提情報やFAQなど} システムプロンプト ルール ロール タスク 基本は評価不要 (細かい振る舞いはルール定義に集約) 手順の遷移の正しさ(状態遷移) I/O Tool 参照データ 振る舞いの実際の挙動 禁止事項の遵守可否 評価対象 ー ➢ 会話ログ全体からの遷移結果の評価 ➢ 遷移直前までの会話履歴からの次アクション確認 評価方法の例 目標達成可否の結果 想定外のインプットへの対処 アウトプット形式 アウトプット内容の質 Tool選択の適切さ 抽出パラメータの確からしさ Groundedness (渡したデータを解釈できているか) ➢ 会話ログ全体からの目標達成可否の結果確認 ➢ 会話ログ全体からの振る舞いの結果確認 ➢ 対象の振る舞いを引き出す入力を用意し結果確認 ➢ 対象の振る舞いを引き出す入力を用意し結果確認 ➢ 想定入力以外の入力を用意し結果確認 ➢ パースや型チェック ➢ タスクによって確認方法が変わる ➢ Function Callingを引き出す入力を準備しCall対象の確認 ➢ タスクによって確認方法が変わる ➢ データに関する質問回答ほか
44. 44 入出力パターン別の評価方法 マルチターンの評価は現状有効なツールも無く、評価用データセットの準備のための労力がやや大きい。 カテゴリ or 数値 自然言語 シングル マルチ パターン ① - ✓ ✓ ➢ 質問内容のカテゴリ判定 ➢ 感情分析のスコアリング 評価対象出力の形式 評価対象出力のターン数 シングル マルチ - ✓ 入力のターン数 - 例 評価方法 正解データを用意し、カテゴリ予測/ 回帰系MLの評価指標活用 パターン ② - ✓ ✓ ➢ 関係の無いトピックの質問 に対するreject - ✓ - • LLM as a Judge • 人手評価 • Embeddingによる類似度評価 パターン ④ - ✓ ✓ ➢ 会話からのRAGクエリ抽出 ➢ 要約 - 直前までの会話履歴を準備し、 出力結果を②の手法で評価 パターン ③ - ✓ ✓ ➢ Function Callingにおける 関数の選択 - 直前までの会話履歴と正解を準 備し、出力結果を①の指標で評価 ✓ - ✓ - パターン ⑤ ✓ ➢ 1連の手順をユーザの反応を 見ながら少しずつ説明する - ユーザ役の人またはLLMを準備し 会話させ、評価対象を引き出し、 会話履歴をLLMまたは人手評価 ✓ - ✓ - 厳密には直前までの会話履歴を準備する 手法は再現性が保証できない点は注意
45. 45 RAGのチューニング対象項目 RAGは僅かな観測対象からチューニング項目を適切に選択し、手を打つ必要がある。細かい調整は大全4章を参照。 検索呼び出しプロンプト調整 ➢ 十分な情報収集ができるように、検索までの情報収集や検索タイミングの調整 クエリ化・関数定義チューニング ➢ クエリへの十分な情報付与および加工・拡張などの調整 検索エンジンチューニング ➢ 検索ロジック、リランク、フィルタ検索などの設定 Groundednessに配慮した結果取り込みドキュメント数調整 ➢ 取り込む検索結果のドキュメント数 インデックス改良 ➢ インデックスアーキテクチャやチャンクに含む情報、検索対象の調整 クエリ化結果 検索された ドキュメント 最終回答 観測できるもの チューニング対象
46. 46 RAGの評価 RAGの評価は意外にもシンプル。 RAGシステムからの出力収集 正解となるデータセットの準備 「質問」、「理想の回答」、「検索されるべきドキュメント」のペアを多量に用意する。 件数の目安は特に無いが、バリエーションや数が多いほど評価の信頼性が高まる。 1で用意した質問をRAGシステムへ入力し、 「RAGシステムの最終回答」、「検索された ドキュメント(群)」を取集する。LLMは確率的な生成をするため同じ質問でも聞き方を 変えるなどして、複数生成させておくのが望ましい。 出力と正解の突合せ 1と2を比較し、適切なドキュメント抽出が出来ているか、回答の正確性を評価する。 ドキュメントについてはIDを突き合せれば評価できるが、回答についてはLLMを用いて 評価する必要がある。 1 2 3 Azure OpenAIで 使えるモデルは？ 2で出力された結果 1で用意した正解 検索されたドキュメント 正解のドキュメントが 含まれているか判定 正解のドキュメント RAGシステム gpt-4, gpt-35-turbo, …が利用 可能です。 検索結果をコンテキストとして 与えた際の最終回答 採点 正解の回答 現在使えるモデルはgpt-4, gpt-35-turbo, …です。 LLM or 人 ドキュメント検索 検索結果を基にした回答
47. 47 「ちょっと待て」 ～評価役へのLLM活用～ GPTに出力を評価させる場合、その評価が妥当なものであるかどうかを確認する必要がある。 Azure OpenAIで 使えるモデルは？ 2で出力された結果 1で用意した正解 検索されたドキュメント 正解のドキュメントが 含まれているか判定 正解のドキュメント RAGシステム gpt-4, gpt-35-turbo, …が利用 可能です。 検索結果をコンテキストとして 与えた際の最終回答 採点 正解の回答 現在使えるモデルはgpt-4, gpt-35-turbo, …です。 LLM このLLMによる採点は 信頼してもいいのか
48. 48 評価役LLMの採点能力の検証 評価役が人である場合は業務や領域の熟練者などを連れてくることで解決するが、 LLMには実際に評価をさせてみて、その評価が適切かどうか最初に検証しておく必要がある。 対話履歴データ 評価役LLMによる採点 人間によるチェック (人間のスコアとの比較) 5 Score 4 Score 4 Score 5 Score 5 Score 2 Score 3 Score 4 Score 比較 比較 比較 比較
49. 49 評価用データセット・会話履歴データの揃え方 データセット収集はLLMプロジェクトにおいて、最も重要だが最も手間が掛かる。 少量でも良いのでプロジェクト開始時に作成しておくことでプロジェクト進行は遥かに楽になる。 オ フ ラ イ ン オ ン ラ イ ン ➢ 会話内容を自由にコントロール可能 人手作成 LLMによる シミュレータ 本番運用時の 対話履歴 ➢ 作れる件数が限られる。外注などが必要。 ➢ 外注の場合、ドメイン固有の知見などは 反映できない ➢ 一度良いシミュレータを確立できたら 大量にデータを生成できる ➢ リアルな対話にならない ➢ トラブルや規定路線の対話がメインとなるため テストケースを引き出しにくい ➢ 作成に手間が掛かる ➢ 人手を掛けず収集するため手間が最も低い ➢ リアルな会話をベースにテスト出来る ➢ 本番運用が始まらないとデータが存在しない、 いわゆるコールドスタート問題がある。 ➢ 評価観点に沿った会話を網羅的に 取得することが難しい。 Pros Cons
50. 50 プロンプトログの分析による GPT システム継続改善例 Blob Storage Azure Datalake Storage Azure Machine Learning データ取得 ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ プロンプトログ Azure OpenAI Service Embedding + クラスタリングを施し プロンプトの傾向を分析→ FAQデータベース化へ Sentiment分析にかけ 回答の良し悪し分類→テストデータ化やメタプロンプト改善 独自のContent filteringトレーニングに用いて 不正検知やプロンプトインジェクション対策 レコメンドアルゴリズムへのインプットにして より高度なパーソナライズへ
51. 51 最後に
52. 52 AIの発展により起こる社会変化で、何をすべきか テキストモデルに留まらない、生成AIの視界・音声へのモダリティ拡張により、 あらゆる行動にAIが介在する製品・サービスが登場。特定の作業の自動化で1人あたりで捌ける労働量が大幅に拡大へ。 Consumer Business Vision Text Voice ➢ 高度な知識・知能を持ったパートナーAIが 新たなデバイスを通じてユーザと視界を共有し、 音声対話UIで日常生活を常にサポート ➢ 汎用性が求められ、恐らく大規模モデルが採用 クラウド上の パートナーAI (汎用/大規模AI) 移動 (自動運転、音声案内) 情報探索 (新たな検索エンジン) コミュニケーション (リアルタイム翻訳・発話補助) ➢ コンシューマとの接点は汎用AIを通じて実施 ➢ 各社製品・サービスは特化型AIで最適化(AIのインターフェース搭載が標準化) ➢ AIを活用した徹底的な業務効率化競争に入る ➢ 1人当たりの業務遂行能力が向上。少人数でも労働力がスケール。 人間はAIの仕事をデザイン・管理するマネージャ的な存在へ。 独自サービス・業務組み込み AI業務変革競争の勃発 人間のチームによる 業務遂行 AIによる労働成果の爆発的スケール (特化型/中規模AI) 汎用AIのパートナー化 セールス (資料作成、営業代行) 窓口業務・サポートセンタ (自動応対、トラブルシューティング) 一部はパートナーAIも 機能提供 独自業務・製品組込は 特化型AIを整備 ※個人的な予測を含みますので参考程度に
53. 53 未来へ向けて我々は何を始めるべきか AIの受入には実業務を通じた生の経験と時間が必要。 しかし劇的な速さで進行するAI技術に対しては、過去のITの業務浸透よりも急ピッチな準備が求められる。 AI適用すべき領域の可視化は急務 ➢ AIの進化フェーズに応じた 人間の業務の関わり方の変遷を定義 ➢ 現時点からの段階的なトランスフォーム 計画を策定 来るAI労働力スケール時代に向けた 業務プロセス整理 AI開発と業務浸透に対する 企業としてのCapability強化 AIを監視・育成し続けるための プラットフォーム整備 AIの真骨頂「成長」を続ける地盤づくりへ ➢ AIの監視・分析・学習・記憶のための パイプライン整備 ➢ 監視・育成用に役立つデータを整理、 収集管理するプラットフォーム構築 開発・業務ともにAIドリブンへの 人間側の適合に経験蓄積が必須 ➢ 新技術へ対応した迅速な開発力強化 ➢ 実際にAIを駆使した 実業務での活用による訓練
54. 55 ◼ 本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性 については保証できません。 ◼ 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。 ◼ すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコー ディング、その他）、および目的であっても禁じられています。 これらは著作権保護された権利を制限するものではありません。 ◼ Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、著作権、ま たはその他の知的財産へのライセンスを与えるものではありません。 © 2024 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。