청킹 및 옵션
청킹은 문서를 검색 가능한 단위(청크) 로 나누는 과정입니다. 어떤 청킹 전략과 옵션을 고르느냐가 검색 품질을 좌우합니다. 이 문서에서는 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에서 전체 초기화 후 재수집해야 합니다.