Note

Advanced RAG 인덱싱

청킹, 메타데이터, 하이브리드 검색

⏱ 40분 51 / 189

Advanced RAG 인덱싱

청킹, 메타데이터, 하이브리드 검색

검색이 엉뚱할 때 쓰는 처방전

실패 유형 진단과 파이프라인 단계별 처방 — 검색 품질을 끌어올리는 기법 체계

인덱싱 최적화

Parent-Child · 메타데이터 · 임베딩 전략

PART 2 · 인덱싱 최적화

인덱싱 최적화

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

저장을 바꾸면 검색이 바뀐다

RAG 모듈의 인덱싱 파이프라인 위에 얹는 세 가지 개선 — 청킹 구조 · 메타데이터 · 임베딩

Parent-Child — 작게 찾고 크게 읽기
Semantic Chunking — 의미 경계에서 분할
메타데이터 — 검색 전 범위 제한
임베딩 전략 — 모델·차원 선택

takeaway

한 번 설정하면 모든 쿼리에 적용됩니다 — 가성비가 가장 높은 단계이므로 항상 1순위로 적용합니다.

PART 2 · 인덱싱 최적화

Parent-Child 청킹

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

Child — 검색용

작은 청크 (100~300자)

정밀한 의미 매칭 — 검색 정확도 높음
"취소 수수료" 키워드가 든 청크를 정확히 조준
ID로 자신의 Parent를 참조

검색은 Child에서 일어납니다 — 작을수록 쿼리와의 의미 매칭이 선명해집니다.

Parent — 응답용

큰 청크 (1,000~2,000자)

조건 · 계산법 · 예외가 함께 담긴 문맥
LLM에 전달되는 단위 — 답변 완전성 확보
앞뒤 맥락 포함 — 문장 중간 절단 없음

매칭된 Child의 Parent를 LLM에 전달합니다 — 정밀 검색과 풍부한 문맥을 동시에 얻습니다.

Bedrock Knowledge Bases Hierarchical Chunking

Knowledge Base에서 Hierarchical Chunking을 선택하면 코드 없이 같은 효과를 얻습니다 — Parent 1,500 · Child 300 토큰 기본값으로 관리형 구성됩니다. 커스텀 분할 로직이 필요할 때만 직접 구현하세요.

PART 2 · 인덱싱 최적화

Semantic Chunking — 의미 경계에서 분할

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

고정 크기 청킹

N자마다 기계적 분할

구현 간단 — 인덱싱 비용 최소
문장 · 주제 중간에서 잘릴 위험
항목이 독립적인 FAQ에 적합
기본값으로 먼저 시도하는 출발점

짧고 독립적인 문서라면 이것으로 충분합니다 — 검색 품질 문제가 측정될 때만 다음 단계로 갑니다.

Semantic Chunking

유사도 변화점에서 분할

문장 임베딩 유사도가 급락하는 지점에서 절단
주제 단위 보존 — 긴 단락 기술 문서에 적합
모든 문장을 사전 임베딩 — 인덱싱 비용 증가
조항 경계가 뚜렷한 법률 · 정책 문서에 효과

인덱싱 1회 비용을 내고 검색 품질을 사는 선택입니다 — 문서 갱신이 잦으면 비용이 반복되는 점을 감안하세요.

takeaway

문서 유형이 전략을 정합니다 — 기술 문서는 Parent-Child, FAQ는 고정 크기, 법률·정책은 Semantic + 메타데이터, 표 문서는 Data Automation이 맞습니다.

PART 2 · 인덱싱 최적화

메타데이터로 범위 좁히기

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

핵심 포인트

.metadata.json: S3에 각 문서와 함께 업로드 — Knowledge Base가 필터 키를 자동 인덱싱
필수 키 3종: category(유형) · effective_date(유효일) · source(출처)
연산자: equals · notEquals · greaterThan · in · startsWith 등
설계 원칙: 키 3~5개 제한, 날짜는 ISO 8601, 중첩 없이 1depth 평탄화

코드

python

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": "이탈리안"}},
        ]},
    }},
)

PART 2 · 인덱싱 최적화

임베딩 전략 — 모델과 차원

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

선택과 최적화

한국어 위주: Titan Embed v2가 출발점 — 8,192토큰 입력, AWS 통합
다국어 혼합: Cohere Multilingual v3 — 512토큰 입력 한도 주의
차원 축소: 1,024 → 256으로 저장·검색 비용 절감 (약간의 정확도 손실과 교환)
인덱싱 최적화: 배치 임베딩 · 문서 해시 캐싱으로 재임베딩 방지 · 코사인 사용 시 정규화

모델 비교

모델	차원	최대 입력	강점
Titan Embed v2	1,024	8,192 토큰	AWS 통합 · 범용 · 상대적으로 저렴
Cohere Multilingual v3	1,024	512 토큰	다국어 혼합 문서에 최적

기법을 쌓는 것이 아니라, 병목을 진단하고 처방하세요.

인덱싱 → 사후 → 사전 순으로 — 평가 루프로 효과를 확인하며 한 번에 하나씩