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

Knowledge Retrieval Extremely Slow #15651

New Issue
Closed
opened 2026-02-21 19:22:43 -05:00 by yindo · 15 comments
yindo commented 2026-02-21 19:22:43 -05:00
Owner
Copy Link
Copy Source

Originally created by @hiwuye on GitHub (Jul 24, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Image

I currently have 9 knowledge bases with approximately 2,500 documents in total. Since version 1.4, knowledge retrieval has become significantly slower, often taking more than 40 seconds.

Image Even when referencing only one knowledge base containing a single document, the retrieval takes around 19 seconds. This issue still exists in version 1.7. Is this a known issue? Is the team actively working on a fix?

✔️ Expected Behavior

Overall retrieval performance is expected to be faster and smoother than the current state.
In earlier versions, retrieval speed was significantly better.
No major system or hardware changes occurred during the upgrade.
Looking forward to any advice on optimization or ongoing plans to improve performance.

❌ Actual Behavior

Even when referencing only one knowledge base containing a single document, the retrieval takes around 19 seconds. This issue still exists in version 1.7.

Originally created by @hiwuye on GitHub (Jul 24, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce <img width="464" height="245" alt="Image" src="https://github.com/user-attachments/assets/5dd10ffa-6f98-4e09-95fb-cbc8988db6de" /> I currently have 9 knowledge bases with approximately 2,500 documents in total. Since version 1.4, knowledge retrieval has become significantly slower, often taking more than 40 seconds. <img width="423" height="256" alt="Image" src="https://github.com/user-attachments/assets/fa3965e8-5fa5-4439-acf3-e37035dc97a4" /> Even when referencing only one knowledge base containing a single document, the retrieval takes around 19 seconds. This issue still exists in version 1.7. Is this a known issue? Is the team actively working on a fix? ### ✔️ Expected Behavior Overall retrieval performance is expected to be faster and smoother than the current state. In earlier versions, retrieval speed was significantly better. No major system or hardware changes occurred during the upgrade. Looking forward to any advice on optimization or ongoing plans to improve performance. ### ❌ Actual Behavior Even when referencing only one knowledge base containing a single document, the retrieval takes around 19 seconds. This issue still exists in version 1.7.
yindo added the 👻 feat:rag label 2026-02-21 19:22:43 -05:00
yindo closed this issue 2026-02-21 19:22:43 -05:00
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jul 24, 2025):

This is a known issue since v1.4—knowledge retrieval performance has regressed due to architectural changes in the RAG pipeline. The team is actively working on a RAG 2.0 pipeline to address these performance problems, as confirmed in recent discussions and issues (see here).

Recent pull requests show ongoing work on knowledge retrieval, including fixes for validation errors and improvements to database session handling, which may help with speed (PR #22682), (PR #22306), (PR #22793).

For optimization, review your Docker resource allocations (CPU/memory), ensure your vector database backend is performant and properly configured, and check for any network/database bottlenecks. Performance can also be affected by embedding model choice, chunk size, and connection pool settings—these are typically documented in sample config files and code comments.

Keep an eye on updates related to RAG 2.0, and if possible, experiment with different vector database backends or configurations to see if retrieval speed improves.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 24, 2025): <!-- Answer --> This is a known issue since v1.4—knowledge retrieval performance has regressed due to architectural changes in the RAG pipeline. The team is actively working on a RAG 2.0 pipeline to address these performance problems, as confirmed in recent discussions and issues [(see here)](https://github.com/langgenius/dify/issues/21326). Recent pull requests show ongoing work on knowledge retrieval, including fixes for validation errors and improvements to database session handling, which may help with speed [(PR #22682)](https://github.com/langgenius/dify/pull/22682), [(PR #22306)](https://github.com/langgenius/dify/pull/22306), [(PR #22793)](https://github.com/langgenius/dify/pull/22793). For optimization, review your Docker resource allocations (CPU/memory), ensure your vector database backend is performant and properly configured, and check for any network/database bottlenecks. Performance can also be affected by embedding model choice, chunk size, and connection pool settings—these are typically documented in sample config files and code comments. Keep an eye on updates related to RAG 2.0, and if possible, experiment with different vector database backends or configurations to see if retrieval speed improves. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/01a3bd44-21ec-4d33-9e5a-0147d4573521?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/22933)
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@GreatStep commented on GitHub (Jul 25, 2025):

slow~ slow~
I look forward to RAG 2.0~

@GreatStep commented on GitHub (Jul 25, 2025): slow~ slow~ I look forward to RAG 2.0~
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@onestardao commented on GitHub (Jul 28, 2025):

Ouch — 40+ seconds on knowledge retrieval is brutal, especially when your doc count isn't massive yet
We ran into a similar bottleneck before, and turns out the issue wasn’t just vector store speed... it was semantic overhead.

A lot of pipelines try to "retrieve meaning" too late in the process.
Our solution? Move semantic compression up front, encode high-density meaning before vectorization, and design the RAG interface to behave more like a symbolic planner than a text fetcher.

You might like this approach — it shaved our response times by 70% even under heavy load.
Engine name: WFGY (weird name, long story — but full repo's open source if you're curious:
https://github.com/onestardao/WFGY/tree/main/OS)

It works with chunked retrieval, hallucination blockers, even lets you visualize retrieval reasoning if needed.
Might be worth exploring if latency’s driving you insane

@onestardao commented on GitHub (Jul 28, 2025): Ouch — 40+ seconds on knowledge retrieval is brutal, especially when your doc count isn't massive yet We ran into a similar bottleneck before, and turns out the issue wasn’t just vector store speed... it was *semantic overhead*. A lot of pipelines try to "retrieve meaning" too late in the process. Our solution? Move semantic compression up front, encode high-density meaning **before** vectorization, and design the RAG interface to behave more like a symbolic planner than a text fetcher. You might like this approach — it shaved our response times by 70% even under heavy load. Engine name: **WFGY** (weird name, long story — but full repo's open source if you're curious: https://github.com/onestardao/WFGY/tree/main/OS) It works with chunked retrieval, hallucination blockers, even lets you visualize retrieval reasoning if needed. Might be worth exploring if latency’s driving you insane
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@DavideDelbianco commented on GitHub (Aug 30, 2025):

@crazywoola

I have ~4 sec retrieval on a KB with 400 documents that is filtered, after filtering on average there should be ~40 docs.
I am using Weaviate, it is my understanding that Vector databases should be able to support much much greater knowledge bases.

Are those numbers the norm?

@DavideDelbianco commented on GitHub (Aug 30, 2025): @crazywoola I have ~4 sec retrieval on a KB with 400 documents that is filtered, after filtering on average there should be ~40 docs. I am using Weaviate, it is my understanding that Vector databases should be able to support much much greater knowledge bases. Are those numbers the norm?
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 30, 2025):

Hi, @hiwuye. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported severe slowdowns in knowledge retrieval starting from Dify v1.4, with retrieval times exceeding 40 seconds across multiple knowledge bases.
  • This performance issue has persisted through to v1.7 and is linked to architectural changes in the RAG pipeline.
  • The Dify team is actively working on a RAG 2.0 pipeline aimed at improving retrieval performance.
  • Community members have suggested workarounds like semantic compression before vectorization and alternative vector databases such as Weaviate for faster retrieval.
  • Users are encouraged to optimize Docker resources and vector database configurations while awaiting official improvements.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open.
  • If I don’t hear back within 15 days, I will automatically close this issue to help us focus on active concerns.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Sep 30, 2025): Hi, @hiwuye. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported severe slowdowns in knowledge retrieval starting from Dify v1.4, with retrieval times exceeding 40 seconds across multiple knowledge bases. - This performance issue has persisted through to v1.7 and is linked to architectural changes in the RAG pipeline. - The Dify team is actively working on a RAG 2.0 pipeline aimed at improving retrieval performance. - Community members have suggested workarounds like semantic compression before vectorization and alternative vector databases such as Weaviate for faster retrieval. - Users are encouraged to optimize Docker resources and vector database configurations while awaiting official improvements. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open. - If I don’t hear back within 15 days, I will automatically close this issue to help us focus on active concerns. Thank you for your understanding and contribution!
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@deific commented on GitHub (Oct 10, 2025):

I just upgraded from 1.3.1 to 1.9.1 and I clearly feel that the knowledge base retrieval is slowing down. Any new solutions?

@deific commented on GitHub (Oct 10, 2025): I just upgraded from 1.3.1 to 1.9.1 and I clearly feel that the knowledge base retrieval is slowing down. Any new solutions?
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@hiwuye commented on GitHub (Oct 23, 2025):

1.9.2 the same .Did the project team hear the sound?

@hiwuye commented on GitHub (Oct 23, 2025): 1.9.2 the same .Did the project team hear the sound?
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@zhaozhiwei1992 commented on GitHub (Oct 27, 2025):

version 1.4.3, in prod 16k Documents need 8s, dev environment need 1s, how to fix。

@zhaozhiwei1992 commented on GitHub (Oct 27, 2025): version 1.4.3, in prod 16k Documents need 8s, dev environment need 1s, how to fix。
yindo commented 2026-02-21 19:22:43 -05:00
Author
Owner
Copy Link
Copy Source

@NameJaho commented on GitHub (Oct 28, 2025):

1.9.2 the same .Did the project team hear the sound?1.9.2 相同 .项目小组听到声音了吗？

change vector db to milvus may be faster. it's worked for me

@NameJaho commented on GitHub (Oct 28, 2025): > 1.9.2 the same .Did the project team hear the sound?1.9.2 相同 .项目小组听到声音了吗？ change vector db to milvus may be faster. it's worked for me
yindo commented 2026-02-21 19:22:44 -05:00
Author
Owner
Copy Link
Copy Source

@hiwuye commented on GitHub (Oct 28, 2025):

1.9.2 the same .Did the project team hear the sound?1.9.2 相同 .项目小组听到声音了吗？

change vector db to milvus may be faster. it's worked for me

How to configure it? I tried but didn’t succeed.help

@hiwuye commented on GitHub (Oct 28, 2025): > > 1.9.2 the same .Did the project team hear the sound?1.9.2 相同 .项目小组听到声音了吗？ > > change vector db to milvus may be faster. it's worked for me How to configure it? I tried but didn’t succeed.help
yindo commented 2026-02-21 19:22:44 -05:00
Author
Owner
Copy Link
Copy Source

@NameJaho commented on GitHub (Oct 28, 2025):

1.9.2 the same .Did the project team hear the sound?1.9.2 相同 .项目小组听到声音了吗？1.9.2 相同 .项目小组听到声音了吗？

change vector db to milvus may be faster. it's worked for me将矢量数据库更改为 Milvus 可能更快。

How to configure it? I tried but didn’t succeed.help如何配置？我试过了，但没有成功。

  1. VECTOR_STORE=milvus
  2. MILVUS_URI=http://172.30.48.95:19530
  3. recompose
  4. docker exec -it docker-api-1 flask vdb-migrate
@NameJaho commented on GitHub (Oct 28, 2025): > > > 1.9.2 the same .Did the project team hear the sound?1.9.2 相同 .项目小组听到声音了吗？1.9.2 相同 .项目小组听到声音了吗？ > > > > > > change vector db to milvus may be faster. it's worked for me将矢量数据库更改为 Milvus 可能更快。 > > How to configure it? I tried but didn’t succeed.help如何配置？我试过了，但没有成功。 1. VECTOR_STORE=milvus 2. MILVUS_URI=http://172.30.48.95:19530 3. recompose 4. docker exec -it docker-api-1 flask vdb-migrate
yindo commented 2026-02-21 19:22:44 -05:00
Author
Owner
Copy Link
Copy Source

@zhaozhiwei1992 commented on GitHub (Dec 3, 2025):

change vector db to milvus, it`s worked for me too. thanks @NameJaho

@zhaozhiwei1992 commented on GitHub (Dec 3, 2025): change vector db to milvus, it`s worked for me too. thanks @NameJaho
yindo commented 2026-02-21 19:22:44 -05:00
Author
Owner
Copy Link
Copy Source

@zhaozhiwei1992 commented on GitHub (Dec 25, 2025):

I upgrade dify from 1.4.3 to 1.11.1, knowledge retrieval faster.

@zhaozhiwei1992 commented on GitHub (Dec 25, 2025): I upgrade dify from 1.4.3 to 1.11.1, knowledge retrieval faster.
yindo commented 2026-02-21 19:22:44 -05:00
Author
Owner
Copy Link
Copy Source

@hiwuye commented on GitHub (Jan 3, 2026):

I upgrade dify from 1.4.3 to 1.11.1, knowledge retrieval faster.

I also upgraded to version 1.11.1, and the knowledge base has become faster, returning to its previous level of performance.

@hiwuye commented on GitHub (Jan 3, 2026): > I upgrade dify from 1.4.3 to 1.11.1, knowledge retrieval faster. I also upgraded to version 1.11.1, and the knowledge base has become faster, returning to its previous level of performance.
yindo commented 2026-02-21 19:22:44 -05:00
Author
Owner
Copy Link
Copy Source

@hiwuye commented on GitHub (Jan 3, 2026):

close

@hiwuye commented on GitHub (Jan 3, 2026): close
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 👻 feat:rag
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#15651
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?