신뢰할 수 있는 RAG 시스템 구축

Source: Dev.to

Retrieval‑Augmented Generation (RAG)은 종종 모델링 문제로 논의됩니다. 실제로 대부분의 RAG 실패는 언어 모델과는 거의 관련이 없습니다. 실패 원인은 다음과 같습니다:

• 잘못된 정보가 검색됨
• 올바른 정보가 잘못 분할됨
• 관련 컨텍스트는 검색되었지만 순위가 낮게 매겨짐

이 가이드는 실제로 RAG 품질을 결정하는 세 가지 계층을 살펴봅니다:

1. Chunking – 정보가 어떻게 세분화되는지
2. Retrieval – 후보가 어떻게 찾아지는지
3. Reranking – 최적의 컨텍스트가 어떻게 선택되는지

각 계층은 이전 계층 위에 구축됩니다. 순서를 무시하고 최적화하면 시스템이 취약해집니다.

RAG 파이프라인 (개념적 개요)

Documents
   ↓
Chunking
   ↓
Indexes (Vector + Lexical)
   ↓
Retrieval
   ↓
Rank Fusion
   ↓
Reranking
   ↓
LLM

대부분의 시스템은 하단을 과도하게 최적화하고 상단은 충분히 설계하지 못합니다.

Source: …

Part 1 — Chunking: Making Information Retrievable

Chunking이 실제로 의미하는 것

Chunking은 문서를 검색 가능한 단위(“청크”)로 나누어 인덱싱하고 검색할 수 있게 하는 과정입니다.

Chunking은 다음이 아닙니다:

• 컨텍스트 윈도우를 채우는 방법
• 전처리 세부 사항
• 나중에 임베딩이 해결해 줄 것

Chunking은 어떤 정보를 전혀 검색할 수 있는지를 결정합니다. 정보가 잘못 나뉘면 사실상 존재하지 않는 것과 같습니다.

Chunking의 핵심 규칙

청크는 하나의 일관된 질문에 대해 잘 답변할 수 있어야 합니다.

청크가 인간 독자에게 스스로 의미를 갖지 못한다면, 검색에서도 제대로 동작하기 어렵습니다. 토큰 수는 제약일 뿐, 목표가 아닙니다.

왜 단순한 Chunking은 실패하는가

흔히 저지르는 실수:

• 고정 토큰 수로 나누기
• 문장 중간이나 규칙 중간에서 나누기
• “혹시 몰라”라며 과도하게 겹치게 만들기
• 구조를 평평한 텍스트로 변환하기

이러한 실수는 다음을 초래합니다:

• 부분적인 답변
• 누락된 한정자
• 모델이 만든 환각을 모델 탓으로 돌리게 됨

텍스트가 아니라 구조에 따라 Chunking하기

Chunking을 시작하기 전에 문서를 구조화된 블록으로 취급합니다:

• 제목
• 섹션
• 단락
• 리스트
• 표
• 코드 블록

Chunking은 원시 텍스트를 얇게 자르는 것이 아니라 블록을 의사결정 단위로 조합해야 합니다.

개념 흐름

Raw Document
   ↓
Structured Blocks
   ↓
Chunk Assembly

현실적인 기본 Chunking 전략

대부분의 실제 시스템에 적용 가능한 방법:

• 문서 순서와 계층 구조를 유지한다.
• 인접 블록을 병합해 하나의 완전한 아이디어를 포착한다.
• 목표 토큰 수는 약 200–600 토큰(유연하게)이다.
• 규칙과 그 예외를 분리하지 않는다.

최소한의 컨텍스트를 앞에 붙인다(예: 문서 제목, 섹션 경로).

그 결과 생성되는 청크는:

• 의미가 있다
• 검색 가능하다
• 디버깅하기 쉽다

청크 확장(핵심 아이디어)

하나의 청크 크기에 얽매일 필요는 없습니다. 강력한 패턴은 검색 시점 확장입니다:

1. 작고 정확한 청크를 검색한다.
2. 인접 청크나 상위 섹션을 확장한다.
3. 생성 전에 병합한다.

Retrieved chunk
   ↑      ↓
Neighbors / Parent context

이 방법은 인덱스를 부풀리지 않으면서 컨텍스트를 향상시킵니다.

Source: …

Part 2 — Retrieval: Finding the Right Candidates

Chunking은 무엇을 검색할 수 있는지를 정의합니다. Retrieval은 어떤 청크가 고려되는지를 정의합니다. Retrieval은 재현율에 관한 것이며, 최종 정확성에 관한 것이 아닙니다.

Retrieval methods (what they actually do)

Lexical retrieval (BM25 / FTS)

• 정확한 용어와 매치됩니다.
• 식별자, 이름, 키워드에 탁월합니다.
• 패러프레이즈에는 약합니다.

“이 텍스트에 이 단어들이 포함되어 있나요?”

Vector retrieval (embeddings)

• 의미적 유사성을 매치합니다.
• 패러프레이즈, 모호한 질의에 탁월합니다.
• 희귀 토큰, 숫자, 정확한 제약조건에는 약합니다.

“이 텍스트가 비슷한 의미를 가지고 있나요?”

Why neither is sufficient alone

• Lexical 검색은 의미를 놓칩니다.
• Vector 검색은 의미를 과도하게 일반화합니다.

둘 중 하나만 사용하면 체계적인 사각지대가 생깁니다.

Hybrid retrieval (the default)

가장 신뢰할 수 있는 시스템은 두 가지 모두를 사용합니다:

Query
 ├─ Lexical retrieval (BM25)
 ├─ Vector retrieval (embeddings)
 └─ Candidate union

이렇게 하면 재현율을 최대화할 수 있습니다.

Rank fusion: merging retrieval signals

Lexical과 vector 점수는 직접 비교할 수 없습니다. 점수를 섞는 대신 순위 기반 융합을 사용합니다.

Reciprocal Rank Fusion (RRF)

직관: 여러 리스트에서 상위에 나타나는 문서일수록 더 신뢰할 수 있습니다.

단순화된 공식:

score(doc) = Σ 1 / (k + rank)

• 간단함
• 견고함
• 파라미터가 거의 없음

RRF는 훌륭한 기본 옵션입니다.

Retrieval goal (important)

Retrieval은 최고의 청크를 고르는 것이 아니라 올바른 청크를 놓치지 않는 것에 초점이 있습니다. 정밀도는 나중에 다룹니다.

Part 3 — 재랭킹: 최적의 컨텍스트 선택

After retrieval you typically have 20–100 candidate chunks—too many for an LLM, and many are only weakly relevant. Reranking introduces understanding.
검색 후 일반적으로 20–100개의 후보 청크가 생깁니다—LLM에게는 너무 많고, 대부분은 관련성이 약합니다. 재랭킹은 이해를 도입합니다.

What rerankers do differently

재랭커가 다르게 하는 일

Unlike retrieval, rerankers see the query and chunk together and model cross‑attention between them. This allows them to understand:
검색과 달리, 재랭커는 쿼리와 청크를 함께 보고 이들 사이의 교차 주의를 모델링합니다. 이를 통해 다음을 이해할 수 있습니다:

• constraints
  • 제약
• negation
  • 부정
• specificity
  • 구체성
• intent
  • 의도

Rerankers answer: “Does this chunk actually answer the query?”
재랭커는 다음에 답합니다: “이 청크가 실제로 쿼리에 답하고 있는가?”

Why reranking matters

재랭킹이 중요한 이유

Without reranking:
재랭킹이 없을 경우:

• semantically “close” but wrong chunks rise to the top
  • 의미적으로 “가깝지만” 잘못된 청크가 상위에 오름
• confident hallucinations occur
  • 자신감 있는 환각이 발생
• irrelevant material is passed to the LLM
  • 관련 없는 자료가 LLM에 전달됨

Reranking filters the candidate set down to a handful of truly relevant chunks, enabling the LLM to generate accurate, grounded responses.
재랭킹은 후보 집합을 실제로 관련 있는 소수의 청크로 필터링하여, LLM이 정확하고 근거 있는 응답을 생성하도록 합니다.

전형적인 재정렬 흐름

Top‑K retrieved chunks
   ↓
Cross‑encoder reranker
   ↓
Top‑N high‑precision chunks

* N은 보통 작습니다 (5–10). *

비용 vs 품질 트레이드오프

Rerankers는:

• 검색보다 느리다
• 쿼리당 비용이 더 많이 든다

그렇기 때문에 검색 후에 사용되며, 대신에 사용되지 않는다.
이와 같은 계층적 접근 방식은 시스템을 확장 가능하게 유지한다.

모두 한 번에 보기

엔드‑투‑엔드 RAG 파이프라인

Documents
   ↓
Chunking (decision units)
   ↓
Indexing
   ├─ Lexical index
   └─ Vector index
   ↓
Retrieval
   ├─ BM25
   ├─ Vector search
   └─ Rank fusion (RRF)
   ↓
Reranking
   ↓
Chunk expansion (optional)
   ↓
LLM

각 레이어는 하나의 책임만을 갖습니다.

시스템 평가 방법 (자주 생략됨)

먼저 모델을 튜닝하지 마세요. 먼저 검색을 평가하세요.

핵심 질문

• 올바른 청크가 top‑K에 나타나는가?
• 올바른 섹션이 검색되는가?
• 재정렬이 올바른 청크를 위로 올리는가?
• 인간이 검색된 컨텍스트만으로 질문에 답할 수 있는가?

추적할 지표

• recall@K
• 섹션 히트율
• 답변 충실도
• 인용 정확성

검색이 잘못되면 생성도 올바를 수 없습니다.

일반적인 안티패턴

• 벡터 전용 검색
• 문장 수준 청킹을 어디서나 적용
• 과도한 중복
• 기본적으로 LLM 전용 청킹
• 환각을 모델 탓으로 돌리기

이러한 문제들은 보통 상위 단계의 문제를 가립니다.

지루하지만 신뢰할 수 있는 진실

• 청킹은 무엇을 찾을 수 있는지를 결정합니다
• 검색은 무엇이 고려되는지를 결정합니다
• 재순위는 무엇이 신뢰되는지를 결정합니다

모델은 이 세 가지 모두의 하위 단계에 위치합니다.

좋은 RAG 시스템은 하향식으로 구축됩니다, 상향식이 아니라.

최종 요약

한 가지만 기억한다면:

RAG 품질은 생성 문제가 되기 전, 먼저 검색 문제이다.

청크화, 검색, 그리고 재정렬을 제대로 하면 모델이 훨씬 똑똑해 보인다.