RAG 컨텍스트를 68% 줄이면서도 96%의 Recall을 유지한 방법: LLM 기반 Context Pruning

RAG(Retrieval-Augmented Generation)는 대규모 문서와 기술 문서를 기반으로 정확한 답변을 생성하는 AI 시스템에서 핵심적인 역할을 합니다. 하지만 검색된 문서를 모두 LLM에 전달하는 방식은 비용 증가와 컨텍스트 낭비라는 문제를 함께 가져옵니다.

이번 글에서는 Kapa가 이러한 문제를 해결하기 위해 Retriever와 Generator 사이에 'Context Pruning' 단계를 추가한 사례를 소개합니다. 작은 LLM이 실제 답변에 필요한 문서만 선별하도록 하여, 전체 컨텍스트의 약 68%를 제거하면서도 약 96%의 Recall을 유지하고, 결과적으로 질의 비용을 약 3분의 1 절감한 방법을 살펴보겠습니다.

반응형

---

기존 RAG 파이프라인의 구조

일반적인 RAG 시스템은 다음과 같은 흐름으로 동작합니다.

사용자 질문
        │
        ▼
 Retriever
(Embedding + Keyword Search)
        │
        ▼
   Reranker
        │
        ▼
 Generator (LLM)
        │
        ▼
      답변 생성

Retriever는 수십만 개 이상의 문서 조각(Chunk) 중 질문과 관련 있는 후보를 찾고, Reranker는 그 후보들의 우선순위를 정합니다.

이후 상위 약 15개의 Chunk가 Generator(LLM)에 전달되어 최종 답변이 생성됩니다.

---

문제점: 사용하지 않는 컨텍스트도 비용이 발생한다

Retriever는 높은 Recall을 목표로 하기 때문에 실제 답변에 필요하지 않은 문서도 함께 전달하는 경우가 많습니다.

즉,

• 필요한 정보
• 관련은 있지만 사용되지 않는 정보
• 거의 필요 없는 정보

가 모두 Generator에 전달됩니다.

LLM은 이러한 불필요한 정보를 무시할 수 있지만, 입력 토큰 비용은 그대로 발생합니다.

Kapa의 서비스에서는 검색된 Chunk가 전체 질의 비용의 약 3분의 2를 차지했습니다.

즉,

• 답변 생성 비용
• 대화 기록(Context)
• System Prompt

보다 Retrieval Context가 가장 큰 비용 요소였습니다.

또한 Agent 시스템에서는 Tool Call이 반복될수록 Context가 계속 누적되므로 불필요한 Chunk는 더욱 큰 문제가 됩니다.

---

단순히 Chunk를 줄이면 왜 안 될까?

가장 쉬운 방법은 Reranker Score를 기준으로 일정 점수 이하의 Chunk를 제거하는 것입니다.

예를 들어,

Score > 0.7
→ 유지

Score ≤ 0.7
→ 제거

처럼 사용할 수 있을 것처럼 보입니다.

하지만 실제로는 두 가지 문제가 있습니다.

첫 번째 문제: Rerank Score는 절대적인 점수가 아니다

Reranker의 점수는 순위를 결정하기 위한 값입니다.

즉,

• Chunk A가 Chunk B보다 관련성이 높다

는 의미일 뿐,

• Score가 0.8이면 항상 중요하다

는 의미는 아닙니다.

따라서 모든 질문에 동일한 Threshold를 적용할 수 없습니다.

---

두 번째 문제: Chunk는 개별적으로 평가할 수 없다

더 큰 문제는 Chunk의 중요성은 다른 Chunk와 함께 봐야만 판단되는 경우가 많다는 점입니다.

예를 들어,

첫 번째 Chunk는 Audit Log를 설명하고,

두 번째 Chunk는 권한 설정만 설명한다고 가정합니다.

두 번째 Chunk만 보면 질문과 직접적인 관련이 없어 보입니다.

하지만

첫 번째 Chunk와 함께 읽으면

답변을 완성하는 데 반드시 필요한 정보가 됩니다.

즉,

Chunk의 중요성은

"혼자 중요한가?"

가 아니라

"다른 Chunk와 함께 답을 만드는가?"

가 되어야 합니다.

기존 Pointwise Reranker는 각각의 Chunk를 독립적으로 평가하기 때문에 이러한 관계를 이해하지 못합니다.

---

Anchor Document 방식도 해결하지 못했다

Kapa는 또 다른 방법으로 Anchor Document 기법도 실험했습니다.

이 방식은

가상의 문서를 여러 개 만들어

예를 들어

• Essential
• Relevant
• Supporting
• Unrelated

수준의 문서를 함께 Ranking에 넣고,

실제 문서가 어느 Anchor보다 높은지 비교하는 방식입니다.

이론적으로는 점수를 절대적인 기준으로 보정할 수 있습니다.

하지만 실제 문제는 해결되지 않았습니다.

이유는 동일합니다.

Reranker는 여전히

각 Chunk를 개별적으로만 평가하기 때문입니다.

간접적으로 필요한 정보나 여러 Chunk가 함께 답을 구성하는 상황은 여전히 판단하지 못했습니다.

---

해결 방법: Retriever와 Generator 사이에 작은 LLM 추가

Kapa는 결국 새로운 단계를 추가했습니다.

기존 구조

Retriever
    │
Reranker
    │
Generator

변경된 구조

Retriever
    │
Reranker
    │
Context Pruner (Small LLM)
    │
Generator

Pruner는

질문과 검색된 모든 Chunk를 한 번에 읽고

필요하지 않은 Chunk를 제거합니다.

즉,

Generator는 이미 정리된 Context만 전달받게 됩니다.

---

LLM은 어떻게 Chunk를 평가할까?

Pruner는 각 Chunk를 다음과 같은 5단계 기준으로 평가합니다.

점수	등급	의미
5	Essential	답변 생성에 반드시 필요한 정보
4	Contributing	다른 Chunk와 함께 답을 완성하는 정보
3	Supporting	있으면 도움이 되지만 없어도 답변 가능
2	Tangential	같은 주제지만 실제 답변에는 기여하지 않음
1	Unrelated	질문과 관련 없음

이후 설정한 Threshold 이상의 Chunk만 Generator에 전달합니다.

이 방식은 앞에서 설명한 두 가지 문제를 동시에 해결합니다.

첫째,

등급 자체가 의미를 가지므로

모든 질문에서 동일한 Threshold를 사용할 수 있습니다.

둘째,

LLM이 모든 Chunk를 함께 보기 때문에

Chunk 간의 관계를 이해할 수 있습니다.

---

Context Pruning의 주요 설정 요소

Pruner의 성능은 다음 세 가지 요소에 크게 영향을 받습니다.

1. 사용하는 LLM

Pruner는 비용 절감이 목적이므로

고성능 대형 모델보다

빠르고 저렴한 소형 모델을 사용하는 것이 적합했습니다.

---

2. Threshold

Threshold는

얼마나 많은 Chunk를 제거할 것인지 결정하는 핵심 설정입니다.

Threshold를 높이면

더 많은 Context를 줄일 수 있지만

Recall이 감소할 위험이 있습니다.

---

3. Keep Top-K

가장 높은 점수를 받은 일부 Chunk는

Pruner의 평가와 관계없이 항상 유지합니다.

이를 통해

Pruner가 중요한 Chunk를 잘못 제거하는 위험을 줄였습니다.

---

함께 실험한 다른 방법

Kapa는 현재 방식 외에도 두 가지 접근을 비교했습니다.

Budget Select

처음 몇 개의 Chunk는 유지하고

LLM이 추가로 최대 N개만 선택하는 방식입니다.

장점은

최종 Context 크기를 일정하게 유지할 수 있다는 점입니다.

하지만

예산(N)을 모두 사용하면

그 이후 중요한 Chunk도 모두 제거되는 문제가 있었습니다.

---

Keep 방식

LLM에게

"어떤 Chunk를 유지할지 직접 선택하라"

고 요청하는 가장 단순한 방식도 테스트했습니다.

만약 새로운 설계가 이 방식보다 성능이 좋지 않다면

복잡한 구조를 만들 이유가 없기 때문입니다.

---

최종 결과

Kapa는 실제 서비스 데이터를 기반으로 성능을 검증했습니다.

평가 기준은

• Recall
• Compression
• 비용
• Latency

였습니다.

그 결과

• Context 약 68% 제거
• Recall 약 96% 유지
• Pruner 비용을 포함한 전체 Query 비용 약 3분의 1 절감

이라는 결과를 얻었습니다.

즉,

Generator가 읽는 문서는 크게 줄였지만

답변 품질은 거의 유지할 수 있었습니다.

---

728x90

기존 RAG 시스템은 높은 Recall을 위해 많은 문서를 LLM에 전달하고, Generator가 불필요한 정보를 스스로 무시하도록 설계되는 경우가 많았습니다. 하지만 이러한 방식은 입력 토큰 증가와 비용 상승이라는 한계를 가지고 있습니다.

Kapa는 Retriever와 Generator 사이에 LLM 기반 Context Pruner를 추가하여 이 문제를 해결했습니다. 핵심은 단순히 관련성이 높은 문서를 선택하는 것이 아니라, 질문과 모든 Chunk를 함께 고려해 실제 답변에 필요한 정보만 남기는 것입니다.

이번 사례는 RAG 파이프라인에서 Retrieval 이후에도 최적화 여지가 충분하다는 점을 보여줍니다. 특히 대규모 문서를 다루거나 Agent 기반 시스템처럼 컨텍스트가 빠르게 증가하는 환경에서는 Context Pruning이 비용 절감과 성능 유지라는 두 가지 목표를 동시에 달성할 수 있는 효과적인 접근 방식이 될 수 있습니다.

300x250

https://www.kapa.ai/blog/how-we-prune-rag-context

How we taught a small LLM to throw away 68% of our RAG context - kapa.ai - Instant AI answers to technical questions