系列100 天系统学习 AI Agent 开发当前阶段RAG、知识库与工具边界今日目标切分大小、重叠长度、标题保留和层级结构都会影响 RAG 的召回质量。有时不是没搜到而是答案被切成了两半一份部署文档里“执行命令”在上一段“环境变量说明”在下一段。如果按固定字数正好从中间切开检索可能只拿到命令却漏掉执行前提。片段再相似也无法补回被边界割断的关系。Chunking 看起来像预处理细节实际上决定检索系统最小能找到什么。块太小语义不完整块太大相关句子被大量噪声包围还会挤占上下文。没有一个适合所有资料的神奇数字。四个互相牵制的变量变量太小/缺失的后果太大/过多的后果chunk 大小语义断裂、缺上下文噪声多、定位不准、成本高overlap跨边界信息丢失重复召回、索引膨胀标题路径代词和短段失去主题每块重复过多导航文字结构层级表格、代码、步骤被拆散整章作为一块难以命中细节Overlap 不是越大越稳。相邻三块都包含同一段话时Top 3 看似命中了三条实际只有一份信息模型得到的证据多样性反而下降。三种策略必须控制变量比较今天的练习是把同一篇技术文档做三份索引固定约 300 字保留少量重叠固定约 800 字保留少量重叠按标题和语义结构切分代码块与紧邻解释尽量不分开。为了让比较有意义Embedding 模型、查询集、Top K、metadata 过滤和生成 Prompt 都应保持一致。否则结果变化不能归因于切分。查询期望证据300 字800 字标题层级观察项安装前置依赖是什么“环境准备”列表待运行待运行待运行是否完整命中列表超时后能否重试错误策略 幂等说明待运行待运行待运行关系是否跨块某函数参数含义参数表对应行待运行待运行待运行表格有没有被破坏这里没有伪造优胜策略。我的预期是结构化切分通常更自然但遇到标题很差、正文结构混乱的文档它也可能不如固定窗口稳定。一个保守的标题切分草案fromdataclassesimportdataclassdataclassclassChunk:chunk_id:strheading_path:list[str]text:strsource:strdefenrich_text(chunk:Chunk)-str:heading .join(chunk.heading_path)returnf标题路径{heading}\n正文{chunk.text.strip()}这段代码只演示“标题路径与正文一起进入检索文本”。真正的解析器还要处理 Markdown 表格、围栏代码、列表、图片说明和超长章节。尤其不应在代码块中间按字符硬切那会留下无法理解、也无法运行的残片。如果不得不用固定窗口也应先按句子或段落寻找安全边界优先边界标题 段落 句子 字符兜底 禁止边界代码围栏内部、表格行中间、步骤标题与其内容之间常见失败模式只看平均块长。平均 500 字可能掩盖少数 5000 字的超长块。用同一策略处理所有格式。FAQ、API 参考、叙述文章、表格需要不同规则。只评最终回答。模型可能用常识碰巧答对掩盖切分没命中。chunk_id 不稳定。每次重建都随机编号历史评测和引用无法对齐。先切再丢标题。“它支持三种方式”被检索出来却不知道“它”指什么。我现在的取舍切分不是越精细越专业而是要让一个片段足够独立地支持一条结论同时还能准确被问题召回。这个尺度只能用自己的文档和问题集校准。下一篇做 metadata 后还能把版本、权限和主题作为硬条件减少仅靠语义相似承担的压力。面试官会追问Chunk 设成 512 还是 1024这不是常数题。Chunk 应围绕“一个检索结果能否独立支撑答案”设计。FAQ 可以一问一答一块API 文档要保留标题、参数表与示例合同则不能把定义和适用条款切开。我会做一个小实验固定 30 个问题分别测试固定长度、按标题层级、语义切分三种方案记录 Recall5、平均 chunk 长度、上下文 Token 与引用完整率。若召回正确但引用缺前提说明切得太碎若每次都召回整页却答案漂移说明切得太粗。加分点不是报出一个“最佳长度”而是讲清楚标题继承、父子块检索、邻块扩展和版本元数据怎样共同减少语义断裂。今日检查清单三种切分策略使用同一问题集和检索参数标题、代码、表格和列表没有被无意义切断同时记录命中、证据完整度和重复召回chunk_id 可稳定追溯到源文档位置结论写成“本数据集上的观察”不包装成通用定律
Day 013｜Chunking 策略：为什么知识库效果差，锅经常在切分
系列100 天系统学习 AI Agent 开发当前阶段RAG、知识库与工具边界今日目标切分大小、重叠长度、标题保留和层级结构都会影响 RAG 的召回质量。有时不是没搜到而是答案被切成了两半一份部署文档里“执行命令”在上一段“环境变量说明”在下一段。如果按固定字数正好从中间切开检索可能只拿到命令却漏掉执行前提。片段再相似也无法补回被边界割断的关系。Chunking 看起来像预处理细节实际上决定检索系统最小能找到什么。块太小语义不完整块太大相关句子被大量噪声包围还会挤占上下文。没有一个适合所有资料的神奇数字。四个互相牵制的变量变量太小/缺失的后果太大/过多的后果chunk 大小语义断裂、缺上下文噪声多、定位不准、成本高overlap跨边界信息丢失重复召回、索引膨胀标题路径代词和短段失去主题每块重复过多导航文字结构层级表格、代码、步骤被拆散整章作为一块难以命中细节Overlap 不是越大越稳。相邻三块都包含同一段话时Top 3 看似命中了三条实际只有一份信息模型得到的证据多样性反而下降。三种策略必须控制变量比较今天的练习是把同一篇技术文档做三份索引固定约 300 字保留少量重叠固定约 800 字保留少量重叠按标题和语义结构切分代码块与紧邻解释尽量不分开。为了让比较有意义Embedding 模型、查询集、Top K、metadata 过滤和生成 Prompt 都应保持一致。否则结果变化不能归因于切分。查询期望证据300 字800 字标题层级观察项安装前置依赖是什么“环境准备”列表待运行待运行待运行是否完整命中列表超时后能否重试错误策略 幂等说明待运行待运行待运行关系是否跨块某函数参数含义参数表对应行待运行待运行待运行表格有没有被破坏这里没有伪造优胜策略。我的预期是结构化切分通常更自然但遇到标题很差、正文结构混乱的文档它也可能不如固定窗口稳定。一个保守的标题切分草案fromdataclassesimportdataclassdataclassclassChunk:chunk_id:strheading_path:list[str]text:strsource:strdefenrich_text(chunk:Chunk)-str:heading .join(chunk.heading_path)returnf标题路径{heading}\n正文{chunk.text.strip()}这段代码只演示“标题路径与正文一起进入检索文本”。真正的解析器还要处理 Markdown 表格、围栏代码、列表、图片说明和超长章节。尤其不应在代码块中间按字符硬切那会留下无法理解、也无法运行的残片。如果不得不用固定窗口也应先按句子或段落寻找安全边界优先边界标题 段落 句子 字符兜底 禁止边界代码围栏内部、表格行中间、步骤标题与其内容之间常见失败模式只看平均块长。平均 500 字可能掩盖少数 5000 字的超长块。用同一策略处理所有格式。FAQ、API 参考、叙述文章、表格需要不同规则。只评最终回答。模型可能用常识碰巧答对掩盖切分没命中。chunk_id 不稳定。每次重建都随机编号历史评测和引用无法对齐。先切再丢标题。“它支持三种方式”被检索出来却不知道“它”指什么。我现在的取舍切分不是越精细越专业而是要让一个片段足够独立地支持一条结论同时还能准确被问题召回。这个尺度只能用自己的文档和问题集校准。下一篇做 metadata 后还能把版本、权限和主题作为硬条件减少仅靠语义相似承担的压力。面试官会追问Chunk 设成 512 还是 1024这不是常数题。Chunk 应围绕“一个检索结果能否独立支撑答案”设计。FAQ 可以一问一答一块API 文档要保留标题、参数表与示例合同则不能把定义和适用条款切开。我会做一个小实验固定 30 个问题分别测试固定长度、按标题层级、语义切分三种方案记录 Recall5、平均 chunk 长度、上下文 Token 与引用完整率。若召回正确但引用缺前提说明切得太碎若每次都召回整页却答案漂移说明切得太粗。加分点不是报出一个“最佳长度”而是讲清楚标题继承、父子块检索、邻块扩展和版本元数据怎样共同减少语义断裂。今日检查清单三种切分策略使用同一问题集和检索参数标题、代码、表格和列表没有被无意义切断同时记录命中、证据完整度和重复召回chunk_id 可稳定追溯到源文档位置结论写成“本数据集上的观察”不包装成通用定律
