파인튜닝, 아직도 가치 있을까?

이 트윗에서 던진 질문들에 대한 내 개인적인 견해를 정리해보겠다:

파인튜닝에 회의적인 목소리가 점점 늘고 있다.

이 분위기에 대해 더 널리 의견을 듣고 싶다. (지금 당장 내 생각을 밝히지는 않겠다).

아래 트윗은 @mlpowered @abacaj @emollick 의 글이다. pic.twitter.com/cU0hCdubBU

— Hamel Husain (@HamelHusain) 2024년 3월 26일

---

파인튜닝은 여전히 많은 상황에서 충분히 가치 있다고 생각한다. 조금 더 파고들어보니, 파인튜닝이 쓸모없다고 말하는 사람들은 실제로 파인튜닝이 효과를 발휘하기 어려운 제품을 만들고 있는 경우가 많았다:

• 개발자 도구를 만들고 있는 경우 — 파운데이션 모델은 이미 코딩 태스크로 충분히 훈련되어 있다.
• 파운데이션 모델을 구축하며 가장 범용적인 케이스를 테스트하는 경우 — 파운데이션 모델 자체도 범용성을 목표로 학습된다.
• 특정 도메인이나 사용 사례로 범위를 한정하지 않은 개인 어시스턴트를 만드는 경우 — 사실상 파운데이션 모델을 만드는 것과 다를 바 없다.

또 자주 보이는 패턴이 있는데, 제품 개발 초기 단계에 있는 사람들이 이런 말을 많이 한다는 점이다. 아직 초기 단계라는 신호 중 하나는 도메인에 특화된 평가 체계(eval harness)가 없다는 것이다.

평가 시스템 없이는 파인튜닝을 제대로 할 수 없고, 이 선결 조건을 갖추지 못한 채 파인튜닝을 시도하다 보면 결국 파인튜닝 자체를 포기하게 된다. 파인튜닝 여부와 무관하게, 제대로 된 평가 시스템이 없으면 장기적으로 제품을 개선하는 것 자체가 불가능하다.

파인튜닝에 앞서 프롬프트 엔지니어링을 최대한 충분히 해보는 것이 좋다. 단, 이유는 흔히 생각하는 것과 다르다. 프롬프트 엔지니어링을 충분히 해야 하는 진짜 이유는, 그 과정이 평가 시스템을 스트레스 테스트하기에 탁월한 방법이기 때문이다.

프롬프트 엔지니어링으로 충분한 성과가 나온다면(그리고 제품을 체계적으로 평가하고 있다면) 거기서 멈춰도 전혀 문제없다. 나는 문제를 가장 단순한 방법으로 해결하는 것을 지지한다. 다만, 파인튜닝을 아직 섣불리 포기할 필요는 없다는 점을 강조하고 싶다.

파인튜닝이 실제로 효과를 발휘한 사례

일반적으로 파인튜닝은 문법, 스타일, 규칙을 학습시키는 데 강점을 보이는 반면, RAG 같은 기법은 모델에 맥락이나 최신 정보를 제공하는 데 더 적합하다.

내가 함께 일했던 회사들의 사례 몇 가지를 소개한다. 조만간 더 자세한 내용을 공유할 수 있기를 바란다.

• Honeycomb의 자연어 쿼리 어시스턴트 — 기존에는 Honeycomb 쿼리 언어의 '프로그래밍 매뉴얼'을 수많은 예제와 함께 프롬프트에 통째로 넣는 방식을 썼다. 나쁘지 않은 방법이었지만, 이 틈새 도메인 특화 언어의 문법과 규칙을 모델에 학습시키는 데는 파인튜닝이 훨씬 더 뛰어난 결과를 보여줬다.

• ReChat의 Lucy — 기존 부동산 CRM 시스템에 통합된 AI 부동산 어시스턴트다. ReChat은 LLM의 응답이 매우 독특한 형식을 따르도록 요구한다. 구조화 데이터와 비구조화 데이터를 엮어서, 프론트엔드가 위젯·카드·각종 인터랙티브 요소를 채팅 인터페이스에 동적으로 렌더링할 수 있어야 하기 때문이다. 파인튜닝이 이를 제대로 동작하게 만든 핵심이었다. 자세한 내용은 이 발표에서 확인할 수 있다.

덧붙여, 파인튜닝이 오픈소스나 '소형' 모델에만 국한된다는 생각은 오해다. Perplexity.AI나 CaseText처럼 GPT-3.5를 파인튜닝해서 활용하는 곳도 적지 않다.