Field Log · Entry

긴 문서 Embedding: Chunking·Contextual·Multi-vector (9/14)

긴 문서를 독립 chunk, 전체 문맥을 본 contextual chunk, single document vector와 token multi-vector로 표현하는 네 가지 retrieval 경로

이번 글의 결론

  • Max context length가 길다는 것과 긴 문서의 여러 사실을 single vector에 잘 보존한다는 것은 다릅니다.
  • 독립 chunk는 localized evidence와 index 효율에 좋지만 대명사·section·앞 문단의 정의를 잃습니다. Chunk text와 embedding context를 분리해서 생각해야 합니다.
  • Late chunking, Contextual Document Embedding, situated embedding은 모두 문맥을 쓰지만 문맥을 주입하는 위치와 학습 방식이 다릅니다.
  • Multi-vector는 세부 match를 보존하는 대신 vector 수·저장·후보 scoring 비용을 늘립니다. Document/page/patch 수준별 Pareto를 재야 합니다.
  • 긴 문서 평가는 길이뿐 아니라 answer position, evidence span, 문맥 의존도, 반환 단위를 함께 바꿔야 합니다.

앞 글까지 입력 언어를 다뤘습니다. 이제 입력 길이와 문서 구조가 embedding bottleneck을 어떻게 바꾸는지 봅니다.


1. 긴 입력의 두 문제

Model Input Limit

Tokenizer가 8K 이상을 받지 못하면 뒤 text는 잘립니다.

Representation Capacity

32K를 입력할 수 있어도 모든 fact를 1,024차원 vector 하나에 압축해야 합니다.

32,000 tokens
  → Transformer
  → one 1,024-d vector

두 번째 문제를 semantic dilution 또는 information bottleneck 관점에서 봅니다. Context window extension만으로 해결되지 않습니다.

2. Chunk-then-Embed Baseline

document
  → split into chunks
  → encode each chunk independently
  → store one vector/chunk

장점:

  • 근거를 작은 단위로 반환
  • single-vector ANN 그대로 사용
  • update와 citation이 단순
  • generator token budget에 맞음

문제:

앞 chunk: "이하 이 정책을 예외 정책이라 한다."
현재 chunk: "이는 승인된 관리자에게만 적용된다."

현재 chunk만 보면 이는이 무엇인지 모릅니다.

3. Context Prefix Baseline

Chunk 앞에 title·section path·짧은 summary를 붙입니다.

[문서: 보안 정책]
[절: 예외 승인 > 관리자 범위]
[본문: 이는 승인된 관리자에게만 적용된다.]

가장 구현하기 쉬운 contextualization입니다. 검색 결과로 generator에 넘길 때 prefix와 원문을 구분해 provenance를 유지합니다.

LLM-generated context는 비용과 hallucination risk가 있으므로 deterministic heading baseline과 비교합니다.

4. Parent–Child Retrieval

Child chunk로 검색하되 parent section 또는 주변 window를 반환합니다.

index: child chunks
retrieve: child IDs
expand: parent section / neighbors
rerank/select: expanded evidence

Embedding 자체는 바꾸지 않지만 localized match와 넓은 generator context를 분리합니다. 중복 parent가 top-k를 독점하지 않도록 group-by-document selection이 필요합니다.

5. Long-context Single-vector

문서 전체 또는 큰 section을 한 번에 encoding합니다.

장점:

  • chunk boundary를 줄임
  • 문서 전체 topic·style를 반영
  • vector 수 감소

단점:

  • 작은 answer span 희석
  • 긴 input encoding 비용
  • update 시 큰 단위 재계산
  • citation granularity 부족
  • position sensitivity

LongEmbed는 synthetic 2개와 real-world 4개 task로 긴 문서와 분산된 target information을 평가하며, 허용 context가 늘어도 긴 retrieval에는 개선 여지가 큼을 보였습니다.

6. Late Chunking

Late chunking은 먼저 긴 문서 전체 token을 Transformer에 통과시키고, 그 뒤 chunk span별 token state를 pooling합니다.

normal chunking:
  split → encode each chunk → pool

late chunking:
  encode whole document → split token states → pool each span

각 chunk vector는 작은 반환 단위를 유지하면서 앞뒤 문맥을 본 token state를 가집니다.

구현 핵심

  1. Character chunk boundary를 만든다.
  2. Offset mapping으로 boundary를 token span에 맞춘다.
  3. 긴 문서를 한 번 encoding한다.
  4. 각 token span을 masked mean pooling한다.
  5. 각 chunk vector를 normalize한다.

Tokenizer가 offset mapping을 안정적으로 제공하지 않거나 문서가 context limit보다 길면 window overlap 정책이 필요합니다.

7. Late Chunking의 비용

Independent chunk는 chunk별 forward라서 중복 overlap을 여러 번 계산할 수 있습니다. Late chunking은 문서 전체를 한 번 보지만 attention cost가 긴 sequence에서 큽니다.

independent:
  Σ chunks attention(chunk_length)

late:
  attention(document_length)

Transformer attention implementation과 length에 따라 어느 쪽이 빠른지 달라집니다. Ingestion throughput과 peak memory를 측정합니다.

8. Contextual Document Embeddings, CDE

CDE는 개별 document가 retrieval corpus에서 out-of-context로 encoding된다는 문제를 제기합니다. Neighbor document/context 정보를 contrastive objective와 architecture에 반영해 contextualized document embedding을 만듭니다.

embedding(d_i | neighboring documents / corpus context)

Late chunking이 한 긴 문서 내부 token 문맥을 먼저 보는 방법이라면, CDE는 document 주변의 contextual information까지 representation에 반영하는 더 넓은 관점입니다.

Corpus context를 쓰면 같은 text도 corpus가 바뀔 때 vector가 달라질 수 있습니다. Ingestion·incremental update contract가 복잡해집니다.

9. Situated Embedding

ACL 2026의 Situated Embedding 연구는 긴 chunk 하나를 반환하는 대신 짧은 chunk의 의미를 넓은 context에 조건화하는 방향을 제안합니다.

localized chunk c
broader context C
→ embed(c | C)

기존 general embedding에 긴 context를 붙이기만 하는 것이 아니라 situated context를 쓰도록 학습하는 paradigm이 필요하다고 주장하며 book-plot retrieval 평가를 제시했습니다.

차이:

방식반환 단위문맥 범위추가 학습
independent chunkchunk없음불필요
prefix contextchunkheading/summary불필요
late chunkingchunk같은 encoding window선택
CDEdocument/chunkneighbor/corpus context있음
situated embeddingshort chunkbroader local context있음

10. Multi-vector Late Interaction

Single vector로 평균하지 않고 token vector를 보존합니다.

score(q,d) = Σ_i max_j q_i · d_j

장점:

  • rare term·숫자·entity의 local match
  • 긴 문서의 여러 facet 보존
  • query token별 evidence alignment

비용:

  • document당 vector 수 증가
  • index·storage 증가
  • MaxSim 계산
  • pruning/compression 필요

ColBERT는 text token, ColPali는 document page image patch/token vector로 이 방향을 확장합니다.

11. Hierarchical Multi-vector

document vector → coarse candidate documents
section vectors → candidate sections
token vectors   → fine late interaction

모든 level을 동시에 검색할 필요는 없습니다. Coarse-to-fine cascade로 저장 장치와 latency budget을 맞춥니다.

12. Chunking Ablation Matrix

segmentation:
  fixed 256 / 512 tokens
  paragraph
  heading-aware
  semantic boundary

context:
  none
  title+heading
  neighbor window
  late chunking

representation:
  single vector
  multi-vector

한 축씩 바꿉니다. “Semantic chunker + 새 model + reranker”를 한꺼번에 바꾸면 gain 원인을 모릅니다.

13. 긴 문서 Evaluation Slice

Length Bucket

0–512, 513–2K, 2K–8K, 8K–32K, >32K tokens

Relative Answer Position

answer_start / document_length
→ beginning / middle / end

Evidence Width

  • 한 문장
  • 한 paragraph
  • 여러 chunk에 분산
  • 전체 문서 theme

Context Dependence

  • self-contained
  • heading 필요
  • previous paragraph 필요
  • distant definition 필요

평균 length 하나는 이 실패를 숨깁니다.

14. Retrieval Unit와 Relevance Unit

Gold가 page인데 system은 chunk를 반환하거나, gold가 document인데 section vector를 검색할 수 있습니다.

index unit      = chunk
retrieval unit  = chunk
evaluation unit = document
generation unit = parent section

Metric 계산 시 child hit가 parent document hit로 count되는 mapping을 명시합니다. 여러 child가 같은 parent를 차지하면 document-level top-k를 deduplicate할지 정합니다.

15. Contextual Embedding Update 문제

독립 chunk vector는 한 chunk만 바뀌면 재계산하면 됩니다. Context-conditioned vector는 주변 변경의 영향을 받습니다.

change chunk c3
  → recompute c3 only?                independent
  → recompute c1...c5 window?         local context
  → recompute whole document?         late chunking
  → recompute corpus neighborhood?    CDE-style

Index freshness와 update amplification을 architecture 선택에 포함합니다.

16. Production Manifest

document_embedding:
  parser: pdf-parser-v4
  segmentation: heading-aware-v3
  max_chunk_tokens: 384
  overlap_tokens: 48
  context:
    method: late_chunking
    encoder_window: 8192
    long_document_stride: 7168
  pooling: span-masked-mean
  representation: single-vector-per-chunk
  parent_expansion: section
  deduplicate_parent_at_k: true
  update_scope: encoding-window

Chunk ID는 parser·segmentation version과 source offsets를 포함해 trace 가능하게 합니다.

17. 선택 가이드

Corpus첫 baseline다음 실험
짧은 FAQindependent passagetitle prefix
구조화 manualheading-aware chunkparent-child / late chunking
법률·책section + parentsituated/contextual embedding
visually rich PDFOCR+text baselineColPali/Qwen3-VL 계열
세부 exact match 중요hybrid BM25+densemulti-vector rerank/retrieval

스스로 확인하기

  1. 32K input 지원과 32K document retrieval quality가 같은 말이 아닌 이유는 무엇인가?
  2. Late chunking과 context prefix는 문맥을 어디에서 주입하는가?
  3. CDE처럼 corpus context를 쓰면 incremental indexing이 어려워지는 이유는 무엇인가?
  4. Multi-vector가 single-vector보다 보존하는 정보와 추가 비용은 무엇인가?
  5. 긴 문서 benchmark에서 answer position과 context dependence를 분리해야 하는 이유는 무엇인가?

다음 글에서는 STS·분류·clustering·retrieval의 metric을 분리하고 exact search·paired 통계·RAG utility를 포함한 평가 protocol을 만듭니다.

참고자료