RAG or 파인튜닝? 선택 전 던져야할 몇가지 질문들
학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 번역 과정에서 의미 전달이 애매한 일부 문장은 삭제했습니다. 이번 에는 AWS 생성AI 부문 시니저 솔루션 아키텍트인 Heiko Hotz가 미디엄에 공유한 글 일부를 정리한 것입니다.
거대 언어 모델(LLM)들에 대한 관심이 급증하면서 많은 개발자와 조직들이 이를 활용하는 애플리케이션을 구축하느라 분주하다. 하지만 사전 학습된 LLM이 기대한 대로 또는 희망한 대로 작동하지 않을 때, LLM 애플리케이션 성능을 개선하는 방법이 궁금하게 마련이다. 결국 스스로질문을 이런 던지게 된다: 결과를 개선하기 위해 검색 증강 생성(RAG)이나 모델 파인 튜닝(Finetuning)을 사용해야 할까?
더 자세히 알아보기 전에 이 두 가지 방법에 대해 알아보자.
RAG: 이 방식은 검색(retrieval or searching)의 강력한 기능을 LLM 텍스트 생성에 통합한다. 대규모 말뭉치에서 관련 문서 스니펫을 가져오는 리트리버 시스템(retriever system)과 이러한 스니펫 정보를 사용해 답변을 생성하는 LLM을 결합한 것이다. 본질적으로 RAG는 모델이 외부 정보를 '조회'해 응답을 개선할 수 있도록 도와준다.
파인튜닝: 사전 학습된 LLM을 더 작은 특정 데이터 세트에 대해 추가로 학습시켜 특정 작업에 맞게 조정하거나 성능을 개선하는 프로세스다. 미세 조정을 통해 데이터를 기반으로 모델 가중치를 조정해 애플리케이션의 고유한 요구사항에 LLM을 보다 최적화시킬 수 있다.
RAG와 파인튜닝 모두 LLM 기반 애플리케이션 성능을 향상시키는 강력한 도구들이지만 최적화 프로세스의 다른 측면을 다루기 때문에 둘 중 하나를 선택할 때는 이를 고려해야 한다. 이전에는 조직들에 파인튜닝에 뛰어들기 전에 RAG로 실험해 보라고 제안하곤 했다. 이는 두 접근 방식이 비슷한 결과를 얻을 수 있지만 복잡성, 비용, 품질 측면에서 차이가 있다는 인식에 근거한 것이었다.
RAG는 더 간단하고 저렴하지만 품질이 떨어질 수 있다. 나는 보통 RAG로 시작해 성능을 측정한 후 부족한 부분이 발견되면 파인튜닝으로 전환하라고 조언했다. 하지만 이후로 내 관점은 달라졌다. RAG와 파인튜닝을 같은 결과를 달성하는 두 가지 기법으로 보는 것은 지나치게 단순화시킨 것이라고 생각한다. RAG와 파인튜닝은 근본적으로 다른 기술이며 LLM 애플리케이션의 서로 다른 요구 사항을 충족한다.
이를 더 명확하게 이해하기 위해 간단한 현실 세계 비유를 생각해보자.: "식사를 할 때 칼을 사용해야 하나, 숟가락을 사용해야 하나?"라는 질문을 던졌을 때 가장 논리적인 반문은 "그럼, 무엇을 먹고 있나요?"이다. 친구와 가족에게 이 질문을 던졌더니 모두 본능적으로 이 반문으로 대답했는데, 이는 그들이 칼과 숟가락을 서로 바꿀 수 있는 것으로 생각하지 않거나 어느 한 쪽이 다른 쪽의 열등한 변형이라고 생각하지 않는다는 것을 보여준다.
무슨 뜻일까?
이번 글에선 특정 작업에 가장 적합한 기법을 결정하는 데 중요한 여러 차원들에 걸쳐 RAG와 파인튜닝을 구분하는 뉘앙스에 대해 자세히 살펴볼 것이다. LLM 애플리케이션에서 가장 많이 사용되는 몇 가지 사용 사례를 살펴보고 첫 번째 부분에서 설정한 차원을 사용해 어떤 기술이 어떤 사용 사례에 가장 적합한지 구별할 것이다. 마지막 부분에서는 LLM 애플리케이션을 구축할 때 고려해야 할 추가적인 측면을 살펴볼 것이다 각 측면들은 별도 블로그 포스팅이 필요할 수 있으므로 이번에는 간략하게 다룬다.
왜 신경 써야 할까?
LLM을 적용하는 데 적합한 기술을 선택하는 것은 NLP 애플리케이션 성공에 큰 영향을 미칠 수 있다. 잘못된 접근 방식을 선택하면 다음과 같은 결과를 초래할 수 있다:
특정 작업에서 모델 성능이 저하돼 부정확한 결과물이 나올 수 있다
기술이 사용 사례에 최적화되지 않은 경우 모델 학습 및 추론에 대한 컴퓨팅 비용 증가.
나중에 다른 기법으로 전환해야 하는 경우 추가 개발 및 반복 시간.
애플리케이션을 배포하고 사용자에게 제공하는 데 지연이 발생할 수 있다
지나치게 복잡한 적응 방식을 선택할 경우 모델 해석 가능성 부족.
크기 또는 계산상 제약으로 인해 모델을 프로덕션에 배포하기 어려움.
RAG와 파인튜닝 간 미묘한 차이는 모델 아키텍처, 데이터 요구 사항, 계산 복잡성 등에 걸쳐 있다. 이들 세부 사항을 간과하면 프로젝트 일정과 예산에 차질이 생길 수 있다. 이번 글은 각 기법들이 유리한 시점을 명확하게 제시해 헛수고를 방지하는 것이 목표다. 그럼 시작해보자.
성능 향상을 위한 주요 고려 사항
RAG와 파인튜닝을 선택하기 전 몇 가지 측면에서 LLM 프로젝트 요구 사항을 평가하고 몇 가지 질문을 스스로에게 던져야 한다.
사용 사례에 외부 데이터 소스에 대한 액세스가 필요한가?
LLM을 파인튜닝할지 RAG를 사용할지 선택할 때 한 가지 중요한 고려 사항은 애플리케이션에 외부 데이터 소스에 대한 액세스가 필요한지 여부다. 대답이 '예'라면 RAG가 더 나은 옵션일 가능성이 높다. RAG 시스템은 정의상 응답을 생성하기 전에 지식 소스에서 관련 정보를 검색해 LLM 기능을 보강하도록 설계됐다. 따라서 RAG는 데이터베이스, 문서 또는 기타 정형/비정형 데이터 리포지토리를 쿼리해야 하는 애플리케이션들에 매우 적합하다. 리트리버(retriever )와 제너레이터(generator)는 이러한 외부 소스를 활용하도록 최적화할 수 있다.
반대로 외부 지식을 학습하도록 LLM을 파인튜닝할 수는 있지만, 그렇게 하려면 대상 분야 질문-답변 쌍으로 구성된 대규모 라벨이 지정된 데이터셋이 필요하다. 이 데이터셋은 기반(underlying) 데이터가 변경될 때마다 업데이트되어야 하므로 자주 변경되는 데이터 소스에는 실용적이지 않다. 또 파인튜닝 프로세스는 외부 지식을 쿼리하는 데 관련된 검색 및 추론 단계를 명시적으로 모델링하지 않는다. 요약하면 애플리케이션에서 외부 데이터 소스를 활용해야 하는 경우, RAG 시스템을 사용하는 것이 파인튜닝만으로 필요한 지식을 '구워 넣는' 것보다 더 효과적이고 확장성이 높을 수 있다.
모델 동작, 글쓰기 스타일 또는 도메인별 지식을 수정해야 하나?
고려해야 할 또 다른 매우 중요한 측면은 모델 동작, 작성 스타일을 조정하거나 도메인별 애플리케이션에 맞게 응답을 조정하기 위해 모델이 얼마나 필요한지 여부다.
파인튜닝은 특정 뉘앙스, 어조 또는 용어에 맞게 LLM 동작을 조정하는 데 탁월한 능력을 발휘한다. 모델이 의료 전문가처럼 들리도록 하거나, 시적인 스타일로 글을 쓰거나, 특정 산업 전문 용어를 사용하도록 하려는 경우 도메인별 데이터에 대한 파인튜닝을 통해 이를 달성할 수 있다. 모델 동작에 영향을 미치는 이들 기능은 특정 스타일이나 도메인 전문 지식에 부합하는 것이 중요한 애플리케이션에 필수적이다.
RAG는 외부 지식을 통합하는 데는 강력하지만 주로 정보 검색에 중점을 두며 검색된 정보를 기반으로 언어 스타일이나 도메인 특이성을 본질적으로 조정하지는 않는다. 외부 데이터 소스에서 관련 콘텐츠를 가져올 수는 있지만 파인튜닝된 모델이 제공할 수 있는 맞춤형 뉘앙스나 도메인 전문성을 보여주지 못할 수 있다.
따라서 애플리케이션에 특수한 작문 스타일이나 도메인별 언어 및 관습에 대한 심층적인 조율이 필요한 경우, 파인튜닝이 이를 달성할 수 있는 보다 직접적인 경로를 제공한다. 특정 대상 또는 전문 분야에 진정으로 공감을 불러일으키는 데 필요한 깊이와 맞춤화를 제공해 생성된 콘텐츠가 진정성 있고 충분한 정보를 제공한다고 느낄 수 있도록 보장한다.
간단한 요약
이 두 가지 측면은 LLM 애플리케이션 성능을 향상시키는 데 사용할 방법을 결정할 때 고려해야 할 가장 중요한 요소들이다. 흥미롭게도 이 두 가지 방법은 서로 직교하며 독립적으로 사용할 수도 있고 결합해 사용할 수도 있다. 하지만 사용 사례를 살펴보기 전에 방법을 선택하기 전에 고려해야 할 몇 가지 주요 측면들이 더 있다.
환각을 억제하는 것이 얼마나 중요한가?
LLM에서 한 가지 단점은 현실에 근거가 없는 사실이나 세부 사항을 만들어내는 환각 경향이다. 이는 정확성과 진실성이 중요한 애플리케이션에서 큰 문제가 될 수 있다. 파인 튜닝을 통해 특정 도메인 학습 데이터를 활용해 환각을 어느 정도 줄일 수 있다. 그러나 익숙하지 않은 입력에 직면했을 때 모델은 여전히 응답을 조작할 수 있다. 허위 조작을 지속적으로 최소화하려면 새로운 데이터에 대한 재훈련이 필요하다.
반면, RAG 시스템은 응답시 검색된 증거에 근거를 두기 때문에 본질적으로 환각에 덜 취약하다. 검색기는 생성기가 답변을 구성하기 전에 외부 지식 소스에서 관련 사실을 식별한다. 이 검색 단계는 사실 확인 메커니즘으로 작용해 모델의 혼동 능력을 줄여준다. 제너레이터는 검색된 컨텍스트에 의해 지원되는 응답을 합성하도록 제한한다.
따라서 허위와 상상적 조작을 억제하는 것이 중요한 애플리케이션에서 RAG 시스템은 환각을 최소화하는 메커니즘을 내장하고 있다. 응답을 생성하기 전에 뒷받침하는 증거를 검색하면 RAG는 사실에 입각한 정확하고 진실한 결과물을 보장하는 데 유리하다.
얼마나 많은 라벨링 학습 데이터를 사용할 수 있나?
RAG와 파인 튜닝 중 하나를 결정할 때 고려해야 할 중요한 요소는 사용할 수 있는 도메인 또는 작업별 라벨링된 학습 데이터의 양이다. 특정 작업이나 도메인에 맞게 LLM을 파인튜닝하는 것은 사용 가능한 라벨링된 데이터의품질과 양에 따라 크게 달라진다. 풍부한 데이터셋은 모델이 특정 도메인 뉘앙스, 복잡성, 고유한 패턴을 심층적으로 이해해 보다 정확하고 맥락에 맞는 응답을 생성하는 데 도움이 될 수 있다. 그러나 제한된 데이터셋으로 작업하는 경우 파인튜닝을 통한 개선 효과가 미미할 수 있다. 경우에 따라 데이터셋이 부족하면 모델이 학습 데이터에서는 잘 작동하지만 보이지 않거나 실제 입력에 대해서는 어려움을 겪는 과적합(overfitting)으로 이어질 수도 있다.
반대로 RAG 시스템은 외부 지식 소스를 활용해 관련 정보를 검색하기 때문에 학습 데이터로부터 독립적이다. 라벨링된 광범위한 데이터셋이 없더라도 RAG 시스템은 외부 데이터 소스에서 인사이트에 액세스하고 이를 통합함으로써 유능한 성능을 발휘할 수 있다. 검색과 생성을 결합하면 도메인별 학습 데이터가 부족한 경우에도 시스템이 정보를 유지할 수 있다.
기본적으로 도메인 복잡성을 파악할 수 있는 라벨링 데이터가 풍부하다면 파인 튜닝을 통해 보다 맞춤화되고 정제된 모델 동작을 제공할 수 있다. 그러나 이러한 데이터가 제한적인 시나리오에서는 RAG 시스템이 강력한 대안을 제공해 애플리케이션이 검색 기능을 통해 데이터에 기반하고 상황에 맞는 인식을 유지할 수 있도록 한다.
데이터가 얼마나 정적인가, 동적인가?
RAG와 파인튜닝 중 선택할 때 고려해야 할 또 다른 기본적인 측면은 데이터의 동적 특성이다. 데이터가 얼마나 자주 업데이트되며, 모델을 최신 상태로 유지하는 것이 얼마나 필수적인가?
특정 데이터셋에 대한 LLM을 파인튜닝하는 것은 모델의 지식이 학습 시점에 해당 데이터 정적 스냅샷이 된다는 것을 의미한다. 데이터가 자주 업데이트, 변경 또는 확장되는 경우, 이로 인해 모델이 빠르게 구식이 될 수 있다. 이러한 동적 환경에서 LLM을 최신 상태로 유지하려면 자주 재학습해야 하는데, 이 과정은 시간과 리소스가 많이 소요될 수 있다. 또 업데이트된 모델이 다양한 시나리오에서 여전히 잘 작동하는지, 새로운 편향이나 이해의 공백이 발생하지 않았는지 확인하기 위해 각 반복마다 세심한 모니터링이 필요하다.
반대로 RAG 시스템은 본질적으로 동적 데이터가 있는 환경에서 유리하다. 검색 메커니즘은 외부 소스를 지속적으로 쿼리해 응답을 생성하기 위해 가져오는 정보가 최신 상태인지 확인한다. 외부 지식 기반 또는 데이터베이스가 업데이트되면 RAG 시스템은 이러한 변경 사항을 원활하게 통합해 모델을 자주 재교육할 필요 없이 관련성을 유지한다.
요약하면 빠르게 진화하는 데이터 환경과 씨름하고 있다면 RAG는 기존 파인 튜닝으로는 따라올 수 없는 민첩성을 제공한다. RAG는 항상 최신 데이터에 연결 상태를 유지함으로써 생성된 응답이 현재 정보 상태와 일치하도록 보장하므로 동적 데이터 시나리오에 이상적인 선택이다.
LLM 앱이 필요로 하는 투명성/해석 가능성은 어느 정도인가?
마지막으로 고려해야 할 측면은 모델 의사 결정 프로세스에 대한 인사이트가 어느 정도 필요한지다. LLM을 파인튜닝하는 것은 매우 강력하지만 블랙박스처럼 작동하므로 응답의 추론이 불투명해질 수 있다. 모델이 데이터셋 정보를 내재화함에 따라 각 응답의 정확한 출처나 추론을 파악하기가 어려워진다. 이로 인해 개발자나 사용자가 모델의 출력을 신뢰하기 어려울 수 있다. 특히 답변 뒤에 숨은 '이유'를 이해하는 것이 중요한 중요한 애플리케이션에서는 더욱 그렇다.
반면 RAG 시스템은 일반적으로 파인튜닝된 모델에서는 볼 수 없는 수준의 투명성을 제공한다. 검색과 생성 두 단계로 이루어지는 RAG 특성을 고려할 때 사용자는 프로세스를 들여다볼 수 있다. 검색 구성 요소를 통해 어떤 외부 문서 또는 데이터 포인트가 관련성이 있는 것으로 선택되었는지 검사할 수 있다. 이는 대응이 구축되는 기반을 이해하기 위해 평가할 수 있는 증거 또는 참조의 가시적인 흔적을 제공한다. 특정 데이터 소스에 대한 모델의 답변을 추적하는 기능은 고도의 책임성이 요구되는 애플리케이션이나 생성된 콘텐츠 정확성을 검증해야 하는 경우에 매우 유용할 수 있다.
본질적으로 투명성과 모델 응답의 기반을 해석하는 능력이 우선시되는 경우 RAG는 분명한 이점을 제공한다. 응답 생성을 여러 단계로 세분화하고 데이터 검색에 대한 인사이트를 제공함으로써 RAG는 결과물에 대한 신뢰와 이해를 높일 수 있다.
요약
이러한 차원들을 고려하면 RAG와 파인튜닝 중 하나를 선택하는 것이 더 직관적이다. 외부 지식을 활용하고 투명성을 중요하게 생각한다면 RAG를 사용하는 것이 좋다. 반면 안정적으로 라벨링된 데이터로 작업하고 모델을 특정 요구 사항에 더 가깝게 조정하는 것이 목표라면 파인튜닝이 더 나은 선택이다.
