Parallel RAG Workflow
Use this Skill only after the Manage stage selects it. Keep retrieval, reranking, rewriting, and generation implementations outside the workflow script.
Component selection
- Optionally select one
rewriterComponent when rewriting or decomposing the query improves recall. When norewriteris bound, every branch starts from the original query. - Select two to four distinct
retrieverComponents. Prefer diversity, such as BM25 plus Vector Retrieval. - Optionally select one
rerankerComponent; it is applied independently to each retrieval branch before fusion. - Select exactly one
generatorComponent. - Load only the selected Component Skill bodies and implementations.
Rewriter interface
A rewriter Component must provide the rewriter capability:
- Input
RewriteRequest:query, optionaltemperature, optionalmax_tokens - Output
RewriteResult: either a singlerewritten_querystring (HyDE-style) orqueries, a non-empty list of retrieval query strings
Each query becomes a fan-out point for all retrieval branches. The rewriter may reformulate, decompose, or expand the query through the Executor Model; it must not retrieve documents or generate a final answer. When the HyDE Rewriter is selected, bind at least one Vector Retrieval branch and never add the hypothetical document to the retrieved evidence.
Workflow
Execute scripts/workflow.py:run after binding every required slot:
RAGRequest
-> optional rewriter (one or more query views)
-> retrievers in parallel per query view
-> optional per-branch reranker
-> reciprocal rank fusion
-> generator
-> RAGResult
The workflow owns branch fan-out, reranking order, and fusion. Each retriever owns only its concrete retrieval algorithm.