haystack 使用元数据来提升提取式阅读器的性能

r1zk6ea1  于 4个月前  发布在  其他
关注(0)|答案(6)|浏览(40)

您的功能请求是否与问题相关?请描述。

我想能够使用元信息来为TransformerReader或FARMReader提供上下文,以类似的方式提高回答问题的性能,就像我们可以使用embed_meta_fields来提高EmbeddingRetrievers的性能一样。有时需要元信息来区分相似的文档。
我们的多个客户都面临过这个问题,因为他们从许多法律PDF文件中检索信息,这些文件中有很多样板文本,通常在60页的PDF文件开头定义公司名称等事物。

描述您希望的解决方案

作为动力,我想通过一个示例来说明,在查询时将文档的元信息添加到Reader中会带来什么好处。假设我有两个具有相似结构和相似信息的文档,但涉及两个不同的公司:
文档1(来自pear_llc_contract.pdf)

# meta info
meta = {"additional_context": "This passage is about the company Pear, from the year 2020."}
# content of Document
Company ID: 312521124141
Deal amount: 100k
Two leading organizations have joined forces in a groundbreaking partnership that promises to revolutionize their respective industries. The agreement, which was finalized after months of negotiations, will see the companies collaborate on a range of exciting initiatives that will benefit both parties and their customers.

文档2(来自rainforest_contract.pdf)

# meta info
meta = {"additional_context": "This passage is about the company Rainforest, from the year 2019."}
# content of Document
Company ID: 847584923
Deal amount: 60k
The deal is expected to generate significant benefits for both companies, including increased revenue, improved operational efficiency, and enhanced customer experience. It is also expected to create new jobs and stimulate economic growth in the regions where the companies operate.

我想问问题 "Pear LLC的公司ID是多少?"然而,文档内容中没有任何地方指定参与交易的公司名称。因此,如果将这两个文档提供给FARMReader,我应该得到正确答案的50/50几率。
然而,如果我可以指定一个新的变量(例如embed_meta_fields,就像我们可以为EmbeddingRetrievers使用的那样)

reader = ExtractiveReader(model="deepset/deberta-v3-large-squad2", embed_meta_fields=["additional_context"])

那么FARMReader将拥有回答问题的必要上下文。

附加背景

  • 这与我们如何使用PromptTemplates为PromptNode提供上下文类似。而且,在PromptTemplates中,我们已经可以使用特殊的变量将文档中的元信息添加到提示中。我认为将其扩展到提取式阅读器仍然非常有益,因为Sol仍然对提取式模型感兴趣。
  • 然而,一个区别是,我们应该考虑是否阻止ExtractiveReader将additional_context作为答案返回,因为additional_context不会出现在返回给用户的文档中。
0vvn1miw

0vvn1miw1#

嘿,@sjrl,这可能是ExtractiveReader的一个特性,而不是FARMReader的吗?我们正在尝试在它们之间实现功能一致性,因此新功能应该直接添加到ExtractiveReader中。
如果是这样的话,让我们更改标题并将此标记为Haystack 2.x功能请求。如果不是的话,让我们找出原因吧。

3phpmpom

3phpmpom2#

当然可以。这可以作为ExtractiveReader的一个功能。

mzsu5hc0

mzsu5hc03#

我不明白为什么它应该是一个元字段。难道这个信息不能在预处理过程中添加到文档中吗?无论如何,如果对任何客户来说都紧急的话,请随意打开一个轻量级的PR。不过,我还是希望在Reader之外处理它。

p8ekf7hl

p8ekf7hl4#

我不明白为什么它应该是一个元字段。
我认为我们通常不希望让读者允许返回额外的信息作为答案。所以从我最初的描述来看:

  • 然而,一个区别是我们应该考虑是否阻止ExtractiveReader将additional_context作为答案返回,因为additional_context不会出现在返回给用户的文档中。

这就是为什么直接将其添加到预处理过的文档中不起作用的原因。
不过,我更倾向于在阅读器之外处理它。
考虑到这一点,我认为最好不要允许将此额外文本作为答案返回,因此将其集成到ExtractiveReader中会更好。
你怎么看?

afdcj2ne

afdcj2ne5#

Mh,仍然不确定这个。在提示中,用户可以查看传递给模型的内容。在使用提取式问答时,我们希望确保用户能够正确检查预测结果。如果没有additional_context,这可能不可能实现。
我认为将additional_context放在文档内部是可以的(并明确指出它是添加的?)。
我喜欢这个想法的原因是它与embedders中的embed_meta_fields的设计相似。
请随时为这个功能打开一个轻量级的PR。

34gzjxbg

34gzjxbg6#

我喜欢这个想法,因为它与嵌入器的embed_meta_fields设计相似。我想说的是,embed_meta_fields使向文本文件添加元数据变得模糊。embed_meta_fields功能仅在索引时添加文本,但当用户搜索时,他们看不到文档前面有这些元信息被添加。

在提示中,用户可以查看传递给模型的内容。对于提取式问答,我们希望确保用户能够正确检查预测结果。

然而,这是一个很好的观点。也许一个折中的方案是,我们在返回的Haystack答案中将additional_context添加到文档中,这样用户就可以看到它,但我们仍然限制模型不将additional_context作为答案的一部分返回?

相关问题