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
エンジニアとしての機械学習との付き合いかた
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
yubessy
April 25, 2017
Programming
6.4k
3
Share
エンジニアとしての機械学習との付き合いかた
機械学習システムの開発・運用を担うエンジニアの視点からの話です ※社内LT用につくったもの
yubessy
April 25, 2017
More Decks by yubessy
See All by yubessy
DDIA (Designing Data-Intensive Applications) はいいぞ
yubessy
0
1.6k
Introduction to CircleCI
yubessy
1
120
Docker Hands-on
yubessy
0
120
Resource Polymorphism
yubessy
0
310
不動点コンビネータ?
yubessy
0
310
とりあえず機械学習したかった
yubessy
0
350
Scala Native
yubessy
0
230
Type Erasure と Reflection のはなし
yubessy
1
480
量子暗号
yubessy
0
240
Other Decks in Programming
See All in Programming
Claude Codeをカスタムして自分だけのClaude Codeを作ろう
terisuke
0
140
ソフトウェア設計の結合バランス #phperkaigi
kajitack
0
130
Coding as Prompting Since 2025
ragingwind
0
830
The Monolith Strikes Back: Why AI Agents ❤️ Rails Monoliths
serradura
0
340
UIの境界線をデザインする | React Tokyo #15 メイントーク
sasagar
2
360
アーキテクチャモダナイゼーションとは何か
nwiizo
19
5.2k
Back to the roots of date
jinroq
0
100
Vibe NLP for Applied NLP
inesmontani
PRO
0
430
Server-Side Kotlin LT大会 vol.18 [Kotlin-lspの最新情報と Neovimのlsp設定例]
yasunori0418
1
150
LM Linkで(非力な!)ノートPCでローカルLLM
seosoft
0
500
煩雑なSkills管理をSoC(関心の分離)により解決する――関心を分離し、プロンプトを部品として育てるためのOSSを作った話 / Solving Complex Skills Management Through SoC (Separation of Concerns)
nrslib
4
950
GNU Makeの使い方 / How to use GNU Make
kaityo256
PRO
16
5.6k
Featured
See All Featured
Writing Fast Ruby
sferik
630
63k
Making Projects Easy
brettharned
120
6.6k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
10k
エンジニアに許された特別な時間の終わり
watany
106
240k
How STYLIGHT went responsive
nonsquared
100
6.1k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
260
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
510
Java REST API Framework Comparison - PWX 2021
mraible
34
9.3k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.2k
Producing Creativity
orderedlist
PRO
348
40k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.6k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
110
Transcript
エンジニアとしての 機械学習との付き合いかた @yubessy 0x64 物語 Reboot #02
コモディティ化がもたらしたもの Fasttext, TensorFlow, Google Cloud NLP ... ライブラリ -> フレー
ムワー ク -> API 高度な専門知識がなくてもそこそこの予測モデル が作れる TensorFlow によるキュウリの仕分け https://cloudplatform- jp.googleblog.com/2016/08/tensor ow_5.html 僕はこの先何で食っていけばよいのか?
これからの機械学習のお仕事 入口に寄るか出口に寄るか? 入口: デー タサイエンティスト モデルの構築前からかかわる デー タの取捨選択・UI 設計・ 問題の定式化
出口: 機械学習エンジニア モデルの構築後も面倒を見る システム・ インフラ設計・ 継続的な運用 今日はこっちの話
Q. エンジニアリング視点での 機械学習の難しさとは?
問題: 事前に誤りを防ぐことが困難 システムの出力の正しさが定義できない そもそも未来に対する予測なので 「X を入力してY が出力されたら正解」 とは誰も言えない システムに無謬性を要求できない 100%
の精度を実現するのは事実上不可能 エラー をどこまで許容するかを考える必要
問題: 結果の解釈・ 再現・ 修正が困難 モデルのブラックボックス化 意図しない結果が出ても何をどう直せばいいか わからない 結果の再現の困難さ 再学習しようとしたらDB の状態が変わっている
昨日の予測結果が今日の学習デー タに影響 CACE (Changing Anything Changes Everything) e.g. ゴミが1 件混じっただけで精度が大幅低下
実際みんな苦労してる Machine Learning: The High Interest Credit Card of Technical
Debt https://research.google.com/pubs/pub43146.html 機械学習は技術的負債の高利子クレジットカー ド “ “
何が困難さを生み出すのか?
図で考える機械学習システム
一般的なシステムとの違い デー タ依存性 システムの入出力を決定する関数が デー タを入力とする別の関数によって作られる 予測処理だけをみると巨大な副作用のかたまり デー タ依存性がもたらすもの 関数を人間が直接読み書きできない(≠
コー ド) 結果に対して事前に何かを保証しにくい
どうやって問題と戦うか?
先駆者の知見 Rules of Machine Learning: Best Practices for ML Engineering
http://martin.zinkevich.org/rules_of_ml/rules_of_ml.p df To make great products: do machine learning like the great engineer you are, not like the great machine learning expert you aren’t. “ “
未知なるものとの闘い 問題に直面したとき 問題を特定し、 分割し、 パター ン化する 既存の仕組みやツー ルを応用する それでも解決できないとき 問題の影響を最小限の範囲に封じ込める
新たな枠組みを作り上げる 多くの課題はエンジニアリングの領域にある “ “
今すぐにできること 機械学習特化した開発・ 運用の体系は未確立 -> 問題をよく知られた方法論に落とし込む 特に信頼性工学的な手法は相性が良い バー ジョン管理 ( 自動)
テスト CI / CD
問題発生を未然に防ぐ テストの導入 典型的なパター ンは通常のテストと同様 境界条件付近ではデー タを微妙に替えて水増し 画像 -> アフィン変換 テキスト
-> 無関係な語の追加 バックテストによるオフライン検証 過去のデー タに対する予測を行って 既にわかっている結果と比較
問題発生後の対処を簡単にする モデルだけでなくデー タのバー ジョン管理を行う システムの状態を任意の時点に復元可能に 継続的なデプロイ モデル改善のサイクルを細かくする -> 問題発生時の原因特定を容易化
対処療法の先へ 問題を個別に解決していくだけでは限界 複合的な問題を包括的に扱う仕組みが必要 ライブラリ -> フレー ムワー ク コンポー ネント
-> アー キテクチャ 個人的な注目株 モデルの表現: PMML, PFA モデルの検証: ソフトウェア基礎論の応用 デー タの管理: ラムダアー キテクチャ
モデルの表現: PMML, PFA モデルの計算式をコー ドで表現 -> 静的解析や差分のバー ジョン管理が可能に input: fields:
- {name: x, type: double} - {name: y, type: double} ... output: double method: emit action: - cast: input.mag cases: - as: double named: magDouble do: [{emit: magDouble}]
モデルの検証: 型理論の応用 Dependent Type による精度保証 演算の型にパラメー タを指定できる -> 浮動小数点数の演算の精度を保証したり ->
推測統計・ 機械学習への応用?
デー タの管理: ラムダアー キテクチャ 処理のもとになる全てのデー タを保存 速度と堅牢性を必要に応じて選択できる 継続的に運用しても破綻しにくい http://lambda-architecture.net/
まとめ エンジニアからみた機械学習 デー タ依存がもたらす困難さ 既存の方法論による対処 これからの注目株
まだまだ仕事はあるぞ!