---

先说一个前提：Chunking 没有“最优策略”，只有“最适合当前文档类型 + 检索任务 + 生成任务”的策略。所以回答时不能只列策略，要说清楚每种策略解决什么问题、代价是什么、什么场景选它。

1、固定长度切分（Fixed-size Chunking）

做法：按固定 token 数或字符数切，比如每 512 token 一块。

适合场景：

• 文档结构弱、格式不统一，比如爬虫抓来的网页、聊天记录、日志。
• 快速搭 baseline，先跑通链路再优化。
• 文档本身段落很短、语义边界不明显。

优点：

• 实现最简单，块长可控，索引和检索成本可预估。
• 对 Embedding 模型友好，因为大多数模型有最佳输入长度。

缺点：

• 容易在句子中间、段落中间切断，破坏语义。
• 关键信息可能被切到两个块里，导致召回时只命中一半。

关键取舍：

• 块太小 → 检索准但上下文不足，生成时信息不够。
• 块太大 → 上下文足但噪声多，向量语义被稀释，召回精度下降。
• 一般 256~512 token 是常见起点，但必须用评估验证。

2、滑动窗口切分（Sliding Window Chunking）

做法：固定长度切分，但相邻块之间有重叠，比如块长 512，重叠 128。

适合场景：

• 固定长度切分的升级版，适合语义边界不明显但又怕切断的文档。
• 法律条文、技术文档、长段落说明文，关键信息可能跨段。

优点：

• 缓解切断问题，跨块信息在重叠区被保留。
• 实现仍然简单，容易和固定长度结合。

缺点：

• 索引膨胀，重叠越多，存储和检索成本越高。
• 检索时可能召回多个高度相似的块，造成冗余和噪声。
• 生成时如果多个重叠块都进上下文，浪费 token。

关键取舍：

• 重叠比例：一般 10%~25%。太小没效果，太大成本高且冗余。
• 需要配合去重或重排序，避免重复块挤占上下文。

3、按语义切分（Semantic Chunking）

做法：按句子、段落、语义相似度变化点切分。常见做法有：

• 按段落/句子边界切。
• 用 Embedding 计算相邻句子相似度，在相似度骤降处切。
• 用 LLM 判断语义边界。

适合场景：

• 文档结构较好、段落语义完整，比如论文、报告、书籍。
• 对检索精度要求高，且愿意承担更高计算成本。
• 需要保留完整论证或完整语义单元的场景。

优点：

• 保留语义完整性，检索命中的块更可能直接可用。
• 生成时上下文更干净，减少噪声。

缺点：

• 块长不均匀，可能出现过短或过长块。
• 用 Embedding 或 LLM 切分，计算成本高、速度慢。
• 语义边界判断本身有误差，不一定比固定长度好。

关键取舍：

• 效果 vs 成本：语义切分通常效果更好，但索引构建更贵。
• 块长控制：需要设置最大块长，避免单块过大。

4、按标题层级切分（Hierarchical / Structural Chunking）

做法：按 Markdown、HTML、PDF 的标题层级切分，比如 H1 → H2 → H3，保留层级路径作为元数据。

适合场景：

• 结构化文档：技术文档、API 文档、产品手册、法律合同、书籍。
• 文档有明确章节，且章节内语义集中。

优点：

• 天然语义边界，块内主题一致。
• 可保留标题路径（如“第3章 > 3.2 节 > 安装步骤”），增强检索和溯源。
• 支持父子块：小块检索，命中后返回父块或相邻块生成。

缺点：

• 依赖文档格式，格式差的文档无法用。
• 标题层级过深或过浅时，块长可能很不均匀。
• 需要额外的解析和清洗工作。

关键取舍：

• 是否保留父子关系：保留则检索精度和生成质量都好，但索引和逻辑更复杂。
• 标题路径是否入向量：入向量增强语义，但也可能引入噪声。

5、策略对比总结

策略	适合场景	优点	缺点
固定长度	格式乱、快速 baseline	简单、可控	易切断语义
滑动窗口	怕切断、语义边界弱	缓解切断	索引膨胀、冗余
语义切分	语义完整、高精度要求	语义完整	成本高、块长不均
标题层级	结构化文档	边界清晰、可溯源	依赖格式

实践建议：

• 先用固定长度 + 重叠做 baseline。
• 文档结构化好 → 标题层级 + 父子块。
• 文档语义强但结构弱 → 语义切分。
• 最终都要用评估数据验证，不要凭感觉选。

6、如何评估切分质量？

这是这道题的核心追问点，很多人只答策略不答评估，会丢分。

（1）间接评估：看端到端效果

切分质量最终影响检索和生成，所以可以通过下游指标反推：

检索阶段：

• Recall@K：正确文档是否被召回。
• MRR / NDCG：正确文档排得是否靠前。
• Hit Rate：Top-K 里有没有命中。

生成阶段：

• Faithfulness：答案是否基于检索内容。
• Answer Correctness：答案是否正确。
• Context Precision / Context Recall：检索上下文是否相关且完整。

如果切分策略改变后，这些指标提升，说明切分更好。

（2）直接评估：构造“切分-查询”标注集

• 人工标注一批 query 和它对应的“正确块”。

• 看不同切分策略下，正确块是否被完整保留、是否被召回。

重点看：

• 块完整性：答案是否落在同一个块内。

• 块独立性：块是否脱离上下文也能理解。

• 块粒度：是否过细或过粗。

（3）启发式指标

• 块长分布：是否均匀，是否有超长/超短块。

• 语义一致性：块内句子相似度是否高。

• 边界质量：是否在句子/段落中间切断。

• 重叠冗余率：重复内容占比。

• 检索冗余率：Top-K 中重复或高度相似块的比例。

（4）人工抽查

• 随机抽块，看是否语义完整、是否可独立理解。

• 抽 bad case，看是切分问题还是检索/生成问题。

• 对比不同策略下同一 query 的召回块，判断哪个更合理。

（5）A/B 测试

• 线上切分策略 A/B，看用户点击、满意度、答案采纳率。

• 这是最真实的评估，但成本高、周期长。

一句话：切分质量没有单一指标，要结合下游检索生成指标 + 块级人工评估 + 线上 A/B综合判断。

7、这道面试题的质量点评

优点

聚焦且深入：只问 Chunking，但能一路追问到评估，考察深度。

有真实区分度：做过 RAG 的人能说出场景和取舍；只背八股的人只能列四种策略。

评估环节是关键分水岭：能答出“如何评估切分质量”的人，通常真做过调优。

贴近工程实践：切分是 RAG 最常见、最容易被忽视、也最影响效果的一步。

缺点

四种策略并列，容易变成背诵题：如果候选人只对比四种策略，不结合场景，区分度会下降。

缺少业务约束：没给具体文档类型，候选人可以泛泛而谈。

评估部分偏开放：如果面试官不追问，候选人可能只答“看 Recall@K”就结束。

没有涉及父子块、元数据、多模态等进阶点：这些是当前工业界常用手段，题目没提。

总体评价

质量：中上偏上。 作为 RAG 专项题，它比“介绍 RAG 流程”更有区分度，因为 Chunking 是细节，能看出候选人是否真正调过。但单靠这一题不够，最好追问：

“你实际项目用的哪种？为什么？”

“块大小怎么定的？试过哪些值？”

“怎么判断切分好不好？”

“父子块用过吗？解决什么问题？”

“表格、代码、多模态文档怎么切？”

8、怎么回答才是最好的

回答原则

先给判断框架：不要一上来列四种策略，先说“选哪种取决于文档结构和检索任务”。

每种策略讲清场景 + 代价：适合什么、不适合什么。

主动提评估：这是加分核心。

结合真实项目：说“我们当时用 XX，因为 XX，后来发现 XX”。

提进阶手段：父子块、元数据、标题路径、去重。

推荐回答结构

“Chunking 没有最优解，主要看文档结构和检索任务。我一般分四类来说……”

“固定长度适合格式乱的文档，做 baseline；滑动窗口是它的升级，缓解切断，但索引会膨胀……”

“语义切分适合段落语义完整的文档，效果好但成本高；标题层级适合技术文档，能保留层级路径，还支持父子块……”

“我们项目里用的是标题层级 + 父子块，因为文档是 API 手册，结构清晰。小块检索，命中后返回父块生成……”

“评估上，我们主要看三块：检索的 Recall@K 和 MRR，生成的 Faithfulness，还有人工抽查块完整性……”

“另外我们会看块长分布和检索冗余率，避免块太碎或重复太多……”

“如果重来，我会先做固定长度 baseline，再用评估数据决定要不要上语义切分。”

加分点

提到 父子块、元数据、标题路径、RRF、Recall@K、Faithfulness、Context Precision/Recall。

提到 块长分布、冗余率、人工抽查、A/B 测试。

提到 表格/代码/多模态文档怎么切。

主动说 踩过的坑，比如“切太碎导致召回准但生成缺上下文”。

减分点

只列四种策略，不说场景和代价。

不提评估，或只说“看效果”。

说“我们用 LangChain 默认切分”，显得没调过。

把 Chunking 当成纯预处理，不联系检索和生成。

---

---