[LLM] Finetuning – 파인튜닝과 RAG의 관계

파인튜닝 vs RAG – 언제 무엇을 선택할까?

파인튜닝(Finetuning)과 RAG(Retrieval-Augmented Generation)는 모두 모델 성능을 향상시키는 대표적인 방법입니다. 하지만 두 접근법은 목적과 활용 방식에서 본질적인 차이를 갖고 있습니다.

핵심 정리는 이렇습니다:

“파인튜닝은 형식(Form)을 위해, RAG는 사실(Fact)을 위해”

정보 기반 실패에는 RAG가 효과적입니다

만약 모델이 정답을 알고 있지 않아서 틀리는 경우라면, 파인튜닝보다는 RAG가 더 효과적입니다. 예를 들어:

• 모델이 정보를 모르는 경우: 조직 내부 데이터, 최신 뉴스, 논문 등은 기존 모델이 사전학습 시점에 포함하지 못한 경우가 많습니다. 이럴 땐 외부 검색 기반의 RAG가 효과적입니다.
• 모델이 오래된 정보를 가지고 있는 경우: 예컨대 "Taylor Swift의 최신 앨범은?"이라는 질문에 대해 모델의 커트오프 이후 앨범이 나왔다면, 파인튜닝으로 해결하기보다는 RAG를 통해 최신 정보에 접근하는 것이 훨씬 빠르고 정확합니다.

실제로, Ovadia et al. (2024)의 연구에 따르면, 최신 정보가 필요한 질문에 대해서는 RAG가 파인튜닝을 능가하는 성능을 보였습니다.

Model	Base Model Only	+  RAG	FT-reg	FT-par	FT-reg + RAG	FT-par + RAG
Mistral-7B	0.481	0.875	0.504	0.518	0.818	0.830
Llama 2-7B	0.505	0.855	0.525	0.540	0.806	0.830
Orca 2-7B	0.456	0.876	0.511	0.566	0.820	0.826

위 표에서도 알 수 있듯이, 정보 접근이 핵심인 작업에서는 RAG의 도입이 파인튜닝보다 훨씬 더 큰 성능 향상을 이끕니다.

---

행동 기반 실패에는 파인튜닝이 효과적입니다

반면, 모델이 정보를 알고 있음에도 형식을 따르지 못하거나, 요청에 적절하게 반응하지 못하는 경우에는 파인튜닝이 더 적합합니다.

• 출력 형식을 따르지 못할 때: 예를 들어 HTML 코드, SQL 쿼리, JSON과 같은 엄격한 구조화 형식이 요구될 경우, 프롬프트만으로는 한계가 있고 파인튜닝을 통해 정확도를 개선할 수 있습니다.
• 의도와 다른 응답을 줄 때: 예를 들어 엔지니어링 팀에서 요구하는 기술 명세를 생성해야 하는데, 모델이 스타일은 맞지만 구체적인 요구사항을 반영하지 못한다면, 해당 명세로 파인튜닝하는 것이 더 정확한 출력을 유도할 수 있습니다.

또한 파인튜닝은 프롬프트 캐싱(prompt caching)을 가능하게 하여 짧은 프롬프트, 빠른 응답, 낮은 비용이라는 실무적 장점도 제공합니다.

---

파인튜닝과 RAG는 상호보완적입니다

• RAG는 외부 정보에 접근하여 정확성을 높이고,
• 파인튜닝은 출력의 형식, 문체, 응답 패턴을 개선합니다.

두 접근법은 서로를 대체하는 관계가 아니라, 상호보완적으로 사용되어야 합니다.
특히 실제 응용 시스템에서는 하나의 작업에 대해 RAG와 파인튜닝을 조합해서 사용하는 경우가 대부분이며, 이를 통해 정확도와 응답 품질을 동시에 향상시킬 수 있습니다.

RAG와 파인튜닝은 동시에 사용할 수 있습니다

많은 분들이 "RAG를 쓸까, 파인튜닝을 할까?"를 서로 배타적인 선택지로 생각하지만, 실제로는 두 방법을 조합해서 성능을 극대화하는 것이 일반적입니다.

Ovadia et al. (2024)의 연구에 따르면, RAG만 사용했을 때보다 RAG + 파인튜닝을 함께 사용했을 때 더 높은 성능 향상이 일관되게 나타났습니다.
실제로 MMLU 벤치마크(Massive Multitask Language Understanding) 기준으로도, 대부분의 작업에서 파인튜닝보다 RAG가 더 강력한 성능을 보였으며, 이를 기반으로 한 복합 전략이 유효함이 입증되었습니다.

워크플로우 예시: 언제 RAG, 언제 파인튜닝?

OpenAI의 예시를 기반으로 한 Figure 7-3은 다음과 같은 전략적 전환 흐름을 제시합니다:

1. 프롬프트 최적화부터 시작
   예제 없이 프롬프트 자체를 개선합니다 (예: “너는 채점 기준을 가진 교수다…” 등)
2. 프롬프트에 예시 추가
   필요시 프롬프트에 1~50개의 예시(example)를 추가합니다.
3. 정보 부족이 원인이라면 RAG 도입
   외부 검색 기반으로 문서 또는 DB와 연결합니다. 단순 검색 → 하이브리드 검색으로 확장 가능
4. 행동 실패가 원인이라면 파인튜닝 도입
   불완전하거나 잘못된 반응이 반복되면 파인튜닝으로 양식, 스타일, 행동을 교정합니다.
5. 성능 극대화를 원한다면 RAG + 파인튜닝 결합

간단히 정리하자면:

상황	적합한 기법
정보가 부족해서 틀린다면	RAG
형식, 표현이 잘못되었다면	파인튜닝
정보도 부족하고 행동도 어긋난다면	RAG + 파인튜닝 조합

---

파인튜닝에서 가장 큰 도전 과제: 메모리 병목 (Memory Bottleneck)

파인튜닝의 가장 현실적인 제약 중 하나는 메모리 사용량입니다.
대형 모델의 파인튜닝은 수십 GB의 GPU 메모리를 요구하며, 이는 학습뿐 아니라 추론(inference) 시점에도 큰 부담으로 작용합니다.

이 장에서는 이어서 다음과 같은 내용을 다루게 됩니다:

• 파인튜닝 기법별 메모리 사용량 비교
• 메모리 병목을 줄이는 효율적 파인튜닝 전략(예: LoRA, QLoRA 등)
• 파인튜닝을 위한 하드웨어 요구사항 계산법 (백오브더넵킨 방식)

이는 특히 온프레미스 환경이나 제한된 자원을 가진 조직, 스타트업, 개인 연구자에게 중요한 내용이 됩니다.

---

마무리하며 – 전략적 파인튜닝을 위한 실전 설계 포인트

마지막으로, 파인튜닝 설계를 고민하실 때 아래 항목들을 꼭 점검해보시기 바랍니다.

체크리스트설명

✅ 목적이 명확한가?	단순 성능 향상인지, 형식 통제인지, 도메인 특화인지 구체적으로 정의
✅ 프롬프트로 해결 가능한가?	파인튜닝 없이 가능한 최선의 prompt 실험을 거쳤는가
✅ 정보가 부족한가?	최신 데이터가 필요한가, 폐쇄형 정보가 필요한가
✅ 행동 문제가 반복되는가?	스타일, 형식 오류가 반복된다면 파인튜닝 고려
✅ 자원이 충분한가?	GPU 메모리, 스토리지, 인력 등 운영 인프라 준비 여부
✅ RAG와 조합 가능한가?	단일 접근보다 조합이 더 효율적일 수 있음