Raptor가 현실에서 잘 작동하지 않는 이유
최근 RAG(검색 증강 생성) 기술이 각광받으면서 다양한 최적화 기법들이 등장하고 있습니다. 그중 하나인 랩터(Raptor)는 계층적 클러스터링을 통해 검색 품질을 높인다고 알려져 있죠. 하지만 많은 개발자들이 랩터를 실제 프로젝트에 적용한 뒤 기대만큼의 효과를 보지 못하는 경우가 많습니다.
왜 그럴까요? 논문에서는 성공적이라고 말하는 랩터가 현실에서는 잘 작동하지 않는 이유를 심층적으로 분석해보고자 합니다.
📝 랩터(Raptor)의 기본 원리
랩터는 계층적인 구조를 통해 문서 검색의 효율을 높이는 기술입니다. 기본 흐름은 다음과 같습니다.
- 청크 분할 및 임베딩: 문서를 작은 청크(Chunk)로 나눈 후, 각 청크의 임베딩(Embedding)을 생성합니다.
- 차원 축소 및 클러스터링: 생성된 고차원 임베딩을 UMAP과 같은 알고리즘으로 저차원으로 축소합니다.
- 요약 및 상위 임베딩 생성: 저차원 임베딩을 기준으로 클러스터(군집)를 만듭니다. 클러스터에 속한 청크들을 모아 LLM(거대 언어 모델)으로 요약하고, 이 요약문에 대한 임베딩을 생성합니다. 이 과정을 반복하여 계층적 구조를 만듭니다.
- 검색: 사용자의 질의가 추상적이면 상위 요약 임베딩을, 구체적이면 하위 청크 임베딩을 검색하여 답변을 생성합니다.
논문만 보면 굉장히 그럴듯한 방법으로 보입니다. 하지만 이 과정에서 치명적인 문제들이 발생합니다.
🚨 랩터가 현실에서 실패하는 3가지 이유
1. 치명적인 '컨텍스트' 문제
랩터는 시맨틱(의미론적) 유사도가 높은 청크들을 모아 클러스터링합니다. 하지만 시맨틱만으로는 문맥(Context)을 완벽하게 파악할 수 없습니다.
- 컨텍스트가 상이한 문서의 결합: 예를 들어, '한국사'와 '일본사'에 대한 내용이 섞여 있는 문서가 있다고 가정해 봅시다. '임금이 죽었다'와 '천황이 죽었다'라는 두 청크는 시맨틱적으로 유사하기 때문에 클러스터링될 가능성이 높습니다. 그러나 두 문장은 완전히 다른 컨텍스트(국가)를 다루고 있으므로 함께 묶이면 안 됩니다. 랩터는 이런 미묘한 문맥 차이를 구분하지 못하고, 잘못된 클러스터링 결과를 만들 수 있습니다.
- 유사 시맨틱의 반복: 뉴스 기사처럼 정형화된 포맷의 문서는 명사만 바뀌고 문장 구조는 동일한 경우가 많습니다. 이 경우 시맨틱 임베딩 값이 매우 유사하게 나와 하나의 클러스터로 묶이지만, 실제로는 아무런 의미 없는 정보들의 집합이 될 수 있습니다.
이러한 문제들을 피하려면 클러스터링 전에 수동으로 컨텍스트를 분리하는 작업이 필요하지만, 이는 비현실적입니다.
2. 임베딩과 클러스터링의 '수학적' 불일치
가장 핵심적인 문제입니다. 임베딩 모델의 작동 방식과 랩터의 클러스터링 방식이 근본적으로 충돌합니다.
- 임베딩은 코사인 유사도에 최적화: 임베딩 모델은 학습 시 손실 함수(Loss Function)로 코사인 유사도를 사용합니다. 즉, 처음부터 코사인 유사도 값이 높게 나오도록 학습이 이루어진 것이죠. 따라서 우리는 두 임베딩 벡터의 유사도를 평가할 때 반드시 코사인 유사도를 사용해야만 합니다.
- 랩터의 잘못된 클러스터링: 그런데 랩터는 임베딩을 저차원으로 축소하는 과정에서 UMAP을 사용합니다. UMAP은 코사인 유사도를 버리고 유클리드 거리(Euclidean distance)를 기반으로 위상적 관계만 보존합니다. 이후 클러스터링을 위해 K-평균(K-means)과 같은 유클리드 거리 기반 알고리즘을 사용합니다.
결과적으로, 코사인 유사도에 최적화된 임베딩을 유클리드 거리에 기반한 클러스터링에 사용하는 비극이 발생합니다. 고차원에서는 두 거리가 비슷한 결과를 내는 경우가 있지만, UMAP으로 차원을 축소하면 이 관계가 깨져버리기 때문에 클러스터링 결과가 원래의 의미와 전혀 상관없게 되는 것이죠.
3. 데이터 추가의 비효율성
랩터가 사용하는 UMAP은 정해진 데이터 집합에 대해서만 차원 축소를 수행할 수 있습니다. 즉, 새로운 문서를 추가할 때마다 UMAP 차원 축소와 클러스터링을 처음부터 다시 해야 합니다.
- 데이터가 동적으로 계속 추가되는 실제 서비스 환경에서는 이 과정이 엄청난 비용과 시간을 요구하게 됩니다.
- 결국 랩터는 한정된 정적 데이터셋을 사용하는 논문에서는 잘 작동할 수 있지만, 지속적으로 데이터가 업데이트되는 현실 서비스에는 맞지 않는 구조입니다.
📝 랩터는 언제 쓸모 있을까?
랩터는 데이터의 컨텍스트가 매우 명확하고, 정적이며, 클러스터링 결과가 의미 있을 만큼 잘 정돈된 '특수한 데이터셋'에서만 효과를 발휘합니다. 논문 속 데이터셋이 바로 그러한 경우죠.
하지만 대부분의 현실 데이터는 컨텍스트가 복잡하고, 구조화되지 않았으며, 지속적으로 업데이트됩니다. 이 때문에 많은 기업에서 랩터 대신 다중 벡터 스토어(Multi-Vector Store)나 셀프 쿼리(Self-Query) 같은 다른 RAG 최적화 기법을 선호하는 것입니다.
RAG 기술을 도입할 때는 무조건 최신 기술을 쫓기보다는, 프로젝트의 데이터 특성과 요구 사항을 고려하여 가장 적합한 방법을 선택하는 지혜가 필요합니다. 랩터의 한계를 명확히 인지하고, 더 나은 RAG 시스템을 구축하는 데 이 글이 도움이 되기를 바랍니다.
