dify icon indicating copy to clipboard operation
dify copied to clipboard

向量化后的段落是否可以支持二次编辑

Open lsave opened this issue 1 year ago • 11 comments

也可以考虑在拆分后的每个段落下面支持一个附加字段,附加字段不参与向量化和检索,但附加字段会合并到上下文里参与问答。 导入的时候支持QA对,对Q进行嵌入,A作为附加字段。

这样做的好处:

  • 减少向量化片段中过多干扰描述影响召回率,同时又不影响组装后上下文的内容详实性。
  • 降低embedding的成本
  • 增强复杂问答场景下内容维护的便利性

lsave avatar May 17 '23 11:05 lsave

好的提议,类似于 few-shots 的变种

takatost avatar May 17 '23 12:05 takatost

那不好控制A这个附加字段的质量啊,比如做问答不把A传给LLM,就不能做到组织语言或总结

linchen111 avatar May 19 '23 03:05 linchen111

那不好控制A这个附加字段的质量啊,比如做问答不把A传给LLM,就不能做到组织语言或总结

A是需要作为上下文传给LLM的,A只是不参与嵌入和向量检索而已。

lsave avatar May 20 '23 12:05 lsave

明白了,谢谢。 QA的文本我看过有方案是拆分chunk做A,用LLM生成Q。 感觉会提升一些召回准确率,但是embedding的成本似乎还是差不多

那不好控制A这个附加字段的质量啊,比如做问答不把A传给LLM,就不能做到组织语言或总结

A是需要作为上下文传给LLM的,A只是不参与嵌入和向量检索而已。

linchen111 avatar May 20 '23 13:05 linchen111

如果不是QA的,附加字段该如何生成?

dalong2hongmei avatar May 25 '23 09:05 dalong2hongmei

如果不是QA的,附加字段该如何生成?

也许可以用gpt3.5对你的chunk形成几个最佳提问

linchen111 avatar May 25 '23 09:05 linchen111

如果不是QA的,附加字段该如何生成?

也许可以用gpt3.5对你的chunk形成几个最佳提问

1、费钱,违背了省钱的初衷;2、生成的提问作为上下文似乎对于回答真实问题没有帮助(我猜的)

所以是不是非qa场景,不应该用附加字段这种方案

dalong2hongmei avatar May 25 '23 09:05 dalong2hongmei

如果不是QA的,附加字段该如何生成?

也许可以用gpt3.5对你的chunk形成几个最佳提问

1、费钱,违背了省钱的初衷;2、生成的提问作为上下文似乎对于回答真实问题没有帮助(我猜的)

所以是不是非qa场景,不应该用附加字段这种方案

有个叫fastGPT的可以看看,他好像就是做的生成QA,其实按道理是有帮助的,在ChatGPT火之前有人就有T5类的模型来做好像

linchen111 avatar May 25 '23 09:05 linchen111

核心目的其实是: 1、阶段1-基于向量的相似检索。 通过对原始分段进行二次编辑,提升召回率和准确率。 这个过程可以是人工完成的,也可以是让LLM帮你摘要、精炼、生成最佳提问等等,可以很灵活。

当前业界对这个阶段的优化手段五花八门,有先基于用户提问提取关键词,然后用关键词embedding后去检索的;也有对chunk让LLM生成最佳提问,基于最佳提问来匹配的;到底对召回率和准确率有多少提升,我也不清楚。但一定会比直接检索原始chunk要更优一些。

2、阶段2-拼接上下文由LLM生成回答 这一步在附加字段中增加few-shot来优化LLM的最终回答,并且这个字段里的内容可以随时更新,而无需重新进行embedding。比较好理解。

以上两步,分别编辑了原始chunk及其附加字段,本质上是在做知识库的清洗和精细化管理。感觉对专业知识库维护是有必要的。

当然这两步可以都不做,不是必选的,就跟现在一样,相当于提供了傻瓜模式和专业模式。

lsave avatar May 26 '23 03:05 lsave

核心目的其实是: 1、阶段1-基于向量的相似检索。 通过对原始分段进行二次编辑,提升召回率和准确率。 这个过程可以是人工完成的,也可以是让LLM帮你摘要、精炼、生成最佳提问等等,可以很灵活。

当前业界对这个阶段的优化手段五花八门,有先基于用户提问提取关键词,然后用关键词embedding后去检索的;也有对chunk让LLM生成最佳提问,基于最佳提问来匹配的;到底对召回率和准确率有多少提升,我也不清楚。但一定会比直接检索原始chunk要更优一些。

2、阶段2-拼接上下文由LLM生成回答 这一步在附加字段中增加few-shot来优化LLM的最终回答,并且这个字段里的内容可以随时更新,而无需重新进行embedding。比较好理解。

以上两步,分别编辑了原始chunk及其附加字段,本质上是在做知识库的清洗和精细化管理。感觉对专业知识库维护是有必要的。

当然这两步可以都不做,不是必选的,就跟现在一样,相当于提供了傻瓜模式和专业模式。

完全认同,补充一点,在一些召回率较高的场景下,可以对chunk做总结,从而增加top_k。

mkdirmushroom avatar May 26 '23 07:05 mkdirmushroom

chunk

非常全面总结

linchen111 avatar May 26 '23 07:05 linchen111

Close due to it's no longer active, if you have any questions, you can reopen it.

github-actions[bot] avatar Jun 26 '23 03:06 github-actions[bot]

所以针对QA类型提供专门的增删改查功能,向量仅索引Q这样的功能,是否在路上呢?对面FastGPT对QA类型确实是有专门优化的,但是我先上手的Dify,感觉更方便,更易上手,文档也很好,就是QA方面专门性的支持尚欠缺,对于QA需要经常增删改的情况,目前能够提供的支持,似乎比较弱。

ulion avatar Jul 06 '23 03:07 ulion

所以针对QA类型提供专门的增删改查功能,向量仅索引Q这样的功能,是否在路上呢?对面FastGPT对QA类型确实是有专门优化的,但是我先上手的Dify,感觉更方便,更易上手,文档也很好,就是QA方面专门性的支持尚欠缺,对于QA需要经常增删改的情况,目前能够提供的支持,似乎比较弱。

哈哈我最近也在看FastGPT,确实支持好一点

linchen111 avatar Jul 06 '23 04:07 linchen111