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
「見せ球」「作って終わり」のLLM機能卒業のために
Search
ryopenguin
April 23, 2024
Technology
0
380
「見せ球」「作って終わり」のLLM機能卒業のために
@ LLM Night〜本番運用して気づいた課題と学び〜
https://yojo.connpass.com/event/315357/
ryopenguin
April 23, 2024
Tweet
Share
More Decks by ryopenguin
See All by ryopenguin
「見せ球」「作って終わり」LLM機能卒業のために
ryokaneoka0406
0
36
LLMからはじめる、 プロダクトへのAI導入
ryokaneoka0406
0
130
ゼロイチプロダクトのプロダクトマネジメント
ryokaneoka0406
0
390
SaaSのアップセルプロダクトにおけるブレない軸
ryokaneoka0406
1
2.1k
チームのコンテキスト理解を高める 朝会/夕会コンテンツ
ryokaneoka0406
4
1.5k
Other Decks in Technology
See All in Technology
映像・音声伝送システム
jtes
0
190
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
240
【shownet.conf_】3Dアプローチで守るセキュリティ
shownet
PRO
0
260
Oracle Cloud Infrastructure:2024年9月度サービス・アップデート
oracle4engineer
PRO
0
330
Consoles, printk, Nested-NMIs_ Oh my!
ennael
PRO
0
150
REST API Design Pitfalls
victorrentea
1
500
たった一人で始めた音楽制作が気がついたら会社公認の部活動になっていた話〜組織の垣根を超えるコラボレーションを実現するには〜 / On-KAG-bu
piyonakajima
0
100
XPを始める新人に伝えたい近道の鍵
nakasho
1
200
KDD2024参加報告
cyberagentdevelopers
PRO
0
180
LINEヤフー新卒採用 コーディングテスト解説 アルゴリズム問題編
lycorp_recruit_jp
0
12k
AI時代のアジャイル開発(XP祭り2024版) / Agile Development in the AI Era in XPJUG
takaking22
13
3.4k
Oracle GoldenGate 23ai 導入Tips
oracle4engineer
PRO
1
190
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
A better future with KSS
kneath
235
17k
Fashionably flexible responsive web design (full day workshop)
malarkey
402
65k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
4 Signs Your Business is Dying
shpigford
180
21k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
26
4k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.3k
Writing Fast Ruby
sferik
624
60k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
The Mythical Team-Month
searls
218
43k
Ruby is Unlike a Banana
tanoku
96
11k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
Transcript
「見せ球」「作って終わり」のLLM機 能卒業のために 2024.04.24 LLM Night〜本番運用して気づいた課題と学び〜 Ryo Kaneoka SmartHR Product Manager
• リリース前にすること ◦ LLMを交えた機能は、深く課題と限界を理解して、動くものを早く作り切る • リリース後にすること ◦ フィードバックは強めに取りに行く • この2つができれば、社内外に上手く訴求してリリースし、きちんと
ユーザー課題を解決した上でビジネスになるように LLMを使えるはず 今日話すこと これだけは覚えて帰ってほしい
• 開発の詳細 ◦ プロンプトのノウハウや評価パイプラインの話は情報が増えてきたので、今 日は特に現場感あるお話にフォーカスして話します! 今日あまり話さないこと
Ryo Keneoka(@ryopenguin) • プロダクトマネージャー • SmartHRには2020年10月に入社 • 「従業員サーベイ」「スキル管理」の PM •
LLM利用のタスクフォース、AIの R&Dチームを立ち上げ 自己紹介
アジェンダ • はじめに - SmartHRとLLMについて • よくある課題とリリース前後で2つの提案 • リリース前:深く課題と限界を理解して、動くものを早く作り切る •
リリース後:フィードバックは強めに取りに行く • 結論
はじめに - SmartHRとLLMについて
SmartHRの主な機能
SmartHRの主な機能
オプションの従業員サーベイで「要約AI」機能をリリース
部門横断でLLMハッカソン実施
AIポリシーの策定、AI研究室の立ち上げ AI研究室以後、 各プロダクトでのLLM活用を模索
よくある課題と リリース前後で2つの提案
LLMのプロダクト開発、こんな課題はありませんか? 社内PoCでとどまる フィードバックが 集まらない 最初は話題にはなるけど 実際には使われない
SmartHRでも顕在化 サーベイ要約機能は出せたが、 その他の機能がなかなか前に進まない ユーザーには使われていても、 フィードバックが十分ではない
「見せ球」「作って終わり」にしない何かが必要 LLM機能のローンチは検証や開発を含め高コストなもの ユーザーとビジネスに意味がないともったいなすぎる
リリース前後での2つの提案 • リリース前にすること ◦ LLMを交えた機能は、深く課題と限界を理解して、動くものを早く作り切る • リリース後にすること ◦ フィードバックは強めに取りに行く
リリース前: 深く課題と限界を理解して、 動くものを早く作り切る
リリース前:深く課題と限界を理解して、動くものを早く作り切る ユーザーのコストが 想像できるまで課題を 理解する LLMの速度・価格・知性の 限界を把握しておく 動くものを早く作る このフェーズで紹介すること https://www.vellum.ai/llm-leaderboard https://www.productboard.com/agile-product-management-tool/
リリース前(1/3)ユーザーのコストが想像できるまで課題を理解する LLM利用機能を考える前に 人的コストが想像できるレベルにユーザー解像度を上げるのが実は近道 要望蓄積SaaSや ユーザーインタビューを常に行えるようにする 要望を集める仕組みを整備する ユーザー課題を解像度高く把握する 「サーベイ」のユーザーが 数百人以上の自由 記述回答を全て読んでいる
ことを知っていた https://www.productboard.com/agile-product-management-tool/
リリース前(2/3)LLMの価格・知性・速度の限界を把握しておく ユースケース、ビジネスモデル、ユーザーペルソナによって取れる選択肢は変わってくる リクエストや扱うトークンが 多いとGPT-4では厳しい タスクによっては、 GPT-3.5でなんとかなるケースも (例:RAG、要約) 利用者が従業員か管理者かで 待てる時間は変わってくる 価格
知性 速度 https://www.vellum.ai/llm-leaderboard https://azure.microsoft.com/ja-jp/prod ucts/ai-services/openai-service
リリース前(3/3)動くものを早く作る 未知の技術を使ったソリューションは動くものがないと価値や制約がわからない ここはプロダクトアウトに、動くプロトタイプを作ってしまう
「深く課題と限界を理解して、動くものを早く作り切る」効果 ROIの見込みとLLM機能である必然性があってはじめて上手くいく これらがないとどこかで頓挫するし、ユーザーにも訴求しにくい ユーザーのコスト、使うべき LLMと 原価が把握でき、 ROIを推測できる 投資余地、ROIを推測できる ソリューションが適切か評価できる プロトタイピングで本当に
ユーザーの課題を解決できるかも推測できる
「要約AI」機能は3つのアクションが取れたので使われたのかも
リリース後: フィードバックは強めに取りに行く
リリース後:ユーザーフィードバックは強めに取りに行く このフェーズで紹介すること タスク完了時にすぐフィードバックを依頼する ユーザーと一緒に操作する
フィードバック収集は、弊社でもうまくできていない部分です 🙏 現時点では後述のように強めに取りに行くしかないと思っているが …パネルディスカッションで議論 させてください! disclaimer:フィードバック収集については…
タスクによっては、機能が役に立ったかがわからない 人間が実施していたタスクを LLMに置き換えると「本当に役に立ったか」がわからない プロンプト含めて、本来は改善したい
Good/Badボタンは押されない Good/Badボタンを基本ユーザーは押さない 「要約AI」はアンケートへのリンクも用意したが、ほぼ入力されなかった
リリース後(1/2)タスク完了時にすぐフィードバックを依頼する タスク完了時に依頼したり、出力の ABテストをするのは一定有効そう( ChatGPTに学ぶ)
リリース後(2/2)ユーザーと一緒に操作する ユーザビリティテストのように、ユーザーと一緒に画面を見ながら操作するのも有効かも
「フィードバックを強めに取りに行く」効果 ソフトウェアプロダクトはリリースして終わりでないのは LLMを使っても一緒 特にプロンプトのブラッシュアップは永遠の課題 ユーザーの実データで本当に意図した挙動になっ ているか把握し、適応する ユーザーの現場に適応できる モデル仕様の変更など、異常に対応できる APIプロバイダの仕様変更でハルシネーション してないかなど、チェックは常にしたい
https://openai.com/blog/new-embedding-models-and-api-updates
フィードバック収集は、弊社でもうまくできていない部分です 🙏 現時点では前述のように強めに取りに行くしかないと思っているが …パネルディスカッションで議論 させてください! disclaimer(再掲):フィードバック収集については…
結論
• リリース前にすること ◦ LLMを交えた機能は、深く課題と限界を理解して、動くものを早く作り切る • リリース後にすること ◦ フィードバックは強めに取りに行く • この2つができれば、社内外に上手く訴求してリリースし、きちんと
ユーザー課題を解決した上でビジネスになるように LLMを使えるはず 今日の結論 これだけは覚えて帰ってほしい
ご静聴ありがとうございました!