슬라이딩 윈도우 청킹 (Sliding Window Chunking)

슬라이딩 윈도우 청킹 (Sliding Window Chunking)은 더 집중적인 청킹 (chunking) 메커니즘입니다. 이 방법에서는 문자(character) 또는 토큰(token) 제한을 기반으로 윈도우 크기 (window size)를 정의합니다. 완전히 분리된 청크 (chunks)를 만드는 대신, 윈도우는 이전 콘텐츠의 일부를 유지하면서 점진적으로 앞으로 이동합니다. 문자 또는 토큰 제한을 윈도우 크기 (window size)라고 부르며, 윈도우가 매번 앞으로 이동하는 양을 스텝 크기 (step size)라고 부릅니다. 이는 중첩 청킹 (overlapping chunking)의 더 엄격한 형태입니다.

작동 방식

가정:
윈도우 크기 (Window size) = 500자
스텝 크기 (Step size) = 100자

첫 번째 청크 (chunk)는 1500번째 문자를 포함할 수 있습니다. 두 번째 청크는 100자를 이동한 후 시작되어 101600번째 문자를 포함할 수 있습니다. 이러한 중첩 (overlap) 덕분에 관련된 정보가 여러 청크에 걸쳐 반복적으로 포함됩니다.

장점
이 방법의 주요 장점은 의미론적으로 관련된 지점들이 벡터 데이터베이스 (vector database) 내에서 마치 클러스터 (clusters)처럼 서로 더 가깝게 저장된다는 것입니다. 이는 문맥 (context)이 빈번하게 변하는 시나리오에서 검색 (retrieval) 성능을 향상시킵니다.

단점

문제 1: 더 높은 토큰 소비 (Higher Token Consumption)
중첩된 데이터가 반복적으로 임베딩 (embedded)되기 때문에, 임베딩 모델 (embedding model)이 더 많은 토큰을 소비합니다. 로컬 임베딩 모델 (local embedding models)을 사용하지 않는 한 이는 계산 비용을 증가시킵니다.

문제 2: 중복 검색 (Duplicate Retrieval)
관련된 청크들이 매우 가깝게 저장되기 때문에, LLM은 서로 다른 문맥을 검색하는 대신 여러 개의 중복되거나 거의 동일한 청크를 검색할 수 있습니다. 그 결과:

• 문맥 다양성 (Context diversity) 감소
• 토큰 사용량 증가
• 검색 효율성 (Retrieval efficiency) 저하 가능성

슬라이딩 윈도우 청킹이 유용한 경우
슬라이딩 윈도우 청킹은 문맥 전환 (context switching)이 빈번하게 발생하는 시나리오에서 유용합니다.

예시: 소스 코드 (Source Code)
코딩 관련 데이터셋의 경우:

• 코드의 서로 다른 부분이 직접적으로 연관되어 있지 않을 수 있습니다.
• 하나의 서비스나 모듈이 다른 서비스를 간접적으로 트리거할 수 있습니다.
• 중요한 문맥 (context)이 여러 섹션에 걸쳐 존재할 수 있습니다.
  예를 들어, 마이크로서비스 아키텍처 (microservices architecture)에서는:
• 하나의 서비스 이벤트가 다른 서비스의 트리거가 될 수 있습니다.
• 관련 로직이 서로 다른 파일이나 서비스에 존재할 수 있습니다.
  슬라이딩 윈도우 청킹은 토큰 소비량이 더 높음에도 불구하고, 이러한 관계를 보존하는 데 도움을 줍니다.

토큰 기반 청킹 (Token Based Chunking)
토큰 기반 청킹은 주로 비용 최적화와 모델의 제한 사항에 초점을 맞춥니다.
LLM (Large Language Models)은 텍스트를 단어가 아닌 토큰 (token) 단위로 처리합니다.
토크나이저 (tokenizer)와 모델에 따라 다음과 같이 달라집니다:

• 하나의 단어가 하나의 토큰이 될 수 있습니다.
• 하나의 단어가 여러 개의 토큰이 될 수 있습니다.
• 때로는 단일 문자 하나가 하나의 토큰이 될 수도 있습니다.
  모델에는 토큰 입력 제한이 있으므로, 콘텐츠가 허용된 토큰 크기 내에 머물도록 하기 위해 토큰 기반 청킹이 사용됩니다.
  이 방식에서는:
• 토큰 수에 따라 텍스트를 분할합니다.
• 청크 (chunks)를 임베딩 벡터 (embedding vectors)로 변환합니다.
• 벡터를 벡터 데이터베이스 (vector database)에 저장합니다.
  이 방법은 주로 엄격한 토큰 제약 조건이 있는 환경에서 사용됩니다.

TOON (Token-Oriented Object Notation)
TOON은 Token-Oriented Object Notation의 약자입니다.
이는 JSON과 비교하여 토큰 사용량을 줄이기 위해 설계된 대안적인 표현 형식입니다.
JSON은 사람이 읽기 쉽지만, 반복되는 키 (keys)가 토큰 소비를 증가시킵니다.
반복되는 구조와 키는 토큰 사용량을 높입니다.
TOON은 반복되는 키를 줄이고 동일한 정보를 더 토큰 효율적인 형식으로 표현합니다.
그 목적은 문맥을 보존하면서 임베딩 및 추론 (inference) 비용을 줄이는 것입니다.

LLMLingua
LLMLingua는 프롬프트 압축 (prompt compression)에 사용되는 프레임워크입니다.
이는 원래의 의미와 문맥을 보존하면서 사용자 질의(query)나 프롬프트를 단순화된 버전으로 변환합니다.
주요 목표는 다음과 같습니다:

• 토큰 소비 감소
• 추론 비용 절감
• 효율성 향상
  하지만 공격적인 압축은 때때로 원래의 JSON 또는 텍스트 구조와 비교했을 때 검색 (retrieval) 품질을 저하시킬 수 있습니다.

청킹 방법 요약 (Summary of Chunking Methods)
일반적으로 사용되는 청킹 (Chunking) 방법은 다음과 같습니다:

• 고정 크기 청킹 (Fixed Chunking)
• 중첩 청킹 (Overlapping Chunking)
• 의미론적 청킹 (Semantic Chunking)
• 임베딩 기반 청킹 (Embedding-Based Chunking)
• 슬라이딩 윈도우 청킹 (Sliding Window Chunking)
• 토큰 기반 청킹 (Token-Based Chunking)

이 방법들은 서로 다른 접근 방식과 트레이드오프 (trade-offs)를 나타냅니다. 실제 애플리케이션에서는 다음과 같은 요소에 따라 여러 청킹 방법을 결합하여 사용하는 경우가 많습니다:

• 데이터셋 유형 (Dataset type)
• 검색 품질 (Retrieval quality)
• 비용 제약 (Cost constraints)
• 토큰 제한 (Token limitations)
• 애플리케이션 요구 사항 (Application requirements)

모든 데이터셋에 가장 잘 작동하는 단일 청킹 전략은 존재하지 않습니다.

RAG 시스템에서의 PDF 읽기 (PDF Reading in RAG Systems)
기업 내부 통신 파일과 같은 문서를 처리하려면, 먼저 PDF를 읽을 수 있는 텍스트로 변환해야 합니다. LangChain 프레임워크 하에서 이 목적으로 흔히 사용되는 라이브러리는 다음과 같습니다:

• PyPDFLoader
• PyPDF
• PyMuPDF

문서 유형에 따라 서로 다른 처리 방식이 필요합니다. 단일 패키지가 모든 문서 형식에 효과적으로 작동하지 않을 수 있습니다.

PDF 처리의 과제 (Challenges in PDF Processing)
문서에는 다음과 같은 내용이 포함될 수 있습니다:

• 스캔된 이미지 (Scanned images)
• 다단 레이아웃 (Multi-column layouts)
• 표 (Tables)
• 필기 텍스트 (Handwritten text)
• 양면 스캔 페이지 (Two-sided scanned pages)

이 때문에 전처리 (preprocessing)가 중요한 단계가 됩니다.

PDF 처리에 사용되는 도구 (Tools Used in PDF Processing)

• Camelot: Camelot은 PDF에서 표 (table) 콘텐츠를 추출하는 데 흔히 사용됩니다.
• Tesseract: Tesseract 또는 컴퓨터 비전 (computer vision) 모델은 스캔된 이미지를 읽을 수 있는 텍스트 문서로 변환하는 데 사용됩니다.

문서를 위한 최종 RAG 흐름 (Final RAG Flow for Documents)

1. 원본 문서 수집 (Raw documents are collected)
2. 이미지, 표, 스캔된 콘텐츠를 텍스트로 변환 (Images, tables, and scanned content are converted into text)
3. 데이터 정제 (Data is cleaned)
4. 청킹 방법을 사용하여 문서를 청크로 분할 (Documents are split into chunks using chunking methods)
5. 청크를 임베딩 벡터로 변환 (Chunks are converted into embedding vectors)
6. 검색을 위해 벡터를 벡터 데이터베이스에 저장 (Vectors are stored in the vector database for retrieval)