每周一道 Agent 面试题 - chunk 怎么切

开场

上一篇《每周一道 Agent 面试题 - Top K 怎么设》，我们聊了检索时该取多少段内容。K 调大以后，原来漏掉的信息有没有补回来，无关内容有没有变多，还得结合上下文预算和测试结果来看。

不过，判断 K 是否合适之前，还得看看取回来的每一段内容是怎么切出来的。

同样取 5 个 chunk，每块只有几句话，和每块包含一整节内容，交给模型的信息量就不一样。如果操作步骤和适用条件被切到了不同块里，只找回步骤，答案就可能漏掉限制。遇到这种情况，除了调整 Top K，还得检查文档切分和后面的上下文组装。

面试官也可能接着追问：

“你们 RAG 的文档怎么切 chunk？切多大，要不要 overlap，为什么这样设？”

你可能会先回答：“我们先切成比较短的块，相邻两块留一些重叠。”

这时，面试官再问“长度按字符还是 token 算”“为什么后来把块调大了”“重叠到底有没有用”，就得拿文档和测试结果来解释了。

这篇接着聊切法、大小和 overlap 的取舍，也看看短块找得准却答不全时，怎样补上缺少的上下文。

1、重点考的是什么

回答这道题，得能说出切分怎样影响检索和回答，尤其是信息被拆开以后，哪里会出问题。

第一层：切完以后，信息之间的关系还在不在

一段内容长度没有超限，并不代表它适合单独拿来回答问题。切分边界可能拆开条件和结论，也可能让一句话失去指代对象。

比如一份申请说明写着：

普通申请补齐材料后可以线上提交。特殊申请需要先完成审核，通过后才能提交。

如果两类申请被切到不同块里，用户问“申请怎么提交”时，系统只找回普通申请的那块，回答就可能漏掉特殊申请的审核要求。

审核要求还在知识库里，只是这次检索和上下文组装没把它带回来。切分改变了哪些信息会一起出现，也就影响了回答能不能说全。

类似的问题还有：

• 步骤保留下来了，适用条件被切到另一块；

• 表格数据和表头分开，只剩数字，看不出对应项目；

• “上述情况”“该方法”出现在块的开头，缺少前文；

• 代码和解释被分开，检索命中了代码，却没有带回使用限制。

拿这样的片段解释切分，比只报一个长度容易说清楚。哪些内容要尽量放在一起，已经拆开的怎么补回来，都能落到原文上。遇到漏信息，先确认解析后的文本有没有保留下来，再判断是否与切分有关。

第二层：切片大小怎么选

发现信息被拆开后，可以试着把 chunk 调大一点。不过，得看看多出来的内容是什么。

如果一段流程略长于当前长度，调大后能保留步骤和条件，就值得测试。多出来的内容要是已经转到另一个主题，命中这一块时，也会带回无关文字，占用上下文预算。

反过来，切得更短，某个定义或操作步骤可以单独被检索出来，但回答需要的其他信息也可能落在相邻块中。用户问的是整个流程，系统却只找到了其中一步，答案仍然不完整。

用户主要查字段含义、术语定义时，较短的块可能已经够用。经常问操作流程、适用条件和例外，就要检查这些内容有没有被拆散，检索能不能把它们找齐。

比较大小时，可以把同一段原文的两种切分结果摆在一起：短块的边界切断了什么？把块调大后，多保留了哪些内容？这些内容对回答有帮助吗，有没有混进其他主题？

对照这些片段，就能解释为什么从这个大小开始，后来调大或调小是为了修正哪类问题。

第三层：为什么需要 overlap，重叠多少才有用

块调大了，边界问题也未必消失。长文档仍然需要拆分，条件和步骤还是可能分到两块里，只是边界换了位置。

overlap 会让相邻块共享一部分内容，给跨边界的信息多一次一起被检索回来的机会。

假设原文有这样两句话：

以下提交流程仅限审核通过的申请。进入提交页面，填写信息并上传材料。

如果边界落在两句话之间，后一块只有操作步骤。用户问“在哪里提交、怎么操作”时，可能命中后一块，但这一块没有带上审核条件。

加入 overlap 后，如果重叠范围覆盖了前一句，后一块就会同时包含审核条件和操作步骤。即使只找回后一块，也有机会给模型提供完整依据。

如果只复制了“申请”两个字，仍然补不回审核条件。重叠多少得看实际复制了什么，有没有覆盖完整句子，能不能带回缺失的前提。

overlap 能补充的范围也有限。如果例外要求在几页之后，复制相邻的一段话仍然找不到它。这种情况需要考虑父子分块或检索后的上下文扩展。

重叠过多，还可能让相邻块反复包含同一段内容。假如前几个检索结果都在讲相同的步骤，其他必要条件就可能没有进入最终结果。

测试时固定块大小，只调整重叠长度，把无重叠和几档重叠各跑一遍。对照实际片段，看原来漏掉的条件有没有回来、重复结果多了多少，以及去重后是否保留了完整证据。选定重叠范围，也就有了依据。

第四层：选好的切片，能不能完整进入模型

切分预览看着完整，也可能在后面丢信息。

比如，为了保留一段流程，你把块调大了。先得确认，这个长度按字符还是 token 算。

如果切分器按字符算长度，embedding 模型按 token 接收输入，两边的长度就不能直接对应。需要用实际模型的 tokenizer 检查，尤其是包含英文、数字或代码的文档。

还要看真正送去编码的文本。预览里的正文可能没有超限，但系统如果又加上文档名、章节标题等内容，输入长度就会继续增加。

如果超过当前服务允许的长度，具体实现可能报错，也可能截断。假如尾部恰好是“特殊情况需要先审核”，截断后，这条要求就没有参与向量编码。

只读预览，容易忽略这种截断：条件还显示在块里，却没参与向量编码。

同样，检索找回以后，也要检查实际交给生成模型的内容。父块返回或邻近扩展可能补齐条件，但组装时如果又因为预算裁掉了它，回答依然可能遗漏。

把编码输入、最终上下文和切分结果对照，才能分清信息是在切分时拆开了，还是在后续处理里丢了。

第五层：如何评估切片的效果

切完以后，先读预览，检查句子、条件和步骤是否完整。检索效果好不好，还得用具体问题测试。

可以用几类问题来测：

• 查定义：某个字段是什么意思；

• 查流程：申请需要经过哪些步骤；

• 查条件：什么情况下可以直接提交；

• 查例外：特殊申请和普通申请有什么不同。

这些问题会暴露不同的切分问题。只测试定义类问题，即使结果不错，也不能说明流程和例外都能找齐。

每个问题都要标出回答需要的证据。比如“申请怎么提交”，既需要普通申请的材料要求，也需要特殊申请的审核要求。只找回“提交”相关的内容，缺了其中一项，仍然算没找齐。

有了这份依据，就可以比较同一单位下的短块和较长的块，或者固定块大小后比较有无 overlap。先保持文档、解析方式、embedding 模型和检索流程一致，减少其他变化的干扰。

先看切分结果：必要信息分布在哪些块里？条件有没有和步骤分开？块能否独立读懂？

再看检索和最终上下文：需要的证据有没有找齐？结果是不是反复返回相同内容？补充或裁剪以后，关键条件还在不在？

最后看回答：是否交代完整流程和例外，引用能否对应原文。某个方案找回了相关块，却仍然漏掉必要条件，就需要继续定位原因。

比较大小时，还要留意实际输入量：返回数量相同，块更大的方案本来就会给模型更多文字。控制这部分影响的做法，见后面的评测部分。

重新切分后，相关证据也需要重新映射。旧方案里的一块，在新方案里可能变成两块，不能直接沿用旧 chunk 的标注。

证据覆盖、答案遗漏和重复内容，要和 token、延迟、索引成本一起比较。比如 overlap 补回了边界条件，却带来很多重复结果，就还得调整重叠范围或去重方式。记录哪类问题改善了、哪类仍在漏，下次才知道从哪里改。

2、面试官的判分逻辑

“我们按标题切，超长条款再拆分，并保留一段适度重叠。”这样的回答交代了做法，面试官接着会问为什么。回答时，得把前面提到的问题放回具体文档里。

2.1、你说切分会拆散信息，具体会造成什么问题？

“条件和步骤分到两个 chunk 里，检索时多取几块不就行了吗？”

多取几块可以测试，但不能保证缺失的条件一定回来。

以前面的申请文档为例，操作步骤和审核要求被分到了不同块里。用户问“申请在哪里提交”，检索可能找回操作页面、上传材料等内容，却没有选中审核要求。增加 Top K 后，能否找回审核要求，仍然需要查看结果。

信息还在文档里，但被拆开后要分别参与检索。命中步骤的那块，不代表条件的那块也会跟着回来。

表格也是类似的问题。数据和表头分开后，即使检索找到了某个数字，模型也可能缺少判断它属于哪个项目的依据。带有“上述情况”的片段，则需要前文才能确定适用范围。

说“会破坏语义完整性”，面试官还不知道你遇到了什么。用原文指出互相依赖的内容、切完缺少的部分，以及答案可能漏掉的要求，才好继续讨论。

如果准备用父子分块或补充邻近段落来解决，还得说清楚会补回什么内容。

2.2、为什么从较小粒度开始，再逐步扩大？

“你们为什么从较小粒度开始？扩大切分范围以后会有什么变化？”

“短块更精准”是个判断，得有自己文档上的结果支持。

假设一段流程超过了当前长度，操作步骤在第一块，例外条件在第二块。如果调大后能把流程保留在同一块里，就减少了需要分别找回两块证据的情况。

还得检查多出来的内容是否仍然属于这个流程。如果已经包含另一个业务主题，每次命中这一块，也会带回无关文字。

比较时，把短块拆开的信息、调大后保留的内容和新增的无关文字标出来，取舍就容易解释了。

接着再看问题类型。如果用户主要查定义，较短的块可能已经够用；如果用户经常问完整流程，就要检查多个步骤和条件能否一起找回。

拿出两组切分片段，就能说明调整的理由。最终用哪组，还要看检索和回答结果。

2.3、为什么加 overlap，重叠范围怎么定？

“你已经按标题和段落切了，为什么还需要重叠？”

可以先讲当前切法留下的边界问题。比如，一个超长段落还得拆开，前一块末尾是适用条件，后一块开头是操作步骤。后一块单独被检索回来时，就可能缺少前提。

overlap 的作用，是把边界附近的一部分内容同时放进相邻块。如果重叠范围覆盖了完整条件，后一块便有机会同时带回条件和步骤。

但重叠范围有没有用，要看它实际包含什么。它可能覆盖完整句子，也可能只复制了一段没有独立含义的文字。所以别只看配置比例，把重叠后的片段调出来看。

“重叠加大以后，为什么结果反而不好了？”

先检查有没有重复召回。相邻块包含大量相同内容，前几个结果可能反复返回同一段步骤。数量没变，覆盖的独立信息却少了，其他条件可能因此没进入最终上下文。

如果条件补回来了，却被大段重复内容挤占了上下文，也不能直接说重叠有效。要检查去重之后的证据是否仍然完整。

如果相关条件在几页之外，overlap 通常够不到它，就得换一种补上下文的办法。

2.4、切分预览里内容完整，为什么还会漏？

“你已经确认条件和步骤在同一块里，模型为什么还是没用上？”

内容切在一起之后，还得经过编码、检索和上下文组装。

先看 embedding 阶段。切分器如果按字符控制长度，模型按 token 接收输入，两者不能直接对应。正文之外，如果又拼入标题等内容，编码长度还会增加。

如果实际输入超过服务限制，并被截断，那么预览里存在的尾部条件，可能没有参与向量编码。需要查看实际编码输入和截断配置，确认是不是这种情况。

再看生成前的上下文组装。检索结果里已经有完整证据，但排序、选择或预算裁剪之后，关键内容可能没有进入最终输入。

最后才看回答。如果证据已经完整交给模型，仍然漏掉条件，就需要继续检查生成阶段怎样使用这些内容。

答案漏了条件，原因未必是 chunk 太小。把这几个阶段的实际内容对着看，才知道信息丢在哪一步。

2.5、怎么证明新的切法效果更好？

“你说扩大切分范围以后更好，具体好在哪里？怎么测出来的？”

准备一批问题，标好对应证据。问题不能全是查定义，还要覆盖流程、条件和例外，不然测不出信息被拆散以后会有什么影响。

比较切分方案时，可以只改大小，保持文档、解析方式、embedding 模型和检索流程一致。

同一份证据，在这几个位置分别检查：

比如，加了 overlap 后，边界条件更容易进入检索结果，证据找齐率（recall）提上去了，答案里的对应遗漏也少了，这才有依据说它对这类问题有帮助。

换了切分方案，原来的 chunk 边界也会变化。评测标注应当依据源文档里的必要证据重新映射，不能直接沿用旧 chunk 的编号。

最后，再结合 token、延迟和索引成本决定是否采用。一个方案补齐了条件，但带来大量重复内容，可能还需要继续调整，而不是直接作为最终配置。

回答时把原来的错误、改后的片段和测试结果对应起来，也保留那些还没解决的问题。

3、怎么回答更稳

回答可以从自己的语料和用户问题讲起，说明怎么选切法、从什么配置开始测试，再用结果解释后续调整。

3.1、固定长度还是语义切分：先看文档结构

先打开文档。如果标题、条款、章节或函数边界很清楚，就可以从这些结构入手。一条规则的条件、步骤和例外，往往也能从排版和段落关系里看出来。

几种常见切法的区别如下：

以递归切分为例，可以先尝试按段落拆，段落太长再按句子等更细的边界拆。LangChain 的官方文档也区分了按长度、文本结构和文档结构等切分方式。

这些方法可以组合使用。比如，先按标题拆成章节，再对超长章节做递归切分。

还以前面的申请流程为例：

普通申请可以线上提交，提交前需要补齐材料。特殊申请需要先完成审核，再进入提交流程。

如果用户问“申请怎么提交”，回答就可能需要同时交代普通申请和特殊申请的区别。

假设边界刚好落在特殊申请之前，检索只找回第一块，模型就可能漏掉审核要求。可以分别测试增加召回数量、调整边界或补充上下文，看哪种办法能补回来。

这两句话很短，未必真的会被拆开；这里只是假设边界落在中间，说明长文档里可能发生的情况。

读切分预览时，留意这些地方：

• 条件和对应步骤有没有分开；

• 表格的数据有没有带上表头；

• 代码和解释是否还能对应起来；

• “上述”“以下”“该情况”这些指代是否找得到对象。

换成语义切分后，也用这些问题做对照。原来的错误有没有改善，改善是否值得增加计算和维护成本，都要测。

3.2、切多大：如何逐步扩大切分幅度，先看单位和模型限制

切片长度的单位要先确认。同一个数值，在某个平台里指字符，在另一个平台里可能指 token，不能直接比较。

几份官方资料里的配置就不一样：

对应资料分别是百炼创建索引接口、阿里云 Dify FAQ、QAnything v2 API 文档和RAGFlow 数据处理流程介绍。

这些推荐值和默认值可以作为实验起点，但不同平台的配置并不统一，实际还得看语料。

Dify 的分段文档明确按字符配置最大分段长度和 overlap。使用其他框架时，也要检查它的长度计算方式。

结合 ModelScope 的模型页、模型卡和官方评测，文本 RAG 可以先测试 Qwen3-Embedding 系列。需要稠密、稀疏和多向量混合检索时，也可以把 BGE-M3 加进来比较。

Qwen3-Embedding 系列的规格和版本关系见官方发布说明。模型卡里的成绩要连着评测日期一起看，ModelScope 的页面更新时间和下载量也不能当成效果排名。这些候选在自己的文档上表现如何，要用同一批问题比较，不能凭上表就认定哪个模型在所有语料上都最好。

输入上限说明模型能接收多长的文本，并不直接告诉你块该切多大。

如果模型的输入上限较短，更要把实际文本交给对应的 tokenizer 检查。平台按字符设的长度，未必能直接对应模型的 token 限制，中文、英文、数字和代码的分词结果也不同。

正文之外，拼进去的文档标题、章节路径和特殊 token 也可能占用输入长度。

用云端 embedding 服务时，确认具体接口和地域，还要看长度限制针对单条文本还是整个批次。百炼的 embedding 文档列出了不同接口的限制，某个接口的数字不能直接套到所有模型上。

确认这些限制后，可以从模型或框架的默认长度起步，在同一单位下逐步把块调大。每次保持解析方式、embedding 模型和检索流程一致，用同一批问题比较。

先看切分预览。短块如果把规则拆散了，调大后有没有保留完整段落，多出来的内容是不是仍在讲同一件事？再检查检索和回答，记录证据是否找齐、例外是否遗漏、引用是否对应原文，以及总输入 token 和延迟。

短块经常拆开完整步骤，调大后能保留它，就可以继续测试更大的块。如果原来的块已经够用，多出来的主要是其他主题，再调大就未必有收益。

3.3、要不要 overlap：检查边界损失，也检查重复成本

overlap 会把上一块末尾的一部分内容，保留到下一块开头。

它可以让靠近切分边界的信息出现在相邻块中。Dify 的分段文档也介绍了分段重叠的作用。

比如，前提在上一块结尾，步骤在下一块开头。加入适当重叠后，下一块就可能同时包含前提和步骤。

固定长度滑窗和递归切分的 overlap，表现并不一样。按字符平移的固定窗口，每块开头复制上一块末尾，重复量比较均匀，大约是重叠长度占块长的比例。边界在哪里、重复多少，可以事先算出来。

递归切分按分隔符拆，保留下来的可能是前一块的整句或整段。重复集中在边界附近，具体位置取决于文本结构，得读切分预览才能确认。去重时尤其要留意：这段重复内容可能正是补回的前提，直接删掉，又会缺条件。

不过，重叠能带回多少信息，取决于它的范围。如果某条例外在很远的另一节里，复制相邻的一小段内容仍然不够。这时就需要考虑文档结构、父子分块或检索后的上下文扩展。

重叠也会让一部分内容重复进入索引。如果相邻块都被检索回来，模型上下文里可能出现大段重复文字，占用了本可以留给其他证据的位置。

测试时固定块大小，从不重叠开始逐步加大，单位与当前配置保持一致。尤其留意需要跨边界信息的问题，记录边界信息补全了多少、重复增加了多少，并检查去重后必要条件是否仍在。

如果完整条款或自然段已经保留了必要关系，也可以试试少量重叠，或者不重叠。

3.4、粒度与上下文完整性的矛盾怎么解

有时会遇到这样的情况：短块检索得挺准，但给模型的信息不够；把块放大以后，上下文多了，却又混进其他主题。

检索用的块和交给模型的内容，可以分开设计。

父子分块就是一种做法：用较短的子块匹配问题，命中后返回对应父块。Dify 的父子分段说明采用了这种思路。

回到前面的申请例子。一个子块可能只包含“线上提交”的步骤，便于匹配相关问题；返回父块时，再带上适用条件和审核要求，帮助模型形成完整回答。

父块的范围仍然需要控制。每次命中都返回很长的章节，可能又会增加无关内容和上下文成本。

另一个办法是扩展邻近段落。命中后，按需补充前后内容，让被拆开的步骤或条件一起进入上下文。

LlamaIndex 里也有这两类实现。sentence-window 检索单句，命中后带出周围的窗口；auto-merging 按层级组织块，子块命中得多就合并成父块返回。这类做法常统称 small-to-big，也就是用小块匹配，用大块回答。

补充多少要看文档结构和问题，并控制在上下文预算内。标题和路径也要保留。单独一句“需要先审核”，读者不知道它在说哪类申请；带上“特殊申请／提交流程”，就能看出适用范围，引用也更清楚。

除了检索后补上下文，也可以在索引阶段处理。

contextual retrieval（Anthropic 2024 年 9 月提出）会让 LLM 为每个块生成一段几十个 token 的说明，交代它在全文中的位置，拼在块前面再做 embedding。这段说明补上了“该方法”“上述情况”的指代对象，也可以用来建 BM25 索引。

官方在自家语料上报告，配合 BM25 和重排序，top-20 检索失败率最多下降 67%。这是他们的测试结果，换成自己的语料未必一样。成本在于索引时每个块都要调用一次 LLM，可以通过提示缓存减少开销。

late chunking（Jina AI 2024 年提出）则先编码，再按块池化。整篇文档送进长上下文 embedding 模型，拿到每个 token 的向量后，再按块边界池化成块向量。编码时每个 token 都能看到全文，指代和条件的上下文也参与了表示，不需要额外调用 LLM。

前提是模型的上下文能装下整篇文档（8K 以上）。文档超过这个范围，就不能直接这样处理。

这两种方法都在索引阶段调整。测试时比较指代类问题的 recall，再记录增加的索引成本和耗时，判断是否值得采用。

父块返回、邻近扩展和多次命中都可能产生重复，组装时还可能因为预算限制丢掉部分内容。最后检查去重、裁剪后的上下文，确认条件和步骤仍然在里面。

3.5、建立评测闭环，再与 Top K 联动

如果切法、embedding 模型和检索方式一起换了，即使结果变好，也很难知道哪项调整起了作用。比较时先只改切法或大小，其他条件尽量一致。

评测问题里，有些一句话就能回答，有些需要完整步骤，还有些必须同时看到条件和例外。表格和代码是否要测，则看实际语料。

如果测试集只有“查一个定义”这类问题，就很难发现流程被拆散以后会造成什么影响。

标注时，尽量记录答案对应的源文档证据。重新切分后，再把证据映射到新 chunk，才能比较不同方案有没有找回同一份必要信息，减少边界变化的干扰。

找回一个相关 chunk 后，还得检查证据是否完整。步骤找到了，例外没找到，答案仍可能漏信息。

给每个问题标好必要证据，就可以统计找回了多少，而不只是看结果是否相关：

比如“差旅报销怎么提交”需要两条证据：审批条件和提交步骤。只找回步骤，这个问题的 hit rate 已经满分，recall@K 却只有一半。所以一题需要多条证据时，还得看 recall@K。

方案 A 和方案 B 用同一批问题、同一份证据标注，映射到各自的 chunk 后分别计算。比较两组 recall，比“看着找齐了”更容易说明变化，也能发现退步。如果某类问题的 recall 降了，再查看对应的检索结果，通常能看出是边界重新拆开了证据，还是排序变了。

回答也可以检查漏项。把每个问题的必要条件列成清单，答案没交代就记一项，再统计漏项率。问题多了，可以让 LLM 按清单判断。RAGAS 这类框架也用于自动评测，faithfulness 看答案是否依据给出的证据，answer relevancy 看是否切题。自动判分可能出错，需要抽一批结果人工核对。

recall 低，说明证据没找全，先查切分和检索；recall 不低，漏项率却高，问题多半在上下文组装或生成。数字能帮助确定先查哪里，具体原因还得沿着第四部分的流程检查。

切片大小变化后，上一篇讨论的 Top K 也要一起考虑。先固定 Top K，看每组配置在相同返回数量下的表现；再把上下文 token 预算控制到相近水平，检查改善是否主要来自更多的输入内容。

比如，调大块以后回答更完整，可能是边界更合适，也可能是同样的 K 给模型提供了更多文字。控制上下文预算，可以帮助区分这两种情况。

涉及父子分块或邻近扩展时，不能只用 K 乘平均 chunk 长度估算。需要统计组装、去重后的实际输入：

最终组装后的检索内容 token 总量 ≤ 可用上下文预算

还要留意，embedding 模型和生成模型的 tokenizer 可能不同。编码时没有超限，不代表生成阶段的 token 数可以按同一个结果计算。

保留这两轮结果，面试时就可以说明当前方案的依据，再结合错误类型和成本，解释还需要调整什么。

3.6、约 90 秒的面试口述答案

下面以报销制度知识库为例，示范怎么回答。实际面试时，换成自己做过的项目、配置和测试结果。

我会先看文档和用户常问的问题。比如报销制度里，普通报销要补齐材料后提交，差旅报销还得先审批。审批条件和提交步骤如果分在两块里，问“差旅报销怎么提交”时只找回步骤，就会有漏答审批要求的风险。

我会按标题和条款切，太长的条款再按句子拆。先确认长度单位是字符还是 token，从短块开始逐步调大，看能不能把条件和步骤留在一起，同时用对应模型的 tokenizer 检查有没有超限。

漏答如果集中在边界附近，就固定块大小，对比有无 overlap。重叠能不能把“差旅报销需先审批”带到下一块，带回来以后是否少了漏答，相邻块会不会重复太多，都得看结果。

各组都用同一批报销问题测，比较证据的 recall、审批条件的漏答情况，以及实际上下文 token 和延迟。短块找得准却答不全时，我会试着返回父块或补上邻近段落。还要把 Top K 一起考虑，在相近的上下文预算下再比一遍，确认改善是不是主要来自多放了文字。

4、再遇到这个问题的解答思路

遇到答案漏信息，可以沿着这条链路检查：

原文 → 解析 → 切分 → 检索 → 上下文 → 回答。

模型漏掉特殊申请的审核要求时，可以按这个顺序查。

先看原文里有没有这条要求，解析后的文本有没有保留下来。如果解析时已经丢了，调整切片大小也补不回来。

然后看切分结果。审核要求被放在哪一块？它有没有和对应申请类型分开？有没有出现缺少指代对象的片段？embedding 时是否发生截断？

再看检索。对应证据有没有进入候选结果，排在哪里，最终是否被选中？

检索已经找到了证据，就查上下文组装：父块或邻近内容有没有补回来，去重和预算裁剪有没有删掉关键要求？

证据完整进入模型输入后，回答仍然漏项，再检查生成阶段怎么使用这些证据。

找出信息丢在哪一步，再决定改哪里，避免反复试 chunk 大小却没解决问题。准备面试案例时，保留这几个阶段的结果，追问到某个判断，就能拿出对应片段解释。

5、哪些知识需要形成肌肉记忆

这几类问题，可以记住各自从哪里查起：

字符和 token 不能按固定比例换算，要检查实际文本在对应 tokenizer 下的长度。

平台里的最大长度是配置上限，实际切出来的块可能更短，以切分预览为准。

模型规格和部署配置也要分别检查。模型支持的长度，未必就是当前服务实际采用的长度。

检索单元和最终上下文单元可以不同。使用父子分块、邻近扩展以后，要重新检查实际返回内容、去重和预算。

复习时，试着用自己的文档回答：为什么从当前大小开始？怎么确认没有截断？漏信息时先查哪里？换了切法，拿什么结果判断它更好？卡住的地方，回去补原文片段或测试记录。

6、下篇预告

下一篇：《每周一道 Agent 面试题 - 现在市面上的 Embedding Model 怎么选择》。

切片能完整送进 embedding 模型之后，还要看这个模型能不能把自己的文档检索好。

面试官可能会问：“你们为什么选这个 Embedding Model？比较过哪些候选，依据是什么？”模型名字和榜单名次之外，还得说说它在自己语料上的表现。

下一篇会聊模型在中文、英文和代码语料上怎么测，输入长度与切片怎么配合，以及向量维度、部署方式、延迟和成本的取舍。换模型后怎么验证检索效果、什么时候需要重新选型，也会一起讨论。

7、结束语

准备这道题时，可以找一篇熟悉的文档，里面有完整步骤、适用条件和例外就更好。先切成短块，再逐步调大，保持单位一致，用同一批问题测试。

把切分预览、检索结果、实际模型输入和最终答案放在一起看。条件被拆开了没有？相关内容有没有找齐？前几个结果是不是重复？组装后的上下文还保留了哪些证据？记录这些变化，也记录仍然出错的问题。

调 chunk 的时候，也留意上一篇的 Top K。取回多少块、每块多大、边界在哪里，命中后又补了什么内容，都会影响模型最后看到的文本。

面试官追问配置的依据时，就用这些片段和测试记录回答：当时遇到了什么问题，怎么改的，哪些结果支持这个选择，还有什么情况需要继续调整。