LongRAG 논문 정리

---

source_paper: "LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs"
paper_id: "arXiv:2406.15319v3"

---

LongRAG 논문 정리

한 줄 요약
기존 RAG는 짧은 chunk를 너무 많이 찾아야 해서 retriever가 과하게 무거운 구조였다.
LongRAG는 retrieval unit 자체를 길게 만들고, long-context LLM이 그 안에서 답을 찾게 해서 retriever와 reader의 역할 균형을 다시 맞춘다.

논문 정보

• 제목: LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs
• 저자: Ziyan Jiang, Xueguang Ma, Wenhu Chen
• 소속: University of Waterloo
• 버전: arXiv v3, 2024-09-01

---

이 논문이 던지는 핵심 문제

기존 RAG는 보통 100단어 안팎의 짧은 passage를 retrieval unit으로 쓴다.
이 방식에서는 retriever가 수천만 개에 가까운 작은 조각 중에서 정확한 “needle”을 찾아야 한다. 반면 reader는 이미 잘 골라진 짧은 조각 몇 개만 읽으면 되므로 상대적으로 일이 가볍다.

저자들의 문제의식은 간단하다.

1. retriever가 너무 힘들다.
2. 짧게 잘린 chunk는 문맥을 잃기 쉽다.
3. 최근 long-context LLM은 훨씬 더 긴 입력을 다룰 수 있는데, 기존 RAG 설계는 이 능력을 충분히 쓰지 못한다.

즉, 이 논문은 “retrieval granularity를 지금도 너무 작게 잡고 있는 것 아닌가?”라는 질문을 던진다.

---

LongRAG의 핵심 아이디어

LongRAG는 이름 그대로 long retriever + long reader 구조다. 핵심은 세 가지다.

1) Long Retrieval Unit

기존 RAG가 짧은 passage를 검색 단위로 썼다면, LongRAG는 4K 토큰 이상의 긴 retrieval unit을 만든다.

• 문서가 이미 길면 문서 전체를 하나의 unit으로 사용
• 문서가 짧으면 관련 문서 여러 개를 묶어서 하나의 unit으로 사용
• 위키피디아 계열 실험에서는 하이퍼링크 기반으로 관련 문서들을 그룹화

이렇게 하면 검색 대상 개수가 크게 줄어든다.
저자들은 NQ에서 corpus를 22M passage → 600K grouped documents, HotpotQA에서 5.2M documents → 500K grouped documents 수준으로 압축했다고 보고한다.

2) Long Retriever

Long retriever의 목표는 더 이상 “정확히 정답 chunk 하나를 찍는 것”이 아니다.
대신 대략적으로라도 관련 정보가 충분히 들어 있는 큰 묶음을 잘 가져오는 데 초점을 둔다.

중요한 포인트는 다음이다.

• top-100, top-200처럼 많은 short chunks를 reader에게 넘기지 않는다.
• 보통 1~8개 정도의 긴 unit만 가져온다.
• re-ranker 없이도 강한 recall을 확보하려고 설계한다.

이 논문이 강조하는 메시지는 분명하다.

RAG의 성능은 “얼마나 많이 가져오느냐”보다 “얼마나 덜 헷갈리게 가져오느냐”가 더 중요할 수 있다.

3) Long Reader

reader는 retrieved context를 길게 받는다.
논문에서는 주로 Gemini-1.5-Pro와 GPT-4o 같은 long-context LLM을 사용한다.

reader는 2단계로 동작한다.

1. 긴 context를 보고 long answer를 먼저 생성
2. 그 long answer에서 짧은 최종 답(short answer) 을 다시 추출

저자들은 긴 context에서는 처음부터 너무 짧은 답만 강요하면 성능이 떨어질 수 있어,
“길게 생각한 뒤 짧게 정리하는 방식”이 더 잘 동작한다고 설명한다.

---

Figure 1로 보는 논문의 전체 메시지

 

Figure 1. Traditional RAG와 LongRAG의 개념 비교 및 NQ/HotpotQA 성능 비교 (원논문 Figure 1, p.2).

이 그림은 논문의 주장을 가장 압축적으로 보여준다.

• 위쪽:
  • Traditional RAG는 짧은 unit을 많이 검색하고, ranking까지 거친 다음 reader로 보낸다.
  • LongRAG는 긴 unit 몇 개만 가져와서 long reader가 처리한다.
• 아래쪽:
  • NQ에서는 LongRAG가 62.7 EM까지 올라간다. 이는 fully-trained Atlas의 64.0에 근접한다.
  • HotpotQA에서는 LongRAG가 64.3 EM을 기록한다. fully-supervised COS의 68.2보다는 낮지만, no fine-tuning 계열 대비 상당히 강하다.

Figure 1에서 읽어야 할 포인트

• 이 논문은 “retriever를 더 복잡하게 만들자”가 아니라 retriever 부담을 줄이자는 방향이다.
• LongRAG의 장점은 학습 없이도 강한 성능을 낸다는 점이다.
• 완전한 SoTA를 모두 넘어선 것은 아니지만, 학습 없는 설정치고는 매우 강한 결과를 보여준다.

---

Figure 2로 이해하는 LongRAG 동작 예시

 

Figure 2. HotpotQA 스타일 질문에서 LongRAG가 어떻게 동작하는지 보여주는 예시 (원논문 Figure 2, p.4).

이 예시는 논문의 직관을 아주 잘 보여준다.

질문은 대략 이런 형태다.

“2015 AFL Rising Star 수상자의 키는 얼마인가?”

 

전통적인 RAG는 짧은 단위로 끊긴 문서를 여러 개 가져오다가, 관련은 있지만 엉뚱한 선수 문서 같은 hard negative를 섞어 reader를 헷갈리게 만들 수 있다.
반면 LongRAG는 2015 AFL Rising Star, Jesse Hogan, Australian Football League 같이 서로 연결된 문서를 하나의 긴 retrieval unit 안에 묶어서 넘긴다.

이 그림의 핵심 해석

• multi-hop QA는 short chunks를 많이 모은다고 자동으로 잘 풀리지 않는다.
• 관련 문서가 하나의 묶음 안에 들어 있으면, long reader는 그 안에서 관계를 따라가며 답을 찾을 수 있다.
• 결국 LongRAG는 retrieval 단계에서 정답만 찍으려 하기보다, 정답에 도달할 수 있는 의미 있는 덩어리를 가져오는 전략이다.

---

LongRAG의 구현 포인트

논문에서 특히 흥미로운 부분은 긴 retrieval unit을 어떻게 임베딩하느냐다.

문서 전체가 4K~6K 토큰 이상이면, 그 긴 텍스트를 한 번에 벡터 하나로 잘 표현하기가 어렵다.
그래서 저자들은 긴 unit 전체를 직접 인코딩하는 대신 다음과 같은 근사를 쓴다.

• retrieval unit 내부를 여러 chunk로 나눈다.
• query와 각 chunk의 유사도를 계산한다.
• 그중 최대값(max) 을 해당 long unit의 점수로 본다.

즉,
“긴 문서 전체를 한 번에 표현하는 대신, 내부 조각들 중 가장 query와 잘 맞는 부분을 대표값으로 삼는다.”

논문 Table 4는 이 근사가 꽤 중요하다는 점을 보여준다.

• BGE-Large + 512-token chunk max scoring: AR@1 71.7
• E5-Mistral-7B + 4K chunk: AR@1 54.2
• E5-Mistral-7B + entire grouped unit: AR@1 23.4

여기서 얻는 인사이트는 분명하다.

“long embedding model이 있다고 해서 긴 retrieval이 바로 잘 되는 것은 아니다.”
현재 시점에서는 오히려 짧은 조각 단위 점수의 max approximation이 더 강하게 동작했다.

---

실험 세팅 한눈에 보기

Dataset	Corpus source	평균 문서 길이	문서 수	QA 케이스 수	Metric
NQ	Wikipedia	800 tokens	3M	3,610	EM
HotpotQA	Wikipedia	130 tokens	5.2M	7,405	EM
Qasper	Science papers	4.7K tokens	416	371	F1
MultiFieldQA-en	Multi-field documents	6.9K tokens	150	150	F1

 

이 표가 의미하는 바는 크다.

• NQ / HotpotQA: 문서가 짧고 corpus가 아주 크다.
  → LongRAG는 문서를 묶어서 retrieval unit을 크게 만드는 전략이 중요하다.
• Qasper / MultiFieldQA-en: 문서 자체가 이미 길다.
  → LongRAG는 문서 전체를 하나의 retrieval unit으로 쓰는 전략이 자연스럽다.

---

핵심 결과 요약

1) Retrieval 성능: 긴 unit 몇 개로도 충분히 강하다

NQ

• Passage-level, 1개 retrieval: AR 52.24
• Grouped documents, 1개 retrieval: AR 71.69

즉, top-1 기준으로만 봐도 긴 unit이 훨씬 강하다.

또한,

• Passage 100개: AR 89.92
• Grouped documents 8개: AR 88.53

비슷한 recall을 얻는 데 필요한 unit 수가 극적으로 줄어든다.

HotpotQA

• Document 2개: R 30.01 / AR 47.75
• Grouped documents 2개: R 56.30 / AR 72.49

HotpotQA에서도 long retrieval unit이 retrieval 부담을 크게 줄인다.

---

2) End-to-End QA 성능: no fine-tuning인데도 강하다

Dataset	LongRAG 결과	비교 포인트
NQ	62.7 EM (GPT-4o, 4 units)	Atlas 64.0에 근접
HotpotQA	64.3 EM (GPT-4o, 8 units)	no fine-tuning 계열보다 강하고, fully-supervised SoTA에 근접
Qasper	26.3 F1 (Table 6 기준, 1 document)	100 passages의 22.6보다 높음
MultiFieldQA-en	57.5 F1 (5 documents)	100 passages의 51.3보다 높음

해석 포인트

• 이 논문의 가장 큰 장점은 “학습 없이도 성능이 나온다”는 점이다.
• 특히 위키 기반 QA에서 long-context LLM을 reader로 붙였을 때, 기존 no fine-tuning RAG보다 꽤 큰 폭으로 오른다.
• 긴 문서 기반 dataset에서는 짧게 쪼개는 것보다 문서 전체를 넣는 편이 더 낫다는 점을 보여준다.

주의해서 볼 점

Qasper 결과는 본문과 초록 사이에 약간의 숫자 차이가 있다.

• 초록: 25.9 F1
• Table 6 본문: 1 document 설정에서 26.3 F1, 2 documents 설정에서 25.9 F1

블로그에서는 이 차이를 숨기기보다,
“본문 표 기준 최고 수치는 26.3이고, 초록 요약에는 25.9가 적혀 있다”고 함께 적어두는 편이 더 정확하다.

---

Figure 3: 왜 긴 retrieval unit이 필요한가

 

Figure 3. retrieval unit 크기와 개수, reader context 길이에 따른 성능 변화를 보여주는 ablation (원논문 Figure 3, p.9).

이 그림은 LongRAG의 핵심 주장을 실험적으로 뒷받침한다.

왼쪽 그래프에서 볼 점

retrieval unit 크기별로, reader에 몇 개 unit을 넣는 것이 좋은지를 비교한다.

NQ에서는 대략:

• passage 단위는 100~200개 사이에서 꺾이고,
• document 단위는 5~10개,
• grouped documents는 4~8개 사이가 적절하다.

즉, 더 많이 넣는다고 계속 좋아지지 않는다.

오른쪽 그래프에서 볼 점

retrieval recall이 올라가도 end performance(EM)가 항상 같이 올라가지는 않는다.
이게 바로 저자들이 말하는 hard negatives 문제다.

짧은 chunk를 너무 많이 넣으면 recall 자체는 올라갈 수 있다.
하지만 reader 입장에서는 관련은 있어 보이지만 정답과 직접 관계없는 정보가 같이 들어와서 오히려 헷갈릴 수 있다.

이 figure의 핵심 메시지

RAG에서는 recall만 높다고 끝이 아니다.
reader가 감당할 수 있는 문맥 길이 안에서 덜 헷갈리는 retrieval이 중요하다.

저자들은 reader에 들어가는 적정 context 길이가 대략 30K tokens 전후라고 설명한다.
이 부분은 실무적으로도 시사점이 크다.

---

Figure 4: 어떤 reader가 더 잘 읽는가

 

Figure 4. LongRAG에서 reader 모델별 성능 비교 (원논문 Figure 4, p.10).

NQ 200개 테스트 케이스 기준 비교 결과는 다음과 같다.

• Gemini-1.5-Pro: 59.5
• GPT-4-Turbo: 61.5
• GPT-4o: 62.0
• Claude-3-Opus: 61.0
• Claude-3.5-Sonnet: 60.0
• DeepSeek-V2-Chat: 51.0

Figure 4에서 얻는 인사이트

• LongRAG의 성패는 결국 reader의 long-context 이해력에 크게 좌우된다.
• 폐쇄형 상용 모델들은 서로 비슷하게 강하지만, 이 실험에서는 GPT-4o가 가장 좋다.
• 오픈소스 reader는 아직 격차가 꽤 있다.

즉, LongRAG는 retrieval 설계만의 문제가 아니라 “긴 문맥을 실제로 잘 읽는 모델이 있는가”와도 강하게 연결된다.

---

이 논문에서 정말 중요한 5가지 포인트

1) RAG의 병목은 retriever일 수 있다

기존 RAG는 너무 작은 조각을 너무 많이 찾아야 한다.
LongRAG는 이 구조를 바꿔 retriever의 검색 공간을 줄인다.

2) retrieval unit의 크기는 단순 하이퍼파라미터가 아니다

이 논문은 retrieval granularity를 시스템 설계의 핵심 변수로 끌어올린다.

3) 긴 문맥은 단순히 “많이 넣는 것”과 다르다

LongRAG의 장점은 긴 context 자체보다,
의미가 보존된 단위로 긴 context를 구성한다는 데 있다.

4) recall과 최종 QA 성능은 다르다

short chunks를 많이 넣으면 recall은 오를 수 있다.
하지만 hard negatives 때문에 EM/F1은 오히려 떨어질 수 있다.

5) long-context 시대의 RAG는 설계를 다시 해야 한다

이 논문이 던지는 가장 큰 메시지는 이것이다.

“long-context LLM이 등장했는데도, 왜 retrieval 단위는 예전처럼 지나치게 짧게 유지하고 있는가?”

---

한계와 주의할 점

1) 평가 지표 해석은 조심해야 한다

논문은 LongRAG 평가에서 refined EM을 사용한다.
짧은 alias 형태의 정답도 맞다고 인정하기 위한 수정인데, 저자들은 이것이 더 공정하다고 설명한다.

이 자체는 타당한 문제의식이지만, 블로그에서는
“표준 EM을 약간 수정한 버전”이라는 점을 함께 적어두는 편이 좋다.

2) 강한 reader에 많이 의존한다

LongRAG는 GPT-4o, Gemini-1.5-Pro 같은 강한 long-context LLM이 있을 때 특히 빛난다.
즉, retrieval 설계가 좋아도 reader가 길게 읽지 못하면 성능이 제한된다.

3) 문서 그룹핑 전략은 데이터셋 의존적일 수 있다

위키피디아에서는 하이퍼링크를 이용해 관련 문서를 묶을 수 있다.
하지만 모든 실무 corpus에 이런 구조가 있는 것은 아니다.

4) 완전한 SoTA를 모두 넘어선 것은 아니다

NQ와 HotpotQA에서 강한 성능을 보여주지만, fully-supervised 최고 성능을 항상 이기지는 않는다.
따라서 이 논문의 포인트는 “항상 최고 점수”보다 “학습 없이도 구조적 개선만으로 강하다”에 가깝다.

---

핵심 문장

• LongRAG의 핵심은 더 많은 chunk를 찾는 것이 아니라, 더 덜 잘못된 긴 문맥을 가져오는 것이다.
• 기존 RAG가 ‘정답 조각 찾기’에 가깝다면, LongRAG는 ‘정답에 도달할 수 있는 문맥 묶음 찾기’에 가깝다.
• long-context LLM 시대에는 retrieval unit의 크기부터 다시 설계해야 한다.
• RAG에서는 recall이 높아도 hard negative가 많아지면 최종 답변 성능은 오히려 떨어질 수 있다.
• LongRAG는 retriever를 더 무겁게 만드는 대신, reader가 더 잘 일하도록 역할을 재배치한 접근이다.

---

발표 / 리뷰용 결론

LongRAG의 메시지는 단순하다.

• 기존 RAG는 짧은 unit을 너무 많이 다뤄서 retriever에 과부하가 걸렸다.
• long-context LLM이 등장한 지금은, retrieval unit을 길게 만들고 reader가 더 많은 문맥을 읽게 하는 설계가 가능하다.
• 실제로 긴 retrieval unit은 corpus 압축, recall 개선, hard negative 감소, end-to-end 성능 향상으로 이어진다.

이 논문은 단순히 성능 수치만 보여주는 것이 아니라,
“RAG 시스템을 설계할 때 무엇을 가장 먼저 다시 봐야 하는가”를 잘 짚어 준다.

가장 중요한 takeaway는 이 문장으로 정리할 수 있다.

LongRAG는 RAG의 미래가 ‘더 정교한 reranking’보다 ‘더 나은 retrieval granularity’에 있을 수 있음을 보여준다.

---

참고 메모

• 모든 figure는 업로드된 PDF에서 직접 crop한 이미지다.
• figure 설명은 블로그용으로 재서술했다.
• 수치는 논문 본문 표와 그림을 기준으로 정리했다.
  다만 Qasper처럼 초록과 본문 표의 값이 약간 다른 경우는 본문에서 별도로 명시했다.