답변:
신용 모델 구축에서 거부 추론은 신청 프로세스에서 거부 된 신용 계정의 성과를 유추하는 프로세스입니다.
응용 프로그램 신용 위험 모델을 작성할 때 " 통과 "적용 가능성 이있는 모델 , 즉 모든 응용 프로그램 데이터를 신용 위험 모델에 입력하고 모델에서 위험 등급 또는 확률을 출력하려고합니다. 기본값입니다. 과거 데이터에서 모델을 작성하기 위해 회귀를 사용할 때의 문제는 과거에 승인 된 응용 프로그램에 대해서만 계정의 성능을 알고 있다는 것입니다. 그러나, 우리는 거부 한 후에는 거부 한 결과를 모릅니다. 모델에서 과거의 "수락"만 사용하는 경우 "문을 통과하는"모집단에서 모델의 성능이 저하 될 수 있기 때문에 모델 에서 선택 편차 가 발생할 수 있습니다 .
거부 추론을 처리하는 방법에는 여러 가지가 있으며, 모두 논란의 여지가 있습니다. 여기에 간단한 두 가지를 언급하겠습니다.
"과거 거부를 불량으로 정의"는 거부 된 모든 애플리케이션 데이터를 단순히 취하고 모델을 빌드 할 때이를 폐기하는 대신 모든 불량을 지정합니다. 이 방법은 과거의 수락 / 거부 정책을 향해 모델을 크게 편향시킵니다.
"소포"는 조금 더 정교합니다. 그것은 구성
3 단계에서 할당을 양호 또는 불량으로 지정하는 방법에는 여러 가지가 있으며이 프로세스를 반복적으로 적용 할 수도 있습니다.
앞에서 언급했듯이 거부 추론을 사용하는 것은 논란의 여지가 있으며 모델의 정확도를 높이는 데 어떻게 사용할 수 있는지에 대한 직접적인 대답을하기가 어렵습니다. 이 문제에 대해 간단히 다른 사람들을 인용하겠습니다.
Jonathan Crook과 John Banasik, 추론을 거부하면 애플리케이션 스코어링 모델의 성능이 실제로 향상됩니까?
첫째로, 많은 비율의 지원자가 거부되는 경우에도 수용된 모델에 대해서만 매개 변수가 지정된 모델을 개선 할 수있는 범위는 크지 않습니다. 거부율이 그렇게 크지 않은 경우, 그 범위는 실제로 매우 작은 것으로 보입니다.
David Hand, "신용 운영에 대한 직접 추론", 2001 년 신용 평가 핸드북에 등장
몇 가지 방법이 제안되어 사용되고 있으며, 그중 일부는 명확하게 좋지 않으며 권장해서는 안되지만 추가 정보를 얻지 않는 한 보편적으로 적용 할 수있는 가장 좋은 방법은 없습니다. 즉, 가장 좋은 해결책은 거부 지역에 해당하는 신청자에 대한 추가 정보를 얻는 것입니다 (아마도 일부 거부에 대한 대출을 허용하여).
이전 의견의 @GabyLP. 내 경험을 바탕으로 이러한 클라이언트를 두 부분으로 나누고 확률에 따라 두 분할에 가중치를 할당 할 수 있습니다. 예를 들어 거부 된 클라이언트의 PD가 10 % 인 경우이 클라이언트에서 두 클라이언트를 만들 수 있습니다. 첫 번째는 목표 변수 1과 가중치 0.1을, 두 번째는 목표 변수 0과 가중치 0.9를 갖습니다.
허용 된 전체 클라이언트 샘플의 가중치는 == 1입니다.
이것은 로지스틱 회귀와 함께 작동하지만 트리 기반 모델에서는 작동하지 않습니다.