回答:
信用モデルの構築では、推論の拒否は、申請プロセスで拒否された信用口座のパフォーマンスを推論するプロセスです。
アプリケーションの信用リスクモデルを構築するときは、「ドアを介して」適用できるモデルを構築する必要があります。つまり、すべてのアプリケーションデータを信用リスクモデルに入力し、モデルがリスクレーティングまたは確率を出力します。デフォルトの。回帰を使用して過去のデータからモデルを構築する場合の問題は、過去の承認されたアプリケーションについてのみアカウントのパフォーマンスを把握していることです。ただし、申請後にドアに送り返したため、拒否のパフォーマンスはわかりません。これにより、モデルで選択バイアスが発生する可能性があります。モデルで過去の「承認」のみを使用する場合、モデルは「ドアを介した」母集団ではうまく機能しない可能性があるためです。
拒絶推論に対処する方法はたくさんありますが、それらはすべて物議を醸しています。ここでは簡単な2つの方法について説明します。
「過去の拒否を悪いものとして定義する」とは、拒否されたすべてのアプリケーションデータを取得し、モデルの構築時に破棄するのではなく、それらすべてを悪いものとして割り当てます。この方法は、モデルを過去の承認/拒否ポリシーに大きく偏らせます。
「小包」はもう少し洗練されています。それはで構成されています
ステップ3で良いか悪いかの割り当てを行うにはさまざまな方法があり、このプロセスは繰り返し適用することもできます。
前に述べたように、拒否推論の使用は物議を醸すものであり、モデルの精度を高めるためにそれをどのように使用できるかについて簡単な答えを出すことは困難です。この件については、他の人を引用するだけです。
Jonathan CrookとJohn Banasik、Reject推論は本当にアプリケーションスコアリングモデルのパフォーマンスを向上させますか？
第1に、却下された申請者の割合が非常に高い場合でも、承認された申請者についてのみパラメーター化されたモデルを改善する余地は控えめに見えます。拒否率がそれほど大きくない場合、その範囲は非常に小さいように見えます。
デビッドハンド、「信用業務における直接推論」、クレジットスコアリングハンドブック、2001年に掲載
いくつかの方法が提案され、使用されていますが、それらのいくつかは明らかに貧弱であり、推奨されるべきではありませんが、追加情報が得られない限り、普遍的な適用性に固有の最良の方法はありません。つまり、最良の解決策は、拒否地域に該当する申請者に関する情報を（おそらく、一部の潜在的な拒否にローンを付与することによって）取得することです。
以前のコメントの@GabyLP。私の経験に基づいて、そのようなクライアントを2つの部分に分割し、確率に従って両方の分割に重みを割り当てることができます。たとえば、拒否されたクライアントのPDが10％の場合、このクライアントから2つのクライアントを作成できます。最初にターゲット変数1と重み0.1があり、2番目にターゲット変数0と重み0.9があります。
クライアントの受け入れられたサンプル全体の重みは== 1になります。
これはロジスティック回帰では機能しますが、ツリーベースのモデルでは機能しません。