AWS re:Invent 2023 - LLMOps: The lifecycle of an LLM の(おそらく)世界最速レポート

はじめに

レバレジーズ株式会社 テクノロジー戦略室室長の竹下です。 現在 AWS re:Invent 2023に現地ラスベガスで参加しています。皆さんに少しでも早くラスベガスの風を感じてもらうために、月曜午前の”LLMOps: The lifecycle of an LLM”セッションのレポートを、あの会社や、あのブログより最速でお届けしたいと思います。

他の記事も見たい方はこちらの目次からお辿りください。

セッション概要

LLMOpsを進めるに当たって、E-mailのサマリーを自動で作成するシステムを例に出しながら、どのような観点でどのように意思決定をするかをシミュレーション。また、AWSのサービスをどのように組み合わせてシステムを実現できるかの構成の紹介もあり

セッションの内容

今回は、Toolingと、LLMOpsの構築プロセスについての話をしていく。 E-mailのサマリーを自動で行うシステムを例にして話をしていく。 LLMOpsにおいても、「Start small, think big」は大事。 まずは、ただサマリーを作る部分から始めるものの、最終的には各人のドメインを理解したシステムを考えて作る必要がある

MLOpsとLLMOpsまたFMOpsの違いはなにか? どちらもほぼオーバーラップしている

LLMOpsには、3タイプのユーザーがいる。 Provider: Tuners, Customer それぞれ必要なスキル、注目点が違っている

LLMOps構築までのプロセスと、構築後の改善プロセスがある。 まずは構築段階の話をしていく

まずはUseCaseの分析が必要。Criticality, Scale, Task Type, Eloquence, ROIの観点が大きく考えられる。今回のE-mailのサマリーシステムの場合は、 Criticality: Low 内容多少違っていたとしても、メールの本文を読めば良いので、優先度は低い Scale: Low 自分のメールの入力だけで良く、出力もそのユーザーに向けてだけなのでデータ的にスケール要件は低い Task Type: Specific メールの要約というSpecificな範囲 Eloquence: Medium 文章的に自然である必要はある程度ある ROI: 重要。生産性を高めることがちゃんと出来る必要がある

LLMモデルを選択するときの判断軸としては以下のような物がある。

この中でUseCaseで重要な項目と優先度を見積もっていく 今回のE-mailのサマリーシステムの場合は Cost > Precision > Speed となる。

また、通常のDeepLearningなどはハイパーパラメーターなどの調整となるが、LLM、GenAIの場合は、プロンプトの調整となる

モデルが決定し、調整も出来たら、評価が必要。 モデルは完璧では無いため多層的に、図のようなチーズモデルによって評価し、致命的な問題が無いかを適正にチェックする必要がある。

構築が完了したら、あとは改善のループを回す必要がある。最初の構築はS3がらSageMakerのNoteBookなどを利用し、BedRokSummaryを投げて結果を返す。

システム化する、受け取ったメールのデータを転送、バッチを定期実行、出力された結果をメールする、QuickSightにつなぎこんで評価を可視化するなどをするため、以下のような構成になる

更に進化させるには、Orchestrationも必要となってくる

最後に

現地時間 2023/11/27 12:01 書き上げました。セッション聞きながらリアルタイムでまとめてリリースしたので、きっと世界最速レポートになっていると思います。 聞き漏らしたところもあるので完璧な内容ではない部分もありますが、ご了承ください。

現在、私たちと一緒に挑戦してくださるエンジニアを募集しています。ご興味のある方はぜひ採用サイトをご覧ください!