← 返回概念解读

Concept Fable精修版

父子分块

Parent-Child Chunking · Retrieval preparation

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

寓言故事

小纸条找到门,大卷宗说明来龙去脉

城里档案馆最早按整卷出借资料。读者问一个细问题,抄录员就搬出厚厚一整册。册子里确实有答案,可读者常常要翻半天才找到那一段。

馆长嫌太慢,改成把卷宗切成很多小纸条。每张纸条只写一小段,查找变快了;只要问题里有相近内容,小纸条很容易被挑出来。

新麻烦也来了。读者拿到的小纸条经常缺前因后果。纸条写着‘按第三级审批处理’,却没说第三级是谁;写着‘例外按旧规’,却没带旧规在哪里。

有人提议把小纸条切得稍微长一点。长一点后,上下文多了,命中又变粗了;很多问题只需要一两句话,却被一大段无关内容挤进桌面。

另一个人建议给每张小纸条都补一段摘要。摘要越写越像新的卷宗,维护成本上升,还会出现摘要和原文不一致的情况。

一位年轻馆员换了做法。他仍然用小纸条负责找门牌,因为小纸条足够精细;但每张小纸条背后都挂着它所属的大卷宗、章节和相邻段落。

当读者提问时,系统先用小纸条匹配最相关的位置,再把对应的大段父卷宗拿上桌。小纸条负责命中,父卷宗负责解释。

后来,审批流程、产品手册、合同模板都按这种方式整理。查找不再在‘小而碎’和‘大而钝’之间摇摆,而是让两种颗粒度各做擅长的事。馆长最后在索引柜上写了一句话:找答案要细,给答案要全。后来读者也更信任馆员:他们不会只拿一张断句来解释复杂规矩,也不会把整册无关内容压到桌上。小纸条带路,大卷宗作证。馆员还会检查父卷宗是否过大。若一张小纸条背后拖出半间屋子的资料,读者仍会迷路;父与子的大小都要配合问题。

揭示

这个故事讲的是:父子分块

父子分块(Parent-Child Chunking)是一种 RAG 文档切分策略:用较小的 child chunk 做 embedding 和检索,以提高命中精度;命中后返回较大的 parent chunk、章节或原文片段,以保留完整上下文。它适合企业文档、合同、手册、SOP 等上下文依赖强的资料。相比单一 chunk size,父子分块能缓解小块上下文不足和大块检索不准之间的矛盾,但需要在索引中维护 child 到 parent 的映射,并控制返回父块的长度,避免把无关内容塞进模型上下文。

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

隐喻映射

  • 整卷出借:用大块文档直接检索,召回粗、上下文多但噪声大
  • 小纸条:child chunk,粒度细,适合做向量匹配或关键词命中
  • 缺前因后果:过小 chunk 容易丢失上下文
  • 把纸条切长一点:单纯调大 chunk size 会牺牲检索精度
  • 纸条背后挂着大卷宗:child 到 parent 的映射关系
  • 小纸条负责命中,父卷宗负责解释:父子分块的核心工作方式
  • 审批流程、产品手册、合同模板:适合 parent-child chunking 的企业文档类型
  • 找答案要细,给答案要全:检索颗粒度和生成上下文颗粒度分离

Soloharness 判断

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

chunkingretrieval granularity

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。