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

Transcript

1. 1 ©2024 Loglass Inc. ログラスの継続的なプロンプト改善のための LLMOpsの今 2024.2.29 r.kagaya LLM Night 〜LLM Ops編〜 #pharmax_tech_collabo
2. 2 新卒で入社したヤフー株式会社で、 ID連携システムの保守・運 用開発を経験したのち、 ID連携システムのフルリプレイス PJに 従事。 その後、2022年に株式会社ログラスに入社。 ソフトウェアエンジニアとしてマスタ管理 機能等の開発、イネー ブルメントチームの一員として横断課題の解決に取り組んだの ち、現在は生成AI/LLMチームの立ち上げを行う。 X: @ry0_kaga 株式会社ログラス r-kagaya
3. 3 ©2024 Loglass Inc. ログラスについて（5秒） 企業価値を向上する
 経営管理クラウド

4. 4 ©2024 Loglass Inc. 4 次世代型 経営管理クラウド
5. 5 ©2024 Loglass Inc. 経営企画は「企業価値の向上」をミッションに、企業経営にまつわるあらゆる業務を担っている
6. 6 ©2024 Loglass Inc. ログラス社のLLMへの取り組み 機能開発から業務改善まで、生成 AI/LLMで
 
 ①プロダクトビジョン実現のための技術検証 
 ②業務プロセスへの AIの組み込み
 ③制度や仕組みの整備とスキルや知見の共有 
 
 
 

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

8. 8 ©2024 Loglass Inc. 前提 • LLMモデルそのもの評価ではなく、LLMアプリケーションにおける話
 

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

10. 10 ©2024 Loglass Inc. 要するにやりたいこと -> 継続的にLLMアプリケーションを育てていく そのために Evaluating LLMs Tracking LLMs Monitoring LLMs LLMの出力をどの様 に評価するか レスポンスタイム、 トークン数、コスト、 エラー率から、独自 の評価指標のトラッ キング 継続・定期的に観 察、記録する
11. 11 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の難しさ 常に同じ予測可能な結果が得られるとは限らない 出力を変化させうる変数が多い 確率的 パラメーター次第でも変 動 評価指標の定義が ケースバイケース 一つの正解がない可能性。複数のパターン・要素・観点がある 完全一致の検証が必ずしもできるわけではない 「唯一絶対の正解」が ないことも 等式アサーション の限界(UT) 一般的な項目はあれど、より具体はアプリケーション・ユースケース・ プロンプトによって千差万別
12. 12 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の難しさ 一般的な項目はあれど、より具体はユースケース・アプリケーションによって千差万別 • 有用性（helpfulness） ◦ どれだけ有用な回答をしたか（= 課題を解決できたか） • 事実性（factuality） ◦ 正しい回答ができるか（事実でない内容を回答しないか） • 有害性（harmlessness） ◦ 望ましくない回答をする
13. 13 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の実態 • 平均2.3種類のフィードバックを持つテス ト実行 • LLMを使った評価が58% • 40％近くはカスタム評価を作成 • Kaggleコンペ(LLM Prompt Recovery) で、ground truthの類似度を見るという Evaluation Metricが採用 引用: LangChain State of AI 2023
14. 14 ©2024 Loglass Inc. LLMアプリケーションのテスト‧評価の実態 • 正しさ、有用性の評価が高い ◦ ただ定義も難しい • 評価技法としての完全一致の順位が低 い 引用: LangChain State of AI 2023
15. 15 ©2024 Loglass Inc. ログラスのLLMOpsへの向き合い⽅ 前提 • LLM機能・プロンプトは当然育てていく前提。そのためにも改善サイクルを回しやすい状態にした い 現時点の優先事項 • 継続的・安全にプロンプトチューニングが出来る • 非エンジニア以外もプロンプトを書いて、機能に影響を与えられる → 例えばドメインエキスパートが自ら実験、お客様毎に適した出力を表現できたら、よりテーラーメード な分析体験を提供できるのでは？ (最終的には自動で改善・パーソナライズが回ってくれるとか )
16. 16 ©2024 Loglass Inc. LLM engineering != prompt engineering プロンプトエンジニアリングは、LLMアプリケーションを開発し、本番環境に導入するために必要なこと のほんの一部
17. 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 自動テストで一定割合の精度を確認
18. 18 ©2024 Loglass Inc. プロンプトエンジニアリング‧チューニングの難しい/考えること プロンプトやモデル変更 時のデグレをどう防ぐか 何の変数がどう出力に 影響したのか？ プロンプトやモデル変更 時のデグレをどう防ぐか プロンプトやモデル変更 時のデグレをどう防ぐか プロンプトのバージョン 管理 ユースケース毎に変わ るコンテキスト情報の用 意して実験 プロンプトやモデル変更 時のデグレをどう防ぐか プロンプトどうやって書く のが良いのかわからな い 評価基準の言語化・選 定 プロンプトやモデル変更 時のデグレをどう防ぐか ユースケース選定・タス ク分割 広げすぎると品質の担 保も大変 実行状況のモニタリング
19. 19 ©2024 Loglass Inc. プロンプトエンジニアリング‧チューニングの難しい/考えること プロンプトやモデル変更 時のデグレをどう防ぐか 何の変数がどう出力に 影響したのか？ プロンプトやモデル変更 時のデグレをどう防ぐか プロンプトやモデル変更 時のデグレをどう防ぐか プロンプトのバージョン 管理 ユースケース毎に変わ るコンテキスト情報の用 意して実験 プロンプトやモデル変更 時のデグレをどう防ぐか プロンプトどうやって書く のが良いのかわからな い 評価基準の言語化・選 定 プロンプトやモデル変更 時のデグレをどう防ぐか ユースケース選定・タス ク分割 広げすぎると品質の担 保も大変 実行状況のモニタリング この辺が解消されたら、まずはエンジニア以外も プロンプトを書いて、プロダクトに影響を与えられる 世界に近づけるかも？
20. 20 ©2024 Loglass Inc. どう対応するか‧しようとしているかの例 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 評価基準の言語化・選定 ドメインエキスパートの巻き込み 2 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 デグレをどう防ぐか ⾃動テスト オンライン評価 3 ユースケース選定 LLMを利⽤するユースケースをコントロール可能な領域に限定 1 実行状況のモニタリング コンテキスト情報の用意 モニタリング‧実験管理ツールの導⼊ 4
21. 21 ©2024 Loglass Inc. LLMを使うユースケースをコントロール可能な領域に限定 • 品質担保しやすいケースに絞ることは一つの選択肢 • e.g.) ◦ 正解がある程度明確、もしくは正解がないユースケースで利用 ◦ LLM出力をユーザには直接見せない ◦ ユーザーがプロンプトを入力しない • タスク分割や変数を減らして、考慮すべき要素も減るか考える • 数値計算はContextで事前計算した値を渡して参照のみ ◦ 参照した数値が正しいことをチェックするテスト ◦ 数値計算結果をアサートするより、テストも書きやすい
22. 22 ©2024 Loglass Inc. LLMを使うユースケースをコントロール可能な領域に限定 • LLMだけで生成していない ◦ LLMの読解力や生成力をポイントで 活用 • Compound AI System ◦ 非AI/LLMのコンポーネントも合わせ て総合的に良いシステムを作る
23. 23 ©2024 Loglass Inc. ドメインエキスパートの巻き込み ドメインエキスパートがカジュアルに相談可能な定例を開催してくれたり、 PdM/デザイナー/エンジニア が直接お客様にヒアリングする風土に支えられている
24. 24 ©2024 Loglass Inc. ドメインエキスパートの巻き込み プロンプトを書きたいユースケースにおいて、何が・なぜ良い /悪いのかを言語化し、プロンプトで再現で きるようにするプロセス 理想とする出力や正解例の検討は社内のドメインエキスパートのサポートがあってこそ 期待するア ウトプット/ 特性を定義 する 合致するプ ロンプトを書 く 継続的に評 価・監視
25. 25 ©2024 Loglass Inc. ⾃動テスト 自動テストがあることで、リファクタリングは安全で効率的なプロセスになる • アプローチ ◦ Example-based tests(例に基づくテスト) ◦ Auto-evaluator tests(自動評価テスト) ◦ adversarial tests(敵対的テスト) i. 現時点では機能ユースケースやフェーズ、展開状況、ユーザー権限制御等で、この観 点でのリスクが低いので強く力を入れられていない 引用: Engineering Practices for LLM Application Development
26. 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
27. 27 ©2024 Loglass Inc. ⾃動テスト 最低限守りたい特性や仕様を定義した後、プロンプト変更をキーに CI • LangChain / LangSmith ◦ LangChainにもプリセットの評価基準が存在 ◦ LangSmithからデータセットも準備可能 • promptfoo ◦ LLM出力品質を評価するためのCLI
28. 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
29. 29 ©2024 Loglass Inc. オフライン評価とオンライン評価 オンライン評価の今 • 正直、運用が回ってはいない、整備しようとしてる段階 ◦ → 代替指標の選定は何にするか？ • ユーザーFB機構を作って、ダッシュボードで見れるようにはしている ◦ しかしリリースしたばかりでもある上に、誰もがフィードバックを送ってくれるとは期待できな い ◦ 我が身を振り返っても、フィードバックボタンを押さない • 現機能フェーズ(β版) && BtoB SaaSならではの泥臭く直接ヒアリングで一定回収する
30. 30 ©2024 Loglass Inc. モニタリング‧実験管理ツールの導⼊ LangSmithを入れてる (LangSmith: LangChain社が運営しているLLMOpsツール) • お客様データはセンシティブなので、今は開発環境だけ • 細かい点はさておき、モニタリングとプレイグラウンドだけでも全然嬉しい • リクエスト履歴を元にプレイグラウンドで試せるのは便利 ◦ Evaluation・データセットでテストも書ける、Hubでプロンプト管理もできる • LangSmith自体についてのおすすめ記事 ◦ LangChain社LLMOpsツール「LangSmith」を触ってみた（詳細解説つき） ◦ LangSmith で始める LLMOps
31. 31 ©2024 Loglass Inc. まとめ • プロンプトリファクタリングと誰でもプロンプトが書けることに今はフォーカス • 以下は絶賛取り組んでる最中 ◦ LangSmithのEvaluation・データセット機能の活用 ◦ プロンプトの変更履歴管理 i. 現状はリポジトリに含めて、自前で PrompTemplate機構を書いてる ii. GithubとLangSmithでわかるといえばわかる • 初期は泥臭く人間が介在するんだろうと思っている ◦ 人間が介在して、アドホックに i. モニタリング・実験管理ツールがあれば色々出来る ◦ 評価指標の確立・自動テストの活用 ◦ データを元にサイクルを回せるように
32. 32 ©2024 Loglass Inc. 蛇⾜ • 評価指標や代替指標等が整ってきたら、自動生成もチャレンジできそう？したい • e.g.) ◦ プロンプト候補を大量生成し、オフライン評価で絞り込んだ上で、オンライン評価で 決定する • Eladlev/AutoPromptは近そう