ログラスの継続的なプロンプト改善のためのLLMOpsの今 / LLMOps at loglass now

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 新卒で入社したヤフー株式会社で、 ID連携システムの保守・運用開発を経験したのち、 ID連携システムのフルリプレイス PJに従事。その後、2022年に株式会社ログラスに入社。ソフトウェアエンジニアとしてマスタ管理機能等の開発、イネーブルメントチームの一員として横断課題の解決に取り組んだのち、現在は生成AI/LLMチームの立ち上げを行う。 X: @ry0_kaga 株式会社ログラス r-kagaya

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 ©2024 Loglass Inc. ログラス社のLLMへの取り組み LLMも用いて、予実分析結果・レポートを生成   さらに分析結果・データに対して指示を重ねることで追加で示唆を得る、加工を行える (e.g: 報告用に3行で特定部署のサマリ、〇〇の株価を調べて)  LLMを意識しないで使える体験   ・ボタン操作で簡単に Loglassのデータを生かし、 LLMも良い感じに組み合わせて、分析結果を得ることが出来る体験を目指している     → 本発表自体は基本この機能関連  

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 ©2024 Loglass Inc. LLMOpsとは？ LLMOpsは、運用中のLLMのライフサイクルを合理化し、最適化することを目的としたプラクティスとツールのセットです。効果的なプロンプトの設計から、複雑なモデルのデプロイとモニタリングのオーケストレーションまで、さまざまな活動が含まれる。 LLMOpsの原則を採用することで、組織は LLMを効果的に管理し、LLMのデプロイ、メンテナンス、安全かつ責任ある利用を保証することができる。       https://spotintelligence.com/2024/01/08/llmops/ 

Slide 10

Slide 10 text

Slide 11

Slide 11 text

11 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の難しさ常に同じ予測可能な結果が得られるとは限らない出力を変化させうる変数が多い確率的パラメーター次第でも変動評価指標の定義がケースバイケース一つの正解がない可能性。複数のパターン・要素・観点がある完全一致の検証が必ずしもできるわけではない「唯一絶対の正解」がないことも等式アサーションの限界(UT) 一般的な項目はあれど、より具体はアプリケーション・ユースケース・プロンプトによって千差万別

Slide 12

Slide 12 text

12 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の難しさ一般的な項目はあれど、より具体はユースケース・アプリケーションによって千差万別 ● 有用性（helpfulness） ○ どれだけ有用な回答をしたか（= 課題を解決できたか） ● 事実性（factuality） ○ 正しい回答ができるか（事実でない内容を回答しないか） ● 有害性（harmlessness） ○ 望ましくない回答をする

Slide 13

Slide 13 text

13 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の実態 ● 平均2.3種類のフィードバックを持つテスト実行 ● LLMを使った評価が58% ● 40％近くはカスタム評価を作成 ● Kaggleコンペ(LLM Prompt Recovery) で、ground truthの類似度を見るという Evaluation Metricが採用引用: LangChain State of AI 2023

Slide 14

Slide 14 text

Slide 15

Slide 15 text

15 ©2024 Loglass Inc. ログラスのLLMOpsへの向き合い⽅前提 ● LLM機能・プロンプトは当然育てていく前提。そのためにも改善サイクルを回しやすい状態にしたい現時点の優先事項 ● 継続的・安全にプロンプトチューニングが出来る ● 非エンジニア以外もプロンプトを書いて、機能に影響を与えられる → 例えばドメインエキスパートが自ら実験、お客様毎に適した出力を表現できたら、よりテーラーメードな分析体験を提供できるのでは？ (最終的には自動で改善・パーソナライズが回ってくれるとか )

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 ©2024 Loglass Inc. LLM engineering != prompt engineering 評価・実験も単にEvalsだけでなく、ユースケース選定やキャッシング含めて、より総合的で担保・改善していくもの？ Prompt Tuning 出力のユニークネスを抑える調整 Caching 出力のブレを抑える仕組み Guadlails LLMアウトプットの品質管理 Usecase of LLM 何の問題をどう解くのに使うか Defensive UX 曖昧性・不安定性に対するUX Collect Feedback FB収集と代替指標による監視 UX for AI AI/LLMアプリ向けのUI・UX Monitoring LLMの出力の継続的な監視・記録 Evals 自動テストで一定割合の精度を確認

Slide 18

Slide 18 text

18 ©2024 Loglass Inc. プロンプトエンジニアリング‧チューニングの難しい/考えることプロンプトやモデル変更時のデグレをどう防ぐか何の変数がどう出力に影響したのか？プロンプトやモデル変更時のデグレをどう防ぐかプロンプトやモデル変更時のデグレをどう防ぐかプロンプトのバージョン管理ユースケース毎に変わるコンテキスト情報の用意して実験プロンプトやモデル変更時のデグレをどう防ぐかプロンプトどうやって書くのが良いのかわからない評価基準の言語化・選定プロンプトやモデル変更時のデグレをどう防ぐかユースケース選定・タスク分割広げすぎると品質の担保も大変実行状況のモニタリング

Slide 19

Slide 19 text

19 ©2024 Loglass Inc. プロンプトエンジニアリング‧チューニングの難しい/考えることプロンプトやモデル変更時のデグレをどう防ぐか何の変数がどう出力に影響したのか？プロンプトやモデル変更時のデグレをどう防ぐかプロンプトやモデル変更時のデグレをどう防ぐかプロンプトのバージョン管理ユースケース毎に変わるコンテキスト情報の用意して実験プロンプトやモデル変更時のデグレをどう防ぐかプロンプトどうやって書くのが良いのかわからない評価基準の言語化・選定プロンプトやモデル変更時のデグレをどう防ぐかユースケース選定・タスク分割広げすぎると品質の担保も大変実行状況のモニタリングこの辺が解消されたら、まずはエンジニア以外もプロンプトを書いて、プロダクトに影響を与えられる世界に近づけるかも？

Slide 20

Slide 20 text

20 ©2024 Loglass Inc. どう対応するか‧しようとしているかの例ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 評価基準の言語化・選定ドメインエキスパートの巻き込み 2 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 デグレをどう防ぐか⾃動テストオンライン評価 3 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 実行状況のモニタリングコンテキスト情報の用意モニタリング‧実験管理ツールの導⼊ 4

Slide 21

Slide 21 text

21 ©2024 Loglass Inc. LLMを使うユースケースをコントロール可能な領域に限定 ● 品質担保しやすいケースに絞ることは一つの選択肢 ● e.g.) ○ 正解がある程度明確、もしくは正解がないユースケースで利用 ○ LLM出力をユーザには直接見せない ○ ユーザーがプロンプトを入力しない ● タスク分割や変数を減らして、考慮すべき要素も減るか考える ● 数値計算はContextで事前計算した値を渡して参照のみ ○ 参照した数値が正しいことをチェックするテスト ○ 数値計算結果をアサートするより、テストも書きやすい

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 ©2024 Loglass Inc. ⾃動テスト自動テストがあることで、リファクタリングは安全で効率的なプロセスになる ● アプローチ ○ Example-based tests(例に基づくテスト) ○ Auto-evaluator tests(自動評価テスト) ○ adversarial tests(敵対的テスト) i. 現時点では機能ユースケースやフェーズ、展開状況、ユーザー権限制御等で、この観点でのリスクが低いので強く力を入れられていない引用: Engineering Practices for LLM Application Development

Slide 26

Slide 26 text

26 ©2024 Loglass Inc. ⾃動テスト Auto-evaluator tests ● LLMを使ってLLMをテストする、イメージは単体テスト (結合テストっぽさあるが..) ● アウトプットをアサートするのではなく、アウトプットの特性や特徴をチェックする ● 「品質」の各重要な側面を特性として明確にすることから始まる ○ LangChainにもプリセットの評価基準は存在 ● e.g) ○ The Cover Letter must be short (e.g. no more than 350 words) ○ The Cover Letter must mention the Role ○ The Cover Letter must only contain skills that are present in the input → 上記の特性をドメインエキスパートやお客様ヒアリングを踏まえて固める引用: Engineering Practices for LLM Application Development

Slide 27

Slide 27 text

Slide 28

Slide 28 text

28 ©2024 Loglass Inc. オフライン評価とオンライン評価 ● オフライン評価(事前にデータセットを用いて評価 )だけでは限界がある ○ 常に同じ予測可能な結果が得られるとは限らない ○ 究極はユーザーが見た出力が全て、事前に想定しきれない ● オンライン評価(ユーザーの実利用を元に評価)・代替指標を組み合わせる ● 代替指標 ○ 回答精度を直接評価しない。影響を与えると考えられるビジネス指標・ KPIを参照 ○ e.g.) LLM出力によるサジェストを受け入れた率 ● e.g.) Github Copillot i. Acceptance Rate (どの程度の頻度で受け入れるか ) ii. Retension Rate (どの程度の頻度と範囲で編集するか ) iii. The architecture of today’s LLM applications

Slide 29

Slide 29 text

29 ©2024 Loglass Inc. オフライン評価とオンライン評価オンライン評価の今 ● 正直、運用が回ってはいない、整備しようとしてる段階 ○ → 代替指標の選定は何にするか？ ● ユーザーFB機構を作って、ダッシュボードで見れるようにはしている ○ しかしリリースしたばかりでもある上に、誰もがフィードバックを送ってくれるとは期待できない ○ 我が身を振り返っても、フィードバックボタンを押さない ● 現機能フェーズ(β版) && BtoB SaaSならではの泥臭く直接ヒアリングで一定回収する

Slide 30

Slide 30 text

30 ©2024 Loglass Inc. モニタリング‧実験管理ツールの導⼊ LangSmithを入れてる (LangSmith: LangChain社が運営しているLLMOpsツール) ● お客様データはセンシティブなので、今は開発環境だけ ● 細かい点はさておき、モニタリングとプレイグラウンドだけでも全然嬉しい ● リクエスト履歴を元にプレイグラウンドで試せるのは便利 ○ Evaluation・データセットでテストも書ける、Hubでプロンプト管理もできる ● LangSmith自体についてのおすすめ記事 ○ LangChain社LLMOpsツール「LangSmith」を触ってみた（詳細解説つき） ○ LangSmith で始める LLMOps

Slide 31

Slide 31 text

31 ©2024 Loglass Inc. まとめ ● プロンプトリファクタリングと誰でもプロンプトが書けることに今はフォーカス ● 以下は絶賛取り組んでる最中 ○ LangSmithのEvaluation・データセット機能の活用 ○ プロンプトの変更履歴管理 i. 現状はリポジトリに含めて、自前で PrompTemplate機構を書いてる ii. GithubとLangSmithでわかるといえばわかる ● 初期は泥臭く人間が介在するんだろうと思っている ○ 人間が介在して、アドホックに i. モニタリング・実験管理ツールがあれば色々出来る ○ 評価指標の確立・自動テストの活用 ○ データを元にサイクルを回せるように