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가지로 제안함
- [파인튜닝 불필요❎] Retrieval Reordering ⭐⭐ ⭐
- [파인튜닝 필요✅] Implicit Robustness Fine-tuning ⭐ ⭐
- [파인튜닝 필요✅] 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) 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) 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"의 영향이 달라지는가? -> 예.
주요 인사이트
- 실험 결과 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)
- 높은 관련성을 가진 문서를 입력의 시작과 끝에 배치하도록 순서를 조정
- 구체적으로, 홀수 인덱스의 문서는 앞쪽에, 짝수 인덱스의 문서는 뒤쪽에 배치
- 최종 입력을 [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 시스템의 성능을 더욱 향상시키는 방법을 연구
마무리
논문을 읽고 제가 한 생각, 배운점, 느낀점 등을 간략히 정리하면 아래와 같습니다.
- Long context RAG의 경우 recall이 아주 높은 e5같은 retriever을 사용하는 것은 위험할 수 있으며, bm25같은 애들이 무난하게 작동할 수 있다. 어떤 Retriever를 선택하느냐도 항상 고민해야할 문제.
- RAG를 구현할 때 retrieval reordering을 통해 hard negatives는 중간에 배치하여 LLM이 덜 주목하게 하면 모델이 Long context를 잘 처리할 수 있다.
- 그치만 중요한 context가 중간에 배치되어도 정확하게 답변을 출력할 수 있는 능력도 결국엔 중요하지 않을까? 파인튜닝을 하지 않기 위해 RAG가 도입되었지만 결국 완벽한 RAG는 적절한 파인튜닝이 필수적으로 요구되는듯..
- 또 파인튜닝을 1단계로 하지 않고 2단계로 나누어서 처음에 ‘중간 추론 단계’라는 걸 넣어주면 좋다는데 이것은 자원의 한계를 고려해서 실행해야 할 듯 하다.
포스팅 내 잘못된 정보가 있다면 댓글 남겨주시기 바라며, 이번 포스팅을 읽어주셔서 감사합니다.
지금까지 사이언티스트 수리링이었습니다 :)
'Data Science > DL 딥러닝' 카테고리의 다른 글
딥러닝 | Retrieval Augmented Generation or Long-Context LLMs? - A Comprehensive Study and Hybrid Approach(2024) 논문 리뷰 (1) | 2024.10.31 |
---|---|
딥러닝 | Improving Retrieval Augmented Language Model with Self-Reasoning(2024) 논문 리뷰 (0) | 2024.10.29 |
딥러닝 | RAG(2021) 논문 리뷰 (0) | 2024.08.05 |
딥러닝 | 효율적인 파인튜닝에 관한 고찰 - LoRA(2021) 논문 리뷰, peft, unsloth (0) | 2024.08.01 |
딥러닝 | RAG 활용 pdf파일 검색 챗봇시스템 구현하기 (4) | 2024.07.24 |