[논문 리뷰]Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity
1. Introduction
기존의 RAG 기반 파이프라인은 모든 질의에 동일한 검색 전략을 적용하여, 단순한 질의에는 과도한 계산을, 복잡한 질의에는 부족한 정보를 제공할 수 있는 문제가 존재합니다.
2. Adaptive-RAG의 제안
이에 저자는 sLLM을 분류기로 질의의 복잡도를 판단하여 아래의 세 가지 전략 중 하나를 선택합니다.
- No Retrieval: 단순한 질의는 검색 없이 LLM만으로 처리
- Single-Step Retrieval: 중간 복잡도의 질의는 한 번의 검색으로 처리
- Multi-Step Retrieval: 복잡한 질의는 여러 단계의 검색과 추론을 통해 처리
3. Training Strategy
질의 복잡도에 대한 라벨이 포함된 공개 데이터셋이 존재하지 않아 논문에서는 두 단계의 자동 라벨링 전략을 제안합니다.
- 답변 생성 기반 라벨링
각 질문에 대해 위의 세 가지 접근법을 시도하고, 성공 여부에 따라 라벨을 부여합니다.- 비검색 기반 LLM이 정답을 생성했을 경우 → A
- 비검색 기반 답변에 실패했하고 단일 검색이 정답을 생성한 경우 → B
- 다단계 검색만이 정답 생성 경우 → C
→ 두 전략이 모두 정답을 생성한 경우 더 단순한 전략에 우선 순위를 두기에 B가 됩니다.
- 데이터셋 구조 기반 라벨 보완
모두 실패하여 라벨이 지정되지 않은 경우, 데이터셋의 특성(단일/다중 hop 기반)에 따라 라벨을 보완합니다. 논문에서는 벤치마크 QA 데이터셋 자체가 생성 방식에 따라 특정 검색 전략에 대한 유의미한 편향을 이미 내포하고 있다고 가정합니다.
예를 들어 순차적 추론을 요구하는 QA 데이터셋은 일반적으로 다단계 검색(multi-step approach)이 필요하고,
단일 문서에 정답이 라벨링된 질의는 단일 검색(single-step)으로 해결 가능한 경우가 많습니다.- 단일 hop QA 데이터 → B
- 다중 hop QA 데이터 → C
최종적으로 이렇게 구축된 질의–복잡도 쌍을 사용해 분류기를 Cross-Entropy Loss로 학습합니다.
4. 실험
데이터셋
단일 hop QA: SQuAD v1.1, Natural Questions, TriviaQA
멀티 hop QA: MuSiQue, HotpotQA, 2WikiMultiHopQA
모델
- Simple 접근: No Retrieval, Single-step Retrieval
- Adaptive 접근: Adaptive Retrieval, Self-RAG, Adaptive RAG(본 논문)
- Complex 접근: Multip-step Approach(SOTA 다단계 검색, CoT 포함)
여기서 Adaptive Rretrieval은 질의의 특성에 따라 검색 여부만 검사(single 전략)하는 것이고, Self-RAG는 LLM이 답변에 대해 평가하고 고치는 형식입니다. 둘 다 난이도나 multi에 대한 고려가 없다는 점이 본 논문과의 차이점입니다.
평가지표
정확도: F1, EM, Accuracy
효율성: Retrieval & Generation 횟수, 1-step 방법 대비 평균 응답 시간
구현 세부 사항
- Retriever: 모든 모델에서 동일하게 sparse 기반의 BM25 사용
- Corpus
- 단일-hop: Wikipedia (Karpukhin et al., 2020)
- 다중-hop: Trivedi et al., 2023에서 전처리된 corpus
- LLMs
- FLAN-T5 XL (3B) 및 XXL (11B)
- GPT-3.5-turbo-instruct
- Adaptive-RAG 분류기
- T5-Large 모델 사용
- 학습 시: 6개 데이터셋에서 총 400개의 질의를 추출해 라벨링 (단일-hop → B, 다중-hop → C)
- 3가지 전략을 통해 라벨 예측 → 겹치지 않도록 테스트 질의와 분리
- 학습 방식: 최적 epoch까지, learning rate 3e-5, 옵티마이저는 AdamW 사용
분석
결론: 쓸데없는데서 자원을 아끼고 필요할 때 쓸 수 있도록 분류기를 사용하자.
나의 결론: 시간이 있다면 Classifier를 만들어서 해보는 것도 좋은 방법이겠으나 LangGraph 기반 Agentic RAG 아키텍처를 구성하는게 낫지 않나 생각이 들었습니다.