二十八：Chunking-free RAG¶

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484318&idx=1&sn=4418e2d1274a9deb68526001d7f34384&chksm=f01eb0e7c76939f18d33672b84ec682eb53b10a867c43d7f4942673eb37ab4ffe69cfae2c82f#rd

1. 学习范围¶

本日主题是 Chunking-free RAG，重点是 Chunking-Free 架构。传统 RAG 通常需要把文档切成 chunk，再对 chunk 做 embedding 和检索。Chunking-free RAG 试图减少或避免人工 chunking 对语义完整性、召回和上下文组织造成的损伤，让模型在更完整的文档上下文中定位和使用证据。本日覆盖： - 传统 chunk-based RAG 的基本假设和问题。

Chunking-free RAG 的动机与定位。
Landmark Embedding 的基本思想。
Chunking-Free In-Context Retrieval 的核心流程。
长上下文模型、位置标记、段落/句子级定位与证据选择。
Chunking-free 与普通 RAG、long-context RAG、parent document retrieval 的关系。
工程实现、评估指标、适用场景和限制。

2. 传统 Chunk-based RAG 的回顾¶

传统 RAG 的典型流程是：

Document -&gt; Split into chunks -&gt; Embed chunks -&gt; Vector index
Query -&gt; Embed query -&gt; Retrieve top-k chunks -&gt; Prompt -&gt; Answer

chunking 的作用是把长文档拆成较短片段，便于向量化、索引和放入 prompt。但 chunking 会引入明显的工程选择： - chunk size。

overlap。
分隔符和结构边界。
标题是否拼入 chunk。
表格、代码、公式如何切分。
父子文档如何映射。

这些选择会影响召回、上下文完整性、成本和答案忠实性。

3. Chunking 的核心问题¶

chunking 的主要问题包括： - 语义切断：一个完整论点被拆成多个 chunk。

上下文丢失：chunk 命中但缺少标题、前提、定义或限制条件。
噪声扩大：chunk 太大导致 embedding 混杂，召回不精确。
边界敏感：答案正好跨 chunk 边界时容易漏召回。
参数敏感：chunk size 和 overlap 需要针对数据集调参。
结构破坏：表格、代码、法律条款、论文段落被切坏。
重复召回：overlap 太大导致 top-k 被相似 chunk 占满。

因此，chunking 并不是一个无害预处理步骤。它会改变文档作为知识单元的形态。

4. Chunking-free RAG 的定位¶

Chunking-free RAG 的目标是：“不提前对文档做固定离线切分”，在尽量保留完整文档或较大上下文结构的情况下，让系统能够定位与 query 相关的证据，并把相关证据提供给 LLM。它不是简单地“把所有文档塞进长上下文”。真正的 Chunking-free 思路通常包含： - 用特殊 embedding 或定位机制标记文档中的关键位置。

在完整或大段文本中识别 query 相关区域。
避免离线阶段固定切 chunk。
在线阶段根据 query 动态选择证据位置或片段。
保持更完整的原始文档结构。

它和 long-context RAG 有交集，但不完全相同。long-context RAG 关注把更多内容放入上下文；Chunking-free RAG 关注不依赖预切 chunk 的检索和定位机制。

5. Landmark Embedding（地标嵌入）的基本思想¶

传统分块 RAG 将文档预先切割为固定长度文本块，语义边界易被人为截断，跨块关联信息丢失；而 Chunking-free RAG 需要一套能在完整长文档内精准定位相关片段的编码方案，Landmark Embedding（以 BGE Landmark 为代表）就是适配无分块检索的主流表征方案。 BGE Landmark Embedding 相关工作关注在长文本中插入 landmark token 或 landmark 标记，使 embedding 模型能够感知和定位文档中的重要位置。直观理解是：不是把文档切成很多独立 chunk，而是在文档内部设置“地标”，让检索模型学习 query 与文档内部位置之间的关联。核心思想可以概括为：

Document with landmarks -&gt; Encode -&gt; Landmark-aware representations
Query -&gt; Encode -&gt; Match query to relevant landmark/position

这样系统可以在长文档中定位相关区域，而不必完全依赖固定 chunk 边界。 Landmark 的意义： - 保留文档整体上下文。

提供位置级检索入口。
缓解 chunk 边界切断问题。
让检索结果能指向原文中的具体区域。

具体来说：

1. 离线文档预处理：插入地标 token¶

不需要拆分文档，只做简单插入： - 把整篇完整长文按句子拆分；

在每一句的结尾固定追加专用符号（词表中一个独立特殊 token，类似[CLS]/[SEP]）；
如果全文长度超过 Embedding 模型最大输入上限，用滑动窗口滚动读取全文，窗口之间有重叠，全程不破坏原文顺序与结构。

举个极简文本例子：原始段落： Bill paid a visit to Eiffel Tower on Sunday. He spent the morning exploring its details.

插入地标后送入模型的输入：Bill paid a visit to Eiffel Tower on Sunday. He spent the morning exploring its details.

¶

2. 模型编码：让学会代表前面整句话语义¶

把带一串的完整长文本一次性送入 BGE-Landmark 编码器做全局编码： - Transformer 会同时看到整段上下文，每个能感知前一句 + 前后相邻句子的全局语境；

训练阶段专门优化：强制每个的输出向量，等于它前面那整句话的语义表征；
编码完成后，从模型输出序列里，单独提取每一个对应的向量，这个向量就叫LE（Landmark Embedding，地标向量）。

上面例子会产出 2 个独立地标向量： - LE₁ = 第一个向量 → 代表第一句话语义

LE₂ = 第二个向量 → 代表第二句话语义

3. 查询匹配：用地标做细粒度定位¶

¶

用户 Query 处理：问句末尾同样加，编码取出最后一个 token 向量作为查询向量；
相似度计算：拿 Query 向量，和文档里每一个 LE 地标向量算余弦相似度；
匹配结果：相似度最高的那个 LE，对应原文里该前面的句子，就是和问题最相关的局部区域。

与之前的Chunk分割区别在于，地标不是手动标注的关键词，不需要人工提取实体、关键句；并且全程不会破坏文档完整结构，离线阶段不会切分固定chunk，整篇文本连续输入，消除分块割裂语义的问题；并且将检索精度精细到了句子级。 - 滑动窗口只是为适配模型长度，不是分块。窗口只是分批送入长文本，窗口间重叠、原文不截断，取出的地标依然保留全局上下文信息。

地标向量自带原文位置映射。每个 LE 都记录了它在文档中的前后位置，检索命中后可以动态截取该句子 + 前后上下文送入 LLM，完美适配 Chunking-free RAG “在线动态选证据” 的需求。

6. Chunking-Free In-Context Retrieval¶

Chunking-Free In-Context Retrieval 关注在不进行传统 chunking 的情况下，让模型在上下文中完成检索。其核心目标是减少预处理阶段的人为分块，利用长上下文模型和检索机制在输入内部找到相关信息。一个高层流程可以表示为：

Long document / collection
&nbsp; &nbsp; &nbsp; |
Add markers / positions / structured boundaries
&nbsp; &nbsp; &nbsp; |
Model or retriever identifies relevant spans
&nbsp; &nbsp; &nbsp; |
LLM answers based on selected in-context evidence

与传统 RAG 的区别在于：传统 RAG 的基本检索单元是预先切好的 chunk；chunking-free 试图把检索单元转向位置、span、landmark 或动态片段。 Landmark 地标标记是该检索方案最常用的底层技术手段，依靠<LMK>锚点实现上下文内细粒度 span 定位。

7. Landmark、Span 与动态证据¶

Chunking-free 系统通常需要解决两个问题： - 如何定位：query 对应文档中的哪些位置？

如何提供证据：定位后给 LLM 多大范围的文本？

定位可以是： - landmark token。

句子位置。
段落位置。
标题节点。
token span。
attention/score 高的位置。

证据提供可以是： - 命中位置前后窗口。

命中段落。
命中章节。
多个 span 合并。
原文加高亮标记。

chunking-free 并不意味着最终不给模型片段，而是避免离线固定 chunk，把片段选择推迟到 query-time 动态完成。

8. 与 Parent Document Retrieval 的关系¶

Parent document retrieval 用小 chunk 检索，返回大 parent。Chunking-free RAG 与它有相似目标：缓解小 chunk 缺上下文的问题。区别： - Parent document retrieval 仍然依赖离线 child chunk。

Chunking-free 更强调不使用固定 chunk，或使用位置/landmark 替代 chunk。
Parent document retrieval 更容易工程落地。
Chunking-free 更依赖模型能力、长上下文能力或专门训练的 embedding。

可以把 parent retrieval 看作 chunking-free 思想的工程折中：检索仍用 chunk，但生成尽量用完整父上下文。

9. 与 Long-Context RAG 的关系¶

长上下文模型能容纳更多文本，但它不自动解决检索问题。直接把大量文档塞入 prompt 会带来： - 成本和延迟高。

关键信息被稀释。
模型忽略中间信息。
引用和证据定位困难。
无关信息干扰答案。

Chunking-free RAG 可以利用长上下文，但仍需要位置定位、证据选择和忠实性控制。理想状态是：既保留长文档结构，又能高效定位相关区域。

10. Chunking-free 的输入组织¶

为了让模型在大上下文中定位，输入组织很关键。常见设计：

&lt;doc id="doc_1"&gt;
&lt;title&gt;...&lt;/title&gt;
&lt;section path="1.2"&gt;
&lt;landmark id="L001"/&gt;
段落文本...
&lt;landmark id="L002"/&gt;
段落文本...
&lt;/section&gt;
&lt;/doc&gt;

或使用轻量位置标记：

[L001] 第一段...
[L002] 第二段...
[L003] 第三段...

位置标记的作用： - 让模型输出可引用位置。

便于后处理抽取证据。
便于评估命中位置是否正确。
支持动态扩展命中位置周围上下文。

11. 检索粒度与证据窗口¶

Chunking-free 系统仍然需要决定证据窗口大小。常见策略： - 命中 landmark 前后若干句。

命中段落。
命中章节。
命中位置周围固定 token 窗口。
根据语义边界动态扩展。

窗口过小会丢失前提，窗口过大则引入噪声。与传统 chunking 不同的是，窗口可以在 query-time 动态确定，而不是离线固定。

12. 训练与模型能力¶

Chunking-free RAG 往往依赖模型具备以下能力： - 长文本编码能力。

query 与文档内部位置匹配能力。
对 landmark/position 标记的理解。
从大上下文中选择证据的能力。
输出引用位置的能力。

如果 embedding 模型或 LLM 没有经过相关训练，单纯插入标记可能效果有限。Landmark embedding 这类方法的价值在于让模型学习如何利用这些地标。

13. 工程实现路径¶

在工程中可以采用不同强度的 chunking-free 方案。轻量方案： - 减少 chunk 数量，使用更大的结构化片段。

保留完整标题路径和 doc_id。
使用 parent document retriever。
在返回上下文中加入位置标记。

中等方案： - 使用句子/段落级索引。

命中后动态扩展上下文窗口。
使用 reranker 判断 span 相关性。
对长文档做位置标记和证据高亮。

高级方案： - 使用 landmark embedding。

使用 chunking-free in-context retrieval 模型。
结合长上下文 LLM 和位置级证据抽取。
对文档级检索、位置级定位、答案生成做联合评估。

14. 评估指标¶

Chunking-free RAG 评估既要看最终答案，也要看位置定位。检索/定位指标： - Evidence recall。

Landmark hit rate。
Span overlap。
Position accuracy。
Document recall。

生成指标： - Answer correctness。

Faithfulness。
Citation accuracy。
Completeness。
Refusal accuracy。

系统指标： - Token cost。

Latency。
Context utilization。
证据窗口长度。
与 chunk-based baseline 的对比。

关键是比较：在相同成本或相同上下文预算下，chunking-free 是否比 chunk-based RAG 更能保留证据和提升答案忠实性。

15. 适用场景¶

Chunking-free RAG 更适合： - 长文档理解。

法律合同和政策文档。
论文和技术报告。
章节结构强的文档。
答案跨 chunk 边界的任务。
需要保留上下文完整性的问答。
chunking 参数很难调的复杂文档。

不一定适合： - 简单 FAQ。

小规模短文档。
对延迟极敏感的在线检索。
embedding/LLM 不支持长上下文或 landmark 的系统。
需要低成本大规模召回的场景。

16. 限制与风险¶

Chunking-free RAG 的主要限制： - 长上下文成本高。

对模型位置理解能力要求高。
landmark 或位置标记需要训练或适配。
证据窗口仍需设计。
大规模文档集合中仍需要文档级粗召回。
工程生态不如传统 chunk RAG 成熟。
评估更复杂。

它不是传统 RAG 的完全替代，而是一类针对 chunking 痛点的改进方向。

17. 与传统 RAG 的取舍¶

传统 chunk RAG： - 工程成熟。

向量数据库生态完善。
成本可控。
适合大规模检索。
但受 chunk 边界影响明显。

Chunking-free RAG： - 更保留文档结构。

减少固定 chunk 参数依赖。
更适合长文档和跨边界证据。
但成本、模型要求和工程复杂度更高。

实际系统常采用混合方案：先文档级或章节级召回，再用位置标记、动态窗口、rerank 和长上下文生成。

18. 面试表达要点¶

面试中可以这样总结：

传统 RAG 把文档预先切成 chunk，检索单元固定，容易出现语义切断、上下文丢失和参数敏感。
Chunking-free RAG 的目标是减少固定 chunk 依赖，通过 landmark、位置标记、长上下文和动态 span 选择，在更完整文档结构中定位证据。
它不是把所有文档无脑塞进 prompt，也不是完全不选择证据；而是把证据定位从离线固定切分转为 query-time 动态定位。
它适合长文档和跨 chunk 证据，但成本高、对模型能力要求高，工程上常与 parent retrieval、rerank、long-context RAG 混合使用。

19. 核心总结¶

Chunking-free RAG 的核心逻辑： - chunking 是传统 RAG 的关键瓶颈之一。

避免固定 chunk 可以减少语义切断和上下文丢失。
Landmark embedding 让模型能感知文档内部位置。
In-context retrieval 借助长上下文和位置标记在上下文中动态找证据。
最终仍要解决证据窗口、引用、忠实性、成本和评估问题。
生产中更现实的是 hybrid：粗召回 + 动态定位 + rerank + 长上下文生成。

20. 参考资料¶

BGE Landmark Embedding paper: https://arxiv.org/pdf/2402.11573
Chunking-Free In-Context Retrieval paper: https://arxiv.org/pdf/2402.09760
BAAI BGE models: https://github.com/FlagOpen/FlagEmbedding
LangChain Parent Document Retriever: https://python.langchain.com/docs/how_to/parent_document_retriever/
LlamaIndex Advanced Retrieval: https://docs.llamaindex.ai/en/stable/optimizing/advanced_retrieval/advanced_retrieval/
```
        预览时标签不可点
```
<div class="