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
Machine Learning and Feedback
Search
Agata Naomichi
September 26, 2018
Programming
1
1.5k
Machine Learning and Feedback
Agata Naomichi
September 26, 2018
Tweet
Share
More Decks by Agata Naomichi
See All by Agata Naomichi
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
8.7k
全員アーキテクトで挑む、 巨大で高密度なドメインの紐解き方
agatan
8
22k
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
2
660
医療系スタートアップが経験した 認知負荷問題の症状分析と処方箋 チーム分割による認知負荷の軽減 / Cognitive Load Busters
agatan
2
590
専門性の高い領域をいかに開発し、 テストするか / How to test and develop complicated systems with Domain Experts!
agatan
3
870
Henry のサーバーサイドアーキテクチャ 狙いと課題 2022.08.25 / Server-Side Architecture at Henry, Inc.
agatan
3
5.8k
The Web Conference 2020 - Participation Report
agatan
1
730
○○2vec 再考
agatan
1
4.6k
Improving "People You May Know" on Directed Social Graph
agatan
4
2.7k
Other Decks in Programming
See All in Programming
Vibe Coding - AI 驅動的軟體開發
mickyp100
0
170
LLM Observabilityによる 対話型音声AIアプリケーションの安定運用
gekko0114
2
420
AI Agent Tool のためのバックエンドアーキテクチャを考える #encraft
izumin5210
6
1.8k
カスタマーサクセス業務を変革したヘルススコアの実現と学び
_hummer0724
0
630
OSSとなったswift-buildで Xcodeのビルドを差し替えられるため 自分でXcodeを直せる時代になっている ダイアモンド問題編
yimajo
3
610
疑似コードによるプロンプト記述、どのくらい正確に実行される?
kokuyouwind
0
380
Kotlin Multiplatform Meetup - Compose Multiplatform 외부 의존성 아키텍처 설계부터 운영까지
wisemuji
0
190
AI時代のキャリアプラン「技術の引力」からの脱出と「問い」へのいざない / tech-gravity
minodriven
20
6.8k
AIによるイベントストーミング図からのコード生成 / AI-powered code generation from Event Storming diagrams
nrslib
2
1.8k
CSC307 Lecture 03
javiergs
PRO
1
490
AI時代の認知負荷との向き合い方
optfit
0
150
AI Agent の開発と運用を支える Durable Execution #AgentsInProd
izumin5210
7
2.3k
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
A designer walks into a library…
pauljervisheath
210
24k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
91
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
290
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
1.8k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
290
Testing 201, or: Great Expectations
jmmastey
46
8k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
0
310
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.3k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.7k
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 としてユーザフィードバックが得られる構造になっているか? ◦ 半教師あり的に扱う ◦ ひたすら分析 + パターンを見出して改善する