Advanced RAG 사후 검색
Reranking, Compression, Citation
Advanced RAG 사후 검색
Reranking, Compression, Citation
검색이 엉뚱할 때 쓰는 처방전
실패 유형 진단과 파이프라인 단계별 처방 — 검색 품질을 끌어올리는 기법 체계
사후 검색
Reranking · Compression · Lost-in-the-Middle · Citation
사후 검색
검색은 됐는데 순위 · 분량 · 출처가 문제일 때 — 결과를 정제한 뒤 LLM에 전달
가져온 것을 다듬는다
적용 순서가 곧 우선순위 — 순위 교정(Reranking) → 분량 정리(Compression) → 출처 명시(Citation)
- Reranking — Cross-Encoder 정밀 재정렬
- Compression — 관련 문장만 추출
- Lost-in-the-Middle — 배치 재조정
- Citation — 출처 명시 · 환각 탐지
전부 쓸 필요 없습니다 — Reranking 하나로 대부분 충분하고, 나머지는 증상이 있을 때만 얹습니다.
Reranking 전 → 후
"예약금 환불 규정이 어떻게 되나요?"의 후보들 — 유사도 순위가 Cross-Encoder 관련도로 뒤집히는 전/후
→
Cross-
Encoder
유사도(가깝다)와 관련도(답이 된다)는 다릅니다 — 이 재정렬이 retrieve 호출 한 번에 들어갑니다.
Reranking — 2단계 파이프라인
Bi-Encoder로 넓게 후보 20개 → Cross-Encoder가 쿼리·문서 쌍을 1:1 정밀 비교해 Top-5 선별
import boto3
bedrock_rt = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
response = bedrock_rt.retrieve(
knowledgeBaseId="KB-RESTAURANT-001",
retrievalQuery={"text": "당일 취소 수수료"},
retrievalConfiguration={"vectorSearchConfiguration": {
# ① 1단계 — 후보는 넓게 20개 (Bi-Encoder + 하이브리드)
"numberOfResults": 20,
"overrideSearchType": "HYBRID",
# ② 2단계 — rerankingConfiguration은 vectorSearchConfiguration 내부에 위치
"rerankingConfiguration": {
"type": "BEDROCK_RERANKING_MODEL",
"bedrockRerankingConfiguration": {
# ③ Cross-Encoder(Cohere Rerank)가 정밀 재정렬해 Top-5만 남김
"numberOfRerankedResults": 5,
"modelConfiguration": {"modelArn": "arn:aws:bedrock:us-east-1::foundation-model/cohere.rerank-v3-5:0"},
},
},
}})- 1단계 — 넓은 후보 — numberOfResults=20으로 재현율 확보. HYBRID로 어휘 불일치 보완
- 2단계 — 리랭킹 설정 — retrieve 호출 한 번에 리랭킹까지. 별도 파이프라인 코드 불필요
- Cross-Encoder 선별 — 쿼리·문서 쌍 1:1 정밀 비교로 Top-5만 LLM에 전달. LLM 호출 없이 리랭커만 추가되는 가성비 기법
Compression과 배치 전략
가져온 문서가 너무 길거나, LLM이 중간을 건너뛰거나 — 분량과 배치의 문제
Contextual Compression
문서에서 관련 문장만 추출
- 500토큰 청크에서 관련 50토큰만 — 비용 절감 + 정밀도 향상
- 문서당 LLM 1회 추가 호출 — 경량 모델(Haiku)로 절충
- 200토큰 이하 청크에는 불필요 — 오히려 정보 손실
Lost-in-the-Middle 방지
중요 문서를 처음과 끝에 배치
- LLM은 프롬프트 처음·끝에 집중 (Stanford NLP 연구)
- Reranking 후 1등은 맨 앞, 2등은 맨 뒤로 재배치
- Knowledge Base RetrieveAndGenerate는 자체 정렬 — 커스텀 RAG 전용 기법
문서 수를 줄이면 "중간"이 사라집니다 — Top-3 제한이 가장 값싼 Lost-in-the-Middle 방어입니다.
Citation — 출처가 곧 방어선
답변의 각 주장에 출처 번호를 강제 — 신뢰성 확보와 환각 탐지를 동시에
커스텀 RAG — 프롬프트 유도
[N] 번호 강제
- 문서마다 [1], [2] 번호를 붙여 전달
- "각 주장에 [N] 표기" + "없으면 확인 불가로 답변" 지시
- 답변에서 [N] 패턴 추출 → 원문과 대조
- [N] 없는 문장 = 환각 의심 신호
Citation 검증을 파이프라인에 넣으면 환각 탐지가 자동화됩니다 — Guardrails와 결합하면 방어선이 이중이 됩니다.
Bedrock Knowledge Bases — 자동 제공
관리형 경로
- RetrieveAndGenerate 응답에 citations 배열 포함
- retrievedReferences + generatedResponsePart 매핑
- Managed Knowledge Base도 기존 Retrieve API 호환 — location으로 출처 추적
- 프롬프트 엔지니어링 불필요
관리형 경로는 Citation이 기본입니다 — 직접 유도가 필요한 것은 커스텀 파이프라인뿐입니다.
Citation이 있어도 원문과 불일치하면 잘못된 인용 — 번호의 존재가 아니라 내용 대조까지가 검증입니다.
적용 전략
진단 → 처방 · 적용 순서 · 실습
증상 → 진단 → 처방
실패 로그의 증상이 진단을, 진단이 기법을 결정 — 처방은 비용 낮은 것부터
| 증상 | 진단 | 처방 (비용 낮은 순) |
|---|---|---|
| 관련 문서가 아예 안 나옴 | 어휘 불일치 | 메타데이터 필터 → Query Rewriting → 하이브리드 |
| 문서는 나오는데 순위가 낮음 | 임베딩 한계 | Parent-Child → Reranking → HyDE |
| 복합 질문에 반쪽 답변 | 주제 혼재 | Sub-Query 분해 → RAG Fusion |
| 너무 구체적이라 0건 | 검색 범위 협소 | Step-back 추상화 |
| 무관한 문서가 많이 섞임 | 과잉 검색 | Semantic Chunking → Compression |
| 답이 중간 내용을 누락 | Lost-in-the-Middle | Top-3 제한 또는 재배치 |
| 정확하지만 출처 불명 | 신뢰성 부족 | Citation |
이 표가 이 모듈의 요약입니다 — 증상 없이 기법부터 고르지 않습니다.
적용 순서 — 비용이 낮은 것부터
한 번에 1개 기법만 — 여러 개를 동시에 바꾸면 효과의 출처가 불분명
-
1
1순위 — 인덱싱
Parent-Child · 메타데이터 · 청킹 조정. 1회 설정으로 모든 쿼리에 적용, 추가 쿼리 비용 0.
-
2
2순위 — 사후 검색
Reranking부터 — LLM 호출 없이 리랭커만 추가. 코드 몇 줄로 즉각 효과.
-
3
3순위 — 사전 검색
Query Rewriting → 필요 시 HyDE · RAG Fusion. 매 쿼리 LLM 비용 — 가장 비싸지만 효과도 큼.
-
4
상시 — 평가 루프
기법 1개 추가마다 동일 데이터셋으로 재측정. 개선이 확인될 때만 유지 — 빼서 좋아지는 경우도 있습니다.
"더 넣으면 좋겠지"가 아니라 수치로 개선 확인이 기준입니다 — 측정 방법(3축 메트릭·RAGAS)은 RAG 평가 모듈에서 다룹니다.
Advanced RAG 실습
Naive RAG에 Advanced 기법을 단계별로 얹으며 품질 변화를 직접 확인합니다
학습 목표
- Query Rewriting으로 검색 쿼리 최적화
- Multi-Query로 다양한 관점의 검색 수행
- Reranking으로 검색 결과 정확도 향상
- Self-RAG로 응답의 근거 자동 검증
- 기본 RAG vs Advanced RAG 품질 비교
인덱싱 → 사후 → 사전 순으로 — 평가 루프로 효과를 확인하며 한 번에 하나씩