zenn.devを使いはじめました

テクニカルな内容はzennに書いていこうと思います。

https://zenn.dev/hagino3000

最初の投稿は臨床診断支援システムの歴史についてです。
https://zenn.dev/ubie_dev/articles/62dcaf309c78b3

「施策デザインのための機械学習入門」が素晴しい内容だった

読んだので感想を書きます。「手元のデータに当てはまりの良い予測モデルを本番適用してもビジネス的に良い結果が得られない」という現場で頻発する課題に対して明快なアプローチと手順を示しており、機械学習がワークするために必要な要素がクリアになりました。

施策デザインのための機械学習入門〜データ分析技術のビジネス活用における正しい考え方
技術評論社 (2021/7/30)
齋藤 優太 (著), 安井 翔太 (著), 株式会社ホクソエム (監修)
Kindle版/紙版両方あり

目次と構成

• はじめに
• 1章 機械学習実践のためのフレームワーク
• 2章 機械学習実践のための基礎技術
• 3章 Explicit Feedbackを用いた推薦システム構築の実践
• 4章 Implicit Feedbackを用いた推薦システムの構築
• 5章 因果効果を考慮したランキングシステムの構築
• 付録A 演習問題

感想

著者はまず1章で機械学習の実践でありがちな2つのパターンを批判しています。

ひとつ目は予測を用いた施策は本来意思決定の問題であるはずなのに、予測の問題として解いてしまうという物。意思決定の性能で評価すべき問題を損失関数最小化の問題として解くことで誤った意思決定を導きます。ふたつ目は過去の施策の影響を受けたデータをナイーブに扱って新たな施策の評価を行なう物で、本来知りたい意思決定の性能の良さが推定できていません。

機械学習を用いた施策の開発過程において、意思決定の性能ではなく予測性能を追い求めてしまうのは現場でよくみられる姿なので1章から胃が痛くなります。ほとんどは意思決定の性能が評価できるデータが無いか集められないパターンだとは思いますが「損失が低いのだからビジネス的に良い結果が得られるはずだ」と予測精度のメトリクスの良さとビジネス的な良さを混同してしまう人もいます。これがやっかいなのは本番環境におけるA/Bテストで良い結果が得られなかったときにパラメータチューニングや特徴量エンジニアリングに目を向けてしまい、それ以前の問題である可能性を考えられなくなってしまう事です。AIベンチャーに相談をするとその予測に意味があるのかどうかをすっとばして予測モデルの実装の話が始まってしまうのも似た話でしょうか (私の経験上はそうです)。

著者はこの2つの落とし穴に対して解決策となるフレームワークを提示しています。

1. KPIを設定する
2. データの観測構造をモデル化する
3. 解くべき問題を特定する
4. 観測データのもを用いて問題を解く方法を考える
5. 機械学習モデルを学習する
6. 施策を導入する

このフレームワークの一連言語化が素晴らしいなと思いました。私は広告分野の人間なので広告分野におけるデータの観測構造由来のバイアスを除去する論文は目にしますが、このフレームワークはあらゆる分野で適用可能な一般化がなされています。

現実世界にはデータのノイズが大きい場合や環境の変化が激しい場合、目的変数に関係する特徴量が取得できない場合など、データや機械学習を活用すること自体が無謀な状況はいくらでもあります。このような現実において我々が心得ておくべきなのは、機械学習が機能する状況を整えることができなければ、機械学習を活用することが有効な場面であるか否かという情報すら得られないということです。

著者がこの部分に着目する理由も明快で次のように説明されています。

なお、巷に溢れている特徴量エンジニアリングやハイパーパラメータチューニングもしくは論文で議論されている最先端の深層学習手法などは、基本的に真の性能を経験性能で精度良く近似できるということを(しばしば暗黙の)前提としています。

(中略)

おおよそ機械学習という言葉から連想される技術は、機械学習の実践において下流に位置するステップに関するものだったのです。本書の焦点は、施策の性能につながる問題を機械学習に解かせる部分であり、解くべき問題が与えられた状態でその問題をいかにうまく解くかという部分ではありません。効果的な施策につなげるためには、精度追求に関してあれこれ試行錯誤するよりも前に、フレームワークとしてまとめた手順を上から順に漏れなくクリアしておく必要があるのです。

 2章は観測データを用いて意思決定の性能を推定する方法について解説しています。私はIPWやDoubly Robust推定量には馴染みがあったのですが「データが観測される確率の逆数をsample weightに仕込めばよい」と単なる暗記に近かった部分がしっかり式で丁寧に説明さていたので助かりました。知りたい真の損失関数と手元のデータを使ったときの損失関数の差を打ち消す手順がわかるので応用が効くようになるでしょう。

3章以降は著者の提案するフレームワークの実践になっています。私は特に5.3章のプラットフォーム全体で観測される目的変数を最大化するが興味深い設定でした。施策を実施したものの他の部分のKPIを悪化させたり、単なる需要の先食いになるのはよく聞く話です。

まとめ

機械学習の実践に取りくんでおり、特にビジネスKPIの改善に責任を持つ機械学習エンジニア^*1にとって頼りになる内容である事は間違いないでしょう。どのような損失関数を採用すべきか正解は無く自分で考えるべきだと、ある所から先は切って捨てている所も好感を持ちました^*2。

1章で学習および性能評価がやりやすいデータを意識して普段から集めておく事をさらっと促していますが、意思決定方策のオフライン評価にはとても重要なことがわかります。参考文献に載っていたSpotify Researchの論文^*3を読みましたが、オフライン評価のために一様ランダムに行動を選択したログを収集していました。

本書の焦点は機械学習がワークするための前提でしたが、特徴量エンジニアングやハイパーパラメータチューニングの記事と同じぐらいこれらの記事がインターネットに出てきてくれると嬉しいなと感じました。

ビジネス価値を生むことに責任を持つために実践している内容を『仕事ではじめる機械学習 第2版』に書きました

第2版がでました。

仕事ではじめる機械学習 第2版
オライリー・ジャパン (2021年04月)
有賀 康顕、中山 心太、西林 孝　著
電子版版/紙版両方あり

私は7章の「効果検証」と13章の「オンライン広告における機械学習」を執筆しました。12章は書き下し新章です。既に発売からは時間が経っているのでこの2つの章の裏話というか思想について解説します。

PoC貧乏という言葉があるように機械学習を用いてビジネス価値を生む施策は失敗しがちなことが知られてきました。前提として本書はその様な失敗しやすい施策をできるだけ成功に近づけるにはどうしたら良いかを広く扱っています。

ビジネス価値を定義する

予測を当ててどんな価値を生みたいのかを定義しないと開発は始まりません。13章では広告配信事業者の顧客である広告主の効用を選びました。オンライン広告ではオークションによる広告枠の売買が行なわれます。広告主は財の買い手となるので経済学の言葉を使うと広告主の効用は買い手の効用 (buyer's utility) に相当します。広告の場合、他には広告枠の売り手の利益 (seller's profit) や交換によって生まれる価値 (welfare) といった価値を選ぶこともできます。これはどんなビジネスをしているかによって変わるため自らの状況に照しあわせて選択するものです^*1。

意思決定方策への落しこみ

次に広告主の効用を最大化する行動を取るためにはどうしたら良いかを考えます。広告主の効用は広告枠の買いつけコストと広告を表示する事で得られる価値の差となります。この効用を定式化すると広告を表示した時にポジティブな反応が得られる確率と市場価格の予測が必要なことがわかります。

13章の前半は予測を元に期待効用を最大にする入札金額を数理最適化で求めれば良いという流れにしました。ここは価値を生むための意思決定方策をどう設計していくかの解説になっています。

308ページ 12.2.2節 より

明確に定式化できなくとも予測が当たることでビジネス価値が生まれる機序が説明できることが重要だと考えています。

ビジネス指標を使った予測モデルの評価

7章は効果検証がテーマですが、ここは一貫してlogloss等の予測精度ではなくビジネスインパクトで予測モデルの評価をしようという話です。予測が当たったとき外れたときのビジネスインパクトを金額換算できるか考えてみましょうと。

そしてビジネスインパクトを正しく推定するためにはバイアスを除去した比較が必要であること、サンプルから母集団における効果を推定することでプロダクトへの影響を限定して本番環境で実験できることを統計的仮説検定と因果推論の導入を含めて解説しました。比較が重要なのは機械学習を使わなくとも従来通り人間がやるのと何も変わらなかったりするからです^*2。

まとめ

私が担当した章について思想を含めて紹介しました。いずれのトピックにしても深い所までは解説していないので、必要であれば適宜専門書に進んでもらえればと思います。

関連する書籍として技術評論社から『施策デザインのための機械学習入門』が出たので後ほど紹介記事を書く予定です。序盤から「機械学習を使った施策は予測ではなく意思決定の問題として捉えよう」とあり、他にもなるほどそういう表現があったかと膝を打つ場面が何度もありました。

本を執筆して、どうも自分はソリューション設計に興味があるらしいことがわかったので次はそんな話が書けたらと思っています。現場あるある話として「コンペだと特徴量減らすモチベーションないけど、効くかどうかわからない特徴量もりもりのモデルは推論APIの実装時に自分の首締めることになるよ」とかそういうのも大量にあるんですが。

---

[1] 広告に限らず売り手と買い手が存在する両面市場においてはこのパターンがはまります。

[2] 人間と同じ性能が出せれば十分なケースもあります。どこまでの性能を求めるかはプロジェクト次第です。

Data validation for machine learning 読んだ

Breck, Eric, et al. "Data validation for machine learning." Conference on Systems and
Machine Learning (SysML). https://mlsys.org/Conferences/2019/doc/2019/167.pdf . 2019.

読み手のコンテキスト

現職で機械学習予測モデルをプロダクトに投入する様になって3年程経った。そうもなると開発時に想定していた訓練データの分布と現状の分布が乖離して、予測の動作不良を引き起すケースがしばしば見られる様になった。明らかな予測の不具合として目立っていなくとも性能が落ちている部分はもっとあるはずで、これに早く気づいて対応したいモチベーションがある。かつ運用専任メンバーはいないので、できるだけ運用は手を抜きたい。

概要

著者らはData Validationシステムを開発した。これはGoogleで稼動中のMLプラットフォーム(TFX)にデプロイされており数百のプロダクトで毎日利用されている。論文の構成はData Validationシステムを構成する3つのコンポーネントであるSingle-batch validation・Inter-batch validation・Model testingと、それぞれが解決できるデータの異常パターンと実装した提案手法の解説。最後にGoogleにおける利用状況と実際のサービスにおける検出例 (ケーススタディ) の紹介。

新規性および貢献

MLコンテキストに適用できるData Validationの手法について提案した。

Data Validationはおなじみの概念 (例えば Databaseの分野では) であるが、ML Pipelineの文脈で既存の手法をそのまま適用する事ができない。例えばデータの生成元とMLパイプラインが分離されているので、流れてくるデータを元にschemaを決める事になる。Databaseの世界では先にschemaを決めるので順序が逆。またカイ二乗検定 (chi-square test)の様な手法はMLパイプラインが扱うスケールのデータでは敏感すぎる。よって既存のData Validationを見直してMLコンテキストにマッチする手法を開発した。

Data ValidationはTFXの設定に基づいて開発されたが、別のシステムでも利用可能な様に提案手法をOSSライブラリとして実装もした。

Single-Batch Validation

一度の訓練に利用される訓練データのvalidation。人々は訓練データに対してstableであり続ける何らかの特性を期待している。そのためexpert domain knowledgeによって与えられるデータの特性からの乖離を異常とみなす。これを検出するためにスキーマ定義によるvalidationを開発した。

例えばあるフィールドの出現しうるカテゴリ値を定義できたりする。

ただしMLモデルは数千の素性を利用するため、人がスキーマ定義をゼロから作るのは現実的ではない。この問題を緩和するのに、スキーマの初期バージョンをデータから作成する機能を用意した。バリデーションエラーとなるデータが見つかった時にはスキーマの変更差分も自動で生成する。

Inter-Batch Validation

Concept-Driftの様な一回分の訓練データだけで判断できないタイプのエラーを検出する仕組み。エラーの例として次のパターンを挙げている。

• Feature Skew
• 例えば訓練時の前処理と推論時の前処理の差から生まれる。訓練時の前処理と推論時の前処理では求められる性能特性が異なるので、別のコードが使われる。そのため、片方だけ修正してしまうといった事が発生する。
• Distribution Skew
• 時間経過による分布の変化
• Scoring/Serving Skew
• 多く配信された広告データはサンプルが多いが、少なく配信された広告はデータ少ない
• MLシステム自身によって発生させたバイアス

これらのエラーを検知するには各バッチ毎に訓練データセット同士の分布の距離をみれば良い。これは分布間の距離を定量的に求めるメトリクスに依存する。統計的検定やKL-Divergenceは最初の一歩となる、しかし値の解釈や閾値の設定が難しかったりする。統計的検定はサンプルサイズが大きいとsensitiveになりすぎる。よって実際に使っているのは分布pとqの距離を次の式で定義したものである。

i は "each value i" とあるから各カテゴリだろうか (自分の理解があやしい)。カテゴリ値ごとの出現率の差なので非常に理解しやすく調整が容易。

Model Unit Testing

例えば前処理で対数変換をしている時、その前処理コードは暗黙的に訓練・予測データに正の値を期待している事になる。よってこの暗黙的な期待が満たされない時にコードはクラッシュしてしまう。推論時にクラッシュしたらサービスに影響が出てしまう。

このエラーに気づける仕組みとして前述のスキーマ定義を用いた fuzz testing アプローチを採用した。Single-Batch Validationで作成したスキーマ定義を基にデータを生成して学習コードを実行する。こうする事でスキーマ定義に現われていない暗黙の期待を洗い出す事ができる。(クラッシュしたらわかる)

Empirical Validation

デプロイしたValidationの利用状況。表1がわかりやすかった。

感想

正に自分が直面している課題を解決する内容だったので先人に感謝。

データエラーの例が生々しくて良かった。思いあたるフシがありすぎて「推論時と訓練時の前処理が別のコードで動いていて片方だけ直してしまうだと……うっ頭が」という状態で読んだ。しかし他の会社でも同じ事が起きているんだなと若干ほっとした。

次はOSS実装版のTensorflow Data Validationを触ってみようと思います。

『効果検証入門』がアプリケーション開発エンジニアにとって得る物が多い本だった

読みました。アプリケーション開発エンジニア視点で読んで同僚に勧められる素晴しい内容でした。本稿はエンジニア視点のレビューになります。

効果検証入門〜正しい比較のための因果推論／計量経済学の基礎
技術評論社 (2019/1/18)
安井 翔太 (著), 株式会社ホクソエム (監修)
Kindle版/紙版両方あり

目次と構成

序 嘘っぱちの効果とそれを見抜けないデータ分析

1章 セレクションバイアスとRCT

2章 介入効果を測るための回帰分析

3章 傾向スコアを用いた分析

4章 差分の差分法（DID）とCausalImpact

5章 回帰不連続デザイン（RDD）

付録 RとRStudioの基礎
終 因果推論をビジネスにするために

まず効果検証とは何かという導入と共にビジネスの現場でありがちな誤りのある検証について解説があります。この誤りの原因となるセレクションバイアスと理想的な比較方法であるランダム化比較試験が1章です。以後の章はランダム化比較試験ができない状況において効果検証にどう取り組むか主要なアプローチ毎の手法の解説と実践例があります。

1章 セレクションバイアスとRCTより

想定読者は「効果検証を行なう必要のあるエンジニアやデータサイエンティスト」となっているのでバリバリ手を動かしてコードが書ける人が対象なのでしょう。文中の操作は全てRのコードが付いています。私はRがわからないのでPythonで再実装しつつ読み進めました。

どんな視点で読んだか

まず私はプロダクト開発エンジニアで、説明のためのモデルよりも予測のためのモデルを作る事が多く、Rはほぼ使った事がなく普段はPythonを書く人間です。機能リリース後の効果検証は解釈の容易さから主にランダム化比較試験を採用しますが、稀に適切なランダム割り当てができないケースで観察研究に頼る事があります。

良かった点

予測のためのモデル(機械学習)に慣れ親しんだ人間が持つ疑問に答えている

機械学習エンジニアは因果推論・計量経済学で用いられる線形回帰モデルよりも予測と汎化性能を重視したより複雑なモデルを扱います。なので当然「クロスバリデーションしなくていいのか?」とか「対数変換やスケーリングした方が精度が出るのでは?」と思うわけです。この様な予測をメインにしている人が効果検証における線形回帰モデルを見た時の違和感の解説が2章の終りにあります。

正しい比較が何の役に立つのか言及している

正確な効果検証が価値を生むビジネスケースとそうでないケースが挙げられています。因果推論で価値を生めるかどうかはビジネスの構造に依存するというのは実務者が持っておいて損がない心構えでしょう。最終章に

もし因果推論でビジネスに対する価値を発揮したいのであれば、「正しい情報がビジネスの価値になる」という構造を持っている環境へ移るか、もしくはそのような環境を作ることを強くお勧めします。

と記述があります。エンジニアは正に「正しい情報が価値を生む」側でしょう。私の現場では「機能開発すべきかどうかの事前調査」と「リリース後の効果検証」が因果推論が絡むタスクです。事前調査は「変数xがyに寄与しているならxを利用した機能開発を検討する」といった物で、これを見誤ると意味の無い機能を作ってしまいます。

説明モデルの作り方の参考としても若手に勧められる

新卒エンジニアが部署に配属される時期ですが、エンジニアはコンピューターサイエンス・機械学習よりのスキルを持つ事が多く。極端な例では「ディープラーニングは判るけど一般化線形モデルは知らない」といった事もあります。ただ実務では効果検証のために線形モデルを利用する事はあるので線形モデルの応用や説明モデルの作り方といった計量経済学寄りの知識も持って欲しい訳です。現場のエンジニアに計量経済学の入口として渡すのもアリかなと思いました。

分析コードの難しさがわかる

私は書籍中のR実装をPythonで書き直しながら読み進めましたが、OLSで線形モデルをフィットして係数を求める所までは簡単に再現ができましたが。そこから先のマッチングやIPWとなると途端に同じ結果を出すのが難しくなりました。本の結果という正解がある状況なので自分の仕込んだバグに気づけましたが、正解が無い状況ではコードがバグっているのか仮説が間違っていて期待通りの結果にならなかったのか見極めが非常に難しい事に気づかされます。バグが無くとも利用するライブラリを変えるとまた結果が変わります。

ただ「傾向スコアマッチングをした時には共変量のバランスを確認する」等の因果推論の手法が機能しているかどうかの確認ポイントと前提とする仮定がしっかり解説されており、各手法は知っていても実際に手を動かした事がない人のガイドになる内容になっています。

疑問が残った点

対数を用いた回帰分析 (2.4.3節) で、目的変数の対数を取った時の係数βが 0.1であれば10%引き上げると解釈できるとあったので手元で実験してみたが上手くいかなかった。xが1増える毎にyが倍(100%増)になるようなデータで係数βを求めても1にならないので、βが小さい時のみこの解釈ができる等の制約がありそう。この現象について教えて頂いたので最後に追記ました。

標準化平均差(Average Standardized Absolute Mean distance: ASAM)の定義がわからなかった。本文では「平均の差をその標準誤差で割った値」とあるが、標準誤差はサンプルサイズが増えた時にゼロに近づくのでASAMが発散してしまう気がした。ASAMを利用している論文はいくつも見つかるが定義そのものの数式がなかなか見つからない。平均の差を全標本の標準偏差で割った値が正解?

本だけでわからなかった点ですが、formula定義に出てくる I(re74^2) の I() が何かわからなかったのでRのドキュメントを調べました。混乱を避けるためのただの括弧みたいですね。

まとめ

以前からお世話になっている安井さんが実務者向けの因果推論の本を上梓されたとの事で非常に興味があったのですが、期待を裏切らない内容でした。安井さんは5年程前に予測性能に重きを置く機械学習と説明に重きを置くための因果推論・計量経済学の違いを教えてくれた方であり、それで自分の視野が一気に広がった経緯があります。なので若干バイアスのかかったレビューになっている事はご容赦ください。

因果推論は以前から興味があったもののRCT以外はほぼ使った事がなかったので、実務で利用する際の手順や注意点は非常に参考になりました。あとRが凄いので分析業務は素直にRを使おうという気持ちになりました。

追記

係数を解釈する時に利用している近似はマクローリン展開だから、ゼロから離れると二次以降の項が無視できなくなってズレが大きくなると教えてもらいました。プロットするとこうなります。