600만 파라미터 LLM 파인튜닝으로 10%→79% 정확도 끌어올린 실전 기록 (teachmecoolstuff.com)
목차(8)
한줄 요약
600M 파라미터짜리 초소형 LLM을 파인튜닝해 질문 분류기로 만든 실험, 10%에서 79%로 정확도가 튀었다.
어떤 상황에서 필요한가?
로컬 LLM 기반 RAG 시스템을 설계할 때 가장 먼저 맞닥뜨리는 문제는 검색 노이즈다. 벡터 DB에 질문을 그대로 던지면 의미적으로 가까운 문서가 카테고리를 가로질러 뒤섞여 올라온다. "수영장 펌프를 언제 교체했지?"라는 질문에 hvac 관련 문서가 섞여서 나오는 식이다.
이 문제를 해결하는 방법 중 하나가 메타데이터 필터링이다. 질문을 벡터 검색에 넘기기 전에 먼저 카테고리를 분류해서, 검색 범위를 해당 카테고리로 좁히는 것이다. 개념 자체는 단순하지만 실제로는 "분류를 어떤 모델이 담당하느냐"가 시스템 전체 품질을 좌우한다.
여기서 선택지가 갈린다. GPT-4급 API를 쓰면 정확도는 나오지만 응답 지연과 비용이 붙는다. 반면 로컬에서 돌리면 레이턴시와 프라이버시 문제는 해결되지만, 초소형 모델은 프롬프트만으로는 분류 신뢰도가 너무 낮다. 이 간극을 파인튜닝으로 메울 수 있는지가 이 실험의 핵심 질문이다.
핵심 구현 방법
시스템 구조부터 잡는다
전체 아키텍처는 크게 두 모델로 나뉜다. Qwen 3:0.6B는 질문 분류 전용, Qwen 3:4B는 실제 답변 생성 담당이다. 분류기를 답변 모델에서 분리한 것은 합리적인 선택이다. 분류는 단순 분기 작업이므로 굳이 대형 모델을 쓸 이유가 없고, 작은 모델을 특화시키면 응답 속도도 유리하다.
베이스라인부터 측정한다
파인튜닝 전에 베이스라인을 잡는 것은 기본 중의 기본이다. 원문 저자는 파인튜닝 없이 프롬프트만으로 Qwen 0.6B를 테스트했고, 131개 케이스 중 13개만 정답이었다. 정확도 약 10%다.
실패 패턴이 흥미롭다. 모델이 허용된 카테고리 목록을 무시하고 "apartments" 같은 존재하지 않는 카테고리를 만들어내거나, electric이나 appliances 같은 범용 카테고리에 모든 것을 몰아넣는다. 초소형 모델에 프롬프트 인스트럭션만 주입하면 이런 hallucination이 반드시 나온다는 걸 수치로 확인한 셈이다.
파인튜닝 데이터셋 구성
약 850개 항목을 수집해 70/15/15 비율로 훈련/평가/테스트 세트로 분리했다. 데이터 구조는 단순하다. 질문 하나에 카테고리 하나를 매핑하는 형태다.
툴 선택은 Unsloth + QLora 조합이다. 로컬 하드웨어에서 소형 모델을 파인튜닝할 때 자주 쓰이는 스택이다. 저자가 강조한 포인트가 있다. 하이퍼파라미터 튜닝에 집착하기보다 데이터셋 품질에 집중하는 게 더 효과적이라는 것이다. 실제로 Unsloth의 기본 파라미터 값이 좋은 출발점이 된다고 한다.
1차 파인튜닝 결과
131개 테스트 케이스에서 104개 정답, 정확도 79.39%로 뛰었다. 10%에서 시작했으니 의미 있는 도약이다. 그러나 실패 패턴이 여전히 남아 있다. "hvac" 대신 "ac"나 "air"처럼 카테고리 이름의 일부만 출력하는 경우, 그리고 fountain, water heater, pool처럼 의미적으로 겹치는 카테고리 간 혼동이다. 1차 시도만으로 79%까지 올라왔다는 건 파인튜닝 효과가 명확하다는 뜻이기도 하지만, 동시에 카테고리 설계 자체가 분류 난이도에 직접 영향을 준다는 걸 보여준다.
실전에서 주의할 점
오버피팅을 구조적으로 막아야 한다. 테스트 데이터를 훈련 데이터에서 완전히 격리하는 건 당연하고, 사용자 피드백을 재학습 데이터로 흡수하는 채널을 처음부터 설계해두는 게 좋다. 저자도 이 점을 언급한다. 실세계 데이터가 계속 들어오는 시스템에서 모델은 고정된 게 아니라 살아있는 컴포넌트다.
카테고리 경계를 명확하게 설계해야 한다. fountain, pool, water heater처럼 "물"이라는 공통 속성을 가진 카테고리는 모델 입장에서 구분하기 어렵다. 카테고리 설계 단계에서 경계가 불분명한 쌍을 미리 찾아내고, 해당 경계를 다루는 훈련 샘플을 더 넣는 게 효과적이다.
후처리 정규화는 단기 처방이다. "ac"를 "hvac"로 보정하는 후처리 레이어를 붙이면 단기적으로 수치는 올라간다. 하지만 카테고리가 늘어날수록 유지 비용이 선형으로 증가한다. 근본적으로는 모델이 정확한 토큰을 출력하도록 파인튜닝 전략 자체를 바꾸는 방향이 낫다.
데이터 품질이 파라미터 튜닝보다 우선이다. 이건 이 실험이 가장 명확하게 보여주는 교훈이다. 하이퍼파라미터를 정밀하게 조정하는 데 시간을 쓰기 전에, 경계 케이스를 더 잘 커버하는 데이터를 추가하는 게 ROI가 높다.
자주 묻는 질문
Q.파인튜닝 없이 프롬프트 엔지니어링만으로 소형 LLM의 분류 정확도를 높일 수는 없나?
이 실험이 보여주듯 0.6B 수준의 초소형 모델은 프롬프트만으로는 카테고리 준수 자체가 안 된다. 허용 목록을 무시하고 새로운 카테고리를 만들어내는 hallucination이 구조적으로 발생한다. Few-shot 예제를 더 넣거나 프롬프트를 정교화해도 근본적인 한계는 바뀌지 않는다. 분류 태스크에 특화된 신뢰도가 필요하다면 파인튜닝이 현실적인 선택이다.
Q.Unsloth + QLora 조합이 로컬 파인튜닝에 적합한 이유가 뭔가?
QLora는 모델을 4비트 또는 8비트로 양자화한 상태에서 저차원 어댑터만 학습하기 때문에 GPU 메모리 요구량이 크게 줄어든다. Unsloth는 이 위에 최적화 레이어를 더해 학습 속도를 끌어올린다. 결과적으로 소비자용 GPU로도 소형 모델 파인튜닝이 가능해진다. 다만 하드웨어 스펙과 모델 크기에 따라 실제 소요 시간은 달라지므로 작은 스텝으로 먼저 검증해보는 게 좋다.
Q.RAG 시스템에서 메타데이터 필터링이 순수 벡터 검색보다 효과적인 경우는 언제인가?
벡터 DB에 저장된 문서가 명확한 도메인 또는 카테고리로 구분될 때 효과가 크다. 질문과 관련 없는 카테고리의 문서가 벡터 유사도 상위에 올라오는 노이즈를 구조적으로 차단할 수 있기 때문이다. 반면 카테고리 경계가 불분명하거나 하나의 질문이 여러 카테고리에 걸쳐 있는 경우에는 메타데이터 필터가 오히려 리콜을 낮출 수 있다. 시스템 설계 단계에서 카테고리 구조와 데이터 분포를 함께 검토해야 한다.
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.