Retrieval Pipeline Configuration Prompt for Query Generation

This prompt is for platform engineers and RAG architects who need to programmatically configure a multi-stage retrieval pipeline. Instead of manually wiring rewriters, expanders, and backend-specific query formatters for every query type, this prompt takes a user query and a registry of available retrieval components and produces a complete, executable configuration. Use this when you are building a retrieval orchestration layer that must dynamically assemble the right sequence of query transformations based on the query's intent, complexity, and the capabilities of your available indexes. This is not a prompt for rewriting a single query; it is a meta-configuration prompt that generates the plan for how a query should be processed.

The ideal user is an infrastructure engineer who already has a catalog of retrieval components—such as a dense vector rewriter, a BM25 keyword expander, a metadata filter extractor, and a graph traversal constructor—each with a known interface and capability description. The prompt requires a structured [COMPONENT_REGISTRY] that defines each component's name, input/output contract, and constraints. The output is a [PIPELINE_CONFIG] object that specifies the ordered sequence of components to invoke, the arguments to pass between them, and the final backend targets. This configuration should be directly executable by your orchestration engine without manual intervention.

Do not use this prompt when you have a single, static retrieval backend or when the query transformation logic is simple enough to be hardcoded. If your system only ever performs dense vector search with a single rewriter, a meta-configuration prompt adds unnecessary latency and complexity. Similarly, avoid this prompt for real-time, latency-critical paths where dynamic planning overhead is unacceptable; instead, precompute pipeline templates for known query classes. Finally, this prompt is not a substitute for a proper feature store or A/B testing framework—use it to generate candidate configurations, but always validate pipeline effectiveness against your retrieval metrics before promoting to production.

This prompt template is designed to be pasted directly into your orchestration layer. It instructs the model to act as a retrieval pipeline architect, producing a structured configuration object that maps a user's query type to a specific set of rewriters, expanders, and target backends. The output is not a rewritten query, but a machine-readable plan for your retrieval dispatcher. Replace the square-bracket placeholders with your system's available components, constraints, and the specific user query you need to configure a pipeline for.

textCopy
You are a retrieval pipeline configuration engine. Your task is to analyze a user query and produce a complete query generation configuration. This configuration specifies the exact sequence of rewriters, expanders, and target retrieval backends to invoke for this specific query type.

## Available Components
- Rewriters: [AVAILABLE_REWRITERS]
- Expanders: [AVAILABLE_EXPANDERS]
- Backends: [AVAILABLE_BACKENDS]

## System Constraints
- Maximum pipeline stages: [MAX_STAGES]
- Latency budget: [LATENCY_BUDGET_MS]
- Required backends for all queries: [REQUIRED_BACKENDS]
- Forbidden components for this context: [FORBIDDEN_COMPONENTS]

## User Query
[USER_QUERY]

## Output Schema
Return a valid JSON object with the following structure:
{
  "query_type": "string (classification of the query: factual, comparative, procedural, multi-hop, etc.)",
  "pipeline_stages": [
    {
      "stage": "integer (execution order, starting from 1)",
      "component": "string (name of the rewriter, expander, or backend from the available lists)",
      "action": "rewrite | expand | retrieve",
      "target_backend": "string | null (required if action is 'retrieve')",
      "instructions": "string (brief, specific instruction for this stage's execution)"
    }
  ],
  "parallel_groups": [
    ["integer (stage numbers that can run in parallel)"]
  ],
  "fallback_strategy": "string (description of what to do if primary retrieval returns zero results)",
  "rationale": "string (brief explanation of why this configuration was chosen for this query type)"
}

## Constraints
- Do not include components not listed in the available lists.
- Respect the maximum pipeline stages limit.
- Ensure all 'retrieve' actions specify a valid target_backend.
- If the query is ambiguous, include a disambiguation rewriter as the first stage.
- For multi-hop queries, ensure stages are ordered to resolve dependencies.

To adapt this template for your system, populate the [AVAILABLE_REWRITERS], [AVAILABLE_EXPANDERS], and [AVAILABLE_BACKENDS] placeholders with the exact names of the components registered in your retrieval dispatch layer. The model will only select from these lists, preventing hallucinated components. The [MAX_STAGES] and [LATENCY_BUDGET_MS] constraints enforce your production limits. After receiving the configuration, your application should validate the JSON against the output schema, confirm that all specified components exist in your registry, and reject any plan that references forbidden components or exceeds stage limits. For high-stakes pipelines, log the generated configuration alongside the query for auditability before execution.

This prompt is designed to be called programmatically as part of a query planning service that sits between user input and your retrieval backends. The service receives a user query, classifies its type, and invokes this prompt to produce a complete pipeline configuration specifying which rewriters, expanders, and backends to use. The output is a structured JSON configuration object that downstream orchestrators consume to execute the retrieval pipeline. Wire this prompt into an API endpoint or a message queue consumer that accepts a [USER_QUERY] and an optional [QUERY_TYPE] hint, then returns the configuration to your retrieval dispatch layer.

Validation and Schema Enforcement: The prompt output must conform to a strict schema before any retrieval execution begins. Implement a JSON Schema validator that checks: (1) the pipeline_stages array contains only recognized stage types (rewrite, expand, backend_query), (2) each backend_query stage references a backend ID that exists in your infrastructure registry, (3) all required fields (stage_id, type, config) are present, and (4) dependency references between stages resolve correctly. If validation fails, log the failure with the raw output and the validation error, then retry the prompt once with the error message appended as a [CONSTRAINTS] update. If the retry also fails, fall back to a default pipeline configuration for the detected query type and alert the on-call channel.

Model Choice and Latency Budget: This is a planning prompt that runs once per user query before retrieval execution, so latency directly adds to the user's perceived wait time. Use a fast model with strong JSON output capabilities—GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned smaller model if you have sufficient training data. Set a strict timeout (500-800ms) and implement a circuit breaker: if the prompt exceeds the timeout or fails three times within a rolling window, short-circuit to a cached default configuration for that query type. Log every circuit-breaker activation with the query fingerprint for later analysis.

Observability and Logging: Attach a trace ID to every prompt invocation that propagates through the entire retrieval pipeline. Log the input query, the detected query type, the generated configuration, validation results, and the final backends invoked. This trace allows you to measure configuration accuracy by comparing the generated pipeline against retrieval quality metrics (recall@k, precision@k, answer faithfulness) downstream. Store these traces in your observability platform and build a dashboard that tracks configuration change frequency, validation failure rate, and pipeline latency by query type.

Testing and Evaluation: Before deploying changes to this prompt, run it against a golden dataset of 50-100 queries covering all your supported query types (factual lookup, comparison, summarization, procedural, multi-hop). For each test case, verify that the generated configuration invokes the correct backends and applies appropriate rewriters. Automate this as a CI check that blocks prompt changes if configuration accuracy drops below 90%. Additionally, run periodic shadow evaluations in production where you compare the generated configuration against a human-reviewed ideal configuration to detect drift.

What to Avoid: Do not call this prompt synchronously in the user request path without a timeout and fallback—pipeline planning failures should never block the user from getting results. Do not skip schema validation; malformed configurations will cause cascading failures in downstream orchestrators that are harder to debug. Do not treat this prompt's output as the final retrieval plan without checking that the specified backends are healthy and available at execution time—implement a pre-flight check that removes unavailable backends from the configuration before dispatching.