Tweet
Tweet

Slide 1

Slide 1 text

Cloud Next '23 から考える LLMOps Citadel AI Asei Sugiyama

Slide 2

Slide 2 text

自己紹介 杉山 阿聖 (@K_Ryuichirou) Software Engineer @ Citadel AI Google Cloud Innovators Champion @ Cloud AI/ML MLSE 機械学習オペレーション WG 機械学習図鑑 共著

Slide 3

Slide 3 text

TOC LLMOps 前夜 <- LLMOps in Next '23 まとめ

Slide 4

Slide 4 text

LLMOps 前夜 MLOps VS LLMOps LLM で新たに出現した事項 LLM の運用における課題

Slide 5

Slide 5 text

MLOps VS LLMOps まったく違うものになるという予感はしていた 何が異なるのか、うまく言えない状態が続いていた

Slide 6

Slide 6 text

LLM を用いるアプリケーションで新たに出現した事項 汎用 Chatbot プロンプトエンジニアリング RAG

Slide 7

Slide 7 text

汎用 Chatbot 特定タスクに特化しない Chatbot データ基盤や分析基盤を社内に 構築していなくても、いきなり 導入できる AI は画期的 「データを貯めてるから AI に分 析させればなんかできるんじゃ ないか」は依然として無理なの でお帰りください

Slide 8

Slide 8 text

プロンプトエンジニアリング 入力文を操作することで出力の クオリティを上げるテクニック Chain of Thought などのさまざ まなテクニックがある 「プロンプト」が管理対象に含 まれる ChatGPT Prompt Engineering for Developers https://www.coursera.org/projects/chatgpt-prompt-engineering-for-developers- project

Slide 9

Slide 9 text

RAG (1/2) 検索と LLM を組み合わせるアプ リケーションのアーキテクチャ 検索結果をユーザーの問い合わ せに加えて LLM にわたす 「学習せずに知識をモデルに与 える」という発明 Google Cloud で生成 AI アプリケーションを作ろう！パート 7 : 複数サービスの組み合わ せ技で実用的なアプリを作る https://zenn.dev/google_cloud_jp/articles/generative- retrieval-augmented-generation

Slide 10

Slide 10 text

RAG (2/2) RAG の動作は要約タスクの性質を思い出すと理解しやすい 出力文は未知の入力文と同様の内容を持つ文章となっている 入力文の内容を変更することで、出力に含めたい情報を意図的に操 作できる 学習データに含まれていない内容も、要約タスクとして与えること で、LLM から出力できる 数億のコストを払わずに LLM を「学習」させていることが画期的

Slide 11

Slide 11 text

課題 データの用意が大変 学習にかかる莫大なコスト 新たな管理対象 モデルのサービングがとても大変 言語資源の品質の定義が困難

Slide 12

Slide 12 text

データの用意 データの用意が非常に大変 大規模な言語資源: 地球上のすべての 言語資源を集めている 高品質な対話データ: 基本的には Q&A で、数千対話程度が必要、一問 一答形式ではダメ 高品質な評価用データ: 多様なタスク を評価するためのデータが必要 ELYZAが公開した日本語LLM「ELYZA-japanese-Llama-2-7b」についての解説 : (2) 評価編 https://zenn.dev/elyza/articles/5e7d9373c32a98

Slide 13

Slide 13 text

LLM は一企業に作れるもの ではない クラウドコストを見るとほぼ明 らか Finetune を粗雑なデータセット で行うと壊れることも知られて いる ELYZAが公開した日本語LLM「ELYZA-japanese-Llama-2-7b」についての解説 : (2) 評 価編 https://zenn.dev/elyza/articles/5e7d9373c32a98

Slide 14

Slide 14 text

管理対象に新たなデータが含まれる 今までの機械学習では再現性を得るために典型的には次を管理する コード モデル データ (訓練・評価) これに加えて、プロンプトや検索 DB も管理対象となる さらに、同一のプロンプトやパラメーターでも同一の結果が得られない ため、「再現性」の確保はとても大変

Slide 15

Slide 15 text

モデルのサービング 自分でモデルをサービング するのはとても大変 学習用の GPU と推論用の GPU は大きく特性が違う (VRAM の量やレイテンシ、 価格) LLM は推論用の GPU に乗 らない GPU platforms | Compute Engine Documentation | Google Cloud https://cloud.google.com/compute/docs/gpus#general_comparison_chart

Slide 16

Slide 16 text

モデルのサービング API の利用が第一選択 計算資源の利用量や内部の処理 時間は監視の対象外 応答時間やエラー、課金額を監 視することになりそう API や SDK は頻繁に更新されて おり、Stable とは言い難い v1.0.0 Beta · openai/openai-python · Discussion #631 · GitHub https://github.com/openai/openai-python/discussions/631#discussioncomment- 7191589

Slide 17

Slide 17 text

言語データの品質について定義が困難 (1/4) 膨大な学習データ 高品質な対話データ 高品質な評価用データ 検索データベースのデータ アウトプットの評価

Slide 18

Slide 18 text

言語データの品質について定義が困難 (2/4) 膨大な学習データ 世間に存在する差別や偏見の影響は確実に受ける 一般に存在する誤解も影響 (大手のものはうまく弾いている様子) 高品質な対話データ 「対話が高品質」というのはどう定量化する？ 長ければ良い？短ければ良い？丁寧な方が良い？

Slide 19

Slide 19 text

言語データの品質について定義が困難 (3/4) 高品質な評価用データ 新たなプロンプトや RAG を構築した場合、評価が改めて必要 評価用データセットをアプリケーションごとに定義する必要がある 望ましい対話を定義し、具体例として保持する必要があるが、スケール させるのがとても困難

Slide 20

Slide 20 text

言語データの品質について定義が困難 (4/4) 検索データベースのデータ 「検索結果」とは異なる評価が必要 既存の Q&A や、過去の応対記録は必要な情報が欠落していることが多 く、大概の場合役に立たない アウトプットの評価 プロンプトは頻繁に更新されることが想定される 改善されたかどうか、エンドユーザーの評価が必要

Slide 21

Slide 21 text

LLMOps 前夜: ここまでのまとめ LLM の利用形態を考えると、LLM 特有な課題が出てくることが想定さ れる 学習データを用意しなくても動かすことはできるものの、評価は依然と して必要 課題はインフラや、コスト、データの品質と多岐にわたる 「高品質な対話データ」を準備することはかなり難しい

Slide 22

Slide 22 text

TOC LLMOps 前夜 LLMOps in Next '23 <- まとめ

Slide 23

Slide 23 text

LLMOps in Next '23 海外市場の対応状況 Google での対応方法 今後必要になるであろう対応方法

Slide 24

Slide 24 text

海外市場の対応状況 誰もが「LLM に対応してい る」と主張する 「対応している」の内容に は要注意

Slide 25

Slide 25 text

「LLM に対応している」 データベースであれば、ベクトルデータベースに対応していると誰もが 言う (e.g. PostgreSQL, MongoDB) モニタリング基盤であれば、LLM の API の監視に対応していると誰もが 言う 一般の SaaS ツールでも生成モデルに対応していると誰もが言う 評価について、ベストプラクティスやツールを提供しているところはほ ぼない

Slide 26

Slide 26 text

Google での対応方法 さまざまな有害なアウトプ ットの類型を定義 それぞれの種類の有害性に ついて、スコアを算出 (算出 方法の詳細は不明) おそらく、評価に特化した 機械学習モデルを作成して いるものと思われる What’s new with generative AI at Google Cloud https://youtu.be/Nw- E93ksuxk?si=RiJZ75okn-V3igiO

Slide 27

Slide 27 text

今後必要になるでろう対応 (1/2) 次のような観点からアプリケーションごとに指標を設計 アプリケーションに特有な指標 ガードレールとしての指標 一般的な言語モデルとしての指標 言語モデルを用いた評価やルールベースの評価を組み合わせて利用

Slide 28

Slide 28 text

今後必要になるでろう対応 (2/2) アプリケーションに特有な指標 何らかの精度指標 特定のフォーマットにしたがっている出力の割合 ガードレールとしての指標 toxicity fairness 一般的な言語モデルとしての指標 Q&A データセットを用いた評価 要約データセットを用いた評価

Slide 29

Slide 29 text

LangCheck OSS として公開中 機械学習モデルを用いて文 章を評価する機能も 一方、その困難さに直面す ることも 評価用モデルがない 良い入出力を自分で定 義しにくい citadel-ai/langcheck https://github.com/citadel-ai/langcheck

Slide 30

Slide 30 text

まとめ LLM は既存の機械学習と運用が異なるため新たな課題が生じる 多くのプレイヤーが LLM に取り組んでおり、市場は活発 LLM の評価がもっとも困難な課題だと思われるものの、そこに取り組ん でいるプレイヤーは少ない 「有害な事象を検出するためのモデルの開発」という Google での対応 方法は回答のひとつになりそう 実際にそれをまねてみようとすると難しいので、ルールやアンケートを 用いた評価から始めるのが現実的