Cloud Next '23 から考える LLMOps

by Asei Sugiyama

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 での対応方法は回答のひとつになりそう実際にそれをまねてみようとすると難しいので、ルールやアンケートを用いた評価から始めるのが現実的