RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval

억지로 끼워 맞춘 줄임말이 아니라 조금 편한 상태로 시작할 수 있는 논문인 점이 마음에 든다.

랩터,라고 발음도 편하다.

 

가끔 중간에 낀 아무 알파벳을 대문자로 키우고 말도 안 되는 이름을 만든 경우를 보면 저게 뭐야 인상이 찌푸려지다가도 오죽하면 저런 결과물이 나왔을까, 이리 붙이고 저리 잘라도 그럴싸한 게 나오지 않아 결국 선택한 것이 저것일까 싶어 저자들이 안쓰러워지는 그런 이름이 아니라서 다행이다.

 

새로운 논문들이 끊임없이 쏟아지니 쓰는 사람은 이름짓느라 골머리가 아프고, 찾아보는 사람은 머릿속에서 휘발되는 이름들을 힘겹게 붙잡아보지만 같은 이름을 대여섯 번은 검색해서 겨우 찾는 웃픈 현상은 이 바닥에선 아주 흔하다.

아무리 구려도, 막 지어도 성능이 월등하면 다 알아서 잘 부르겠지만 챗GPT같은 걸 뚝딱 만들어낼 수 없는 것은 양측 모두 공감할 수 있으니 말이다.

 

rap·tor /ˈraptər/ 는 맹금류, 혹은 밸로키랍토르나 유타랍토르라는 공룡을 줄여 부르는 말이라고 한다.
F-22 랩터라는 전투기도 있다는데 2024년 5월 기사 기준 무려 현존 최강이란다.

 

여러모로 네이밍은 낫베드인 것 같은 논문을 살펴보자.

 

 

 

 

RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval

 

저자: Parth Sarthi, Salman Abdullah, Aditi Tuli, Shubh Khanna, Anna Goldie, Christopher D. Manning
Stanford University
published @ICLR 2024

 

 

 

이 논문은 RAG 개발 업무를 진행하고 있어 고도화를 위해 리서치하며 읽었던 논문 중 하나였다.

 

현재 RAG의 한계점으로 제기되는 '글을 전체적인 내용을 아우르는 질문에 답하기 어려움' 과 결이 비슷한 문제를 해결하기 위해 해당 논문을 보게 되었다.

 

문제를 좀 더 엄밀히 정의하자면 실제 비즈니스에서는 '이 길고 긴 글을 한 문장으로 요약하면 뭐라고 해야 할까?' 같은 국어문제 같은 문제보다 아래와 같은 이슈가 훨씬 빈번하게 일어난다.

 

 

보통은 짤막한 문단 단위로 정보가 나뉘는데,
가끔씩 몇 페이지에 걸친 긴 단위가 하나의 정보를 담고 있다.

모든 것을 긴 경우에 맞춰 큼직하게 분할하자니
일반적인 경우 필요없는 정보들이 너무 많이 포함된다.
이렇게 되면 답변 생성을 담당하는 LLM이 도리어 관련 없는 정보를 너무 많이 포함시킨
틀리거나 애매한 답변을 만들어내 문제가 될 수 있다.

반대로 짧게 쪼개자니 검색 결과가 저 긴 내용에 걸쳐있는 모든 청크들을 상위로 올려야만
완전한 답변을 할 수 있는 가능성이 있다.
만약 엄청난 검색 모델을 만들어 모두 검색이 된다고 해도,
상위 몇 개의 청크를 프롬프트에 들어가게 해야 하는가?

또, 두 경우 모두에서 애초에 긴 텍스트의 길이가 max length를 넘는다면
이건 또 어떻게 처리해야 하는가?



이런 이슈들은 사실 RAG의 모든 프로세스에 걸쳐있는 문제다. 문서를 이해하고 텍스트화하는 전처리 과정에서도 해결해야 할 과제가 있고, 어떤 구조로 벡터 DB에 적재할 것인지, 어떻게 검색할 것인지, 답변 생성 콘텍스트로 어떻게 집어넣을 것인지 모든 것들이 맞물려 있다.

 

그래서 자꾸 어느 곳에 집중해야할지 계속해서 갈팡질팡하게 되기도 했지만, 기술적으로 크게 구분할 수 있는 문서 전처리 - 적재 및 검색 (벡터 DB와 맞물려 돌아가기 때문에 크게는 하나로 구분) - 답변 생성 LLM으로 나누었을 때 나의 역할은 가운데에 해당하는 적재 및 검색에 집중하기로 했다.

 

그럼 이런 미션(?)을 가진 나의 관점에서 이 논문을 살펴보자.

 

 

Contributions

본 논문에서는 여러 scale의 콘텍스트를 검색하기 위해, 즉 위에서 말한 이슈들을 해결하기 위해 트리 형태의 문서 요약 방식을 사용했다. 문서를 적재할 때 비교적 작은 청크들로 처음 쪼갠 것을 시작으로 계속 클러스터링을 진행하며 그 청크의 요약문을 재귀적으로 적재하는 형태이다.

동일한 내용이 한 번만 적재되는 것이 아니기 때문에 이후 검색 방식에서도 차이를 줄 수 있어 논문에서는 두 방식을 소개한다. methodology가 크게 복잡한 것은 아니라서 간단히 살펴보며 실제 어플리케이션에 어떤 부분은 적용 가능하고, 어떤 부분은 개선 혹은 추가 개발 등이 필요한지 나름대로 정리한 내용을 소개하려 한다.

 

 

문서 전처리

먼저 텍스트 길이를 100마다 쪼개 청크를 만든다. 단, 여기서 문장이 도중에 끊기게 되는 경우에는 무조건 100으로 자르는 것이 아닌 이 문장 시작까지로 끊고 잘리는 문장은 다음 청크로 넘긴다고 한다. 여기서 드는 첫 번째 의문은 문장이 도중에 잘렸는지 어떻게 판단하고, 해당 문장의 시작 위치는 또 어떻게 찾는 것일까? 하는 것이다. 단순히 정규식을 적용하기에는 다양한 변수가 많을 텐데 현실적으로 가능한 방법일지 의문이 든다.

아무튼 이렇게 기본적으로 구성된 청크를 트리 구조에서 가장 leaf nodes로 두고 점차 여러 청크를 묶어 트리를 구성하는데, 이 논문에서는 클러스터링을 사용한다. 다른 논문들 중 대/중/소제목 등이 잘 구분된 문서 구조를 가정하고 이 구조 자체를 활용하는 경우가 있는데, 실무에서 이런 문서는 찾기 매우 어렵다. 어디서 어디까지가 같은 내용일지, 구분되는 시점은 또 어디일지를 알 수 없다고 가정하는 것이 현실적이다. 그런 점에서 클러스터링은 어느 정도 합리적인 선택으로 보인다.

 

클러스터링 알고리즘으로는 Gaussian Mixture Models(GMMs)를 사용하였다. 이 모델은 각각의 데이터가 가우시안 분포 여럿에서 생성되었다고 가정한다. 높은 차원 공간에서 유사도 계산이 어렵기 때문에 전통적인 GMMs은 dimension이 큰 벡트 임베딩 표현도 어렵다고 여겨졌는데, 논문에서는 nearest neighbors 개수(n_neighbors)로 local과 global 정보를 조절하는 Uniform Manifold Approximation and Projection (UMAP)이라는 차원 축소를 활용해 이를 해결하고자 했다. n_neighbors를 조절해 처음에는 global 클러스터를 찾은 뒤 해당 클러스터들 내의 local 클러스터를 찾도록 2스텝으로 구성해 텍스트의 넓은 주제부터 세부사항까지 다양한 관계를 파악할 수 있다고 주장한다.

 

이런 방식으로 클러스터링을 한 후 클러스터를 요약해야 하는데, 요약 모델의 인풋 토큰보다 작게 유지되도록 클러스터 내의 클러스터링을 반복한다. 적절한 클러스터 개수를 판단하기 위해 Bayesian Information Criterion (BIC)로 모델을 선택한다. BIC는 모델 복잡도에 페널티를, 적합도 검정(goodness of fit test)에 리워드를 주는 방식이다. GMMs가 sparse하고 skewed된 분포를 가진 텍스트 데이터와 가장 적합하지 않을지 몰라도 이 상황에서의 클러스터링에는 유의미한 결과를 보여줬다고 주장한다.

 

 

soft clustering을 사용했다는 것 또한 강조하는데, 한 청크가 여러 클러스터에 포함될 수 있도록 허용하는 것으로 한 청크에 존재하는 여러 관점의 내용이 여러 클러스터에 녹아들 수 있기 때문이라고 설명한다. 요약을 진행하면 아무래도 클러스터 내의 공통적인 내용이 주로 남게 될테니 손실되는 정보가 있고, 그 손실되는 정보가 다른 클러스터에서는 공통적인 내용일 수 있으니 유의할 것으로 예상된다.

 

요약은 요즘 유행인 LLM을 활용하고, 이 요약문을 해당 node의 텍스트로 여기고 임베딩 및 적재를 진행한다. 즉, 클러스터 개수만큼의 요약이 필요하다. 초기 데이터 처리 및 적재에 시간이 꽤나 소요될 것이고, 이후 문서가 꾸준히 업데이트 되는 상황에서 사용성이 있을지 테스트가 필요해 보인다.

 

 

 

검색

문서가 트리 형태로 적재되어있기 때문에 이 구조를 살려 검색할 수도 있을 텐데, 논문에서는 그러한 tree traversal 방법과 모두 flat하게 펼쳐놓고 검색하는 collapsed tree 방식 두 가지를 비교했다.

 

 

 

위 그림을 보면 긴 말 필요없이 금방 이해가 될 것이다.

tree traversal은 트리 구조의 꼭대기인 root부터 아래로 내려가며 각 layer마다 적절한 노드들을 검색하는 방식으로, layer가 정보의 깊이를 어느 정도 일관되게 보여준다고 했을 때, global한 정보와 local한 정보를 모두 골고루 탐색할 수 있는 방법일 것이다. 두 번째 collapsed tree 방식은 모든 layer를 동등하게 펼쳐놓고, 같은 레벨에서 비교하여 검색한다. 이 방식은 global과 local에 몇 개씩 검색하라는 특별한 제약을 둔 것이 아니라서 실제 검색 결과는 더 적합한 layer에 위치한 청크가 더 많이 뽑힐 것이다.

 

 

결과적으로, collapsed tree 방식이 성능이 더 좋았다고 하는데, 보통 유저의 질문 하나는 global-to-local을 모두 아우른 정보를 골고루 보고 답을 해야하는 것이 아닌 특정한 hierarchy에 해당하는 질문(전체적인 주제가 뭐야, 혹은 매우 구체적인 이러이러한 걸 어떻게 해? 등)을 하기 때문으로 예상한다.

 

 

 

실제 구현 시 어려운 점들

논문에 구현 코드 링크가 첨부되어 있는데, 데모용에 그치는 것으로 보여 실제로 구현하고 서빙하려면 고민하고 개발해야할 것들이 많아 보인다. 특히 문서 관리 부분이 그러한데, 트리 구조를 관리하는 시스템과 디비가 없어 문서가 수정되면 해당 문서 텍스트가 관련된 클러스터 모두 영향을 받는데, 이에 대응하기가 쉽지 않다. 우선 모든 클러스터에 포함된 청크 정보를 관리하는 것이 필요하다. 가장 아래단의 leaf node들에 대해서는 어떤 문서의 어느 내용인지 모두 관리가 필요하다. 그 후, 클러스터에 묶인 노드들을 매핑하여 트리 구조를 관리하는 DB가 필요할 것이다.

 

그 후, 문서 C(R)UD 중 그나마 간단할 수 있는 삭제의 경우를 먼저 보자. 최대한 간단하게 하려면 삭제해야 하는 문서의 청크들이 포함된 클러스터의 요약문만 새로 작성할 수 있을 것이다. 전체적으로 봤을 때 일부 청크의 삭제가 클러스터링 구조 자체를 바꿀 수 있지만, 그래도 삭제된 문서 내용만 지우는 것이 아주 비합리적이진 않다는 예상을 조심스레 해본다.

 

다음 문서 추가의 경우 또한 청킹 후 이미 구성된 첫번째 layer(leaf-node 바로 윗 레벨)에서 새 청크들 간의 클러스터를 추가하고, 기존 클러스터들과 유사도를 비교하여 적합한 클러스터가 있다면 해당 청크들을 추가할 수 있을 것이다. 물론 이것도 완벽하지 않다. 문서가 추가될수록 한 클러스터에서 커버하는 leaf node의 개수가 늘어나기 때문에 rebalance 작업도 필요할 것이다. 모든 청크에 대해서 다시 클러스터링을 하고 변화가 있는 클러스터에 대해서만 작업 후 재적재를 한다고 해도, 문서량이 늘어날수록 가능한 구조일지 의문이 든다.

 

마지막으로 문서가 수정될 경우, 그러니까 이미 tree에 포함된 청크의 텍스트가 수정되는 경우는 더 어려워진다. 이론상 삭제 후 추가하는 방식이 우선 가능할 것이다. 하지만 이 경우, 문서 내용이 크게 수정되지 않는다고 가정했을 때에는 해당 문서가 연관된 클러스터는 대부분 비숫할 것이고, 동일한 클러스터에 작업을 중복해서 진행해야 한다. 클러스터 작업은 LLM 요약문 생성 및 임베딩 추출/적재이기 때문에 API사용 시 비용이 두 배이고, 비용을 제외하더라도 시간이 두 배로 소요된다.

 

그게 아니라면 해당 문서 청크가 관련된 노드들을 아래 레벨에서부터 하나씩 확인하며 클러스터 내 텍스트 간의 유사도에 차이가 있는지를 확인하고, 있다면 업데이트하는 등의 작업이 필요할 것이다. 하지만 문서 수정이 예를 들어 단순히 제일 앞에 몇 가지 내용이 추가된 것이라면, 문서 내 청크의 순서는 뒤로 밀리고, 청킹이 동일하게 적용되는 것을 확신할 수 없어 기존 텍스트와 신규 텍스트의 변화를 찾는 것부터 쉽지 않다. 물론 여기서도 유사도로 기존 텍스트와 신규 텍스트를 매칭하고, 기존 청킹에 기반해 자르고, 등등의 작업을 할 수 있긴 할테지만 전처리의 과정이 얼마나 복잡해질지 조금 두려워진다.

 

 

나가며

물론 개발은 차츰차츰 구체화해가며 고도화하는 것이니 하면 다 할 수 있다. 하다 보면 더 좋은 방법, 더 효율적인 방법을 찾을 수도 있을 것이다. 하지만 생각하면 할수록 실무와 논문의 차이가 많이 느껴진다. 사실 이런 계층적으로 문서를 적재하는 것은 실무 중 종종 유사한 방식으로 제시되었던 방법인데, 많은 논문이 그러하듯 이 논문에서는 이것을 하나의 방법론으로 정리하여 실험하고, 특정 벤치마크에서 효과가 있다는 것을 증명했다.

 

실사용이 가능한 방법일지 고민하는 차원에서 비교적 비판적으로 바라봤는데, GraphRAG같은 다른 방법론보다는 현실성이 있어 보이고, 반드시 여기서 제시한 과정을 똑같이 적용하지는 않더라도, tree 구조를 훨씬 러프하게 일부만 적용하여 효과를 볼 수도 있을 것 같다는 기대감이 들었다.

 

이제 개발할 차례.