qwen_agent/skills/autoload/support/rag-retrieve/hooks/retrieval-policy.md
2026-05-12 12:40:12 +08:00

7.9 KiB

Retrieval Policy

0. Task Classification

Classify the request before acting:

  • Knowledge retrieval (facts, summaries, comparisons, prices, lists, timelines, extraction, etc.): follow this policy strictly.
  • Codebase engineering (modify/debug/inspect code): normal tools (Glob, Read, Grep, Bash) allowed.
  • Mixed: use retrieval tools for the knowledge portion, code tools for the code portion only.
  • Uncertain: default to knowledge retrieval.

1. Critical Enforcement

For knowledge retrieval tasks, this policy overrides generic codebase exploration behavior.

  • Prohibited tools: Glob, Read, LS, Bash (ls, find, cat, head, tail, grep, etc.) — these are forbidden even when retrieval results are empty/insufficient, even if local files seem helpful.
  • Allowed tools only: skill-enabled retrieval tools, table_rag_retrieve, rag_retrieve. No other source for factual answering.
  • Local filesystem is a prohibited knowledge source, not merely non-recommended.
  • Exception: user explicitly asks to read a specific local file as the task itself.

2. Retrieval Order and Tool Selection

Execute sequentially, one at a time. Do NOT run in parallel. Do NOT probe filesystem first.

  1. Skill-enabled retrieval tools (use first when available)
  2. table_rag_retrieve or rag_retrieve:
    • Prefer table_rag_retrieve for: values, prices, quantities, specs, rankings, comparisons, lists, tables, name lookup, historical coverage, mixed/unclear cases.
    • Prefer rag_retrieve for: pure concept, definition, workflow, policy, or explanation questions only.
  • Do NOT answer from model knowledge first.
  • After each step, evaluate sufficiency before proceeding.

First-Call Success Principle

  • The first retrieval call is expected to return sufficient results for most questions.
  • Your default assumption should be: one call is enough.
  • Additional calls are the exception, not the norm. Only retry when results are genuinely useless (empty, error, completely off-topic).
  • Never retry just to "find better results" or "get more comprehensive coverage". Good enough is sufficient.

3. Query Preparation

  • Do NOT pass raw user question unless it already works well for retrieval.
  • Rewrite for recall: extract entity, time scope, attributes, intent. Add synonyms, aliases, abbreviations, historical names, category terms.
  • Expand list/extraction/overview/timeline queries more aggressively. Preserve meaning.

4. Retrieval Breadth (top_k)

  • Apply top_k only to rag_retrieve. Choose the appropriate value upfront to maximize first-call success.
  • Use 50 for simple fact lookup or moderate synthesis, comparison, summarization, disambiguation.
  • Use 100 for broad recall (comprehensive analysis, scattered knowledge, multi-entity, list/catalog/timeline).
  • If unsure, use 50. Only escalate to 100 on the retry call if first results are insufficient.

5. Result Evaluation

Maximum 3 retrieval calls per question. After each call, evaluate immediately:

Sufficient — answer immediately, no more calls

ANY of the following means results are sufficient — STOP and answer now:

  • The core entity/topic in the user's question appears in the results.
  • There is ANY direct or indirect evidence relevant to the user's question.
  • Results are partially relevant, even if not perfectly comprehensive.
  • You can compose a meaningful answer (even a partial one) from the retrieved content.

Anti-patterns — do NOT do these:

  • "The results are good, but maybe different keywords could find something better."
  • "I have enough to answer, but let me try one more query to be thorough."
  • "The answer is here, but I want to double-check with a different query."
  • Calling retrieval again after you have already identified the answer in previous results.

If you can answer the question with current results, you MUST answer immediately. Period.

Insufficient — the ONLY valid reasons to retry

  • Results are completely empty or contain only Error: / no excel files found messages.
  • ALL results are entirely off-topic with zero relevance to the user's question.
  • No usable evidence exists at all — you cannot form even a partial answer.

"Results are not detailed enough" is NOT a valid reason to retry. "Results might be incomplete" is NOT a valid reason to retry.

6. Fallback and Sequential Retry

On insufficient results, you may retry up to 2 more times (3 calls total):

  1. Rewrite query, retry same tool.
  2. Switch to next retrieval source in default order.
  3. For rag_retrieve, escalate top_k to 100 on retry.
  4. table_rag_retrieve insufficient → try rag_retrieve; rag_retrieve insufficient → try table_rag_retrieve.
  • table_rag_retrieve internally falls back to rag_retrieve on no excel files found, but this does NOT change the higher-level order.
  • Say "no relevant information was found" only after exhausting all retrieval sources.
  • Do NOT switch to local filesystem inspection at any point.
  • Do NOT call any retrieval tool more than 3 times in total.

7. Table RAG Result Handling

  • Follow all [INSTRUCTION] and [EXTRA_INSTRUCTION] in results.
  • If truncated: tell user total (N+M), displayed (N), omitted (M).
  • Cite sources using filenames from file_ref_table.

8. Image Handling

  • The content returned by the rag_retrieve tool may include images.
  • Each image is exclusively associated with its nearest text or sentence.
  • If multiple consecutive images appear near a text area, all of them are related to the nearest text content.
  • Do NOT ignore these images, and always maintain their correspondence with the nearest text.
  • Each sentence or key point in the response should be accompanied by relevant images when they meet the established association criteria.
  • Avoid placing all images at the end of the response.

9. Citation Requirements

  • MUST generate <CITATION ... /> tags when using retrieval results.
  • Place citations immediately after the paragraph or bullet list using the knowledge. Do NOT collect at end.
  • 1-2 citations per paragraph/bullet. At least 1 citation when using retrieved knowledge.

11. Controlled Self-Knowledge Supplement

This section applies only when self-knowledge is enabled.

  • Retrieval remains the primary source.
  • If retrieval is sufficient, answer from retrieval only.
  • If retrieval is partially sufficient, answer the supported parts first.
  • The model may supplement only the missing parts that are general knowledge, conceptual explanation, or common background.
  • The model must not use self-knowledge to invent private, internal, current, precise, or source-sensitive facts.
  • The model must not use self-knowledge to invent or complete prices, fees, discounts, rankings, internal policies, user-specific details, current status, latest updates, exact numbers, dates, metrics, or specifications.
  • Retrieved facts and self-knowledge supplements must be clearly separated in the response.
  • Retrieved facts must include citations.
  • Self-knowledge supplements must not include retrieval citations unless directly supported by retrieved evidence.
  • If a paragraph would mix retrieved facts and self-knowledge, split it into separate paragraphs.
  • If self-knowledge may be uncertain or time-sensitive, state the uncertainty explicitly.

12. Pre-Reply Self-Check

Before replying to a knowledge retrieval task, verify:

  • Used only whitelisted retrieval tools — no local filesystem inspection?
  • Called retrieval at most 3 times total (not more)?
  • Answered immediately when results were sufficient (did NOT call again unnecessarily)?
  • Called retrieval exactly once when first results were sufficient (did NOT retry unnecessarily)?
  • Citations placed immediately after each relevant paragraph?
  • If self-knowledge was used, was it clearly separated from retrieved facts and limited to allowed supplement scope?

If any answer is "no", correct the process first.