Parent-Child Chunk 分层索引

面试回答

固定切块加 overlap 可以补偿切分边界附近的信息，但政策的适用范围和例外说明可能相隔比较远，只增加相邻重叠，不一定能把这些条件一起带回来。overlap 过大还会增加重复文本，让相似片段占用召回名额。

所以我采用父子分块，让较小、主题集中的子块负责精确召回和重排，命中后再按父子关系补回完整条款。这样既能定位用户问的具体条件，也能让模型看到同一条款的前置条件和例外。子块仍然可以保留适量 overlap，两种方法配合使用，只是补充上下文的范围更多依据文档结构来确定。

面试回答

我们优先按文档结构切分，再设置长度上限。父块尽量对应一个完整条款或章节中的独立主题，子块再沿段落、句子边界细分，保证检索时主题集中。调参参考范围是子块约 200 到 400 tokens，父块约 800 到 1500 tokens，具体仍要结合条款结构。

选择大小时，我同时看检索效果和回答完整性。子块太大可能混入无关主题，太小又可能失去必要指代；父块太大则会增加上下文成本。我们通过离线测评比较不同粒度下的召回、排序、适用条件覆盖以及 token 开销，再选择合适的切分配置。

面试回答

这套方案里，MySQL 保存文档版本、父子块正文和关联关系，子块上记录 parentId、章节路径和页码。用于检索的是子块，全文索引保存子块文本供 BM25 使用，Milvus 保存 BGE-M3 编码后的子块向量和必要过滤字段。

检索、融合和重排确定子块后，再根据文档版本和 parentId 从 MySQL 回查父块，补充完整上下文。父块读取走关联关系，不需要再做一遍父块向量检索。回查时还会核对当前版本和权限，避免索引更新滞后时，把已失效或无权访问的正文交给模型。

面试回答

我们先对子块重排，再回溯父块。子块内容比较集中，Reranker 更容易判断它是否直接回答问题，输入长度和计算成本也比较可控。等相关子块筛选出来后，再补回它所在的完整条款，供后续生成答案使用。

如果先扩展为父块，同一父块可能被多个候选重复带入，正文长度也会明显增加，反而容易把真正相关的内容截断。不过子块也不能完全失去上下文，所以切分时会保留标题、章节路径和必要指代信息，让重排模型能够理解这一段在讲什么。

面试回答

我先按文档版本和 parentId 聚合，同一个父块只放进上下文一次，同时保留命中的子块和位置。父块排序主要使用其中相关性最高的子块得分，不把所有子块分数简单相加，避免长章节因为子块多就天然排在前面。

如果同一父块的多个命中分别覆盖问题的不同条件，装配时会保留这些证据范围。重排后的十个子块也可能只对应两个父块，所以去重后还会检查证据是否过于集中，必要时从后续候选中补充不同父块，但仍然受相关性和上下文预算限制。

面试回答

父块过大时，我不会直接从开头截一段，而是围绕命中的子块补充所属条款，优先保留标题、适用条件和例外说明。同一父块中多个相邻或重叠的命中范围先合并，减少重复，不同父块再根据相关性分配 token 预算。

如果回答依赖的必要条件仍然装不下，就通过后续读取或补充检索分步查证，不能为了满足长度限制把关键条件删掉。证据仍不充分时，就缩小当前回答范围。这样控制的是上下文开销，同时保留足以支持结论的完整依据。

面试回答

我按解析后的条款和表格结构切分，页码主要用于引用定位。一个条款即使跨了两页，只要编号、标题和正文是连续的，仍然需要关联起来，同时保留每个片段的来源页码。

表格要保留表名、表头、单位和附注。表格过大需要拆开时，每组数据行都带上必要表头，否则一个金额数字脱离照护等级和每人每月的单位就没有完整含义。跨页表格还要检查列结构和表头是否一致，不能只因为位置相邻就合并。最终引用指向真正支持结论的页面，涉及多页时保留多页来源。

面试回答

我用控制变量的方式比较。固定同一批文档和版本、同一测评集，以及 embedding、检索和重排配置，主要改变分块与上下文补充方式。检索侧看 Recall@10、MRR@10，回答侧检查适用条件和例外是否遗漏、引用是否支持结论，同时记录上下文 token 数与耗时。

这里使用我们构建的 200 余道题测评集。因为不同分块方案的 chunk ID 会变化，标准证据标到原文条款或范围，再判断各方案有没有找到。简历里 0.71 到 0.89 的 Recall@10、0.62 到 0.78 的 MRR@10 是整套检索改进的结果，父子分块的贡献要看它自己的对照实验，不能直接用整体增幅代替。