Advanced RAG series: Indexing

이 글은 Advanced RAG series: Indexing 를 보고 작성한 글입니다.

---

1. Chunk Optimization

Chunking 전략을 구성하기 전에 물어봐야 할 두 가지 질문이 있다고 함:

• 데이터가 짧은지, 긴지.
• 우리가 만들려는 LLM 의 목적에 따라서 Chunking 전랴이 달라질 수 있다고 한다.

 

1번의 경우에는 데이터가 짧다면 그대로 Vector Store 에 넣으면 되니까. 하지만 문서가 크다면 Chunk 로 쪼개야 할거임.

 

2번의 경우에는 확실히 LLM 을 Q&A Chatbot 으로 사용할건지, Summarization Tool 로 사용할건지, 아니면 Agentic Workflow (그러니까 한 LLM 의 출력이 다른 LLM 에게 넘어가서 최종적인 답변이 완성되는 경우) 에 따라 달라질거임.

 

Q&A Chatbot 의 경우에는 Document 를 가지고 예상 질문을 뽑은 후 해당 예상 질문과 Document 를 매핑해서 임베딩해서 Vector Store 에 넣는 식으로 Chunking 전략이 결정될거임.

 

Summarization Tool 의 경우에는 Document 를 맥락을 풍부하게 만들기 위해서 글의 단락 별로 제법 길게 Chunking 전략을 구축할 수 있을거임.

 

Agentic Workflow 의 경우에는 각 단계마다 필요한 데이터가 다를 거니까 같은 데이터라고 하더라도 각 처리 단계에 맞게 사용할 수 있도록 Chunking 전략을 구축해야할거임.

 

대표적인 Chunking 전략들에 대해서 하나씩 살펴보자.

 

 

1) Rule based:

가장 단순한 방법은 Character 크기로 Chunk 를 구축하는 방법임.

 

하지만 유의미한 방법이 아니라는 건 알거임. 문장 중간에 잘라져서 chunk 로 구성된다고 생각해보자. 그게 의미가 있을까? 아무리 overlaping 을 준다고 해도.

 

 

물론 더 나아가서 Sentence Tokenizer 를 이용하는 방법도 있음. 이렇게 하면 문장 단위로 잘 짤린다.

 

하지만 Context 가 여러 글의 단락으로 구성되어 있는 경우에 이런 방법은 통하지 않을 걸 예상할 수 있음.

 

 

2) Recursive structure aware splitting:

훨씬 나은 방법임 이 방법을 쓰면 그래도 글의 단락 별로 Chunking 을 구성하게 만들 수 있음. 대신 Chunk 사이즈가 균일하지는 않을 수 있음.

 

원리는 글의 단락 별로 나눠질 때 구분자가 들어갈거임. (e.g \n, \n\n 등) 이런걸로 단락별로 구별한다고 알면됨.

 

 

3) Content-Aware Splitting

만약 Document 의 포맷에 대해 알고있다고 한다면 그 포맷에 맞춰서 나눠서 Chunking 을 하면 됨.

 

예로 Markdown 이라고 한다면 # ## ### 별로 글의 내용이 구별될텐데 이걸 이용해서 쪼개면 됨.

 

 

2. Multi-representation indexing:

여기서는 또 다양한 방식의 Chunking 전략을 소개함.

Parent Document

주어진 질문으로 Chunk 를 검색했을 때 해당 Chunk 를 포함하고 있는 Document 원본을 Context 로 쓰는 방법임.

 

Document 가 가장 컨택스트가 풍부할거니까.

 

그러나 문제점은 Document 가 Context Window 보다 큰 경우가 있을 수 있다는 거임.

 

이런 경우에는 Document 의 내용을 요약시켜서 Context Window 사이즈에 맞게 줄이는 방법임.

 

 

Dense X Retrieval

이 방법은 조금 색다른 방법인데 Chunk 에 넣을 문장들을 문장이나 글의 일부 단락으로 넣는게 아니라 명제 (proposition) 으로 구별해서 넣는 방법이라고 함.

 

이렇게 명제 별로 넣어서 Vector Store 에 적재했을 때 검색 성능이 35%, 22.5% 정도 더 잘 나온다고 함.

 

 

3. Specialized Embeddings

여기서의 방법은 더 유사도 높은 검색을 위해서 Embedding 모델 부분에거 개선을 시도한 것.

 

Fine-tuning:

임베딩 모델을 파인튜닝해서 특정 도메인의 언어를 더 잘 사용하도록 만들면 훨씬 해당 분야의 언어 이해를 더 잘하기 때문에 주어진 질문에 대해 관련있는 Chunk 를 더 잘 찾을 수 있다고 함.

 

ColBERT

임베딩 모델로 ColBERT 를 사용하면 이것도 주어진 질문과 관련있는 Chunk 를 더 잘 찾는다고 함.

 

ColBERT 는 BERT 모델에서 더 업그레이드 한 걸로 더 빠르게, 더 정확하게 검색할 수 있는 모델임. 그래서 대량의 데이터 검색에도 잘 쓸 수 있다고 함.

 

BERT 모델 자체가 Encoder-Decoder 모델로 언어의 유의미함을 잘 발견하는 편이긴 함.

 

유사도 검색 알고리즘으로는 Cosine 을 쓰는게 아니라 MaxSim 이라는 걸 쓴다고 한다.

 

 

4. Hierarchical Indexing:

RAPTOR

RAPTOR의 Chunking 전략은 다음과 같음:

• Document 를 Chapter 별로 쪼갠다. 그리고 Chapter 를 다시 글의 단락별로 쪼갠다.
• 각 단락의 글을 요약해서 해당 단락의 핵심 내용을 추출해서 사라지지 않도록 잘 요약해서 Chunk 를 만든다. 이 Chunk 는 Vector Store 에 저장된다.
• 각 챕터의 단락 요약을 모아서 챕터 요약을 만든다. 이 챕터 요약도 Vector Store 의 Chunk 로 저장된다.
• 글의 챕터의 요약도 모두 모아서 최종 문서 요약도 만든다. 그리고 이 요약 도 Vector Store 에 저장된다.

 

이렇게 Vector Store 에 문서 요약 트리 구조의 내용을 넣어서 검색하면 훨씬 더 성능이 잘 나온다고 함. 

 

이 전략을 Retrieve 에서 Auto-merging 전략과 같이 쓰면 훨씬 나을 수도?