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
670
「見せ球」「作って終わり」の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
57
LLMからはじめる、 プロダクトへのAI導入
ryokaneoka0406
0
250
ゼロイチプロダクトのプロダクトマネジメント
ryokaneoka0406
0
480
SaaSのアップセルプロダクトにおけるブレない軸
ryokaneoka0406
1
2.2k
チームのコンテキスト理解を高める 朝会/夕会コンテンツ
ryokaneoka0406
4
1.6k
Other Decks in Technology
See All in Technology
メモ整理が苦手な者による頑張らないObsidian活用術
optim
1
160
【Λ(らむだ)】最近のアプデ情報 / RPALT20250729
lambda
0
160
人に寄り添うAIエージェントとアーキテクチャ #BetAIDay
layerx
PRO
0
100
「AI駆動開発」のボトルネック『言語化』を効率化するには
taniiicom
1
230
From Live Coding to Vibe Coding with Firebase Studio
firebasethailand
1
330
alecthomas/kong はいいぞ
fujiwara3
6
1.2k
Gemini in Android Studio - Google I/O Bangkok '25
akexorcist
0
100
마라톤 끝의 단거리 스퍼트: 2025년의 AI
inureyes
PRO
1
140
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
170
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
920
CSPヘッダー導入で実現するWebサイトの多層防御:今すぐ試せる設定例と運用知見
llamakko
1
280
AI人生苦節10年で会得したAIがやること_人間がやること.pdf
shibuiwilliam
1
230
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Being A Developer After 40
akosma
90
590k
Typedesign – Prime Four
hannesfritz
42
2.7k
Optimizing for Happiness
mojombo
379
70k
4 Signs Your Business is Dying
shpigford
184
22k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Balancing Empowerment & Direction
lara
1
510
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
GraphQLとの向き合い方2022年版
quramy
49
14k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
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を使えるはず 今日の結論 これだけは覚えて帰ってほしい
ご静聴ありがとうございました!