支持私有云部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


使用RAG技术构建企业级文档问答系统:切分(1)Markdown文档切分

发布日期:2024-12-17 08:58:10 浏览次数: 1961 作者:超乎想象的科技圈

1 概述

在解析(1)使用MinerU将PDF转换为Markdown中我们提到了将各种文档解析为Markdown的好处,本文我们接着上一篇文章处理后的Markdown,讲解如何对Markdown文档进行切分。

在很多文档中,标题都是非常重要的信息,例如企业内部的办理流程,稍微规范点的文档,标题里面都会体现重点信息的。

既然转成了Markdown,标题肯定是保留下来了,本文将首先介绍基于Markdown标题的切分方法,以及另外一种常规的Markdown切分方法。Langchain中对于Markdown文档专用的切分器,其实也只有两类:

  • 普通的Markdown切分方法(Langchain中的MarkdownTextSplitter),效果和使用PyPDFLoader加载解析PDF的效果是一致的

  • 基于标题的切分方法(Langchain中的MarkdownHeaderTextSplitter类),与直觉理解还不太一样,直接-使用langchain的Markdown标题切分类,效果并不好,我们将通过对结果的简单分析,尝试发现问题,并进行优化,下图是经过2次优化后的结果,效果答复提升,最终效果基本上是与基础流程打平了

本文将介绍这两种切分方法,并介绍如何通过对基于标题的切分结果进行简单的数据分析,尝试发现问题并进行解决。

2 效果对比

下图是效果对比,从结果上来看,并没有体现出将PDF使用MinerU转换成Markdown的优势,可能的原因有以下两点:

  • 我们示例所使用的文档,转成Markdown后只有一级标题,标题的层级不够丰富,意味着转Markdown后,标题所能发挥的作用有限

  • 由于最初在使用RAG技术构建企业级文档问答系统之QA抽取构造的测试集是使用PyPDFLoader加载解析PDF并直接切分构造的,从这个角度讲,基础流程是与测试集更加契合的

  • 0.71相比0.72只低了1个点,并没有显著得低,这个结果未必置信

3 核心代码

3.1 基于标题切分

3.1.1 直接使用MarkdownHeaderTextSplitter

这部分完整代码在:

https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_2_markdown_header_text_splitter.ipynb

在Langchain中基于Markdown标题的切分核心样例代码如下:

   MarkdownHeaderTextSplitter
 


markdown_documents = (os.path.join(os.path.pardir, , , )).read()

 (markdown_document):

    headers_to_split_on = [
        (, ),
        (, ),
        (, ),
    ]
    markdown_splitter = MarkdownHeaderTextSplitter(headers_to_split_on)
    md_header_splits = markdown_splitter.split_text(markdown_document)

 md_header_splits

md_splitted_docs = split_md_docs(markdown_documents)

由于原文几乎没有二级标题,这意味着每个片段可能会偏大,检查切分后片段的大小:

   

pd.Series([(d.page_content)  d  md_splitted_docs]).describe()
count      43.000000
mean      749.395349
std       673.945036
min        33.000000
25%       241.000000
50%       462.000000
75%      1075.500000
max      2839.000000

可以看出,50%以上的文档片段长度都在462以上,粗略估计可能有40%的文档片段超过了向量模型的最大长度,这种片段的超长内容必然无法被向量模型捕获到,从而导致后续无法检索。

后续的检索、生成流程与之前的完全一致,篇幅原因大家可以到代码仓库查看完整代码。

使用这种方式切分的片段,所生成的答案最终打分只有0.37,大幅低于Baseline,结合前面对切片长度的分析,我们推测是否答错了的问题是否是片段超长导致的。

下面对答案正确(下图中score为1的)和错误(下图中score为0的)的问题,对应的最大切片长度、平均切片长度绘制灯箱图进行分析,可以明显看出,回答错了的,无论是最大切片长度,还是平均切片长度,都是比回答正确的问题要大的,推测是正确的。

3.1.2 对超长片段进行二次切分

这部分完整代码在:

https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_3_markdown_header_text_splitter_v2.ipynb

既然我们上面分析出了问题所在,接下来使用MarkdownTextSplitter对超长的片段进行二次切分:

   MarkdownTextSplitter

new_md_splitted_docs = []
splitter = MarkdownTextSplitter(
    chunk_size=,
    chunk_overlap=
)
 doc  md_splitted_docs:
 (doc.page_content) > :
        small_chunks = splitter.split_documents([doc])
        new_md_splitted_docs.extend(small_chunks)
:
        new_md_splitted_docs.append(doc)


这次处理后的结果,自动打分能达到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,我们把这个参数关闭:

 (markdown_document):
    headers_to_split_on = [
        (, ),
        (, ),
        (, ),
    ]
    markdown_splitter = MarkdownHeaderTextSplitter(headers_to_split_on, strip_headers=)
    md_header_splits = markdown_splitter.split_text(markdown_document)

 md_header_splits

同时,对超长部分的片段,也把这个标题“传播”到每个超长片段二次切分后的子片段中:

   MarkdownTextSplitter

new_md_splitted_docs = []
splitter = MarkdownTextSplitter(
    chunk_size=,
    chunk_overlap=
)
 doc  md_splitted_docs:
 (doc.page_content) > :
        small_chunks = splitter.split_documents([doc])

 doc  small_chunks[:]:
            header_prefix = 
 head_level  (, ):
   doc.metadata:
                    header_prefix +=  * head_level +  + doc.metadata[] + 
            doc.page_content = header_prefix + doc.page_content

        new_md_splitted_docs.extend(small_chunks)
:
        new_md_splitted_docs.append(doc)

这次处理后,最终自动化打分能达到0.71,基本上追平了基准0.72,但基准模型原文切分后得到了52个切片,而这种方式得到了102个切片,原文总长度是一样的,切片数量多意味着每个切片的平均长度短,都检索TopN作为上下文的话,意味着这种方式总的Prompt会更短,线上实际使用无论是耗时还是消耗API(如果使用在线API服务)的tokens数更少,这可以说是转换成Markdown后最有价值的点了。

3.1.4 对上下文片段数搜参

这部分完整代码在:

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_chunksaccuracy
30.71
40.74
50.74
60.76
70.77
80.78
90.77
100.78

3.2 普通Markdown切分器这部分完整代码在:https://github.com/Steven-Luo/MasteringRAG/blob/main/split/01_1_markdown_text_splitter.ipynb


   MarkdownTextSplitter
   Document
 


markdown_documents = (os.path.join(os.path.pardir, , , )).read()

 (markdown_document, chunk_size=, chunk_overlap=):
    splitter = MarkdownTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap
    )
    splitted_texts = splitter.split_text(markdown_document)
 [Document(page_content=text)  text  splitted_texts]

从Langchain的源代码看,MarkdownTextSplitter其实是我们之前一直使用的RecursiveCharacterTextSplitter的子类:

https://github.com/langchain-ai/langchain/blob/master/libs/text-splitters/langchain_text_splitters/markdown.py

 (RecursiveCharacterTextSplitter):


 (, **kwargs: Any) -> :

        separators = .get_separators_for_language(Language.MARKDOWN)
().(separators=separators, **kwargs)

只是分割符,使用了Markdown的:

...
 language == Language.MARKDOWN:
 [

,




,

,
,
,


,
,
,
,
    ]
...

注意:看起来MarkdownTextSplitter的切分符包含了标题切分,似乎可以涵盖MarkdownHeaderTextSplitter的功能,但其实不然,大家如果阅读源代码的话会发现,MarkdownTextSplitter切分只会按照指定的字符串硬切,如果Markdown的代码块中包含这些切分符,也会被切开,会造成语义不连贯,但MarkdownHeaderTextSplitter有诸如split_text这样的方法,可以确保如果切分符出现在代码块中,它是不会硬切开的。


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询