소형 언어 모델 파인튜닝 실전: 로컬 합성 데이터 생성부터 평가와 하네스 설계까지

핵심 메시지

• 목표는 범용 챗봇이 아니라, 내 문서 더미 위에서 질의응답이나 지식 추출 같은 좁은 작업만 아주 빠르게 해내는 작은 모델이다.
• 학습 데이터는 로컬에서 돌린 40억 파라미터급 모델로 직접 만들었다. 폐쇄형 모델을 쓸 때 따라오는 증류 관련 위험을 피하고 비용도 들지 않는다.
• 구조화 출력은 프롬프트가 아니라 제약 디코딩으로 보장한다. 문법에 맞지 않는 토큰의 확률을 0으로 눌러 작은 모델도 형식을 절대 어기지 않게 만든다.
• 합성 데이터는 질의응답 한 종류에 그치지 않는다. 요약·사실 추출·지식 그래프 삼중항·문단 비교 등으로 늘리고, 모른다고 답하는 부정 예시까지 넣어야 견고해진다.
• 학습을 마친 모델은 그대로 내놓지 않고 하네스로 감싼다. 사용자가 프롬프트를 자유롭게 넣는 대신 정해진 스키마로 입력받고, 내부에서는 학습 때와 똑같은 프롬프트를 쓴다.

쉽게 이해하기

발표자는 파인튜닝 강좌의 두 번째 편에서 허깅페이스에서 찾을 수 있는 가장 작은 축에 드는 1억 3500만 파라미터 모델을 골랐다. 명령어 튜닝조차 되지 않은 버전이라 더 까다롭지만 그만큼 배울 것이 많다는 이유다. 앞선 편에서 아카이브 논문으로 계속 사전학습을 마친 모델을 가져와, 이번에는 실제로 쓸모 있게 만드는 과정을 다룬다.

첫 단계는 원문 문서에서 학습용 지시 데이터를 뽑아내는 일이다. 1500편의 논문을 잘라 넣고, 맥북에서 4비트로 양자화해 돌린 40억 파라미터급 모델로 질문과 답 쌍을 생성했다. 여기서 핵심 도구가 아웃라인즈(Outlines) 같은 제약 디코딩 라이브러리다. 작은 모델에게 JSON을 뱉으라고 프롬프트로 부탁하면 중첩 구조나 목록에서 형식이 자주 깨지지만, 토큰 단위 문법 가이드를 두고 유효하지 않은 토큰의 확률을 0으로 만들면 형식은 언제나 지켜진다. 다만 이는 구조를 보장할 뿐 내용의 정확성까지 담보하지는 않는다.

데이터를 늘리는 방식도 눈여겨볼 만하다. 한 문단에서 나온 질문·답 목록을 여러 개의 학습 사례로 쪼개고, 같은 내용을 JSON 대신 마크다운으로 요청하는 변형을 만들고, 사실 나열이나 지식 그래프 삼중항, 두 문단의 공통점과 차이 찾기처럼 과제 자체를 다양화한다. 발표자는 문단을 언제나 입력에 넣고 출력에는 넣지 않았다고 밝히는데, 이는 모델에게 지식을 외우게 하는 대신 주어진 자료를 읽고 처리하는 오픈북 시험 능력을 가르치겠다는 선택이다. 이렇게 만든 데이터가 30만 행에 이른다.

학습은 언슬로스(Unsloth)로 진행한다. 알파카 형식의 지시·입력·출력 딕셔너리를 채팅 템플릿 문자열로 바꾸고, 어시스턴트 응답 토큰에만 손실이 흐르도록 설정하는 것이 요령이다. 실험은 단순했다. 랭크 16짜리 로라(LoRA)로는 손실이 1.17에서 계속 떨어지는 중이라 학습이 덜 된 상태로 판단했고, 랭크를 32로 올리고 학습률을 높여 검증 손실 0.7 부근에서 멈췄다. 두 번의 실험에 든 비용은 모두 합쳐 8달러였다.

평가는 더 큰 모델을 심판으로 세우는 방식으로 했다. 평가 데이터 500행을 충실성·정답성·관련성·완결성 네 기준으로 채점하니, 학습한 모델은 같은 크기의 명령어 튜닝 모델을 크게 앞섰고 여덟 배 큰 모델과도 큰 차이가 나지 않았다. 속도는 8비트 양자화 시 초당 350토큰, 모델 크기는 100메가바이트 수준이다. 다만 발표자는 결과를 과장하지 않는다. 학습 내내 시스템 프롬프트를 하나로 고정했기 때문에 표현만 조금 바뀌어도 성능이 떨어진다는 것이다. 그래서 마지막 단계가 하네스다. 사용자가 프롬프트를 직접 넣게 두지 말고 작업별 스키마로 입력을 받아 내부에서 학습 때와 동일한 프롬프트로 변환하면, 벤치마크에서 확인한 성능을 실제 서비스에서도 재현할 수 있다.

주요 인사이트

• 제약 디코딩은 상용 API의 구조화 출력 기능과 근본적으로 같은 원리다. 서버 안에서 벌어지던 일을 로컬에서 직접 하는 것뿐이라는 설명이 이 기술의 문턱을 낮춘다.
• 지식을 넣을 것인가 행동을 가르칠 것인가를 먼저 정해야 한다. 작은 모델에 방대한 연구 내용을 욱여넣기보다 읽고 처리하는 능력을 가르치는 오픈북 전략이 현실적이라는 판단이다.
• 손실값을 읽는 실용적 기준도 제시된다. 3 이상이면 학습이 거의 안 되고 있을 가능성이 크니 예시 두 개로 과적합이 되는지부터 확인해 코드 버그를 걸러내라는 조언이다.
• 데이터 다양성이 없으면 벤치마크 점수가 실사용으로 이어지지 않는다. 입출력 쌍은 다양했지만 지시문이 고정되어 있었던 탓에 프롬프트가 조금만 달라져도 성능이 흔들린다.
• 하네스는 개발자·모델·사용자 세 이해관계자를 조율하는 층이다. 모델은 학습 때 보던 형태의 입력을 원하고 사용자는 단순한 API를 원하는데, 그 간극을 메우는 코드가 결국 품질을 지킨다.

자주 묻는 질문

관련 AI 소식