[Feature Request]: Native Query Decomposition Integration in Retrieval Component

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).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

Is your feature request related to a problem?

Describe the feature you'd like

Problem Statement: Complexity and Performance Overhead of Current Query Decomposition Implementations

To achieve complex query decomposition and multi-step retrieval, users currently face two suboptimal approaches:

1. Workflow-based Approach:

   • High Complexity: Users must manually assemble multiple components (LLM, loop, retriever) and carefully design their connections and data flow logic. This process is cumbersome, error-prone, and requires significant technical expertise.
   • Redundant Overhead: Each retrieval round requires independent serialization, deserialization, and network calls, introducing unnecessary latency and resource consumption.

2. Agent-based Approach:

   • Slow Performance: The agent's decision-making process involves multiple LLM calls (thinking, tool selection, execution, output parsing), making it inherently too slow for production scenarios requiring high responsiveness.
   • Unpredictability: Agent behavior can be unstable, potentially leading to excessive retrieval rounds or loops, resulting in poor controllability.

Core Value Proposition

We propose integrating a powerful and efficient native Query Decomposition feature directly into the core Retrieval component. This offers two key benefits:

• Simplified User Experience: Users no longer need to be "workflow engineers." They can simply provide a decomposition prompt (or use high-quality built-in defaults) to access powerful multi-step retrieval capabilities. This dramatically lowers the barrier to using advanced retrieval features.
• Enhanced Performance & Efficiency: Tight internal integration eliminates inter-component communication overhead and enables global chunk deduplication and ranking across sub-queries. This delivers faster performance and better final results compared to external assembly approaches.

Feature Specification & Design - A new query decomposition retrieval component

1. User Configuration Interface

• Enable Toggle

  • A clear checkbox, e.g., "Enable Query Decomposition & Reranking", to toggle the entire advanced retrieval pipeline on or off.

• Decomposition Prompt

  • An editable text input field allowing users to provide a custom prompt instructing the LLM on how to decompose complex queries. The system should provide a high-quality, validated default prompt to help beginners get started quickly.
  • Default Prompt Example:

    You are a query decomposition expert. Please break down the following complex question into 2 to 3 simpler, independently retrievable sub-questions. Ensure the sub-questions cover all key aspects of the original query and are non-redundant.
    Original Query: {original_query}
    Output Requirement: Output ONLY a standard JSON array where each element is a string representing a sub-question. Example: ["sub-question 1", "sub-question 2"]. Do not output any other explanatory text.

• Reranking & Weighting Settings

  • This section is the core of the new capability, configuring the final quality assessment and sorting of retrieved chunks.
  • Reranking Prompt: An editable text input field used to guide the LLM in judging the contextual relevance and informational usefulness of a single chunk.
    • Default Prompt Example:

      You are an information relevance assessment expert. Please judge the usefulness of the provided 'Contextual Document Chunk' for answering the 'Query'.
      Query: {query_or_subquery}
      Contextual Document Chunk: {chunk_text}
      Assessment Task:

      1. Relevance Score: Provide an integer score from 1 to 10 based on whether the chunk contains a direct answer, indirect clues, or is completely irrelevant.
      2. Brief Justification: State the core reason for the score in one sentence.
         Output Requirement: Output strictly in JSON format: {"score": score, "reason": "justification"}.

  • Score Fusion Weight: A slider or number input field allowing users to set the weight of the Semantic Similarity Score and the LLM Reranking Score in the final aggregate score.
    • For example, setting it to 0.7 means: Final Score = 0.7 * LLM Reranking Score + 0.3 * Vector Similarity Score. This provides flexibility for users to adjust the ranking strategy based on scenario preferences (trusting model understanding more vs. vector matching).

• Advanced Settings

  • Max Decomposition Count: A number input field limiting the maximum number of generated sub-queries to prevent over-decomposition (Default: 3).
  • Concurrency Control: A toggle switch to control whether the retrieval and reranking processes for all sub-queries are executed concurrently, maximizing performance.

**2. Internal Execution Engine **

1. Query Decomposition: Internally calls the LLM to split the original query into a set of sub-queries based on the "Decomposition Prompt".
2. Concurrent Retrieval: The system performs vector retrieval for all sub-queries concurrently, fetching the Top-K candidate chunks for each.
3. Global Reranking & Deduplication (Core Enhancement):
   • Deduplication: Performs initial deduplication of candidate chunks returned from all sub-queries based on Chunk ID.
   • LLM Reranking & Scoring: For each unique chunk after deduplication, the system uses the "Reranking Prompt" to task the LLM with judging the chunk's usefulness in the context of its corresponding original sub-query, outputting a score.
   • Score Fusion: The system calculates a final composite score for each chunk by performing a weighted average of its Vector Similarity Score (from Step 2) and its LLM Reranking Score, using the user-configured "Score Fusion Weight".
   • Global Sorting: All unique chunks are sorted in descending order based on this Composite Score, generating the final, optimized candidate list.

Comparative Advantages

Feature	Current Flow Approach	Current Agent Approach	This Proposal (Built-in Decomposition)
Setup Complexity	High (multiple components)	Medium (tools definition)	Low (one-click enable, prompt config)
Response Latency	Medium (serialization & loop overhead)	High (multi-step decision overhead)	Low (internal concurrency, minimal overhead)
Result Quality	Depends on flow design	Unstable, potentially redundant	High (global deduplication & reranking)
Control & Determinism	High	Low	High (explicit step and prompt control)

Summary

This feature transforms query decomposition from an "architectural pattern" into a first-class citizen of the retrieval component. It directly addresses the core pain points of current implementations, delivering both improved developer experience and tangible gains in performance and effectiveness through simplified configuration and an optimized execution path. This will make RAGflow more robust and user-friendly when handling complex, multi-faceted queries.

Describe implementation you've considered

No response

Documentation, adoption, use case

Additional information

No response