← 프로젝트 목록으로
Data Analysis · LLM

LLM 기반 반도체 Process 데이터 분석 및 수율 예측 자동화 시스템 개발

작년 진행한 SECOM 프로젝트의 심화 버전입니다. 결측치 처리를 평균 대체에서 KNN Imputer로 바꾸고, Random Forest 단일 모델에서 XGBoost와 비교하는 구조로 확장했으며, Feature Importance만 보던 것에서 F1·AUC·Confusion Matrix까지 정량 평가를 갖췄습니다. 여기에 분석 결과를 LLM이 자동으로 읽고 해석 리포트를 작성하는 파이프라인까지 더해 작년보다 한 단계 완성도 있는 분석 흐름을 만들었습니다.

기간2026.07
역할개인 프로젝트
스택Python, scikit-learn, XGBoost, LangChain, Gemini API
데이터Kaggle SECOM (작년과 동일 데이터셋)
0/21두 모델 모두 실제 불량 탐지 0건 (기본 threshold)
AUC 0.802Random Forest — 두 모델 중 최고
LLM자동 해석 리포트 생성

개요

작년 SECOM 수율 분석 프로젝트를 하며 '다음에는 XGBoost·LightGBM 등 다른 분류 모델과 성능을 비교하고 실시간 이상 탐지로 확장해보고 싶다'던 계획을 실행한 후속 프로젝트입니다. 같은 SECOM 데이터셋으로 결측치 처리 방식, 모델 비교, 정량 평가, 그리고 LLM 에이전트를 활용한 자동 해석 report 생성을 이용해 작년보다 한 단계 심화된 분석 파이프라인을 구축했습니다.

개선 사항: 결측치 처리(mean → KNN Imputer) · 모델 비교(Random Forest 단일 → Random Forest + XGBoost) · 평가 방식(Feature Importance만 → F1·AUC·Confusion Matrix 정량 평가) · 신규(Gemini 기반 LLM이 분석 결과를 읽고 자동으로 해석 리포트를 작성하게 하기)

문제 정의

  • 작년 프로젝트는 Feature Importance만으로 핵심 변수를 도출했을 뿐, 모델의 실제 분류 성능(정밀도·재현율)을 검증하지 않았음
  • Random Forest 단일 모델만 사용해 다른 알고리즘 대비 상대적 성능을 알 수 없었음
  • 분석 결과(수치·차트)를 현업 엔지니어가 읽고 바로 활용할 수 있는 해석과 액션으로 정리하는 과정이 수작업

접근 방법

전처리

  • 결측치 20% 초과 컬럼 제거(작년과 동일 기준) 후 558개 변수로 축소
  • 남은 결측치는 KNN Imputer(k=5)로 대체 — 작년의 단순 평균 대체보다 변수 간 유사도를 반영한 보간

모델링 및 평가

  • Random Forest(class_weight=balanced)와 XGBoost(scale_pos_weight로 불균형 보정) 두 모델을 동일 조건으로 학습·비교
  • Feature Importance뿐 아니라 F1 Score, AUC, Confusion Matrix, 불량 Recall/Precision까지 정량 평가
  • 두 모델의 Top 15 Feature Importance를 비교해 공통으로 중요하게 나타난 변수를 별도로 확인
SECOM 데이터 (1567×592)
→
결측치 20%+ 컬럼 제거
→
KNN Imputer (k=5)
↓
Random Forest
→
F1 · AUC · Confusion Matrix
→
LLM 자동 해석 리포트
XGBoost
→
Feature Importance 비교

결과

모델별 정량 평가 (불량 클래스 기준):

모델F1 ScoreAUC불량 Recall불량 Precision
Random Forest0.00000.80220.00000.0000
XGBoost0.00000.66800.00000.0000
Random Forest와 XGBoost의 Confusion Matrix 비교
Random Forest(좌) vs XGBoost(우) Confusion Matrix — 테스트셋 314건 (정상 293건, 불량 21건)

F1 Score는 두 모델 모두 0입니다. Confusion Matrix를 보면 원인이 드러납니다. Random Forest는 정상 293건은 모두 맞혔지만 불량 21건도 전부 정상으로 예측해 하나도 탐지하지 못했습니다. XGBoost는 정상 291/293건을 맞히고 2건만 불량으로 오탐했을 뿐, 불량 21건에 대해서는 동일하게 탐지율 0을 기록했습니다. AUC는 RF 0.8022, XGBoost 0.6680으로 두 모델 모두 어느 정도의 구분 능력은 있지만, 기본 threshold(0.5)에서는 소수 클래스(불량)를 전혀 예측하지 못하는 편향이 나타났습니다.

Random Forest와 XGBoost의 Feature Importance Top 15 비교
Random Forest(좌) vs XGBoost(우) Feature Importance Top 15 — 두 모델 공통 상위 변수: 103, 31, 319

두 모델의 Top 15 변수 중에서는 변수 103, 31, 319가 공통으로 상위권에 올랐습니다.

인터랙티브 데모

모델이 실제로 뱉는 건 0~1 사이의 확률 점수 하나뿐이고, 이걸 "정상/불량"으로 가르는 기준선(threshold)은 사람이 정하는 값입니다. 위 결과표는 threshold=0.5 기준이었는데, 이 기준을 낮추면 애매한 점수까지 전부 "불량"으로 넘어가서 Recall은 오르지만 오탐(FP)도 같이 늘어나는 trade-off가 생깁니다. 이 관계를 눈으로 확인하고 싶어서 만든 대시보드입니다.

314개 테스트 샘플 각각의 예측 확률값은 따로 저장해두지 않고 F1·AUC·Confusion Matrix 같은 집계 결과만 리포트에 남겨서 원본 점수를 그대로 가져올 수는 없었습니다. 대신 두 모델의 점수 분포를 흉내낸 가상의 점수 배열을 만들고, threshold=0.5에서는 위 결과의 Confusion Matrix(RF AUC 0.8022, XGBoost AUC 0.6680, 둘 다 불량 Recall 0)와 똑같은 숫자가 나오도록 점수 범위를 역산해서 맞춰뒀습니다. 슬라이더를 움직이면 그 threshold 기준으로 TP/FP/FN/TN을 다시 세고, Precision·Recall·F1·ROC를 그 자리에서 재계산해서 그려주는 방식이라, 0.5 지점 말고는 실측이 아니라 근사치라는 점은 감안하고 봐주세요.

Threshold0.50
분류 기준 점수. 낮출수록 Fail 검출 민감도(Recall) 상승, 오탐(FP) 증가.
불균형 보정 모델
–AUC
–F1 Score
–Precision
–Recall
Threshold별 지표 — Random Forest
Precision / Recall / F1
Precision Recall F1
ROC Curve — Random Forest
AUC = 0.8022
Confusion Matrix — Random Forest
Test set 314건 (정상 293 / 불량 21)
예측: 정상
예측: 불량
실제: 정상
0
TN
0
FP
실제: 불량
0
FN
0
TP

LLM 해석 리포트

분석 결과(성능 지표, Feature Importance)를 텍스트로 정리해 Gemini(LangChain PromptTemplate)에 전달하면, 아래 4개 섹션으로 구성된 해석 리포트를 자동으로 작성하도록 프롬프트를 설계했습니다.

  • 모델 성능 해석: 두 모델의 성능 차이를 불량 탐지 관점에서 해석
  • 핵심 Feature 분석: SECOM 변수명이 익명화(숫자)되어 있어, 일반적인 반도체 Process 센서(Process 조건·장비 상태·전후 Process 영향) 관점에서 의미를 추론
  • 수율 개선 제안 3가지: 현업 엔지니어가 바로 쓸 수 있는 구체적 액션
  • 분석의 한계 및 개선 방향: 이 분석에서 아쉬운 점과 실제 Process 적용 시 고려사항

Gemini API 무료 티어는 일일 요청 한도가 있어, 리포트는 필요할 때 노트북을 실행해 생성하는 방식으로 운영하고 있습니다.

배운 점 & 한계

  • F1 Score 하나만으로는 모델의 실제 예측 편향을 놓칠 수 있다는 것을 Confusion Matrix에서 직접 확인했습니다 — 불균형 데이터일수록 총계 지표가 아니라 클래스별 지표와 혼동행렬을 함께 봐야 한다는 것을 체감했습니다
  • class_weight='balanced'나 scale_pos_weight 같은 불균형 보정 옵션을 적용해도 실제로 소수 클래스를 얼마나 잘 잡아내는지는 별도로 검증해야 한다는 것을 배웠습니다
  • LLM에게 정량 결과를 그대로 던지는 것이 아니라 원하는 리포트 구조(성능 해석 → Feature 분석 → 액션 → 한계)를 프롬프트에 명시해야 실무에 바로 쓸 수 있는 리포트가 나온다는 것을 확인했습니다. 다만 LLM은 입력된 수치를 그대로 받아들여 해석할 뿐, 그 수치 자체가 잘못됐는지는 검증하지 못한다는 한계도 함께 확인했습니다
  • 향후에는 SHAP 기반 설명가능 AI를 추가하고, Gemini API 유료 티어 또는 로컬 LLM으로 전환해 요청 한도 문제를 해결하고 싶습니다

첨부 자료

GitHub Repository →