파인튜닝

대규모 언어 모델은 엄청난 양의 텍스트를 미리 읽어 두고 앞말에 이어질 말을 고르는 프로그램입니다. 세상에 널린 글을 읽고 나온 물건이라 답도 세상의 평균을 닮습니다. 그런데 제품에 붙는 기능은 평균을 원하지 않습니다. 우리 회사가 쓰는 문의 분류 체계가 따로 있고, 고객에게 나가는 문장의 길이와 어조에도 나름의 규칙이 있습니다.

처음에는 그 규칙을 지시문에 적어 주는 것으로 해결합니다. 모델에게 주는 지시문을 다듬는 일을 프롬프트 엔지니어링이라고 하는데, 규칙이 늘어날수록 이 지시문이 두꺼워집니다. 페이지덱에서 고객 문의를 자동으로 분류하는 기능을 만들던 태오의 지시문은 마지막에 마흔 줄이 넘었습니다. 분류 이름 열두 개를 적고, 헷갈리기 쉬운 경계를 설명하고, 예시를 스무 개 붙인 결과였습니다.

문제는 둘이었습니다. 하나는 그 마흔 줄이 문의 한 건을 처리할 때마다 따라붙는다는 것입니다. 모델은 글을 토큰이라는 조각 단위로 읽고 요금도 그 개수로 매겨지니, 지시문이 길어진 만큼 건당 비용이 늘어납니다. 다른 하나는 스물한 번째 형태에서 여전히 틀렸다는 것입니다. 예시에 없던 모양의 문의가 들어오면 모델은 자기가 원래 알던 일반적인 분류로 돌아갔습니다.

파인튜닝은 이 상황을 뒤집습니다. 규칙을 매번 말로 설명하는 대신, 맞게 처리된 사례를 수백 건 보여 주고 모델 자체를 그쪽으로 기울여 둡니다. 설명서를 매번 건네는 대신 신입에게 지난 사례집을 통째로 읽히는 쪽에 가깝습니다.

용도를 하나로 좁히는 데서 시작해 학습을 돌리고 평가로 확인하는 여섯 단계를 밟습니다.

1. 고칠 대상을 한 가지로 정합니다. 문의 분류든 요약 형식이든 하나만 잡습니다. 여러 가지를 한 번에 맡기면 어느 쪽이 좋아지고 나빠졌는지 가릴 수 없습니다.
2. 예시를 모읍니다. 입력과 그에 대한 올바른 출력을 짝지은 묶음이 학습 데이터입니다. 형태가 고른 작업은 수백 건부터 효과가 보이고, 판단이 섞이는 작업은 천 건 넘게 필요합니다.
3. 모은 것의 10~20퍼센트를 떼어 따로 보관합니다. 이것이 평가셋으로, 학습에 쓰지 않은 문제를 풀려야 실력이 는 것인지 답을 외운 것인지 구별됩니다.
4. 학습을 돌립니다. 모델을 만든 회사가 제공하는 창구에 데이터를 올리고 몇 시간을 기다리면 우리 전용 모델이 하나 생깁니다. 직접 계산 장비를 갖추지 않아도 됩니다.
5. 원래 모델과 새 모델에 같은 평가셋을 돌려 점수를 견줍니다. 분류 정확도가 71퍼센트에서 89퍼센트로 올랐다는 식의 숫자가 나와야 다음으로 넘어갑니다.
6. 제품에 붙이고 실제 입력에서 관찰합니다. 평가셋에 없던 형태의 문의가 계속 들어오므로, 틀린 건을 모아 다음 학습 데이터에 더합니다.

맞는 자리는 형태를 고정하는 일입니다. 정해진 분류 중 하나를 고르게 하거나, 답변의 길이와 말투를 일정하게 유지하거나, 정해진 형식의 결과물을 빠짐없이 내놓게 하는 작업이 여기 듭니다. 이런 일은 규칙을 말로 다 적기가 어렵고 사례를 보여 주는 쪽이 훨씬 빠릅니다.

맞지 않는 자리는 지식을 넣는 일입니다. 어제 올라온 사내 공지를 모델에게 가르치려고 파인튜닝을 하면 대개 실패합니다. 모델은 그 내용을 정확히 외우는 대신 비슷한 분위기의 문장을 지어내는 쪽으로 기울고, 그러면 사실이 아닌 답을 자신 있게 내놓는 환각이 오히려 늘어납니다. 자료를 읽고 답하게 하려면 질문이 들어올 때 관련 문서를 찾아 지시문에 붙여 주는 RAG 쪽이 맞습니다.

한계는 셋입니다. 첫째, 밑천이 듭니다. 수백 건의 예시를 사람이 검수해 만들어야 하고, 그 과정이 보통 며칠에서 몇 주입니다. 둘째, 모델을 갈아타면 처음부터 다시 해야 합니다. 새 모델이 나와 성능이 좋아져도 우리가 길들여 둔 것은 이전 모델에만 붙어 있습니다. 셋째, 바뀐 규칙이 즉시 반영되지 않습니다. 분류 이름 하나가 추가되면 지시문은 한 줄 고치면 끝이지만 파인튜닝한 모델은 데이터를 보태 다시 학습해야 합니다.

그래서 순서가 있습니다. 지시문을 다듬어 보고, 자료를 붙여 보고, 그래도 남는 문제에 파인튜닝을 꺼냅니다.

"이거 파인튜닝까지 갈 일인가요? 프롬프트로 한 번 더 해 보죠."

비용이 큰 수단이니 싼 것부터 소진하자는 제안입니다.

"학습 데이터 300건 모았는데 라벨이 사람마다 달라요. 기준부터 맞춰야 할 것 같아요."

일관성이 없으면 학습해도 모델이 같은 기준을 배우지 못한다는 뜻입니다.

"파인튜닝 모델이 평가셋에서는 좋은데 실제 문의에서 떨어져요."

모아 둔 예시가 실제로 들어오는 입력의 분포를 대표하지 못했다는 신호입니다.

페이지덱의 문의 자동 분류가 이 길을 그대로 걸었습니다. 태오가 지시문만으로 두 주를 버티다 정확도가 70퍼센트 언저리에서 더 오르지 않자 파인튜닝을 제안했고, 지현이 지난 반년치 문의 1,200건의 분류 기록을 꺼내 왔습니다. 문제는 그 기록의 라벨이 담당자마다 달랐다는 점입니다. 결제 오류를 어떤 사람은 결제로, 어떤 사람은 버그로 넣어 뒀습니다.

그래서 학습을 돌리기 전에 분류 기준을 다시 합의하고 800건을 사람이 다시 붙였습니다. 그 작업에 나흘이 들었고 학습 자체는 세 시간 만에 끝났습니다. 파인튜닝에서 시간이 걸리는 쪽이 어디인지 보여 주는 비율입니다.

파인튜닝을 하면 모델이 우리 회사 문서를 외운다고 생각하는 경우가 가장 많습니다. 자료를 넣어 학습시킨다는 말이 곧 내용을 기억시킨다는 뜻으로 들리니 자연스러운 오해입니다. 실제로 모델이 배우는 것은 내용이 아니라 형태와 경향입니다. 사내 규정 문서 500건을 그대로 학습시킨 모델에게 휴가 일수를 물으면, 규정 문서처럼 생긴 문장으로 그럴듯하게 틀린 숫자를 답합니다. 그대로 두면 답변이 전보다 그럴듯해진 탓에 틀린 것을 알아채기가 더 어렵습니다.

효과를 숫자로 확인하지 않고 넘어가는 것도 흔합니다. 결과물 서너 개를 읽어 보면 확실히 나아진 느낌이 들기 때문입니다. 느낌은 고른 사례에 좌우되고, 사람은 대개 잘 된 사례를 먼저 고릅니다. 평가셋 없이 붙인 모델은 몇 주 뒤 어느 쪽이 나았는지 아무도 답하지 못하고, 되돌릴 근거가 없으니 그냥 쓰게 됩니다.