RAG는 질문할 때 관련 자료를 찾아 모델에 전달합니다. 파인튜닝(Fine-tuning)은 예시 데이터로 모델을 추가 학습시켜 특정한 작업이나 형식에 더 잘 맞도록 조정합니다. 두 방법은 경쟁 관계라기보다 바꾸는 대상이 다릅니다.

자료를 참고시키는 RAG

예를 들어 제품 설명서가 매주 바뀐다면, 질문을 받을 때 최신 설명서의 관련 부분을 찾는 방식이 자연스럽습니다. 사용자는 답의 출처를 열어볼 수도 있습니다. RAG의 검색과 답변 생성 과정을 먼저 보면 이 차이를 이해하기 쉽습니다.

다만 문서가 있다고 끝나지는 않습니다. 검색이 엉뚱한 부분을 찾거나, 가져온 내용이 질문을 해결하기에 부족하면 답변도 흔들립니다.

모델을 조정하는 파인튜닝

파인튜닝은 입력과 원하는 출력의 예시를 사용해 모델의 동작을 조정합니다. 예를 들어 특정 형식으로 문장을 분류하거나 일관된 출력 구조를 따르게 하는 데 검토할 수 있습니다. 학습 데이터의 품질과 모델·서비스가 지원하는 학습 방식이 중요합니다.

최신 회사 규정을 파인튜닝만으로 계속 반영하려면 자료가 바뀔 때마다 학습과 검증이 필요할 수 있습니다. 학습한 내용을 모델이 정확히 기억하고 출처까지 제시한다고 가정해서도 안 됩니다.

이 표는 일반적인 경향입니다. 실제 선택은 모델, 데이터, 정확도 요구, 운영 비용에 따라 달라집니다.

어떤 질문부터 해야 할까

업데이트되는 사실을 답해야 한다면 먼저 “모델이 읽을 자료를 어떻게 제공할까?”를 생각해 보세요. 일정한 응답 형식이나 특정 작업 수행이 문제라면 “좋은 예시 데이터로 모델의 동작을 조정할 필요가 있을까?”를 검토할 수 있습니다. 두 요구가 함께 있으면 두 방식을 함께 사용할 수도 있습니다.

중요한 것은 “내 데이터가 있으니 파인튜닝”처럼 방법을 먼저 정하지 않는 것입니다. 필요한 정보가 어디에 있고 얼마나 자주 바뀌는지, 답의 출처가 필요한지를 먼저 확인해야 합니다.

핵심 정리

RAG는 지금 읽을 자료를 바꾸고, 파인튜닝은 모델의 동작을 조정합니다. 최신 정보와 출처가 중요하면 RAG를, 특정 작업의 일관된 수행이 중요하면 파인튜닝을 검토할 수 있습니다. 어느 쪽도 정확성을 자동으로 보장하지 않으므로 실제 질문과 데이터로 확인해야 합니다.

참고 자료

• AWS: RAG와 파인튜닝 비교
• Google Cloud: Retrieval-augmented generation 개요

짧게 말하면 검색으로 근거를 찾고, 언어 모델이 그 근거를 바탕으로 문장을 작성합니다. 모델의 지식을 매번 다시 학습시키는 방식과는 다릅니다.

어떤 일이 일어나나

사용자가 “올해 재택근무 신청 기준이 뭐야?”라고 물었다고 가정해봅시다. 시스템이 할 일은 크게 세 가지입니다.

1. 검색: 사내 규정 문서에서 질문과 관련된 부분을 찾습니다.
2. 문맥 구성: 찾은 문서 조각과 사용자 질문을 모델의 입력에 넣습니다.
3. 답변 생성: 모델이 전달받은 자료를 읽고 답합니다. 문서의 제목이나 링크를 함께 보여주면 사용자가 근거를 확인할 수 있습니다.

예를 들어 검색 결과에 “주 2회까지 신청 가능하며 팀장 승인 필요”라고 적혀 있다면, 모델은 그 내용을 토대로 답할 수 있습니다. 검색 결과가 없다면 모른다고 말하게 하는 편이 근거 없는 답을 만드는 것보다 낫습니다.

질문: 재택근무 신청 기준이 뭐야?
검색된 문서: 인사 규정 4.2 — 주 2회까지, 팀장 승인 필요
답변: 인사 규정 4.2에 따르면 주 2회까지 신청할 수 있고 팀장 승인이 필요합니다.

이 예시는 원리를 보여주기 위한 단순화입니다. 실제 결과는 문서의 상태, 검색 품질, 모델의 해석에 따라 달라집니다.

검색과 생성은 서로 다른 역할이다

검색기는 무엇을 읽을지 정합니다. 언어 모델은 읽은 내용을 어떻게 답으로 표현할지 정합니다. 검색이 관련 없는 문서를 가져오면 모델이 아무리 문장을 잘 만들어도 정확한 답을 기대하기 어렵습니다. 반대로 올바른 문서를 찾았더라도 모델이 문서에 없는 내용을 보태면 답이 틀릴 수 있습니다.

문서를 찾는 방법도 하나만 있는 것은 아닙니다. 단어가 정확히 일치하는 문서를 찾는 방법, 문장의 의미가 비슷한 문서를 찾는 방법, 두 방법을 함께 쓰는 방법이 있습니다. 의미 기반 검색에서는 문장을 숫자 벡터로 바꾸는 임베딩이 자주 쓰입니다.

RAG가 유용한 상황

문서가 자주 바뀌거나, 답의 근거를 보여줘야 할 때 유용합니다. 제품 설명서, 사내 지식 문서, 정책 안내가 대표적인 예입니다. 자료를 바꾸면 다음 검색부터 새 문서를 참고할 수 있다는 장점도 있습니다. 다만 문서 업데이트가 곧 정확한 답변을 보장하는 것은 아닙니다.

흔한 오해: RAG를 붙이면 환각이 사라진다?

그렇지 않습니다. 검색 결과가 부정확할 수 있고, 모델이 자료를 잘못 읽거나 자료 밖의 내용을 만들어낼 수도 있습니다. RAG는 참고 자료를 제공하는 구조이지, 모든 답변에 자동으로 사실성을 부여하는 장치가 아닙니다.

또 하나의 오해는 RAG에 반드시 벡터 데이터베이스가 필요하다는 생각입니다. 작은 문서 집합에서는 단순 검색으로 시작할 수도 있습니다. 어떤 검색 방식을 고를지는 문서와 질문의 성격에 달려 있습니다.

핵심 정리

RAG는 모델 바깥의 자료를 찾아 입력에 더한 뒤 답을 생성합니다. 검색은 근거를 찾고, 모델은 그 근거를 읽어 답합니다. 따라서 “모델이 무엇을 아는가”만큼 “어떤 자료를 찾아 전달했는가”가 중요합니다. 모델 자체를 조정하는 방식과의 차이는 RAG와 파인튜닝 비교에서 이어서 볼 수 있습니다.

참고 자료

• Google Cloud: Retrieval-augmented generation 개요
• AWS: RAG와 파인튜닝 비교