이 영역을 누르면 첫 페이지로 이동
천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

페이지 맨 위로 올라가기

천천히 꾸준히 조용히

천천히 꾸준히 조용히.. i3months 블로그

[Data Science] Decision Tree & Regularization

  • 2026.03.14 13:23
  • Computer Science/Data Science
반응형

 

 

 

Decision Tree는 데이터를 분류하기 위해 Y/N 으로 구성된 트리 구조로 이어붙인 모델. 아이디어는 굉장히 단순함.

그런데 이걸 어떻게 학습시키는지가 문제..

 

 

 

 

 

 

Training ML 모델 중 제일 많이 사용되는 모델으로, 딥러닝 모델처럼 Training Data를 완벽하게 설명할 수 있도록 학습된다는 공통점이 있음.

그러니 일단 오버피팅으로 만들고 Training과 Validate가 비슷해지도록 조작한다.

 

모델을 처음부터 적당히 학습시키려고 하면 어디에서 멈춰야 하는지에 대한 기준이 없음.

그러니 일단 Training Set을 제대로 설명하는 복잡한 모델을 만들고, Validation Set 성능을 보면서 Complexity를 줄여나가는 식으로..

딥러닝에서는 Early Stopping, Dropout 등으로 구현되고 Decision Tree에서는 Prunning, max_depth 제한으로 구현된다.

 

depth를 조작할 때는 Validation Accuracy를 사용한다.

depth가 커지면 Training Accuracy는 계속 오르지만 Validation Accuracy는 점점 떨어지고, 그 떨어지는 지점이 최적 depth.

 

Prunning은 서브트리 전체를 Leaf 노드로 교체했을 때 Validation 성능이 비슷하다면 더 단순한 쪽을 선택한다는 것. 

그런데 뒤에 설명할 Random Forest 방식이 훨씬 편함..

 

각 분기점에서 Feature를 기준으로 데이터를 둘로 나누고, 더 이상 나눌 수 없거나 종류가 하나만 남는 경우 그게 리프 노드가 된다.

 

어떤 질문을 선택해야지 데이터가 잘 분리될까? 

이걸 계산할 때는 Entropy개념을 사용한다.

 

노드 하나에 여러 클래스가 섞여있다면 엔트로피가 높고 클래스가 하나밖에 없다면 엔트로피가 0이다.

그러니 Weighted Entropy를 계산해 이 값이 가장 작은 split을 선택한다.

 

 

 

 

나눠진 두 자식 노드의 엔트로피를 각 노드의 비율로 가중평균 값을 계산함.

 

저거만 보고도 유추할 수 있듯 그리디하게 눈앞에서 가장 좋은 split을 고르기에 Training Data의 노이즈까지 학습하게 됨.

Feature간에 클래스가 잘 나뉘지 않는 경우 경계선이 매우 복잡해지고.. 이 복잡한 경계선은 Test Data에 fit하지 않게 된다.

 

오버피팅을 막기 위한 방식으로 여러가지가 있음. 

 

1. Random Forest

완전히 자라난 Decision Tree는 Training Data에 맞춰서 Overfit 되고, 데이터를 조금만 바꿔도 완전히 다른 트리가 나타난다.

그러니 Overfit된 트리 여러 개를 조합한다면 편향이 작고 분산도 낮아지지 않을까? 

이 아이디어를 Bagging이라고 부름. (Bootstrap AGGregatING)

 

원본 데이터에서 복원추출로 T개의 데이터셋을 생성하고, 각 데이터셋으로 Decision Tree를 구축한다.

예측 할 때는 T개의 Decision Tree의 결과를 다수결로 계산하는 식.

 

Bagging 으로는 제일 처음에 강한 Feature가 분리 기준으로 선택되니 트리가 서로 비슷해진다.

그러니 매 split마다 전체 Feature 중 무작위로 m개만 후보로 사용한다.

이러면 각 Decision Tree가 다른 방식으로 오버피팅되고 다양성이 확보됨.

 

 

2. Gradient Boosting

Bagging은 트리를 병렬로 만들어 다수결로 예측하는 방식이고, Boosting은 순차적으로 약점을 보완하는 방식이다. 

지금 모델의 잔차를 다음 모델에게 전달해 오차를 줄이는 방식임. 

 

수학적으로는 Gradient Descent와 동일한 방식임. 

Residual은 곧 MSE 손실과 비슷하기에.. 

그러니 Learning Rate를 결정할 때도 Gradient Descent에서 사용한 방식을 그대로 활용할 수 있다. 

새로운 트리를 더할 때 Learning Rate 만큼만 반영하는 방식.

 

 

Gradient Boosting은 Theta가 아니라 예측값 자체를 직접 업데이트한다.

즉, 잔차 방향으로 예측값을 조금씩 개선하는 방식임. 

 

Weak Learner를 모아서 강력한 모델 하나를 구축하는 것.

 

 

 


 

 

 

 

모델을 평가하고 하이퍼파라미터를 튜닝할 때는 Test Set을 여러 번 쓰면 안됨. 

Test Set 정보는 절대 절대 모델이 학습하면 안된다. 그러니 K-Fold Cross Validation을 사용한다.

 

 

 

 

최종 성능은 K번 Val 성능의 평균으로 측정되고, 이 값을 기준으로 모델을 선택하고 하이퍼파라미터를 튜닝한다. 

 

데이터가 정말 충분하다면 이걸 굳이 안해도 되지만.. 데이터가 적으면 해줘야 함.

실제 Accuracy를 모사하기 위해 전체 데이터를 k개의 fold로 나누고 성능 확인 후 각 모델의 성능을 측정해 평균 측정.

 

우선 머신러닝을 한다는 건, 데이터 분포가 있다는 것.

모든 데이터를 볼 수 없으니 모델을 가지고 테스트 한다는건데..

 

또 강조해보면 모델 튜닝에 Test Set이 노출되는건 절대로 막아야 함.

Validation을 테스트처럼 써야하는데 이걸 지키지 않는 논문들도 많다고 한다.. 

 

 

 


 

 

 

 

우리가 관측하는 모든 데이터에는 항상 노이즈가 섞여서 들어온다.

이 노이즈는 무작위성을 가지기에 데이터셋을 뽑을 때 마다 y값이 달라짐.

 

 

 

 

데이터셋이 2차식 형태를 띄고, 함수도 2차식 형태를 띈다면 잘 맞출 수 있지만, 더 낮은 차원을 사용하거나 더 높은 차원을 사용한다면 Variance가 너무 낮거나 또 너무 높아질 수 있다.

 

다만 데이터를 무작위로 뽑으면 Theta도 무작위이고, 함수도 무작위로 결정된다는게 중요함.

즉, 같은 입력에 대해서도 예측값이 학습마다 달라질 수 있다는 것.

 

이걸 기반으로 다시 개념을 정의해보자.

 

Model Bias : 여러 번 학습했을 때 예측값의 평균이 실제값에서 얼마나 체계적으로 벗어나는가? 

Model Variance : 학습 데이터가 조금 달라졌을 때 예측값이 얼마나 흔들리는가? 

Model Risk : 모델 예측값과 실제 관측값 사이의 평균 제곱 오차.

 

단순할수록 Bias가 높고, 복잡할수록 Variance가 높다.

최종 성능 지표로 Bias와 Variance를 동시에 반영하는 Model Risk를 사용한다.

 

 

 

 

식을 잘 정리해보면 Model Risk가 절대 조작할 수 없는 Irreducible Error, Bias, Variance로 구성됨을 확인할 수 있음.

 

Variance를 줄이려면 모델을 단순하게 만들어야 하는데 이러면 Bias가 올라가고.. Bias를 줄이려면 모델을 복잡하게 만들어야 하는데 이러면 Variance가 올라간다.

 

 

 

 

그러니 최적의 Point를 찾아야 함. 그게 그래프에서의 최소 지점이다.

 

최적의 Complexity를 찾은 후에는 저걸 직접 제어할 수 있어야 함. Regularization을 수행 할 수 있어야 한다.

Parameter가 너무 커지지 않도록 Q값을 도입한다. Q가 작으면 모델이 단순해지고, Q가 크면 복잡해진다.

 

 

 

 

 

 

 

 

Regularization이 없을 때의 OLS Theta Hat은 Loss를 완전히 최소화하는 지점에 위치해 파라미터 값이 굉장히 크다.

모델이 Training Data에 완전히 맞추기 때문. 

 

여기에 파라미터 합이 Q보다 작아야 한다는 Regularization을 걸어버리면 원래의 최솟값이 되는 지점은 제약 밖에 위치하기에 도달할 수 없고, 제약 영역 안에서 Loss가 가장 작은 Theta를 찾아야 함.

 

L1 에서는 제약 영역이 다이아몬드 형태로 이루어지고 L2 에서는 제약 영역이 원형으로 이루어진다.

원형에서는 등고선이 곡선 위에서 만나니 모든 Feature가 유지된다 정도만 알면 됨.

다이아몬드 형태에서는? Theta가 0이 될 가능성이 있어 Feature가 사라질 수도 있음.

 

 

 

 

L1이든 L2든 제약식을 사용할 때는 특정 영역 밖으로 나가면 안된다는 식을 풀어야 하기에 최적화하기 힘들다.

그런데 제약식을 페널티식으로 변형하면 최솟값을 찾는 문제로 바뀌게 되고, Gradient Descent를 그대로 사용할 수 있어 최적화하기 편함.

 

Q값이나 lambda값은 모델의 일부가 아닌 하이퍼파라미터일 뿐이니 마찬가지로 Validation Accuracy를 보고 결정하자.

 

 

 

 

반응형
저작자표시 (새창열림)

'Computer Science > Data Science' 카테고리의 다른 글

[Data Science] Regression & Classification  (0) 2026.03.07

댓글

이 글 공유하기

  • 구독하기

    구독하기

  • 카카오톡

    카카오톡

  • 라인

    라인

  • 트위터

    트위터

  • Facebook

    Facebook

  • 카카오스토리

    카카오스토리

  • 밴드

    밴드

  • 네이버 블로그

    네이버 블로그

  • Pocket

    Pocket

  • Evernote

    Evernote

다른 글

  • [Data Science] Regression & Classification

    [Data Science] Regression & Classification

    2026.03.07
다른 글 더 둘러보기

정보

천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

  • 천천히 꾸준히 조용히의 첫 페이지로 이동

검색

방문자

  • 전체 방문자
  • 오늘
  • 어제

카테고리

  • 분류 전체보기 (685)
    • Algorithm (205)
      • Data Structure (5)
      • Theory && Tip (33)
      • Baekjoon (166)
      • ALGOSPOT (1)
    • Spring (123)
      • Spring (28)
      • Spring Web MVC (20)
      • Spring Database (14)
      • Spring Boot (6)
      • Spring 3.1 (11)
      • Spring Batch (6)
      • Spring Security (16)
      • JPA (12)
      • Spring Data JPA (5)
      • QueryDSL (4)
      • eGovFramework (1)
    • Programming Language (74)
      • C (25)
      • C++ (12)
      • Java (19)
      • JavaScript (15)
      • Python (1)
      • PHP (2)
    • Computer Science (145)
      • Machine Learning (38)
      • Operating System (18)
      • Computer Network (28)
      • System Programming (22)
      • Universial Programming Lang.. (8)
      • Data Science (2)
      • Embedded Software (1)
      • Computer Architecture (4)
      • Compiler Design (11)
      • Computer Security (13)
      • BlockChain (0)
    • Database (21)
      • Database (7)
      • MySQL (3)
      • Oracle (3)
      • Redis (5)
      • Elasticsearch (3)
    • DevOps (20)
      • Docker && Kubernetes (8)
      • Jenkins (4)
      • Amazon Web Service (8)
    • Mobile (28)
      • Android (21)
      • Flutter (7)
    • 💡 솔루션 (17)
    • 👥 모각코 (12)
    • 💬 기록 (8)
    • 📚 공부 (7)
    • -------------- (25)

최근 글

나의 외부 링크

메뉴

  • 홈
반응형

정보

i3months의 천천히 꾸준히 조용히

천천히 꾸준히 조용히

i3months

블로그 구독하기

  • 구독하기
  • RSS 피드

티스토리

  • 티스토리 홈
  • 이 블로그 관리하기
  • 글쓰기
Powered by Tistory / Kakao. Copyright © i3months.

티스토리툴바