The same knowledge pipeline yields different results on Dify 1.9.2 and Dify 2.0.0 Beta.

[liuzhuosin]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I created knowledge bases using the exact same knowledge pipeline on both Dify 1.9.2 and Dify 2.0.0 Beta, with all configuration settings identical. However, the retrieval test results for the same PDF turned out to be different. Could you please help me understand why this might be the case?

2. Additional context or comments

No response

[dosubot[bot]]

The difference in retrieval results between Dify 1.9.2 and 2.0.0 Beta—even with the same knowledge pipeline and configuration—is likely due to major changes in the knowledge pipeline and retrieval implementation introduced in 2.0.0 Beta. The 2.0.0 Beta release included a significant refactor of the knowledge pipeline, adding new modules and changing how documents are processed, chunked, indexed, and retrieved. This means that even with identical user-facing settings, backend changes (like chunking logic, embedding, or retrieval strategies) can yield different results for the same input PDF citation.

Other factors that can cause discrepancies include differences in backend properties (such as indexing technique, embedding model, document segmentation, and metadata filtering), changes in default retrieval strategies, or even differences in how Celery worker queues are configured and used for document processing citation citation.

To troubleshoot or align results, check that all backend settings (embedding model, chunking, indexing method), document statuses, and pipeline configurations are truly identical. If you migrated data between versions, re-indexing or re-uploading documents may be necessary to ensure consistency citation. If you need to compare retrieval logic in detail, reviewing the new rag_pipeline modules and related workflow changes in 2.0.0 Beta may help clarify where the differences arise.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[liuzhuosin]

The difference in retrieval results between Dify 1.9.2 and 2.0.0 Beta—even with the same knowledge pipeline and configuration—is likely due to major changes in the knowledge pipeline and retrieval implementation introduced in 2.0.0 Beta. The 2.0.0 Beta release included a significant refactor of the knowledge pipeline, adding new modules and changing how documents are processed, chunked, indexed, and retrieved. This means that even with identical user-facing settings, backend changes (like chunking logic, embedding, or retrieval strategies) can yield different results for the same input PDF citation.

Other factors that can cause discrepancies include differences in backend properties (such as indexing technique, embedding model, document segmentation, and metadata filtering), changes in default retrieval strategies, or even differences in how Celery worker queues are configured and used for document processing citation citation.

To troubleshoot or align results, check that all backend settings (embedding model, chunking, indexing method), document statuses, and pipeline configurations are truly identical. If you migrated data between versions, re-indexing or re-uploading documents may be necessary to ensure consistency citation. If you need to compare retrieval logic in detail, reviewing the new rag_pipeline modules and related workflow changes in 2.0.0 Beta may help clarify where the differences arise.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other    

I've noticed that the knowledge pipeline in Dify 1.9.2 does not seem to execute the retrieval test strictly, whereas the retrieval test in Dify 2.0.0 Beta does. I’m wondering if there might be an issue with the retrieval test functionality in version 1.9.2?@dosu

[dosubot[bot]]

You're correct—there isn't a specific bug in the retrieval test functionality of Dify 1.9.2, but it is a known limitation that the retrieval test in 1.9.2 is not as strict or reliable as in 2.0.0 Beta. This is due to backend and pipeline implementation differences, not just the test logic itself. In 1.9.2, the retrieval test simply proxies what the backend search returns, without strict correctness checks or evaluation metrics. Factors like backend queue configuration, document indexing status, and vector database schema changes can also cause retrieval tests to be skipped or incomplete, leading to inconsistent results—even with identical settings example example.

The stricter and more reliable retrieval test execution you see in 2.0.0 Beta is the result of a major refactor of the knowledge pipeline and retrieval logic, which addressed these limitations details. So, the difference is expected and is not a bug in 1.9.2, but rather a limitation that was improved in the newer version.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[liuzhuosin]

你是对的——Dify 1.9.2 的检索测试功能中没有特定的错误，但 1.9.2 中的检索测试不像 2.0.0 Beta 中那样严格或可靠，这是一个已知的限制。这是由于后端和管道实现的差异，而不仅仅是测试逻辑本身。在 1.9.2 中，检索测试只是代理后端搜索返回的内容，没有严格的正确性检查或评估指标。后端队列配置、文档索引状态和矢量数据库架构更改等因素也可能导致跳过检索测试或不完整，从而导致结果不一致，即使设置示例示例相同也是如此。

您在 2.0.0 Beta 中看到的更严格、更可靠的检索测试执行是对知识管道和检索逻辑进行重大重构的结果，它解决了这些限制细节。因此，这种差异是意料之中的，不是 1.9.2 中的错误，而是在较新版本中改进的限制。

要回复，只需提及@dosu。

我做得怎么样？好 |无关紧要 |不正确 |详细 |幻觉 |报告 🐛 |其他    

Are there any other significant differences between them? @dosu

[dosubot[bot]]

除了检索测试严格性和可靠性的大幅提升，Dify 2.0.0 Beta 相比 1.9.2 还有以下显著差异：

• 知识管道和 RAG 架构全面重构，支持多种索引与检索方式（如关键词、向量、LLM 问答片段、混合检索、多路召回等），底层文档分块、索引、召回和评估流程都发生了变化，支持更复杂的知识库和检索场景 详情。
• 工作流引擎升级为分层、事件驱动的可扩展架构，支持可视化节点编排、并行执行、条件分支、循环、外部命令控制等，节点类型更丰富（如 LLM、知识检索、代码、HTTP、IF/ELSE、工具等），逻辑更灵活 架构说明。
• 模型管理能力大幅增强，新增 model_runtime 模块，支持 LLM、Embedding、Rerank、语音、审核等多种模型类型，模型/Provider 配置与 UI 解耦，前端可直接读取后端定义的模型和参数，便于扩展和切换 模型管理说明。
• 向量数据库 Weaviate 客户端升级到 v4，需配合 Weaviate 1.27.0+，默认启用 gRPC，检索和导入性能提升 2-5 倍，配置和环境变量有变动，升级需注意兼容性和迁移步骤 迁移指南。
• JSON 序列化全面切换为 flask-orjson，性能提升 2-3 倍，修复了原有编码器的 bug，提升了大数据量和复杂结构下的稳定性 PR。
• 新增和优化了大量用户功能：可视化工作流/Chatflow 编排、节点调试、日志与追踪、文件上传（支持多类型）、内容审核、团队协作、API 扩展、插件/工具生态等 功能总览 附加功能。

升级到 2.0.0 Beta 时，需特别注意 Weaviate 版本兼容、知识库/索引的重建、模型配置迁移等关键点。整体来看，2.0.0 Beta 在架构、性能、可扩展性和功能丰富度上有质的提升，适合更复杂和企业级的 AI 应用场景。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}