|
在解析(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个点，并没有显著得低，这个结果未必置信
3.1.1 直接使用MarkdownHeaderTextSplitterhttps://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)dmd_splitted_docs]).describe() count43.000000
mean749.395349
std673.945036
min33.000000
25%241.000000
50%462.000000
75%1075.500000
max2839.000000 可以看出，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对超长的片段进行二次切分： MarkdownTextSplitter
new_md_splitted_docs=[]
splitter=MarkdownTextSplitter(
chunk_size=,
chunk_overlap=
)
docmd_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=
)
docmd_splitted_docs:
(doc.page_content)>:
small_chunks=splitter.split_documents([doc])
docsmall_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_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 |
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)textsplitted_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) ...
language==Language.MARKDOWN:
[
,
,
,
,
,
,
,
,
,
]
... 注意：看起来MarkdownTextSplitter的切分符包含了标题切分，似乎可以涵盖MarkdownHeaderTextSplitter的功能，但其实不然，大家如果阅读源代码的话会发现，MarkdownTextSplitter切分只会按照指定的字符串硬切，如果Markdown的代码块中包含这些切分符，也会被切开，会造成语义不连贯，但MarkdownHeaderTextSplitter有诸如split_text这样的方法，可以确保如果切分符出现在代码块中，它是不会硬切开的。
|
