企业官网建设流程全解析

在搭建RAG（检索增强生成）应用时，文档分块是决定检索效果的第一道关卡。很多团队花大量时间调提示词、换嵌入模型，却忽略了分块方式对召回率和生成质量的深远影响。这篇文章我用自己的项目经验，把RAG文档分块的主流方式、参数设置、实操流程和坑点都梳理一遍，希望能帮你少走弯路。

先说结论：没有“最好”的分块方式，只有“最匹配你的文档形态和检索场景”的分块方式。固定长度、递归字符、语义边界、结构化感知，各自都有自己的适用条件。下面我会逐个拆解，并告诉你为什么在某个场景下选A不选B，以及实操中这些方案到底怎么跑通。

1. 为什么分块是RAG的第一道关卡

1.1 分块在RAG链路中的定位

RAG的完整链路通常是：原始文档 → 分块 → 向量化 → 存储 → 召回 → 重排 → 拼接上下文 → 生成答案。很多人在这个链路里只关注“向量化”和“召回”两个环节，觉得嵌入模型选得好、向量库性能高，检索结果自然就准。但实际上，分块是整条链路最上游的决策，上游一旦出错，下游再优化也是事倍功半。

我打个比方：分块相当于给一本书做索引目录。如果目录把章节标题和正文对不上，把两个不同主题的内容硬塞进同一条目，那读者按目录翻书，要么翻到无关内容，要么漏掉关键段落。RAG也是同理，用户的问题是一个“查找意图”，向量检索在块集合里做相似度匹配，块定义得越接近“一个完整语义单元”，命中的准确率就越高。

在我的实际项目中，曾经对同一套产品文档做过实验：用固定512字符分块时，问答准确率大约在62%左右；后来改成基于标题层级的结构化递归分块，同样的检索算法、同样的生成模型，准确率提升到81%。这个差距不是靠换嵌入模型能补回来的，因为问题就出在“原料被切坏了”。

所以分块的第一原则是：让每个块尽量承载一个可以独立理解的信息单元。这个单元可以是完整的一段论述、一个操作步骤、一个FAQ条目、一个功能模块的说明，而不是简单按字符数硬切。

1.2 分块效果直接决定检索上限

在信息检索领域有一个经典观点：“索引决定了召回的上限，排序算法只是在这个上限内做筛选”。分块就是这个“索引”的具体形态。如果你的某个知识条目被腰斩，那无论嵌入模型多强，用户提问时都不太可能通过余弦相似度把“半个条目”召回并正确生成答案。

另外，分块还直接影响生成阶段的上下文质量。大模型在回答时会依赖系统提示词中拼接的检索片段，如果片段里混杂了过多无关内容或者缺少关键信息，模型很容易被带偏，出现“答非所问”“编造细节”“只答一半”等情况。这些现象表面上看起来是模型问题，追根溯源往往是分块给的上下文不干净。

我自己的经验是：在排查RAG效果差的问题时，不要急着换模型，先手动打印几个用户问题召回出来的块，亲眼看看“切出来的东西像不像人能读懂的段落”。这一步虽然笨，但能快速暴露分块策略的毛病，比如语义断裂、标题与正文分离、块内信息冗余等等。

2. 主流分块方式的原理、参数与适用场景

2.1 固定长度分块：最朴素，但别小看它

固定长度分块是入门最简单的方式：设定一个固定长度（比如256个字符或512个token），从文档开头依次切分，最后不足一个块长的部分单独成块。听起来很原始，但它依然是很多生产系统的兜底方案。

这种方式的优点是非常明显的：速度快、可解释性强、实现成本几乎为零，几行代码就能跑通。适合那些内容结构比较松散、没有明显章法的大规模语料，比如日志、聊天记录、社交媒体文本。这些内容本身没有清晰的段落边界，你也没必要花大力气做精细化分块。

但固定长度分块的缺点也同样突出。首当其冲的是语义断裂：一个完整的技术方案可能被硬切成两半，前半段讲原理，后半段讲实现，检索时用户问题匹配到其中一半，答案自然不完整。其次，它完全忽视文档的结构信息，代码块、表格、列表可能被拦腰截断，导致很多字符在嵌入时失去上下文含义。

固定长度分块的参数主要有两个：块大小（chunk_size）和步长（step）。块大小决定单块的信息容量，步长决定切分密度。在实际操作中，如果你要采用这种方式，我建议优先按token数而非字符数切分，因为嵌入模型一般都以token为输入单位，按token切分可以更精确地控制向量化时的上下文窗口用量。

使用固定长度分块时，我有几个习惯性的操作：一是尽量配合一定比例的重叠（overlap），比如块大小取512 token时，相邻块之间重叠80~100 token，这样能缓解切断语义带来的负面影响；二是针对中文场景，避免直接在半个词、半个实体处硬切，最好先做一个粗粒度的预切分，保证每个块至少从一个完整句子起始。

2.2 递归字符分块：兼顾结构与文本的默认答案

如果你不愿意自己做太多决策，又想比固定长度分块更科学一点，递归字符分块是目前最稳妥的“默认答案”。它的核心逻辑是：维护一个分隔符优先级列表，比如先按段落标记（\n\n）切，如果切出来的块还是太大，再按换行符（\n）切，再按句号、空格等继续递归细化，直到所有块都小于设定的块大小上限。

这种方式的好处在于它天然尊重文本中存在的结构线索。以一篇文章为例，它会优先保留段落的完整性，只有段落本身过长时才退而求其次按句子边界切分。相比固定长度分块，递归分块切出来的块通常在语义上更连贯，也更像人手工划分的段落。

在参数选择上，递归分块主要关注块大小（chunk_size）、块重叠长度（chunk_overlap）以及分隔符列表。块大小的初始值需要根据你的文本平均段落长度和嵌入模型的最大输入长度来定。我通常的做法是：先统计语料里平均段落字符数，把chunk_size设为略大于这个值，保证大部分段落能被完整保留；overlap则设为chunk_size的1/8到1/4之间，目的是让相邻块之间共享交界处的上下文信息，避免重要内容恰好落在切分边界上。

递归分块很擅长处理Markdown文档、技术博客、产品说明书这类带有自然段落结构的长文本。我曾在某个知识库项目里，用LangChain的RecursiveCharacterTextSplitter按1000字符块大小、200字符重叠来处理一批Markdown技术文档，检索命中率比固定长度切分提升了约10个百分点。代价是切分时间会稍微长一点，但对于离线索引的文档量级，这个成本完全可接受。

不过递归分块也有它的盲区。它对段落标记明确的文本很有效，但对没有换行、没有标题的纯文本比如PDF扫描件，递归起来也容易切得不够聪明。此外，如果文档本身结构混乱，分隔符优先级再合理也救不回来，所以使用前最好先做一轮文本清洗。

2.3 语义分块：让模型自己找边界

前面几种方式本质上都在用“字符/结构规则”找切分点，而语义分块换了一个思路：用嵌入模型的相似度来判断哪些句子适合放在同一个块里。

具体做法是：先把文本按句子拆开，逐句计算向量，然后比较相邻两个句子之间的语义相似度。如果相似度较高，说明它们属于同一个话题，可以继续拼接；如果相似度出现明显下降，就认为这里存在一个语义边界，应该另起一块。

语义分块的最大价值在于它能识别出那些“形式不同但内容相关”的内容。比如一篇文章里，前一段在讲“安装步骤”，后一段在讲“环境变量配置”，表面看都是操作指南，但语义上属于两个话题。固定长度分块会把它们拼在一起，递归分块也可能因为段落标记不明显而无法切分，语义分块则可以比较可靠地识别出话题切换的边界。

代价也很直接：计算成本高，处理耗时明显高于前两种方式。因为你需要对每个句子都做一次嵌入计算，对于超大规模语料，这个开销可能非常可观。另外，语义相似度阈值需要调试，阈值设置过高会把句子切得过于零碎，阈值设置过低则分块不彻底，依旧残留大量无关内容混在一起。

我的使用建议是：语义分块适合内容主题切换频繁、文档结构不规整的场景，比如行业研究报告、新闻资讯集合、客服对话记录。如果文档本身就是结构良好的手册，用递归分块就够了，没必要上语义分块。实际落地时，也可以采用“混合策略”：先用结构化方式切出候选块，再利用语义边界做微调，兼顾效率和质量。

2.4 结构化与文档感知分块：页面级切分的专业做法

当你的文档本身带有明确层级结构时，最聪明的分块方式就是“顺着结构走”。这包括按Markdown标题层级切分、HTML标签切分、PDF版面分析切分等方法。我会这类方式统称为文档感知分块。

以Markdown文档为例，编辑器里通常有二级标题、三级标题、正文段落、代码块、表格。按标题层级切分时，可以先把文档拆成若干个“从某级标题到下一个同级标题之前”的区块，再根据块大小限制决定是否继续将区块递归切细。这样一来，每个块都能自带标题上下文，用户在检索时也更容易根据标题判断这段内容是否相关。

我强烈建议在向量检索时把标题信息也带上。比如某个块属于“第三章 安装部署”下的“3.2 配置参数”这级标题，那么在向量化的时候，可以把“安装部署 → 配置参数”这段上下文前缀拼到块内容前面一起嵌入。这样既能增强语义向量对块主题的表达，也能在召回时提供更清晰的定位信息，尤其适合层级分明的产品帮助中心文档。

对于PDF文档，文档感知分块会更复杂一点，因为PDF的“段落”往往受排版影响，经常出现同一段落跨页、两栏混排等情况。实践中需要先做版面分析，识别标题、正文、表格、页眉页脚，再根据版面元素重建阅读顺序，最后再按标题层级切分。这样虽然麻烦，但对于论文、行业报告、扫描件这类PDF文档类型，效果要远好于前面几种方式。如果不做版面分析直接按页切块，你会在向量库里存进大量页眉页脚噪声，检索质量惨不忍睹。

2.5 分块方式对比速查表

补充一种实践中的常见变体：父子分块。父块是大粒度内容单元，比如一个完整的章节或较长的段落，子块是从父块内部切出的更小片段。向量化时只对子块建索引，召回时如果命中了某个子块，就把对应的父块整体作为上下文喂给大模型。这种设计在子块本身信息量不足、需要更多上下文时非常好用。我把它用在一个包含大量FAQ的客服知识库项目中，因为FAQ条目本身往往简短且缺少上下文背景，仅靠单个子块回答往往信息不足，带上父块之后就顺了很多。

3. 实操过程：从原始文档到高质量分块的全流程

3.1 先做数据体检：确定分块策略的依据

在我接手任何一个RAG项目时，第一件事不是写分块代码，而是先把语料从头到尾翻一遍，搞清楚三个问题：文档类型有哪些、单篇文档平均多长、内容是否具备清晰的标题层级。

比如有一批文档是运营团队整理的Word售后手册，打开一看，每篇三四千字，有层级标题但格式不统一，有的用“一、二、三”，有的用“1.1 1.2”。这种情况下就不能直接用Markdown感知分块，得先把标题格式规范一下。再比如另一批文档是从旧系统导出的纯文本工单记录，一段一段没有标题，这类数据最适合用固定长度加重叠，或者语义分块来切。

数据体检阶段不需要做太复杂的统计，我通常会写一个脚本输出以下指标：文档总数、平均字符数、平均段落数、段落平均长度、标题数量、代码块和表格数量。这些指标能帮我快速判断用什么分块策略，也能作为后期调参的基准。

这里特别提醒一点：检查语料里有没有大量重复文本、模板文本、签名档、免责声明。这些内容在分块后会被重复向量化，查询时容易被这些噪声分散检索概率。遇到这种情况，我会在清洗阶段直接把这些固定模板删除，或者在分块结果里做一次去重操作，把重复度过高的候选块标记出来。

3.2 参数设计与计算：chunk_size和overlap怎么定

分块参数看起来只有两个，但在这两个参数背后要考虑的因素不少。很多人直接把chunk_size设成500、overlap设成50，最后效果不好也不知道怎么调。

chunk_size的设定逻辑主要取决于三件事：内容的语义单元大小、嵌入模型的最大输入长度、以及下游大模型的上下文窗口。

先看语义单元大小：如果你的文档段落很少，一个段落就有上千字，那chunk_size设成500会把每个段落实质上切成两半；如果文档段落很短，一个段才几十字，chunk_size设成500又会把好几个不相干的话题混在一起。所以正确做法是先统计语料的平均段落长度，然后让chunk_size略大于这个值，给段落留一点余量。

再看嵌入模型的最大输入长度：很多常见的嵌入模型只支持512 token左右的输入。如果chunk_size超过模型最大输入，超出的部分要么被截断，要么被忽略，白白浪费信息。所以在设定参数前，一定要查清楚你使用的嵌入模型的上下文上限。

最后看下游大模型的窗口：如果你最终要把检索回来的块拼进提示词里，那上下文窗口不能无限塞块。比如你的模型上下文是8K token，你打算拼2K的提示词和指令，那检索块总预算大约是6K token，再除以你想召回4到6个块，每个块的可接受长度就有限了。这个计算流程会让你的chunk_size选择更有依据。

overlap的设计逻辑就更简单了——它是在为“切分点恰好落在关键信息上”这一风险买保险。overlap太小起不到衔接作用，overlap太大又会造成块与块之间大量重复，检索时多个块命中同一信息，既浪费向量库空间，又容易造成上下文重复。我经验上取值在chunk_size的10%到25%比较稳。比如chunk_size是1000 token，I会把overlap设为100到250 token之间。如果语料里句子普遍偏长、切分点更容易落在句子中间，我会把overlap适当调大一些。

3.3 嵌入模型与分块大小的匹配

嵌入模型的选择和分块大小之间是互相约束的关系，这里有一个经常被忽视的细节：嵌入模型在训练时，对不同长度的文本表示能力并不一致。有些模型在短文本上表现很好，长文本上反而会丢失焦点；有些模型对长文本的语义聚合能力更强。

实际操作时，我会先确定自己倾向的分块规模，再选择合适的嵌入模型。比如我的某个知识库项目，文档段落平均长度约600字，对应的token数大约是300到400，所以我使用chunk_size为800字符的递归分块，然后选择支持较长输入的嵌入模型，这样每个块在嵌入时不会触发截断。如果反过来，你想用某个只支持512 token的模型，就得把chunk_size严格控制在模型输入范围内。

还有一个技巧：块内容里的噪声对嵌入质量的影响比想象中大。如果某个块里混进了各种与主旨无关的内容，比如大量的超链接文本、页脚版权声明、随机时间戳，嵌入向量的主方向会被带跑偏，检索时会经常返回莫名其妙的块。所以分块前做内容清洗，去掉与正文无关的噪声元素，是性价比极高的投资。我在处理网页抓取数据时就深有体会：未清洗的块检索准确率只有不到50%，把导航、页脚、广告区过滤掉之后，准确率直接翻倍。

3.4 检索质量评估：用真实问题验证分块效果

分块方案好不好，不能靠感觉，要靠测试。我一般会组建一个几十条问答的评测集，这些问题来源于真实用户高频提问，每条问题都标注了期望命中的文档范围。然后跑一遍完整的RAG流程，统计召回命中率、答案准确度和上下文利用率三个指标。

召回命中率最简单：对于每个测试问题，看Top5召回结果里有没有包含“期望命中的内容块”。答案准确度可以用人工打分或让模型评分。上下文利用率更偏工程化：观察最终拼进提示词的块中，有多大比例的内容是真正和问题相关的，如果大量块内容都在“凑数”，说明分块粒度或重叠设置有问题。

评测集不需要太大，但要有代表性。我通常会把测试问题按类型分好：事实查询型、步骤操作型、对比归纳型、异常处理型。不同类型的问题对分块形态的敏感度不一样：事实查询型问题需要块内信息集中，步骤操作型问题需要块内包含完整流程，对比归纳型问题则更依赖多个块之间的信息协同。

做完一轮评测后，我会记录当前分块参数下的各项指标，然后修改chunk_size或切换分块策略，再跑一轮对照。反复迭代三次左右，基本能定位出一组比较稳的参数。这种迭代方法虽然朴素，却是确保分块方案持续有效的核心手段。

4. 常见问题与排查技巧实录

4.1 分块切断了重要的语义单元

这个问题在固定长度分块里最常见。比如一段话在讲某个功能的使用限制和注意事项，前半段是“必须注意”，后半段是“否则会导致错误”，中间恰好被一刀切开。用户问“这个功能有什么风险”，检索出来的块只有前半段，生成答案时就缺了最关键的后果说明。

排查方法是去向量库里随机抽查几个块的边界，看边界处是否存在语义断裂。如果频繁出现“上一块结尾和下一块开头拼起来才是一个完整意思”的情况，就说明切分粒度或者切分规则不对。解决办法有三个方向：改用递归分块并增大chunk_size、增大重叠比例、或者引入语义分块，确保切分点落在语义边界上。

4.2 检索命中了块，但上下文仍然不够

这是我被问得最多的问题之一。用户的反馈是：系统确实搜到了相关内容，但生成答案总是干巴巴的，缺少背景和细节。查了一下召回日志，发现命中的块内容本身太短，只包含一个小片段，无法支撑完整回答。

这种情况在短段落语料、FAQ条目和父子分块的子块场景下尤其常见。解决方案就是我在前文提到的父子分块策略：保持小块用于检索，召回命中后把父块或相邻块一并拉回，拼进提示词。另一个思路是提高recall阶段返回的候选块数量，比如从Top3改成Top5，再靠重排环节把最相关的挑出来。实践证明，这个调整对答案质量提升非常明显。

4.3 中文分块的边界处理难点

中文和英文的天然差别导致分块难度不在一个量级。英文有空格天然分界，句子边界可以用句号、问号、感叹号识别，但中文没有空格，句子的语义边界更依赖标点符号和语义判断。固定长度硬切时，很容易把一个完整词汇切得七零八落，比如把“机器学习”切成“机器”和“学习”。

我处理中文语料时的做法是：在做任何切分之前，先做一次粗粒度的句子切分，以句号、问号、感叹号、分号作为边界标记。然后在这些“完整句子”基础上再执行后续的递归分块或语义分块。这样即使后续按长度合并句子，也不会出现半句话的情况。另外一个细节是中文标点有全角半角之分，清洗阶段要把全角标点统一，否则正则切分容易漏边。

还有一个容易忽略的坑：中文里引号、书名号经常跨越多句，如果切分点落在引号中间，会把整段引用内容拆开，检索时也容易误导匹配。所以在做分块时，我建议对引号内容做一次完整检测，尽量让引号内的内容保持在同一块里。

4.4 表格、代码与图文混排内容的处理

表格和代码块是分块中最容易出问题的两类内容。表格如果直接按字符切，结果就是一堆没有表头的数字碎片，用户问“第三季度的营收是多少”时，检索出来的内容完全不可读。代码块如果被拦腰切开，生成的解释也可能基于不完整的代码逻辑，误导性很强。

对于表格，我的建议是不要把表格里的每行单独切成一个块。更好的做法是：把表头连同表格内容一起转换成一个结构化的文本描述，比如“表1：季度营收明细，列包括第一季度、第二季度、第三季度、第四季度，第一行数据为...”。这样一来，嵌入模型能更好地理解表格语义，检索效果也会好很多。

对于代码块，我通常把它们作为一个不可分割的整体保留，除非代码块特别长，才考虑按函数或类定义切开。判定标准很简单：切开之后每一段是否还能独立说明一个问题。如果切出来的代码片段没有上下文就毫无意义，那就该整体保留。

4.5 分块后的去重与噪声问题

分块之后，向量库里往往有大量内容高度相似的块，来源可能是重复文本、相似模板、版本更新遗留的旧文案。这些问题会导致检索时返回大量冗余结果，挤占上下文窗口，甚至让大模型在信息之间摇摆。

我的处理方案是引入一个去重环节：对所有块做一次MinHash或SimHash计算，把相似度超过阈值的块归并，只保留其中一个。另一种更轻量的方式是，在向量检索阶段对召回的块按来源文档和位置做聚簇，同一聚簇只取一个代表块参与重排。这个策略在大型知识库项目里对上下文利用率的提升相当明显，值得尝试。

4.6 常见问题速查表

按着这张表排查，大部分分块相关的问题都能找到明确的方向。最后还是那句话：分块方式没有银弹，数据形态和场景需求才是决定因素。我的个人体会是，分块这事最少预留一周时间来做方案验证和迭代，前期多花点心思在切分策略上，后面调模型和调提示词的时间都会省下来。如果你现在正在做RAG项目，不妨先把分块代码停下来，去认真看一下自己手头的文档到底长什么样，再决定怎么切。这个习惯，能让你的RAG应用少踩很多坑。