问题 :在排除LLM的强大,Prompt的精心调整,检索算法和Embedding优化后仍然答案不准确。
解决方案 :
如果你把一句话从中间给切断了,那模型就很难去理解他的真正要表达的含义,所以理想的分块标准应该要在这两个目标之间去找到一个平衡。
- 分块的本质:
- 大模型本身的上下文长度限制
- 向量的检索是依赖与语义的完整度
- 理想的分块标准
- 平衡信息的密度与上下文完整性
- 通过chunk_size(控制文本块的长度大小,256/512/1024字符或token)、chunk_overlap(相邻块之间的重叠部分,通常会设置块的大小的10%到20%),这个重叠部分就是用来防止语义的断裂
- 分块策略
- 基础分块 :我们可以按照固定长度的字符或者句子来进行切分
- 固定长度、递归字符、句子

- 固定长度、递归字符、句子
- 结构感知分块:我们会利用文档本身的结构,比如markdown/html的一些网页,它们本身是有结构的,所以就可以利用这些结构来进行结构化分块
- 语义 /主题分块 :通过embedding模型去理解内容,他会在语义出现变化的地方进行切块,比如:他在描述一个对象,接下来立马在描述另一个对象,那么语义发生了变化,这个时候它就会自动的来进行切分。

- 高级策略 :小-大分块(小的文本块会利于检索,但是上下问太少就会导致生成答案的时候信息不足;大的文本块上下文很丰富,但是检索的时候会有噪声,命中率就会下降。基于这样的问题,我们的做法就是利用小块检索,检索到之后再返回它对应的大文本块)、代理式分块(主要是基于大模型本身来帮我进行动态的一个切分,这种方式成本会很高)

混合分块--复杂文档的实践
策略 :先结构粗切-》再语义/递归细切。可以先做一个初步的切分,在通过检查切分的块大小阈值判断再进行其他方式的切分。
适合场景 :技术白皮书、年报、多个是混合文档
特别适合处理包含多种元素(文本、图表、代码)或者逻辑层次复杂的长文档。

如何选择最佳的策略
三步决策法
- 看数据类型:结构化文档(PDF、Markdown)、无格式的文本
- 看业务需求:是追求高精度的检索效果还是需要支持长上下文的生成任务
- 看资源成本:能否承受大语言模型语义分块带来的计算开销和延迟