RAG와 미세 조정: 무엇을 언제 사용할까

특정 도메인에서 LLM이 잘 작동하도록 해야 할 때는 두 가지 주요 전략이 있습니다. 검색 증강 생성(RAG)은 추론 시점에 관련 지식을 동적으로 주입하는 반면, 파인 튜닝은 모델의 가중치를 업데이트하여 지식, 스타일 또는 형식 선호도를 모델에 내재화합니다. 둘 중 올바르게 선택하는 것은 신뢰할 수 있는 시스템을 구축할지, 잘못된 접근 방식에 수개월 동안 값비싼 GPU 연산을 낭비할지를 좌우할 수 있습니다.

파인 튜닝은 예시 입력-출력 쌍으로 학습하여 모델의 가중치를 업데이트합니다. 파인 튜닝은 동작을 변경하는 데 뛰어납니다. 예를 들어 모델이 항상 특정 JSON 형식으로 응답하도록 가르치거나, 브랜드의 말투를 사용하게 하거나, 도메인별 추론 패턴을 따르게 하거나, 최적화되지 않았던 작업 유형을 수행하게 할 수 있습니다. 파인 튜닝이 사실 지식을 안정적으로 업데이트하는 것은 아닙니다. 모델은 학습 예시에 과적합하면서도 그 근본적인 사실을 새로운 질의에 일반화하지 못할 수 있습니다.

RAG는 모델의 가중치를 수정하지 않습니다. 대신 관련 문서를 컨텍스트 창에 배치하여 추론 시점에 모델이 이용할 수 있는 정보를 변경합니다. RAG는 지식과 관련된 작업, 즉 비공개 문서에 대한 질문에 답하거나, 자주 업데이트되는 데이터에 맞춰 최신 답변을 제공하거나, 검증 가능한 출처에 응답을 근거하는 작업에 뛰어납니다. RAG로 쉽게 변경할 수 없는 것은 모델 고유의 스타일, 형식 선호도 또는 추론 방식입니다.

정보가 시간에 따라 변경되는 모든 사용 사례에서는 RAG가 분명히 우수합니다. 문서가 업데이트될 때 벡터 저장소를 다시 색인하는 데는 몇 분이면 되며 GPU 리소스도 필요하지 않습니다. 새로운 데이터로 모델을 파인 튜닝하려면 재학습이 필요하고(비용과 시간이 많이 듦), 그렇게 하더라도 모델이 새로운 사실을 안정적으로 기억하지 못할 수 있습니다. 제품 카탈로그, 법률 규정, 의료 지침, 회사 정책에는 모두 파인 튜닝보다 RAG가 더 적합합니다.

프롬프트 엔지니어링만으로는 안정적으로 강제할 수 없는 매우 구체적인 스타일, 어조 또는 구조화된 형식으로 모델이 항상 응답해야 한다면 파인 튜닝이 적합한 도구입니다. 예를 들어 브랜드 고유의 어휘를 항상 사용해야 하는 고객 서비스 봇, 회사의 내부 스타일 가이드에 맞는 코드를 생성해야 하는 코드 생성기, 수천 가지 예외 사례에서 엄격한 분류 체계를 안정적으로 출력해야 하는 분류 모델 등이 있습니다.

파인 튜닝은 초기 비용이 높지만(학습을 위한 연산, 데이터 세트 준비 시간, 평가 비용), 더 작은 모델을 사용할 수 있게 해 준다면 질의당 비용을 줄일 수 있습니다. RAG는 초기 비용이 낮지만(벡터 데이터베이스 색인 비용이 저렴함) 질의당 추가 비용이 발생합니다. 여기에는 임베딩 API 호출과 주입된 컨텍스트로 인해 약간 길어진 프롬프트가 포함됩니다. 일일 질의 수가 1,000만 건 미만인 대부분의 애플리케이션에서는 파인 튜닝 개발 비용에 비해 RAG의 질의당 추가 비용이 무시할 수 있는 수준입니다.

파인 튜닝된 모델은 더 짧은 프롬프트가 필요하므로 추론 속도가 더 빠를 수 있습니다. 지식이 컨텍스트가 아니라 가중치에 들어 있기 때문입니다. RAG는 두 번의 왕복을 추가합니다. 하나는 임베딩 API 호출이고, 다른 하나는 벡터 검색 질의입니다. 전체 추가 지연 시간은 일반적으로 50~200ms입니다. 실시간 음성 비서와 같이 지연 시간에 민감한 애플리케이션에서는 이 추가 시간이 중요합니다. 대부분의 채팅 및 질의응답 애플리케이션에서는 사용자가 추가 지연을 거의 느끼지 못합니다.

RAG는 명확한 감사 추적 기록을 제공합니다. 모든 답변에 대해 어떤 문서가 검색되었는지 정확히 알 수 있고 이를 사용자에게 보여 줄 수 있습니다. 파인 튜닝된 모델은 불투명한 가중치를 바탕으로 답변하므로 특정 출력을 생성한 학습 예시에 대한 기록이 없습니다. 금융, 의료, 법률과 같이 답변을 설명하고 검증할 수 있어야 하는 규제 산업에서는 RAG의 투명성이 파인 튜닝에 비해 중요한 장점입니다.

RAG와 파인 튜닝은 서로 배타적이지 않습니다. 일반적인 실제 운영 패턴은 모델을 파인 튜닝하여 출력 형식과 도메인 어휘를 일관되게 만든 다음, RAG를 추가하여 최신 사실 지식을 제공하는 것입니다. 파인 튜닝된 모델은 스타일과 구조를 안정적으로 처리하고, RAG는 지식을 처리합니다. 이 조합은 중요도가 높은 기업 애플리케이션에서 어느 한 가지 접근 방식만 사용하는 것보다 뛰어난 성능을 보입니다.

다음 의사 결정 경로를 따르십시오. 문제가 스타일 또는 형식의 일관성에 관한 것인가요? → 파인 튜닝을 고려하십시오. 정보가 비공개이거나 자주 업데이트되나요? → RAG를 사용하십시오. 출처 인용이 필요한가요? → RAG를 사용하십시오. 데이터 세트가 파인 튜닝에 너무 작은가요(예시 500개 미만)? → 소수 샷 프롬프트와 함께 RAG를 사용하십시오. 모델이 현재 수행을 거부하는 작업을 처리해야 하나요? → RLHF 또는 DPO를 사용해 파인 튜닝하십시오. 확실하지 않다면 RAG로 시작하십시오. 구축이 더 빠르고, 업데이트가 더 쉬우며, 투명하기 때문입니다.

다음 상황을 통해 감을 익혀 보십시오. 사내 HR 챗봇(정책이 분기마다 변경되고 출처를 인용해야 함) → RAG. 독점 프레임워크용 코드 자동 완성(일관된 코드 스타일과 프레임워크 패턴) → 파인 튜닝. 법률 문서 질의응답(비공개 문서와 정확한 인용이 필요함) → RAG. 고객 지원 봇(특정 어조가 필요하고 제품 FAQ가 매주 변경됨) → 어조에는 파인 튜닝 + 지식에는 RAG. 의학 문헌 요약기(최신 연구와 중요한 출처 표시) → RAG.

이 레슨에서 배운 AI 엔지니어링 개념을 이해했는지 확인해 보십시오.

이 레슨에서는 파인 튜닝이 모델의 동작과 스타일을 변경하지만 사실 지식을 안정적으로 변경하지는 않는다는 점, RAG가 완전한 투명성과 출처 인용을 제공하면서 추론 시점에 지식을 동적으로 공급한다는 점, 그리고 선택을 위한 의사 결정 프레임워크를 배웠습니다. 즉, 출처 표시가 필요한 자주 업데이트되는 비공개 지식에는 RAG를 사용하고, 일관된 스타일과 형식에는 파인 튜닝을 사용하며, 중요도가 높은 기업 애플리케이션에는 두 가지를 결합합니다. 다음으로는 처음부터 완전한 RAG 파이프라인을 구축해 보겠습니다.