微信扫码
添加专属顾问
我要投稿
在解析(1)使用MinerU将PDF转换为Markdown中我们提到了将各种文档解析为Markdown的好处,本文我们接着上一篇文章处理后的Markdown,讲解如何对Markdown文档进行切分。
在很多文档中,标题都是非常重要的信息,例如企业内部的办理流程,稍微规范点的文档,标题里面都会体现重点信息的。
既然转成了Markdown,标题肯定是保留下来了,本文将首先介绍基于Markdown标题的切分方法,以及另外一种常规的Markdown切分方法。Langchain中对于Markdown文档专用的切分器,其实也只有两类:
普通的Markdown切分方法(Langchain中的MarkdownTextSplitter),效果和使用PyPDFLoader加载解析PDF的效果是一致的
基于标题的切分方法(Langchain中的MarkdownHeaderTextSplitter类),与直觉理解还不太一样,直接-使用langchain的Markdown标题切分类,效果并不好,我们将通过对结果的简单分析,尝试发现问题,并进行优化,下图是经过2次优化后的结果,效果答复提升,最终效果基本上是与基础流程打平了
本文将介绍这两种切分方法,并介绍如何通过对基于标题的切分结果进行简单的数据分析,尝试发现问题并进行解决。
下图是效果对比,从结果上来看,并没有体现出将PDF使用MinerU转换成Markdown的优势,可能的原因有以下两点:
我们示例所使用的文档,转成Markdown后只有一级标题,标题的层级不够丰富,意味着转Markdown后,标题所能发挥的作用有限
由于最初在使用RAG技术构建企业级文档问答系统之QA抽取构造的测试集是使用PyPDFLoader加载解析PDF并直接切分构造的,从这个角度讲,基础流程是与测试集更加契合的
0.71相比0.72只低了1个点,并没有显著得低,这个结果未必置信
这部分完整代码在:
https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_2_markdown_header_text_splitter.ipynb
在Langchain中基于Markdown标题的切分核心样例代码如下:
由于原文几乎没有二级标题,这意味着每个片段可能会偏大,检查切分后片段的大小:
可以看出,50%以上的文档片段长度都在462以上,粗略估计可能有40%的文档片段超过了向量模型的最大长度,这种片段的超长内容必然无法被向量模型捕获到,从而导致后续无法检索。
后续的检索、生成流程与之前的完全一致,篇幅原因大家可以到代码仓库查看完整代码。
使用这种方式切分的片段,所生成的答案最终打分只有0.37,大幅低于Baseline,结合前面对切片长度的分析,我们推测是否答错了的问题是否是片段超长导致的。
下面对答案正确(下图中score为1的)和错误(下图中score为0的)的问题,对应的最大切片长度、平均切片长度绘制灯箱图进行分析,可以明显看出,回答错了的,无论是最大切片长度,还是平均切片长度,都是比回答正确的问题要大的,推测是正确的。
这部分完整代码在:
https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_3_markdown_header_text_splitter_v2.ipynb
既然我们上面分析出了问题所在,接下来使用MarkdownTextSplitter
对超长的片段进行二次切分:
这次处理后的结果,自动打分能达到0.68了,但依然大幅低于基准0.72,下面对结果的分析也表明效果差应该不是切片长度的问题了。
3.1.3 切片增加标题
这部分完整代码在:
https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_4_markdown_header_text_splitter_v3.ipynb
再次检查代码发现,MarkdownHeaderTextSplitter
中有一个参数strip_headers,默认值为True,意思是它会把切出来的标题,放到每个切片的metadata中,这样切片本身就没有标题了,这可以说是一个bug,我们把这个参数关闭:
同时,对超长部分的片段,也把这个标题“传播”到每个超长片段二次切分后的子片段中:
这次处理后,最终自动化打分能达到0.71,基本上追平了基准0.72,但基准模型原文切分后得到了52个切片,而这种方式得到了102个切片,原文总长度是一样的,切片数量多意味着每个切片的平均长度短,都检索TopN作为上下文的话,意味着这种方式总的Prompt会更短,线上实际使用无论是耗时还是消耗API(如果使用在线API服务)的tokens数更少,这可以说是转换成Markdown后最有价值的点了。
这部分完整代码在:
https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_5_markdown_header_text_splitter_v4.ipynb
上一篇文章,包括本文介绍了一堆Markdown的好处,但如果仅从效果的角度看,并没有表现得很能打,是否是超参数设置得不够优导致的?因此本文又对上下文片段数进行了搜参,结果如下表,如果大家回忆之前的使用RAG技术构建企业级文档问答系统:检索优化(11)上下文片段数调参,基准模型的Top6准确率可以达到0.8,而此处只能在0.8时达到0.78。有可能是将超长片段二次切分时,将大标题传播到每个小片段,对检索造成了误解,更多原因有待大家可以进一步探索。
n_chunks | accuracy |
3 | 0.71 |
4 | 0.74 |
5 | 0.74 |
6 | 0.76 |
7 | 0.77 |
8 | 0.78 |
9 | 0.77 |
10 | 0.78 |
从Langchain的源代码看,MarkdownTextSplitter
其实是我们之前一直使用的RecursiveCharacterTextSplitter
的子类:
https://github.com/langchain-ai/langchain/blob/master/libs/text-splitters/langchain_text_splitters/markdown.py
只是分割符,使用了Markdown的:
注意:看起来
MarkdownTextSplitter
的切分符包含了标题切分,似乎可以涵盖MarkdownHeaderTextSplitter
的功能,但其实不然,大家如果阅读源代码的话会发现,MarkdownTextSplitter
切分只会按照指定的字符串硬切,如果Markdown的代码块中包含这些切分符,也会被切开,会造成语义不连贯,但MarkdownHeaderTextSplitter
有诸如split_text
这样的方法,可以确保如果切分符出现在代码块中,它是不会硬切开的。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-04-02
回答我!会不会搭建 DeepSeek 版个人知识库?
2025-04-02
你的RAG检索太“笨”?用K-Means聚类来“调教”
2025-04-02
强大的AI研究助手Local Deep Research
2025-04-02
探索智能代理增强检索生成(Agentic RAG):从基础到实践
2025-04-01
ragflow想说爱你不容易,win10环境搭建、常用修改
2025-04-01
跟着高手学提问,复现deepsearch
2025-04-01
Ubuntu服务器RAGFlow的部署教程
2025-04-01
连续尝试了18种RAG技术之后,我找到了最优的那个
2024-10-27
2024-09-04
2024-07-18
2024-05-05
2024-06-20
2024-06-13
2024-07-09
2024-07-09
2024-05-19
2024-07-07
2025-04-02
2025-04-01
2025-04-01
2025-03-30
2025-03-28
2025-03-27
2025-03-27
2025-03-25