지식 증류
Knowledge Distillation
지식 증류란?
- 큰 모델(선생)→작은 모델(학생)
- 성능 유지하며 가볍게
- 양자화와 함께 경량화
지식 증류를 도입하면 팀 안에서 오가는 질문 자체가 바뀝니다. '어느 모델이 제일 똑똑한가'가 아니라 '이 업무에 필요한 실력을 얼마짜리 모델로 낼 수 있는가'를 따지게 됩니다. 대형 모델은 서비스에 직접 올리는 물건이 아니라 학습 신호를 찍어내는 설비로 자리가 바뀌고, 실제 트래픽은 작은 모델이 받습니다. 그래서 프로젝트의 성패는 모델 고르기보다 선생에게 무엇을 얼마나 물어볼지 설계하는 단계에서 갈립니다.
방식은 크게 둘로 갈립니다. 선생의 내부 확률분포(로짓)까지 꺼내 쓰는 화이트박스 증류는 가중치를 열 수 있는 오픈소스 모델에서만 가능하고, 상용 API처럼 내부를 볼 수 없으면 선생이 생성한 답변 텍스트를 정답처럼 학습시키는 블랙박스(시퀀스 수준) 증류를 씁니다. 양자화·프루닝과 자주 섞어 쓰는데, 그쪽은 같은 모델의 숫자 정밀도나 연결을 덜어내는 작업이고 증류는 구조가 다른 새 모델을 키우는 일입니다. 둘은 배타적이지 않아서 증류한 학생 모델에 양자화까지 얹는 조합이 실제 배포에서는 흔합니다.
다만 아무 과제에서나 먹히지는 않습니다. 범용 상식과 긴 추론을 요구할수록 학생이 따라잡기 어렵고, 문의 분류·요약·사내 규정 안내처럼 범위가 좁게 정의된 업무에서 격차가 빠르게 줄어듭니다. 현장에서는 파라미터를 5~10분의 1로 줄이면서 해당 업무 평가셋 기준 선생 대비 95% 안팎을 합격선으로 잡고, 미달하면 데이터를 무작정 늘리기보다 선생이 뱉은 오답을 걸러내는 작업을 먼저 손봅니다.
가장 흔한 사고는 선생을 검수 없이 믿는 것입니다. 선생이 틀린 답이나 철 지난 규정을 말하면 학생은 그 오류를 더 자신 있게 반복하고, 나중에 원인을 추적하기도 어렵습니다. 또 전체 평균 점수만 보고 배포하면 문의의 3~5%를 차지하는 예외 케이스에서 먼저 무너지므로, 실패 유형별로 쪼갠 평가셋이 필요합니다. 상용 API 출력물로 자체 모델을 학습시키는 행위를 약관에서 금지하는 사업자도 있어 법무 검토를 건너뛰면 안 됩니다.
제프리 힌턴(Geoffrey Hinton) 등이 2015년 논문에서 대형 모델의 지식을 작은 모델로 옮기는 방법으로 정립했습니다.
가상의 사례로 살펴보겠습니다. 연매출 900억 원, 임직원 240명 규모의 생활가전 제조사 A사입니다. 고객센터 챗봇을 외부 대형 모델 API로 돌리는데 월 사용료가 2,700만 원까지 올랐고, 성수기에는 응답이 평균 3.2초로 늘어져 상담사 이관 문의가 쌓였습니다. CS본부는 3개월 안에 비용과 지연을 동시에 잡으라는 지시를 받았습니다.
- CS본부장이 "월 2,700만 원이면 상담사 세 명 인건비"라고 못을 박자, 데이터팀장은 최근 6개월 상담 로그 18만 건을 추려 선생 모델에 태워 답변과 근거 조항을 함께 생성했습니다.
- 생성된 답변을 CS 매니저 2명이 3주간 표본 검수해 오답과 철 지난 환불 규정 7.4%를 걷어냈습니다. "선생이 틀린 건 학생한테 절대 안 넘긴다"가 팀 원칙이었습니다.
- 학생 모델로는 70억 파라미터 오픈소스 모델을 잡고, 사내 GPU 2장으로 11일간 파인튜닝했습니다. 인프라 담당 과장이 응답 1초, 서버비 월 500만 원 이하를 합격선으로 걸었습니다.
- 1차 검증에서 자주 묻는 200문항은 선생 대비 96%가 나왔지만 분할결제 취소 같은 드문 문의는 71%에 그쳐, 해당 유형만 2,300건을 추가로 증류해 다시 학습시켰습니다.
- 8주 차 전환 결과, API 비용 월 2,700만 원이 자체 서버 운영비 420만 원으로 줄고 평균 응답은 3.2초에서 0.9초로 단축됐으며, 상담사 이관율은 12.1%에서 12.8%로 사실상 유지됐습니다.