251 Views
December 01, 24
スライド概要
CloudNative Days Winter 2024の登壇資料
https://cloudnativedays.jp/
温かい目で見守ってください
気まぐれ LLMのふるまいを暴け! - OpenLLMetryを通して見る世界 @shukawam / @ystkfujii 1
Shuhei Kawamura(X: @shukawam) Job: Senior Solutions Architect / Oracle Japan ひとこと: 車をゲットしたけどその 2日後に飛び石をくらってフロント ガラスを全交換しました 😇 Job: 何でも屋(Terraform/k8s/Golang) / ニート ひとこと: ミュウツーexが全然出ない 🥺 Yoshitaka Fujii(X: @ystkfujii) 2
はじめに ● ● 目的: ○ OpenLLMetryの完全理解 話さないこと: ○ LLMの評価手法について ○ 実運用を通じたLLMのオブザーバービリティTips 3
アジェンダ 1. 2. 3. 4. 5. Cloud Native と AI LLM × オブザーバービリティ OpenLLMetryとは 実際にやってみた まとめ 4
Cloud NativeとAI 5
AIってCloud Nativeなんだろうか・・・? 🤔 6
Cloud Native と AI ● ● ● 2023/03: CNCF TAG(Technical Advisory Group) AIの提案[1] 2023/11: Cloud Native AI Working Groupとして承認[2] ○ TAG RuntimeとTAG Observabilityの共同ホスト 2024/03: Cloud Native AI Whitepaperの発表[3] ○ KubeCon + CloudNativeCon Europe 2024でアナウンス[4] [1]https://github.com/cncf/toc/issues/1048 [2]https://github.com/cncf/toc/issues/1200 [3]https://www.cncf.io/reports/cloud-native-artificial-intelligence-whitepaper/ [4]https://kccnceu2024.sched.com/event/1Yhhk/observability-tag-a-review-and-the-rise-of-gen-ai-observability-alolita-sharma-mattyoung-apple-vijay-samuel-ebay-bartlomiej-plotka-google 7
Cloud Native Artificial Intelligence Whitepaper Cloud Native Artificial Intelligence is an evolving extension of Cloud Native. 進化の先 8 https://www.cncf.io/blog/2024/03/19/announcing-the-ai-working-groups-new-cloud-native-artificial-intelligence-whitepaper/
Cloud Native Landscape group CNAI 9 https://landscape.cncf.io/?group=cnai
用語の関係性 10 https://tag-runtime.cncf.io/blog/cnai-kubecon-eu-paris-2024-recap/#form-storm-norm
用語の関係性 11 https://tag-runtime.cncf.io/blog/cnai-kubecon-eu-paris-2024-recap/#form-storm-norm
LLM と Observability Observability LLMを利用して 予測 / 検知 / 補助 する LLM LLMワークロードを 観察 / 監視 / 分析 する 👆今日はこっち 12 https://youtu.be/YluNsK0hgrw?t=696
LLM x オブザーバビリティ 13
ChatGPTやGitHub Copilot など使ったことある方?🖐 14
規模を問わずLLMを使った アプリケーションを開発したことがある方🖐 15
作ったLLMアプリケーションを適切に監視し、 継続的に改善するためのデータを取得している方🖐 16
LLM(Large Language Model)とは 大規模な言語モデルのこと(完)... 言語モデル ■ 単語や文章の出現確率を統計的に分析しモデル化したもの 何が大規模なのか ■ パラメータ数、学習データ、計算量 モデルの性能が大きく向上[1]し、高度な言語能力を獲得 17 [1] Scaling Low: パラメータ数、データセットのサイズ、計算量が増えると損失 (誤差)がべき乗則に従って、減少する法則のこと 参考: https://arxiv.org/abs/2001.08361
LLMをアプリケーションに組み込む際の課題の例 1 それっぽい出力だが、 期待したものではない。 誤った内容も含まれている。 18 回答には、Cohere Playground(command-r-plus-08-2024)を使用
参考:期待した出力はなぜ得られないのか ■ ■ LLMは、ある単語に対して次に続く単語を確率的に選択するだけ ◻ i.e. 正しい情報を出力することを目的として学習されていない 学習データは必ずある時点までのスナップショット ◻ i.e. 学習時以降のデータや学習データ期間に含まれ得ない情報は 正しく出力することができない ◻ command-r-plus-08-2024はどんなに長く見積もっても2024/08ま でのデータしか含まないので、CNDW2024の情報は正しく出力す ることができない 19 参考: Building LLM Powered Applications - https://learning.oreilly.com/library/view/building-llm-powered/9781835462317/
参考:LLMに追加の知識を与える 1. 継続事前学習 a. 知識を与えたいドメインに対して大量の未ラベルデータを用いて追 加の学習をすること 2. ファインチューニング a. 比較的少量のラベル付きのデータを使用して、モデルの出力をそ のタスクに特化させること 3. グラウンディング a. 特定の知識や情報源に接続することで、LLMの出力を現実世界の 知識に基かせるプロセスのこと 20
参考:LLMに追加の知識を与える 1. 継続事前学習 a. 知識を与えたいドメインに対して大量の未ラベルデータを用いて追 加の学習をすること 2. ファインチューニング a. 比較的少量のラベル付きのデータを使用して、モデルの出力をそ のタスクに特化させること 3. グラウンディング a. 特定の知識や情報源に接続することで、LLMの出力を現実世界の 知識に基かせるプロセスのこと 21
参考:Retrieval-Augmented Generation | RAG RAG: LLMの出力を関連情報を取得する検索システムと統合し、LLMへ入力 するプロンプトを拡張することで強化する手法のこと 検索システムの例: ベクトルデータベース、全文検索エンジン、etc. 1. 入力 4. 入力 + 関連情報 5. 関連情報を含んだ出力 3. 関連情報の取得 2. 関連情報の検索 図: RAGの流れ 22
LLMをアプリケーションに組み込む際の課題の例 2 同じプロンプトを入力しても同じ出力がされるとは 限らない。出力の品質にばらつきが生まれる可能 性もあるし、コスト [1]も変わり得る。 23 回答には、Cohere Playground(command-r-plus-08-2024)を使用 [1] OpenAIやCohereなどは、LLMの推論環境を入出力のトークン、文字数による従量課金で使用可能
LLMアプリケーションで起こり得る課題例について 期待する内容が出力されない 予測が難しい運用コスト 出力に時間がかかってしまう … 改善策を検討する&その結果を確認するために必要なデータはきちんと 収集し、それが活用できる状態であるべきでは?
オブザーバビリティ システムがどのような状態になったとしても、それが どんなに斬新で奇妙なものであっても、どれだけ理 解し説明できるかを示す尺度 25 https://www.oreilly.co.jp/books/9784814400126/
オブザーバビリティが重要だと考える理由 ■ ■ ■ ”LLMのふるまいは気まぐれ”(非決定的)であること ☐ だが、機能の根幹を担っておりサービス品質に直結する LLMアプリケーションは構成や処理フローが複雑になりがち ☐ LLM、検索コンポーネント、キャッシュストア、外部API、... ☐ 処理フロー自体をLLMに推論させる[1]ような実装も存在する ユーザーの入力は多様であること ☐ セキュリティリスクを含む入力がされる可能性もある ■ e.g. xxさんのパスワードを教えてください 26 [1] ReAct: 入力を解決するために必要なアクションをLLMに推論させ、実行すること。LangGraphはその有名な実装。
LLMアプリケーションの監視項目 ● ● ● Traces ○ LLMアプリケーションの入力〜出力までの流れ + 付帯情報 ○ e.g. 各ステップの実行時間、モデル名、パラメータ Metrics ○ LLMを使用するクライアント: トークンの使用量、処理時間 ○ LLMをホストするサーバー: TTFT[1]、TPOP[2] Events ○ LLMに対する入出力のキャプチャ 27 [1] Time To First Token: レスポンスのための最初のトークンを生成するために要した時間 [2] Time Per Output Token: 最初のトークンの後に生成されるトークンあたりに要した時間
探究!OpenLLMetry 28
OpenLLMetry ● ● ● OpenTelemetryを拡張したLLMオブザーバビリティツール ○ Traceloop社がApache 2.0ライセンスで公開 ○ Semantic Conventions for Gen AIをリード[1] さまざまなツールに対する計装ライブラリ も提供 ○ OpenAI、LangChain、Chroma DB など 利用例 29 https://www.traceloop.com/docs/openllmetry/contributing/semantic-conventions
Semantic Conventions for Gen AI[1] ● OpenTelemetry配下で生成AIに対するセマンティック規約を策定 ○ 対象:Events[2] / Metrics / Spans(Traces) セマンティック規約とは、 さまざまな操作やデータで 推奨される名前 を定義したもの ● たとえば、Spanの規約(一部抜粋) Attribute Description Example gen_ai.request.model リクエスト先の生成AIの名前 gpt-4o-mini-2024-07-18 gen_ai.usage.input_tokens 生成AIの入力で使用されたトークン数 83 experimental 30 [1] https://opentelemetry.io/docs/specs/semconv/gen-ai/ [2] 2024年10月にマージ:https://github.com/open-telemetry/semantic-conventions/pull/980
Semantic Conventions for Gen AI[1] ● OpenTelemetry配下で生成AIに対するセマンティック規約を策定 ○ 対象:Events[2] / Metrics / Spans(Traces) OpenLLMetryを利用すると、 さまざまな操作やデータで 推奨される名前 を定義したもの セマンティック規約をもとに、 いい感じに計装 できる! セマンティック規約とは、 ● たとえば、Spanの規約(一部抜粋) Attribute Description Example gen_ai.request.model リクエスト先の生成AIの名前 gpt-4o-mini-2024-07-18 gen_ai.usage.input_tokens 生成AIの入力で使用されたトークン数 83 experimental 31 [1] https://opentelemetry.io/docs/specs/semconv/gen-ai/ [2] 2024年10月にマージ:https://github.com/open-telemetry/semantic-conventions/pull/980
GrafanaからTraceをみると LLMからの回答 ユーザからの質問 32
GrafanaからMetricsを見てみる 処理時間 消費トークン数 33
Traceloop (SaaS)も利用可能 34 https://app.traceloop.com/
OpenLLMetryを使えばいい感じに計装できる ? 🤔 まだまだ発展途上... 変化に追いついていない部分もある ● ● セマンティック規約周り ○ メトリクスにTime To First TokenやTime Per Output Tokenがない[1] ○ Eventsは未実装[2] Frameworkの計装ライブラリ周り ○ LangChain Instrumentationはstream出力した場合、トークン数が取得 できない[3] [1]https://github.com/traceloop/openllmetry/blob/v0.33.12/packages/traceloop-sdk/traceloop/sdk/metrics/metrics.py#L87 [2]https://github.com/traceloop/openllmetry/issues/2322 [3]https://github.com/traceloop/openllmetry/blob/main/packages/opentelemetry-instrumentation-langchain/opentelemetry/instrumen tation/langchain/callback_handler.py#L251 35
OpenTelemetryの拡張ということは ...? 36
OpenTelemetryの拡張ということは ...? 既存のエコシステムが利用可能! 37
エコシステムとの統合 ● たとえば、 ○ Grafanaによる可視化 ○ テレメトリーシグナルに対する各種クエリ機能 ■ PromQL / TraceQL / TraceQL Metrics … ○ OpenTelemetry Collectorの活用 もちろん、、、 オブザーバビリティベンダーの SaaSも利用可能! (念のため) 38
計装ライブラリの提供状況 LLM Provider ● ● ● ● ● ● ● Azure OpenAI Aleph Alpha Anthropic Amazon Bedrock Cohere IBM watsonx Google Gemini ● ● ● ● ● ● ● Google VertexAI Mistral AI Ollama OpenAI Replicate together.ai HuggingFace Transformers 39 https://www.traceloop.com/docs/openllmetry/tracing/supported
計装ライブラリの提供状況 言語 ● ● ● ● ● Python Node.js Next.js Go Ruby Frameworks Vector DB ● ● ● ● ● ● Choma DB Marqo Milvus Pinecone Qdrant Weaviate ● ● ● ● Haystack LangChain LlamaIndex burr 40 https://www.traceloop.com/docs/openllmetry/tracing/supported
計装方法 これだけでサポートされている LLM Provider, Vector DB, Frameworkに対する計装が行われる [1] デコレーターを利用することも可能 41 [1] もちろん、Traceloop SDKを使用せずに計装することも可能です。
実際にやってみた 42
よし、 LLMアプリケーション作って オブザーブしてみよう! \ ヤッテク / 43
デモ:CNDW2024 セッション提案 Bot アプリケーション 44 https://github.com/codex-odyssey/cndw2024-llm-observability/tree/main
デモ:CNDW2024 セッション提案 Bot アプリケーション 45 https://github.com/codex-odyssey/cndw2024-llm-observability/tree/main
デモ:アプリケーションの概要 Agent 関連性 を評価 関連性が 高ければ 、 Respondentにパス 関連性が 低ければ 、 質問に関連する キーワードを生成 Respondent (回答者) Keyword Generator Prompt Template Prompt Template Chat Model Chat Model Session Retriever Retriever Prompt Template Vector DB Embedding Model Chat Model セッション情報 46 https://github.com/codex-odyssey/cndw2024-llm-observability/tree/main
デモ:アプリケーションの概要 役割:質問に関連するCloud Nativeっぽいキーワード作成 ②必要に応じて、質問に関連するキー ワードを生成 Keyword Generator ③質問 / キーワードで検索 ①質問 Responder (回答者) ⑤回答 Session Retriever ④関連するセッション情報 役割:ユーザーへの回答作成 https://github.com/codex-odyssey/cndw2024-llm-observability/tree/main 役割:質問 / キーワード に関連するセッションの取得
デモ:オブザーブしてみよう! LLMが何を生成しているのか? トークンをどれだけ消費しているのか? 処理時間が長いやつはどのコンポーネントなのか? 48
Grafana:LLMが何を生成しているのか 49
Grafana:トークンをどれだけ消費しているのか 50
Grafana:遅いコンポーネントはどれか? 51
ちなみに、 SaaSだとどんな感じ? 52
Traceloop:LLMが何を生成しているのか 53
Traceloop:遅いコンポーネントはどれか ソート 54
Traceloop:トークンをどれだけ消費しているのか 55
まとめ ● Cloud NativeはAIで進化する ● LLMには、固有のオブザーバビリティの観点がある ○ ● ● LLMの入出力 / トークン数 / モデル名等の属性値 など OpenTelemetryの拡張として、OpenLLMetry がある ○ 既存のエコシステムが利用可能 無限の可能性 ○ 特化したツールに比べると、学習や実現コストが発生 今後のエコシステムの進化に期待!!! 56
宣伝:同人誌作りました! 57 https://techbookfest.org/product/vwEgK9fAmzRphNukv4E83P?productVariantID=b6iAh0AVyEs4hCUczPiy89 https://techbookfest.org/product/mn0L7GEm3s8Vhmxq971HEi?productVariantID=myG2YLxFNAEVkRf2dipG8f
Thank y u! 58