Junhyun
포스트

[LLM] 파인튜닝 vs RAG vs 프롬프트 — 무엇을 언제 쓰나

LLM을 내 목적에 맞추는 세 가지 방법을 비교합니다. 무엇을 바꾸려는지에 따라 답이 갈리는 이유와, 실무에서 어떤 순서로 시도하면 되는지를 논문 근거와 함께 정리합니다.

[LLM] 파인튜닝 vs RAG vs 프롬프트 — 무엇을 언제 쓰나

RAG 편을 쓰면서 “파인튜닝과의 선택 기준은 따로 다루겠다”고 미뤄뒀습니다. 이번 편이 그 자리입니다.

이 질문은 자주 “셋 중 뭐가 제일 좋냐”로 나옵니다. 그런데 그렇게 물으면 답이 안 나옵니다.

질문을 바꿔야 합니다

세 방법은 서로 경쟁하는 대안이 아니라 건드리는 층이 다릅니다.

img_file직접 그린 그림입니다

  • 프롬프트는 지시를 바꿉니다. 모델도 그대로, 자료도 그대로입니다
  • RAG는 모델이 보는 것을 바꿉니다. 모델은 그대로 두고 근거 문서를 붙여줍니다
  • 파인튜닝은 모델 자체를 바꿉니다. 가중치를 다시 학습시킵니다

그래서 물어야 할 것은 “무엇이 더 좋은가”가 아니라 “내가 바꾸려는 게 어느 층인가” 입니다.

새 지식을 넣는 거라면 RAG 쪽입니다

가장 흔한 상황부터 보겠습니다. 모델이 모르는 정보를 알게 하고 싶은 경우입니다.

Fine-Tuning or Retrieval?가 이 둘을 직접 비교했습니다. 결론이 분명합니다.

비지도 파인튜닝도 어느 정도 개선을 주지만, RAG 가 일관되게 더 나았다. 학습 때 본 지식과 완전히 새로운 지식 양쪽에서 그랬다.

같은 논문이 이유에 해당하는 관찰도 함께 내놓습니다. 모델은 비지도 파인튜닝으로 새로운 사실을 배우는 데 어려움을 겪습니다. 같은 사실을 여러 형태로 바꿔가며 많이 보여주면 나아지긴 하지만, 그건 그만큼 손이 더 든다는 뜻이기도 합니다.

정리하면, “우리 회사 규정을 알게 하고 싶다”는 파인튜닝이 아니라 RAG 의 영역입니다. 환각 편에서 “새 지식을 넣는 용도라면 RAG 를 먼저 검토하라”고 적은 근거가 이것입니다.

그런데 배타적이지 않습니다

여기서 “그럼 파인튜닝은 필요 없나” 로 가면 너무 멀리 간 것입니다.

RAG vs Fine-tuning은 농업 데이터로 둘을 같이 써봤습니다. 결과가 흥미롭습니다.

조건정확도
파인튜닝만+6%p 이상
위에 RAG 를 더함+5%p 추가

논문 표현으로 두 효과는 누적(cumulative) 이었습니다. 하나를 고르는 문제가 아니라 쌓는 문제였다는 뜻입니다.

이 수치는 농업 데이터셋 한 건의 실험 결과입니다. 논문이 쓴 모델도 Llama2-13B·GPT-3.5·GPT-4 로 지금 기준으로는 오래됐습니다. “6%p 오른다”를 일반 법칙으로 옮기면 안 됩니다.

그럼 파인튜닝은 언제 쓰나

앞의 두 논문을 겹쳐 보면 방향이 보입니다. 파인튜닝이 잘 듣는 건 지식보다 양식입니다.

바꾸고 싶은 것어울리는 방법
모르는 사실을 알게 하기RAG
자주 바뀌는 정보 반영RAG
출력 형식·말투를 일관되게프롬프트 → 안 되면 파인튜닝
특정 분야의 표현·용어에 익숙해지기파인튜닝
긴 지시문을 매번 안 넣고 싶다파인튜닝
일단 뭐든 빨리 해보기프롬프트

마지막에서 두 번째 줄이 실무에서 의외로 큽니다. 같은 지시를 매 요청마다 넣으면 토큰 비용이 계속 듭니다. 그 지시를 모델에 새겨 넣는 것이 파인튜닝의 현실적인 쓸모 중 하나입니다.

실무에서는 이 순서로

1. 프롬프트부터. 가장 싸고, 즉시 되돌릴 수 있고, 놀랄 만큼 자주 여기서 끝납니다. 형식을 명시하고 예시를 두어 개 주는 것만으로 해결되는 문제가 많습니다.

2. 안 되면 RAG. 모델이 모르는 것 때문에 막힌다면 프롬프트를 아무리 다듬어도 안 됩니다. 근거를 붙여주는 단계입니다.

3. 그래도 안 되면 파인튜닝. 여기까지 왔다면 문제는 대개 지식이 아니라 양식이나 비용입니다.

이 순서를 권하는 이유는 단순합니다. 아래로 갈수록 비용이 크고 되돌리기 어렵습니다. 파인튜닝은 데이터를 모으고, 학습을 돌리고, 결과를 평가하는 과정이 필요하며, 모델을 바꾸면 그 작업을 다시 해야 합니다.

각각이 못 하는 것

프롬프트 — 모델이 모르는 사실은 만들어내지 못합니다. 길어지면 중간이 묻히는 문제도 생기고, 매 요청마다 비용이 붙습니다.

RAG — 검색이 틀리면 거기서 끝입니다. 문서 전체를 훑어야 하는 질문에도 약합니다. 말투나 출력 형식을 바꾸는 용도는 아닙니다.

파인튜닝 — 새 사실을 넣는 데 약하다는 것이 위 논문의 관찰입니다. 비용이 크고, 학습 데이터의 편향을 그대로 흡수하며, 무엇이 달라졌는지 설명하기 어렵습니다. 잘못 학습된 것을 되돌리려면 다시 학습해야 합니다.

정리

세 방법은 고르는 게 아니라 층이 다른 손잡이입니다. 프롬프트는 지시를, RAG 는 모델이 보는 것을, 파인튜닝은 모델 자체를 바꿉니다.

새 지식을 넣는 문제라면 근거는 RAG 쪽을 가리킵니다. 다만 배타적이지 않아서, 한 실험에서는 둘의 효과가 더해졌습니다.

실무 순서는 프롬프트 → RAG → 파인튜닝입니다. 아래로 갈수록 비싸고 되돌리기 어려우니, 위에서부터 시도하고 막히는 지점을 보고 내려가는 편이 낫습니다.

그리고 어느 층에서 막혔는지를 먼저 판단해야 합니다. 모르는 것 때문에 막힌 문제를 프롬프트로 풀려고 하면 오래 헤맵니다.

참고

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.