기본 콘텐츠로 건너뛰기

Partial Dependence Plot(PDP)

Partial Dependence Plot

어떤 black-box model 내부에서 각 feature가 prediction에 어떻게 영향을 주는지를 시각적으로 보여주는 기법이다.

기본 원리

validation dataset에서 구하고자하는 feature의 백분위수(percentile)를 전체적으로 균등하게 추출한다음 각 percentile값만을 feature의 값으로 가지는 여러가지 dataset을 만든다. 예를들면 11개의 백분위수로 나누면 feature값으로 0%백분위수만을 가지는 dataset, 10% 백분위수만을 가진 dataset, ... 100% 분위수만을 가진 데이터셋 이렇게 11개의 dataset이 만들어진다.  이제 각 dataset을 이용해 prediction을 수행하면 해당 feature값이 변화함에 따라 predicted target이 어떻게 변하는지 알 수가 있다.

"YearBuilt"값의 변화에 대한 target response의 변화를 나타낸다.

좌측에서 첫번째 점이 첫 dataset으로 prediction을 수행한 결과로 이 값이 y축의 기준점(0)이 된다. 예제에서는 "YearBuilt"값이 1880일때의 예측값이 기준이다. 각각의 점들은 각 dataset으로 예측을 수행했을때의 값을 나타내고 파란영역은 그 분산을 나타낸다. 예제를 보면 알듯이, PDP를 통해 대략적인 상관관계를 유추 가능하다. 이 model에서 target은 'YearBuilt'와 강한 양의 상관관계를 가지고 있음을 알수 있다. 예제에서는 아니지만, 2차함수나 3차함수의 모양을한 non-linear한 상관관계를 보여줄 수도 있다.

2D PDP

PDP를 각각의 feature에 대해 모두 구할수 있는만큼, 여러개의 feature들을 변수로 주었을 때의 target response의 변화도 구할 수 있다. 이론적으로는 model의 전체 feature들의 집합의 모든 부분집합에 대한 PDP를 구할 수 있지만, 시각적으로 적절히 표현하기에는 원소가 2개인 부분집합이 최대 한계라고 할 수있다. 그 원소 2개짜리 부분 집합에대한 PDP가 2D PDP다. 2D PDP는 해당 feature쌍이 target response에 어떻게 영향을 주는지를 나타낸다.
색으로 구분된 영역으로 '1stFlrSF', '2ndFlrSF'쌍에 대한 target response값을 나타낸다.
 
'1stFlrSF'와 '2ndFlrSF'의 합이 일정한 부분을 따라 선을 긋는다면 그 선에 영역이 나란히 나타남을 알 수가 있다. 완벽하지는 않지만 '1stFlrSF'와 '2ndFlrSF'의 합에 target response가 비례한다는 것을 알 수가 있다.

Permutation Importance와의 차이

Permutation Importance : Model의 각 feature가 prediction에 얼만큼의 영향을 끼치는가?
= 각 feature와 target간의 상관관계 세기

Partial Dependence Plot : Model의 각 feature가 prediction에 어떻게 영향을 끼치는가?
= 각 feature와 target간의 상관관계

장, 단점 : Permutation Importance와 같다

장점

  • 별도의 재학습(re-training)과정이 필요가 없어서 빠르다. 학습은 예측보다 시간이 훨신 많이 걸린다.

단점

  • under or over-fitting된 model에 대해서는 model의 feature importance가 실제 feature-target간의 상관관계와는 상이할 수 있다. 언제까지나 model에 종속적인 속성임을 알아야한다.
  • 각 feature들이 모두 독립변수라는 가정을 한다. 이는 Model들이 실제로 그런 가정을 기반으로 학습되기 때문이기도 하다. 때문에 실제 dataset에서는 feature들간의 상관관계가 존재함에 따라 target과의 상관관계가 다를 수 있다.

적용


라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

윈도우 10 마우스(커서) 옆에 자꾸 Progress bar(진행중 아이콘)가 나타난다면

이 글은 윈도우10 사용자 중 자꾸만 마우스 커서 옆에 뭔가가 실행중이라고 진행 아이콘이 뜨는 사람에게 조그마한 희망을 주는 글 입니다. 또한 백그라운드에서 프로그램이 실행되는 경우는 아주 다양하니 이 글에서 제시하는 방법은 수많은 문제 중 한가지 문제의 해결책일 뿐임을 미리 알려드립니다. 본인은 원래 해당컴퓨터에서 바이러스에 걸릴만한 행위를 일체 하지않았다. 토렌트나 웹하드는 전혀 사용하지 않고 인터넷에서 파일도 대기업의 공인된 파일만 다운받아서 썼었다. 그러나 어느 날 부턴가 다음과 같은 현상이 발생하였다. 아무런 프로그램도 실행중이지 않지만 자꾸 마우스 아이콘에 실행중이라고 뜨는 문제였다. 이해를 돕기위한 삽화 나는 실행한 프로그램이 없지만 뭔가가 실행중이라는 것은 백그라운드 서비스가 원인이라는 것이다. 그렇다면 어떤 서비스가 다음과같은 현상을 야기했을까? 나는 작업관리자에서 의심가는 백그라운드 프로세스를 종료해보았다. 바로 vpwalletservice VP.Inc에서 배포한 프로그램이었다. 아니나 다를까 해당 프로세스를 삭제하자마자 현상은 사라졌다. 백그라운드 서비스인만큼 msconfig의 서비스 목록에서도 제거하였고 이제 확실히 이런 현상은 발생하지 않을 것이다. 해당 프로그램은 현재 여러 문제를 야기시키는 것으로 인터넷에서 유명하다. 얼마전에는 해당프로그램이 윈도우 부팅시에 start process as current user get session user token failed 메시지를 띄우게 만들어 부팅을 방해했던 문제도 직접 경험해 본적이있다. 이 경우에도 해결방법은 같다.
댓글 쓰기
자세한 내용 보기

Cubase : Serum 사용법(1) : 소개와 오실레이터, 필터, 모듈레이터의 사용법

큐베이스 가상악기 Serum 사용법(1) Serum 소개와 오실레이터, 필터, 모듈레이터의 사용법 1. Serum 이란? 큐베이스에서 사용가능한 가상악기 VST 플러그인 형태로 나온 Software Synthesizer 이다. 사운드의 시각화가 잘 되어있는게 특징이며, 웨이브테이블을 통해 다체로운 사운드를 만들 수 있는게 특징이다. Serum 사용 화면. 2. Serum 의 구조 소프트웨어 신디사이저는 구조는 다음과 같고 Serum도 이러한 구조로 이루어져있다. 신디사이저의 구조 여기에서 각 모듈들이 하는 역활은 다음과 같다. 오실레이터 (Oscillator) : 소리를 발진 시킨다. 필터 (Filter) : 오실레이터로부터 받은 소리를 필터링 한다. 엠프 (Amp) : 필터를 거쳐온 소리를 증폭시켜서 최종적으로 출력한다. 모듈레이터 (Modulator) : 각 모듈(오실레이터, 필터, 엠프)에 ENV, LFO 신호를 줘서 변형을 준다. ENV (Envelope Generator) : ADSR의 패턴을 가지고 신디사이저의 모듈들을 컨트롤 할 수 있는 Envelope를 생성한다. 보통 키보드 게이트의 신호를 통해 작동되어 시간에 따라 변하는 전압(Envelope)을 생성한다. LFO (Low Frequency Oscillator) : 저주파 발진기로. 저주파 패턴을 만들어서 음성을 변조하는대 사용한다. 그리고 Serum에서 각 모듈의 위치는 다음과 같다. Serum의 모듈 위치 3. Serum 각 모듈별 사용법 - 오실레이터(Oscillator) 오실레이터에서 Osc A, B가 활성화 되어있다 오실레이터는 크게 Sub와 Noise, Osc A, Osc B로 이루어져 있다. Sub는 기본파형을 발생시킬수 있으며 Noise는 치지직거리는 배경 잡음을 발생시키고, Osc A와 B는 각각 웨이브테이블을 이용해 다양한 파형의 소리를 발진시킨다. 각 요소...
댓글 쓰기
자세한 내용 보기

C++ 프로그래밍에서의 메모리 제한(C++)

Visual C++에서는 배열을 선언할때 매모리 제한으로 258257까지만 할당할 수 있다고 한다. 따라서, 1차원 배열은 [258257]이 최대이고 이차원 대략 [508][508] 삼차원은 대략 [63][63][63]까지 할당할 수 있다고한다. 그래서 직접해봤다. 다음 코드를 작성하면 이런 결과를 볼 수 있다. #include <iostream> using namespace std; int main() {  int a[258258];  cin >> a[0]; return 0; } Unhandled exception at 0x0F3B9B32 (ucrtbased.dll) in example1.exe: 0xC00000FD: Stack overflow (parameters: 0x00000001, 0x01042FF4). 오 정말로 스텍오버플로우가 발생한다!!! 이번엔, 배열을 258257까지 선언해보았다. #include <iostream> using namespace std; int main() {  int a[258257];  cin >> a[0];  return 0; } Unhandled exception at 0x770AFA6E (ntdll.dll) in example1.exe: 0xC00000FD: Stack overflow (parameters: 0x00000001, 0x00602F74). 어라????!! 대체 어디까지 줄여야 스택오버플로우가 안뜨나 해봤다. 그 크기는 항상 달랐다. 대략 250000이하부터 안전해 지는 거 같다. 왠만하면 배열을 100000이상으로 안쓰는게 좋겠다. 게다가 변수를 하나만 선언해 놓고 쓰는것도 아니니까 실질적으로 선언할 수 있는 많이 줄어들 것이다. Dev C++에선 그 크기가 약간 다른거 같다. Dev C++을 이용해본 결과 배열을 [519828]...
댓글 쓰기
자세한 내용 보기