機械学習の記事や本をちょこちょこ見たりしていると、どうも自分の認識とは結構違う。そこで一度自分の認識をまとめておこう、と思う。

データ分析を用いたサービス開発とは、データと問題の、自分たちの間違いを理解する過程である

一番認識が違う、と思う所が、問題とデータを理解する過程を重視しない所にある。一方でこれが本質だと自分は思っていて、そのために用いるのがモデルだ、と思っている。これは科学分野のモデルでは一般的な話だが、プログラマはこれをブラックボックスとして呼ぶだけのその他のライブラリ達と同じ物にしたい、という気持ちが強い為、現実から目をそらしがち。

そこを少し説明してみたい。

途中で設計する問題は、全て間違えている

普通のサービス開発との比喩で考える。

サービス開発が、顧客やユーザーの本当に欲しい物を探る過程である、というのは、自分のブログを読むような人間なら同意してくれるだろう。ここから始めたい。

これは仕様があってそれをただ実装するだけ、というのとは大きく異なる所だ。で、その為に顧客とのコミュニケーションとかイテレーションとかが必須になる。

これに対応するデータ分析のサービス開発というと、基本的には「問題を理解する」過程という事になる。そして問題を理解する過程とは、「自分達の間違い」に気づく事を積み重ねる過程である。

これが既存の機械学習の記事などでは抜け落ちている所で、まるで

問題の設計＝＞モデルの改善（スコアの改善）

と進むかのように書かれている。おまけくらいに仮説を検証して間違っていたら仮説をアップデートしましょうね、と書いてある程度だ。問題の方を修正して正しくする過程が本質で、そこがデータ分析の開発の本体なのに、まるでそこはデータ分析の開発とは切り離せる何かのように書かれている。

これは通常のサービス開発をウォーターフォールのように記述して、たまに後工程の間違いを前に反映しましょうね、と形だけ助言するのと似た問題がある。仕様が最初に決まっていて動かなくて、それを翻訳する過程としてサービス開発を語る事に似ている。

そういう場合も確かにあるが、大多数はそうでは無いし、本質はそうでは無い方にある。データ分析の話でも同様だ。問題の設定の所をビジネス的なKPIや何かしらのMVPで確認して、それを実装しましょう、というのは、一番難しいはずの所が解決されているという前提から始まってしまう。

では自分達の間違い、というのをどうやって知っていくか？そこで登場するのがモデルという物だ。

モデルとライブラリの違い

Inception v3を知らなくてもこれを使う事は出来る、という点で、モデルはブラックボックスとして使う事が、現時点でもある程度は出来ている。

でも、だからといってやがて画像分類が汎用で出来るようになるからデータ分析の知識は要らなくなる、という風にはならない。少なくとも自分はそう思っている。

だが、そういう風に主張する人は（特にやってない人に）多く、そういう記事をいつもKazunori Satoがシェアしてて自分が噛み付いている。あまりにも不毛なので、ここらでちゃんとその話をしておこう。

モデルというのは、それを通して

問題設計
データ

を理解する為の物である。少なくとも現在のデータ分析においてはそうである。

我々は、このモデルの評価を通じて、自分たちの間違いを知る。間違いを知り修正していく過程で問題とデータを理解していく。これがデータ分析の本質となる。

モデルを評価する事で間違いを知る為には、自分に何かしらの考えがあって、それを表現する必要がある。それがモデルと呼んでいる物の正体だ。自分たちはモデルを通して自分の考えを表現し、それを評価することを通じて自分の考えの間違いを知る。だから自分の考えを表現する必要は、どこまで行っても無くならない。

これを全く自分の考え、という物を挟まずに、ただ「よその誰かの考えた問題の理解を表現した物」を持ってきて動かす事を考えよう。それを評価しても、自分たちの問題の理解の誤りは何も分からない。それはモデルに自分たちの問題の理解が表現されてないからだ。だからこの行いは、データ分析をやってるのと表面上凄く似てて、だからそれを簡単にやりましょう、という本が溢れてしまっているが、これでは全く役に立たない。

どうやったら自分達の問題設計の間違いに気づき、どうやってそれを修正していくのかがデータ分析の仕事となる。正しい問題設計にたどり着く過程こそがデータ分析なのであって、正しい問題設計がされてる所でスコアを改善するようにモデルを修正していく過程では無い。

なお、リコメンド周辺（含む検索順位）は問題設計が完全に固まってるので、今やスコアを改善していくだけという場所もありえる。これは凄く特殊な例で、既存のサービス開発で、完全に仕様が動かせないケースに近い。そういうケースは確かに存在するけれど、主流では無いでしょう？

話を戻して。データ分析の入門というのは、このモデルを通して正しい問題設計に至るには、どうしたら良いか？という事を扱うのが筋だと思う。

自分の考えをモデルにどうやって表現するのか、それを評価した結果からどう自分達の間違いの本質が何なのかを引き出すのか、それを通して最終的にどういうプロセスで「正しい」問題設計に辿り着くのか、そういうのがデータ分析の入門となる。

こういう要素を軽視すると、何かスコアを返す関数があって、このスコアを改善しようと中をいじる過程、という風になってしまうが、それでは少なくともDLを実際のサービスに応用することはまったく出来ない。

既存の開発プロセスとの融合（をどうしたらいいのかは分からない）

ここまでで、データ分析の話はだいたい良いと思うのだけど、これを既存のサービス開発のマネージメントとか開発自体とどう融合するかは自分には良く分かってない。

少なくとも我々は最初に何を解くべきかを理解してないので、非データ分析の人と解くべきことを最初に了解して別々に進める、というのは出来そうに無い。何を作れるのかを誰も知らない所で、何を作るべきかをどうやって決めれば良いのだろう？良く分かってない。

うまく行ってる所はなんかいろいろやってみて、偶然見つけた面白そうな物を出しているだけに見える。これではビジネスとかサービスの改善という点では厳しいような気もする。

でもなんかのKPIを改善しましょう、みたいなのがうまく行くのなんて、本当に限られたごく一部の特殊なサブゼットだけで、ほとんどのデータ分析系のサービス開発はこの中に入ってないどころかカスリもしていない。 DL系は全滅だ。

どうしたらいいのか自分は分かってないので、誰か教えてください。