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 对超长片段进行二次切分

既然我们上面分析出了问题所在，接下来使用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 切片增加标题

再次检查代码发现，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 对上下文片段数搜参

上一篇文章，包括本文介绍了一堆Markdown的好处，但如果仅从效果的角度看，并没有表现得很能打，是否是超参数设置得不够优导致的？因此本文又对上下文片段数进行了搜参，结果如下表，如果大家回忆之前的使用RAG技术构建企业级文档问答系统：检索优化(11)上下文片段数调参，基准模型的Top6准确率可以达到0.8，而此处只能在0.8时达到0.78。有可能是将超长片段二次切分时，将大标题传播到每个小片段，对检索造成了误解，更多原因有待大家可以进一步探索。

   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这样的方法，可以确保如果切分符出现在代码块中，它是不会硬切开的。