AI 연재 5/9 — RAG는 검색 문제다: 청킹, 하이브리드 검색, 리랭킹, 평가
RAG를 처음 접하면 "벡터DB에 문서 넣고 유사한 걸 가져와 프롬프트에 붙이는 것"으로 이해하기 쉽다. 틀린 설명은 아니다. 다만 실제로 품질을 가르는 건 생성 모델이 아니라 무엇을 가져오느냐인 경우가 많다. 보상 서비스 예시로 치면 약관과 지급 기준 문서에서 맞는 조항을 못 찾으면 아무리 좋은 모델도 틀린 판단을 한다.
뿌리: 파라미터 밖의 기억
RAG라는 이름은 Lewis 등의 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"(NeurIPS 2020, arXiv 2005.11401)에서 왔다. 사전학습된 생성 모델(파라미터 메모리)에 위키피디아 밀집 벡터 인덱스와 신경 검색기(비파라미터 메모리)를 결합한 구조다. 논문은 두 가지 변형을 제시한다. 생성 전체에 같은 검색 결과를 쓰는 방식과, 토큰마다 다른 검색 결과를 쓰는 방식이다. 초록에서는 더 구체적이고 다양하고 사실적인 생성을 보였고 여러 개방형 QA에서 최고 성능을 냈다고 한다.
2020년 논문이라 지금 우리가 쓰는 RAG(외부 검색 결과를 프롬프트에 붙이는 방식)와 구조가 완전히 같지는 않다. 아이디어의 출처로 이해하자.
청킹과 맥락 잃기
문서를 일정 크기로 자르면 조각이 원래 문맥을 잃는다. "이 경우에는 지급하지 않는다"는 조각이 어떤 보장 항목의 예외인지는 앞 문단에 있다. 그 조각만 검색되면 의미를 알 수 없다.
Anthropic의 Contextual Retrieval(2024-09-19)이 이 문제를 직접 다룬다. 각 청크 앞에 Claude가 생성한 50~100토큰 길이의 맥락 설명을 붙인 뒤 임베딩하고 BM25 인덱스에도 반영한다. 글에서 보고한 상위 20개 청크 검색 실패율은 이렇다.
| 방식 | 실패율 | 기준 대비 감소 |
|---|---|---|
| 기준(일반 임베딩) | 5.7% | - |
| Contextual Embeddings | 3.7% | 35% |
| Contextual Embeddings + BM25 | 2.9% | 49% |
| 위에 리랭킹 추가 | 1.9% | 67% |
이 수치는 Anthropic이 자체 데이터셋에서 낸 결과다. 내 문서에서 같은 비율이 나온다는 뜻이 아니다. 우리 데이터로 직접 재 봐야 한다. 이 글은 프롬프트 캐싱을 쓰면 일회성 맥락 생성 비용이 문서 토큰 100만 개당 약 1.02달러 수준이라고도 한다. 가격은 시점에 따라 바뀌니 현재 요금은 확인이 필요하다.
하이브리드 검색: 벡터만으로는 놓친다
임베딩 검색은 의미가 비슷한 문장을 잘 찾지만 고유명사, 제품 코드, 조항 번호 같은 정확한 토큰 일치에는 약할 수 있다. 키워드 기반 BM25와 섞는 이유다. 이 부분은 일반적인 설명이고, 위 Contextual Retrieval 표에서 BM25를 추가했을 때 실패율이 더 내려간 것이 간접 증거다.
두 검색의 점수를 어떻게 합칠까? 스케일이 달라서 점수를 그대로 더하기 어렵다. 널리 쓰이는 방법이 RRF(Reciprocal Rank Fusion)다. Azure AI Search 문서(Microsoft Learn)에 따르면 각 검색의 순위 목록에서 1/(rank + k)를 합산하고, 문서는 k가 60 같은 작은 값에서 잘 동작한다고 설명한다. 순위만 쓰므로 점수 정규화가 필요 없다는 건 내가 이 설명에서 이끌어낸 해석이다. RRF의 원 논문(Cormack et al., 2009)은 PDF를 열지 못해서 확인하지 못했다.
그 위에 리랭커를 얹는다. 넓게 가져온 후보를 더 정교한 모델로 다시 점수 매겨 좁힌다. Contextual Retrieval에서는 상위 150개를 가져와 20개로 줄였고, 20개가 5개나 10개보다 나았다고 한다.
컨텍스트 조립: 중간에 둔 정보는 잊힌다
가져온 청크를 프롬프트에 어떻게 배치할까. Liu 등의 "Lost in the Middle"(2023, arXiv 2307.03172)은 관련 정보가 입력의 처음이나 끝에 있을 때 성능이 가장 좋고 중간에 있을 때 크게 떨어진다고 보고했다. 장문맥을 위해 설계된 모델에서도 같은 경향이 있었다.
주의가 필요하다. 이 결과는 2023년 모델에 대한 것이다. 최신 모델에서 같은 정도로 나타나는지는 이번에 확인하지 못했다. 그래도 설계 습관으로는 유효하다. 가장 중요한 청크를 앞이나 끝에 두고, 청크를 무작정 많이 넣지 않는다.
평가: 검색과 생성을 분리한다
RAG가 틀렸을 때 원인은 두 갈래다. 맞는 문서를 못 가져왔거나, 가져왔는데 모델이 잘못 썼거나. 둘을 섞어서 보면 어디를 고칠지 알 수 없다.
RAGAS 논문(Es 등, arXiv 2309.15217, 2023)은 정답 라벨 없이 RAG를 평가하는 프레임워크를 제안했고, 초록 기준으로 faithfulness, answer relevance, context relevance를 다룬다. 현행 Ragas 문서(docs.ragas.io)에서 확인한 지표 이름은 약간 다르다. Faithfulness, Context Precision, Context Recall, Response Relevancy, Context Entities Recall, Noise Sensitivity 같은 것이 보이고, 에이전트용 지표(Tool Call Accuracy, Agent Goal Accuracy 등)도 있다. 논문과 라이브러리의 지표 이름이 달라서 처음엔 혼동하기 쉽다. 라이브러리 버전 정보는 도구 요약이 모순돼 확인하지 못했다.
이름은 달라도 쓰임은 구분된다.
- Context Precision/Recall: 검색 쪽 진단. 필요한 걸 가져왔는가, 쓸데없는 걸 얼마나 가져왔는가
- Faithfulness: 생성 쪽 진단. 답이 가져온 문서에 근거하는가
2편에서 말한 평가셋 원칙은 여기서도 같다. 실제 질의에서 뽑은 작은 세트로 시작하고, 검색 결과의 정답 문서를 직접 라벨링해 두면 검색 단계만 따로 평가할 수 있다. 그리고 LLM 판정자를 쓰면 사람 라벨로 보정한다.
흔한 실패
출처가 있는 건 위에서 언급한 두 가지(맥락 상실, 중간 정보 무시)이고, 아래는 내 정리다.
- 임베딩만 쓰고 코드·ID·조항 번호 질의를 놓친다
- 리랭킹 없이 top-k만 늘린다. 노이즈가 늘어 오히려 나빠질 수 있다
- 생성 결과만 보고 검색 품질을 측정하지 않는다
- 문서가 업데이트되는데 인덱스 갱신 규칙이 없다
- 검색된 문서를 신뢰된 지시처럼 다룬다(문서 속 악성 지시. OWASP LLM08은 벡터·임베딩 약점을 별도 항목으로 둔다)
청크 크기에 정답은 없다
청크 크기와 겹침 비율은 문서 구조에 크게 의존하고, 이번에 확인한 어떤 출처도 "이 값이 좋다"고 말하지 않았다. 평가셋으로 직접 비교하는 수밖에 없다.
다음 편에서는 에이전트로 돌아간다. 도구, 상태, 중단과 재개, 그리고 보안이다.
연재 목차: 4편 · 5편(현재) · 6편 에이전트 심화
참고자료
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020)
- Anthropic, Introducing Contextual Retrieval (2024-09)
- Microsoft Learn, Relevance scoring in hybrid search using RRF
- Liu et al., Lost in the Middle (2023)
- Es et al., RAGAS (2023)