我们知道，要想原生的大模型从我们需要的知识库里读取内容，那就需要将相关的内容一起发送给大模型，相当于让大模型做了识别和重新组织语言的能力。

为什么需要文档分块chunk

首先文档有可能很大，文档的内容可能超过30w字，那么扔给大模型，大模型检索的速度肯定也堪忧。
其次大模型本身也有上下文token长度的限制，基本都是128k-1M之间，过大的文本也无法进行识别。
因此以上两个问题都需要促使我们对文档进行分块处理。

分块的核心参数

chunkSize

chunkSize是每个分块的大小，比如chunkSize设置为200，那就是一个分块的大小是200个token或者200个字符，这个可以自己定义。我们就以token来定义。
chunkSize的大小定义还是比较有学问的，如果chunkSize设置小了，那一个分块都放不下几个字，切分时容易把语句给截断，如果设置大了，那这个分块就会包含很多的东西，显得无关的东西又会太多。
一般业务里设置200-1000的chunkSize就差不多了，具体得看文档类型和业务定义。

overlap

overlap指的是两个分块之间的共同内容区域的字符有多少。
举个例子，假设我们有一段文本，我们进行拆分的时候按照200个token的硬拆分，那结果就可能会将一个语句给拆分为了两段，每段都包含一定的意思，但是每段都无法完全表达。所以这时候overlap的效果就出来了，我们可以将两个语句设置一定的共同内容，这样可以一定程度上的保证语句内容的完整性。

主流分块策略

固定分块大小

顾名思义，就是设置一个通用的分块大小，然后无差别的切割，这样切割出来的内容可以保证每个块的大小都基本差不多，但是无法保证句子的完整性，具体也得根据文章定制，优点就是实现起来极其简单粗暴。

重叠分块拆分

重叠分块是对固定分块大小的优化改进，在固定分块的基础上增加了overlap的设置，可以在一定程度上保证分块后文档的完整性。

递归分块

递归分块在业务里用的会比较多，它主张的是先按大段拆分成分块，如果大段的内容超过了一个分块的大小，再进行通过分隔符小分块的拆分，如果一个段还是会超出分块的大小，那就再按符号进行分割，如果一个大段都没有符号，那再进行通过字符长度进行强制切割。
这种分块的方式已经是很主流了，保证了一定的语义完整性和块的大小控制，如果没有特别好的拆分方法，就使用这种肯定没错。但是对于一些特殊文本来说，这种拆分可能不太好，比如换行符特别多的文本。那拆分起来就很难受了。

语意拆分

这是实现比较复杂的一种分块策略。
这个策略会将文本通过标点符号进行拆分，拆分后对每个句子都生成一个向量，然后去计算每个句子向量之间的相似度，当两个句子相似度较低的时候，就进行拆分为分块。这种方式可以比较好的理解语意，通过向量数据库即可做到。但是对比前面几种，缺点也是需要引入向量数据库去实现，更复杂的可能还需要使用llm进行语意理解，成本比较高。

混合分块

最后一种，混合分块。
比如正常的系统里，肯定不可能只有一种类型的文档，那不同的文档类型可能就要使用不同的文档拆分方式，甚至需要对某些文档拆分方式进行组合。
比如使用递归分块+语意分块，先使用递归分块对文章里的大块进行拆分，再使用向量语意进行小块之间的细分，确保每个块再语意上是内聚的。
这种比较适合企业级的RAG系统，更灵活，也更细致。缺点就是复杂度高，可能需要对各种组合进行路由的排列。

分块选择

总结

以上只是系统性的一些分块策略，但是往往我们的生产级系统里，不太可能程序切完就直接上去用的，可能还需要经过打分，人工审核，人工修正的问题，程序做初筛，人工做二次修正。
然而得到分块的文本后，这些文本还不能被机器所识别，无法和问题进行匹配，还需要进行向量化的操作。