第 3 章 — 进阶分块框架
LLM Primer III: Enhancing Enterprise AI with RAG 章节走读的第三篇。朴素的分块选择最会悄悄拖垮下游每一件事 — 以及最近两项把可能的上限都改写了的技术。
这一章为什么存在
文档解析过之后,下一个决定也是后果最大的:把它切成小到能嵌入、又大到还能自成一意的块。这是分块。一个把定义和它的限定条件切开的块,会被自信地检索出来,然后给出错的答案。一个把五个不相关话题捆在一起的块,会稀释它所触及的每一个嵌入。后面搭出来的检索系统,只能把分块那一步留下来的东西捞起来 — 而这一层的失败形态,是安静的:检索器仍然返回候选、模型仍然写得很顺,只有用户察觉答案微微地不对。
3.1 分块谱
把策略按「它对这份文档知道多少」排一排,会清楚很多。这一头,定长分块 什么都不知道 — 数 token,切。快、可复现,对风格均匀的短文(聊天记录、FAQ、用户评论)够用了。在结构性强的技术文档上,它是一场静音灾难。递归分块 走一份优先级清单 — 段、行、句、词 — 在能装进目标大小的最高级别上切。几乎和定长一样便宜,效果好得多。这是大多数团队该选的默认。
语义分块 把决定从句法挪到语义:把每个句子嵌入,沿着序列走,相邻句相似度低于阈值的地方就划话题边界。在结构线索弱的长文上(分析师报告、访谈记录)效果好;在结构性强的技术文档上反而差 — 密集的交叉引用和重复的模板会把句嵌入弄糊。结构感知分块 把解析过的文档当作一棵树,沿着树切 — 按章节、按标题级别、按代码函数。做好了是最忠实的那一类分块;上游没有版面感知解析器,它就和递归分块没区别 — 因为结构压根没被抽出来。这四种是互相替代的关系,不是叠在一起部署的栈。
3.2 「重叠率」迷思,以及 context cliff
几乎每一份教程都建议 15–20% 的块重叠。直觉那一半没错 — 重叠能防边界损失 — 但收益曲线很快就平了。头 10% 把绝大多数好处拿回来了。过了 25% 左右,准确率几乎不动,代价却沿三条轴在涨:嵌入账单跟块数线性走、索引体量和查询延迟跟着涨、检索结果里 top 几名开始互为近重复。用户的查询匹中了 A、B、C 三块的同一段;上下文窗口被吞掉,新信息没进来;重排器把预算花在反复给同一段内容换顺序。一个团队把重叠率往 30–40% 抬,那是信号:分块器选错了,而不是重叠不够高。
与之相关又不同的一件事是 context cliff — 一个块一旦失去了让它能被找到的那几个锚词,检索质量会陡降。某一段以「2023 年对 47-B 号政策的修订,要求所有分行…」起头,接下来几句具体描述这条要求。从开头之后切一刀,描述要求的那个块再不提政策、不提修订、不提年份。它会被自信地检索给不相关的查询,而漏掉真正该匹中的那一句。检索是 top-k — 块要么被捞上来,要么压根没出现,没有所谓的平滑降级。这条悬崖,是技术语料里的头号失败形态 — 在技术文本里,代词和简称把先行词在一节里一路向后带。
3.3 把块大小对上查询类型
「最佳块大小」常被当成只有一个答案的问题来争。它不是 — 因为答案取决于系统要应付什么样的查询。一个事实型查询 — 「47-B 号保单 2024 版的免赔额是多少?」— 要 150–300 token,窄到精确、又宽到消歧。一个推理型查询 — 「总结 2023 和 2024 两版之间的变化,并解释它对续保的影响」— 要 800–1,200 token,把一节里的连接组织保下来。两者的最佳大小差 4–8 倍,而生产里的流量,通常是这两类混在一起。
有两条有效的应对。多粒度索引 把同一份语料按多个块大小都存一遍,按意图分类把查询分发过去。分级检索 用小块建索引以求精度,但返回它们所属的父段以补上下文 — 一份索引,在查询时按需做条件,生产里更常见,因为意图分类出错时它的降级更平滑。「父文档」这一套,是生产检索文献里收益最高的几项技术之一。
3.4 上下文检索与 late chunking
前沿是这样一件事的觉醒:「块」和「嵌入」是两个可以分开的概念。最近两项技术,从相反的方向利用这层分离。上下文检索(2024 年 Anthropic 把它推开)把每一个块连同整份文档喂给一个便宜的 LLM,问它写一两句这个块在文档里坐在哪儿 — 「这一块讲的是 2024 年 47-B 号政策修订引入的免赔额计算调整」 — 把这一句话拼到块文本前面再嵌入。块就能被原文里没出现过的那些查询找到。Anthropic 在自家评测上报告检索失败减少约 49%,与混合检索和重排叠加之后更多。让它经济上跑得通的窍门是 prompt 缓存:文档发一次,每个块对着缓存的版本处理一次。
Late chunking(2024 年 Jina AI 提出)从反面攻同一个问题。整份文档在一个长上下文嵌入模型里一次过,产出已经被整篇上下文化了的 token 级嵌入。这时再分块,每个块的嵌入,从它现在已经被上下文化的 token 里池化出来。不再多调 LLM;块嵌入隐含地继承了文档级上下文。约束是嵌入模型得原生支持(jina-embeddings-v3/v4 和少数研究模型行),文档得装进模型的窗口。能装下的文档,late chunking 用 contextual retrieval 几分之一的索引代价做到差不多的事。装不下的文档,contextual retrieval 更通用。两者并不互斥,认真些的生产系统常常两条都跑,顶上加一层去重。
第 3 章接下去会怎么走
分块把一份解析过的文档变成一群可被检索的单位。每个单位都得有地方住 — 存得下、能建索引、能低延迟查询、随着语料变还能更新。那个「地方」就是向量数据库,而选向量数据库这件事,和选分块策略完全是两类决定。分块是软件问题,代价也在软件里。数据库选型是个软件问题,代价却落在基础设施、运维、合规上,选错了,撤回得花六个月。
明天 — 第 4 章:选对向量数据库。专用架构与扩展架构、托管派的主角、开源派的阵营,以及真正决定选型的那三根轴 — 数据驻留、运维形态、总成本。
