오늘은 올해 발행되어, RAG 시스템의 개선 아이디어를 제시한 'RAPTOR' 논문에 대해 자세히 리뷰해보려 한다.
0. 어원
먼저, RAPTOR의 어원을 먼저 살펴보자.
페이퍼 타이틀인 "RECURSIVE ABSTRACTIVE PROCESSING FOR TREE-ORGANIZED RETRIEVAL"를
직역하면, "트리로 구성된 검색을 위한 재귀적 추상 처리"로 번역할 수 있는데,
뒤에 설명하겠지만, 해당 논문은 RAG를 위한 데이터 구축 방식 및 검색 방법론을 설명하고있고, 여기서는 '트리'와 '재귀적 추상'이라는 키워드에 대해서만 주목하고 넘어가면 될 것 같다.
만약, RAPTOR의 동작방식에 대해서만 빠르게 이해하고자한다면, 아래의 "2.그렇다면, RAPTOR란 무엇인가?" 의
프로세스 부분만 읽어도 무방하다.
1. 배경
기존 Native RAG의 문제점?
RAPTOR는 기존 RAG시스템의 아래 두가지 문제를 해결하기 위해 제안되었다.
첫번째 - 파편화된 참조 정보로 인한 맥락 이해의 어려움
최근 LLM의 단점을 보완할 수 있는, RAG(검색 증강 생성)기법이 소개되면서, 이를 활용하여 다양한 분야에서 domain knowledge를 활용한 연구 및 서비스 개발이 가능해졌다.
RAG 시스템은 보통 User Query에 대해서, 상위 K개의 참조정보를 '추출'한 후, 해당 참조 데이터를 참고해서 높은 객관성을 가진 답변을 생성해내는 원리로 동작한다.
이런 RAG의 특징을 통해, LLM의 고질적인 문제였던 hallucination과 domain knowledge를 참조하지 못하는 문제들을 상당히 해결해내었지만, 추가적인 성능 개선의 필요성이 발생했다.
예를들어, "신데릴라가 어떻게 행복한 결말을 맞이 했는가?"라는 질문에 답한다고 가정해보자.
Native RAG에서는 먼저 주어진 Vector DB내에서 위 문장에 대한 답변을 제공할때 참고할 수 있는
K개의 documents를 추출한다.
각 document는 전체 정보중 유사성이 높은 일부 데이터들로 추출될것이다.
가령,
[
"호박마차를 탔을때, 신데렐라는 유리구두를 잃어버렸다는것을 알게되었습니다",
"신데렐라의 언니들은 저마다 화려한 옷을 입고, 반짝이는 장신구로 치장했습니다",
"그날은 왕자님이 배우자를 찾기 위한 자리였습니다",
...
]
위와 같은 파편화된 문장이 주어졌을때,
최초의 질문이었던"신데릴라가 어떻게 행복한 결말을 맞이 했는가?"라는 질문에 제대로 답변할 수 있을까?...
위 예시와 같이 RAG시스템은 사용자의 질문에 적합한 참고 데이터를 통해 기반 정보를 확대할 수 있다는 장점이 있지만,
전체 정보 또는 특정 sector의 맥락정보를 이해하지 못하고, 파편화된 데이터만을 통해서 피상적 답변의 추출만 가능하다는 한계점을 가지고 있다.
한가지 실제 사례를 추가로 보자면, 세법문서의 경우, 헌법, 법률, 시행력 등 하위규정과 같이 트리구조로 계층화되어 조직화된 경우가 많고, 과학 논문 또한 학문 분야와 주제별로 하위 내용을 형성한다.
대부분의 도메인 지식들은 이와 같이 계층적으로 구조화 되어있는데, 이와 같이 많은 정보가 계층적으로 조직된 경우, 상위 노드에서 중요한 내용을 요약하고, 하위에서 세부 사항을 탐색하는 방식이 효과적이다.
이는 보통 인간이 정보를 탐색하는 방식인데, 예를들어, 세법에서도 부가가치세법, 법인세법 등 다양한 법령 카테고리가 나눠진 후,
부가가치세법 하위에 의제매입에 대한 조항, 수출입 물품에 대한 부가세 적용 조항과 같이
하위 구조가 어이지는 형태로 구성되어있다.
사람은 계층화된 정보를 상위부터 의미를 파악하여 범위를 좁히며 의미를 파악해 나갈 수 있지만,
기존의 RAG 시스템은 계층적 구조를 활용하지 못하고,
키워드를 기반으로 개별적 단위로 탐색을 진행한다는 문제점을 가지고 있다.
두번째 - 대규모 데이터 처리 문제
<RAG 시스템하에서 32k의 context를 input했을때, 하나의 질문에 소요되는 시간과 비용 측정 → 질문당 30달러, 2~7분 소요....서비스가 불가한 수준....>
기존 RAG 시스템은 각 문서를 개별적으로 처리하거나 단순 키워드 매칭에 의존하는 경우가 많아,
추출되는 정보의 양이 방대하기 때문에, 정보를 많이 참고할수록 속도가 느려지고, 검색 결과의 품질이 떨어진다.
이러한 단점을 개선하기 위해, 임의로 정의한 특정 길이 만큼만의 정보만 참조할 경우에도 또한 품질이 떨어질 수 밖에 없다.
세번째 - "요즘에 많이 나오고있는 큰 input length(32k 등..)를 지원하는 모델에서 전체 문서를 input하면 이런 문제가 해결되지 않는가?"
다만, 최근 하드웨어 및 알고리즘의 발전으로 모델이 한번에 처리할 수 있는 context의 길이가 확장되면서,
검색시스템의 필요성에 대한 의문이 제기되기도 한다.
위의 예시와 같이 대량의 input length를 허용하는 모델에 전체 문서를 통째로 input하면, 파편화된 정보로 인해 전체 문맥을
이해하지 못하는 문제도 해결되지않을까라는 반론을 제시할 수 있을것이다.
하지만, 근본적으로, 32k모델과 같이 큰 length의 text를 한번에 input한다고 해도, 전체 문서 내에서 적절한 처리없이,
높은 탐색 성능을 보장할 수는 없다.
Liu et al. (2023)과 Sun et al(2021) 논문에서는 모델은 주어진 매우 큰 크기의 context에 대해 정보를
충분히 활용하지 못하는 경향을 가진다는 연구결과를 발표한 바 있다.
특히, long context가 주어질 수록 성능이 저하되는 특징도 함께 주장되었다.
이뿐아니라 만약 수십, 수백만개의 토큰으로 이루어진 long context를 사용하는것은 비용과 Latency측면에서도
매우 큰 리스크를 가진다.
결국, 전체 문서의 맥락적 의미를 파악하고, 지식을 통합해야하는 질문에 대해 답변하기 위해서는 기존과 다른 새로운 방법론이 필요하고,
이번에 소개할 논문은, RAPTOR가 그 대안이 될 수 있음을 주장하고있다.
2. 그렇다면, RAPTOR는 무엇인가?
RAPTOR의 컨셉을 한마디로 요약하면, "하위에서 상위 Depth로 이어지는 요약 트리구조를 생성하고 이를 참고"하는 기법을 의미한다.
RAPTOR의 진행 프로세스에서의 핵심은, clustering과 summarization을 통한 계층적 요약구조인데,
이 개념이 사실 처음 나온 아이디어는 아니다.
| Author | IDEA |
| Angelidis & Lapata (2018) | 재귀적 요약을 컨텍스트 요약 기법으로 사용하면 문서의 요약된 뷰를 제공하여 콘텐츠에 더 집중정으로 참여 가능.. → 문서의 내용을 축약하는 방식으로, 전체적 Context를 반영할 수 있음에 대한 아이디어 |
| Gao et al.(2023) | 요약/스니펫 모델은 구절의 요약과 스니펫을 사용하여, 대부분의 데이터세트에서 정확성을 향상시키지만, 때로는 손실이 많은 압축수단일 수 있음 → 문서 요약은 정확성을 높이지만, 압축 과정에서 디테일한 세부 정보가 소실될 수 있음을 언급 |
| Wu et al. (2021) | 재귀적 추상 요약 모델(재귀적으로 추상화된 요약을 생성 : map-reduce)은 작업 분해(task decomposition)를 사용하여, 더 작은 text chunk를 요약하고 나중에 통합하여 더 큰 섹션의 요약을 만듦. 이 방법은 더 광범위한 테마를 포착하는 데 효과적이지만 세부적인 내용을 놓칠 수 있습니다. → 마찬가지로 광의의 의미를 잘 파악하겠지만, 세부정보를 누락할 가능성을 언급 |
| LlamaIndex(Liu, 2022) | 유사한 방식으로 인접한 Text chunk를 요약하지만, 중간 노드를 유지하여, 다양한 수준의 세부 정보를 저장하고 세부적인 내용을 유지함으로써 이 문제를 완화합니다. 그러나, 두 방법 모두 인점한 노드를 그룹화하거나 요약하기 위해 인접성에 의존하기 때문에 텍스트 내에서 RAPTOR로 찾아서 그룹화할 수 있는 먼 상호의존성을 간과할 수 있습니다. → 말그대로, 인접한 chunk간의 관련성을 그룹화하는데, 이는 멀리 떨어진 문맥간의 의존성, 관계성을 무시하는 결과를 보이게 될거임.. |
위와 같이 유사한 여러건의 연구결과를 통해 종합해보면,
1) 전체적 문맥정보를 파악하기 위해서는 전체 또는 sector별 요약 정보가 도움이 될 수 있다.
2) 요약 정보만 남기게 될 경우, 세부적 의미를 누락할 위험이 있기 때문에 하위정보와 요약정보를 함께 활용해야한다.
3) 전체 정보공간(전체 documents)에서 흩어져있는 관련 정보들을 연결지어 온전한 정보로 활용할 필요가 있다.
세가지 인사이트를 도출할 수 있는데,
이 세가지를 모두 충족할 수 있는 방향으로 고안된 방법론이 RAPTOR라고 보면된다.
자, 그럼 위 3가지 인사이트를 어떻게 반영했는지, 아래 RAPTOR 작업 프로세스를 보면서 살펴보자. ㄱㄱ~!
| 1) Chunking |
전체 텍스트를 길이, 의미 단위로 Chunking을 진행한다 (첫번째 그림에서 Leaf layer에 해당)
|
| 2) Embedding |
Chunking 된 각 문장들에 대한 embedding vector를 생성한다.
|
| 3) Clustering |
Chunk Pool을 대상으로 Clustering을 진행하여 유사문장들간의 Group을 형성한다. (두번째 그림 참고)
|
| 4) Summarization by LLM (중요) |
LLM을 통해 각 클러스터의 '요약 문장'을 생성한다.
|
| 2~4) 종합 : TREE 구축 METHOD |
| 자, 여기까지 2~4번과정은 결국, 상세정보와 축약정보를 골고루 담고있는 Tree 를 구축하기 위한 과정이었다. 여기서 Tree 구축에 대한 조금 더 디테일한 방법론을 살펴보자. 1) GMM(가우시안 혼합모델)
|
| 5) Flatten(Collapsed Tree Structure) |
위에서 생성한 Tree구조의 데이터를 그대로 사용하지 않고, Flatten하여 단일 layer에서 선택하도록 처리한다.
|
VECTOR DB 생성 완료!!!
| 6) Reference Context 검색 및 생성 |
|
| 7) Answer |
|
마지막으로, 2,000토큰을 context Max length 기준으로 두고,
제공된 reference context와 User Query를 참고하여 LLM은 최종 답변을 출력하게 된다. |
3. RAPTOR 효과
Since RAPTOR with SBERT has the best performance
...
<NarrativeQA Performance With + Without RAPTOR:>
<QuALITY and QASPER Performance With + Without RAPTOR>
<Controlled comparison of F-1 scores on the QASPER dataset, using three different language models (GPT-3, GPT-4, UnifiedQA 3B) and various retrieval methods>
Retrieval-augmented language models can better adapt to changes in world state and incorporate long-tail knowledge. However, most existing methods retrieve only short contiguous chunks from a retrieval corpus, limiting holistic understanding of the overall document context. We introduce the novel approach of recursively embedding, clustering, and summarizing chunks of text, constructing a tree with differing levels of summarization from the bottom up. At inference time, our RAPTOR model retrieves from this tree, integrating information across lengthy documents at different levels of abstraction. Controlled experiments show that retrieval with recursive summaries offers significant improvements over traditional retrieval-augmented LMs on several tasks. On question-answering tasks that involve complex, multi-step reasoning, we show state-of-the-art results; for example, by coupling RAPTOR retrieval with the use of GPT-4, we can improve the best performance on the QuALITY benchmark by 20% in absolute accuracy.
<평가 데이터>
- NArrativeQA(Ko cisk y et al.2018) : 책과 영화에 대한 자유 텍스트 응답 질문 벤치마크
- QASPER(Dasigi et al. 2021) : 과학 논문에 대한 질의응답 데이터셋으로, 논문의 복잡한 내용을 이해하고 해당 내용을 기반으로 질문에 답변하는 AI 모델을 평가하기 위해 개발된 데이터 셋
- QuALITY(Pang et al. 2022) : 긴 형식의 입력 문서를 기반으로 질문에 답하는 AI 모델의 이해 및 추론 능력을 평가하기 위한 벤치마크 데이터셋으로, 단순 정보 추출이 아니라 문맥의 전체적인 이해와 추론이 요구되는 질문을 제공 함
논문에서는 RAPTOR를 다양한 케이스에서 QASPER, QuALITY 벤치마크를 통해 성능을 비교 평가했다.
→ NArrativeQA 벤치마크를 기준으로, SBERT, BM25, DPR중에서는 SBERT가 RAPTOR를 함께 사용했을때, 좋은 성능을 보여주었다.
→ 긴 입력 문서 기반 답변(QuALITY)에서 모든 임베딩 알고리즘이 RAPTOR를 함께 사용했을때, 단독으로 추론한 것 보다 더 좋은 성능을 보여주었다.
→ 논문기반 답변 벤치마크(QASPER)에서 BM25 vs DPR vs SBERT&RAPTOR 를 각각 다양한 LLM과 함께 사용했을때, SBERT&RAPTOR를 GPT4와 함께 사용했을때 가장 좋은 성능을 보였다. (논문에 표현된 지표 상, 약 20%정도의 성능 향상을 확인할 수 있다.)
4. RAPTOR 구현 시, 주의할 점 (참고)
RAPTOR를 구성할때, 가장 중요한점은 Tree를 잘 구축하는것이다.
Tree에 요약된 부모 노드의 context가 하위 노드의 정보를 '잘~요약'했을때, Clustering 성능과, 최종 LLM의 정보 Extraction 성능을 높아질 수 있기 때문이다!
요약된 정보의 품질이 낮을 경우, 이후 재귀적으로 진행되는 클러스터링 결과 및 부모노드의 퀄리티는 완전히 다른 결과를 반영할 수 있다.
이 내용은, 테디노트 RAPTOR 영상의 한 구독자 댓글에서도 해당 인사이트를 확인할 수 있다.
이 부분은 추후 RAPTOR구현 시, Vectorization 및 요약에 사용할 모델의 실제 성능을 잘 평가, 선택할 필요가 있음을 알 수 있다.
5. 결론 및 OneAI 활용 방안
- 결론
- RAPTOR는 파편화된 document를 의미단위로 축약처리하여, 추상적인 Query에도 적절한 참고 정보를 찾을 수 있는 검색 알고리즘이다.
- 위치와 관계없이 문서내 흩어진 관련 정보를 모아 새로운 참조 데이터를 생성할 수 있다.
- 상세 정보와 추상정보를 모두 포함하여, 다양한 Depth의 Query에도 강건한 검색 성능을 가진다.
- max context내에 질문과 밀접한 관련이 있는 참조 정보만으로 선택적으로 추출이 가능하다.
오늘은 RAPTOR논문에 대해서 자세히 살펴보았다.
RAPTOR는 복잡한 내부 프로세스 없이, 클러스터링과 요약으로 이루어진 Tree 구조의 데이터 증강을 통해
손쉽게 RAG 참조 데이터의 퀄리티를 높일 수 있는 방식으로 보인다.
현재 RAPTOR는 FAISS와 Langchain을 통해서 간편하게 구현이 가능하기때문에,
기존 서비스에 이미 반영된 RAG시스템을 빠르게 대체할 수 있을것으로 보이고,
교체에 드는 리소스보다, 다양한 Depth의 질문에 대한 답변 성능 개선 효과가 더 클 것으로 예상된다.
나도 얼른 서비스하고 있는 챗봇에 적용해보고 추후 반영 후기도 한번 포스팅 해보도록 하겠다.
'PAPER_REVIEW' 카테고리의 다른 글
| [AI/ML] 좋은 논문 찾는 법! (0) | 2023.04.05 |
|---|
