2nd/10_Wiki/Topics/Topics_Rag/문서 청킹 전략.md

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

id	title	category	status	verification_status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	created_at	updated_at	review_reason	merge_history	tags	raw_sources	applied_in	github_commit
문서-청킹-전략	문서 청킹 전략	AI_and_ML	draft	conceptual		Text Chunking Document Splitting 텍스트 분할 기법 청크 사이즈 최적화 Chunking Strategy RecursiveCharacterTextSplitter Semantic Chunking		A	0.95	2026-06-08	2026-06-08			research RAG Chunking Preprocessing Index-Optimization	1. RAG 파이프라인 기초 아키텍처 RAG Architecture: 4 Key Components & Example Implementation - Cloudian RAG Pipeline - velog RAG 솔루션 디자인 및 개발 - Azure Architecture Center - Microsoft Learn [Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화 RAG 기술의 진화: Naive에서 Modular까지 총정리 - 슈퍼브 블로그	01_RAG_파이프라인_기초_아키텍처.ipynb Parent Document Retriever implementation Azure AI Search Indexing Pipeline

문서 청킹 전략

🎯 한 줄 통찰 (One-line insight)

청킹은 검색의 정밀도(Precision)와 문맥의 풍부함(Context) 사이의 트레이드오프를 최적화하여 RAG 시스템의 답변 품질을 결정하는 핵심 전처리 공정이다 [S17, S122, S168].

🧠 핵심 개념 (Core concepts)

• 청크 사이즈 (Chunk Size): 문서를 분할하는 텍스트의 크기로, 임베딩 모델의 토큰 제한과 검색 단위의 정밀도를 결정한다 [S18, S27, S62].
• 청크 오버랩 (Chunk Overlap): 분할된 청크 간의 중첩 영역으로, 청크 경계에서 문맥이 단절되는 것을 방지하고 정보의 연속성을 유지한다 [S18, S62].
• 구분자 우선순위 (Separator Priority): 재귀적 분할 시 문단(\n\n), 줄(\n), 단어( ) 등의 순서로 의미 단위를 최대한 보존하며 나누는 기준이다 [S17, S61].
• 시맨틱 경계 (Semantic Boundary): 텍스트의 의미적 유사도가 급격히 변하는 지점을 계산하여 내용적으로 일관된 단위로 분할하는 기법이다 [S20, S64, S238].

🧩 추출된 패턴 (Extracted patterns)

• Structure-then-Size Pattern: 마크다운 헤더나 HTML 태그 등 문서의 논리적 구조로 먼저 나눈 뒤, 각 섹션이 너무 크면 크기 기반(Recursive)으로 재분할하는 복합 전략이다 [S21, S22, S65].
• Small-to-Big Retrieval Pattern: 검색은 작은 청크(자식)로 정밀하게 수행하되, 생성 단계에서는 더 큰 주변 문맥(부모 청크)을 LLM에 전달하여 정확도와 이해도를 동시에 확보한다 [S31, S36, S75, S80].
• Token-Model Alignment: 사용하는 임베딩 모델의 실제 토크나이저와 일치하는 토큰 기반 분할기를 사용하여 하드웨어/API 제약 조건 내에서 최대 정보를 수용한다 [S19, S27, S71].

📖 세부 내용 (Details)

1. 주요 청킹 전략 유형 및 특징 [S17, S22, S61, S66]

전략	클래스	주요 특징	최적 적합 사례
재귀적 문자 분할	RecursiveCharacterTextSplitter	문단→줄→단어 순으로 자연스러운 경계 시도 [S18].	일반 텍스트, 보고서 (가장 범용적)
토큰 기반 분할	TokenTextSplitter	LLM의 토큰 제한에 정확히 맞춰 분할 [S19].	정확한 토큰 수 관리가 필요한 경우
구조 기반 분할	Markdown/HTML HeaderSplitter	헤더(#, ) 계층에 따라 논리적 섹션 보존 [S19, S21].	기술 문서, API 가이드, 웹 문서
시맨틱 분할	SemanticChunker	임베딩 유사도를 기반으로 의미 변화 지점 포착 [S20].	주제 변화가 잦은 복합 문서

2. 실무 파라미터 정의 기준 [S18, S23, S27, S62, S67, S71]

• 기본 권장값: 대중적으로 chunk_size 5001000자, chunk_overlap은 크기의 1015%(50~150자) 수준에서 시작하여 품질 평가를 통해 튜닝한다 [S23, S67].
• 임베딩 모델 제약: OpenAI(8191 토큰), Gemini(2048 토큰) 등 모델별 최대 입력 단위를 초과하지 않도록 설정해야 하며, 토큰 기반 분할 시 인코딩(cl100k_base 등)을 일치시켜야 오차가 없다 [S27, S71].
• 도메인 특화: 법률/계약서처럼 문맥 보존이 중요한 경우 10002000자의 큰 단위를, FAQ/용어집처럼 개별 항목이 명확한 경우 200500자의 작은 단위를 사용한다 [S22, S66].

3. 고도화된 청킹 및 인덱싱 기법 [S36, S80, S238]

• Parent Document Retriever: 검색용 '자식 청크'는 작게(300500자) 설정하여 검색 재현율을 높이고, 반환되는 '부모 청크'는 크게(15002000자) 설정하여 LLM이 충분한 근거를 갖게 한다 [S36, S80].
• 계층적 인덱싱: 미시적 개체 정보를 담은 청크와 거시적 요약 정보를 담은 커뮤니티 요약을 계층화하여 검색 범위를 유연하게 조절한다 [S277].

⚖️ 모순 및 업데이트 (Contradictions & updates)

• 고정 크기 vs 시맨틱: 고정 크기 분할은 속도가 빠르고 예측 가능하지만 문맥이 잘릴 위험이 있고, 시맨틱 분할은 품질이 우수하지만 임베딩 모델 추가 호출로 인한 비용과 시간이 발생한다는 트레이드오프가 존재한다 [S20, S64].
• 재인덱싱의 비가역성: chunk_size나 전략을 변경하면 문맥 경계가 불일치해지므로, 기존에 구축된 벡터 DB 인덱스를 100% 재구축(재임베딩)해야 한다 [S28, S72].

🛠️ 적용 사례 (Applied in summary)

• 주피터 노트북: 01_RAG_파이프라인_기초_아키텍처.ipynb에서 RecursiveCharacterTextSplitter를 활용한 세법 문서 분할 예제가 구현되어 있다 [S10, S54].
• Parent Document 전략: 실무에서 부모 2000자, 자식 400자 설정을 통해 긴 법률 문서의 정밀 검색과 전체 문맥 확인을 병행하는 아키텍처가 제안되었다 [S37, S81].
• KT Cloud RAG Suite: 이미지, PDF, 워드 등 다양한 문서 유형에 대해 레이아웃과 표 구조를 보존하며 최적화된 청킹을 제공하는 API 서비스로 운영되고 있다 [S342, S393].

🔎 코드베이스 근거 (자동 추출 — E:\Wiki 레포)

실제 구현/사용 위치:

• connectai/src/retrieval/chunker.ts:7 — * 쪼개면 질의가 정확히 해당 섹션에 매치된다 (제2뇌의 "문서 청킹 전략" 지식 그대로).
• connectai/src/retrieval/evalHarness.ts:13 — * { "query": "RAG 청킹 전략 비교", "expected": ["문서 청킹 전략.md"], "note": "선택" }

자동 생성: code_grounding.mjs · 재실행 시 갱신됨

✅ 검증 상태 및 신뢰도

• 상태: draft
• 검증 단계: conceptual (실제 구현 코드 및 라이브러리 가이드 기반)
• 출처 신뢰도: A (Microsoft, Azure, kt cloud, Cloudian 등 기술 전문 조직의 가이드라인 기반)
• 신뢰 점수: 0.95
• 중복 검사 결과: 신규 생성 (New discovery)

🔗 관련 문서 링크 (Related document links)

상위/유사 개념

[아키텍처/기반 기술]

• RAG 아키텍처 및 파이프라인 기초
  • 연결 이유: 청킹은 RAG 파이프라인 7단계 중 검색 품질을 결정짓는 두 번째 핵심 단계임 [S8, S53].
• 텍스트 임베딩 모델
  • 연결 이유: 임베딩 모델의 물리적 토큰 제한이 청킹 전략의 기술적 제약 조건이 됨 [S27, S71].

[구현/활용 도구]

• 벡터 데이터베이스
  • 연결 이유: 청킹된 결과물이 임베딩되어 영구 저장되는 물리적 장소임 [S28, S73].
• 데이터 인덱싱 및 오케스트레이션
  • 연결 이유: 대규모 데이터셋의 청킹 및 인덱싱 프로세스를 관리하는 상위 워크플로우 [S220, S269].

심층 후속 질문 (Deeper Research Questions)

• 시맨틱 청킹 시 사용되는 breakpoint_threshold_amount의 최적값을 도메인별(법률 vs 일반)로 자동 산출할 수 있는 방법은 무엇인가? [S21, S65]
• 멀티모달 데이터(이미지+표)를 포함한 문서에서 레이아웃을 깨지 않고 청킹하는 최신 비전 기반 파싱 기법의 성능 차이는? [S312, S363]
• 청크 사이즈를 동적으로 조절할 때, 검색 단계에서의 랭킹 알고리즘(RRF 등)이 청크 간 길이 불균형에 얼마나 민감하게 반응하는가? [S193, S206]

실무 적용 맥락 (Practical Application Contexts)

• Implementation: LangChain의 RecursiveCharacterTextSplitter를 기본으로 사용하고, chunk_size 500/1000/1500으로 실험 수행 [S23, S67].
• System Design: 구조화된 문서(마크다운)의 경우 반드시 MarkdownHeaderTextSplitter를 선행 적용하여 논리 구조 보존 [S22, S66].
• Operation / Maintenance: 원본 문서의 20% 이상이 변경되거나 청킹 파라미터 수정 시 인덱스 전체 재구축 스케줄 수립 [S28, S72].
• Learning Path: 분할 원리 이해 -> 오버랩 효과 실험 -> 구조 기반 분할 실습 -> 시맨틱 청킹 도입 순으로 학습 [S1, S45].

인접 주변 주제

• 텍스트 토크나이저
  • 확장 방향: BPE, WordPiece 등 분할 기준이 되는 토큰화 알고리즘의 원리 이해 [S314, S365].

🔗 지식 그래프 (Knowledge Graph)

• 상위/루트: RAG 아키텍처 및 파이프라인 기초
• 관련 개념: 텍스트 임베딩 모델, 벡터 데이터베이스, Parent Document Retriever, 시맨틱 청킹
• 참조 맥락: 비정형 문서의 지식 밀도를 유지하며 검색 성능을 최적화해야 하는 전처리 설계 단계에서 참조.

📚 출처 (Sources)

• [S17] 단계 2: 청킹(Text Chunking/Splitting) 개요 (devspoon)
• [S18] RecursiveCharacterTextSplitter 상세 및 파라미터 (devspoon)
• [S21] SemanticChunker 동작 원리 및 설정 (devspoon)
• [S22] 실무에서의 청킹 전략 선택 가이드 및 복합 전략 (devspoon)
• [S27] 청킹 모델과 임베딩 모델의 선택 기준 (devspoon)
• [S36] Parent Document Retriever 상세 (devspoon)
• [S122] 검색 세밀도와 모델 컨텍스트 제한의 정렬 (Cloudian)
• [S168] 청킹 튜닝 및 인덱스 분할 전략 (Cloudian)
• [S238] Advanced RAG 인덱싱 개선 기법 (슈퍼브 블로그)
• [S260] Azure RAG 데이터 파이프라인 흐름 (Microsoft Learn)
• [S342] kt cloud AI Foundry RAG Suite 파싱 및 청킹 기능 (kt cloud)
• [S360] 비정형 데이터 레이아웃 보존 파싱 (kt cloud)

📝 변경 이력 (Change history)

• 2026-06-08: Initial draft generated via Datacollector_MAC P-Reinforce engine.