1.9.0 – Orchestrating Knowledge, Powering Workflows #26138
crazywoola
announced in
Releases
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
🚀 Introduction
In Dify 1.9.0, we are introducing two major new capabilities: the Knowledge Pipeline and the Queue-based Graph Engine.
The Knowledge Pipeline provides a modularized and extensible workflow for knowledge ingestion and processing, while the Queue-based Graph Engine makes workflow execution more robust and controllable. We believe these will help you build and debug AI applications more smoothly, and we look forward to your experiences to help us continuously improve.
📚 Knowledge Pipeline
✨ Introduction
With the brand-new orchestration interface for knowledge pipelines, we introduce a fundamental architectural upgrade that reshapes how document processing are designed and executed, providing a more modular and flexible workflow that enables users to orchestrate every stage of the pipeline. Enhanced with a wide range of powerful plugins available in the marketplace, it empowers users to flexibly integrate diverse data sources and processing tools. Ultimately, this architecture enables building highly customized, domain-specific RAG solutions that meet enterprises’ growing demands for scalability, adaptability, and precision.
❓ Why Do We Need It?
Previously, Dify's RAG users still encounter persistent challenges in real-world adoption — from inaccurate knowledge retrieval and information loss to limited data integration and extensibility. Common pain points include:
All of them lead to poor answer quality and hinder the model's overall performance.
In response, we reimagined RAG in Dify as an open and modular architecture, enabling developers, integrators, and domain experts to build document processing pipelines tailored to their specific requirements—from data ingestion to chunk storage and retrieval.
🛠️ Core Capabilities
🧩 Knowledge Pipeline Architecture
The Knowledge Pipeline is a visual, node-based orchestration system dedicated to document ingestion. It provides a customizable way to automate complex document processing, enabling fine-grained transformations and bridging raw content with structured, retrievable knowledge. Developers can build workflows step by step, like assembling puzzle pieces, making document handling easier to observe and adjust.
📑 Templates & Pipeline DSL
🔌 Customizable Data Sources & Tools
Each knowledge base can support multiple data sources. You can seamlessly integrate local files, online documents, cloud drives, and web crawlers through a plugin-based ingestion framework. Developers can extend the ecosystem with new data-source plugins, while marketplace processors handle specialized use cases like formulas, spreadsheets, and image parsing — ensuring accurate ingestion and structured representation.
🧾 New Chunking Strategies
In addition to General and Parent-Child modes, the new Q&A Processor plugin supports Q&A structures. This expands coverage for more use cases, balancing retrieval precision with contextual completeness.
🖼️ Image Extraction & Retrieval
Extract images from documents in multiple formats, store them as URLs in the knowledge base, and enable mixed text-image outputs to improve LLM-generated answers.
🧪 Test Run & Debugging Support
Before publishing a pipeline, you can:
This provides safe iteration and debugging at every stage.
🔄 One-Click Migration from Legacy Knowledge Bases
Seamlessly convert existing knowledge bases into the Knowledge Pipeline architecture with a single action, ensuring smooth transition and backward compatibility.
🌟 Why It Matters
The Knowledge Pipeline makes knowledge management more transparent, debuggable, and extensible. It is not the endpoint, but a foundation for future enhancements such as multimodal retrieval, human-in-the-loop collaboration, and enterprise-level data governance. We’re excited to see how you apply it and share your feedback.
⚙️ Queue-based Graph Engine
❓ Why Do We Need It?
Previously, designing workflows with parallel branches often led to:
These issues reduced the usability of complex workflows. To solve this, we redesigned the execution engine around queue scheduling, improving management of parallel tasks.
🛠️ Core Capabilities
📋 Queue Scheduling Model
All tasks enter a unified queue, where the scheduler manages dependencies and order. This reduces errors in parallel execution and makes topology more intuitive.
🎯 Flexible Execution Start Points
Execution can begin at any node, supporting partial runs, resumptions, and subgraph invocations.
🌊 Stream Processing Component
A new ResponseCoordinator handles streaming outputs from multiple nodes, such as token-by-token LLM generation or staged results from long-running tasks.
🕹️ Command Mechanism
With the CommandProcessor, workflows can be paused, resumed, or terminated during execution, enabling external control.
🧩 GraphEngineLayer
A new plugin layer that allows extending engine functionality without modifying core code. It can monitor states, send commands, and support custom monitoring.
Quickstart
1.9.0or higherDEBUG=trueto enable DebugLoggingLayer.WORKFLOW_MAX_EXECUTION_STEPS=500WORKFLOW_MAX_EXECUTION_TIME=1200WORKFLOW_CALL_MAX_DEPTH=10WORKFLOW_MIN_WORKERS=1WORKFLOW_MAX_WORKERS=10WORKFLOW_SCALE_UP_THRESHOLD=3WORKFLOW_SCALE_DOWN_IDLE_TIME=30More Controllable Parallel Branches
Example: Command Mechanism
Note: pause/resume functionality will be supported in future versions.
Example: GraphEngineLayer
GraphEngineLayer Example
FAQ
Is this release focused on performance?
No. The focus is on stability, clarity, and correctness of parallel branches. Performance improvements are a secondary benefit.
What events can be subscribed to?
How can I debug workflow execution?
DEBUG=trueto view detailed logs.Future Plans
This release is just the beginning. Upcoming improvements include:
We look forward to your feedback and experiences to make the engine more practical.
Upgrade Guide
Important
After upgrading, you must run the following migration to transform existing datasource credentials. This step is required to ensure compatibility with the new version:
Docker Compose Deployments
tar -cvf volumes-$(date +%s).tgz volumesdocker exec -it docker-api-1 uv run flask transform-datasource-credentialsSource Code Deployments
Stop the API server, Worker, and Web frontend Server.
Get the latest code from the release branch:
cd api uv syncImportant
If you are currently using version
v2.0.0-beta.1orv2.0.0-beta.2, you must run the following migration script to upgrade.[WARNING] This is a destructive operation that will result in data loss.
This migration script will permanently delete the following data:
Please ensure you have backed up any necessary information before proceeding.
What's Changed
load_streammethod by @bowenliang123 in chore: improve opendal storage and ensure closing file after reading files inload_streammethod #25874datasource.utilsby @hyongtao-code in Chore: remove dead code indatasource.utils#25984New Contributors
Full Changelog: 1.8.1...1.9.0
All reactions