RAG는 저장소 하나가 아니라 원자료를 검색 가능한 단위로 만들고, 관련 근거를 골라 답과 인용으로 연결하는 전체 파이프라인입니다.
RAG라는 말은 흔히 벡터 검색과 같은 뜻으로 쓰이지만, 실제 시스템은 그보다 깁니다. 잘못된 문서가 들어오면 좋은 검색기도 틀린 근거를 찾고, 좋은 근거가 검색돼도 생성기가 무시할 수 있습니다. 각 단계를 분리해야 오류를 고칠 수 있습니다.
AI 핵심 지식 52편 중 25편입니다. 제품 화면이 바뀌어도 남는 원리와 판단 기준을 다룹니다.
RAG의 네 구간
| 구간 | 핵심 작업 | 실패 질문 |
|---|---|---|
| 지식 준비 | 수집·정제·청킹·메타데이터 | 정답 자료가 색인에 존재하는가 |
| 검색 | 질의 변환·후보 회수·재정렬 | 정답 구간이 상위 후보에 오는가 |
| 생성 | 문맥 조립·답변·인용 | 답이 제공된 근거에 충실한가 |
| 평가·운영 | 질문 세트·로그·갱신·권한 | 어느 단계가 실패했는가 |
RAG를 설계하는 순서
- 질문과 정답 근거가 연결된 대표 평가 세트를 만든다.
- 원자료의 권한·갱신일·문서 구조를 보존해 색인한다.
- 검색 회수율과 재정렬 품질을 생성과 분리해 측정한다.
- 답변 충실성·인용·거절과 갱신 운영을 끝단에서 검증한다.
RAG의 출발점은 벡터가 아니라 원자료다
검색 증강 생성은 모델의 매개변수 안에 있는 지식만 사용하지 않고 외부 문서를 찾아 문맥에 넣는 구조입니다. 이때 가장 먼저 확인할 것은 어떤 자료를 지식 원천으로 인정할지입니다. 중복 문서, 오래된 버전, 접근 권한이 다른 문서, OCR 오류가 있는 파일이 함께 들어가면 검색 결과가 처음부터 오염됩니다. 원자료를 수집할 때 제목, 섹션, 작성 주체, 갱신일, 문서 버전, 권한 같은 메타데이터를 보존해야 합니다. 정제 과정에서 표와 각주, 코드 블록을 무작정 제거하면 답에 필요한 관계가 사라질 수 있습니다. 문서를 작은 단위로 나누는 청킹도 원문의 논리 경계를 따라야 합니다. 색인된 문단이 어느 문서의 어느 위치에서 왔는지 되돌아갈 수 있어야 인용과 삭제, 갱신이 가능합니다. RAG를 만들기 전에 실제 사용자가 물을 질문과 정답 근거 구간을 모아 평가 세트를 만들면, 지식 준비 단계에서 이미 빠진 자료를 발견할 수 있습니다. 좋은 검색은 존재하지 않는 정답 문서를 만들어 내지 못하므로 원자료 품질과 범위가 첫 번째 설계 결정입니다.
검색은 후보 회수와 순위 결정을 나눠 본다
사용자 질문은 문서에 쓰인 표현과 다를 수 있습니다. 검색 단계에서는 질문을 그대로 쓰거나 필요한 용어로 확장하고, 키워드·벡터·하이브리드 방식으로 후보 문단을 넓게 회수합니다. 첫 단계의 목적은 정답 문서를 놓치지 않는 데 가깝습니다. 그다음 재정렬 단계는 회수한 후보를 질문과 더 정밀하게 비교해 상위 문맥을 고릅니다. 후보 수를 너무 적게 잡으면 정답이 빠지고, 너무 많이 넣으면 관련 없는 문장이 생성 문맥을 차지합니다. 검색 점수는 서로 다른 모델과 색인에서 같은 의미를 갖지 않으므로 고정 임계값을 맹목적으로 복사하면 안 됩니다. 질문 유형별로 정답 구간이 상위 몇 개 안에 들어오는지, 중복 후보가 얼마나 많은지, 권한 없는 문서가 섞이지 않는지 측정합니다. 특정 질의에 결과가 없을 때는 생성기로 넘기기 전에 검색 실패를 표시할 수 있어야 합니다. 검색 품질을 답변 문체로 평가하지 않고 정답 근거의 회수와 순위라는 독립 문제로 보는 것이 핵심입니다.
생성은 검색된 근거를 사용하는 별도 단계다
상위 문단을 찾았다고 좋은 답이 자동으로 나오지는 않습니다. 생성기에 전달할 때 문서 제목과 출처, 구간 경계를 유지하고, 질문과 직접 관련된 부분을 과도한 주변 문맥과 구분해야 합니다. 서로 충돌하는 자료가 있으면 최신 문서 하나를 몰래 선택하기보다 충돌 사실과 확인일을 전달합니다. 답변 지시는 제공된 근거 안에서 사실 주장을 만들고, 근거가 없으면 부족함을 표시하도록 설계합니다. 그러나 지시만으로 충실성이 보장되지는 않으므로 생성 결과를 주장 단위로 원문과 대조해야 합니다. 인용 번호가 올바른 문단을 가리키는지, 그 문단이 실제 결론을 지지하는지 확인합니다. 문맥에 정답이 있는데도 답이 틀리면 검색이 아니라 문맥 구성이나 생성 단계의 문제입니다. 반대로 답이 우연히 맞아도 정답 문서가 검색되지 않았다면 시스템은 재현 가능한 근거를 제공하지 못합니다. 검색 성공과 생성 충실성을 분리해야 어느 구성 요소를 개선할지 알 수 있습니다.
운영 단계가 파이프라인을 살아 있게 만든다
RAG는 한 번 색인을 만들고 끝나는 정적 기능이 아닙니다. 원문이 바뀌거나 삭제되고 권한이 변경되면 색인과 캐시, 인용 대상도 함께 갱신되어야 합니다. 문서별 갱신 시각과 색인 버전을 기록하고 오래된 조각을 제거할 절차가 필요합니다. 사용자 질문과 검색 결과, 답변의 실패를 개인정보와 보안 범위 안에서 분석해 평가 세트를 보강합니다. 전체 만족도만 보지 말고 자료 누락, 검색 누락, 재정렬 오류, 문맥 과밀, 근거 밖 생성, 잘못된 인용을 각각 집계합니다. 접근 권한은 검색 이전과 결과 반환 시점 모두에서 확인해야 하며, 모델이 권한 없는 문서의 내용을 요약해 누출하지 않도록 합니다. 지연과 비용도 단계별로 측정해야 병목을 찾을 수 있습니다. 변경 전후에는 같은 질문 세트로 회귀 평가를 수행하고 새 문서가 기존 질문을 망치지 않는지 봅니다. 운영 가능한 RAG는 답을 잘 쓰는 데서 끝나지 않고, 자료의 생애주기와 실패의 책임 위치를 계속 추적할 수 있는 시스템입니다.
판단 체크리스트
- 대표 질문마다 정답 근거 구간을 연결한 평가 세트가 있는가
- 원문 위치·버전·권한·갱신일이 청크에 보존되는가
- 검색 회수와 생성 충실성을 별도 지표로 측정하는가
- 삭제·갱신·권한 변경과 회귀 평가 절차가 있는가
자주 생기는 오해
- 벡터 데이터베이스를 연결하면 RAG가 완성된다 — 원자료 준비부터 검색·생성·인용·갱신·평가까지 전체 경로가 필요합니다.
- 최신 문서를 많이 넣을수록 답이 좋아진다 — 관련 없는 문맥과 충돌 문서는 생성 품질을 낮출 수 있어 질문별 회수와 선택을 평가해야 합니다.
단계별 실패를 구분하는 표
| 상황 | 해석 | 다음 행동 |
|---|---|---|
| 정답 문서가 색인에 없다 | 지식 준비 실패 | 수집 범위·갱신·권한·정제를 점검한다 |
| 정답은 색인에 있으나 상위에 없다 | 검색·재정렬 실패 | 질의와 검색 방식, 후보 수를 평가한다 |
| 정답 문단이 있는데 답이 벗어난다 | 문맥 구성·생성 실패 | 근거 지시와 주장 충실성을 검증한다 |
자주 묻는 질문
모든 문서를 임베딩하면 되나요?
아닙니다. 자료의 신뢰도·권한·갱신·구조를 먼저 정리하고 검색할 가치가 있는 범위를 정해야 합니다.
검색 결과는 몇 개를 넣어야 하나요?
고정 답은 없습니다. 정답 회수와 문맥 잡음의 균형을 질문 유형별 평가 세트로 결정합니다.
RAG는 모델의 오래된 지식을 완전히 대체하나요?
외부 근거를 제공하지만 생성 모델은 여전히 자체 패턴을 사용할 수 있어 근거 범위와 충실성 검증이 필요합니다.
인용이 있으면 RAG가 성공한 건가요?
인용 대상이 실제로 존재하고 답의 각 주장을 지지해야 합니다. 형식적 인용만으로는 충분하지 않습니다.
관련 좌표
작성·검증 정보
- 작성·검토: AI좌표 편집부
- 원문 확인일: 2026-07-27
- 다음 재검토일: 2027-07-27
- 재검토 조건: 원 논문의 정정·철회, 표준 정의 변경, 장기 평가에서 핵심 반례가 확인될 때