세 편의 포스트를 통해 저는 동일한 뱅킹 의도(banking-intent) 작업을 위해 세 가지 파인튜닝(fine-tuned) 모델을 구축했습니다 — 270M 모델의 풀 파인튜닝 (full fine-tuning), 1.5B 모델에 LoRA 적용, 7B 모델에 QLoRA 적용. 이 모델들은 모두 비슷한 정확도에 도달했습니다.

이는 솔직하고 약간은 불편한 질문을 던지게 합니다: 내 노트북에서 돌아가는 270M 모델이 이미 잘 작동한다면, 왜 굳이 7B 모델을 찾는 걸까?

"거거익선" 콘텐츠들이 생략하는 답변

이 작업의 경우에는 — 그러지 않을 것입니다. 유능한 엔지니어는 사용 가능한 가장 큰 모델이 아니라, 기준치를 통과하는 가장 작은 모델을 선택합니다. 작은 모델은 서빙(serve) 비용이 더 저렴하고, 밀리초(milliseconds) 단위로 실행되며, 완전히 소유할 수 있습니다. 여기서 7B를 선택하는 것은 오버엔지니어링(over-engineering)입니다.

더 큰 모델을 찾는 것은 과시가 아닙니다. 그것은 작은 모델이 충족할 수 없는 요구사항에 대한 대응입니다. 작은 모델로는 충분하지 않은 네 가지 사례는 다음과 같습니다:

1. 작업이 진정으로 어려운 경우

Banking77은 쉽습니다 — 77개의 고정된 레이블(labels), 짧고 깨끗한 쿼리(queries). 작은 모델로도 충분히 포화 상태에 도달합니다. 하지만 추론(

이것이 바로 LoRA/QLoRA의 조용한 초능력입니다. 하나의 고정된 (frozen) 7B 베이스 모델이 의도 분류기 (intent classifier), 답변 작성기 (reply writer), 요약기 (summarizer), 감성 분석기 (sentiment) 등 수십 개의 교체 가능한 어댑터 (adapters)를 수용할 수 있습니다. 이 모든 것이 메모리 상에서 약 5GB의 점유 공간만으로 가능합니다. 270M 모델은 단일 목적용입니다. 이것이 기업들이 하나의 베이스 모델로부터 수백 개의 파인튜닝 (fine-tune) 모델을 서비스하는 이유입니다.

4. 규모가 커질수록 정확도가 복리로 작용한다

93%의 정확도는 100개의 쿼리 중 7개가 잘못 전달됨을 의미합니다. 월간 1,000만 건의 쿼리가 발생한다면, 이는 700,000번의 실수입니다. 각 실수가 고객 지원 에스컬레이션 (escalation) 비용을 발생시킨다면, 더 큰 모델을 통해 얻는 2~3%의 정확도 향상은 그 비용을 수차례 상쇄하고도 남을 것입니다. 작은 규모에서는 아무도 눈치채지 못하지만, 대규모에서는 그것이 전체 예산이 됩니다.

그렇다면 왜 세 가지 모델을 모두 만들었을까?

작은 모델을 이기기 위해서가 아닙니다. 결과는 동점이었으니까요. 그리고 그 동점이 바로 교훈입니다. 쉬운 작업에서는 기술이 거의 중요하지 않다는 것입니다.

저는 기술을 배우기 위해 이 모델들을 만들었습니다. 그래야 작은 모델로 충분하지 않은 작업에 직면했을 때, 주저 없이 16GB 그래픽 카드에서 7B 모델을 파인튜닝 (fine-tune) 할 수 있기 때문입니다. 이는 마치 화창한 날 집 앞 진입로에서 타이어 교체법을 배우는 것과 같습니다. 진입로에서는 타이어를 갈 일이 없었지만, 이제 저는 고속도로 위 빗속에서도 타이어를 갈 수 있게 되었습니다.

어떤 모델 크기로도 해결할 수 없었던 버그

세 프로젝트 모두를 관통하는 하나의 흐름이 있었습니다. 270M, 1.5B, 7B 모든 모델이 동일한 두 가지 의도(intents)를 혼동했습니다: card_arrival과 card_delivery_estimate. 세 가지 모델 규모, 세 가지 기술을 사용했음에도 모든 혼동 행렬 (confusion matrix)에서 동일한 실수가 나타났습니다.

이것은 돈을 더 써서 해결할 수 있는 용량 (capacity)의 문제가 아닙니다. "제 카드는 어디 있나요?"와 "제 카드는 언제 도착하나요?"는 진정으로 겹치는 부분이 있습니다. 모호함은 모델이 아니라 레이블 (labels) 자체에 있었습니다. 세 모델이 모두 동일한 "실수"에 동의한다는 것은, 모델이 아니라 데이터가 한계라는 강력한 신호입니다.

때로는 정답이 더 큰 모델이 아닐 수도 있습니다. 더 나은 데이터가 정답일 수 있습니다.

그것이 이 시리즈 전체를 통해 제가 배운 가장 유용한 사실일지도 모릅니다.

의사결정을 위한 핵심 요약

실제 요구사항에 대해 작은 모델로 충분한가?
   YES → 그대로 배포하십시오. 더 큰 모델은 낭비되는 비용, 지연 시간 (latency), 그리고 복잡성일 뿐입니다.
   NO  → 그렇다면 왜 안 되겠습니까?
...

요구 사항에 모델을 맞추십시오. 그 직관은 1~3부에서 다룬 그 어떤 파인튜닝 (fine-tuning) 메커니즘보다 더 가치가 있습니다.

📓 Kaggle의 세 가지 노트북 모두 확인하기: https://www.kaggle.com/work/collections/18659493

이 시리즈를 읽어주셔서 감사합니다. 내용이 유익했다면, 반응(reaction)이나 댓글을 남겨주세요. 이는 첫 OOM (Out of Memory) 오류를 디버깅하고 있는 다음 사람에게 이 글이 전달되는 데 큰 도움이 됩니다.