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
63
「見せ球」「作って終わり」LLM機能卒業のために
@ LLM Night〜本番運用して気づいた課題と学び〜
2024.04.23
https://yojo.connpass.com/event/315357/
ryopenguin
April 23, 2024
Tweet
Share
More Decks by ryopenguin
See All by ryopenguin
「見せ球」「作って終わり」のLLM機能卒業のために
ryokaneoka0406
0
710
LLMからはじめる、 プロダクトへのAI導入
ryokaneoka0406
0
270
ゼロイチプロダクトのプロダクトマネジメント
ryokaneoka0406
0
490
SaaSのアップセルプロダクトにおけるブレない軸
ryokaneoka0406
1
2.2k
チームのコンテキスト理解を高める 朝会/夕会コンテンツ
ryokaneoka0406
4
1.7k
Other Decks in Technology
See All in Technology
Pure Goで体験するWasmの未来
askua
1
160
AI×Data×SaaS×Operation
sansantech
PRO
0
110
インサイト情報からどこまで自動化できるか試してみた
takas0522
0
130
DEFCON CHV CTF 2025 Write-up
bata_24
0
200
OCI Network Firewall 概要
oracle4engineer
PRO
1
7.7k
stupid jj tricks
indirect
0
7.6k
#普通の文系サラリーマンチャレンジ 自分でアプリ開発と電子工作を続けたら人生が変わった
tatsuya1970
0
860
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
170
PLaMoの事後学習を支える技術 / PFN LLMセミナー
pfn
PRO
9
3.5k
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
kinosuke01
4
3.6k
about #74462 go/token#FileSet
tomtwinkle
1
260
「技術負債にならない・間違えない」 権限管理の設計と実装
naro143
33
10k
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
71
11k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Fireside Chat
paigeccino
40
3.7k
4 Signs Your Business is Dying
shpigford
185
22k
GitHub's CSS Performance
jonrohan
1032
460k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
840
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Unsuck your backbone
ammeep
671
58k
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を使えるはず 今日の結論 これだけは覚えて帰ってほしい
ご静聴ありがとうございました!