Overlap（Chunk Overlap）
3 秒看懂
一句話：把長文件切成片段時，讓相鄰片段之間有一段”公共區域”，防止關鍵資訊被截斷在兩段交界處丟失——這段公共區域就是 Chunk Overlap。
類比：拍長文件的翻頁照片，如果每頁只拍當前頁，頁縫處的文字可能被裁掉；重疊拍照（每頁多拍到上一頁底部幾行）就能保證無遺漏。
關鍵詞：RAG、文本分塊（Chunking）、滑動視窗、檢索增強生成
3 分鐘產業解釋
為什麼 Chunk Overlap 成了剛需？
大語言模型（LLM）的上下文視窗有限，而企業知識庫動輒上萬頁。RAG（檢索增強生成）的主流做法是：先把文件切成若干”塊”（chunk），對每塊做向量化（embedding），檢索時找出最相關的若干塊塞回 LLM 上下文。
問題出在”切”這個動作上。
如果你按固定 token 數一刀切，一句完整的話、一個完整的概念、一個跨段的表格，都可能被硬生生劈成兩半——分別落入相鄰兩塊。檢索時只召回其中一塊，語義就斷了。
Chunk Overlap 就是解法：切塊時讓相鄰塊有一段重疊區域，保證邊界處的資訊在兩個塊裡都出現。
產業位置
原始文件 → [分塊 + Overlap] → Embedding 向量化 → 向量資料庫 → 檢索 → LLM 生成
↑ 這裡看似是 RAG 管線中最”簡單”的一步預處理，但它直接影響檢索召回率和最終回答質量。實踐中，許多 RAG 專案效果不佳的根因就藏在分塊策略（含 Overlap 引數）裡。
15 分鐘專家深入
核心機制
設 chunk_size = C 個 token，chunk_overlap = O 個 token（O < C）。
則第 i 塊覆蓋的 token 範圍為：
第 0 塊: [0, C)
第 1 塊: [C - O, 2C - O)
第 2 塊: [2C - 2O, 3C - 2O)
...
第 i 塊: [i·(C - O), i·(C - O) + C)步長（stride）= C − O。當 O = 0 時退化為無重疊的固定切分；當 O → C 時步長趨近於 0，等效於逐 token 滑動視窗（極端情況，實際不會這麼用）。
典型引數區間
| 引數 | 常見範圍 | 說明 |
|---|---|---|
| chunk_size | 256 – 1024 tokens | 受限於 embedding 模型最大輸入長度（如 OpenAI text-embedding-3 系列上限為 8191 tokens，BGE/GTE 等開源模型常為 512 tokens） |
| chunk_overlap | chunk_size 的 10% – 20% | 業界經驗常用值；部分場景用到 25%–50% |
| Overlap 單位 | tokens / 字元 | 不同架構預設不同，LangChain 的 RecursiveCharacterTextSplitter 預設以字元計 |
⚠️ 以上引數區間為業界經驗共識性描述，非來自單一權威來源的硬資料。具體最優值高度依賴文件型別、embedding 模型和下游任務，需通過 A/B 實驗確定。
Overlap 的三重作用
- 邊界語義完整性：一個實體名、一句話被劈開後語義損失嚴重；Overlap 保證邊界資訊在至少一個完整上下文中出現。
- 檢索召回增強：同一段內容可能出現在兩個不同 chunk 的 embedding 中，增加被命中機率。
- 上下文連續性：對於需要理解跨段落邏輯（如論證鏈、程式碼函式）的任務，Overlap 能讓檢索到的多個 chunk 之間有”拼接餘量”。
成本代價
| 維度 | 影響 |
|---|---|
| 儲存 | Overlap 比例直接增加向量庫中的 embedding 數量。20% overlap ≈ 向量數增加約 25%（因為 stride 縮短，總 chunk 數 ≈ ⌈(N − C) / (C − O)⌉ + 1） |
| Embedding 計算 | chunk 數增加 → 需要更多 embedding 推論 |
| 檢索精度 | 過多 overlap 導致高度相似的冗餘 chunk 同時被召回，擠壓其他相關 chunk 的排序位置 |
| Prompt 用量 | 檢索到的 chunk 如含大量重疊文本，浪費有限的上下文視窗 |
核心權衡：Overlap 不是越大越好，而是在”邊界完整性”和”冗餘開銷”之間找平衡點。
技術原理（最深）
1. 分塊策略全景
┌──────────────────────────────────────────────────┐
│ Document Chunking Strategies │
├──────────────────────────────────────────────────┤
│ │
│ Fixed-Size Recursive Semantic │
│ Chunking Splitting Chunking │
│ (字元/token) (按分隔符遞迴) (按語義相似度) │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 固定視窗 │ │ 尊重自然 │ │ 嵌入向量 │ │
│ │ + Overlap│ │ 邊界+ │ │ 相似度 │ │
│ │ │ │ + Overlap │ │ 聚類+ │ │
│ │ │ │ │ │ + Overlap │ │
│ └─────────┘ └───────────┘ └───────────┘ │
│ │
│ Overlap 是所有策略的通用可選引數 │
└──────────────────────────────────────────────────┘2. 滑動視窗切分——Overlap 的最簡實現
文件 tokens: [A B C D E F G H I J K L M N O P]
chunk_size = 8, overlap = 3, stride = 5
Chunk 0: [A B C D E F G H]
Chunk 1: [F G H I J K L M]
Chunk 2: [K L M N O P]
↑↑↑
overlap region每個 overlap 區域的內容在兩個 chunk 的 embedding 中都被編碼，檢索時任一命中都能獲得該內容。
3. RecursiveCharacterTextSplitter 的 Overlap 機制（LangChain）
這是 RAG 實踐中最常用的分塊實現之一。其核心邏輯：
function recursive_split(text, separators, chunk_size, overlap):
# 優先用大粒度分隔符（如 "\n\n" 段落）切
# 若某段仍超 chunk_size，降級到下一粒度分隔符（如 "\n" → " " → ""）
# 切完後按 chunk_size 和 overlap 做視窗合併
for each segment:
if len(segment) <= chunk_size:
buffer.append(segment)
if len(buffer) > chunk_size - overlap:
emit(buffer)
# 保留尾部 overlap 長度的內容作為下一塊的開頭
buffer = buffer[-overlap:]
else:
# 遞迴到更細粒度的分隔符
recursive_split(segment, separators[1:], ...)關鍵細節：該實現中 overlap 按字元數計算，且在分隔符邊界處會做對齊（不會在單詞中間截斷）。
4. Semantic Chunking 中的 Overlap
語義分塊不按固定長度，而是按 embedding 相似度的變化來確定切分點。Overlap 在此場景下可以有兩種實現方式：
- 硬重疊：在語義邊界前後各保留 N 個 token 作為 overlap（與固定重疊類似）
- 軟重疊：將相鄰 chunk 的邊界段落重複計入兩個 chunk 的 embedding 加權計算中
⚠️ 語義分塊的軟重疊實現細節各架構差異較大，此處為定性描述。
5. Overlap 與 Embedding 質量的互動
Overlap 區域的內容會被獨立 embedding 兩次。這帶來一個微妙問題：
Chunk A 的 embedding: 加權平均(完整內容含 overlap 區域)
Chunk B 的 embedding: 加權平均(完整內容含 overlap 區域)當 chunk_size 接近 embedding 模型的最大輸入長度時，overlap 區域雖然內容相同，但由於 surrounding context 不同（chunk A 和 B 的其餘部分不同），其在最終 embedding 向量中的貢獻也不同——這被稱為 contextual embedding drift。這意味著：
- Overlap 區域的內容在兩個 chunk 的向量空間中並不完全重合
- 檢索時可能只命中其中一個 chunk（取決於 query 與周圍 context 的匹配度）
- 這既是好處（兩個 chunk 各自提供不同視角），也是隱患（過度依賴 overlap 保證召回可能並不可靠）
6. 與視窗注意力的類比
| Chunk Overlap（預處理） | Sliding Window Attention（模型架構） | |
|---|---|---|
| 層級 | 資料預處理 | 模型前向計算 |
| 目的 | 保證檢索不丟資訊 | 保證長序列注意力不丟資訊 |
| 代表 | RAG 分塊 | Longformer, Mistral 的 SWA |
| 機制 | 文本重疊複製 | 注意力視窗滑動，k-v 共享 |
技術演進史
| 階段 | 時間線 | 核心變化 |
|---|---|---|
| 無分塊時代 | ~2020 前 | 傳統 IR（BM25/TF-IDF）按文件或段落檢索，不需要 chunk overlap |
| 固定視窗切分 | ~2020–2022 | GPT-3 / BERT 等模型的 max_length 限制催生固定 token 視窗切分；Overlap 作為簡單策略出現 |
| RAG 爆發期 | ~2023 | ChatGPT + RAG 範式普及，LangChain/LlamaIndex 將 chunk_size 和 chunk_overlap 暴露為一級引數；業界開始關注分塊策略對端到端效果的影響 |
| 精細化階段 | ~2024 | 語義分塊（Semantic Chunking）、Agentic Chunking 等更智慧的切分方式出現；Overlap 從固定值演化為動態策略；Late Chunking（Jina, 2024）等方法試圖從根本上重新定義 chunk 與 embedding 的關係 |
| 長上下文衝擊 | ~2024–2025 | 隨著 LLM 上下文視窗擴充套件到 128K–1M+ tokens，部分場景可以不切分或用極大 chunk，Overlap 的必要性在某些任務中降低；但 RAG 在延遲和成本上的優勢仍使分塊+Overlap 保持主流地位 |
技術路線對比
Chunk Overlap vs 替代/互補方案
| 方案 | 原理 | 召回改善 | 計算開銷 | 適用場景 | 侷限 |
|---|---|---|---|---|---|
| Chunk Overlap | 相鄰塊共享文本 | 中等（邊界資訊保護） | 與 overlap 比例線性增加 | 通用 RAG | 冗餘儲存、冗餘召回 |
| Late Chunking (Jina, 2024) | 先對整文件做 token-level embedding，再切分池化 | 理論更優（保留全域性 context） | 推論時需處理完整文件 | 長文件、對質量要求高 | 推論延遲高、依賴長上下文 embedding 模型 |
| Contextual Retrieval (Anthropic, 2024) | 每個 chunk 前拼接 LLM 生成的上下文摘要 | 顯著改善 | 需 LLM 預處理（額外成本） | 高價值文件 | 預處理成本高 |
| Parent-Child Chunking | 檢索小塊、返回大塊（父塊） | 中等 | 儲存雙份 chunk | 需要精細檢索但生成需寬上下文 | 需維護層級關係 |
| 增大 chunk_size | 直接用大塊 | 邊界問題減少但模糊 | embedding 輸入更長 | 長上下文 embedding 模型 | 可能超出模型上限、檢索粒度變粗 |
| HyDE / Query 擴充套件 | 從 query 端入手提升召回 | 互補 | 生成偽文件 | 與 overlap 正交 | 不解決邊界問題 |
Late Chunking 和 Contextual Retrieval 為定性描述，具體效能資料依賴實驗設定，此處不列具體數字。
上下游
上游（Chunk Overlap 依賴什麼）
原始文件 ──→ 文件解析器（PDF/HTML/DOCX → 純文本）
│
▼
分詞/Tokenization（決定 chunk_size 的單位）
│
▼
┌─────────────────────┐
│ Chunking Engine │
│ (LangChain / │
│ LlamaIndex / 自研) │
│ 輸入: text + C + O │
└─────────┬───────────┘
│
▼
Chunk 列表（含 overlap）
│
▼
Embedding Model（編碼每個 chunk）下游（Chunk Overlap 影響什麼）
Chunk 列表 ──→ Embedding 向量 ──→ 向量資料庫（儲存/索引）
│
┌─────────────────┘
▼
Top-K 檢索結果
│
▼
┌─────────────────┐
│ Reranker │ ← 如果 overlap 過高，檢索結果
│ (可選) │ 中冗餘 chunk 擠佔 Top-K 位置
└────────┬────────┘
▼
LLM 上下文視窗
(去重後拼接)
│
▼
最終生成回答關鍵指標
| 指標 | 定義 | 典型範圍 | 備註 |
|---|---|---|---|
| Overlap Ratio (O/C) | overlap 長度 / chunk 長度 | 10% – 20%（常用）；極端 0% – 50% | 最核心的調參指標 |
| Effective Redundancy | 因 overlap 導致的額外儲存/計算比例 | ≈ O / (C − O) | O/C = 20% 時冗餘約 25% |
| Total Chunk Count | ⌈(N − O) / (C − O)⌉ | 取決於文件長度 N | chunk 數隨 overlap 增加而增加 |
| Boundary Recall | 邊界處關鍵資訊被正確檢索到的機率 | 定性：overlap 有 > 無 | 難以直接量化，需端到端評估 |
| Retrieval Redundancy Rate | Top-K 結果中屬於同一 overlap 區域的比例 | 過高說明 overlap 設定不當 | 可用於診斷 |
供需與市場資料
市場定位
Chunk Overlap 不是獨立產品，而是 RAG 管線中的基礎配置項。其市場價值體現在：
- RAG 架構生態：LangChain、LlamaIndex、Haystack 等均將 chunk_size 和 chunk_overlap 作為核心引數。LangChain 在 2024 年被統計為 GitHub 上最活躍的 AI 應用架構之一 [定性描述，非精確排名]。
- 向量資料庫需求：overlap 增加 chunk 數量 → 直接擴大向量庫的儲存規模。以 OpenAI text-embedding-3-small（1536 維，float32）估算，每個向量約 6KB；若 overlap 導致 chunk 數增加 25%，儲存成本也相應增加 25%。
- Embedding API 呼叫量：chunk 數增加 → embedding 推論呼叫增加 → 對 OpenAI、Cohere、Jina 等 embedding API 提供商的營收有直接拉動。
規模估算
⚠️ 以下為基於行業結構的邏輯估算，非精確市場資料。
| 維度 | 邏輯推算 |
|---|---|
| 全球 RAG 應用中使用分塊+overlap 的比例 | 估計 > 80%（幾乎所有主流 RAG 教程和架構預設包含此配置） |
| Overlap 帶來的額外 embedding 呼叫 | 估算佔總 embedding 呼叫量的 15%–30% |
| Overlap 帶來的額外向量儲存 | 估算佔向量資料庫總儲存量的 10%–20% |
代表公司與資本對映
| 角色 | 代表公司/產品 | 與 Overlap 的關係 |
|---|---|---|
| RAG 架構 | LangChain, LlamaIndex, Haystack, Semantic Kernel (Microsoft) | 提供 chunking + overlap 的一等公民 API |
| Embedding 模型 | OpenAI (text-embedding-3), Cohere (Embed v3), Jina (jina-embeddings-v3), BAAI (BGE), Nomic | 模型最大輸入長度決定 chunk_size 上限，間接決定 overlap 策略 |
| 向量資料庫 | Pinecone, Weaviate, Milvus/Zilliz, Qdrant, Chroma, pgvector | overlap 增加向量數量 → 增加儲存和檢索負載 |
| 文件解析 | Unstructured.io, LlamaParse, Docling (IBM) | 解析質量影響 overlap 處理的有效性（解析出的文本結構決定最佳切分點） |
| 長上下文 LLM | Google (Gemini 1.5 Pro, 1M+ tokens), Magic.dev (目標 100M tokens) | 長上下文可能減少對 chunk overlap 的依賴，但延遲和成本問題仍使 RAG 保持主流 |
| Contextual Chunking | Anthropic (Contextual Retrieval), Jina (Late Chunking) | 新範式可能部分替代傳統 overlap |
投資邏輯
利好方向
- RAG 基礎設施持續投入：只要 RAG 仍是 LLM 應用的主流範式，chunking（含 overlap）就是剛需。關注 RAG 架構和向量資料庫賽道。
- Embeding 模型使用量增長：overlap 增加 chunk 數 → 更多 embedding 呼叫 → 利好 embedding API 提供商的用量和營收。
- 文件智慧解析：高質量文件解析（保留結構資訊）能讓 overlap 策略更精準，減少無謂冗餘。Unstructured、LlamaParse 等公司處於這一價值節點。
- 智慧分塊工具化：自動化調優 chunk_size 和 overlap 的工具（如基於 A/B 測試的分塊策略最佳化平台）是一個尚未充分開發的細分需求。
風險因素
- 長上下文衝擊：如果 LLM 上下文視窗足夠大且推論成本足夠低，許多 RAG 場景可能轉向”全文塞入”模式，分塊（含 overlap）的需求將萎縮。
- Late Chunking / Contextual Retrieval 等新範式：可能使傳統固定 overlap 策略被替代。
- 競爭壁壘低：chunk overlap 本身是幾行程式碼的事，不構成獨立商業模式；價值必須在更上層的架構或服務中捕獲。
常見誤讀糾偏
❌ 誤讀 1：“Overlap 越大，檢索效果越好”
糾偏：Overlap 超過一定閾值後，檢索結果中大量 chunk 內容高度重複，佔據 Top-K 位置卻只貢獻了”同一段話的不同版本”，反而擠佔了其他有價值 chunk 的排序位置。實驗顯示，overlap ratio 超過 25%–30% 後邊際收益遞減甚至轉負（定性結論，具體因資料集和模型而異）。Overlap 不是銀彈，過猶不及。
❌ 誤讀 2：“Chunk Overlap 能完全解決邊界資訊丟失問題”
糾偏：Overlap 只能保證邊界附近的內容在相鄰 chunk 中重複出現。但對於跨多個 chunk 的長距離依賴（如一個論證跨越 3 段落），單一的相鄰 overlap 無能為力。此時需要更高層級的策略：Parent-Child chunking、文件級摘要拼接、或圖 RAG（Graph RAG）等方案。Overlap 解決的是區域性邊界問題，不是全域性上下文問題。
❌ 誤讀 3：“用 Overlap 了就不需要 Reranker”
糾偏：Overlap 與 Reranker 解決的是不同層面的問題。Overlap 解決的是”關鍵資訊是否被切丟”（是否進入了某個 chunk），Reranker 解決的是”哪個 chunk 與 query 最相關”（排序問題）。兩者正交，理想情況下應配合使用。overlap 導致的冗餘 chunk 恰恰是 Reranker 可以過濾掉的。
❌ 誤讀 4：“Chunk Overlap 在長上下文模型時代已經過時”
糾偏：雖然長上下文（128K+）模型可以容納更多文本，但 ① 長上下文推論的計算成本（延遲和價格）遠高於只處理少量相關 chunk；② “大海撈針”（needle-in-a-haystack）問題表明，即使上下文夠長，LLM 對中間位置資訊的利用效率也下降（Lost in the Middle 現象）。因此 RAG + 精準檢索（含 overlap 分塊）在成本和質量上仍具優勢。
學習路徑
入門（0–2 小時）
- 通讀 LangChain 官方文件中
RecursiveCharacterTextSplitter的chunk_size和chunk_overlap引數說明 - 用一段 2000 token 的文章，分別設定 overlap = 0 和 overlap = 200，觀察切分結果差異
- 理解 stride = chunk_size − overlap 的核心公式
進階（2–8 小時）
- 在一個簡單的 QA 資料集上，對比不同 overlap ratio（0%, 10%, 20%, 30%）對 retrieval recall@K 的影響
- 閱讀 Anthropic 的 “Contextual Retrieval” 技術部落格（2024），理解其與 overlap 的互補關係
- 閱讀 Jina 的 “Late Chunking” 論文/部落格，理解其對傳統 overlap 範式的挑戰
專家（8+ 小時）
- 研讀 Greg Kamradt 的 Chunking 策略對比實驗（YouTube / GitHub）
- 閱讀 “Lost in the Middle”（Liu et al., 2023）論文，理解長上下文中資訊位置對 LLM 效能的影響
- 實現一個自動化 chunk_size + overlap 超參搜尋架構，在真實業務資料上端到端最佳化 RAG pipeline
- 探索語義分塊（Semantic Chunking）和圖 RAG（Graph RAG）等更高階的分塊策略
一句話總結
Chunk Overlap 是 RAG 分塊策略中最基礎也最容易被低估的調參項——它用”冗餘”換”完整性”，核心在於找到那個讓邊界資訊不丟失、又不至於讓檢索結果充滿重複內容的甜蜜點。
延伸閱讀與來源
| 來源 | 連結/標識 | 說明 |
|---|---|---|
| LangChain 文件 | RecursiveCharacterTextSplitter 官方文件 | chunk_size / chunk_overlap 引數定義與使用 |
| Anthropic 技術部落格 | ”Introducing Contextual Retrieval” (2024) | Contextual Retrieval 與傳統 overlap 的對比 |
| Jina AI 部落格 | ”Late Chunking in Long Context Embedding Models” (2024) | 對傳統分塊+overlap 範式的替代方案 |
| Liu et al. (2023) | “Lost in the Middle: How Language Models Use Long Contexts” | 長上下文中資訊位置效應，間接論證 RAG 分塊的價值 |
| Greg Kamradt | ”5 Levels of Text Splitting” (YouTube / GitHub) | RAG 分塊策略的實操對比 |
| LlamaIndex 文件 | Node Parser / SentenceWindowNodeParser | 含 window_size（類似 overlap）的高階分塊方式 |
| Unstructured.io | 技術文件 | 文件解析層與分塊的整合 |
宣告：本文中未標註具體來源的數值和比例均為業界經驗共識性描述或基於行業結構的邏輯推算，不構成精確的技術規格書。具體引數請以實際實驗和廠商最新文件為準。