Searching for Best Practices in Retrieval-Augmented Generation 리뷰

Searching for Best Practices in Retrieval-Augmented Generation

 

오랜만에 논문리뷰를 하는 것 같네요. 링크드인으로 요즘 트렌드나 기술을 팔로 업하고 있는데 'RAG를 최적화하기 위한 필독 논문'이라고 해서 오랜만에 논문 정독을 해야겠다 싶어서 글을 쓰고 있습니다. RAG 기술을 아직도 구현 ing 단계라고 느끼고 있습니다. 다양한 NLP 기반의 방법론을 더해서 완성도를 올리고 있으나 아직 뭔가 적당한 서비스에 적용할 만큼의 성능은 나오질 않는 것 같습니다. 저도 최근에 이력서기반의 RAG 서비스를 만들면서 느낀 건, 다양한 Search 알고리즘을 많이 적용해도 레이턴시가 너무 느려지고, 또 한 PLM 이 좋지 않다면 Context를 잘 뽑아도 ICL 단계에서의 추론성능이 떨어져 원하는 결과물을 가져오지 못한다는 것을 또 깨달았습니다. 

 

RAG 어떻게 하면 더 잘 할까?

 

우선 제가 이전에 이호연님 연사를 듣고 작성한 글을 한번 더 리마인드 해보고 위 논문을 읽으면 좋을 듯합니다. 이전과 같이 본문의 내용을 쭉 설명 요약하고 제가 해석한 방식대로 서술을 하겠습니다.

 

Abstract

RAG 기법은 최신 정보를 통합하고, 환각(hallucinations)을 줄이며, 특히 전문 도메인에서 응답 품질을 향상하는 데 효과적임이 입증되었습니다. 많은 RAG 접근법이 쿼리 의존적 검색을 통해 대형 언어 모델을 강화하려고 제안되었지만, 이러한 접근법은 여전히 복잡한 구현과 긴 응답 시간의 문제를 겪고 있습니다. 일반적으로 RAG 워크플로우는 여러 처리 단계를 포함하며, 각 단계는 다양한 방법으로 실행될 수 있습니다. 여기서 우리는 기존의 RAG 접근법과 이들의 잠재적 조합을 조사하여 최적의 RAG 실천 방안을 식별하고자 합니다. 광범위한 실험을 통해 성능과 효율성을 모두 균형 있게 유지할 수 있는 여러 전략을 제안합니다. 또한 멀티모달 검색 기법이 시각적 입력에 대한 질문 응답 능력을 크게 향상하고, “검색을 생성으로” 전략을 사용하여 멀티모달 콘텐츠 생성을 가속화할 수 있음을 입증합니다.

 

1. Introduction

 

이 연구에서는 광범위한 실험을 통해 RAG의 최적 실천 방법을 식별하고자 합니다. 이러한 방법의 모든 가능한 조합을 테스트하는 것이 불가능하기 때문에, 최적의 RAG 실천 방법을 식별하기 위해 3단계 접근법을 채택합니다. 먼저, 각 RAG 단계(또는 모듈)에 대한 대표적인 방법을 비교하고 가장 성능이 좋은 최대 세 가지 방법을 선택합니다. 다음으로, 다른 RAG 모듈을 변경하지 않은 상태에서 개별 단계에 대해 하나의 방법씩 테스트하여 각 방법이 전체 RAG 성능에 미치는 영향을 평가합니다. 이를 통해 응답 생성 중 다른 모듈과의 기여도 및 상호 작용을 기반으로 각 단계에 가장 효과적인 방법을 결정할 수 있습니다. 일단 모듈에 대한 최적의 방법이 선택되면, 이는 후속 실험에서 사용됩니다. 마지막으로, 성능보다 효율성을 우선시하는 등의 다양한 응용 시나리오에 적합한 몇 가지 유망한 조합을 경험적으로 탐구합니다. 이러한 결과를 바탕으로 성능과 효율성을 모두 균형 있게 유지할 수 있는 여러 전략을 제안합니다.

이 연구의 기여는 세 가지로 요약됩니다:

• 광범위한 실험을 통해 기존 RAG 접근법과 그 조합을 철저히 조사하여 최적의 RAG 실천 방법을 식별하고 추천합니다.
• RAG 모델의 성능을 포괄적으로 평가하기 위해 일반적, 전문적(또는 도메인 특화), RAG 관련 능력을 포함하는 평가 지표와 해당 데이터셋의 포괄적 프레임워크를 소개합니다.
• 멀티모달 검색 기법의 통합이 시각적 입력에 대한 질문 응답 능력을 크게 향상시키고 "검색을 생성으로" 전략을 통해 멀티모달 콘텐츠 생성을 가속화할 수 있음을 입증합니다.

저는 여기서 Repacking 이란 개념 말고는 기존의 Rag-sruvey 에서 다루었던 내용들이라 알고는 있었고, 어느 정도의 Pipeline으로 구성이 되는지는 알고 있었으나 최적의 워크플로우 구성을 위한 설명을 위 논문에서 제시해 준다고 합니다. 그러나 이 논문도 결국 시대의 흐름에 따라 예전기술을 나열하는 이전의 논문이 될 가능성이 높습니다. 그러나 현재 트렌드에서의 효율적인 워크플로우 구성이라서 한번 정독해보겠습니다.

 

2. Related Work

대형 언어 모델(LLM)의 응답 정확성을 보장하는 것은 매우 중요하지만, 단순히 모델 크기를 키우는 것만으로는 특히 지식 집약적 작업 및 전문 도메인에서 환각 문제를 해결할 수 없습니다. RAG 기법은 외부 지식 기반에서 관련 문서를 검색하여 정확하고 실시간의 도메인 특화된 문맥을 제공함으로써 이러한 문제를 해결합니다. 이전 연구들은 쿼리 및 검색 변환, 검색기 성능 향상, 검색기 및 생성기의 미세 조정을 통해 RAG 파이프라인을 최적화하여 응답의 정확성과 관련성을 높였습니다.

 

2. 1 Query and Retrieval Transformation

효과적인 검색을 위해서는 쿼리가 정확하고 명확하며 상세해야 합니다. 쿼리가 임베딩으로 변환되더라도 쿼리와 관련 문서 간의 의미적 차이가 남아있을 수 있습니다. 이전 연구들은 쿼리 변환을 통해 쿼리 정보를 향상하고 검색 성능을 개선하는 다양한 방법을 탐구했습니다. 예를 들어, Query2 Doc과 HyDE는 원본 쿼리에서 의사 문서를 생성하여 검색 성능을 향상하고, TOC는 쿼리를 하위 쿼리로 분해하여 검색된 내용을 집계합니다. 다른 연구들은 검색 소스 문서를 변환하는 데 중점을 두었으며, 대조 학습을 사용하여 쿼리와 문서 임베딩을 의미 공간에서 더 가깝게 만듭니다. 또한, 검색된 문서를 후처리 하여 생성기 출력을 향상하는 방법으로 계층적 프롬프트 요약 및 압축기를 사용하여 문맥 길이를 줄이고 중복을 제거하는 기법이 사용됩니다.

 

기존의 Langchain에서도 지원하고 있는 다양한 쿼리트랜스폼 방법들이 있다. 다중 쿼리에 대한 쿼리를 분할을 한다던지 쿼리를 gpt-4o와 같은 상위모델로 다시 문맥에 맞게 re-write 한다던지, HyDE와 같이 쿼리를 가상의 문서로 생성하고, 임베딩하고 이 임베딩을 통해 다시 유사도 검색을 통해 리트리버 하는 방식인데, 랭체인에서도 쉽게 구현이 가능하다. 결국 HyDE는 조금이나마 벡터 공간 안에서 실제 문서와 조금이라도 더 가깝게 가기 위한 방법론이라 할 수 있다. Query2 doc 또한 문서형태로 더 확장시켜서 검색엔진이 더 많은 정보를 가져오도록 하는 방법론이다. Stepback prompting 방법도 더 추상적인 prompt를 통해서 Query transformation을 하는 방법이다. 이 방법들이 예전에 대회를 할 때 효과를 발휘한 적 있었는데 , 그만큼 응답시간은 늦어질 수밖에 없다 모델을 한번 더 타기 때문이다.

 

hyde | 🦜️🔗 LangChain

 

2. 2 Retriever Enhancement Strategy

문서 청킹(chunking) 및 임베딩(embedding) 방법은 검색 성능에 큰 영향을 미칩니다. 일반적인 청킹 전략은 문서를 청크로 나누는 것이지만, 최적의 청크 길이를 결정하는 것은 어려운 일입니다. 작은 청크는 문장을 분할할 수 있고, 큰 청크는 관련 없는 문맥을 포함할 수 있습니다. LlamaIndex [19]는 Small2 Big 및 슬라이딩 윈도와 같은 방법으로 청킹 방식을 최적화합니다. 검색된 청크는 관련이 없을 수 있으며, 수가 많을 수 있기 때문에 재정렬이 필요합니다. 일반적인 재정렬 접근법은 BERT [25], T5 [26], LLaMA [27]와 같은 심층 언어 모델을 사용하여 느린 추론 단계를 거치지만, 더 나은 성능을 제공합니다. TILDE [28, 29]는 효율성을 달성합니다.

 

Chunk의 중요성을 설명하고 있는데 맞는 말이다. 문서를 로드하고 청크를 제대로 하지 않고, 오버랩을 적당히 주지 않는다면 원하는 검색결과를 가져오기 어려울 것이다. 그 과정에서 llamaindex 에선 small2 big이라는 슬라이딩윈도와 같은 청킹방식을 사용하는 듯하다. 이 청크방법은 langchain의 Parent Child와 비슷하다. 문서 간의 계층구조를 활용해서 부모 - 자식 간의 청크 문서를 활용해서 각각 청크사이즈를 부모는 예로 들어 Chunk_size를 1000 자식은 300으로 주고  하나의 ParentDocumentRetrieval로 초기화하여 더 효과적인 검색을 할 수 있다. 쉽게 말해 큰 덩어리, 작은 덩어리 구분해 놓고 효율적이게 쓰겠다고 생각하면 된다.

 

https://python.langchain.com/v0.1/docs/modules/data_connection/retrievers/parent_document_retriever/

Parent Document Retriever | 🦜️🔗 LangChain

 

이 과정에서도 나오겠지만 재귀적인 청크방법, 글자단위의 청크, Sementic 의미 단위의 청크기반이 사용될 수가 있는데 이건 RAG 구축 과정에서 많은 시도를 해봐야 한다. 일반적으로는 RecursiveCharacterTextSplitter를 많이 쓰는 것 같다.

 

2. 3 Retriever and Generator Fine-tuning

 

RAG 프레임워크 내에서 검색기와 생성기를 최적화하기 위해 미세 조정이 중요합니다. 생성기가 검색기의 문맥을 더 잘 활용할 수 있도록 생성기를 미세 조정하거나, 생성기에 유익한 구절을 검색하도록 검색기를 미세 조정하는 접근 방식이 있습니다. 전체적인 접근 방식은 RAG를 통합된 시스템으로 취급하여 함께 미세 조정함으로써 전체 성능을 향상하는 것입니다. 여러 설문 조사에서는 현재 RAG 시스템의 다양한 측면을 다루고 있지만, 실제 구현을 위한 적절한 알고리즘 선택은 여전히 도전 과제입니다. 이 논문에서는 RAG 방법을 적용하기 위한 모범 사례에 중점을 둡니다.

 

예시에서는 백그라운드 지식의 여부에 따라 알고리즘을 적용하는 관련 예시를 들고 있다. 저도 이 부분이 제일 큰 어려움이라고 생각을 하는데, 예로 들어 파인튜닝을 RAFT와 같은 RAG를 효율적으로 사용하기 위한 RAG prompting에 잘 맞게 언어모델을 템플릿을 구성해서 파인튜닝하는 방법도 있을 것이고 LangGraph 나 Agent 형태와 같이 routing을 잘해서 적재적소에 알고리즘을 적용시키는 방법이 있을 것이다. 과연 이 논문에서 추천하는 방법이 무엇일지 궁금하기도 하다. 

 

3 RAG Workflow

이 절에서는 RAG 워크플로우의 구성 요소를 설명하며, 각 모듈에 대해 일반적으로 사용되는 접근 방식을 검토하고 최종 파이프라인을 위한 기본 및 대체 방법을 선택합니다. 그림 1에서 각 모듈의 워크플로우와 방법을 확인할 수 있으며, 자세한 실험 설정은 부록 A에 있습니다.

3. 1 Query Classification

실험 결과에 따르면, BERT-base-multilingual 분류기는 높은 정확도(Acc), 정밀도(Prec), 재현율(Rec), 및 F1 점수를 기록하였습니다. 이는 분류기의 성능이 우수함을 나타냅니다.

 

쿼리 분류의 필요성은 LLM의 능력과 검색의 필요성 간의 균형을 맞추기 위해 중요합니다. 예를 들어, 모델이 이미 알고 있는 정보에 대한 요청은 검색이 필요 없지만, 최신 정보나 모델이 알지 못하는 정보를 요구하는 요청은 검색이 필요합니다. 이를 자동화하기 위해 분류기를 훈련하며, 이를 통해 응답 시간을 줄이고 정확도를 높이는 데 기여할 수 있습니다.

 

매번 RAG pipeline에서 고려할 수밖에 없는 Query Classification이다. 예로 들어 일상대화 / 도메인 대화 가 있는 사내챗봇을 생각해 보면 물론 prompt engineering으로 어느 정도 해결이 가능할 수 있지만. 버트와 같은 분류모델로 1차 쿼리를 한번 분류해 주고, 해당 내용에 적합한 LLM으로 호출하는 파이프라인이 좋을 것이다. LangChain에서도 여러 개의 Chaining을 통해서 구성을 할 수 있지만 역시 토큰이 소모될 수 있다는 점?이지만 사실 일반 쿼리 분류하는 정도의 토큰은 세발의 피라고 생각한다. 넣는 게 좋다고 생각한다. 어쩌면 Routing을 알아서 하기 전 초기단계의 버전이 아닐까 생각한다.

 

3. 2 Chunking

문서를 작은 세그먼트로 나누는 청킹은 검색 정확성을 향상하고 대형 언어 모델(LLM)의 길이 문제를 피하기 위해 중요합니다. 이 과정은 토큰 수준, 문장 수준, 의미 수준 등 다양한 세분화 수준에서 적용될 수 있습니다.

• 토큰 수준 청킹 (Token-level Chunking): 간단하지만 문장을 분할할 수 있어 검색 품질에 영향을 미칠 수 있습니다.
• 의미 수준 청킹 (Semantic-level Chunking): LLM을 사용하여 분할 지점을 결정하며, 문맥을 유지할 수 있지만 시간이 많이 소요됩니다.
• 문장 수준 청킹 (Sentence-level Chunking): 텍스트의 의미를 유지하면서도 간단하고 효율적인 균형을 이룹니다.

이 연구에서는 단순함과 의미 보존의 균형을 맞추기 위해 문장 수준 청킹을 사용합니다. 우리는 청킹을 다음 네 가지 차원에서 검토합니다.

 

Chunk 단위도 매우 중요하다 위 논문에서는 3개의 방법을 얘기를 한다. Tokens 단위의 청킹과 의미("나는 밥을 먹었어") 단위의 청킹 문장 수준의 청킹이다. 일반적으로는 글자단위의 청킹을 많이 썼던 거 같다. 500으로 설정했을 때 개인적으론 효과가 제일 좋았다. 그러나 이건 그냥 내 데이터에 피한 거지 정답은 없는 거 같다. 부모-자식 청크방법처럼 대-소로 청크를 해서 쓴다던지 위 조합들을 토큰 수준과 의미청크를 같이 fusion 해서 사용해도 괜찮지 않을까 생각이 들긴 한다. 아직 그 방법은 보질 못해서 찾아봐야겠다.

 

3. 2.1 Chunksize

 

chuksize 관련

청크 크기는 검색 성능에 중요한 영향을 미치며, 큰 청크는 더 많은 문맥을 제공하지만 처리 시간이 증가합니다. 작은 청크는 검색 재현율을 높이고 처리 시간을 줄이지만 문맥이 부족할 수 있습니다. 최적의 청크 크기를 찾기 위해 신뢰성과 관련성을 측정하여 균형을 맞춥니다. 다양한 청크 크기의 성능을 비교한 결과, 청크 크기 512와 256이 높은 신뢰성과 관련성을 보여줍니다.

 

내경험도 그랬듯이 확실히 512가 성능이 좋았다. 처음에 사내기반 문서를 RAG 하기 위해 청크를 크게 설정했었는데 오히려 Context가 많이 들어가서 좋은 거 아니야? 무조건적으로 생각을 했었는데 토큰낭비를 할 수 있을 뿐만 아니라 오히려 쓸데없는 정보가 많이 들어가서 내가 원하는 성능이 나오지 않았던 기억이 있다. 결국 많이 잘라봐야 한다!

 

3. 2.2 Chunking Techniques

 

고급 청킹 기법인 small-to-big 및 슬라이딩 윈도는 청킹 블록 관계를 조직하여 검색 품질을 향상합니다. 작은 블록은 쿼리와 일치시키는 데 사용되며, 작은 블록과 문맥 정보를 포함한 더 큰 블록이 반환됩니다. LLM-Embedder 모델을 사용한 실험 결과, 이러한 기법들이 문맥을 유지하고 관련 정보를 검색하는 데 효과적임을 보여줍니다.

 

3.2.3 Embedding Model Selection

 

적절한 임베딩 모델을 선택하는 것은 쿼리와 청크 블록 간의 효과적인 의미적 매칭을 위해 매우 중요합니다. 실험 결과, LLM-Embedder는 BAAI/bge-large-en와 유사한 성능을 보이지만 크기는 더 작습니다. 따라서 우리는 LLM-Embedder을 선택합니다. 또한, 다양한 청크 기술을 비교한 결과, 슬라이딩 윈도 기법이 가장 높은 신뢰성과 관련성을 보여줍니다.

 

Sliding window는 오버랩설정을 주는 기술이다. 오버랩은 이전의 청크단위의 설정값만큼 다음에 오는 문서에 추가해서 문맥을 잘 파악할 수 있도록 긴문서를 나눌 때 설정하는 방법이다. 제일 일반적인 RAG에서 쓰는 기술이다. 이 기술도 중요한 게 너무 많이 주어도 노이즈를 발생시키기도 한다.

 

3.2.4 Metadata addition

 

청크 블록에 제목, 키워드 및 가상 질문 등의 메타데이터를 추가하는 것은 검색 성능을 향상하고, 검색된 텍스트를 더 잘 후처리 할 수 있도록 하며, LLM이 정보를 더 잘 이해할 수 있도록 돕습니다.

 

3.2.5 Vector Databases

 

벡터 데이터베이스는 임베딩 벡터와 메타데이터를 저장하여 효율적인 검색을 가능하게 합니다. 네 가지 주요 기준(다중 인덱스 유형, 수십억 개 벡터 지원, 하이브리드 검색, 클라우드 네이티브 기능)을 기반으로 여러 벡터 데이터베이스를 평가한 결과, Milvus가 가장 포괄적인 설루션으로 선택되었습니다. Milvus는 모든 필수 기준을 충족하며, 다른 오픈 소스 옵션보다 뛰어난 성능을 제공합니다.

 

벡터데이터베이스를 선정하는 것 또한 중요하다. 여기서는 5개의 오픈소스들을 예로 들었는데 사실 Langchain으로 가볍게 시도해 볼 수 있는 예제들은 Faiss , Chroma로 대부분이 구성이 되어있다. 나도 그냥 팔로 업하는 느낌으로 들었을 때도 현업에서도 Milvus를 많이 채택해서 쓴다고들 했다. 확실히 직관적으로 표에서도 이해를 도와준다. 다중인덱스를 지원하고, 수십억 개 대용량처리, 중요한 하이브리드 서치 지원 클라우드 환경 통합 등 Milvus를 써보진 않았는데 이 논문을 계기로 Milvus 를 사용해 봐야겠다.

 

3.4 Retrieval Methods

사용자 쿼리에 대해 검색 모듈은 상위 k개의 관련 문서를 선택하여 생성 모델이 이를 바탕으로 적절한 응답을 생성합니다. 원본 쿼리의 표현 부족과 의미 정보 부족 문제를 해결하기 위해 세 가지 쿼리 변환 방법(쿼리 재작성, 쿼리 분해, 의사 문서 생성)을 평가했습니다. 최근 연구는 어휘 기반 검색과 벡터 검색의 결합이 성능을 크게 향상함을 보여주며, 본 연구에서는 BM25와 Contriever를 사용하여 두 가지 강력한 기준선을 제공합니다.

 

해결 방법:

1. 쿼리 재작성 (Query Rewriting): 쿼리를 재작성하여 관련 문서와의 일치를 개선합니다.
2. 쿼리 분해 (Query Decomposition): 원본 쿼리를 하위 질문으로 분해하여 문서를 검색합니다.
3. 의사 문서 생성 (Pseudo-documents Generation): 사용자 쿼리를 기반으로 가상의 문서를 생성하여 유사한 문서를 검색합니다.

원본쿼리라던지 , 다중의 질문이 있는 의미의 쿼리에서 보통 RAG가 정신을 못 차리고 똑같은 말만 하는 앵무새가 되곤 한다. 그 경험을 개선하고자 쿼리 재작성, 쿼리 분해 후 합치기, Query2 doc과 같이 의사문서 생성등 다양한 방법론을 적용해야 할 수 있다. 내가 가장 유용하게 썼던 건 쿼리분해였다 다중쿼리에서의 앵무새를 잡아주었다. 내가 할 당시에는 쿼리를 3개로 분할해서 각각 호출해서 결과를 다시 요약 합쳐서 쓰긴 했는데 지금 트렌드 자체는 bm25 키워드기반의 서치를 하기 때문에 유용할 수 있겠다 생각을 했다. 논문에서도 bm25, Contriever이 강력하다고 소개한다.

 

3.4.1 Results for different retrieval methods

 

이 부분에서는 다양한 검색 방법의 성능을 비교한 결과를 설명합니다. TREC DL 2019 및 2020 패시지 랭킹 데이터셋을 사용하여 평가한 결과, 지도 학습 방법이 비지도 학습 방법보다 뛰어난 성능을 보였으며, HyDE와 하이브리드 검색을 결합한 방법이 가장 높은 점수를 기록했습니다.

 

주요 결과:

1. 지도 학습 방법: 비지도 학습 방법보다 높은 성능을 보임.
2. HyDE와 하이브리드 검색: LLM-Embedder가 가장 높은 성능을 기록.
3. 쿼리 재작성 및 쿼리 분해: 검색 성능을 크게 향상하지 못함.

권장 사항:

• 기본 검색 방법: HyDE를 사용한 하이브리드 검색.
• 하이브리드 검색: 희소 검색(BM25)과 밀집 검색(원래 임베딩)을 결합하여 낮은 지연 시간으로 높은 성능을 제공.

hybrid 검색은 이제 RAG에서의 필수요소이다. HyDe를 활용해서 하이브리드검색을 사용하라고 말을 하고 있다. 쿼리를 임베딩 단위에서의 문서화를 만들고 그 후 bm25 기반의 하이브리드서치를 적용하란 뜻 같다. 

 

3.4.2 Results for different retrieval methods

 

HyDE를 사용하여 가상의 문서와 쿼리를 결합하는 다양한 전략의 영향을 평가한 결과, 여러 개의 의사 문서를 원래 쿼리와 함께 결합하면 검색 성능이 향상될 수 있지만, 지연 시간이 증가합니다. 이는 검색 효율성과 효과성 간의 균형을 필요로 함을 시사합니다. 알파 값에 따른 하이브리드 검색의 성능을 평가한 결과, α = 0.3일 때 가장 좋은 성능을 보였습니다. 또한, MS MARCO 패시지 랭킹 데이터셋에서 다양한 리랭킹 방법의 성능을 비교한 결과, RankLLaMA가 가장 높은 성능을 기록했습니다.

 

최근에 많은 RAG 예제에서 앙상블 리트리버를 7:3으로 bm25의 비율에 놓고 썼었는데, 성능이 개선된 거 같은 느낌이었는데 논문에서는 알파값을 0.3으로 설정해서 쓰는 것이 베스트라고 한다. 또 아래에서 다루겠지만 리랭크모델에서 성능이 가장 좋은 건 RankLLAMA라고 한다. Cohere의 aya도 괜찮았던 것 같다.

 

3.4.2 Hybrid Search with Different Weight on Sparse Retrieval

 

표 8에서는 하이브리드 검색에서 α 값이 희소 검색과 밀집 검색 간의 가중치 조절에 미치는 영향을 보여줍니다. α 값이 0.3일 때 가장 좋은 성능을 보였으며, 이는 α를 적절히 조정하면 검색 효율성을 향상할 수 있음을 시사합니다. 따라서 우리의 주요 실험에서는 α = 0.3을 사용합니다.

 

 

검색점수는 총검색횟수 = a(가중치) x bm25 + 밀집 검색이다. 여기선 0.3 이 최적이라고 하는데 나는 그동안 0.7로 넣고 썼었는데 다시 시도를 해봐야 할 것 같다.

 

3.5 Reranking Method

초기 검색 후 리랭킹 단계를 통해 검색된 문서의 관련성을 높입니다. 두 가지 리랭킹 방법(DLM 리랭킹과 TILDE 리랭킹)을 평가하였으며, 각각 성능과 효율성을 우선시합니다. 실험 결과, 성능과 효율성의 균형을 맞춘 방법으로 monoT5를 추천하며, 최고의 성능을 위해서는 RankLLaMA, 가장 빠른 경험을 위해서는 TILDEv2를 추천합니다.

 

리랭킹은 옵션 같은 느낌이다 정확도가 높은 Task 라면 무조건 들어가야 할 것이지만 실시간 반응이 나타나야 하는 task엔 부적합할 수 있다. 리트리버 해온 정보들을 다시 재검색해서 순위를 매겨서 Context에 들어갈 수 있게 도와주는 작업이다. 여기선 DLM과 TiLDE 2개의 방법론을 인용하였다. 성능은 DLM기반의  RankLLaMA 속도는 tildev2였는데 RankLlama와 같은 모델은 미리 문서의 관련성을 판단하는 참 거짓으로 레이블링 해서 모델을 파인튜닝한 모델이다. 그래서 참 토큰 확률에 따라 순위가 매겨져서 재정렬을 하게 된다.

 

3.6 Document Repacking

LLM 응답 생성과 같은 후속 프로세스의 성능은 제공되는 문서의 순서에 영향을 받을 수 있습니다. 이러한 문제를 해결하기 위해, 우리는 리랭킹 후 워크플로우에 콤팩트 재포장 모듈을 도입하여 "forward", "reverse", "sides" 세 가지 재포장 방법을 제공합니다.

• “forward” 방법: 리랭킹 단계에서의 관련성 점수가 높은 순서대로 문서를 재포장합니다.
• “reverse” 방법: 관련성 점수가 낮은 순서대로 문서를 재포장합니다.
• “sides” 방법: Liu et al. [48]의 연구에서 관련 정보가 입력의 머리나 꼬리에 배치될 때 최적의 성능이 달성된다는 결론에 따라, 문서를 "앞뒤"에 배치하는 방법입니다.

재포장 방법은 주로 후속 모듈에 영향을 미치기 때문에, 섹션 4에서 다른 모듈과의 조합으로 테스트하여 최적의 재포장 방법을 선택합니다. 이 섹션에서는 기본 재포장 방법으로 "sides" 방법을 선택합니다.

 

repacking 방법은 처음 알게 되었는데, 순위가 낮은 방법으로도 패킹한다는 게 신기했다. side방법의 예시는 기존의 정렬문서 5개가 있다면 순위대로 정렬을 했을 것이다.

리랭킹된 문서 목록 (관련성 순서):

문서 A (가장 관련성 높음)
문서 B
문서 C
문서 D
문서 E (가장 관련성 낮음)
이 목록을 "Sides" 방법으로 재포장하면 다음과 같습니다:

"Sides" 방법으로 재포장:

앞부분(머리): 문서 A, 문서 B
중간 부분: 문서 C
뒷부분(꼬리): 문서 D, 문서 E

위처럼 머리 / 중간 / 꼬리로 구성을 하는 방법이다. 

 

3.7 Summarization

검색 결과는 중복되거나 불필요한 정보를 포함할 수 있으며, 긴 프롬프트는 추론 속도를 저하시킬 수 있습니다. 따라서 효율적인 요약 방법이 필요합니다. 추출적 요약과 생성적 요약 방법을 사용하여 검색된 문서를 요약하며, 쿼리 기반 방법에 초점을 맞춥니다. Recomp는 우수한 성능으로 추천되며, LongLLMLingua는 더 나은 일반화 능력으로 대체 방법으로 고려됩니다.

 

3.8 Generator Fine-tunning

정식으로, 우리는 RAG 시스템에 입력된 쿼리를 x로, 이 입력에 대한 문맥을 D로 표기합니다. 생성기의 미세 조정 손실은 정답 출력 y의 음의 로그 우도입니다. 특히 관련성과 무관한 문맥의 영향을 탐구하기 위해, 쿼리와 관련된 문맥을 dgold로, 무작위로 검색된 문맥을 drandom으로 정의합니다. 우리는 다음과 같이 D의 구성을 변화시키면서 모델을 훈련합니다:

 

문맥 구성:

1. Dg: 쿼리와 관련된 문서로 구성된 문맥.
2. Dr: 무작위로 선택된 문서 하나를 포함하는 문맥.
3. Dgr: 관련 문서와 무작위로 선택된 문서로 구성된 문맥.
4. Dgg: 쿼리와 관련된 문서 두 개로 구성된 문맥.

모델 평가:

• 기본 생성기 (Mb): 미세 조정되지 않은 모델.
• 미세 조정된 모델: 각각 Dg, Dr, Dgr, Dgg로 구성된 문맥을 사용하여 미세 조정된 모델.

결과:

• 평가 지표: 정답 커버리지.
• 모델 성능: 관련 문서와 무작위 문서를 혼합하여 훈련한 모델(Mgr)이 가장 성능이 좋음.

 

쿼리와 관련된 문서와 함께 무작위로 선택된 문서를 훈련 데이터에 포함하면 생성기의 성능이 향상이 된다고 한다. 강인성 향상과, 노이즈처리, 일반화 능력이 향상이 된다. 말 그대로 파인튜닝 시에 내가 만약 영업챗봇을 만든다고 가정하면 영업 도메인데이터뿐만 아니라 무작위 데이터를 함께 섞어서 학습시켰을 때 성능이 개선이 많이 된다고 한다.

 

4 Searching for best RAG Practices

이 섹션에서는 RAG를 구현하기 위한 최적의 방법을 조사합니다. 각 모듈에 대해 섹션 3에서 식별한 기본 방법을 사용하고, 개별 모듈을 순차적으로 최적화하면서 가장 효과적인 옵션을 선택했습니다. 반복적인 과정을 통해 최종 요약 모듈의 최적 방법을 결정했습니다. 섹션 3.8에 기반하여, 각 쿼리가 몇 개의 무작위로 선택된 관련 문서로 보강된 Llama2-7B-Chat 모델을 미세 조정하여 사용했습니다.

최종 권장 방법:

• 분류 모듈 포함
• HyDE와 하이브리드 검색
• monoT5 리랭킹
• reverse 재포장
• Recomp 요약

 

이 설정은 다양한 작업에서 최상의 성능을 제공했으며, 특히 정확도(Acc), 정확 매칭(EM), F1 점수에서 높은 성과를 보였습니다. Milvus를 사용하여 1,000만 개의 영어 Wikipedia 텍스트와 400만 개의 의학 데이터 텍스트를 포함하는 벡터 데이터베이스를 구축했습니다.

 

5 Discussion

5.1 Best Practies for Implementing RAG

 

실험 결과에 따르면, RAG 시스템을 구현하기 위한 두 가지 다른 레시피 또는 실천 방안을 제안합니다. 하나는 성능을 최대화하는 데 중점을 두고, 다른 하나는 효율성과 효과성 간의 균형을 맞추는 것입니다.

 

최고 성능 실천 방안:

• 구성: QueryClassification , HyDE와 하이브리드 방법의 검색, monoT5 리랭킹, Reverse 재포장, Recomp 요약.
• 성과: 가장 높은 평균 점수인 0.483을 기록했지만, 계산 비용이 많이 소요됩니다.

균형 잡힌 효율성 실천 방안:

• 구성: QueryClassification, 하이브리드 검색 방법, TILDEv2 리랭킹, Reverse 재포장, Recomp 요약.
• 성과: 검색 모듈이 시스템 처리 시간의 대부분을 차지하므로, 하이브리드 방법으로 전환하면 지연 시간을 크게 줄이면서도 유사한 성능을 유지할 수 있습니다.

 

5.2 Multimodal Extension

 

우리는 RAG를 멀티모달 응용 프로그램으로 확장했습니다. 구체적으로, 시스템에 텍스트-이미지 및 이미지-텍스트 검색 기능을 포함하여 쌍으로 된 이미지와 텍스트 설명을 검색 소스로 사용했습니다. 그림 4에 나타난 바와 같이, 텍스트-이미지 기능은 사용자의 쿼리가 저장된 이미지의 텍스트 설명과 잘 맞을 때 이미지 생성 프로세스를 가속화합니다(즉, "검색을 통한 생성" 전략). 이미지-텍스트 기능은 사용자가 이미지를 제공하고 해당 이미지에 대해 대화할 때 사용됩니다.

 

멀티모달 RAG 기능의 장점:

• 신뢰성: 검색 방법은 검증된 멀티모달 자료에서 정보를 제공하여 진위성과 구체성을 보장합니다. 반면, 실시간 생성은 새로운 콘텐츠를 생성해야 하므로 사실 오류나 부정확성이 발생할 수 있습니다.
• 효율성: 검색 방법은 특히 답변이 이미 저장된 자료에 존재하는 경우 더 효율적입니다. 반면, 생성 방법은 특히 이미지나 긴 텍스트를 생성하는 데 더 많은 계산 자원이 필요합니다.
• 유지 관리 용이성: 생성 모델은 새로운 응용 프로그램에 맞추기 위해 세심한 미세 조정이 필요하지만, 검색 기반 방법은 검색 소스의 크기와 품질을 향상하는 것만으로도 새로운 요구에 대응할 수 있습니다.

 

• 텍스트-이미지 검색:
  • 텍스트 쿼리를 사용하여 데이터베이스에서 가장 높은 유사성을 가진 이미지를 찾습니다.
  • 높은 유사성이 발견되면 이미지를 직접 반환합니다.
  • 그렇지 않으면 이미지 생성 모델을 사용하여 적절한 이미지를 생성하고 반환합니다.
• 이미지-텍스트 검색:
  • 사용자가 제공한 이미지를 데이터베이스의 이미지와 매칭하여 가장 높은 유사성을 가진 이미지를 찾습니다.
  • 높은 유사성이 확인되면 일치하는 이미지의 사전 저장된 캡션을 반환합니다.
  • 그렇지 않으면 이미지 캡션 모델이 새로운 캡션을 생성하고 반환합니다.

 

6 Conclusion

 

이번 연구는 RAG 시스템 구현을 위한 최적의 실천 방안을 식별하고, 각 모듈에 대한 가장 효과적인 접근 방식을 추천함으로써, 대형 언어 모델이 생성하는 콘텐츠의 품질과 신뢰성을 크게 향상할 수 있는 기반을 마련했습니다. 우리의 연구 결과는 RAG 시스템에 대한 이해를 깊게 할 뿐만 아니라, 향후 연구를 위한 중요한 지침을 제공합니다.

 

 

위 글은 현재 트렌드를 반영하여 대규모의 RAG 시스템을 구축해 보면서 테스트한 결과들을 기술해 두었다. 어차피 트렌드는 빠르게 변하고 변할 것이다. 위 내용을 참고해서 RAG Pipeline을 구축해 보고 좋으면 쓰고, 또 다른 신기술이 나오면 계속 테스트를 해보면서 수정 보완해가야 하는 것이 RAG의 큰 어려움인 것 같다. 이 논문을 보면서도 아 내가 아직도 RAG 잘 모르네 느낄 수 있지 않았나 싶다.