予測モデルが役に立たないことを理解する方法

機械学習に基づいて製品を作成する場合、回避したい状況が発生します。 このテキストでは、仕事で遭遇した8つの問題を分析します。

私の経験は、クレジットスコアリングモデルと産業企業向けの予測システムです。 このテキストは、開発者とデータ科学者が有用なモデルを構築し、マネージャーがプロジェクトに失敗しないようにするのに役立ちます。

このテキストは、会社を宣伝するためのものではありません。 これは、LLC「カモミール」という会社でのデータ分析の実践に基づいています。 「私たち」とは、自分と想像上の友人のチームを意味します。 私たちが作成したすべてのサービスは、特定のクライアント向けに作成されたものであり、他の人に販売または譲渡することはできません。

どのモデルと何のために？

予測モデルを、予測を行うアルゴリズムとし、履歴データに基づいてビジネスに優しい意思決定を自動的に行うことを可能にします。

私は考慮しません：

• 本番環境に入らないデータの1回限りの調査。
• 何か（たとえば、広告のクリック可能性）を監視するが、それ自体は決定しないシステム。
• アルゴリズムのためのアルゴリズム、すなわち ビジネスに直接有益ではありません（たとえば、仮想男性に歩くことを教える人工知能）。

私は教師と学習アルゴリズムについて話します。 「見た」ペアの多くの例（X、Y）があり、XについてYの見積もりを作成できるようになりました。Xは、予測時に既知の情報です（たとえば、クライアントが記入したローン申込み）。 Y-これは、決定を下すために必要な以前は不明な情報です（たとえば、クライアントが期限内にローンを支払うかどうか）。 決定自体は、モデル外の単純なアルゴリズム（たとえば、デフォルトの予測確率が15％を超えない場合にローンを承認する）によって行うことができます。

モデルを作成するアナリストは、原則として、予測エラーの指標 、たとえば平均誤差（MAE）や正解の割合（精度）に依存します 。 このようなメトリックにより、2つのモデルのどちらがより正確に予測するか（および、たとえばロジスティック回帰をニューラルネットワークに置き換える必要があるかどうか）をすばやく理解できます。 しかし、主な質問、 およびモデルの有用性は 、彼らが常に答えを与えるとは限りません。 たとえば、クレジットスコアリングのモデルでは、98％の顧客が「良い」データで98％の精度を非常に簡単に達成でき、全員を「良い」と連続して呼びます。

起業家またはマネージャーの観点から、どのモデルが有用であるかは明らかです。 来年の新しいスコアリングモデルの導入により、5,000万ルーブルの損失をもたらす3,000人の顧客を拒否し、1,000万ルーブルの利益をもたらす5,000人の新規顧客を承認することが可能である場合、モデルは明らかに良好です。 もちろん、モデル開発の段階では、これらの量を正確に知ることはほとんどありません（それでも-事実とはほど遠い）。 しかし、プロジェクトの経済的利益をより早く、より正確かつ正直に評価するほど、より良い結果が得られます。

問題

非常に多くの場合、一見良好な予測モデルを構築しても、期待される成功につながりません：実装されていないか、長い遅延で実装されているか、数十のリリース後にのみ正常に動作を開始するか、実装後数か月で正常に動作を停止するか、まったく動作しません...アナリストはデータから最大の予測力を絞り出し、開発者はモデルが超高速で動作し、クラッシュしない環境を作成し、マネージャーはあらゆる努力をしました 最初の2人が時間通りに作業を完了できるようにします。 なぜ彼らはトラブルに巻き込まれたのですか？

1.モデルはまったく必要ありません

成熟後のビールの強さを予測するモデルを構築しました（実際、ビールでもアルコールでもありませんでしたが、本質は似ています）。 タスクは次のように設定されました。発酵の開始時に設定されたパラメーターが最終ビールの強さにどのように影響するかを理解し、それをよりうまく管理する方法を学びます。 このタスクは楽しくて有望に思えたので、実際には最終的な要塞は顧客にとってそれほど重要ではないことがわかりました。 たとえば、ビールが必要な8％の代わりに7.6％になったとき、彼はそれを単に強いものと混ぜて、望ましい程度を達成します。 つまり、完璧なモデルを構築したとしても、利益はありません。

この状況はかなりばかげているように聞こえますが、実際には常に発生しています。 マネージャーは「面白いから」、または単にトレンドになっているため、機械学習プロジェクトを開始します。 これは本当に必要ではないという認識はすぐには来ないかもしれませんし、その後長い間拒否されます。 時間が無駄になったことを認めて喜んでいる人はほとんどいません。 幸いなことに、このような障害を回避する比較的簡単な方法があります。プロジェクトを開始する前に、理想的な予測モデルの効果を評価してください。 未来を正確に知っているオラクルを提供された場合、いくら支払うつもりですか？ 結婚による損失がすでに少額である場合、おそらく結婚の割合を最小限に抑えるために複雑なシステムを構築する必要はありません。

かつて、クレジットスコアリングチームに新しいデータソースが提供されました。大規模な食料品チェーンからの小切手です。 「あなたが何を買っているか教えてください。あなたが誰であるかを言います。」 しかし、購入者がロイヤルティカードを使用した場合にのみ、購入者の身元を特定できることがすぐに判明しました。 そのようなバイヤーのシェアはわずかであり、銀行の顧客との交差点で、彼らは入ってくるローン申請の5％未満になりました。 さらに、それらは最高の5％でした。ほとんどすべてのアプリケーションが承認され、それらの間の「デフォルト」のシェアはゼロに近くなりました。 たとえそれらのすべての「悪い」アプリケーションを拒否できたとしても、これによりクレジット損失は非常にわずかに減少します。 彼女は、モデルの構築、その実装、および店舗のリアルタイムデータベースとの統合のコストをほとんど回収できなかったでしょう。 したがって、彼らは1週間チェックをいじり、セカンダリ販売部門に渡しました。そのようなデータからより多くの利益が得られるでしょう。

しかし、私たちはまだビールモデルを完成させて導入しました。 結婚を減らすことはできませんが、プロセスの一部を自動化することで人件費を削減できることがわかりました。 しかし、これは顧客との長い議論の後で初めて理解できました。 そして、正直なところ、私たちは幸運でした。

2.モデルは率直に言って弱い

理想的なモデルが非常に有益であったとしても、それに近づくことができるという事実ではありません。 Xには、Yの予測に関連する情報がない場合があります。もちろん、Xからすべての有用な兆候を引き出したことを完全に確信できることはほとんどありません。 数か月間続く可能性のある機能予測は、通常、予測の最大の改善をもたらします。 しかし、あなたは反復的に作業することができます：ブレインストーミング-属性の作成-プロトタイプモデルのトレーニング-プロトタイプのテスト。

プロジェクトの最初の段階で、大企業を集めてブレーンストーミングを行い、さまざまな兆候を考え出すことができます。 私の経験では、最も強力な属性は、多くの場合、完全なモデルから得られた精度の半分をもたらしました。 得点については、それはクライアントの現在のローン負荷であることが判明しました。ビールについては、同じグレードの以前のバッチの要塞でした。 数サイクル後に良好な兆候を見つけることができず、モデルの品質がゼロに近い場合、プロジェクトを最小化するか、緊急に追加データを探すことをお勧めします。

予測の精度だけでなく、それに基づいて行われた意思決定の質もテストする必要があることが重要です。 （テスト環境で）オフラインモデルの利点を常に測定できるとは限りません。 しかし、金銭的影響の評価に何らかの形で近づくメトリックを思い付くことができます。 たとえば、信用リスク管理者がアプリケーションの少なくとも50％の承認を必要とする場合（そうでない場合、販売計画は失敗します）、モデルの観点から50％の「悪い」顧客の割合を推定できます。 これは、ローンの未返済により銀行が被る損失にほぼ比例します。 このようなメトリックは、最初のプロトタイプモデルの作成直後に計算できます。 その実装の利点の大まかな評価があなた自身の人件費をカバーしない場合、それは考慮する価値があります：私達はよい予測を得ることさえできますか？

3.モデルを実装できません

アナリストによって作成されたモデルは、予測の精度と経済効果の両方の良い尺度を示していることがあります。 しかし、実稼働環境に導入し始めると、予測に必要なデータがリアルタイムで利用できないことがわかります。 時々、これは「未来からの」実際のデータであることがあります。 たとえば、ビールの強さを予測する場合、重要な要因は発酵の最初の段階の後の密度の測定ですが、この段階の最初で予測を使用したいと思います。 この機能の正確な性質について顧客と話し合っていなければ、役に立たないモデルを作成していたでしょう。

予測の時点でデータが利用可能な場合はさらに不愉快になりますが、技術的な理由によりモデルにロードできません。 昨年、私たちは、期限内に別のローンの支払いに失敗したクライアントと対話するための最適なチャネルを推奨するモデルに取り組みました。 ライブオペレーター（ただし、それほど安くはない）またはロボット（安いが、それほど効果的ではなく、顧客を激怒させる）は、債務者に電話をかけることができます。 強力な要因の1つは、昨日の電話の結果です。 しかし、使用できないことが判明しました。コールログは1日に1回、夜間にデータベースに転送され、昨日のデータがわかっている今日の明日のコールプランが作成されます。 つまり、予測が適用される前に2日の遅れでコールデータが利用可能になります。

私の実践では、リアルタイムデータにアクセスできないため、精度の高いモデルが棚上げされたり、すぐに破棄されたりすることが何度かありました。 時々、彼らはゼロからそれらをやり直さなければならず、「未来から」のサインを他のサインに置き換えようとしました。 これを防ぐには、モデルの最初の役に立たないプロトタイプを、できるだけ実際のデータストリームに近いデータストリームでテストする必要があります。 これにより、テスト環境の開発に追加コストが発生するように思われるかもしれません。 しかし、ほとんどの場合、「戦闘中」にモデルを起動する前に、いずれにしてもモデルを作成する必要があります。 モデルをできるだけ早くテストするためのインフラストラクチャの構築を開始すると、おそらく多くの興味深い詳細を時間内に学習できます。

4.モデルの実装は非常に難しい

モデルが将来のデータに基づいている場合、それに対してできることはほとんどありません。 しかし、利用可能なデータがあっても、モデルの実装は簡単ではないことがよくあります。 実装が非常に困難なため、このための人的資源が不足しているため、実装が無期限に遅れます。 モデルがすでに作成されている場合、開発者はこれまで何をしますか？

ほとんどの場合、すべてのコードをゼロから書き直します。 この理由はまったく異なる場合があります。 システム全体がJavaで記述されており、Pythonでモデルを使用する準備ができていない可能性があります。2つの異なる環境を統合すると、コードを書き換えるよりも多くの頭痛の種になります。 または、パフォーマンス要件が非常に高いため、すべてのプロダクションコードはC ++でのみ記述できます。そうしないと、モデルの動作が遅くなりすぎます。 または、SQLを使用してモデルをトレーニングするための属性の前処理を行い、データベースからそれらをアンロードしますが、データベースは存在せず、データはjsonリクエストの形式で送信されます。

モデルが1つの言語（Pythonである可能性が高い）で作成され、別の言語で適用される場合、その転送の痛みを伴う問題があります。 たとえばPMML形式などの既成のソリューションがありますが、それらの適用可能性には多くの要望が残されています。 これが線形モデルの場合、係数のベクトルをテキストファイルに保存するだけで十分です。 ニューラルネットワークまたはデシジョンツリーの場合、より多くの係数が必要になり、それらの書き込みおよび読み取りでミスを犯しやすくなります。 完全にノンパラメトリックなモデル、特に複雑なベイジアンモデルをシリアル化することはさらに困難です。 しかし、これでも、コードの作成は完全に任意であるサインの作成と比較すると簡単です。 さまざまなプログラミング言語の無害な関数log()



でさえ、さまざまなことを意味し、写真やテキストを操作するためのコードは言うまでもありません！

すべてがプログラミング言語で正常に機能していても、パフォーマンスの問題と、トレーニングと戦闘のデータ形式の違いは残ります。 別の考えられる問題の原因：モデルを作成するとき、アナリストは大規模なデータテーブルを操作するツールを積極的に使用しましたが、戦闘では、観測ごとに個別に予測を行う必要があります。 n * mマトリックスと1 * mマトリックスを使用して実行される多くのアクションは、非効率的または無意味です。 したがって、プロジェクトの最初からアナリストが必要な形式でデータを受信する準備をし、個々の観測値を処理できるようにすることは有用です。 教訓は前のセクションと同じです。パイプライン全体のテストをできるだけ早く開始してください。

プロジェクトの最初から、生産的なシステムの開発者と管理者がモデルが動作する環境について考えることは有用です。 最小限の変更でデータサイエンティストのコードを実行させるのが彼らの力です。 予測モデルを定期的に実装する場合、負荷管理、フォールトトレランス、およびデータ転送を提供するプラットフォームを一度作成する（または外部プロバイダーで探す）価値があります。 その上で、新しいモデルをサービスとして起動できます。 これを行うことが不可能または不採算である場合は、モデル開発者と事前に制限について話し合うことが役立ちます。 おそらくあなたは彼とあなた自身を長時間の不必要な仕事から救うでしょう。

5.実装中に愚かなエラーが発生する

私が銀行に来る数週間前に、彼らは第三者プロバイダーから信用リスクモデルを立ち上げました。 サプライヤから送信された回顧サンプルでは、​​モデルのパフォーマンスが良好であり、承認された顧客の中で非常に貧弱な顧客を強調しています。 したがって、リアルタイムで予測が届き始めると、すぐに予測を適用し始めました。 数日後、誰かが予想よりも多くのアプリケーションを拒否していることに気付きました。 その後-入ってくる予測の分布は、テストサンプルにあったものとは異なること。 彼らは理解し始め、予測には反対の符号が付いていることに気付きました。 借り手が悪い確率を受け取るのではなく、彼が良い確率を受け取りました。 数日間、私たちは最悪ではなく最高の顧客への信用を拒否しました！

このようなビジネスロジックの違反は、ほとんどの場合、モデル自体ではなく、兆候の準備、またはほとんどの場合、予測の適用で発生します。 それらが標識の間違いよりも明白でない場合、それらは非常に長い間見つけることができません。 この間、明確な理由はありませんが、モデルは予想よりもうまく機能しません。 これを防ぐための標準的な方法は、意思決定戦略のあらゆる部分に対して単体テストを行うことです。 さらに、意思決定システム全体（モデル+その環境）全体をテストする必要があります（はい、はい、これを3つのセクションで繰り返します）。 しかし、これはすべての人をトラブルから救うわけではありません。問題はコードにあるのではなく、データにある可能性があります。 このようなリスクを軽減するために、データストリーム全体（この場合はローンアプリケーション）ではなく、その小さな代表的なシェア（たとえば、ランダムに選択されたアプリケーションの10％）に重大なイノベーションを開始できます。 A / Bテストは一般的に便利です。 そして、あなたのモデルが本当に重要な決定に責任がある場合、そのようなテストは多くの時間をかけて行われる可能性があります。

6.モデルは不安定です。

モデルはすべてのテストに合格し、単一のエラーなしで実装されました。 あなたは彼女が最初に下した決定を見て、それらはあなたにとって意味があるように見えます。 彼らは完璧ではありません-ビールの17番目のバッチはかなり弱いことが判明し、14番目と23番目のビールは非常に強かったが、一般的にはすべてが悪くはありませんでした。 1〜2週間経つと、A / Bテストの結果を見続け、強すぎるパーティが多すぎることを理解します。 これについて顧客と話し合うと、彼は最近、麦汁を沸騰させるためにタンクを交換したため、ホップの溶解レベルが上がる可能性があると説明しています。 あなたの内なる数学者はinります。「どうしてそうなの！あなたは私に一般集団を代表しない訓練サンプルをくれた！これはデマだ！」 しかし、あなたは自分自身をまとめて、トレーニングサンプル（過去3年間）で溶解したホップの平均濃度が安定していないことに気付きました。 はい、今ではかつてないほど高くなっていますが、以前は急激なジャンプと落下がありました。 しかし、彼らはあなたのモデルに何も教えませんでした。

別の例：2007年の危機の後、統計手法に対する投資家コミュニティの信頼は大きく損なわれました。 その後、アメリカの住宅ローン市場は崩壊し、世界経済全体を引っ張った。 信用リスクの評価に使用されたモデルは、すべての借り手が同時に支払いを停止できることを示唆していませんでした。トレーニングサンプルにそのようなイベントがなかったためです。 しかし、主題に精通している人は、精神的に既存の傾向を継続し、そのような結果を予測することができます。

モデルを適用するデータストリームが静止している、つまり 統計的特性は時間とともに変化しません。 次に、最も一般的な機械学習法、ニューラルネットワーク、および決定的なツリーに対する勾配ブースティングがうまく機能します。 これらの方法は両方とも、トレーニングデータの補間に基づいています。ニューロン-ロジスティックカーブ、ブースティング-区分的定数関数による。 それらは両方とも、外挿のタスク-トレーニングセット（より正確には、 凸包 ）の外側にあるXの予測-に非常にうまく対処できません。

 # coding: utf-8 #  ,    import numpy as np import matplotlib.pyplot as plt from matplotlib import rc rc('font', family='Verdana') from sklearn.ensemble import GradientBoostingRegressor from sklearn.neural_network import MLPRegressor from sklearn.linear_model import LinearRegression #   np.random.seed(2) n = 15 x_all = np.random.randint(20,size=(n,1)) y_all = x_all.ravel() + 10 * 0.1 + np.random.normal(size=n) fltr = ((x_all<=15)&(x_all>=5)) x_train = x_all[fltr.ravel(),:] y_train = y_all[fltr.ravel()] x_new = x_all[~fltr.ravel(),:] y_new = y_all[~fltr.ravel()] x_plot = np.linspace(0, 20) #   m1 = GradientBoostingRegressor( n_estimators=10, max_depth = 3, random_state=42 ).fit(x_train, y_train) m2 = MLPRegressor( hidden_layer_sizes=(10), activation = 'logistic', random_state = 42, learning_rate_init = 1e-1, solver = 'lbfgs', alpha = 0.1 ).fit(x_train, y_train) m3 = LinearRegression().fit(x_train, y_train) #   plt.figure(figsize=(12,4)) title = {1:'     ', 2:',     '} for i in [1,2]: plt.subplot(1,2,i) plt.scatter(x_train.ravel(), y_train, lw=0, s=40) plt.xlim([0, 20]) plt.ylim([0, 25]) plt.plot(x_plot, m1.predict(x_plot[:,np.newaxis]), color = 'red') plt.plot(x_plot, m2.predict(x_plot[:,np.newaxis]), color = 'green') plt.plot(x_plot, m3.predict(x_plot[:,np.newaxis]), color = 'orange') plt.xlabel('x') plt.ylabel('y') plt.title(title[i]) if i == 1: plt.legend(['', '', ' '], loc = 'upper left') if i == 2: plt.scatter(x_new.ravel(), y_new, lw=0, s=40, color = 'black') plt.show()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のより単純なモデル（線形モデルを含む）は、より適切に推定されます。 しかし、それらが必要であることをどのように理解するのですか？ 相互検証 （相互検証）が役立ちますが、すべてのデータがランダムに混合されるクラシックではなく、 skelearnのTimeSeriesSplitのようなものです。 その中で、モデルは瞬間tまでのすべてのデータでトレーニングされ、この瞬間以降のデータでテストされます。 このようなテストの品質が良いことは、たとえ過去とわずかに異なっていても、モデルが未来を予測できることを願っています。

線形依存など、強力な依存関係をモデルに導入するだけで、プロセスの変更に十分に適応できる場合があります。 これが望ましくないか十分でない場合は、より普遍的な適応性の作成方法を考えることができます。 最も簡単な方法は、定数に対してモデルを較正することです。予測から、以前のn個の観測値の平均誤差を減算します。 加法定数だけではない場合、モデルをトレーニングするときに、観測値を再重み付けできます（たとえば、 指数平滑法の原理により）。 これは、モデルが最新の過去に焦点を当てるのに役立ちます。

モデルが単純に安定している必要があると思われる場合でも、自動監視を開始すると便利です。 彼は、予測値のダイナミクス、予測自体、モデルの主な要因、およびあらゆる種類の品質指標を説明できます。 モデルが本当に良ければ、それは長い間あなたと共にあります。 したがって、毎月手動でモデルのパフォーマンスを確認するよりも、テンプレートを1回操作する方が適切です。

7.トレーニングサンプルは実際には代表的なものではありません

サンプルの非代表性の原因は、時間の変化ではなく、データを生成したプロセスの特徴であることがあります。 私が働いていた銀行は以前にポリシーを持っていました。つまり、現在の債務の支払いが収入の40％を超える人々に融資をすることはできません。 一方で、これは合理的です。なぜなら、特に危機の際には、高い信用負荷がしばしば破産につながるからです。 一方、収入とローンの両方の支払いを概算することしかできません。 おそらく、私たちの請求されていないクライアントの一部は、実際にはるかに優れていたのでしょう。 いずれにせよ、月に20万を稼ぎ、そのうち100人が住宅ローンを提供するスペシャリストは、有望なクライアントになり得ます。 そのようなクレジットカードを拒否することは利益の損失です。 このモデルが非常に高いクレジット負荷でも顧客を適切にランク付けすることを期待できます...しかし、これは正確ではありません。トレーニングサンプルにそのようなものがないためです！

幸運なことに、私の同僚は、到着の3年前に、恐ろしいとはいえ単純なルールを導入しました。ほとんどすべての政治家を迂回して、クレジットカードのランダムに選択されたアプリケーションの約1％を承認します。 この1％は銀行に損失をもたらしましたが、モデルをトレーニングおよびテストできる代表的なデータを取得することができました。 したがって、私は一見非常に貸されている人々の間でさえあなたが良い顧客を見つけることができることを証明することができました。 その結果、クレジットロードの推定値が40％から90％である人々にクレジットカードを発行し始めましたが、予想されるデフォルトの確率に対するカットオフしきい値はより厳しくなりました。

そのような純粋なデータのストリームがなければ、モデルが通常40％を超える負荷を持つ人々をランク付けすることを経営者に納得させることは困難です。 おそらく、0〜20％の負荷のサンプルで彼女をトレーニングし、20〜40％の負荷のテストデータでモデルが適切な決定を下せることを示します。 しかし、フィルタリングされていないデータの狭い細流は依然として非常に有用であり、エラーの価格がそれほど高くない場合、それを持っている方が良いです。 GoogleのML開発者であるMartin Zinkevichが、機械学習に関するマニュアルで同様のアドバイスを提供しています 。 たとえば、電子メールをフィルタリングする場合、アルゴリズムによってスパムとしてマークされた電子メールの0.1％を引き続きユーザーに表示できます。 これにより、アルゴリズムエラーが追跡および修正されます。

8.予測が非効率的に使用されている

原則として、モデル予測に基づいて下される決定は、ビジネスプロセスのごく一部であり、奇妙な方法でそれと対話することができます。 たとえば、自動アルゴリズムによって承認されたほとんどのクレジットカードアプリケーションは、カードが発行される前に、引受人によって承認される必要があります。 クレジットの負担が大きいアプリケーションの承認を開始したとき、引受会社は引き続きそれらを拒否しました。 おそらく、彼らはすぐに変更について学習しなかったか、または単に珍しい顧客に責任を負わないと決めたのでしょう。 このようなアプリケーションの承認を開始するために、「高負荷のためこのクライアントを拒否しないでください」などのクレジットスペシャリストのラベルに引き渡す必要がありました。 しかし、この問題を特定し、解決策を考え出して実装しましたが、銀行が受け取る利益が少なくなるまでに多くの時間が経過しました。 道徳：事前にビジネスプロセスの他の参加者に同意する必要があります。

モデルを導入または更新する利点を無効にするために、別のユニットが不要な場合があります。 自分のマネージャーと許容限度に同意するのは十分に悪いです。 おそらく、彼はモデルで選択された顧客の承認を開始する準備ができていますが、アクティブなローンが1つしかない場合にのみ、延滞は一度もありませんでした。 説明したセグメントのほぼ全体がすでに承認されている場合、モデルはあまり変わりません。

ただし、モデルを適切に使用すれば、ヒューマンファクターが役立ちます。 衣料品店の従業員に、既存の注文に基づいてクライアントに他に提供できるものを伝えるモデルを開発したとします。 このようなモデルは、非常に効果的にビッグデータを使用できます（特に店舗がネットワーク全体である場合）。 ただし、モデルには、たとえばクライアントの外観に関する関連情報の一部は含まれていません。 したがって、クライアントとまったく同じ衣装を推測する精度は低いままです。 ただし、人工知能と人間を組み合わせるのは非常に簡単です。モデルは売り手に3つのアイテムを伝え、彼はそれらから最も適切なものを選択します。 すべての売り手にタスクを正しく説明すると、成功することができます。

おわりに

予測モデルを作成してビジネスに統合する際に発生した主要な障害のいくつかを経験しました。 ほとんどの場合、これらは数学的な問題ではなく、組織的な問題です。モデルはまったく必要ないか、曲がったサンプルに基づいて構築されているか、既存のプロセスやシステムに統合するのが困難です。 単純な原則を順守すれば、このような失敗のリスクを減らすことができます。

1. 予測の精度と経済効果の合理的で測定可能な尺度を使用します。
2. 最初のプロトタイプから始めて、時系列のデータストリームでテストします。
3. 予測だけでなく、データの準備から意思決定までのプロセス全体をテストする

このテキストが、誰かが自分のプロジェクトをよく見て、愚かな間違いを避けるのに役立つことを願っています。

ROC-AUCとEr-squaresに感謝します！