Multi-Hop Query Plan Repair Prompt After Retrieval Failure

This prompt is designed for production Retrieval-Augmented Generation (RAG) systems that execute multi-hop query plans and require automatic, in-process recovery when a retrieval step fails. A 'hop' is considered failed when it returns zero results, results that fall below a configurable relevance threshold, or results that lack the specific entities or facts needed to construct the subsequent query in the chain. The core job-to-be-done is to prevent a full pipeline failure by programmatically repairing the broken segment of the query plan, allowing the system to self-correct without immediately escalating to a human operator or returning a generic 'I don't know' response. The ideal user is an AI engineer or RAG architect embedding this prompt into a retry controller within a larger agentic or pipeline architecture.

This prompt must be used inside a strict retry loop with a maximum repair attempt limit (e.g., 2-3 attempts) to prevent infinite loops. It takes the original user question, the full failed query plan, the index of the failed hop, and the retrieved results (if any) as input. It outputs a repaired plan segment with alternative queries or a revised dependency path. This prompt is not a substitute for initial query plan generation; it must be paired with an upstream 'Multi-Hop Query Chain Generation Prompt'. It is also not designed to handle ambiguous or unanswerable user questions; those cases should be triaged and refused by an upstream intent classifier or a 'Query Disambiguation and Ambiguity Resolution Prompt' before a query plan is ever generated. Using this prompt on a fundamentally broken question will result in plausible but incorrect query repairs that silently change the user's intent.

Before integrating this prompt, ensure your retrieval pipeline emits structured failure signals, including the hop index, the query that was executed, the result count, and a relevance score. The repair prompt's effectiveness is directly tied to the quality of this failure context. A common failure mode is the repair prompt generating a query that is semantically similar to the original failed query but does not resolve the underlying dependency gap, leading to a second failure on the same hop. To mitigate this, the harness should validate that the repaired query is structurally different from the failed query (e.g., using a simple lexical overlap check) before execution. Proceed by wiring this prompt into your retry controller and pairing it with a 'Dependency Graph Validation Prompt' to pre-check the repaired plan segment for logical consistency before re-executing the retrieval.

This prompt template is designed to be inserted into your system prompt or as a user message in a tool-calling loop. It receives the original query plan, the specific hop that failed, the empty or irrelevant results, and any evidence gathered from prior successful hops. The model's job is to generate a repaired segment—alternative queries or a revised dependency path—that recovers the retrieval chain without silently altering the user's original intent. The output contract is a strict JSON schema so that downstream orchestration code can parse the repair and inject it back into the execution plan.

textCopy
You are a retrieval plan repair agent. Your task is to fix a failed hop in a multi-hop query plan.

# INPUT
- Original User Question: [USER_QUESTION]
- Full Query Plan (JSON): [QUERY_PLAN]
- Failed Hop ID: [FAILED_HOP_ID]
- Failed Query Text: [FAILED_QUERY]
- Retrieval Results for Failed Hop: [FAILED_RESULTS]
- Evidence from Prior Successful Hops: [PRIOR_EVIDENCE]
- Failure Reason (empty_results | irrelevance | other): [FAILURE_REASON]

# CONSTRAINTS
1. Do not change the user's original intent or the ultimate question being answered.
2. The repaired hop must produce information that the subsequent dependent hops can use. Preserve the dependency contract.
3. If the failure reason is "empty_results," generate broader, synonym-expanded, or structurally relaxed queries.
4. If the failure reason is "irrelevance," generate queries with tighter entity constraints, explicit date ranges, or domain-specific terminology drawn from prior evidence.
5. You may propose splitting one failed hop into two sequential sub-hops if a single query cannot bridge the gap.
6. You may propose a new bridge entity if the original bridge entity was not found.
7. If no plausible repair exists, set `repairable` to false and provide a clear reason.

# OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "repairable": boolean,
  "repair_strategy": "broaden" | "tighten" | "split" | "replace_bridge_entity" | "none",
  "repaired_plan_segment": [
    {
      "hop_id": "string (new or reused)",
      "query": "string",
      "target_index": "string (optional)",
      "expected_output_type": "string",
      "depends_on": ["hop_id"]
    }
  ],
  "rationale": "string explaining why this repair should resolve the failure",
  "fallback_escalation": "string (if repairable is false, describe what human or alternative workflow is needed)"
}

To adapt this template, replace the square-bracket placeholders with values from your orchestration layer. The QUERY_PLAN should be the full JSON plan object, not a summary, so the model can reason about dependencies. The PRIOR_EVIDENCE field should contain structured outputs from earlier hops—entities, facts, and source spans—not raw document chunks. For tool-calling setups, wrap the output schema in a function definition and set tool_choice to "required" to guarantee structured output. Before deploying, run this prompt against a golden set of known plan failures and validate that repairable is correctly set and that repaired queries do not drift from the original question's intent. In high-stakes domains, route repairable: false responses to a human review queue rather than silently halting the pipeline.

The repair prompt is not a standalone component; it is a recovery stage inside a multi-hop RAG execution loop. When a hop in the query chain returns zero results, a low-confidence answer, or a retrieval score below a configured threshold, the orchestrator should invoke this prompt with the failed query, the original user question, the evidence collected so far, and the dependency graph. The orchestrator must treat the repair output as a replacement segment of the query plan, not a full replan, to avoid unnecessary latency and cost. The repair prompt's job is to generate alternative queries or revised dependency paths for the specific failed hop while preserving the intent of the original question.

Wire the prompt into an execution harness that enforces a strict contract. The harness should: (1) extract the failed hop's position in the dependency graph; (2) assemble the [FAILED_QUERY], [ORIGINAL_QUESTION], [COLLECTED_EVIDENCE], and [DEPENDENCY_GRAPH] inputs; (3) call the repair prompt with a timeout and a maximum token budget; (4) validate the output against a JSON schema that requires replacement_queries (array of query objects with query_text, target_hop_index, and rationale), intent_preservation_check (boolean), and fallback_strategy (string enum: retry, skip_hop, escalate). If validation fails, retry once with a stricter prompt that includes the schema violation error. If the second attempt fails, log the failure and escalate to the fallback_strategy path. Never silently accept a repair that changes the question's intent—the intent_preservation_check field must be true for the repair to proceed automatically.

Observability is critical because repair loops can mask retrieval quality problems. Log every repair invocation with: the failed query, the generated alternatives, the validator result, the retry count, and whether the repair succeeded in the subsequent retrieval attempt. Emit a metric for repair_rate (fraction of hops that trigger repair) and repair_success_rate (fraction of repairs that produce usable results). Set an alert if repair_rate exceeds 20% of hops or if repair_success_rate drops below 50%, as this indicates systemic retrieval or planning issues. For high-stakes domains, route all repairs where fallback_strategy is escalate to a human review queue with the full trace attached. The repair prompt is a safety net, not a substitute for a well-tuned retrieval pipeline—use the observability data to fix the root cause, not just to patch failures.