我注意到,在Markdown文档的列表块中,每行字符数非常短时,列表会被识别为Title
,而不是NarrativeText
。
这可以防止通过标题进行分块的工作正常进行,因为我希望所有位于Markdown标题下方的内容都变成CompositeText
,以便使用嵌入函数进行索引。
可以通过以下Python代码重现:
from unstructured.partition.md import partition_md
md_text = """
# header 1
## header 2
My list
- item 1
- item 2
- item 3
- item 4
- item 5
## header 3
"""
elements = partition_md(text=md_text)
for el in elements:
if el.category == "Title": print("{}: {}".format(el.category,el.text))
只要列表块中的任何一行(包括介绍行)有更多的字符,列表块就会被正确识别为NarrativeText
。
软件包版本:
unstructured 0.14.5
7条答案
按热度按时间r1wp621o1#
感谢你报告这个问题,我们会尽快查看。
zpjtge222#
@MthwRobinson 事实证明,这种行为是由
markdown
包产生的,而partition_md()
使用它将 Markdown 转换为 HTML。在列表前添加一个空行会产生预期的行为:
"官方"的 John Gruber 规范和参考实现指定了这种行为,即列表需要在其前有一个空行。要点是,恰好以 "-" 或 "*" 开头的折行不应被解释为列表项,例如:
实际上,Markdown 解析器对此更聪明,能够在没有列表前的空行的情况下可靠地区分作者的意图。
请注意,使用
markdown_it
包(我认为已经是依赖项,可能用于摄取),无论是否有空行,我们都得到了“正确”的转换。经过一番探索后,我的总体印象是,
markdown
包过于教条主义,就像严格遵循大约2005年的“原始”标准一样。我认为我们关心的是尽可能多地合法化 Markdown 文件进行解析,就像它们在 GitHub 或其他网站上出现的那样。这种“非正式标准”的行为是 CommonMark 标准所阐述的,而
markdown_it
是符合 CommonMark 的。它也更现代化一些,只有10年的历史,而不是2岁 :)我倾向于认为我们总体上最好使用
markdown_it
包,因为我相信它会以作者原意和在源代码上呈现的方式解析更多的 Markdown 文档。1l5u6lss3#
在等待解决方案的同时,可以尝试以下方法:
基本上,你可以自己将Markdown转换为HTML,然后使用
partition_html()
处理结果。iaqfqrcu4#
顺便问一下,@nickphilip 那个有问题的Markdown是从哪里来的?
那是你为了实验目的手写的吗,还是说你从StackOverflow或其他地方的文档中实际进行了"mis"-partitioning?
iyzzxitl5#
@scanny - 我发现在测试unstructured.io与公共仓库中的Markdown文档时存在问题,因为我注意到我的RAG应用程序没有获得预期的上下文。
对根本原因的很好的评估。您的解决方法是有道理的,但如果使用运行器(管道),修复将是首选。谢谢!
8fq7wneg6#
当你说"公共仓库"时,这是否意味着你正在解析的GFM(GitHub Flavored markdown)?
ac1kyiln7#
在对这个问题进行了一些思考和更多的研究后,我认为有四种可能的方案:
我认为正确的答案是2(CommonMark)。
<br>
元素我不确定是否有完美的答案,但我认为CommonMark在分区方面提供了最广泛的覆盖,因此是一个朝着正确方向迈出的很好的一步。我认为我们都希望在能展示出令人信服的使用案例需要它之前避免引入新的分区选项。