unstructured 在特殊条件下,分区Markdown文档中的列表块被识别为标题元素,

6ju8rftf  于 1个月前  发布在  其他
关注(0)|答案(7)|浏览(43)

我注意到,在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

r1wp621o

r1wp621o1#

感谢你报告这个问题,我们会尽快查看。

zpjtge22

zpjtge222#

@MthwRobinson 事实证明,这种行为是由 markdown 包产生的,而 partition_md() 使用它将 Markdown 转换为 HTML。

md_text = """
My list
- item 1
- item 2
- item 3
"""

>>> markdown.markdown(md_text)
<p>My list
- item 1
- item 2
- item 3</p>

在列表前添加一个空行会产生预期的行为:

md_text = """
My list

- item 1
- item 2
- item 3
"""

>>> markdown.markdown(md_text)
<p>My list</p>
<ul>
  <li>item 1</li>
  <li>item 2</li>
  <li>item 3</li>
</ul>

"官方"的 John Gruber 规范和参考实现指定了这种行为,即列表需要在其前有一个空行。要点是,恰好以 "-" 或 "*" 开头的折行不应被解释为列表项,例如:

The computed value of 7
* 3 equals 21.

实际上,Markdown 解析器对此更聪明,能够在没有列表前的空行的情况下可靠地区分作者的意图。
请注意,使用 markdown_it 包(我认为已经是依赖项,可能用于摄取),无论是否有空行,我们都得到了“正确”的转换。
经过一番探索后,我的总体印象是,markdown 包过于教条主义,就像严格遵循大约2005年的“原始”标准一样。我认为我们关心的是尽可能多地合法化 Markdown 文件进行解析,就像它们在 GitHub 或其他网站上出现的那样。
这种“非正式标准”的行为是 CommonMark 标准所阐述的,而 markdown_it 是符合 CommonMark 的。它也更现代化一些,只有10年的历史,而不是2岁 :)
我倾向于认为我们总体上最好使用 markdown_it 包,因为我相信它会以作者原意和在源代码上呈现的方式解析更多的 Markdown 文档。

1l5u6lss

1l5u6lss3#

在等待解决方案的同时,可以尝试以下方法:

from markdown_it import MarkdownIt

md = MarkdownIt("commonmark", {"html": True}).enable("table")
html_text = md.render(md_text)
elements = partition_html(text=html_text)

基本上,你可以自己将Markdown转换为HTML,然后使用partition_html()处理结果。

iaqfqrcu

iaqfqrcu4#

顺便问一下,@nickphilip 那个有问题的Markdown是从哪里来的?
那是你为了实验目的手写的吗,还是说你从StackOverflow或其他地方的文档中实际进行了"mis"-partitioning?

iyzzxitl

iyzzxitl5#

@scanny - 我发现在测试unstructured.io与公共仓库中的Markdown文档时存在问题,因为我注意到我的RAG应用程序没有获得预期的上下文。
对根本原因的很好的评估。您的解决方法是有道理的,但如果使用运行器(管道),修复将是首选。谢谢!

8fq7wneg

8fq7wneg6#

当你说"公共仓库"时,这是否意味着你正在解析的GFM(GitHub Flavored markdown)?

ac1kyiln

ac1kyiln7#

在对这个问题进行了一些思考和更多的研究后,我认为有四种可能的方案:

  1. 支持"传统"(或许是"遗留")Markdown(我们今天正在使用的)
  2. 支持CommonMark Markdown
  3. 支持GFM(GitHub风格的Markdown)
  4. 支持多种格式,通过某种分区选项实现
    我认为正确的答案是2(CommonMark)。
  • 它解决了这个问题
  • 它通常在处理传统Markdown时表现正常
  • 它不会像GFM那样将单个换行符解释为<br>元素

我不确定是否有完美的答案,但我认为CommonMark在分区方面提供了最广泛的覆盖,因此是一个朝着正确方向迈出的很好的一步。我认为我们都希望在能展示出令人信服的使用案例需要它之前避免引入新的分区选项。

相关问题