123 lines
6.5 KiB
Markdown
123 lines
6.5 KiB
Markdown
# 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, `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. **`rag_retrieve`**
|
|
|
|
- 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:` 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. For `rag_retrieve`, escalate `top_k` to `100` on retry.
|
|
|
|
- Say "no relevant information was found" **only after** exhausting all retries.
|
|
- Do NOT switch to local filesystem inspection at any point.
|
|
- Do NOT call any retrieval tool more than 3 times in total.
|
|
|
|
## 7. 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.
|
|
|
|
## 8. 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.
|
|
- 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.
|
|
|
|
## 9. 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)?
|
|
- 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.
|