Home / RAG 핵심 개념 / RAG 인덱싱 파이프라인
Note

RAG 인덱싱 파이프라인

파싱, 토크나이저, 청킹, 임베딩, 인덱싱

⏱ 40분 40 / 189

RAG 인덱싱 파이프라인

파싱, 토크나이저, 청킹, 임베딩, 인덱싱

검색이 생성을 완성한다

Retrieval-Augmented Generation — LLM의 한계를 외부 지식으로 보완

인덱싱 파이프라인

파싱 · 청킹 · 임베딩 · 벡터 스토어

PART 3 · 인덱싱 파이프라인

인덱싱 파이프라인

문서를 검색 가능한 상태로 바꾸는 오프라인 구간 — 한 번 구축하면 검색 시점에는 반복 없음

인덱싱 파이프라인

문서가 벡터 인덱스가 되기까지 — 각 단계의 품질이 최종 검색 정확도를 결정합니다

  • 파싱 — 텍스트·구조 추출
  • 청킹 — 의미 단위 분할
  • 임베딩 — 벡터 변환
  • 저장 — 벡터 인덱스 기록
takeaway

순서가 곧 의존성입니다 — 앞 단계에서 놓친 정보는 뒤 단계에서 복구할 수 없습니다.

PART 3 · 인덱싱 파이프라인

인덱싱이란?

질문이 오기 전에, 문서를 검색 가능한 형태로 미리 바꿔 두는 오프라인 준비 작업

무엇을 원본 문서 그대로 (PDF·HTML) 청크 + 벡터 + 메타데이터
언제 질문이 올 때마다 실시간 문서가 들어올 때 한 번 (변경 시 갱신)
그래서 매 질문마다 문서 전체 읽기 준비된 인덱스에서 가까운 벡터 찾기
takeaway

도서관의 색인 카드와 같습니다 — 책이 들어올 때 한 번 정리해 두면, 찾을 때는 서가를 뒤지지 않습니다.

PART 3 · 인덱싱 파이프라인

인덱싱 4단계

문서를 검색 가능한 형태로 변환하는 과정

  1. 1
    파싱

    PDF, HTML, DOCX에서 텍스트와 구조(제목·표) 추출
    기본 · 파운데이션 모델 파서 · Data Automation 3전략

  2. 2
    청킹

    긴 텍스트를 의미 단위로 분할
    한국어 300~800자 + 50~100자 오버랩 권장

  3. 3
    임베딩

    텍스트를 고차원 벡터로 변환
    Titan Embed v2 — 1,024차원, 최대 입력 8,192토큰

  4. 4
    저장

    벡터 + 원문 청크 + 메타데이터를 인덱스에 기록
    OpenSearch, S3 Vectors, FAISS

takeaway

검색 품질의 상한은 쿼리 시점이 아니라 문서가 들어오는 시점에 이미 결정됩니다 — 인덱싱이 부실하면 뒤의 어떤 기법도 복구하지 못합니다.

PART 3 · 인덱싱 파이프라인

청킹의 실제 — restaurant-policy.pdf

문서를 통째로 임베딩하면 유사도가 흐려집니다 — 의미 단위로 나눈 청크가 검색·주입·인용의 단위




파싱된 원문 — restaurant-policy.pdf

…예약 변경과 취소는 전화 또는 온라인으로 접수할 수 있습니다. 예약금은 이용일 3일 전까지 취소하면 전액 환불됩니다. 이용일 1~2일 전 취소는 예약금의 50%가 공제되며, 당일 취소와 노쇼(No-show)는 환불되지 않습니다…


아직 한 덩어리 — 통째로 임베딩하면 질문과의 유사도가 흐려짐

→



청크 #11 · 388자 (예시 수치)
"…예약금 규정. 예약 변경과 취소는 전화 또는 온라인으로 접수할 수 있습니다."

↕오버랩 50~100자 — 경계 문장이 양쪽 청크에 남음


청크 #12 · 412자 (예시 수치) — 질문과 만날 청크
"…온라인으로 접수할 수 있습니다. 예약금은 이용일 3일 전까지 취소하면 전액 환불됩니다. 이용일 1~2일 전 취소는 예약금의 50%가…"


청크 #13 · 365자 (예시 수치)
"…당일 취소와 노쇼(No-show)는 환불되지 않습니다. 단체 예약은 별도 규정이 적용되며…"



takeaway

검색 결과로 돌아오는 것은 문서가 아니라 청크 하나입니다 — 질문과 만나는 단위도, 프롬프트에 들어가는 단위도 청크입니다.

PART 3 · 인덱싱 파이프라인

청킹 전략 6가지

단순한 분할에서 정교한 분할로 — 어떻게 나누느냐가 검색 정확도를 결정

takeaway

청킹 전략이 검색 품질을 좌우합니다 — 재귀 분할로 시작하되, 청크가 임베딩 모델 입력 한도(8,192토큰)를 넘지 않게 설계합니다.

PART 3 · 인덱싱 파이프라인

임베딩 — 의미를 좌표로

임베딩 모델은 텍스트를 1,024차원 공간의 좌표에 놓습니다 — 의미가 비슷하면 좌표가 가깝다




"예약금은 이용일 3일 전까지 취소하면 전액 환불…" 청크 #12
↓
임베딩 모델 — Titan Embed v2
↓
[ 0.11, −0.58, 0.27, … ]
1,024차원 좌표 — 이 벡터가 인덱스에 저장됩니다

→


의미 공간 (1,024차원을 2차원으로 눌러 그린 개념도)




의미가 가깝다 = 좌표가 가깝다
"예약금 환불 규정이 어떻게 되나요?" — 질문

"3일 전까지 취소 시 전액 환불…" — 청크 #12

"당일 취소·노쇼는 환불 불가…" — 청크 #13

"오늘의 셰프 추천 코스는…" — 메뉴 안내 청크

"발레파킹은 3시간 무료…" — 주차 안내 청크


검색은 질문 좌표에서 가장 가까운 점 찾기 — 같은 단어가 없어도 의미가 같으면 가깝습니다


takeaway

임베딩 모델은 인덱싱과 검색이 반드시 같아야 합니다 — 모델을 바꾸는 것은 좌표계를 바꾸는 것이라, 곧 전체 재인덱싱입니다.

PART 3 · 인덱싱 파이프라인

벡터 스토어 비교

워크로드에 따른 최적 벡터 스토어 선택

벡터 스토어관리규모특징
OpenSearch Serverless관리형수십억 벡터k-NN + 하이브리드 검색, Bedrock Knowledge Bases 기본
Amazon S3 Vectors관리형20억/인덱스최대 90% 비용 절감, S3 네이티브
FAISS (인메모리)자체 관리수백만 벡터로컬 개발, 빠른 프로토타입
Pinecone외부 SaaS수십억 벡터멀티테넌시, 메타데이터 필터
takeaway

프로덕션 RAG는 OpenSearch Serverless, 대규모·비용 민감 워크로드는 S3 Vectors, 프로토타입은 FAISS가 출발점입니다.

RAG는 모델을 바꾸지 않고 답의 품질을 높이는 가장 효과적인 방법입니다.

인덱싱과 검색 파이프라인을 이해해야 올바른 RAG를 설계합니다.