https://arxiv.org/pdf/2410.05983

RAG의 성능을 어떻게 높일 수 있을까?

전통적인 RAG 시스템은 정보 검색기(retriever)와 생성기(generator)로 구성되며, 정보 검색기가 적절한 정보를 찾으면 생성기가 답변을 구성하는 구조로 활용되었습니다. 그래서 대부분의 이전 연구들이 보통 검색기나 생성기의 성능 향상에 각각 초점을 맞추는 경향이 있어 왔는데요.
해당 포스팅에서 리뷰할 논문은 구글 클라우드에서 발표한 2024년도 최신 연구로, LLM 기반의 RAG 시스템의 안정성을 높이기 위한 방법을 제안합니다. 기존의 기조와 다르게 리트리버나 LLM의 성능보다는, 전체 RAG 시스템을 포괄적으로 분석하면서 긴 문맥을 처리하는 LLM을 생성기로 사용하는 데서 발생하는 과제와 기회를 탐구하는 논문입니다.
원하는 task에 RAG를 직접 적용해 보신 분들께서는 공감하시겠지만, 실제 프로젝트에서 아직 RAG가 원하는 만큼의 성능을 100% 보여주지는 않습니다. 완벽하게 제대로 동작하지 않는 경우가 많고요.....

Long-Context와 RAG

RAG를 사용하면 retrieve하는 문서가 context로 붙으면서 입력 시퀀스가 자연스레 길어지게 됩니다. context가 길수록, 여러 개일 수록 입력하는 시퀀스의 양은 많아지겠죠. 최근 LLM들은 오픈소스 경량 모델 기준으로도 최대 입력 토큰이 128K가 되는 등(예 : Llama 3.2 1B & 3B 모델의 최대 입력 토큰은 128K) 처리할 수 있는 입력량이 많아지기는 했습니다. 하지만 입력이 길어져도 똑같이 좋은 퀄리티의 답변을 수행하느냐?는 별개의 문제인 것 같습니다. 실험을 해 보면 context가 길어질수록 다양한 문제점이 발생하곤 합니다. RAG를 위해 모델을 train, fine-tuinig할 때도 그렇고 Inference를 수행할 때도 그렇고요. 특히 context는 길어지는데 정작 거기에 정답이 없는 경우처럼 복잡한 상황에서는 더욱 문제가 많고는 하죠.
본 논문은 앞서 말씀드린 것처럼 LLM 기반의 RAG 시스템의 안정성을 높이기 위한 방법을 제안합니다. 본 논문 리뷰 포스팅이 관련 RAG 연구에 도움이 되길 바라며, 짧은 논문 리뷰를 시작하겠습니다.


논문 keyword : 
"hard negatives"

[1] Abstract, Introduction 초록, 서론

LLM이 많은 양의 외부 정보를 처리하는 능력이 증가하면서 RAG 성능이 향상될 가능성이 있음
그러나 실험 결과, 긴 문맥을 처리한 많은 LLM들에게서 검색된 문서 수가 증가함에 따라 성능이 처음에는 개선되다가 일정 수준 이후로는 오히려 저하되는 경향이 나타났으며, 분석 결과 "hard negatives"라 불리는 비관련 정보가 성능 저하의 주요 원인임을 밝혀냄 (LLM의 혼란이 가중되어 발생하는 문제)
본 논문에서는 이를 해결하고 LLM 기반의 RAG 시스템의 안정성을 높이기 위한 방법을 아래와 같이 3가지로 제안함

  1. [파인튜닝 불필요❎] Retrieval Reordering
  2. [파인튜닝 필요✅] Implicit Robustness Fine-tuning
  3. [파인튜닝 필요✅] Explicit Relevance Fine-tuning
⭐은 제가 임의로 경중을 나누고자 표시했으며 논문에 기재된 것이 아닙니다.

[2] Related Work 관련 연구

전통적인 RAG 시스템은 정보 검색기(retriever)와 생성기(generator)로 구성되며, 정보 검색기가 적절한 정보를 찾으면 생성기가 답변을 구성하게 됨. 따라서 이전 연구들은 보통 검색기나 생성기의 성능 향상에 초점을 맞추는 경향이 있어 왔음.
본 논문은 전체 RAG 시스템을 포괄적으로 분석하면서 긴 문맥을 처리하는 LLM을 생성기로 사용하는 데서 발생하는 과제와 기회를 탐구함.

관련 연구에 관해서는 이 정도로만 짧게 요약하고 기타 내용은 생략하겠습니다.

[3] Challenges of Long context LLMs in RAG

3.1. The Effect of retrieved context size on RAG performance

긴 문맥을 처리할 수 있는 LLM이 많은 검색된 문서를 수용할 수 있지만, 과연 이렇게 많은 정보를 포함하는 것이 항상 성능 향상으로 이어지는가? -> "아니오"

(a)와 (b)는 각각 e5와 BM25라는 두 가지 검색기를 사용, 검색된 문서 수가 증가함에 따라 여러 LLM의 성능이 어떻게 변화하는지 비교

항목
(a) e5 검색기 사용 RAG 성능 (b) BM25 검색기 사용 RAG 성능
검색기 특징 높은 리콜(Recall)을 제공하는 강력한 검색기 낮은 리콜을 제공하는 약한 검색기
성능 패턴 검색된 문서 수가 약 300개까지 증가할 때 성능이 향상되지만, 그 이후에는 성능이 하락하는 역 U자형 패턴이 나타남 검색된 문서 수가 증가함에 따라 성능이 꾸준히 향상되며, 성능 하락 구간이 거의 없음
"Hard negatives" 영향 많은 "hard negatives"로 인해 검색된 문서 수가 많아질수록 모델의 혼란이 증가하여 성능이 저하됨 "hard negatives"의 영향이 적어, 검색된 문서 수 증가가 성능 저하로 이어지지 않음
모델 간 성능 차이 모든 모델에서 Gemini-1.5-Pro가 가장 높은 성능을 보이지만, 검색된 문서 수가 많아질수록 성능 하락이 더 뚜렷하게 나타남 Gemini-1.5-Pro가 가장 높은 성능을 유지하며, 다른 모델들에 비해 검색된 문서 수 증가에 따른 성능 변화가 완만함
성능 개선 한계 검색된 문서 수가 약 300개를 넘어서면 오히려 성능이 하락하기 시작 검색된 문서 수가 많아질수록 성능이 서서히 증가하며, 성능 하락의 한계가 거의 없음
모델 추천 조합 짧은 문맥을 주로 사용하는 경우 추천 긴 문맥에서 성능 저하가 적기 때문에 다양한 문맥 길이에서 활용 가능

주요 인사이트

  • 관련 정보가 포함되어 있어도 “hard negatives”의 존재로 인해 LLM이 정확한 답변을 생성하는 데 혼란을 줄 수 있음. 또, 더 높은 정확도와 Recall을 가진 Retriever e5가 오히려 성능 저하가 더 심각한 결과를 보임.
  • 이는 검색 품질을 평가할 때 정확도만으로는 부족하며, 관련 없는 정보의 특성을 함께 고려해야 한다는 점을 시사

3.2. The interplay of retrieval quality and LLM capabilities

그래서 RAG의 성능 저하가 검색기의 문제인가 LLM의 문제인가? -> 둘 다의 문제입니다.

(a)와 (b)는 각각 e5와 BM25라는 두 검색기를 사용하여 검색된 문서 수가 증가함에 따라 RAG 정확도, 리콜, 정확도가 어떻게 변화하는지를 나타냄

항목 (a) e5 검색기 사용 그래프 분석 (b) BM25 검색기 사용 그래프 분석
RAG Accuracy 검색된 문서 수가 약 15개까지 증가할 때 정확도가 상승하지만, 이후에는 성능이 하락하거나 유지됨. 이는 "hard negatives"의 증가로 인해 성능이 저하되는 것을 시사 검색된 문서 수가 증가함에 따라 성능이 꾸준히 상승하거나 완만하게 변화하여, "hard negatives"의 영향을 덜 받음
리콜(Recall) 검색된 문서 수가 증가할수록 리콜이 선형적으로 상승, 더 많은 관련 정보가 검색되지만 항상 성능 향상으로 이어지지는 않음 리콜이 증가하지만 e5에 비해 완만한 속도로 증가함. 검색된 문서 수가 늘어남에 따라 관련 정보를 더 많이 포함하되, 속도가 느림
정확도(Precision) 검색된 문서 수가 증가할수록 정확도가 급격히 하락. 이는 "hard negatives"가 많이 포함되어 검색 품질이 떨어짐을 나타냄 검색된 문서 수가 늘어남에 따라 정확도가 완만하게 감소. "hard negatives"가 적게 포함되어 정확도 감소폭이 작음
모델 최적화 방향 적은 수의 문서를 검색할 때 효과적이지만, 문서 수가 많아지면 성능 저하가 발생하므로 조정이 필요 긴 문맥에서도 성능 저하가 덜 발생하여 다양한 문맥 길이에서 활용 가능

주요 인사이트

  • RAG 성능 저하는 검색기가 너무 많은 "hard negatives"를 포함하는 것과 LLM이 겪는 혼란이 결합하여 발생함
  • RAG 시스템에서 LLM 성능을 최적화하려면 검색 품질의 균형이 필요하며, 특히 "hard negatives"를 최소화하는 방향으로 검색기와 검색된 문서 수를 조정할 필요가 있음

3.3. The importance of hard negatives for long-context LLM evaluation

현재의 Long-context LLM들은 "hard negatives"에 얼마나 강인한가? -> 취약함.
사용되는 Retriever 유형에 따라 "hard negatives"의 영향이 달라지는가? -> 예.

e5 > Contriever > BM25 순으로 성능이 높은 검색기 (e5는 가장 높은 리콜)

주요 인사이트

  • 실험 결과 Gemini-1.5-Pro가 그나마 성능 저하가 가장 덜 두드러지고 hard negatives에 대해 강한 내성을 가지고 있다고 보여짐. 그런데 이 결과는 본 논문이 구글 클라우드 연구임을 감안해서 봐야 할듯.
  • 검색기의 유형에 따라 "hard negatives"의 영향이 다르게 나타나기 때문에 목적과 과제에 맞는 검색기 선택 중요

[4] Simple and effective training-free RAG improvement

파인튜닝 불필요❎
"Lost-in-the-middle" 현상

LLM은 입력 시퀀스의 처음과 끝 부분에 있는 정보에 더 집중하는 경향이 있으며, 중간에 있는 정보는 비교적 덜 주목하는 "lost-in-the-middle" 현상 특성을 가지고 있음 → 본 연구에서는 이를 활용하여 검색된 문서 중 높은 관련성을 가진 문서들을 입력의 앞과 뒤에 배치함으로써, 중간에 배치된 "hard negatives"의 영향을 최소화하고자 함
즉, 검색된 문서를 순서 조정하여 관련성이 높은 문서를 시작과 끝에 배치하는 "Retrieval Reordering" 기법을 통해 LLM이 더욱 효과적으로 중요한 정보를 처리할 수 있도록 돕는 방법을 제안함

  • 검색된 문서를 관련성 점수를 기준으로 정렬 (d1​,d2​,...,dk​)
  • 높은 관련성을 가진 문서를 입력의 시작과 끝에 배치하도록 순서를 조정
    1. 구체적으로, 홀수 인덱스의 문서는 앞쪽에, 짝수 인덱스의 문서는 뒤쪽에 배치
    2. 최종 입력을 [I, d1,d3,d5,...,d4,d2,q] 형태로 구성

주요 인사이트

  • Retrieval reordering significantly improves RAG performance, particularly with larger numbers of retrieved passages. 검색된 문서가 많은 상황에서 특히 성능이 크게 개선됨!
  • 즉, 검색된 문서 수가 적을 때는 효과가 미미할 수 있지만, 문서 수가 많을수록 "lost-in-the-middle" 현상과 "hard negatives"의 영향을 줄이는 데 효과적이었음
  • NQ와 PQA 데이터셋 모두에서 유사한 패턴을 보여, reordering 기법이 데이터셋과 모델에 상관없이 RAG 성능을 개선할 수 있는 일반적인 방법임을 확인

[5] Improving Robustness for RAG via Data-Augmented Fine-Tuning

[파인튜닝 필요✅]

5.1. Implicitly improving LLM robustness through fine-tuning

방법

모델이 불필요한 정보를 내포한 상황에서도 더 나은 성능을 발휘할 수 있도록 파인 튜닝함. 즉, "hard negatives"와 같은 관련성이 낮은 문서를 포함한 다양한 검색 컨텍스트에 LLM을 노출하여, 모델이 불필요한 정보에 대한 내성을 자연스럽게 학습 + 잡음을 인식하고 무시하는 능력을 강화

결과

불필요한 정보가 포함된 상황에서도 성능 하락이 덜하다는 점에서 "hard negatives"에 대한 내성이 향상됨

5.2. Enhancing relevance identification through reasoning augmentation

방법

  • 추론 단계 추가: 입력 데이터를 [Instruction, Passage 1, Passage 2, ..., Passage k, Query] 형태로 제공하고, 모델은 중간 단계로 추론 단락(Reasoning Paragraph)을 생성하여 관련 문서를 식별한 후 최종 답변을 도출 - 이를 통해 모델이 관련성과 무관한 정보를 명확하게 구분하는 능력을 갖추게 됨
  • 훈련 중에는 추론 단락의 정답 레이블이 함께 제공됨
  • "중간 추론"을 통해 논리적 체계를 갖추어 정보의 선별이 이루어지며, 최종적으로 답변이 생성
  • 이 과정은 결국 두 단계의 파인튜닝을 수행하는 것과 유사함
    • 1단계: 중간 추론 단락을 생성하여 정보의 관련성을 평가하는 능력을 키움.
    • 2단계: 중간 추론을 바탕으로 최종 답변을 도출하여, 올바른 답변을 생성하도록 최종 파인튜닝.

결과

Explicit Relevance Fine-tuning을 통해 LLM은 노이즈와 관련 정보를 더 잘 구분, 중요 정보 분별력이 향상


[6] Data-Centric Perspectives on Fine-tuning LLMs for RAG

여긴 좀 당연한 소리 하는 파트로, 간략하게만 정리하고 넘어가겠습니다.

(a) 훈련 데이터 분포 분석 (Analysis of training data distribution)

  • 여러 데이터세트(NQ, WoW, Fever, MMLU 등)를 결합한 Mixed data (혼합 데이터)로 훈련한 모델이 모든 검색 문서 수에 걸쳐 가장 높은 성능을 보임 - 단일 데이터보다 혼합 데이터를 사용한 파인튜닝이 모델의 일반화 성능을 높이는 데 더 효과적!

(b) 검색기 변화에 따른 파인튜닝 효과 (Influence of retriever variations on fine-tuning effectiveness)

  • 서로 다른 검색기(BM25, e5, 그리고 이 둘의 혼합)를 사용해 훈련한 모델들이 다양한 검색기(BM25, Contriever, BGE, e5)를 사용할 때 얼마나 높은 정확도를 보이는지 비교 - 혼합 검색기로 파인튜닝한 모델은 모든 검색기에서 고르게 높은 성능을 보여주며, 특히 새로운 검색기(BGE)에서도 강한 적응력을 보임

(c) 최적의 훈련 문서 수 탐색 (Investigation of the optimal number of passages for training)

  • 훈련에 사용된 문서 수의 비율(25%, 50%, 100% 등)에 따라 RAG 성능이 어떻게 달라지는가? - 최대한 많은 문서를 사용하여 파인튜닝하는 것이 RAG 성능을 일반화하고, 다양한 상황에서도 더 높은 성능을 유지하는 데 도움

[7] Conclusion

향후 연구 방향

  • 더 정교한 위치 최적화 및 검색 순서 방법을 통해 모델의 성능을 자동으로 최적화하는 방법을 탐구
  • 더 세분화된 다단계 추론 체인을 통한 LLM 파인튜닝을 통해 RAG 시스템의 성능을 더욱 향상시키는 방법을 연구

마무리

논문을 읽고 제가 한 생각, 배운점, 느낀점 등을 간략히 정리하면 아래와 같습니다.

  1. Long context RAG의 경우 recall이 아주 높은 e5같은 retriever을 사용하는 것은 위험할 수 있으며, bm25같은 애들이 무난하게 작동할 수 있다. 어떤 Retriever를 선택하느냐도 항상 고민해야할 문제.
  2. RAG를 구현할 때 retrieval reordering을 통해 hard negatives는 중간에 배치하여 LLM이 덜 주목하게 하면 모델이 Long context를 잘 처리할 수 있다.
  3. 그치만 중요한 context가 중간에 배치되어도 정확하게 답변을 출력할 수 있는 능력도 결국엔 중요하지 않을까? 파인튜닝을 하지 않기 위해 RAG가 도입되었지만 결국 완벽한 RAG는 적절한 파인튜닝이 필수적으로 요구되는듯..
  4. 또 파인튜닝을 1단계로 하지 않고 2단계로 나누어서 처음에 ‘중간 추론 단계’라는 걸 넣어주면 좋다는데 이것은 자원의 한계를 고려해서 실행해야 할 듯 하다.

포스팅 내 잘못된 정보가 있다면 댓글 남겨주시기 바라며, 이번 포스팅을 읽어주셔서 감사합니다. 
지금까지 사이언티스트 수리링이었습니다 :)

https://arxiv.org/pdf/2407.19813

Self-Reasoning이라는 프레임워크를 통해 RAG의 성능을 높이고자 연구한 논문. 2,000개의 작은 데이터셋으로 LLM 튜닝했을 때 원하는 성과가 나왔다고 한다.

핵심 포인트만 짚어서 가볍게 논문 리뷰를 해보도록 하겠다.



논문 리뷰에 앞서 내가 직접 이해하고 요약한 Self-Reasoning의 흐름은 아래와 같다.

  1. RAG의 고질병은 무관한 문서를 검색할 경우 모델 성능이 저하될 수 있으며, 인용이 명확하지 않으면 생성된 출력의 신뢰성을 검증하기 어렵다는 데에 있다.
  2. 그래서 본 연구는 이를 해결하기 위한 Self-Reasoning이라는 새로운 프레임워크를 제안한다. 이를 통해 관련성 높은 문서를 검색하고, 문서로부터 출처를 명확하게 인용하도록 할 수 있다고 한다.
  3. 이 과정이 구체적으로는 3단계(RAP → EAP → TAP)로 나뉜다.
    • RAP에서는 Retrieve한 문서가 질문에 관련성이 있는지 없는지, 그 이유는 무엇인지 LLM이 생성한다.
    • EAP에서는 가장 관련성이 높은 문서에서 증거(Evidence)에 해당하는 근거 문장들을 찾아내고, 그 문장을 답변의 출처로 인용해도 되는 이유를 LLM이 생성한다.
    • TAP에서는 RAP와 EAP에서 생성한 모든 내용을 종합해서 질문에 대한 답변을 2가지 버전으로 출력하는데, 긴 버전을 Analysis, 짧은 버전을 answer라고 부른다.
  4. 이러한 Self-Reasoning이 잘 굴러가기 위해서 먼저 RAP/EAP/TAP 단계를 모두 이해하도록 LLM 파인튜닝했는데, 그 데이터는 GPT-4로 가공 후 필터링, 총 2,000개 샘플을 제작해서 사용했으며,
  5. 이게 chain구조로 된 꽤 어려운 task이기 때문에 각 단계마다 학습률을 다르게 설정하여 모델이 점진적으로 긴 추론 경로를 생성할 수 있도록 유도하는 '점진적 학습 방법'이라는 걸 적용했다. 
  6. 그래서 실험을 해 보니 원하는대로 문제점이 잘 해결되더라!
 

Self-Reasoning Framework

전체 프로세스를 논문 Figure 2에 해당하는 아래 도식과 함께 이해하는 것이 좋음

 


RAP(Relevance-Aware Process)

instructs the LLM to judge the relevance between the retrieved documents and the question

LLM이 검색된 문서와 질문의 관련성을 평가하도록 instruct

  • 본 연구에서 top-k relevant documents를 가져오는 리트리버는 DPR()과 Contriever을 사용하였음
  • LLM이 직접 retrieved된 문서 D와 주어진 질문 q와의 관련성을 판단(T/F)하고, 그에 대한 이유를 생성하게 한다. 도표에 보이는 것처럼 각각 RelevantRelevant Reason으로 생성됨.
  • 만약 가져온 문서중에 관련 있는 문서가 하나도 없으면, LLM이 가지고 있는 내부 지식을 바탕으로 답변하는 수밖에 없음.
4.4 데이터 생성 및 품질 관리 (Data Generation and Quality Control)에 따르면, RAP단계를 위해 GPT-4로 ground truth에 해당하는 label data를 생성했다고 한다. Relevant가 True일 때에 해당하는 Positive samples뿐만 아니라 False일 때 Relevant Reason으로 why the given documents cannot answer the question - 찾아진 문서가 왜 질문에 답할 수 없는지도 답할 수 있는 Negative samples 데이터까지 균형 있게 만들었다고 함.

EAP : Evidence-Aware Selective Process

directs the LLM to choose and cite relevant documents, and then automatically select snippets of key sentences as evidence from the cited documents

LLM이 관련 문서를 선택하고 인용할 때, 인용한document로부터 snippets of key sentences를 증거로 선택하도록 direct

즉, 검색된 문서 중에서 질문에 가장 관련이 있는 문서를 우선적으로 선택하고, "증거" 문장과 함께 해당 문장이 왜 답변에 도움이 되는지에 대한 이유를 생성하도록 유도

  • We define the selected sentence as evidence in our paper - 관련성 있는 문서로부터 찾아낸 질문과 관계 있는 구절을 본 논문에서는 ‘evidence’라고 부름. snippets of key sentences이라고도 함. EAP 단계에서는 그 Evidence를 찾아내도록 먼저 명령을 함. 이게 곧 도식에서 cite content에 해당.
  • the reason why the selected snippets can answer the question - 증거를 찾았으면, 다음 단계로는 그 증거가 왜 질문에 대한 답변이 될 수 있는지에 대한 이유를 생성하도록 함. 이는 도식에서 reason to cite에 해당.

Trajectory Analysis Process, TAP (궤적 분석 프로세스)

requires the LLM to generate a concise analysis based on all gathered self-reasoning trajectories generated by previous two processes and subsequently provide the final inferred answer.

앞의 두 과정에서 생성된 자체 추론 궤적(self-reasoning trajectories)을 분석하여 최종 답변 생성

앞의 두 과정에서 생성된 관련성 및 증거 선택 정보를 기반으로 요약된 분석을 생성하고, 최종적으로 질문에 대한 답을 도출

  • TAP단계에서는 we ask the LLM to analyze the reasoning trajectories within itself - 지금까지 RAP, EAP 단계에서 생성한 모든 것들을 종합해서 Analysis를 최종 출력하고, and ultimately to output a concise analysis and a short answer - 최종 답변을 짧고 명확하게 도출하도록 유도함.
  • 즉 최종 답변은 analysis와 answer, 두 가지 형태로 출력되는데,
  • the analysis output is defined as a longform answer - analysis를 ‘롱폼 답변'으로,
  • and the answer output is defined as a short-short answer - answer를 ‘숏폼 답변’으로 생각함.

마무리

실험 결과 Self-Reasoning 프레임워크는 소량의 학습 데이터(2,000개 샘플)로도 효율적인 성능을 낼 수 있음을 입증하였고

각 단계(RAP, EAP, TAP)의 개별 효과를 평가했을 때 세 가지 단계가 모두 포함된 완전한 Self-Reasoning 프레임워크가 가장 높은 성능을 나타냈다고 하는데, 특히 RAP를 제거하면 특히 사실 검증 정확도가 크게 떨어져, 관련 문서 필터링이 매우 중요함을 확인했다고 한다.

인용의 정확성과 재현율을 평가하기 위해 사람의 평가와 비교했을 때 유사한 점이 있어서 이는 Self-Reasoning이 인용의 신뢰성을 높이는 데 효과적임을 시사했다고 한다.

공식 깃허브나 코드 등이 공개되지 않아 조금 아쉽고, 실험한 모델이 좀 철 지난 모델들인 점이 또 아쉽지만, 원하는 task에 맞게 체인 형태의 논리 구조로 데이터를 가공하고 고성능의 RAG를 유도하는 아이디어 자체는 reference로 차용하기 좋은 논문인 것 같다.

끝!

https://arxiv.org/pdf/2005.11401

pre-train된 LLM은 학습한 시점 이후의 데이터를 가지고 있지 않기때문에 outdated된 정보를 제공할 수 있으며 특히 domain-specific한 지식이 부족한 단점을 가지고 있습니다. 이를 보완하기 위해 주기적으로 LLM을 재학습시키거나 파인튜닝을 하는 방법이 고안되었지만 시간이나 비용적인 측면에서 비효율적이라는 문제점이 꾸준히 제기되어 왔습니다.

저 역시 domain-specific한 QA task를 실현하기 위해 LLM을 fine-tuning하고자 하는 시도를 하였지만 생각만큼 성능이 잘 확보되지 않으며 오히려 기존에 학습된 파라미터가 fine-tuning을 통해 망가지면서 답변 생성 성능이 저하되는 것을 여러번 경험한 바가 있습니다. 이럴 때 필요한 것이 RAG - Retrieval-Augmented Generation - 검색 증강 생성으로, LLM을 더 잘 활용하기 위해 널리 사용되고 있는 기술입니다.

RAG는 새로운 정보를 벡터 데이터베이스에 저장하고, 쿼리를 받았을때 데이터베이스에서 검색을 실행합니다. 이후 반환받은 관련 정보를 쿼리에 함께 담아 넘겨주면서 context 정보를 구체적으로 제공함으로써 기존의 문제점을 해결하고자 도모합니다.

본 포스팅에서는 RAG에 관해 처음으로 언급한 논문 <Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks>를 읽고 주요 내용을 리뷰해 보도록 하겠습니다.


Abstract

Large pre-trained language models have been shown to store factual knowledge in their parameters, and achieve state-of-the-art results when fine-tuned on downstream NLP tasks. However, their ability to access and precisely manipulate knowledge is still limited, and hence on knowledge-intensive tasks, their performance lags behind task-specific architectures. Additionally, providing provenance for their decisions and updating their world knowledge remain open research problems. (중략)

LLM은 많은 NLP task에서 SoTA 성능을 보여주며 다양하게 활용되어 왔지만, 지식을 습득하고 조종하는 부분에 있어 여전히 많은 한계점을 가지고 있습니다. 저 역시 개인적인 목적으로 GPT4.0등을 활용할 때와 달리 프로젝트를 위해 오픈소스 LLM 등을 활용할 때 특히 그러한 한계점을 많이 체감하게 되곤 했는데요. 특히 task-specific한 구조로 인해서 knowledge-intensive한 task에 있어서는 취약한 점이 많았죠. 나아가 결정에 대한 출처를 제공하는 일, 기존의 지식을 업데이트하는 일은 여전히 미해결 연구 문제로 남아 있었다고 합니다.

We explore a general-purpose fine-tuning recipe for retrieval-augmented generation (RAG)models which combine pre-trained parametric and non-parametric memory for language generation. We introduce RAG models where the parametric memory is a pre-trained seq2seq model and the non-parametric memory is a dense vector index of Wikipedia, accessed with a pre-trained neural retriever.

해당 논문에서는 2가지 종류의 knowledge를 사용하고 있습니다.

  • Parametric knowledge : 모델이 사전에 학습한 파라미터 정보
  • Non-parametric knowledge : retriever를 이용하여 외부 문서로부터 가져오는 파라미터 정보 (논문에서는 Wikipedea 활용)

그런데 논문에서 말하는 general-purpose fine-tuning recipe for RAG란 무엇일까요?

이어서 살펴보겠지만 RAG 모델의 파인튜닝은 리트리버와 생성기를 함께 엔드-투-엔드로 학습하여 모델을 최적화하는 과정을 의미합니다. 오늘날 우리가 RAG를 구현할 때는 이미 학습된 리트리버와 생성기를 LangChain과 같은 라이브러리에서 가져다 사용하기 때문에 별도의 파인튜닝 과정은 사실 필요 없습니다. 덕분에 보다 손쉽게 RAG 기능을 구현할 수 있는 것이죠. 물론 파인튜닝을 추가해서 더 고도화된 모델을 구현할 수도 있겠지만요.

We compare two RAG formulations, one which conditions on the same retrieved passages across the whole generated sequence, and another which can use different passages per token. (중략) For language generation tasks, we find that RAG models generate more specific, diverse and factual language than a state-of-the-art parametric-only seq2seq baseline.

본 논문에서는 2가지의 RAG 포뮬라를 비교 제시하는데요. 하나는 생성된 전체 시퀀스에 걸쳐 동일한 검색된 구절을 조건으로 하고, 다른 하나는 토큰당 다른 구절을 사용합니다. 이를 통해 생성 작업에 있어서 RAG 모델이 더 구체적이고 다양하며 사실에 기반한 언어를 생성한다는 사실을 발견했다고 합니다.


1 Introduction

They cannot easily expand or revise their memory, can’t straightforwardly provide insight into their predictions, and may produce “hallucinations”. (중략) 

기존의 Pre-train된 neural language model들은 파라미터에 저장된 정보를 이용하여 훌륭한 답변을 생성해 내곤 하였는데요. 하지만 이러한 모델들은 기억을 쉽게 확장하거나 수정할 수 없는 단점, 예측에 대한 통찰력을 직접적으로 제공할 수 없는 단점, 그리고 가장 치명적으로 "환각(Hallucinations)"을 일으킬 수 있는 단점을 가지고 있었습니다.

The retriever (Dense Passage Retriever [26], henceforth DPR) provides latent documents conditioned on the input, and the seq2seq model (BART [32]) then conditions on these latent documents together with the input to generate the output. We marginalize the latent documents with a top-K approximation, either on a per-output basis (assuming the same document is responsible for all tokens) or a per-token basis (where different documents are responsible for different tokens). Like T5 [51] or BART, RAG can be fine-tuned on any seq2seq task, whereby both the generator and retriever are jointly learned.

Retriever는 인풋을 받아 latent documents을 제공하고, seq2seq 모델은 이러한 문서들을 묶어서 출력을 생성합니다. RAG는 잠재 문서(latent documents)들 중에서 상위 K개의 문서를 선택(top-K approximation)하여 이 문서들에 기반해 출력을 생성하는데, 이 과정은 두 가지 방식으로 이루어질 수 있습니다. 예시 질문 "팥빙수를 맛있게 만드는 방법은?"을 가지고 각각의 방법이 어떻게 사용되는지 구체화 해보도록 하겠습니다.

  1. 출력 단위로(per-output basis): 하나의 문서가 모든 토큰에 대해 사용된다고 가정.
    • 모델이 가장 관련성 높은 문서 1개를 찾습니다. 예를 들어, 한 문서가 '팥빙수 레시피' 전체를 담고 있다고 가정합니다. 그 문서에서 얻은 모든 정보를 바탕으로 답변을 생성합니다.
    • 답변: "팥빙수를 맛있게 만들려면, 먼저 팥을 준비하고, 얼음을 갈아 위에 얹습니다. 그 다음, 연유와 다양한 토핑을 추가합니다."
  2. 토큰 단위로(per-token basis): 각 토큰이 서로 다른 문서에 의해 지원될 수 있음.
    • 모델이 여러 문서를 찾습니다. 만약 한 문서는 '팥 조리법'을 설명하고, 또 다른 문서는 '팥빙수 토핑 아이디어'를 제공한다면, 각 단어(토큰)를 생성할 때 가장 적절한 문서에서 해당하는 정보를 가져옵니다. 예를 들어, 첫 번째 문서에서 "팥을 준비하고" 정보를 가져오고, 두 번째 문서에서 "얼음을 갈아 얹고" 정보를 가져오며, 세 번째 문서에서 "연유와 다양한 토핑을 추가합니다" 정보를 가져옵니다.
    • 답변: "팥을 준비하고, 얼음을 갈아 얹고, 연유와 다양한 토핑을 추가합니다.
Crucially, by using pre-trained access mechanisms, the ability to access knowledge is present without additional training.

특히 RAG 모델에서 리트리버와 생성기를 사전 학습된 상태로 사용하기 때문에 별도의 추가 학습 과정 없이도 외부 지식을 효과적으로 사용할 수 있다는 것을 강조하고 있습니다. 보통 RAG를 실현할 때 langchain같은 라이브러리에서 사전 학습된 리트리버와 생성기를 간단하게 가져다 쓰기만 하면 되는 것처럼, 무척 편리한 기능 구현이 가능한 것이 바로 RAG의 핵심이기도 하죠.

Finally, we demonstrate that the non-parametric memory can be replaced to update the models’ knowledge as the world changes.

non-parametric memory의 경우에는 업데이트가 가능하기 때문에 유지보수를 통해 최신 정보를 반영하고 정확도를 개선할 수가 있겠습니다.


2 Methods

We explore RAG models, which use the input sequence x to retrieve text documents z and use them as additional context when generating the target sequence y.

RAG 모델은 입력 시퀀스 를 사용하여 텍스트 문서 를 검색하고, 이를 추가 컨텍스트로 활용하여 목표 시퀀스 를 생성합니다.


Figure 1.

  1. Query Encoder (q(x)): 입력된 질문(query)을 벡터 형태로 인코딩합니다.
  2. Retriever (Non-Parametric Memory): 인코딩된 질문을 기반으로 최대 내적 탐색(MIPS)을 사용하여 top-K 문서들을 찾습니다. (주어진 질문 x에 대해 상위 K개의 텍스트 구절 분포를 반환)
  3. Document Index (d(z)): 검색된 문서들의 벡터 인덱스입니다.
  4. Generator (Parametric Memory): 선택된 문서들(z)을 입력으로 받아 최종 출력을 생성합니다. 본 논문의 경우 seq2seq 모델(BART)을 채택하고 있습니다.
  5. Marginalize: 여러 문서들로부터 얻은 출력을 종합하여 최종 답변(y)을 도출합니다. 다양한 문서에 대해 seq2seq 예측을 주변화(marginalize)합니다.

이처럼 RAG 모델은 질문을 인코딩하여 관련 문서를 검색하고, 이를 바탕으로 답변을 생성합니다. 그렇다면 RAG는 retriever와 generator를 어떻게 학습시켰을까요?

To train the retriever and generator end-to-end, we treat the retrieved document as a latent variable. We propose two models that marginalize over the latent documents in different ways to produce a distribution over generated text. In one approach, RAG-Sequence, the model uses the same document to predict each target token. The second approach, RAG-Token, can predict each target token based on a different document.

RAG는 retrieved된 document를 latent variable로 취급한다고 명시하고 있습니다. 본 논문에서는 이와 같은 latent document에 대해 다른 방식으로 marginalization하는 두 가지 모델을 제안합니다.

  1. RAG-Sequence 모델 : Same document를 사용하여 each target token을 예측
  2. RAG-Token 모델 : Different document를 사용하여 each target token을 예측

RAG-Sequence 모델

 

하나의 문서 z에 대해 전체 시퀀스 의 모든 토큰 yi에 대한 확률을 계산합니다. 모든 top-K 문서에 대해 이 과정을 반복한 후, 최종 값을 주변화(marginalize)하여 계산합니다. 즉, 각 문서에 대해 시퀀스 전체를 고려하여 최종 출력을 생성합니다.

RAG-Token 모델

RAG-Token model은 RAG-Sequence와 다르게 각 토큰 yi를 생성할 때마다 모든 top-K 문서에 대해 확률을 계산하고, 그 후 주변화(marginalize)하여 최종 출력을 생성합니다. 즉, 각 토큰에 대해 개별 문서를 고려하여 출력을 생성합니다.

Retriever: DPR

앞서 언급한 바와 같이 RAG에서는 retriever 𝑝𝜂(𝑧|𝑥)로 DPR을 사용합니다. DPR은 기본적으로 bi-encoder 구조 - 사전 학습된 BERT 기반 인코더를 사용하여 리트리버를 초기화하고 문서 인덱스를 구축합니다.

https://arxiv.org/pdf/2004.04906

DPR은 논문 <Dense Passage Retrieval for Open-Domain Question Answering>에서 고안한 방법으로, RAG 논문보다 1년 앞서 출간되었습니다. 나중에 기회가 되면 DPR 논문도 리뷰해 보도록 하겠습니다.

Calculating top-k(pη(·|x)), the list of k documents z with highest prior probability pη(z|x), is a Maximum Inner Product Search (MIPS) problem, which can be approximately solved in sub-linear time [23]

주어진 질문 x에 대해 가장 높은 사전 확률 을 가진 상위 K개의 문서 목록을 계산하는 것은 최대 내적 탐색(MIPS) 문제로 해결합니다. 즉, input x 에 대한 document z의 분포는 위에서 산출한 d(z) 와 q(x)의 내적 연산을 통해 계산되며, 이 내적 값이 높은 순서대로 top-k document를 골라 retrieve를 하게 되는데, 이 과정은 REALM에서 사용되었던 MIPS 알고리즘을 사용하여 효율적인(sub-linear time) 탐색을 가능하게 했다고 합니다.

Generator: BART

생성기로는 무엇을 사용해도 상관이 없으며 본 논문에서는 BART-large를 사용했다고 밝히고 있습니다. 

Training

We jointly train the retriever and generator components without any direct supervision on what document should be retrieved

DPR 기반의 리트리버와 BART-large 기반의 생성기는 학습 과정에서 동시에 학습됩니다. 이때, 어떤 문서가 검색되어야 하는지에 대한 직접적인 감독 없이 진행되는 비지도 학습(unsupervised learning) 방식이 적용됩니다. 오로지 출력 시퀀스에 대한 NLL(Negative marginal Log-Likelihood)을 최소화하는 방향으로 학습되며, 리트리버 또한 이 과정에서 NLL을 최소화하는 방향으로 학습됩니다.

Decoding

앞서 살펴본 두 가지 모델 RAG-Sequence와 RAG-Token은 각각 output 산출 방법이 다르므로 token decoding 하는 과정도 달라지게 됩니다.

  1. RAG-Token 모델 : 표준 시퀀스-투-시퀀스 생성기처럼 작동하며, 여러 문서의 확률을 합산하여 전이 확률을 계산합니다. 이를 표준 빔 디코더에 적용하여 디코딩합니다.
  2. RAG-Sequence 모델 : 각 문서에 대해 별도의 빔 서치를 실행하고, 최종 확률을 추정하기 위해 추가적인 forward pass를 실행합니다. 이를 "Thorough Decoding"이라 하며, 효율성을 위해 추가 패스를 생략하는 "Fast Decoding"도 있습니다.

이 때, 빔 서치는 가장 가능성 높은 N개의 후보를 유지하며 다음 토큰을 생성, 이 과정을 반복해 최종 출력 시퀀스를 생성하는 디코딩 방식을 의미합니다.

출처 : https://slideplayer.com/slide/14552918/


Experiment & Result

해당 부분은 GPT4.0-Turbo를 이용하여 핵심 내용 정리 요약 후 패스하도록 하겠습니다.

  1. Dense Passage Retriever (DPR): DPR은 dense encoding을 통해 질문과 패시지 간의 의미적 관계를 잘 파악합니다.
  2. 성능 비교: BM25와 비교한 실험에서 대부분의 데이터셋에서 DPR이 더 우수한 성능을 보였습니다.
  3. 효율성: 적은 수의 학습 예제로도 고품질의 dense retriever를 학습할 수 있습니다.
  4. 일반화 성능: 학습된 데이터셋 외에도 어느 정도 잘 작동하며, BM25보다 우월한 성능을 보입니다.
  5. 질적 분석: BM25는 키워드에 민감하고, DPR은 의미적 관계를 잘 파악합니다.
  6. 종합 성능: 대부분의 데이터셋에서 DPR이 최상의 성능을 냈습니다.

RAG의 가장 큰 장점은 parametric & non-parametric memory의 결합을 통해 보다 정확하고 다양한 정보를 생성할 수 있다는 점입니다. 이를 통해 기존의 파라미터를 대량 업데이트하거나 fine-tuning 하지 않으면서도 domain-specific한 downstream task을 잘 수행할 수 있는 모델을 구현할 수 있게 되었습니다. 특히 검색 인덱스를 간단히 교체하여 모델을 업데이트할 수 있다는 점에서 매우 효율적이고 유용한 기법이라고 할 수 있겠습니다.

본 논문을 읽기 전에 langchain을 이용하여 RAG을 이미 구현해 본 입장에서, 논문을 통해 핵심 아이디어와 학습 방안에 대해 구체화하고 더 깊이 이해할 수 있어 무척 좋은 기회였습니다. 앞으로 RAG를 다양한 응용 분야에 적용해보고, task에 따라 어떤 방식으로 알맞게 사용할 수 있는지 실험해 보는 과정을 거쳐 보고자 합니다.

읽어주셔서 감사합니다 :)

 

 

 

+ Recent posts