청킹 및 옵션
청킹은 문서를 검색 가능한 단위(청크) 로 분할하는 과정입니다. 적절한 청킹 전략과 옵션 선택이 검색 품질에 결정적인 영향을 미칩니다. 이 문서에서는 D.Hub Knowledge에서 사용 가능한 청킹 전략, 파라미터, 임베딩 모델, 저장소별 동작 방식, 인덱싱 품질 모드를 종합적으로 안내합니다.
청킹 전략
문서를 청크로 분할하는 알고리즘입니다. 문서의 형식과 용도에 따라 적절한 전략을 선택하면 검색 품질을 높일 수 있습니다.
| 전략 | 설명 | 추천 사용 사례 |
|---|---|---|
| hybrid | 마크다운 구조 인식 + 고정 크기 분할을 결합한 복합 전략 (기본값) | 대부분의 문서에 범용으로 적합 |
| markdown | 마크다운 헤딩(#, ##, ### 등) 기준으로 섹션 단위 분할 | 구조화된 문서 (MD, HTML, 기술 문서) |
| hierarchical | 문서의 계층 구조(섹션 → 하위 섹션 → 단락)를 유지하며 분할 | 긴 학술 논문, 법률 문서, 사양서 |
| fixed | 지정된 토큰 수로 균일하게 분할. 문서 구조를 무시함 | 비구조적 텍스트, 로그, 대화 기록 |
| parent_child | 큰 부모 청크와 작은 자식 청크를 쌍으로 생성. 검색은 자식으로, 컨텍스트는 부모에서 제공 | 상세 검색과 넓은 컨텍스트가 동시에 필요한 경우 |
어떤 전략을 선택해야 할지 모르겠다면 기본값인 hybrid를 사용하세요. 문서 구조를 인식하면서도 고정 크기 분할의 안정성을 결합하여 대부분의 상황에서 좋은 결과를 제공합니다.
청킹 파라미터
청크의 크기와 겹침 정도를 제어하는 파라미터입니다. 모든 청킹 전략에 공통으로 적용됩니다.
최대 청크 길이 (max_tokens)
하나의 청크에 포함되는 최대 토큰 수입니다.
| 항목 | 값 |
|---|---|
| 기본값 | 500 |
| 범위 | 100 ~ 4,000 |
- 값이 작을 때: 청크가 세밀하게 분할되어 정밀한 검색이 가능하지만, 컨텍스트가 부족할 수 있음
- 값이 클 때: 청크에 더 많은 컨텍스트가 포함되지만, 검색 정밀도가 떨어질 수 있음
오버랩 길이 (overlap_length)
인접한 청크 간에 겹치는 토큰 수입니다. 오버랩을 설정하면 청크 경계에서 컨텍스트가 끊기는 것을 방지합니다.
| 항목 | 값 |
|---|---|
| 기본값 | 50 |
| 범위 | 0 ~ 500 |
오버랩은 최대 청크 길이의 10~20% 로 설정하는 것이 좋습니다. 예를 들어 최대 청크 길이가 500이면 오버랩은 50~100 사이가 적절합니다. 너무 큰 오버랩은 중복 데이터를 불필요하게 증가시키고, 너무 작은 오버랩은 경계 컨텍스트 손실을 야기합니다.
임베딩 모델
임베딩 모델은 텍스트를 고차원 벡터로 변환하여 의미 기반 유사도 검색을 가능하게 합니다. VECTOR 검색 방법을 사용할 때 적용됩니다.
사용 가능한 모델
사용 가능한 임베딩 모델 목록은 서버 환경에 따라 동적으로 제공됩니다. Knowledge 생성 시 Settings에서 모델 드롭다운을 통해 현재 사용 가능한 모델을 확인할 수 있습니다.
일반적으로 제공되는 모델의 예시:
| 모델 | Dimensions | 특징 |
|---|---|---|
| multilingual-e5-large | 1,024 | 다국어 지원, 높은 정확도 (기본값) |
| all-MiniLM-L6-v2 | 384 | 경량 모델, 빠른 처리 속도 |
| all-MiniLM-L12-v2 | 384 | L6 대비 약간 높은 정확도 |
| all-mpnet-base-v2 | 768 | 영어 기준 높은 품질 |
실제 사용 가능한 모델은 D.Hub 인스턴스 구성에 따라 다를 수 있습니다.
Dimensions(차원 수)이 높을수록 텍스트의 의미를 더 세밀하게 표현할 수 있어 검색 정확도가 향상될 수 있습니다. 반면 저장 공간과 검색 연산 비용이 증가합니다. 일반적인 사용 환경에서는 기본값인 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) 알고리즘으로 병합하여 의미 검색과 키워드 검색의 장점을 결합합니다.
대부분의 경우 VECTOR + TEXT 조합이 가장 효과적입니다. 엔티티 간 관계 탐색이 필요한 경우에만 GRAPH를 추가하세요.
인덱싱 품질 모드
문서 인덱싱 시 품질과 속도 간의 트레이드오프를 제어하는 옵션입니다.
| 모드 | 설명 | 처리 속도 | 검색 품질 |
|---|---|---|---|
| High-Quality | 더 정밀한 청킹, 임베딩, 엔티티 추출 수행 | 느림 | 높음 |
| Economical | 처리 단계를 간소화하여 빠르게 인덱싱 | 빠름 | 보통 |
모드 선택 가이드
| 상황 | 추천 모드 |
|---|---|
| 중요한 지식 베이스 구축 (프로덕션) | High-Quality |
| 빠른 테스트 및 프로토타이핑 | Economical |
| 대량 문서 일괄 인덱싱 | Economical (이후 주요 문서만 재인덱싱) |
| 소량의 핵심 문서 | High-Quality |
High-Quality 모드는 Economical 대비 인덱싱 시간이 더 소요되지만, 청크 경계가 더 자연스럽고 임베딩 품질이 높아 검색 결과의 관련도가 향상됩니다. 문서 수가 적고 검색 품질이 중요한 프로덕션 환경에서는 High-Quality를 권장합니다.
옵션 간 상호 관계
청킹, 임베딩, 저장소 옵션은 서로 연결되어 전체 검색 파이프라인의 품질을 결정합니다.
문서 → [청킹 전략 + 파라미터] → 청크 → [임베딩 모델] → 벡터 → [저장소]
│ │
└──── 원본 텍스트 ──────────────┘
| 단계 | 관련 옵션 | 영향 |
|---|---|---|
| 분할 | 청킹 전략, max_tokens, overlap_length | 청크의 크기와 컨텍스트 범위 결정 |
| 벡터화 | 임베딩 모델 | 의미 표현의 정밀도와 다국어 성능 결정 |
| 저장 | Search Methods | 사용 가능한 검색 모드 결정 |
| 품질 | 인덱싱 품질 모드 | 전체 파이프라인의 정밀도와 속도 결정 |
청킹 전략이나 파라미터를 변경해도 이미 인덱싱된 문서에는 소급 적용되지 않습니다. 변경된 옵션은 이후 새로 추가되는 문서부터 적용됩니다. 기존 문서에 변경된 옵션을 적용하려면 해당 문서를 개별적으로 재인덱싱하거나, Settings에서 전체 초기화 후 재수집해야 합니다.