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
550
「見せ球」「作って終わり」の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
42
LLMからはじめる、 プロダクトへのAI導入
ryokaneoka0406
0
200
ゼロイチプロダクトのプロダクトマネジメント
ryokaneoka0406
0
440
SaaSのアップセルプロダクトにおけるブレない軸
ryokaneoka0406
1
2.1k
チームのコンテキスト理解を高める 朝会/夕会コンテンツ
ryokaneoka0406
4
1.6k
Other Decks in Technology
See All in Technology
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
2
480
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
12
4.3k
E2Eテスト自動化入門
devops_vtj
1
100
Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ
j2yano
0
140
急成長する企業で作った、エンジニアが輝ける制度/ 20250227 Rinto Ikenoue
shift_evolve
0
180
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
280
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
200
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
9
1.8k
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
140
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
220
クラウド食堂とは?
hiyanger
0
120
データモデルYANGの処理系を再発明した話
tjmtrhs
0
140
Featured
See All Featured
KATA
mclloyd
29
14k
The Cost Of JavaScript in 2023
addyosmani
47
7.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
51k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Practical Orchestrator
shlominoach
186
10k
Git: the NoSQL Database
bkeepers
PRO
428
65k
Scaling GitHub
holman
459
140k
How GitHub (no longer) Works
holman
314
140k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
650
Producing Creativity
orderedlist
PRO
344
40k
Building Your Own Lightsaber
phodgson
104
6.2k
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を使えるはず 今日の結論 これだけは覚えて帰ってほしい
ご静聴ありがとうございました!