接下来我们聊一个核心环节现在来弄懂文本分块Chunking。在搞懂向量数据库的运行逻辑后我们会遇到一个新难题。前面我们只用过简短句子举例比如「每周五办公室允许携带宠物犬」。但如果面对真实的制度文件该怎么办假设我们有一份 50 页的员工手册需要存入向量数据库该如何处理我们结合实际场景分析这份手册共 50 页每页包含多个板块各项规章制度附带大量详细说明。如果把整份文档作为单一条目存入 Chroma 向量数据库会发生什么从技术层面来说可以运行Chroma 会为整篇文档生成一个向量嵌入Embedding。但当用户提问「远程办公相关规定是什么」时系统会直接返回完整 50 页手册实用性极差。这就是我所说的检索精度问题。不做文本分块的情况下用户查询远程办公规则却拿到整本手册被大量无关信息淹没只能自己通篇翻阅筛选有效内容。 而分块技术可以把手册切分成多个短小、主题明确的片段。此时用户询问远程办公政策系统只会返回匹配度高的对应章节直接给到精准、简洁的答案。如何对文档执行分块分块有多种实现方案这里先介绍几种最基础的方式1. 固定长度分块设定每块固定 500 字符该方法简单稳定适配绝大多数场景。将文档均匀切分成长度一致的片段理解和开发成本都很低。 但这种方式存在明显缺陷很可能刚好在一句话中间截断。 举个例子一句话「周五办公室允许携带狗狗」切分后前一块只剩「办公室允许携带狗狗」后一块只剩「周五」。语义被割裂模型无法完整理解原文信息。这时就需要引入重叠分块Overlap相邻分块之间预留 50 字符的重叠内容前一块末尾和后一块开头存在重复文本。即便句子被截断关键上下文也会同时保存在两个分块中避免语义丢失。2. 其他基础分块方案基于句子分块以单个句子为单位每一句单独作为一个分块基于段落分块以完整段落为单位一段对应一个分块。分块的核心难点把握尺寸平衡分块看似简单实际落地难度很高关键在于把控分块大小分块过小 → 上下文缺失就像前面的例子一句话被拆成两段信息碎片化、内容残缺模型无法完整理解语义检索效果大打折扣。分块过大 → 检索精度不足如果把一整套完整制度全部塞进同一个分块就回到了最初的问题检索结果冗余大量无关内容查询效率低用户接收信息过载。因此必须根据业务需求选择适配的分块策略。 除了固定长度、句子、段落分块外还有语义分块Semantic Chunking、智能代理分块Agentic Chunking等进阶方案本节课暂不展开讲解。文本分块Chunking完整梳理 通俗总结一、为什么必须做 Chunking向量库的核心痛点向量数据库的底层逻辑输入文本→生成向量 Embedding→用户提问转向量→相似度匹配召回原文不做分块整份 50 页员工手册作为单条入库技术可行但检索灾难查「远程办公规则」会返回整本手册无关信息占绝大多数检索精度极低大模型筛选成本极高。做分块文档切割为独立、主题聚焦的小段向量匹配只召回高度相关片段信息精简RAG 问答时上下文干净、答案精准。二、基础分块方案详解1. 固定长度分块最常用逻辑设定固定字符阈值如 500 字符均匀切割文本优点实现简单、运行稳定、通用适配所有文档开发成本低致命缺陷极易在句子、语义中间截断割裂完整语义 例原句「周五办公室允许携带狗狗」被切分一块只剩后半句、一块只剩时间词语义残缺。配套优化重叠分块Sliding Window / Overlap相邻分块预留重叠文本如 50 字符前后片段重复一部分上下文。 作用就算长句被切割完整语义同时保存在两块检索时任意一块被召回都能补全信息解决断句丢失问题。2. 按句子分块以句号、问号、感叹号分句单句为一块。适用短句多、问答类短文缺点单块信息太少上下文缺失长段落检索效果差。3. 按段落分块以换行 / 分段符切割一整个段落作为单块。适用段落主题独立、篇幅适中的文档缺点长篇大段会变回 “块过大”检索冗余。三、Chunk 大小的平衡核心落地关键两个极端都会摧毁 RAG 效果分块太小 上下文断裂、信息碎片化单块不足以支撑完整语义向量相似度匹配失真检索漏信息。分块太大 单块混杂多个无关主题查询时带入大量无关内容检索精度下降大模型容易被冗余文本干扰。落地原则根据文档类型、模型上下文窗口、业务查询习惯匹配块长度 重叠长度。四、进阶分块拓展了解本节课未展开工业级优化方案语义分块 Semantic Chunking通过向量相似度判断语义边界语义切换处自动切割不硬切字符智能代理分块 Agentic Chunking调用大模型理解文档结构按章节、条款、逻辑单元智能拆分。五、极简一句话总结Chunking 是 RAG 的前置预处理步骤把长文档拆成语义完整、长度适中的片段存入向量库核心目标是兼顾检索精度与上下文完整性基础方案优先用「固定长度 重叠窗口」平衡开发成本与效果。下面为你分享实现优质文本分块的几条核心准则一、分块尺寸参考单块文本长度控制在 200–500 字符能在上下文完整性与检索精准度之间取得良好平衡相邻分块之间预留 50–100 字符的重叠内容以此保障段落语义连贯。 实际数值需要根据你的文本内容灵活调整技术文档与通用政策类文稿适配的分块尺寸往往存在明显差异。二、分割边界规范优先以完整句子为分割节点保证语法完整禁止在单词中间截断完整保留词汇尽量不拆分完整段落维持原文逻辑结构。三、落地验证与调优最后必须结合真实业务检索问句做测试验证分割后的文本块确实能够支撑问题作答确认重叠区间能够完整留存上下文语义持续观察检索返回结果按需微调分块长度。请记住文本分块的本质是在上下文完整度与检索精准度之间找到最优平衡点。 它不只是简单把长文档切分成碎片而是要以贴合用户查询逻辑的方式完成文本拆分。
文本分块（Chunking）完整梳理 + 通俗总结
接下来我们聊一个核心环节现在来弄懂文本分块Chunking。在搞懂向量数据库的运行逻辑后我们会遇到一个新难题。前面我们只用过简短句子举例比如「每周五办公室允许携带宠物犬」。但如果面对真实的制度文件该怎么办假设我们有一份 50 页的员工手册需要存入向量数据库该如何处理我们结合实际场景分析这份手册共 50 页每页包含多个板块各项规章制度附带大量详细说明。如果把整份文档作为单一条目存入 Chroma 向量数据库会发生什么从技术层面来说可以运行Chroma 会为整篇文档生成一个向量嵌入Embedding。但当用户提问「远程办公相关规定是什么」时系统会直接返回完整 50 页手册实用性极差。这就是我所说的检索精度问题。不做文本分块的情况下用户查询远程办公规则却拿到整本手册被大量无关信息淹没只能自己通篇翻阅筛选有效内容。 而分块技术可以把手册切分成多个短小、主题明确的片段。此时用户询问远程办公政策系统只会返回匹配度高的对应章节直接给到精准、简洁的答案。如何对文档执行分块分块有多种实现方案这里先介绍几种最基础的方式1. 固定长度分块设定每块固定 500 字符该方法简单稳定适配绝大多数场景。将文档均匀切分成长度一致的片段理解和开发成本都很低。 但这种方式存在明显缺陷很可能刚好在一句话中间截断。 举个例子一句话「周五办公室允许携带狗狗」切分后前一块只剩「办公室允许携带狗狗」后一块只剩「周五」。语义被割裂模型无法完整理解原文信息。这时就需要引入重叠分块Overlap相邻分块之间预留 50 字符的重叠内容前一块末尾和后一块开头存在重复文本。即便句子被截断关键上下文也会同时保存在两个分块中避免语义丢失。2. 其他基础分块方案基于句子分块以单个句子为单位每一句单独作为一个分块基于段落分块以完整段落为单位一段对应一个分块。分块的核心难点把握尺寸平衡分块看似简单实际落地难度很高关键在于把控分块大小分块过小 → 上下文缺失就像前面的例子一句话被拆成两段信息碎片化、内容残缺模型无法完整理解语义检索效果大打折扣。分块过大 → 检索精度不足如果把一整套完整制度全部塞进同一个分块就回到了最初的问题检索结果冗余大量无关内容查询效率低用户接收信息过载。因此必须根据业务需求选择适配的分块策略。 除了固定长度、句子、段落分块外还有语义分块Semantic Chunking、智能代理分块Agentic Chunking等进阶方案本节课暂不展开讲解。文本分块Chunking完整梳理 通俗总结一、为什么必须做 Chunking向量库的核心痛点向量数据库的底层逻辑输入文本→生成向量 Embedding→用户提问转向量→相似度匹配召回原文不做分块整份 50 页员工手册作为单条入库技术可行但检索灾难查「远程办公规则」会返回整本手册无关信息占绝大多数检索精度极低大模型筛选成本极高。做分块文档切割为独立、主题聚焦的小段向量匹配只召回高度相关片段信息精简RAG 问答时上下文干净、答案精准。二、基础分块方案详解1. 固定长度分块最常用逻辑设定固定字符阈值如 500 字符均匀切割文本优点实现简单、运行稳定、通用适配所有文档开发成本低致命缺陷极易在句子、语义中间截断割裂完整语义 例原句「周五办公室允许携带狗狗」被切分一块只剩后半句、一块只剩时间词语义残缺。配套优化重叠分块Sliding Window / Overlap相邻分块预留重叠文本如 50 字符前后片段重复一部分上下文。 作用就算长句被切割完整语义同时保存在两块检索时任意一块被召回都能补全信息解决断句丢失问题。2. 按句子分块以句号、问号、感叹号分句单句为一块。适用短句多、问答类短文缺点单块信息太少上下文缺失长段落检索效果差。3. 按段落分块以换行 / 分段符切割一整个段落作为单块。适用段落主题独立、篇幅适中的文档缺点长篇大段会变回 “块过大”检索冗余。三、Chunk 大小的平衡核心落地关键两个极端都会摧毁 RAG 效果分块太小 上下文断裂、信息碎片化单块不足以支撑完整语义向量相似度匹配失真检索漏信息。分块太大 单块混杂多个无关主题查询时带入大量无关内容检索精度下降大模型容易被冗余文本干扰。落地原则根据文档类型、模型上下文窗口、业务查询习惯匹配块长度 重叠长度。四、进阶分块拓展了解本节课未展开工业级优化方案语义分块 Semantic Chunking通过向量相似度判断语义边界语义切换处自动切割不硬切字符智能代理分块 Agentic Chunking调用大模型理解文档结构按章节、条款、逻辑单元智能拆分。五、极简一句话总结Chunking 是 RAG 的前置预处理步骤把长文档拆成语义完整、长度适中的片段存入向量库核心目标是兼顾检索精度与上下文完整性基础方案优先用「固定长度 重叠窗口」平衡开发成本与效果。下面为你分享实现优质文本分块的几条核心准则一、分块尺寸参考单块文本长度控制在 200–500 字符能在上下文完整性与检索精准度之间取得良好平衡相邻分块之间预留 50–100 字符的重叠内容以此保障段落语义连贯。 实际数值需要根据你的文本内容灵活调整技术文档与通用政策类文稿适配的分块尺寸往往存在明显差异。二、分割边界规范优先以完整句子为分割节点保证语法完整禁止在单词中间截断完整保留词汇尽量不拆分完整段落维持原文逻辑结构。三、落地验证与调优最后必须结合真实业务检索问句做测试验证分割后的文本块确实能够支撑问题作答确认重叠区间能够完整留存上下文语义持续观察检索返回结果按需微调分块长度。请记住文本分块的本质是在上下文完整度与检索精准度之间找到最优平衡点。 它不只是简单把长文档切分成碎片而是要以贴合用户查询逻辑的方式完成文本拆分。
