RAG — 세 부품 중 어디가 고장 났는지 먼저 가른다

한 줄 요약

RAG 는 검색기, 재순위기, 생성기 세 부품의 조합이며, "답변 품질이 나쁘다"는 신고를 받으면 가장 먼저 할 일은 어느 부품에서 실패했는지 가르는 것이다.

왜 이게 필요했나

모델은 학습 시점의 지식만 갖고 있고, 사내 문서나 최신 정보는 알지 못한다. 미세 조정으로 지식을 넣는 방법도 있지만 비싸고 느리고 갱신이 어렵다.

RAG 의 아이디어는 단순하다. 질문이 오면 관련 문서를 먼저 찾아서 프롬프트에 넣고, 그 문서를 근거로 답하게 한다. 지식이 바뀌면 문서만 갈아 끼우면 된다.

어떻게 동작하나

파이프라인은 세 부품으로 나뉜다.

검색기(Retriever). 질의를 벡터로 바꿔 유사한 청크를 가져온다. 밀집 검색(임베딩)과 희소 검색(BM25 같은 키워드 방식)이 있고, 둘을 합친 하이브리드가 실무 표준이다. 서로 다른 종류의 실패를 하기 때문이다. 임베딩은 의역에 강하지만 제품 코드 같은 정확 일치에 약하고, 키워드는 그 반대다.

재순위기(Reranker). 검색기가 넓게 가져온 후보를 정밀하게 다시 줄 세운다. 질의와 문서를 함께 넣어 점수를 매기는 방식이라 정확하지만 느리므로, 상위 수십 건에만 적용한다.

생성기(Generator). 가져온 컨텍스트를 근거로 답을 만든다.

품질 문제를 진단할 때는 검색과 생성을 반드시 분리해서 봐야 한다.

• 정답 문서가 애초에 검색되지 않았다면 생성기를 아무리 손봐도 소용없다. 검색 지표(Recall@K, MRR)를 봐야 한다.
• 정답 문서가 컨텍스트에 있는데도 틀린 답이 나왔다면 그때가 생성기 문제다. 충실도(faithfulness)를 봐야 한다.

이 구분 없이 프롬프트만 고치는 것이 RAG 개선에서 가장 흔한 시간 낭비다.

주요 지표를 정리하면 이렇다.

| 지표 | 무엇을 재는가 |
| --- | --- |
| Recall@K | 상위 K 개 안에 정답 문서가 들어왔는가 |
| MRR | 정답이 몇 위에 나왔는가 (역수의 평균) |
| Precision@K | 상위 K 개 중 관련 있는 문서의 비율 |
| Faithfulness | 답변이 컨텍스트에 근거하는가 |
| Answer Relevancy | 답변이 질문에 맞는가 |

현장에서 만나는 모습

모른다고 답하게 만드는 것이 의외로 중요하다. 검색 점수가 임계값 미만이면 답하지 않고 그렇게 말하는 편이, 관련 없는 문서를 근거로 그럴듯한 답을 지어내는 것보다 훨씬 낫다. 임계값은 평가 집합으로 정해야 하며, 너무 높으면 답할 수 있는 질문도 거절하고 너무 낮으면 환각이 는다.

그리고 답변에 출처를 붙이는 것은 기능이 아니라 안전장치다. 사용자가 원본을 확인할 수 있으면 잘못된 답의 피해가 줄고, 어떤 청크가 잘못 검색되는지 운영 중에 관찰할 수 있다.

이어서 읽을 것

문서를 청크로 나누고 TF-IDF 로 색인해 8개 질의를 검색한다. 정답 문서 목록과 비교해 Recall@3 과 MRR 을 계산하고, 컨텍스트를 조립하고, 답변이 컨텍스트에 근거하는지 어휘 겹침으로 판정하고, 코퍼스 밖 질문에는 답하지 않는 임계값 규칙을 구현한다.