Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Machine Learning and Feedback
Search
Agata Naomichi
September 26, 2018
Programming
1.6k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Machine Learning and Feedback
Agata Naomichi
September 26, 2018
More Decks by Agata Naomichi
See All by Agata Naomichi
Turning AI into Business Impact / "AI" の事業インパクトを最大化する
agatan
4
740
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
9.8k
全員アーキテクトで挑む、 巨大で高密度なドメインの紐解き方
agatan
9
24k
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
2
750
医療系スタートアップが経験した 認知負荷問題の症状分析と処方箋 チーム分割による認知負荷の軽減 / Cognitive Load Busters
agatan
2
660
専門性の高い領域をいかに開発し、 テストするか / How to test and develop complicated systems with Domain Experts!
agatan
3
960
Henry のサーバーサイドアーキテクチャ 狙いと課題 2022.08.25 / Server-Side Architecture at Henry, Inc.
agatan
3
6.2k
The Web Conference 2020 - Participation Report
agatan
1
770
○○2vec 再考
agatan
1
4.8k
Other Decks in Programming
See All in Programming
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.7k
Spec-driven Development with AI
simas
PRO
0
2.2k
LLM 101
dalinaum
0
440
Inertia Rails: The One-Person Framework with React & Friends
skryukov
0
200
Herb in Rails 8.2: Your ERB views, now HTML-aware @ Kaigi on Rails 2026, Tokyo, Japan
marcoroth
2
380
AIが生成したコードは読むべきか?抽象化設計とコードの品質保証 / abstraction-design-and-quality
minodriven
14
8.1k
Long Living Tokens, Die, Die, Die! (or: The One Ring is Banned in Modern)
sylph01
0
400
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
3
2.3k
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
350
SODA - FACT BOOK(JP)
sodainc
1
40k
ChromeでローカルLLM
ryu1013
0
190
Materialが消えた日 〜真っ白なFlutterキャンバスにRenderObjectで絵を描く〜
umigishiaoi
0
130
Featured
See All Featured
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
500
Chasing Engaging Ingredients in Design
codingconduct
0
380
Building an army of robots
kneath
307
47k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
330
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
380
Darren the Foodie - Storyboard
khoart
PRO
4
4.1k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.8k
Automating Front-end Workflow
addyosmani
1370
210k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
25k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
The Cult of Friendly URLs
andyhume
79
7.1k
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
Transcript
ユーザフィードバックと機械学習 Machine Learning Casual Talks #6
Naomichi Agata Software engineer at Wantedly, Inc. Server side +
Machine learning @ Wantedly People GitHub Twitter @agatan @agatan_
サービスにおける機械学習システムには ユーザフィードバックが重要
フィードバック • ユーザからのフィードバック ◦ レビューやお問い合わせだけではなく、 「ふつうにサービスを使うなかでの行動」から得られる ◦ e.g. 「検索結果をクリックした」「購入せずに戻った」「誤情報を訂正した」 •
ユーザへのフィードバック ◦ より良いサービスを提供する ◦ e.g. 「あなたへのおすすめ」「全体の精度が向上する」
何を持ってそのモデルを「良い」と判断するか 機械学習をサービスに活用するためには 1. モデル自体の精度(オフラインで測れる精度) 2. KPI / ユーザ体験への影響(オンラインでしか測れない精度) の 2
面から「良さ」を判断する必要がある ユーザ体験への影響は「ユーザからのフィードバック」でしか測れない
サービスの成長とモデルの成長 • サービスが大きくなるにつれてできることは増えていくはず ◦ e.g. パーソナライズ • フィードバックループを繰り返して改善していきたい 、というのは機械学習も一緒 良い機械学習によってサービスの成長を加速する
→ データが増える → 精度があがる and/or できることが増える → 成長を加速 → …
理想 良い体験を実現するほど、使ってもらえる ↑↓ 使ってもらうほど、改善がすすむ 使う 改善 より良い体験の提供
現実 • どの程度フィードバックを得られるかは、問題とサービスの性質に依存する ◦ たとえば、推薦はフィードバックを得やすい • 「サービスの拡大とともに使える情報が増える」ことは期待できない場合もある ◦ 学習データにするには壁がある ▪
より高度な annotation 作業が必要, ノイズが多い, … • 機械学習システムだけ成長に置いていかれるわけにはいかない
どんな対応ができるか
前提... • フィードバックを逃さないログ基盤などはとても重要 ◦ 「なにかがおかしい」を察知できないと改善の余地がない ◦ 継続的に評価できないと新しいことに挑戦できなくなる • フィードバックを受けやすい UX
設計も重要になってくる(?) ◦ 予測が間違っているときにそれを伝えられる ◦ 予測が正しかったときにそれを伝えられる ◦ 機械学習エンジニアも UX 設計に参加する必要がある
半教師あり学習として解く • 「少量の教師ありデータ + 大量の教師なしデータ」 • 教師なしでもできることを組み合わせたシステムにするのが一番うまくいった ◦ たとえば、word embedding
layer を教師なしデータで事前学習しておく
データの分布に注目する • annotate されていないデータでも、現実のデータの分布を反映している • 活用できていなかったデータも、細かく分析することで使えるようになる(こともある) • 分布さえわかればできることもある ◦ たとえば、bi-gram
の出現頻度を見ながら sequence 全体での尤度が最大になるように decode する ◦ たとえば、出現頻度の多いパターンにはアドホックにルールベースで対処する ▪ e.g. 高い頻度・確率で「m」が「nn」に訂正されている • より現実に近い data augmentation ができる ◦ データの分布から教師データを作る
ノイズを許容する • ノイズを許容してでも大きなデータで学習したほうが良い場合もある ◦ とはいえ単純につっこんでもうまくいかない(はず) • 地道に分析してノイズを取り除くのが(可能なら)一番よさそう • 教師データのノイズに耐性を持つようなモデルも提案されている
まとめ • サービスの成長にあわせてモデルも改善したい ◦ モデル改善 → サービス向上 → 使ってもらえる →
改善 → … のループが回せると幸せ ◦ 問題・領域によっては、モデルの改善に直接使えるデータは集まらない • どうやってモデルの改善を進めるか ◦ そもそも UX としてユーザフィードバックが得られる構造になっているか? ◦ 半教師あり的に扱う ◦ ひたすら分析 + パターンを見出して改善する