(아래 내용은 Skelter Labs Blog - RAG vs. 파인튜닝 :: 기업용 맞춤 LLM을 위한 선택 가이드)에서 퍼온 글로 공감하는 내용이어서 공유하고자 올립니다)
RAG vs. 파인튜닝 :: 기업용 맞춤 LLM을 위한 선택 가이드
기업이 원하는 맞춤 LLM 모델을 만드는 방법은 여러가지가 있습니다. 그 중 RAG 와 파인 튜닝의 특,장점과 기업이 도입할 땐 어떤 방법이 더 효율적일지 상세히 알아봅니다.
무엇이든 잘하는 범용 LLM, 놀라운 경험을 제공하다
챗GPT, Bard와 같이 우리가 흔히 사용하고 있는 LLM 챗봇은 특정한 목적과 분야(domain)에 집중한 맞춤형 모델이 아닌 범용 모델에 기반하고 있습니다.
기술, 법률, 금융 등 특정 도메인에 한정되지 않고 요약, 번역, 비교, 분석과 같은 일반적인 지적 과업을 대화(자연어)로 지시할 수 있고, 챗봇은 이 요청을 처리해 정제된 언어로 그 결과를 제공합니다.
구시대의 AI비서나 AI검색이 할 수 있었던 일이 매우 제한적이고, 시나리오 상 미리 정해진 답변만 할 수 있었던 것에 비해 다룰 수 있는 주제도, 할 수 있는 일도 폭발적으로 많아졌습니다. 그리고 이것이 사람들이 챗GPT에 열광했던 이유였습니다.
기업에서 원하는 LLM은 범용 모델이 아니다?
챗GPT, Bard와 같은 범용 LLM 챗봇을 적절하게 사용하면 많은 아이디어를 얻을 수 있고 개개인의 업무를 효율화 할 수 있습니다. 그러나 기업에서 고객 대응, 업무용(B2B, B2C)으로 LLM 챗봇을 제공하려고 한다면 그것은 범용 챗봇이 아닐 가능성이 높습니다. 어떠한 주제이든 만능으로 동작하기 보다는 기업의 워크플로우 중 일부를 대신할 수 있을 만큼 해당 분야에 특출난 지식/능력을 갖추는 것이 요구되기 때문입니다.
이 외에도 정보의 최신성, 역동성 등의 이유로 모델 외부의 데이터 소스(External data source)와 연동 되었을 때에만 의미있는 애플리케이션, 서비스로 탄생하는 경우도 있습니다. 결국 범용 모델 그 자체 만으로는 기업들(B2B)과 그 기업의 고객(B2B2C)들의 요구를 충족하기 어렵고, 기업의 니즈를 충족할수 있는 수준으로 가다듬는 과정이 필요합니다.
기업이 원하는 맞춤 LLM 모델을 만드는 3가지 방법
한때는 Tesla의 자율주행팀의 수장이었고, 지금은 OpenAI로 다시 자리를 옮긴 안드레아 카르파티(Andrej Kapathy)는 MS Build 2023에서 맞춤 LLM 모델을 구축하는 3가지 방법을 말하였습니다.
1. 제로 베이스에서 맞춤형 LLM 모델 개발하기
당연하게도 기업이 원하는 맞춤형 모델을 직접 바닥부터 개발하는 방법이 있습니다. 그리고 당연하게도 이렇게 모델을 개발하려면 아주 뛰어나고 숙련된 ML 엔지니어를 확보해야 하고, 많은 양의 관련 데이터가 필요하며 모델 학습을 위한 충분한 인프라를 갖추고 있어야 합니다.
현 시점에서 이런 방식으로 LLM을 출시하는 기업들을 살펴보면 보면 Google, Meta 그리고 국내에서는 네이버, LG AI Research 등 기업들의 규모가 상당하다는 점을 알 수 있습니다. 규모가 큰 기업들만 이 방식으로 모델을 출시했다는 점에서 아무나 이 방식으로 LLM을 개발하긴 어려울 것이라는 점을 유추할 수 있습니다. 오픈소스 툴링이 발전함에 따라 더 많은 기업이 맞춤형 모델을 개발할 것으로 전망되지만 그 진입장벽은 여전히 높고 견고합니다.
2. 파인 튜닝하기
파인 튜닝이란, 사전 학습 모델(pre-trained model)에 도메인 특화 데이터를 추가 학습시켜 맞춤형 모델로 업데이트 하는 것을 의미합니다. 제로 베이스에서 LLM을 개발하는 것보다는 진입 장벽이 낮지만 이 역시 정교한 작업을 할 수 있는 ML 전문가가 필수이며, 파인 튜닝의 과정에서 예측하지 못한 문제를 맞닥뜨리게 되는 경우도 빈번히 발생합니다. 실제 파인 튜닝을 작업을 시도했던 곳에서는 ‘모델 드리프트(Model drift)’*와 같이 예상치 못한 결과가 발생하기도 하였습니다.
*모델 드리프트(Model drift): 모델을 배포한 이후 시간이 지남에 따라 모델 성능이 저하되는 현상
3. 사전 훈련 모델(pre-trained model)을 활용하되 관련 있는 맥락을 검색(retrieve)하기
여러가지 방법이 있지만 이 중 대표적으로 RAG(Retrieval Augmented Generation)라는 방법이 있습니다. 이 기법은 베이스 모델의 외부에서 데이터를 가져와 임베딩을 얻어 Vector DB에 저장하고, 사용자가 질문을 하면 관련도가 가장 높은 임베딩을 찾아내서 모델에 이를 제공하는 방식입니다.
비용적으로 저렴하고, 외부의 데이터를 지속적으로 새로이 가져올 수 있으므로 데이터의 최신성 문제를 해결할 수 있습니다. 또한 ‘근거 있는 생성’을 하기 때문에 LLM의 태생적 문제 중 하나인 할루시네이션(Hallucination)에 대한 대비도 가능합니다. 전통적인 ML 학습의 과정이 불필요 하기 때문에 앞서 제시한 2가지 방법보다 더 빠르게 원하는 LLM 애플리케이션을 만들 수 있는 방법입니다.
기업을 위한 솔루션, 파인 튜닝만이 해답?
LLM을 온전히 처음부터 개발하는 방법의 진입 장벽이 워낙 견고하기 때문에 많은 기업들이 현실적으로 파인튜닝과 RAG 사이에서 고민을 하게 될 것입니다.
RAG라는 기법이 다소 생소하게 들릴수도 있고 기업에서 쓰려면은 범용 모델에 맥락을 제공하는 수준보다는 맞춤형 모델 정도는 되어야 한다고 당연히 생각할 지도 모르지만, 파인튜닝은 신중하게 접근해야 합니다.
OpenAI가 제공하는 파인튜닝 가이드 문서에서도 이 점을 서두에서 강조하고 있는데요. 파인튜닝은 시간과 노력 측면에서 신중하게 접근해야 한다고 하며, 프롬프트 엔지니어링(Prompt Engineering), 프롬프트 체이닝(Prompt Chaining), 함수 호출(Function Calling)과 같은 다양한 방법을 먼저 시도해 본 후에 파인 튜닝을 할 것을 권장한다고 합니다. 범용 모델이 처음에는 잘 하는 것처럼 보이지 않지만 프롬프팅을 잘 했을 때 더 좋은 결과를 내거나 더 좋은 결과를 낼 가능성이 높은 경우가 있으며, 학습용 데이터셋 구축과 학습 환경 구축이 필요한 파인튜닝보다는 프롬프팅과 다른 방법들을 사용한 이터레이션이 더 빠른 피드백을 제공하기 때문입니다.
신중한 고민 끝에 정말로 파인튜닝이 필요하다고 결정 내렸다 하더라도 그에 앞서 프롬프팅 엔지니어링과 다른 도구를 결합한 시도를 해보는 것은 헛 된 시도가 아니고, 모델을 파인 튜닝을 하더라도 프롬프팅과 다른 도구까지 사용하는 경우에 최선을 결과를 낼 수 있다는 점을 강조하기도 합니다.
RAG vs. 파인튜닝을 위한 질문 리스트
Towards Data Science의 아티클 ‘Which is the best tool to boost your LLM application?’ 에서는 파인 튜닝과 RAG사이에서 고민하는 사람들이 고려해야 문제를 다음과 같이 제시하고 있습니다.
1.애플리케이션이 모델 외부 데이터 리소스에 접근할 수 있어야 하는가?
파인튜닝된 모델은 특정 시점까지의 데이터만 학습이 됩니다. 모델 외부 데이터에 대한 상시적 접근이 필요하다면 RAG가 더 효율적인 방법입니다.
2. 베이스 모델의 행동(Behavior), 라이팅 스타일, 도메인 특화 지식 등을 수정/개선해야 하는가?
LLM의 행동(Behavior)을 특정한 뉘앙스, 톤, 용어 등에 적합하게 맞추려고 한다면 파인 튜닝이 더 유리합니다. RAG가 목표한 DB에서 정보를 불러오는 것은 가능하지만, 데이터의 도메인 특화성 전반을 강화한다던가, 언어적인 스타일 등을 수정할 수 있는 것은 아닙니다.
3. 할루시네이션 억제가 얼마나 중요한가?
파인튜닝시 특정 도메인 데이터를 추가로 학습시키기 때문에 이것이 할루시네이션 문제를 다소간 줄여줄 수는 있지만, 익숙하지 않은 입력(Input)이 들어온다면 할루시네이션이 발생할 가능성은 여전합니다. 파인튜닝 방식에서는 이 문제에 대응하기 위해 새로운 데이터를 끊임없이 학습 시켜야 합니다. 반면, RAG는 모든 답변을 근거 있게 생성하기 때문에(based on retrieval evidence) 태생적으로 할루시네이션 방지에 더 유리합니다.
4. 라벨링된 데이터를 얼마나 확보할 수 있는가?
파인튜닝 모델의 품질은 결국 유관 도메인 데이터의 품질과 양에 달려 있습니다. 반면 RAG의 결과물은 학습 데이터의 품질과는 독립적입니다. 충분한 양의 양질의 라벨링 데이터를 확보할 수 없다면 파인튜닝은 적절한 선택이 아닙니다.
5. 데이터의 역동성은 어느 정도인가?
데이터가 정적(static)인지 역동적(dynamic)인지를 살펴보아야 합니다. 데이터의 변동성이 크다면 RAG가 유리합니다. Vector DB를 갱신하는 일이 모델을 추가 학습 시키는 것보다 훨씬 간편한 일이기 때문입니다.
6. 애플리케이션의 의사 결정 과정을 우리가 얼만큼 알고 있어야 할까?
파인 튜닝 모델의 경우 의사결정 과정이 ‘블랙박스’와 같습니다. 반면 RAG 방식은 이 보다 그 과정이 투명합니다. ‘Retrieval(검색)’과 ‘Generation(생성)’ 이라는 2 단계를 살펴보면, Retrieval 단계에서 어떤 외부 문서나 데이터 포인트가 관련성 있는 것으로 판단되고 있는지를 면밀히 살펴볼 수 있고 Generation 단계에서 이를 기반으로 답변을 생성할 수 있기 때문입니다. 높은 수준의 책임성이 필요한 애플리케이션이라면 RAG 방식의 애플리케이션이 파인 튜닝 방식보다 적절합니다.
RAG 기법을 활용한 솔루션으로 LLM 바로 도입하기
RAG 기법을 활용한 솔루션과 그 활용 사례들이 속속 등장하고 있습니다.
일례로 BELLA QNA는 GPT가 연동된 RAG 방식의 Q&A 챗봇으로 고객 문의 대응과 마케팅, 사내 업무 도우미 챗봇 등으로 활용 가능합니다. 위의 활용 사례에서는 데이터의 역동성, 최신성이 애플리케이션 구축에서 필수적인데요. 고객 문의 대응 챗봇이나 마케팅용 챗봇의 경우 매일 바뀌는 이벤트 정보나 상품 정보를 수시로 반영하여 고객에게 전달해야 하고, 사내 업무 도우미 챗봇은 자주 바뀌는 업무 매뉴얼 등을 갱신해주어야 하며 이 방법이 어렵지 않아야 합니다. 쉽게 데이터를 갱신할 수 있는 BELLA QNA Backoffice도 함께 제공하므로 챗봇 관리자가 몇 번의 클릭만으로도 챗봇을 위한 데이터를 갱신할 수 있습니다. 파인 튜닝 방식에서는 상상할 수 없는 최신성을 간편하게 유지할 수 있습니다.
RAG vs. 파인튜닝
품질 관리의 편의성 등을 고려한 현명한 선택
파인튜닝된 모델은 학습이 종료된 시점에 머물러있지만, 정보는 계속 흐릅니다. 파인튜닝을 한 직후의 성능이 만족스럽더라도 지속적으로 처음의 성능을 유지하는 것은 쉬운 일이 아닙니다. 원하는 방향으로 파인튜닝을 하는 것도 도전의 연속이지만, 모델을 지속적으로 재학습을 시키고 성능을 관리하는 것에서 상상 이상의 어려움이 발생할 수 있습니다. RAG가 완벽한 해답은 될 수 없겠지만, RAG 특화 솔루션과 도구, 전문팀과의 협업으로 빠르게 직면한 문제를 해결해볼 수 있는 방법이 존재합니다.
금융, 제조업, 언론에서 선택한 BELLA QNA
RAG 방식으로 웹 문서, pdf, doc, txt 등의 내용에 기반한 GPT Q&A 챗봇 BELLA QNA는 금융, 제조업, 언론 등의 분야에서 이미 사용자들을 만날 준비를 마쳤습니다. 대화형 AI 원천 기술을 보유하고 있는 스켈터랩스의 전문가들이 바로 LLM을 도입할 수 있게 도와드립니다.
