「見せ球」「作って終わり」LLM機能卒業のために

@ LLM Night〜本番運用して気づいた課題と学び〜
2024.04.23
https://yojo.connpass.com/event/315357/

Transcript

1. 「見せ球」「作って終わり」のLLM機 能卒業のために 2024.04.24 LLM Night〜本番運用して気づいた課題と学び〜 Ryo Kaneoka SmartHR Product Manager
2. • リリース前にすること ◦ LLMを交えた機能は、深く課題と限界を理解して、動くものを早く作り切る • リリース後にすること ◦ フィードバックは強めに取りに行く • この2つができれば、社内外に上手く訴求してリリースし、きちんと ユーザー課題を解決した上でビジネスになるように LLMを使えるはず 今日話すこと　これだけは覚えて帰ってほしい
3. • 開発の詳細 ◦ プロンプトのノウハウや評価パイプラインの話は情報が増えてきたので、今 日は特に現場感あるお話にフォーカスして話します！ 今日あまり話さないこと
4. Ryo Keneoka（@ryopenguin） • プロダクトマネージャー • SmartHRには2020年10月に入社 • 「従業員サーベイ」「スキル管理」の PM • LLM利用のタスクフォース、AIの R&Dチームを立ち上げ 自己紹介
5. アジェンダ • はじめに - SmartHRとLLMについて • よくある課題とリリース前後で2つの提案 • リリース前：深く課題と限界を理解して、動くものを早く作り切る • リリース後：フィードバックは強めに取りに行く • 結論
6. はじめに - SmartHRとLLMについて
7. SmartHRの主な機能
8. SmartHRの主な機能
9. オプションの従業員サーベイで「要約AI」機能をリリース
10. 部門横断でLLMハッカソン実施
11. AIポリシーの策定、AI研究室の立ち上げ AI研究室以後、 各プロダクトでのLLM活用を模索
12. よくある課題と リリース前後で2つの提案
13. LLMのプロダクト開発、こんな課題はありませんか？ 社内PoCでとどまる フィードバックが 集まらない 最初は話題にはなるけど 実際には使われない
14. SmartHRでも顕在化 サーベイ要約機能は出せたが、 その他の機能がなかなか前に進まない　 ユーザーには使われていても、 フィードバックが十分ではない
15. 「見せ球」「作って終わり」にしない何かが必要 LLM機能のローンチは検証や開発を含め高コストなもの ユーザーとビジネスに意味がないともったいなすぎる
16. リリース前後での2つの提案 • リリース前にすること ◦ LLMを交えた機能は、深く課題と限界を理解して、動くものを早く作り切る • リリース後にすること ◦ フィードバックは強めに取りに行く
17. リリース前： 深く課題と限界を理解して、 動くものを早く作り切る
18. リリース前：深く課題と限界を理解して、動くものを早く作り切る ユーザーのコストが 想像できるまで課題を 理解する LLMの速度・価格・知性の 限界を把握しておく 動くものを早く作る このフェーズで紹介すること https://www.vellum.ai/llm-leaderboard https://www.productboard.com/agile-product-management-tool/
19. リリース前（1/3）ユーザーのコストが想像できるまで課題を理解する LLM利用機能を考える前に 人的コストが想像できるレベルにユーザー解像度を上げるのが実は近道 要望蓄積SaaSや ユーザーインタビューを常に行えるようにする 要望を集める仕組みを整備する ユーザー課題を解像度高く把握する 「サーベイ」のユーザーが 数百人以上の自由 記述回答を全て読んでいる ことを知っていた https://www.productboard.com/agile-product-management-tool/
20. リリース前（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
21. リリース前（3/3）動くものを早く作る 未知の技術を使ったソリューションは動くものがないと価値や制約がわからない ここはプロダクトアウトに、動くプロトタイプを作ってしまう
22. 「深く課題と限界を理解して、動くものを早く作り切る」効果 ROIの見込みとLLM機能である必然性があってはじめて上手くいく これらがないとどこかで頓挫するし、ユーザーにも訴求しにくい ユーザーのコスト、使うべき LLMと 原価が把握でき、 ROIを推測できる 投資余地、ROIを推測できる ソリューションが適切か評価できる プロトタイピングで本当に ユーザーの課題を解決できるかも推測できる
23. 「要約AI」機能は3つのアクションが取れたので使われたのかも
24. リリース後： フィードバックは強めに取りに行く
25. リリース後：ユーザーフィードバックは強めに取りに行く このフェーズで紹介すること タスク完了時にすぐフィードバックを依頼する ユーザーと一緒に操作する
26. フィードバック収集は、弊社でもうまくできていない部分です 🙏 現時点では後述のように強めに取りに行くしかないと思っているが …パネルディスカッションで議論 させてください！ disclaimer：フィードバック収集については…
27. タスクによっては、機能が役に立ったかがわからない 人間が実施していたタスクを LLMに置き換えると「本当に役に立ったか」がわからない プロンプト含めて、本来は改善したい
28. Good/Badボタンは押されない Good/Badボタンを基本ユーザーは押さない 「要約AI」はアンケートへのリンクも用意したが、ほぼ入力されなかった
29. リリース後（1/2）タスク完了時にすぐフィードバックを依頼する タスク完了時に依頼したり、出力の ABテストをするのは一定有効そう（ ChatGPTに学ぶ）
30. リリース後（2/2）ユーザーと一緒に操作する ユーザビリティテストのように、ユーザーと一緒に画面を見ながら操作するのも有効かも
31. 「フィードバックを強めに取りに行く」効果 ソフトウェアプロダクトはリリースして終わりでないのは LLMを使っても一緒 特にプロンプトのブラッシュアップは永遠の課題 ユーザーの実データで本当に意図した挙動になっ ているか把握し、適応する ユーザーの現場に適応できる モデル仕様の変更など、異常に対応できる APIプロバイダの仕様変更でハルシネーション してないかなど、チェックは常にしたい https://openai.com/blog/new-embedding-models-and-api-updates
32. フィードバック収集は、弊社でもうまくできていない部分です 🙏 現時点では前述のように強めに取りに行くしかないと思っているが …パネルディスカッションで議論 させてください！ disclaimer（再掲）：フィードバック収集については…
33. 結論
34. • リリース前にすること ◦ LLMを交えた機能は、深く課題と限界を理解して、動くものを早く作り切る • リリース後にすること ◦ フィードバックは強めに取りに行く • この2つができれば、社内外に上手く訴求してリリースし、きちんと ユーザー課題を解決した上でビジネスになるように LLMを使えるはず 今日の結論　これだけは覚えて帰ってほしい
35. ご静聴ありがとうございました！