什么是语义切分？重叠窗口、按标题层级切分各解决什么问题？
谁在问：一二面；Q2-03 的自然下一层
口语化问法
- 除了按长度切，还有什么切分策略？
- 语义切分具体怎么实现的？
- 你们的文档是按什么切的？为什么选这个？
考察意图
考策略谱系的完整度和选型判断。面试官想确认你不是只会调 chunk_size，而是知道有一整套策略、每种解决什么问题、代价各是多少。能说出父子分块的候选人明显少数，这是本题的区分点。
参考答案
60 分答案（及格线）
主要有五类：固定长度（按字符/token 硬切，最简单但会切断句子，只适合原型）；递归字符切分（按 \n\n → \n → 句号逐级递归，兼顾自然边界和长度控制，是工程默认起点）；结构感知切分（Markdown 按标题、代码按函数、报告按章节，规范文档用这个精度最高）；语义切分（逐句算 embedding，相邻句相似度出现断崖处下刀，边界最贴合语义但索引成本高）；重叠窗口（相邻块保留一段重复内容，防止关键句被切在边界上）。
90 分答案（有生产经验的回答）
补两块：
父子/小到大分块（关键加分）——一个解耦的巧招：用小块检索、用大块回答。把文档切成小块（如 200 token）做向量索引，检索精度高；命中后不直接把小块给模型，而是回溯它所属的父块（整个小节）送进 prompt，保证上下文完整。这一招同时治好了「切大了检索不准」和「切小了上下文不全」这对矛盾。
语义切分的实现与取舍——先按句子切开，逐句计算 embedding，计算相邻句子的相似度序列，在相似度明显下跌（话题转换）的位置断开。代价是每句都要过一次 embedding 模型，索引成本和耗时都明显上升。所以实践顺序应该是：递归切分做基线 → 评测确认分块是瓶颈 → 才上语义或父子切分，不要一上来就用最贵的。
再补一句选型判断：文档有清晰结构就优先结构感知（投入产出比最高），没有结构才退回递归切分。而且结构感知还有个附带收益——能把标题路径作为元数据挂在 chunk 上，检索时既能过滤又能在 prompt 里给模型交代上下文。
追问链
结构感知切分为什么在规范文档上效果最好？
期望每个 chunk 天然对应一个完整主题，语义内聚性最强、向量不被稀释；附带收益是保留标题层级作元数据，用于过滤、引用溯源和给模型交代上下文信号能说出「标题路径当元数据」这个附带收益 → 是实际用过的信号语义切分要为每句算 embedding，成本上你怎么权衡？
期望索引是一次性成本可以接受，但增量更新频繁时会持续付费；折中两条：先递归切分到粗粒度、再在粗块内做语义细分以减少 embedding 调用，或只对高价值文档用语义切分信号完全不谈成本、把语义切分当免费午餐 → 缺乏工程判断父子分块的父块要多大？多个小块指向同一个父块怎么办？
期望父块通常是一个小节或 1–2 千 token；多个小块命中同一父块必须去重、只送一次，否则上下文里出现重复材料，既浪费预算又可能让模型误判重要性信号能主动想到去重问题 → 基本是真实现过你怎么判断当前的切分策略是不是瓶颈？
期望先用「手工塞正确文档」归因确认是检索侧 → 再看分桶 recall@k：正确 chunk 根本没进候选、且人眼抽检见到语义断裂，才是分块的锅；chunk 完整但排序靠后是排序的锅，改分块没用信号能把「分块问题」和「排序问题」分开 → 说明有排障框架同一个知识库里既有规范手册又有聊天记录和工单，怎么切？
期望按文档类型分流，不用一套参数：手册走结构感知；工单是短文本，一条工单本身就是一个语义单元、不必再切；聊天记录按会话或话题分段（时间间隔 + 语义变化双重信号）→ 全库统一的是元数据 schema，不是切分策略信号坚持全库一套参数 → 说明只处理过同质语料
评分要点
- 能列出至少三种策略并说明各自适用
- 说清递归切分是默认起点、固定切分不上生产
- 能解释语义切分的实现机制（句间相似度断崖）
- 说得出语义切分的成本代价
- 知道结构感知能顺带产出标题元数据
- 加分：说得出父子/小到大分块及其解决的矛盾
- 加分：主张按文档类型分流而非一套参数走天下