langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2026-02-21 17:25:43 -05:00 by yindo · 14 comments
yindo commented 2026-02-21 17:25:43 -05:00
Owner
Copy Link
Copy Source

Originally created by @lsave on GitHub (May 17, 2023).

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

这样做的好处：

  • 减少向量化片段中过多干扰描述影响召回率，同时又不影响组装后上下文的内容详实性。
  • 降低embedding的成本
  • 增强复杂问答场景下内容维护的便利性
Originally created by @lsave on GitHub (May 17, 2023). 也可以考虑在拆分后的每个段落下面支持一个附加字段，附加字段不参与向量化和检索，但附加字段会合并到上下文里参与问答。 导入的时候支持QA对，对Q进行嵌入，A作为附加字段。 这样做的好处： - 减少向量化片段中过多干扰描述影响召回率，同时又不影响组装后上下文的内容详实性。 - 降低embedding的成本 - 增强复杂问答场景下内容维护的便利性
yindo added the 💪 enhancement label 2026-02-21 17:25:43 -05:00
yindo closed this issue 2026-02-21 17:25:43 -05:00
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@takatost commented on GitHub (May 17, 2023):

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

@takatost commented on GitHub (May 17, 2023): 好的提议，类似于 few-shots 的变种
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@linchen111 commented on GitHub (May 18, 2023):

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

@linchen111 commented on GitHub (May 18, 2023): > 那不好控制A这个附加字段的质量啊，比如做问答不把A传给LLM，就不能做到组织语言或总结
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@lsave commented on GitHub (May 20, 2023):

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

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

@lsave commented on GitHub (May 20, 2023): > > > > 那不好控制A这个附加字段的质量啊，比如做问答不把A传给LLM，就不能做到组织语言或总结 A是需要作为上下文传给LLM的，A只是不参与嵌入和向量检索而已。
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@linchen111 commented on GitHub (May 20, 2023):

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

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

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

@linchen111 commented on GitHub (May 20, 2023): 明白了，谢谢。 QA的文本我看过有方案是拆分chunk做A，用LLM生成Q。 感觉会提升一些召回准确率，但是embedding的成本似乎还是差不多 > > > > > > > > > 那不好控制A这个附加字段的质量啊，比如做问答不把A传给LLM，就不能做到组织语言或总结 > > A是需要作为上下文传给LLM的，A只是不参与嵌入和向量检索而已。
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@dalong2hongmei commented on GitHub (May 25, 2023):

如果不是QA的，附加字段该如何生成？

@dalong2hongmei commented on GitHub (May 25, 2023): 如果不是QA的，附加字段该如何生成？
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@linchen111 commented on GitHub (May 25, 2023):

如果不是QA的，附加字段该如何生成？

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

@linchen111 commented on GitHub (May 25, 2023): > 如果不是QA的，附加字段该如何生成？ 也许可以用gpt3.5对你的chunk形成几个最佳提问
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@dalong2hongmei commented on GitHub (May 25, 2023):

如果不是QA的，附加字段该如何生成？

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

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

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

@dalong2hongmei commented on GitHub (May 25, 2023): > > 如果不是QA的，附加字段该如何生成？ > > 也许可以用gpt3.5对你的chunk形成几个最佳提问 1、费钱，违背了省钱的初衷；2、生成的提问作为上下文似乎对于回答真实问题没有帮助（我猜的） 所以是不是非qa场景，不应该用附加字段这种方案
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@linchen111 commented on GitHub (May 25, 2023):

如果不是QA的，附加字段该如何生成？

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

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

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

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

@linchen111 commented on GitHub (May 25, 2023): > > > 如果不是QA的，附加字段该如何生成？ > > > > > > 也许可以用gpt3.5对你的chunk形成几个最佳提问 > > 1、费钱，违背了省钱的初衷；2、生成的提问作为上下文似乎对于回答真实问题没有帮助（我猜的） > > 所以是不是非qa场景，不应该用附加字段这种方案 有个叫fastGPT的可以看看，他好像就是做的生成QA，其实按道理是有帮助的，在ChatGPT火之前有人就有T5类的模型来做好像
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@lsave commented on GitHub (May 25, 2023):

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

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

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

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

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

@lsave commented on GitHub (May 25, 2023): 核心目的其实是： 1、阶段1-基于向量的相似检索。 通过对原始分段进行二次编辑，提升召回率和准确率。 这个过程可以是人工完成的，也可以是让LLM帮你摘要、精炼、生成最佳提问等等，可以很灵活。 当前业界对这个阶段的优化手段五花八门，有先基于用户提问提取关键词，然后用关键词embedding后去检索的；也有对chunk让LLM生成最佳提问，基于最佳提问来匹配的；到底对召回率和准确率有多少提升，我也不清楚。但一定会比直接检索原始chunk要更优一些。 2、阶段2-拼接上下文由LLM生成回答 这一步在附加字段中增加few-shot来优化LLM的最终回答，并且这个字段里的内容可以随时更新，而无需重新进行embedding。比较好理解。 以上两步，分别编辑了原始chunk及其附加字段，本质上是在做知识库的清洗和精细化管理。感觉对专业知识库维护是有必要的。 当然这两步可以都不做，不是必选的，就跟现在一样，相当于提供了傻瓜模式和专业模式。
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@mkdirmushroom commented on GitHub (May 26, 2023):

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

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

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

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

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

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

@mkdirmushroom commented on GitHub (May 26, 2023): > 核心目的其实是： 1、阶段1-基于向量的相似检索。 通过对原始分段进行二次编辑，提升召回率和准确率。 这个过程可以是人工完成的，也可以是让LLM帮你摘要、精炼、生成最佳提问等等，可以很灵活。 > > 当前业界对这个阶段的优化手段五花八门，有先基于用户提问提取关键词，然后用关键词embedding后去检索的；也有对chunk让LLM生成最佳提问，基于最佳提问来匹配的；到底对召回率和准确率有多少提升，我也不清楚。但一定会比直接检索原始chunk要更优一些。 > > 2、阶段2-拼接上下文由LLM生成回答 这一步在附加字段中增加few-shot来优化LLM的最终回答，并且这个字段里的内容可以随时更新，而无需重新进行embedding。比较好理解。 > > 以上两步，分别编辑了原始chunk及其附加字段，本质上是在做知识库的清洗和精细化管理。感觉对专业知识库维护是有必要的。 > > 当然这两步可以都不做，不是必选的，就跟现在一样，相当于提供了傻瓜模式和专业模式。 完全认同，补充一点，在一些召回率较高的场景下，可以对chunk做总结，从而增加top_k。
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@linchen111 commented on GitHub (May 26, 2023):

chunk

非常全面总结

@linchen111 commented on GitHub (May 26, 2023): > chunk 非常全面总结
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jun 25, 2023):

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

@github-actions[bot] commented on GitHub (Jun 25, 2023): Close due to it's no longer active, if you have any questions, you can reopen it.
yindo commented 2026-02-21 17:25:44 -05:00
Author
Owner
Copy Link
Copy Source

@ulion commented on GitHub (Jul 5, 2023):

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

@ulion commented on GitHub (Jul 5, 2023): 所以针对QA类型提供专门的增删改查功能，向量仅索引Q这样的功能，是否在路上呢？对面FastGPT对QA类型确实是有专门优化的，但是我先上手的Dify，感觉更方便，更易上手，文档也很好，就是QA方面专门性的支持尚欠缺，对于QA需要经常增删改的情况，目前能够提供的支持，似乎比较弱。
yindo commented 2026-02-21 17:25:45 -05:00
Author
Owner
Copy Link
Copy Source

@linchen111 commented on GitHub (Jul 6, 2023):

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

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

@linchen111 commented on GitHub (Jul 6, 2023): > 所以针对QA类型提供专门的增删改查功能，向量仅索引Q这样的功能，是否在路上呢？对面FastGPT对QA类型确实是有专门优化的，但是我先上手的Dify，感觉更方便，更易上手，文档也很好，就是QA方面专门性的支持尚欠缺，对于QA需要经常增删改的情况，目前能够提供的支持，似乎比较弱。 哈哈我最近也在看FastGPT，确实支持好一点
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 💪 enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#45
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?