ZGI 父子分块：连接检索片段与完整上下文

知识库把长文切得太短，定义和适用条件容易落在不同片段；切得太长，候选中会混入大量无关内容。父子分块用两种粒度保存同一份资料：子块负责靠近查询，父块保留更完整的语义范围。检索系统可以先定位短片段，再按父子关系补充上下文。

ZGI 的文档处理链路会持久化父块、子块及其关联关系，并记录生成批次、内容哈希和状态。这样的数据结构给分层检索提供了基础。实际返回父块、子块或两者组合，需要结合检索配置与真实问题验证，不能靠一组固定字符数决定。

两种粒度承担不同任务

父块通常覆盖一个完整章节、条款或问答单元，能够带上标题、条件和必要背景。子块从父块中拆出更短的内容，减少无关文字对匹配的干扰。检索命中子块后，可以沿父块标识找到它所属的完整范围，再把合适长度的内容交给模型。

父块越大，上下文越完整，带入的噪声也可能增加；子块越小，匹配越聚焦，语义断裂的风险也会上升。分块策略需要跟着资料结构走。制度文档可以按标题层级建立父块，FAQ 保留完整问答，接口文档把参数表和接口说明放在同一父块内。

列表、表格和代码也需要单独考虑。列表项通常依赖上方标题，表格数据依赖表头，代码片段依赖函数说明和输入输出。子块可以保留具体条目，父块应覆盖解释这些条目的结构。统一按字符数切分，会把这些关系拆开，随后再增加重叠窗口也只能缓解一部分断裂。

父子分块解决的是内容粒度，无法单独承担整个检索质量。查询改写、关键词匹配、向量检索、候选数量和重排都会影响最终候选。正确子块完全没有出现时，应继续检查检索方法和过滤条件；子块已经出现，却带回了错误父块，再回到父子标识和生成批次排查。

资料重新解析或修改分块规则后，同一文档会产生新一批片段。只覆盖正文，很难判断线上候选来自哪个版本。ZGI 的分块数据会保留文档资产、处理任务、生成编号、父块标识、位置和内容哈希；向量记录还需要关联模型、维度与生成状态。

这些字段适合回答三个排查问题：候选来自哪份文档，当前子块属于哪个父块，向量对应哪一次生成。发现旧内容时，可以沿生成编号检查索引是否完成更新；发现片段断裂时，可以回到父块和原始位置核对切分边界。

重建索引时，旧批次和新批次需要有清楚的切换点。文档正文、分块结果和向量若来自不同批次，线上结果会很难解释。发布前可以抽取若干父块，核对其子块数量、顺序和内容哈希，再确认对应向量处于可用状态。

分块效果要用真实问题判断。先收集二十到五十个常见问题，标出期望命中的文件、章节和答案范围。测试时分别看正确子块有没有进入候选、父块补充后是否带回必要条件，以及无关段落是否挤占上下文。

同一批样本可以比较两套分块策略，记录命中位置、候选排序和最终引用片段。专有名词、编号和表格字段通常需要更完整的结构保留，口语问题则更依赖短片段的语义匹配。ZGI 父子分块提供了组织两种粒度的方式，合适的父块边界与子块长度仍要由企业资料和问题样本决定。

调整时一次只改一个变量，例如父块边界、子块长度或重叠范围。多项参数同时变化，结果提升或下降都很难找到原因。保留同一组问题和期望片段，下一次资料更新后还能继续复测。