🎯 Advanced RAG

Advanced RAG

Naive RAG가 실패하는 지점을 진단하고, 파이프라인 단계별로 처방하는 기법 체계

Naive RAG — 직선 파이프라인의 벽

검색 한 번, 결과 그대로 주입 — 앞 모듈에서 만든 기본형이 실전에서 부딪히는 지점

Naive vs Advanced — 무엇이 다른가

파이프라인을 갈아엎는 것이 아니라, 같은 뼈대의 단계마다 개선 포인트를 꽂는 것

Naive RAG의 실패 유형 3가지

단순 벡터 검색이 놓치는 질문들 — 유형에 따라 달라지는 처방

3단계 최적화 지도

왼쪽은 Naive, 오른쪽은 Advanced — 같은 세로 흐름에서 오른쪽에만 기법이 끼어든다

러닝 예제 — Naive vs Advanced

같은 질문 "예약금 환불 규정이 어떻게 되나요?" — 기법 3개가 문서들의 순위를 어떻게 바꾸는가 (예시 수치)

인덱싱 최적화

검색이 시작되기 전에 승부를 내는 오프라인 단계 — 저장 방법이 검색 품질을 결정

Parent-Child 청킹

청킹의 딜레마 — 작게 자르면 문맥 손실, 크게 자르면 검색 흐림. 그래서 둘 다 쓰는 전략

Semantic Chunking — 의미 경계에서 분할

문장 사이 임베딩 유사도가 급락하는 지점 = 주제의 경계 — 기계적 분할이 놓치는 문맥 보존

메타데이터로 범위 좁히기

벡터 유사도는 "2026년 메뉴"와 "2025년 구 메뉴"를 구분하지 못함 — 그래서 필터가 먼저

핵심 포인트

.metadata.json

S3에 각 문서와 함께 업로드 — Knowledge Base가 필터 키를 자동 인덱싱

필수 키 3종

category(유형) · effective_date(유효일) · source(출처)

연산자

equals · notEquals · greaterThan · in · startsWith 등

설계 원칙

키 3~5개 제한, 날짜는 ISO 8601, 중첩 없이 1depth 평탄화

코드

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": {
        "numberOfResults": 5,
        "filter": {"andAll": [
            {"equals": {"key": "category", "value": "restaurant"}},
            {"equals": {"key": "cuisine", "value": "이탈리안"}},
        ]},
    }},
)

임베딩 전략 — 모델과 차원

임베딩 모델이 벡터 공간의 품질을 결정 — 언어 구성과 입력 길이가 갈림길

선택과 최적화

한국어 위주

Titan Embed v2가 출발점 — 8,192토큰 입력, AWS 통합

다국어 혼합

Cohere Multilingual v3 — 512토큰 입력 한도 주의

차원 축소

1,024 → 256으로 저장·검색 비용 절감 (약간의 정확도 손실과 교환)

인덱싱 최적화

배치 임베딩 · 문서 해시 캐싱으로 재임베딩 방지 · 코사인 사용 시 정규화

모델 비교

사전 검색

사용자 질문을 그대로 검색하지 않음 — LLM이 쿼리를 변환한 뒤 검색

Query Rewriting

"해약하면 돈 내야 해?" → "예약 취소 수수료 정책" — 가장 값싸고 확실한 첫 처방

핵심 포인트

REWRITE_PROMPT

지시문이 곧 기법 — 구어체→공식 용어, 대명사→구체 명사

str(result)

AgentResult에서 텍스트를 꺼내는 정본 — message는 dict입니다.

chat_history

최근 3턴을 함께 주면 "그거 얼마야?" 같은 대명사 해소

@tool

Agentic RAG 모듈의 에이전트에 그대로 장착 가능한 형태

코드

from strands import Agent, tool
from strands.models import BedrockModel

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6")

REWRITE_PROMPT = """사용자 질문을 검색에 최적화된 쿼리로 변환하세요.
- 구어체를 공식 용어로, 대명사를 구체적 명사로
- 검색 키워드만 출력 (설명 없이)"""

# 재작성 에이전트를 도구로 — 출력 텍스트는 str(result)로 추출
@tool
def rewrite_query(query: str) -> str:
    """사용자 질문을 검색 최적 쿼리로 변환합니다."""
    rewriter = Agent(model=model, system_prompt=REWRITE_PROMPT)
    return str(rewriter(query))

# "해약하면 돈 내야 해?" → "예약 취소 수수료 정책"

HyDE — 가상 답변으로 검색

HyDE(Hypothetical Document Embeddings) — 문서를 닮은 가상 답변을 만들어, 질문 대신 그 임베딩으로 검색

핵심 포인트

형식 갭 해소

짧은 질문 ↔ 긴 문서 — 답변 임베딩이 문서와 더 가깝습니다.

LLM 2회

가상 답변 생성 + 최종 응답 — 레이턴시 비용을 감수하는 기법

적합

FAQ 스타일 문서, 전문 용어 문서를 일반 사용자가 검색할 때

역효과

수치·날짜·최신 데이터 질문 — 가상 답변이 환각 노이즈가 됩니다.

코드

import boto3
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

# 1단계 — 가상 답변 생성 (정확할 필요 없음, 형식만 문서와 닮으면 됨)
def hypothetical_answer(query: str) -> str:
    response = bedrock.converse(
        modelId="us.anthropic.claude-sonnet-4-6",
        messages=[{"role": "user", "content": [
            {"text": f"다음 질문에 상세히 답변하세요 (부정확해도 됩니다): {query}"}]}],
        inferenceConfig={"maxTokens": 200, "temperature": 0},
    )
    return response["output"]["message"]["content"][0]["text"]

# 2단계 — 질문 대신 가상 답변의 임베딩으로 벡터 검색
docs = vector_search(embed(hypothetical_answer("이탈리안 코스 가격?")))

질문을 쪼개는 세 가지 방법

모호하면 관점을 늘리고, 0건이면 넓히고, 섞였으면 분해 — 문제마다 다른 쪼개기

RAG Fusion — 분해의 완성

여러 쿼리의 결과를 단순 합집합이 아니라 순위 융합으로 — 공통 상위 문서가 진짜 관련 문서

하이브리드 검색

같은 쿼리를 벡터와 키워드로 동시에 검색하고, 두 순위를 하나로 융합

벡터 검색이 놓치는 쿼리

의미에 강하고 용어에 약한 벡터 — 정확한 문자열 매칭은 키워드 검색의 영역

같은 질문, 두 검색기

"예약금 환불 규정이 어떻게 되나요?" — 의미로 찾는 벡터와 "환불" 용어로 찾는 BM25를 순위로 병합

RRF (Reciprocal Rank Fusion)

벡터 점수는 0~1, BM25는 0~무한대 — 점수 대신 순위를 쓰면 사라지는 스케일 문제

핵심 포인트

순위 기반

점수 스케일 불일치를 완전히 회피 — 정규화 불필요

k=60

표준값 — 높일수록 순위 차이의 영향력이 완화됩니다.

양쪽 상위 = 최상위

한쪽에서만 높은 문서는 보완적으로 포함되되 순위 하락

재사용

RAG Fusion(다중 쿼리)과 하이브리드(벡터+키워드) 공용 융합기

코드

# RRF — 점수가 아니라 순위의 역수를 합산한다 (정규화 불필요)
def reciprocal_rank_fusion(results_list, k=60):
    scores = {}
    for results in results_list:
        for rank, doc in enumerate(results):
            scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

# 벡터 1위 + 키워드 3위 = 1/61 + 1/63 — 양쪽 상위 문서가 최상위로
fused = reciprocal_rank_fusion([vector_results, keyword_results])

점수 결합 전략 비교

RRF가 기본값 — 가중치 튜닝은 평가 데이터가 쌓인 뒤에만

사후 검색

검색은 됐는데 순위 · 분량 · 출처가 문제일 때 — 결과를 정제한 뒤 LLM에 전달

Reranking 전 → 후

"예약금 환불 규정이 어떻게 되나요?"의 후보들 — 유사도 순위가 Cross-Encoder 관련도로 뒤집히는 전/후

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"},
            },
        },
    }})

Compression과 배치 전략

가져온 문서가 너무 길거나, LLM이 중간을 건너뛰거나 — 분량과 배치의 문제

Citation — 출처가 곧 방어선

답변의 각 주장에 출처 번호를 강제 — 신뢰성 확보와 환각 탐지를 동시에

증상 → 진단 → 처방

실패 로그의 증상이 진단을, 진단이 기법을 결정 — 처방은 비용 낮은 것부터

적용 순서 — 비용이 낮은 것부터

한 번에 1개 기법만 — 여러 개를 동시에 바꾸면 효과의 출처가 불분명

1. 1
   1순위 — 인덱싱

   Parent-Child · 메타데이터 · 청킹 조정. 1회 설정으로 모든 쿼리에 적용, 추가 쿼리 비용 0.

2. 2
   2순위 — 사후 검색

   Reranking부터 — LLM 호출 없이 리랭커만 추가. 코드 몇 줄로 즉각 효과.

3. 3
   3순위 — 사전 검색

   Query Rewriting → 필요 시 HyDE · RAG Fusion. 매 쿼리 LLM 비용 — 가장 비싸지만 효과도 큼.

4. 4
   상시 — 평가 루프

   기법 1개 추가마다 동일 데이터셋으로 재측정. 개선이 확인될 때만 유지 — 빼서 좋아지는 경우도 있습니다.