← 返回概念解读

Concept Fable精修版

分块

Chunking · Retrieval preparation

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

抄录员把长卷切成能被找到的页

档案馆里有一批很长的卷宗。有的从城门修缮讲到桥税,有的从商队纠纷讲到码头条例。馆长知道这些卷宗重要,但每次有人问一个小问题,他都要把整卷摊开。

最早的办法是整卷入库。这样最省事,卷宗也完整。可读者问‘东桥南侧能不能临时搭棚’,检索员只能把一整卷《街市与桥梁年志》搬来,里面九成内容都不相关。

有人嫌太长,就把每卷按固定长度剪开。每十尺一段,整整齐齐。头几天速度快了,后来问题来了:一条关键规定常常前半句在上一段,后半句在下一段;读到的人只看见半个意思。

于是抄录员改按标题切。每遇到一个小标题,就另起一页。这比十尺一刀好,但有些卷宗写得乱,标题很少;有些标题漂亮,下面却混着三个完全不同的问题。

有个年轻抄录员开始先读内容。他发现真正该切开的地方,不是尺子到哪里,也不一定是标题在哪里,而是意思在哪里换了边界:从桥梁结构转到税务,从条例原文转到裁决案例,从背景转到例外条件。

他还给相邻页留下少量重叠。因为有些问题跨在边界上,完全切断会让下一位读者失去来龙去脉。

后来,馆长规定:长卷入库前,必须先切成适合提问和检索的页。页太大,找回来噪音多;页太小,意思碎了;边界切错,答案就会从一开始歪掉。

读者仍然看到的是馆长的回答,但真正决定回答质量的,常常是那些问题发生前就完成的切页工作。档案馆的人这才明白:资料不是放进去就能被用。要先把长知识切成能被找回、能被理解、能被引用的单位。后来档案馆复查几次错答,发现许多错误并非馆长读错,而是页切得别扭。有人只拿到条例,没有拿到例外;有人拿到案例,却漏了前面的适用范围。馆长于是要求切页人写下边界理由,并定期把被找回却无用的页、该找却没找回的页拿来重切。切页从杂活变成了决定检索质量的手艺。

揭示

这个故事讲的是:分块

分块(Chunking)是把长文档切成适合检索和放入模型上下文的小片段。RAG 系统通常不能直接把整份文档都塞给模型,而是先把文档切块、向量化、索引,再按问题召回相关块。分块质量会直接影响召回精度、上下文完整性、引用准确性和答案质量。好的 chunking 不是机械按字数切,而要考虑语义边界、标题结构、重叠、块大小、父子块和 token 预算。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 很长的卷宗:企业 PDF、网页、手册、合同、知识库文章等长文档
  • 整卷入库:不分块或块过大,召回噪音高、成本高
  • 每十尺一段:固定长度切分,简单但容易切断语义
  • 按标题切:结构化切分,依赖文档本身格式质量
  • 按意思换边界:语义分块,尽量保持一个 chunk 内主题完整
  • 相邻页留下重叠:chunk overlap,用少量重复降低边界断裂风险
  • 页太大和页太小的权衡:chunk size 对召回和上下文完整性的影响
  • 问题发生前的切页工作:chunking 是 RAG 的前置工程,不是回答阶段才补救

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

document parsingtoken budgetoverlapsemantic chunkingretrieval granularitycontext window