RAG의 패러다임(Naive RAG, Advanced RAG, Modular RAG)

오픈AI의 GPT 시리즈, Meta의 LLama 시리즈, Google의 Gemini와 같은 대형 언어 모델(LLM)은 생성 AI분야에서 큰 성과를 이루게 되었다. 하지만 위와 같은 모델들의 문제점은 종종 부정확하거나 관련 없는 정보를 생성하며, 오래된 정보에 의존하고, decision-making 과정이 투명하지 않아 블랙박스 추론을 초래하게 된다. 

 

Retrieval-Augmented Geneartion(RAG)는 외부 지식 소스로부터 추가적인 정보를 통합하여 대형 언어 모델(LLM)을 개선하는 과정이다. 이를 통해 LLM은 더 정확하고 문맥을 고려할 수 있는 답변을 생성하며, 환각(hallucination)을 방지할 수 있게 되었다. 이러한 장점을 가진 RAG는 2023년 이후 LLM 기반 시스템에서 범용적으로 사용되는 아키텍처로 자리 잡았다. 이에 RAG가 어떻게 발전해 왔는지 알아보도록 하겠다. 

💡 RAG Framework 

최근 몇 년 동안 RAG 분야에서는 많은 연구가 이루어졌으며, 크게 RAG는 세 가지의 범주로 나눌 수 있다.

• Naive RAG
• Advanced RAG
• Modular RAG 

그럼 이 세 가지의 범주에 대해서 아래의 그림을 통해 자세히 알아보도록 하겠다. 

💡 Naive RAG 

1. Indexing : Indexing은 RAG에서 수행되는 초기 단계이다. 이 단계는 Raw Data를 추출하는 것에서 시작하며, PDF, HTML, Word와 같은 다양한 파일 형식을 표준화된 plain text로 변환하게 된다. 대규모 언에 모델(LLM)은 한 번에 처리할 수 있는 텍스트의 최대 길이에 제한이 있다. 대규모 문서나 데이터 셋을 더 효율적으로 관리하기 위해 더 작고 관리 가능한 청크로 나누게 되는데, 이를 Chunking이라고 한다. 그런 다음 Embedding Model를 통해 Chunking된 text들을 벡터로 표현이 된다. 마지막으로 벡터화된 청크는 Vector DB에 키-값 쌍으로 저장된 게 된다. 이러한 Vector DB는 이후의 Retreival 단계에서 efficient 하고 scalable search capabilities 기능을 제공한다. 
   
   
2. Retrieval : 사용자 쿼리는 외부 지식 소스(Vector DB)으로 부터 관련 문맥을 검색하는데 활용이 된다. 이를 수행하기 위해 사용자 쿼리는 인코딩 모델에 의해 처리되어 의미적으로 관련된 임베딩을 생성하게 된다. 그런 다음 벡터화된 쿼리는 Vector DB에서 유사성 검색을 기반으로 상위 k개 검색을 수행하여 가장 비슷한 데이터를 찾게 된다. 
   
   
3. Generation : 사용자의 Query와 검색된 추가적인 정보는 Prompt에 입력되고 LLM를 거쳐 답변을 생성하게 된다. 

 

💡 Naive RAG의 문제점 

1. Indexing 

• 정보 추출의 불안정성 : PDF와 같은 비정형 파일 내 이미지와 표에 있는 유용한 정보를 효과적으로 처리하지 못한다. 
• 청킹 방법 : 청킹 과정에서 파일 유형의 특성을 고려하지 않고 "one-size-fits-all" 을 사용하는 것이 대반사이다. 이는 각 청크에 일관성과 불필요한 의미 정보가 포함될 가능성이 크며, 기존 텍스트의 문단 구분과 중요한 세부 사항을 놓치게 된다 
• 비최적화 인덱싱 구조 : 인덱싱 구조가 최적화되지 않아 비효율적인 검색 기능을 초래하게 되며, 이는 검색 속도를 현저하게 느리게 만들고 검색 결과의 정확성을 떨어지게 만든다. 
• 임베딩 모델의 의미 표현 능력 : 임베딩 모델이 텍스트의 의미를 제대로 파악하지 못해, 검색된 정보의 관련성이 낮아진다. 이는 중요한 정보를 놓칠 수 있게 된다. 

2. Retrieval

• 제한된 검색 알고리즘: 키워드, 의미, 벡터 검색을 결합하지 않은 등 다양한 검색이나 알고리즘의 통합이 제한적이며, 이는 검색 결과의 다양성과 정확성을 저하시킨다. 
• 쿼리 및 임베딩 모델의 한계 : 쿼리가 부족하거나 임베딩 모델의 의미 표현 성능이 낮아 유용한 정보를 검색하지 못한다.
• 답변 정보 중복 : 여러 검색된 컨텍스트가 유사한 정보를 포함하여 생성된 답변에 반복적인 내용이 포함된다.

3. Generation  

• 잘못된 응답 생성 : LLM이 관련 없거나 편향된 응답을 생성할 가능성이 높다. 
• 잘못된 정보 제공 : 유용한 정보를 제공하지 않고 검색된 내용을 단순히 반복하는 결과를 초래할 수 있으며, 일관성 없는 답변을 뱉는 경우가 발생한다. 

---

💡 Advanced RAG 

 

Advanced RAG는 Naive RAG 방식에서 직면하고 있는 문제를 해결하기 위해 고안되었다. 하지만 여기에서 고려해야 할 것은 어떠한 방식으로 데이터 소스에서 관련 문서를 효율적으로 검색하는 것이며, 아래와 같은 사항들을 해결해야 한다. 

• 문서와 쿼리의 semantic representation의 정확성을 어떻게 극대화할 수 있을까?
• 쿼리와 문서(청크)의 semantic space를 어떻게 align 시킬수 있을까? 
• Retrieval의 출력을 LLM의 선호도에 맞게 조정할 수 있는 방법이 무엇일까? 

위의 세 가지 고찰을 보완하기 위해 Pre-Retreival 및 Post-Retrieval를 기존 RAG 아키텍처에 추가한 것이 Advanced RAG이다. 이들의 역할에 대해 알아보자. 

1. Pre-Retrieval 

주요 목적은 색인 구조와 사용자 쿼리를 개선하는 것이다. 

• 데이터 품질 향상 : 엔터티와 용어의 모호성을 제거하고, 사실 정확성을 위해 문맥 유지 및 새로운 정보를 업데이트 한다. 
• 인덱스 구조 최적화 : 청크 크기를 최적화하여 문맥을 일정화하고 엔터티 간의 관계를 포착하기 위해 그래프 구조의 정보를 추가한다. 
• 메타데이터 추가 : dates, chapters, subsections, purposes 등과 같은 관련 정보를 청크에 메타데이터로 추가하여 데이터 필터링을 개선한다. 
• 청크 최적화 : 외부 데이터 소스/문서를 사용하여 RAG 파이프라인을 구축할 때, 청크를 더 작은 조각으로 나누어 세부적인 특성을 추출한다. 그런 다음 청크를 임베딩하여 내포하고 있는 의미를 도출한다. 

2. Retrieval 

청크 크기가 결정된 후, 임베딩하게 된다. 해당 단계에서는 쿼리와 임베딩된 청크 간의 유사성을 계산하여 가장 관련성 높은 청크를 식별하게된다. 여기서 쿼리와 청크에 사용되는 임베딩 모델을 최적화할 수 있다. 

• Domain Knowledge Fine-Tuning : 임베딩 모델이 각 도메인별 정보를 정확하게 포착할 수 있도록,  도메인 특화 데이터셋을 사용하여 fine-tuning한다. 이를 위한 데이터셋에는 쿼리, 코퍼스 및 관련 문서가 포함되어야 한다. 
• Dynamic Embedding : 단어가 등장하는 맥락에 맞춰 임베딩을 fine-tuning하는 방식이다. 이는 각 단어에 대해 하나의 벡터만을 사용하여 각 토큰 당 정해진 임베딩을 리턴하는 방식이 아니라 주변 단어에 따라 맥락을 고려할 수 있는 BERT를 사용하는 것과 같다. 

3. Post-Retrieval 

관련된 정보(청크)들을 Vector Database 내에서 검색한 후, 쿼리와 함께 LLM에 입력된다. 하지만 검색된 청크들이 간혹 중복이 되거나 의미 없는 정보를 담는 경우 발생하게 되는데, 이는 LLM이 주어진 컨텍스트를 처리하는 방식에 영향을 미칠 수 있다. 이러한 문제를 극복하기 위해 사용되는 방법에 대해 간단하게 알아보자.

• Reranking : 검색된 정보를 재순위하여 가장 관련성 높은 답변을 우선시한다. LLM에 입력이 추가될 때, 성능이 저하되는 경우가 발생한다. 이에 검색된 청크를 재정렬하고 Top-K 가장 관련성 높은 청크를 식별하여 LLM에 사용할 컨텍스트로 제공한다. 
• Prompt Compression : 검색된 정보에 Noisy가 많을 수 있으므로, LLM에 태우기전에 관련 없는 정보를 압축하고 길이를 줄이는 것도 중요하다.  

 

---

💡Modular RAG 

앞서 알아보았던 Advanced RAG는 Naive RAG의 컴포턴트를 조금씩 보완한 형태라면, Modular RAG는 조금 더 나아가 다양하고 유연한 구조를 지향한다. 이러한 구조는 RAG의 전반적인 성능을 향상 시켰으며, 현재 어플리케이션을 구축할 때 표준 패러다임이 되었다. 그럼 몇 가지 모듈에 대해 알아보도록 하자. 

• Search Module : 임베딩 유사도 기반 검색 외에도 추가적인 검색 시나리오를 가능하게 한다. 즉 Search Module은 특정 시나리오에 맞춰 LLM이 생성한 코드나 SQL 등을 사용하여 검색을 수행하는 모듈이다. 이에 다양한 데이터 소스를 사용할 수 있다는 점이다.
• Memory Module : LLM이 벡터 데이터베이스에서 검색된 청크뿐만 아니라 시스템 메모리에 저장된 이전 쿼리와 결합하여 현재 입력과 가장 유사한 답변을 찾는 모듈이다. 
• Fusion Module : 유저의 의도를 정확하게 반영하지 않을 수도 있다는 차관에서 비롯되었다. LLM을 통해 유저의 쿼리로 부터 여러 개의 가상 쿼리를 생성하여 검색하는 방식이다. 

Fusion Model (RAG-Fusion)

 

위의 모듈뿐만 아니라 다양한 모듈이 존재하니, 이에 대해 궁금하시다면 링크 참고하시길 바랍니다.