#RAG를 어떻게 하냐고 물으면 벡터 DB만 답하지 마라 — 5환 클로즈드 루프

← 전체 목차 · 다음: 장문서 청킹 — 왜 일률적으로 자르면 안 되나

"벡터 데이터베이스를 썼다"만 답하면 데모를 만들어 봤다는 증명밖에 되지 않는다. 프로덕션급 RAG의 난점은 "텍스트 한 단락을 리콜할 수 있는가"가 아니라, 그 텍스트가 어디서 왔고, 정확한가, 권한이 있는가, 답을 뒷받침할 수 있는가, 이후 어떻게 이터레이션하는가에 있다.

프로덕션급 RAG는 단일 능력이 아니라 엔드투엔드 클로즈드 루프이며 다섯 개의 고리로 이루어진다.

데이터 거버넌스  →  검색 품질  →  생성 제약  →  평가 체계  →  프로덕션 피드백
                                                                  │
                    └──────────────── 클로즈드 루프 환류 ──────────┘

모델 효과가 아무리 좋아도 루프가 끊기면 RAG는 실사용자에게 안정적으로 서비스하기 어렵다.

#1환: 데이터 거버넌스

더러운 데이터의 함정 4종

인덱스 진입 전 처리 동작: ①세정 ②중복 제거 ③버전 관리 ④권한 라벨 부여 ⑤메타데이터 보충.

반드시 보존해야 할 메타데이터 필드

한 줄 정리: 데이터가 깨끗하지 않으면 검색이 빠를수록 오류가 빨리 퍼진다.

#2환: 검색 품질

"정확 정보 조회"에 속하는 네 종류: 주문 번호, 오류 코드, 설정 항목, 계약 조항.

키워드 검색  ┐
             ├─► 혼합 리콜 ─► Rerank ─► 질문에 가장 잘 답할 증거를 앞으로
벡터 검색    ┘

정밀 제어의 네 다이얼: TopK 제한(리콜 건수 통제) / 유사도 임계값(저점수 조각 필터) / 결과 중복 제거(같은 내용의 자리 차지 방지) / 컨텍스트 압축(무효 Token 감소).

품질 > 수량 — 조각을 잔뜩 리콜해서 모델이 많이 보는 것 ≠ 정확히 답하는 것.

#3환: 생성 제약

증거를 검색했다고 절반만 끝난 것이며, 모델에는 여전히 세 가지 실패 모드가 있다.

1. 증거 오독
2. 외부 상식을 섞어 넣음
3. 증거 속의 제약 조건을 무시

생성 경계 4대 하드 제약

이 층이 결정하는 것은 답을 신뢰할 수 있는가이다.

#4환: 평가 체계

최종 답이 맞았는지만 보면 안 되고 링크를 쪼개 구간별로 봐야 한다.

목적: 답이 틀렸을 때 시스템이 지식베이스 문제 / 검색 문제 / 정렬 문제 / 생성 문제 중 어디인지 특정할 수 있어야 한다. 프로덕션 RAG는 반드시 진단 가능해야 한다.

#5환: 프로덕션 피드백

이 정보들은 모두 Badcase 라이브러리와 회귀 테스트셋에 들어가 시스템 이터레이션을 지속적으로 밀어야 한다.

#답변 템플릿

저는 RAG를 벡터 데이터베이스로 단순화하지 않습니다.

• 데이터 거버넌스: 세정, 중복 제거, 버전, 권한, 메타데이터
• 검색 층: 혼합 리콜 + Rerank로 증거 품질 향상
• 생성 층: 증거 제약, 인용, 거부 응답
• 평가 층: 리콜, 재정렬, 충실성, 인용 정확률을 쪼개서 봄
• 프로덕션: 사용자 피드백과 Badcase로 지속 최적화

#핵심 통찰

1. RAG의 실패는 대부분 검색 이후가 아니라 검색 이전에 발생한다 — 버전 충돌, 권한 결손, 중복 청킹은 인덱스 적재 단계에서 이미 결정된 것이며, 어떤 검색이나 프롬프트 최적화로도 되돌릴 수 없다. **"데이터가 깨끗하지 않으면 검색이 빠를수록 오류가 빨리 퍼진다"**가 가장 날카로운 한 줄이다.
2. 메타데이터는 선택적 장식이 아니라 진단 가능성의 전제다 — 문서 ID / 장·절 경로 / 페이지 / 갱신 시각 / 발효 상태 / 업무 부서 여섯 필드가 각각 소급, 인용 위치 특정, 시효 판단, 권한 필터링을 떠받친다. 한 필드가 빠지면 특정할 수 있는 장애가 한 종류 줄어든다.
3. 벡터 검색과 키워드 검색은 능력이 상호 보완적이지 신구 대체 관계가 아니다 — 벡터의 강점은 의미 유사도지만 주문 번호, 오류 코드, 설정 항목, 계약 조항 같은 정확 정보는 반드시 키워드에 기대야 한다. RAG를 벡터 DB와 동일시하는 것은 조회 유형의 절반을 능동적으로 포기하는 것이다.
4. 리콜의 목적 함수는 "품질"이지 "수량"이 아니다 — TopK 제한, 유사도 임계값, 결과 중복 제거, 컨텍스트 압축 네 다이얼이 전부 뺄셈이다. "모델이 많이 보는 것 ≠ 정확히 답하는 것" 뒤에는 컨텍스트 노이즈의 희석 효과가 있다.
5. 생성 제약의 본질은 "매끄러움"을 부차적 목표로 강등시키는 것이다 — 네 하드 제약(증거에서만 / 출처 인용 / 부족하면 불확실 / 지어내기 거부)이 전부 모델의 "말을 둥글게 만들려고 지어내는" 기본 성향에 맞선다. 여기서 신뢰도와 매끄러움은 대립한다.
6. 엔드투엔드 지표는 장애를 가리고, 구간별 지표라야 장애를 특정한다 — "답이 맞았는가"만 보면 네 종류 문제(지식베이스/검색/정렬/생성)가 하나의 이진 신호로 뭉개진다. 리콜·재정렬·충실성·인용 정확률 네 구간 지표로 쪼개야 진단 가능성을 논할 수 있다.
7. 프로덕션 행동이 가장 저렴하고 가장 진실한 평가 데이터 소스다 — 추가 질문률, 비추천률, 사람의 재작성 빈도 세 신호는 추가 라벨링 비용이 들지 않으면서 서로 다른 수리 동작으로 자동 분류된다.
8. 클로즈드 루프의 가치는 "환류"에 있지 "고리가 다 있음"에 있지 않다 — 5환이 루프인 이유는 5환이 프로덕션 신호를 Badcase 라이브러리와 회귀 테스트셋에 되돌려 쓰기 때문이다. 이 환류 간선이 없으면 앞의 4환은 정적인 파이프라인일 뿐이다.

#엔지니어링 실전 Tips

• 버전 관리에는 "내리기" 동작이 있어야 하며 "추가"만으로는 부족하다: 구 정책이 여전히 인덱스에 남아 있는 것이 가장 전형적인 더러운 데이터 함정이며, 신구 두 버전이 함께 리콜되면 모델은 대개 어느 것이 최신인지 판별하지 못한다.
• 권한 라벨은 생성 층 필터가 아니라 인덱스 층에서 발효되어야 한다: 먼저 리콜하고 나서 권한으로 거르면 민감 내용이 이미 모델 컨텍스트를 거친 것이고 TopK 자리까지 차지한다.
• 청킹 전에 중복 내용 탐지를 할 것: 중복 내용이 대량의 Chunk로 쪼개지면 리콜(자리 차지)과 Rerank(점수 집중)를 동시에 오염시킨다.
• 정확 정보 조회는 키워드 경로로 갈 것: 주문 번호, 오류 코드 같은 문자열은 벡터 공간에서 변별력이 거의 없어 embedding 리콜은 운에 맡기는 것이다.
• 유사도 임계값과 TopK는 함께 써야 한다: TopK만 설정하면 저품질 상황에서 억지로 K건을 채우고, 임계값만 설정하면 고품질 상황에서 누락 리콜이 발생한다.
• 인용은 장·절 경로 + 페이지까지 정확히: 신뢰도의 원천이자 "인용 정확률" 지표를 자동 평가할 수 있는 전제다.
• Badcase 적재 시 귀인 라벨(지식베이스/검색/정렬/생성)을 함께 달 것: 그렇지 않으면 회귀 테스트셋은 "전체적으로 나빠지지 않았음"만 검증할 뿐 "어느 고리가 고쳐졌는지"는 검증할 수 없다.
• 회귀 테스트셋은 지식베이스 버전과 함께 진화해야 한다: 지식베이스가 갱신되면 일부 과거 Badcase의 기대 답변 자체가 바뀐다.