시맨틱 splitting 과 안 쓸 때

아이디어

시맨틱 splitting 은 각 문장 임베딩, 인접 문장 사이 running cosine similarity 계산, threshold 아래로 떨어지는 자리에서 새 청크 시작. 결과: 임의 길이가 아니라 주제 경계 에 정렬된 청크.

가끔 크게 이기는 이유

긴 narrative 문서 (블로그 포스트, transcript, 소설) 에서 시맨틱 splitting 은 retrieval relevance 를 fixed-size 보다 10–20% 능가할 수 있어 — 청크가 topical 하게 유지되니까. 모델이 생각 중간에 끝나는 Frankenstein 청크를 받지 않아.

프로덕션에서 자주 지는 이유

비용. 모든 문장을 두 번 임베딩 — splitting 한 번, 저장 한 번.
Latency. 80페이지 문서 splitting 이 분 단위 걸려.
opacity. 청크가 이상하게 보일 때 왜인지 쉽게 설명 못 해.
이미 구조화된 문서에서 negligible win. Markdown 헤딩이 이미 주제 경계 마크 — 그 위에 시맨틱 splitting 은 낭비.

긴 비구조화 prose 면 시맨틱 splitting. markup 이 조금이라도 있으면 구조-aware splitter 먼저.

Code

시맨틱 splitter (LangChain experimental)·python

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

splitter = SemanticChunker(
    OpenAIEmbeddings(model='text-embedding-3-large'),
    breakpoint_threshold_type='percentile',
    breakpoint_threshold_amount=85,    # 낮을수록 청크 많아짐
)

chunks = splitter.create_documents([open('long_essay.md').read()])
print(f'{len(chunks)} 시맨틱 청크')

시맨틱 splitting 과 안 쓸 때

아이디어

가끔 크게 이기는 이유

프로덕션에서 자주 지는 이유

Code

External links

Exercise

Progress

댓글 0