청킹 및 옵션
청킹은 문서를 검색 가능한 단위(청크) 로 분할하는 과정입니다. 적절한 청킹 전략과 옵션 선택이 검색 품질에 영향을 미칩니다. 이 문서에서는 D.Hub Knowledge에서 사용 가능한 청킹 전략, 파라미터, 임베딩 모델, 저장소별 동작 방식을 종합적으로 안내합니다.
대부분의 사용자는 기본값(청킹 전략 하이브리드, 최대 청크 길이 500, 오버랩 50)을 그대로 두어도 좋은 결과를 얻습니다. 이 문서는 검색 품질을 세밀하게 조정하려는 경우의 참고 자료입니다 — 아래 고급 옵션을 모두 이해하지 않아도 됩니다. (용어가 낯설면 개요의 핵심 용어를 먼저 참고하세요.)
청킹 전략
문서를 청크로 분할하는 알고리즘입니다. 문서의 형식과 용도에 따라 적절한 전략을 선택하면 검색 품질을 높일 수 있습니다. D.Hub Knowledge는 다음 8가지 전략을 제공합니다.
| 전략 | 설명 | 추천 사용 사례 |
|---|---|---|
| 하이브리드 (hybrid) | 마크다운 구조 인식 + 고정 크기 분할을 결합한 복합 전략 (기본값) | 대부분의 문서에 범용으로 적합 |
| 마크다운 (markdown) | 마크다운 헤딩(#, ##, ### 등) 기준으로 섹션 단위 분할 (웹 크롤링 기본값) | 구조화된 문서 (MD, HTML, 기술 문서) |
| 계층적 (hierarchical) | 문서의 계층 구조(섹션 → 하위 섹션 → 단락)를 유지하며 분할 | 긴 학술 논문, 법률 문서, 사양서 |
| 고정 크기 (fixed) | 지정된 토큰 수로 균일하게 분할. 문서 구조를 무시함 | 비구조적 텍스트, 로그, 대화 기록 |
| 상위-하위 (parent_child) | 큰 부모 청크와 작은 자식 청크를 쌍으로 생성. 검색은 자식으로, 컨텍스트는 부모에서 제공 | 상세 검색과 넓은 컨텍스트가 동시에 필요한 경우 |
| 문장 (sentence) | 문장 경계 기준으로 분할한 뒤 길이 파라미터로 묶음 | 구어체·회의록·QA 로그 등 문장 단위 의미 보존 필요 |
| 시맨틱 (semantic) | 임베딩 유사도의 브레이크포인트를 찾아 의미 경계에서 분할 | 주제 전환이 잦은 긴 문서, 블로그, 뉴스 |
| 에이전틱 (agentic) | 단락 단위 요약을 기반으로 에이전트가 유사 단락을 묶어 의미 청크 구성 | 비정형·장문 리포트, 계약서, 원고 |
어떤 전략을 선택해야 할지 모르겠다면 기본값인 하이브리드 (hybrid) 를 사용하세요. 문서 구조를 인식하면서도 고정 크기 분할의 안정성을 결합하여 대부분의 상황에서 좋은 결과를 제공합니다. 주제 경계 인식이 중요한 긴 문서에는 시맨틱 (semantic) 을, 문서 전체 맥락을 고려한 지능적 그룹핑이 필요하면 에이전틱 (agentic) 을 선택합니다.
청킹 파라미터
청크의 크기와 겹침 정도를 제어하는 파라미터입니다. 모든 청킹 전략에 공통으로 적용됩니다.
최대 청크 길이 (max_chunk_length)
하나의 청크에 포함되는 최대 토큰 수입니다.
| 항목 | 값 |
|---|---|
| 기본값 | 500 |
| 범위 | 100 ~ 4,000 |
- 값이 작을 때: 청크가 세밀하게 분할되어 정밀한 검색이 가능하지만, 컨텍스트가 부족할 수 있음
- 값이 클 때: 청크에 더 많은 컨텍스트가 포함되지만, 검색 정밀도가 떨어질 수 있음
오버랩 길이 (overlap_length)
인접한 청크 간에 겹치는 토큰 수입니다. 오버랩을 설정하면 청크 경계에서 컨텍스트가 끊기는 것을 방지합니다.
| 항목 | 값 |
|---|---|
| 기본값 | 50 |
| 범위 | 0 ~ 500 |
오버랩은 최대 청크 길이의 10~20% 로 설정하는 것이 좋습니다. 예를 들어 최대 청크 길이가 500이면 오버랩은 50~100 사이가 적절합니다. 너무 큰 오버랩은 중복 데이터를 불필요하게 증가시키고, 너무 작은 오버랩은 경계 컨텍스트 손실을 야기합니다.
max_chunk_length와 overlap_length는 공통 파라미터입니다. 단, 에이전틱 (agentic) 전략은 자체 max_chunk_tokens/min_chunk_tokens/paragraph_max_tokens를 사용하므로 공통 파라미터가 화면에 표시되지 않습니다.
Semantic 전략 전용 옵션
의미 브레이크포인트로 분할하는 semantic 전략은 다음 4가지 추가 옵션을 제공합니다.
| 옵션 | 설명 | 기본값 | 범위 |
|---|---|---|---|
| 임베딩 모델 (Embedding Model) | 문장 유사도를 계산할 때 사용할 임베딩 모델 | KoE5 | 서버에서 제공되는 모델 목록 |
| 중단점 유형 (Breakpoint Type) | 의미 경계 판정 지표 유형(백분위수 · 표준 편차 · 사분위수 · 기울기) | 기울기 (gradient) | 4개 중 선택 |
| 중단점 임계값 (Breakpoint Threshold) | 경계 판정 임계값 (해석은 유형에 따라 다름) | 95.0 | 0 ~ 100 (0.5 간격) |
| 최소 청크 토큰 (Min Chunk Tokens) | 청크가 될 수 있는 최소 토큰 수 | 50 | 10 ~ 500 |
- 백분위수 (percentile): 문장 간 거리 상위 N 분위를 경계로 사용합니다.
- 표준 편차 (standard_deviation): 평균 + k·σ를 경계로 사용합니다.
- 사분위수 (interquartile): IQR(1.5·IQR) 바깥을 경계로 사용합니다.
- 기울기 (gradient): 거리 변화율(2차 미분)이 큰 지점을 경계로 사용합니다. 대부분의 한국어 문서에서 가장 자연스러운 결과를 제공합니다.
Agentic 전략 전용 옵션
문서를 단락으로 전처리한 뒤 임베딩 유사도로 병합하는 에이전트 기반 전략입니다.
| 옵션 | 설명 | 기본값 | 범위 |
|---|---|---|---|
| 임베딩 모델 (Embedding Model) | 단락 간 유사도 비교 모델 | KoE5 | 서버에서 제공되는 모델 목록 |
| 단락 최대 토큰 (Paragraph Max Tokens) | 초기 단락 분할 시 한 단락의 최대 토큰 수 | 250 | 50 ~ 1,000 |
| 유사도 임계값 (Similarity Threshold) | 인접 단락을 같은 청크로 묶기 위한 최소 유사도 | 0.75 | 0 ~ 1 (0.01 간격) |
| 최소 청크 토큰 (Min Chunk Tokens) | 최종 청크가 될 수 있는 최소 토큰 수 | 60 | 10 ~ 500 |
| 최대 청크 토큰 (Max Chunk Tokens) | 최종 청크의 최대 토큰 수 | 512 | 64 ~ 2,048 |
agentic 전략은 공통
max_chunk_length/overlap_length를 사용하지 않습니다. 크기 제어는 위의 전용 파라미터로 이루어집니다.
임베딩 모델
임베딩 모델은 텍스트를 고차원 벡터로 변환하여 의미 기반 유사도 검색을 가능하게 합니다. VECTOR 검색 방법을 사용할 때 적용됩니다.
사용 가능한 모델
사용 가능한 임베딩 모델 목록은 서버 환경에 따라 동적으로 제공됩니다. Knowledge 생성 시 Settings에서 모델 드롭다운을 통해 현재 사용 가능한 모델을 확인할 수 있습니다.
일반적으로 제공되는 모델의 예시:
| 모델 | Dimensions | 특징 |
|---|---|---|
| KoE5 | 1,024 | 한국어 특화, semantic/agentic 청킹의 기본 임베딩 |
| multilingual-e5-large | 1,024 | 다국어 지원, 높은 정확도 |
| paraphrase-multilingual-MiniLM-L12-v2 | 384 | 다국어 경량 모델 |
| all-MiniLM-L6-v2 | 384 | 경량 모델, 빠른 처리 속도 |
| all-MiniLM-L12-v2 | 384 | L6 대비 약간 높은 정확도 |
| all-mpnet-base-v2 | 768 | 영어 기준 높은 품질 |
실제 사용 가능한 모델은 D.Hub 인스턴스 구성에 따라 다를 수 있습니다(목록은 서버에서 제공). Knowledge의 VECTOR 임베딩 모델은 생성/Settings 화면에서 선택하며, semantic·agentic 청킹의 기본 임베딩 모델은 KoE5입니다.
Dimensions(차원 수)이 높을수록 텍스트의 의미를 더 세밀하게 표현할 수 있어 검색 정확도가 향상될 수 있습니다. 반면 저장 공간과 검색 연산 비용이 증가합니다. 한국어 위주 데이터에는 KoE5(1,024차원), 다국어 데이터에는 multilingual-e5-large(1,024차원)가 품질과 성능의 균형이 좋습니다.
임베딩 모델을 변경하면 기존 인덱싱된 벡터와 호환되지 않습니다. 모델 변경 시 반드시 Settings의 설정 초기화(Reset)를 수행하고 모든 문서를 재인덱싱해야 합니다.
저장소별 동작
Knowledge는 선택한 검색 방법에 따라 최대 세 가지 저장소에 데이터를 저장합니다. 각 저장소는 서로 다른 검색 방식을 지원합니다.
Vector (벡터 DB)
| 항목 | 설명 |
|---|---|
| 저장 데이터 | 청크 텍스트의 임베딩 벡터 + 원본 텍스트 + 메타데이터 |
| 검색 방식 | 코사인 유사도 기반 의미 검색 |
| 적합한 쿼리 | 개념적 질문, 동의어/유사 표현 검색, 자연어 질의 |
| 필요 설정 | 임베딩 모델 선택 필수 |
Text (텍스트 검색)
| 항목 | 설명 |
|---|---|
| 저장 데이터 | 청크 원문 텍스트 + 역색인(Inverted Index) + 메타데이터 |
| 검색 방식 | BM25 알고리즘 기반 키워드 검색 |
| 적합한 쿼리 | 고유명사, 코드명, 정확한 키워드, 특정 용어 검색 |
| 필요 설정 | 추가 설정 없음 (임베딩 불필요) |
Graph (그래프 DB)
| 항목 | 설명 |
|---|---|
| 저장 데이터 | 청크에서 추출된 엔티티(노드)와 관계(엣지) |
| 검색 방식 | 그래프 탐색, 경로 검색, 패턴 매칭 |
| 적합한 쿼리 | 엔티티 간 관계 탐색, "A와 B의 관계는?", 연결 분석 |
| 필요 설정 | 추가 설정 없음 (엔티티/관계 자동 추출) |
VECTOR와 TEXT를 모두 선택한 경우, Hybrid 검색이 가능합니다. 두 저장소의 결과를 Reciprocal Rank Fusion(RRF) 알고리즘으로 병합하여 의미 검색과 키워드 검색의 장점을 결합합니다.
GRAPH 저장소(엔티티/관계 추출)는 현재 생성·설정 화면에서 선택 비활성 상태이며 향후 제공될 예정입니다. 따라서 실제 사용 가능한 조합은 VECTOR + TEXT입니다.
대부분의 경우 VECTOR + TEXT 조합이 가장 효과적입니다.
옵션 간 상호 관계
청킹, 임베딩, 저장소 옵션은 서로 연결되어 전체 검색 파이프라인의 품질을 결정합니다.
문서 → [청킹 전략 + 파라미터] → 청크 → [임베딩 모델] → 벡터 → [저장소]
│ │
└──── 원본 텍스트 ──────────────┘
| 단계 | 관련 옵션 | 영향 |
|---|---|---|
| 분할 | 청킹 전략, max_chunk_length, overlap_length | 청크의 크기와 컨텍스트 범위 결정 |
| 벡터화 | 임베딩 모델 | 의미 표현의 정밀도와 다국어 성능 결정 |
| 저장 | Search Methods | 사용 가능한 검색 모드 결정 |
청킹 전략이나 파라미터를 변경해도 이미 인덱싱된 문서에는 소급 적용되지 않습니다. 변경된 옵션은 이후 새로 추가되는 문서부터 적용됩니다. 기존 문서에 변경된 옵션을 적용하려면 해당 문서를 개별적으로 재인덱싱하거나, Settings에서 전체 초기화 후 재수집해야 합니다.