真实面经题目 · 原创解析

RAG 外部知识库分片过大时，如何重新切分、保留语义边界并控制召回噪声？

这题考 RAG 知识库切分的工程细节，重点是说明分片过大会稀释 embedding、挤占上下文、引入噪声，并给出递归切分、层级索引、元数据继承、召回重排和回归评测方案。

出现于 2 个公司岗位
RAG Embedding 向量数据库 大语言模型 质量工程 系统设计
01

60 秒回答模板

外部知识库分片首先要围绕检索和生成目标设计，而不是机械按固定字符数切。通常会先解析文档结构，保留标题、章节、段落、表格、代码块、FAQ、版本和权限等元数据；再按语义边界切成适合 embedding 和上下文窗口的 chunk，并设置少量 overlap 防止边界信息丢失。如果某个分片过大，不能简单截断，因为截断可能丢掉答案；也不能直接塞给模型，因为过大的 chunk 会让 embedding 表示混合多个主题，召回时相似度不准，生成时占用 token budget 并引入无关内容。更稳妥的做法是递归切分：先按标题、段落、列表、表格行组、代码函数或问答对拆；仍然过大时再按句子或滑动窗口拆，同时继承父级标题、文档来源、权限、版本和页码等元数据。索引上可以做 parent-child：用小 chunk 做向量召回，用父 chunk 或章节摘要提供上下文；也可以对超长表格、代码和制度文档做专门解析。召回后再通过 rerank、去重、多样性控制和 token budget 选择真正相关的片段。最后要用测试集验证：看 recall@K、命中答案片段率、无关召回率、上下文 token 占用、答案忠实度和 oversize chunk 的回归 badcase 是否下降。

考点 过大分片的危害
难度 真实面经题
回答目标 让候选人能把知识库分片过大回答成 RAG 检索质量、语义切分、层级索引和测试验证的完整工程问题。
02

深入解析

01

先讲清分片的目标

RAG 分片不是为了把文档切小本身，而是为了让检索能命中答案所在的最小语义单元，同时给生成模型足够上下文。一个好 chunk 应该主题相对单一、可独立理解、带有来源和权限元数据，并且大小适合 embedding、rerank 和最终 prompt 预算。

02

过大分片会同时伤害召回和生成

分片过大时，embedding 会把多个主题压到一个向量里，导致相似度被稀释；检索命中后也可能带入大量无关段落，挤占上下文窗口。模型在生成时会面对多段相互干扰的内容，更容易引用错误证据、忽略关键句或产生看似有出处但实际不忠实的答案。

03

切分要优先保留语义边界

优先使用文档结构做切分，例如标题层级、段落、列表、表格、代码块、FAQ 问答对和页面区块。切分时把父级标题、文档名、章节、页码、更新时间、权限标签和业务域继承到子 chunk。这样即使子块很短，也不会丢掉它属于哪个主题和来源。

04

过大时用递归和专用策略处理

如果章节或段落仍然超过阈值，可以递归拆到句子、自然段或滑动窗口，并用 overlap 保留跨边界信息。表格可以按表头加若干行组拆，代码可以按函数或类拆，制度文档可以按条款拆，长 FAQ 可以按问答对拆。不同内容类型用同一个固定长度规则，通常会破坏语义。

05

索引可以做小块召回大块补上下文

为避免小 chunk 缺上下文、父 chunk 又太大，可以采用 parent-child 或 hierarchical retrieval。向量库索引小 chunk，用它提高定位精度；命中后根据父子关系取相邻片段、父级摘要或章节标题补上下文。最终进入 prompt 的内容仍要经过 rerank、去重和 token budget 裁剪。

06

验证要看过大分片的具体坏处是否消失

测试不能只看切出来多少 chunk。要准备有标注答案片段的查询集，比较切分前后的 recall@K、MRR、命中答案片段率、无关片段比例、上下文 token 占用、答案引用正确率和延迟。还要按文档类型分桶看表格、代码、长章节和多版本文档，防止一个平均指标掩盖 oversize badcase。

03

易错点

  • 只说按 500 字或 1000 字切，没有结合文档结构、答案跨度、模型窗口和评测结果。
  • 分片过大时直接截断，导致关键答案、表头、单位、条件或例外条款丢失。
  • 只保留子 chunk 文本，不继承标题、来源、页码、版本、权限和业务域等元数据。
  • 认为 chunk 越小召回越准，忽略小块缺上下文、重复召回和 rerank 成本。
  • 把所有文档都用同一种切分规则，忽略表格、代码、FAQ、制度条款和长章节的差异。
  • 没有用标注查询集和 badcase 回放验证，只凭主观感觉判断新切分策略更好。
04

面试官追问

chunk size 应该怎么选？

没有固定万能值，要结合文档类型、embedding 模型、平均答案跨度、上下文窗口和延迟成本。做法是选几个候选大小和 overlap，在标注查询集上比较召回、噪声、答案质量和 token 成本。

overlap 越大越好吗？

不是。overlap 能减少边界信息丢失，但过大会增加索引体积、重复召回和上下文浪费。需要控制重复片段，并在 rerank 或去重阶段处理相邻 chunk。

表格特别大时怎么切？

通常要保留表头、主键列和单位说明，再按行组或主题列拆分；必要时生成表格摘要或建立结构化查询能力。直接把整张大表作为一个 chunk，召回和生成效果通常都不稳定。

小 chunk 会不会缺少上下文？

会，所以需要父标题、章节元数据、相邻窗口、父级摘要或 parent-child 检索来补上下文。关键是召回定位用小粒度，生成时按预算补足必要背景。

如何判断重新切分后没有引入新问题？

要跑切分前后对比和 badcase 回放，检查答案片段命中率是否提升、无关召回是否下降、重复召回是否可控、权限和版本过滤是否仍然正确，以及线上延迟和索引成本是否可接受。