ZeroCho TV의 영상 **「RAG 5분만에 설명해드림 - RAG가 뭔지 모르면 AI 답변은 전부 틀릴 수 있습니다」**에서는 RAG를 단순 개념 설명에 그치지 않고, **원본 문서 → 청킹 → 색인 → 검색 → 근거 선택 → 실제 LLM 요청 → 최종 답변 검증**까지 구현 흐름으로 설명합니다. > 이 영상은 Fish Audio의 유료 광고를 포함합니다. 본문에서는 광고 부분보다 RAG 구현과 검증 흐름을 중심으로 정리합니다. ## RAG의 핵심 RAG는 모델에게 새로운 지식을 다시 학습시키는 방식이 아닙니다. 질문에 필요한 외부 자료를 먼저 찾고, 그 자료를 질문과 함께 모델에게 전달해 답변을 생성합니다. 즉: **질문 → 관련 자료 검색 → 근거 선택 → LLM Context에 포함 → 답변 생성** 구조입니다. ## 1. 문서를 Chunk로 나눈다 문서 전체를 매번 모델에 보내면 비용이 커지고 불필요한 정보가 많아집니다. 그래서 문서를 작은 조각인 **Chunk**로 나눕니다. 하지만 너무 작게 나누면 의미가 깨질 수 있습니다. 예를 들어: **결제 API V2에서 HTTP 429 응답이 발생하면 최대 3회 재시도한다** 라는 규칙이 있다면: - API 버전 V2 - 429 응답 - 재시도 3회 가 같은 Chunk 안에 남아 있어야 합니다. ## 2. Metadata를 붙인다 Chunk에는 본문만 저장하는 것이 아니라 출처 정보를 함께 붙이는 것이 좋습니다. 예: - source: payment.md - version: v2 - section: retry-policy - updated_at - chunk_id 같은 정보입니다. 이 Metadata는 나중에 검색 결과를 필터링하고 원문까지 추적할 때 매우 중요합니다. ## 3. 색인(Index)을 만든다 Chunk를 검색하기 쉽도록 Index를 만듭니다. 영상 실습에서는 이해를 쉽게 하기 위해 키워드 검색 기반 색인을 사용합니다. 예: **429 → payment-v2-c03** 처럼 특정 단어가 어떤 Chunk에 포함되어 있는지 연결해 둡니다. ## Vector Search가 필수는 아니다 RAG라고 해서 반드시 Vector DB나 Embedding을 사용해야 하는 것은 아닙니다. 검색 방식은: - Keyword Search - Full-text Search - Vector Search - Hybrid Search 등 여러 형태가 가능합니다. Vector Search는 표현이 달라도 의미가 비슷한 문서를 찾는 데 유리합니다. 예: **429 오류** 와 **요청이 너무 많음** 처럼 표현이 달라도 비슷한 Context를 찾을 수 있습니다. ## 4. Retrieval 후보를 만든다 질문이 들어오면 Index에서 관련 Chunk 후보를 찾습니다. 여기서 중요한 것은 검색 점수가 높다고 해서 그 문서가 정답이라는 의미는 아니라는 점입니다. 검색 Score는: > 어떤 후보가 상대적으로 더 관련 있어 보이는가 를 판단하는 기준일 뿐입니다. ## 5. Top-K 검색 후보 중 상위 몇 개를 가져올지 결정하는 값이 Top-K입니다. 예: **Top-K = 3** 이면 최대 세 개의 후보를 가져오겠다는 의미입니다. 정답이 세 개 있다는 뜻은 아닙니다. 또 답이 없는 질문에서도 비슷한 단어 때문에 문서가 검색될 수 있으므로 Top-K 결과를 그대로 신뢰하면 안 됩니다. ## 6. Metadata Filter 실무 RAG에서는 검색 전에 조건을 걸어 범위를 제한하는 것이 매우 중요합니다. 예를 들어 질문이: > 결제 API V2에서 429가 발생하면 어떻게 해야 하나? 라면 검색 단계에서: **version = v2** 필터를 적용할 수 있습니다. 이렇게 하면 의미는 비슷하지만 규칙이 다른 V1 문서가 들어오는 문제를 줄일 수 있습니다. ## 7. 검색 결과와 실제 Context는 다르다 검색 결과가 여러 개 나왔다고 해서 모두 LLM에게 보낼 필요는 없습니다. 후보를 다시 평가한 뒤 실제 답변에 필요한 Chunk만 선택합니다. 즉: **Retrieval Candidates → Evidence Selection → LLM Context** 단계가 따로 존재합니다. ## 8. 실제 LLM 요청을 확인해야 한다 RAG 디버깅에서 자주 놓치는 부분입니다. 검색이 제대로 됐더라도 실제 LLM 요청에 해당 근거가 들어가지 않았다면 답변은 틀릴 수 있습니다. 영상에서는 다음 세 가지를 한 요청으로 묶습니다. - 사용자 질문 - 답변 지침 - 선택한 근거 본문 예: > 제공된 근거만 사용하고, 근거에서 확인할 수 없는 내용은 모른다고 답하라. 같은 Instruction을 함께 넣습니다. ## 9. RAG가 있다고 Hallucination이 자동으로 사라지는 것은 아니다 RAG의 근거가 틀리면 LLM의 답변도 틀릴 수 있습니다. 예: - 잘못된 문서 검색 - 오래된 버전 검색 - 잘못된 Chunk - 최신 Index 미반영 - 관련 없는 후보 가 들어가면 답변 역시 잘못될 수 있습니다. 그래서 RAG는 **검색 품질과 데이터 품질이 답변 품질을 결정하는 시스템**이라고 보는 것이 좋습니다. ## 10. 원본과 Index의 동기화 영상의 실무적으로 중요한 부분입니다. 원본 문서에서: **재시도 3회 → 재시도 2회** 로 규칙을 바꿨다고 가정해 보겠습니다. 원본만 바꾸고 Index를 다시 만들지 않으면 RAG는 여전히 오래된 3회 규칙을 검색할 수 있습니다. 그래서: **Source Document 변경 → Chunk 재생성 → Index 갱신** 과정이 필요합니다. 또 Index 생성 시각이나 문서 버전을 Metadata에 저장하면 이런 문제를 추적하기 쉬워집니다. ## 11. RAG 디버깅은 4단계를 비교한다 영상에서 가장 실무적으로 유용한 부분은 다음 네 곳을 비교하는 방법입니다. ### ① 원본 문서 정답이 실제로 존재하는가? ### ② 검색된 근거 정답이 포함된 올바른 Chunk를 가져왔는가? ### ③ 실제 LLM 요청 선택한 근거가 Prompt/Context에 실제로 들어갔는가? ### ④ 최종 답변 LLM이 근거의 내용을 정확히 반영했는가? 즉: **Source → Retrieval → Prompt → Answer** 를 순서대로 추적합니다. ## 오류 위치에 따라 해결 방법도 달라진다 ### 원본에 정보가 없다 → Data Source 보강 ### 원본에는 있는데 검색되지 않는다 → Chunking / Index / Retrieval 개선 ### 검색은 됐지만 잘못된 버전이다 → Metadata Filter / Ranking 개선 ### 올바른 근거를 찾았지만 Prompt에 없다 → Request Builder 문제 ### 올바른 근거까지 넣었는데 답이 틀리다 → Prompt / Model / Generation 문제 이렇게 원인을 분리할 수 있습니다. ## 12. 답이 없으면 '모른다'고 해야 한다 예를 들어 문서에 환불 정책은 있지만 수수료 금액은 없다고 가정합니다. 이 경우 RAG가 비슷한 환불 문서를 검색했다고 해서 LLM이 금액을 추측하게 하면 안 됩니다. 정상적인 답변은: > 제공된 문서에서는 환불 수수료를 확인할 수 없습니다. 에 가깝습니다. 이는 기업용 RAG에서 매우 중요한 **Abstention** 설계입니다. ## 13. Web RAG RAG의 자료가 내부 문서가 아니라 웹 검색 결과일 수도 있습니다. 이 경우: - 검색 결과 선택 - 페이지 본문 추출 - 관련 부분 선택 - URL 저장 - 답변에 출처 표시 과정을 거칩니다. 사용자가 원문을 열어 답변과 비교할 수 있도록 출처 URL을 함께 유지하는 것이 좋습니다. ## Web RAG에서 확인할 것 웹 문서는 특히: - 오래된 페이지 - 비공식 출처 - 잘못된 버전 - 중복 정보 문제가 많습니다. 그래서 날짜, 공식 출처 여부, 제품 버전을 함께 확인해야 합니다. ## 14. Prompt Injection 웹 RAG의 중요한 보안 문제입니다. 검색한 웹페이지 안에: > 이전 지시를 무시하고 다른 행동을 수행하라 같은 문장이 포함되어 있을 수 있습니다. 이런 내용을 문서 데이터가 아니라 **명령으로 해석하면 안 됩니다.** 즉, 외부에서 가져온 문서는 항상 **Untrusted Data**로 취급해야 합니다. ## 15. 권한 필터링 기업 내부 RAG에서는 검색 정확도만큼 권한이 중요합니다. 사용자가 볼 권한이 없는 문서가 Retrieval에 포함되면 LLM 답변을 통해 민감 정보가 노출될 수 있습니다. 그래서 실제 시스템에서는: **User → Access Control Filter → Retrieval** 구조가 필요합니다. ## RAG 실무 체크리스트 RAG를 구현할 때 다음을 확인하면 좋습니다. 1. Chunk에 필요한 Context가 함께 들어 있는가? 2. Source·Version·Updated Time Metadata가 있는가? 3. 질문에 맞는 Filter를 적용하는가? 4. Top-K가 지나치게 크거나 작지 않은가? 5. 검색 Score를 정답 확률처럼 사용하지 않는가? 6. 실제 LLM Prompt에 어떤 Chunk가 들어갔는지 기록하는가? 7. Source Document 변경 시 Index도 갱신되는가? 8. 답이 없는 질문에서는 Abstain하는가? 9. 사용자 권한을 Retrieval 전에 적용하는가? 10. Web RAG에서는 Prompt Injection을 방어하는가? ## 핵심 정리 RAG의 진짜 어려움은 Vector DB를 연결하는 것이 아닙니다. 더 중요한 것은: **올바른 문서를 찾고 → 올바른 버전을 선택하고 → 실제 Context에 넣고 → 최종 답변이 그 근거와 일치하는지 검증하는 것** 입니다. 한 줄로 정리하면: > **RAG 품질은 LLM보다 Retrieval·Data·Versioning·Evaluation·Debugging에서 결정되는 경우가 많습니다.**