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
59
「見せ球」「作って終わり」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
690
LLMからはじめる、 プロダクトへのAI導入
ryokaneoka0406
0
260
ゼロイチプロダクトのプロダクトマネジメント
ryokaneoka0406
0
490
SaaSのアップセルプロダクトにおけるブレない軸
ryokaneoka0406
1
2.2k
チームのコンテキスト理解を高める 朝会/夕会コンテンツ
ryokaneoka0406
4
1.6k
Other Decks in Technology
See All in Technology
Goss: New Production-Ready Go Binding for Faiss #coefl_go_jp
bengo4com
0
1.1k
Claude Code x Androidアプリ 開発
kgmyshin
1
590
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
6
620
Effective Match Types - Scala Days 2025
bishabosha
1
110
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
2
20k
microCMS 最新リリース情報(microCMS Meetup 2025)
microcms
0
110
小さなチーム 大きな仕事 - 個人開発でAIをフル活用する
himaratsu
0
120
実践アプリケーション設計 ①データモデルとドメインモデル
recruitengineers
PRO
3
260
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.6k
KiroでGameDay開催してみよう(準備編)
yuuuuuuu168
1
130
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
220
Product Management Conference -AI時代に進化するPdM-
kojima111
0
220
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Statistics for Hackers
jakevdp
799
220k
Rails Girls Zürich Keynote
gr2m
95
14k
Thoughts on Productivity
jonyablonski
69
4.8k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
RailsConf 2023
tenderlove
30
1.2k
Agile that works and the tools we love
rasmusluckow
329
21k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Navigating Team Friction
lara
189
15k
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を使えるはず 今日の結論 これだけは覚えて帰ってほしい
ご静聴ありがとうございました!