RAG란 무엇인가 — 파인튜닝과의 차이
RAG(Retrieval-Augmented Generation)는 질문이 들어오면 사내 문서에서 관련 구절을 먼저 검색한 뒤, 그 구절을 근거로 답변을 생성하는 방식입니다. 모델 자체를 바꾸지 않기 때문에 문서가 바뀌면 즉시 반영됩니다.
파인튜닝은 모델의 말투나 출력 형식을 고정할 때 적합하고, 사실 정보를 최신으로 유지하는 목적에는 맞지 않습니다. 인사 규정이나 제품 스펙처럼 자주 바뀌는 정보라면 RAG가 기본값입니다.
- 정보가 자주 바뀐다 → RAG
- 출력 형식·톤을 고정해야 한다 → 파인튜닝 또는 프롬프트 설계
- 출처를 제시해야 한다 → RAG (검색된 원문을 인용 가능)
1단계 — 문서 수집 범위 정하기
처음부터 전사 문서를 넣으면 검색 품질이 떨어집니다. 질문 빈도가 높은 영역 하나를 골라 시작하는 편이 안전합니다. 인사 규정, 영업 제안서, 제품 매뉴얼이 흔한 출발점입니다.
문서를 모을 때는 최신본 여부와 공개 범위를 함께 확인해야 합니다. 폐기된 구버전이 섞이면 AI가 잘못된 규정을 근거로 답변합니다.
- 질문 빈도 상위 1개 도메인으로 범위 한정
- 구버전·초안 문서 제외
- 부서별 열람 권한을 문서 단위로 기록
2단계 — 청킹, 문서를 검색 단위로 쪼개기
문서 전체를 통째로 검색 단위로 쓰면 관련 없는 내용까지 딸려 들어옵니다. 보통 수백~천 자 단위로 쪼개되, 문단이나 조항 경계에서 끊는 편이 검색 정확도가 높습니다.
조항 번호가 있는 규정 문서는 조항 단위로, 서술형 매뉴얼은 소제목 단위로 나누는 식으로 문서 성격에 맞춰 기준을 다르게 잡습니다.
3단계 — 임베딩과 벡터 저장
쪼갠 조각을 임베딩 모델로 벡터화해 저장합니다. 한국어 문서라면 한국어 성능이 검증된 임베딩 모델을 쓰는 것이 검색 품질에 직접 영향을 줍니다.
문서가 갱신될 때 해당 조각만 다시 임베딩하는 구조를 처음부터 잡아두면, 나중에 전체 재구축을 반복하지 않아도 됩니다.
4단계 — 검색과 답변 생성
질문이 들어오면 유사도 상위 조각을 뽑아 프롬프트에 함께 넣습니다. 이때 검색된 근거 안에서만 답하도록 지시하고, 근거가 없으면 모른다고 답하게 만드는 것이 환각을 줄이는 핵심입니다.
답변에 출처 문서명과 조항 번호를 함께 표시하면 사용자가 스스로 검증할 수 있어 실무 신뢰도가 크게 올라갑니다.
5단계 — 평가 없이 배포하지 않기
가장 자주 생략되고, 가장 자주 문제가 되는 단계입니다. 실제로 들어올 법한 질문 30~50개를 정답과 함께 미리 만들어두고, 검색이 올바른 문서를 찾아오는지부터 확인합니다.
검색이 틀렸는데 답변이 그럴듯한 경우가 가장 위험합니다. 답변 품질보다 검색 정확도를 먼저 측정해야 원인을 특정할 수 있습니다.
- 실제 질문 30~50개로 평가셋 구성
- 검색 정확도 → 답변 정확도 순으로 측정
- 실패 사례를 모아 청킹 기준 재조정
자주 묻는 질문
사내 RAG 구축에 얼마나 걸리나요?
범위를 한 도메인으로 좁히면 문서 정리부터 평가까지 보통 수 주 규모입니다. 기간을 좌우하는 것은 기술이 아니라 문서 정리 상태입니다.
우리 문서가 외부로 유출되지 않나요?
문서 저장 위치와 모델 호출 경로를 분리해 설계하면 내부에 보관한 채 운영할 수 있습니다. 도입 전 데이터 처리 위치와 학습 사용 여부를 계약 단계에서 확인해야 합니다.
RAG를 도입하면 검색 담당 인력이 필요 없어지나요?
아닙니다. 문서 최신성 관리와 평가셋 갱신은 사람이 계속 맡아야 하는 영역입니다. 반복 질의 응대 부담이 줄어드는 것에 가깝습니다.