Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ペアーズでの、Langfuseを中心とした評価ドリブンなリリースサイクルのご紹介
Search
fukubaka0825
January 28, 2025
Programming
2
400
ペアーズでの、Langfuseを中心とした評価ドリブンなリリースサイクルのご紹介
Langfuse Night #1 での登壇資料です。
https://connpass.com/event/340099/
fukubaka0825
January 28, 2025
Tweet
Share
More Decks by fukubaka0825
See All by fukubaka0825
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
2.8k
SRE NEXT 2022に学ぶこれからのSREキャリア
fukubaka0825
2
810
Steps toward self-service operations in eureka
fukubaka0825
1
8k
SREの探求のすゝめ
fukubaka0825
5
7.6k
Three principles to design your slackbot to be loved in your team
fukubaka0825
0
4.1k
Goでinteractive message slack botを作ってみた
fukubaka0825
0
300
Other Decks in Programming
See All in Programming
変化の激しい時代における、こだわりのないエンジニアの強さ
satoshi256kbyte
1
1k
JAWS Days 2025のインフラ
komakichi
1
410
RailsでCQRS/ESをやってみたきづき
suzukimar
2
1.3k
SREチームのタスク優先度と向き合う Road to SRE NEXT@札幌
nealle
0
120
読まないコードリーディング術
hisaju
1
180
Google Cloudとo11yで実現するアプリケーション開発者主体のDB改善
nnaka2992
1
200
신입 안드로이드 개발자의 AI 스타트업 생존기 (+ Native C++ Code를 Android에서 사용해보기)
dygames
0
440
コードジェネレーターで 効率的な開発をする / Efficient development with code generators
linyows
0
160
JavaOne 2025: Advancing Java Profiling
jbachorik
1
180
「その気にさせる」エンジニアが 最強のリーダーになる理由
gimupop
3
400
イベントソーシングによってインピーダンスミスマッチから解放された話
tkawae
1
140
CloudRun, Spanner に対する負荷試験の反省と オブザーバビリティによるアプローチ
oyasumipants
1
250
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Music & Morning Musume
bryan
46
6.4k
Designing Experiences People Love
moore
140
23k
Typedesign – Prime Four
hannesfritz
41
2.6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
590
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
How to train your dragon (web standard)
notwaldorf
91
5.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
101
18k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Transcript
ペアーズでの、Langfuseを中⼼ とした評価ドリブンなリリース サイクルのご紹介 2025/01/28 Langfuse Night #1
About Me Nari | Takashi Narikawa(@fukubaka0825) • 株式会社エウレカ ◦ 2020年に⼊社
▪ SRE Team -> AI Team ◦ MLOps Engineer ◦ 筋トレ、⿇雀、サウナが好き
今⽇のお話しする範囲について • 昨今、注⽬を集めるAIエージェントの話は出てきません • シンプルな⽣成AIモデル API出⼒、ワークフローやRAGアプリケーションの評価 の話がメインです ◦ マルチモーダルの話もでてきません ◦
より複雑なAIエージェント評価でも、単体コンポーネントの評価が⼤前提 で、追加で実⾏経路評価などの観点があるだけ • 上記の範囲で、「ペアーズでの、Langfuseを中⼼とした評価ドリブンなリリース サイクル」を5分 LTでお話しできる範囲でお話しします ◦ 詳しく知りたい⽅は、2024 Pairs Advent Calenderに記載した以下の記事も ご参照 ◦ ペアーズにおける評価ドリブンなリリースサイクル:Langfuseをフル活⽤ したLLMOps基盤
Agenda 1. ペアーズにおけるLLMアプリケーション運⽤課題 2. ペアーズのLLMOps基盤のアーキテクチャ 3. LLMOpsツールとしてのLangfuseの採⽤理由 4. 評価ドリブンなリリースサイクルの全体像 5.
オンライン評価プロセス 6. オフライン評価プロセス 7. 導⼊ステップ 8. 評価データセットの育てはじめ⽅ 9. まとめ
ペアーズにおけるLLMアプリケーション運⽤課題 • LLM APIを活⽤したアプリケーションの運⽤では、以下のような課題が顕著 ◦ 出⼒の評価が難しい ◦ 従来のMLOps⼿法がそのままでは通じない ◦ モデル∕プロンプトの出⼒精度低下(デグレ)の検知の重要性
• 弊社ではLLMアプリケーションを開発運⽤しているのがAI Teamだけでなく、 SRE∕Platform Teamも開発者の⽣産性向上のためのLLM活⽤を戦略の⼀部とし て実施しており、全社的に使えるこういった課題の解決を⽀援する基盤を必要と していた
ペアーズのLLMOps基盤のアーキテクチャ
LLMOpsツールとしてのLangfuseの採⽤理由 • LLMOpsに必要な機能を網羅 ◦ LangfuseはSelf-hostするパターンでも、ログ‧トレース管理、プロンプト マネジメント、評価データセット、実験管理、カスタムスコアによる評価 など、LLMOpsに必要な機能を網羅的に提供 • Self-hostしやすさ ◦
LLMOps系のSaaSソリューションは、⼤規模トラフィックのログ‧トレー スデータ量によるコストが課題で、弊社規模のtoCサービスだと採⽤が難し い ◦ LangfuseはOSSとして提供され、Self-hostすることが可能であり、しかも helm chartまで提供されているので、弊社のメインホスティング先である AWS EKSを⽤いて構築できることも⼤きかった
評価ドリブンなリリースサイクルの全体像
オンライン評価プロセス
オフライン評価プロセス ※LLMアプリケーション統合実験もほぼ同様のフロー
導⼊ステップ
評価データセットの育て始め⽅ • 1. 初期データセット作成 ◦ 10~20問程度からスタートでOK ◦ 例えばシンプルなRAGアプリケーションなどであれば、Ragasで⽣成したシ ングル/マルチホップの問答ケース や他LLMで⽣成したケースの採⽤も検討
◦ ユーザー、ドメインエキスパート評価付きオンラインログトレースがすで にある場合はそちらも使⽤ ▪ 正例/負例(検索不備、⽣成不備、プロンプト命令違反) • 2. オンラインログトレースから追加し継続的に育てていく ◦ 情報検索できていない、不完全回答などを洗い出してケース追加 ◦ このプロセスを通して、評価基準の⾔語化、プロンプト改善にもつなげる
まとめ • LLMアプリケーションの運⽤は従来のMLOpsの⼿法が通じず、かつ出⼒の評価が 難しいことなどが起因して、⾮常に難しい • 上記の課題を解決するために、Langfuseを中枢に据えたLLMOps基盤を⽤いて、 オンライン評価とオフライン評価でリリースを挟み込んだ評価ドリブンなリリー スサイクルを回していくのがおすすめ • 上記を実践するために
◦ まずはアプリケーションのログ‧トレースを保存 ◦ 次にプロンプトマネジメント導⼊と、評価データセット作りを10件から ◦ そこからプロンプト実験と、LLM-as-a-JudgeなどのLLM Evaluatorの仕組 みを、評価基準など不完全で良いので導⼊してみる ◦ これらをまずは実践することで、評価ドリブンなリリースライフサイクル が、評価データセットと評価基準を育てながら回せるようになる
We’re hiring! ペアーズではエンジニアを積極採⽤中! カジュアル⾯談もお待ちしております! (X: @fukubaka0825)
None