rag

name	rag
description	Query HKU degree-plan and employment data using rag_query plus grep over data/content.
always	true

RAG Document Search

Always use these local tools before searching online for anything about HKU programmes or graduate employment data.

Tools

• rag_query — semantic + knowledge-graph retrieval. Use this to identify candidate files, sections, entity aliases, and terminology when the question is open-ended, fuzzy, alias-heavy, or requires cross-document scoping. It is a scoping tool, not an exact counter.
• grep with path="data/content" — literal text search. Use this first for exact values: course codes, credit counts, salary figures, verbatim policy text, exact employer names, and obvious field labels. Set output_mode='content' to see matching lines; fixed_strings=true for verbatim quotes.

Use path="data/content/<subdir>" to narrow grep to a specific folder. For markdown-only searches, add type="md". When browsing files, start from data/content and identify the relevant programme/year directories first. Only narrow into subfolders such as hybrid_auto after scoping the target directory; do not jump directly to data/content/*/*/hybrid_auto/*.md as the first discovery step.

To calibrate top_k for rag_query, check corpus size first with grep(output_mode="count", pattern=".", path="data/content", glob="*.md") and scale accordingly.

How to write rag_query queries

Treat the rag_query string as a retrieval query, not a task instruction.

• Prefer corpus-facing terms: exact field labels, headings, employer names, programme names, degree names, section titles, aliases, and years.
• Prefer English corpus vocabulary when the source documents are mostly English.
• Keep the query short and keyword-rich; noun phrases beat full instructions.
• Include likely table/header variants together when useful, e.g. mean salary average monthly salary gross income basic salary.
• For cross-year or cross-programme work, let rag_query scope the files/aliases first; do not ask it to "rank", "compare", or "calculate" in the query string.
• Remove workflow phrasing such as 先找出, 再判断, 不要直接, 总结, first, then, summarize, rank, compute.
• For graduate employment evidence, do not stop at a single year unless the user explicitly asks for that year only. When the user asks about a programme trend, comparison, explanation, or “why” question, actively look across multiple relevant years before concluding.
• If only one year has been checked so far, mark the finding as provisional and continue searching nearby/relevant years to reduce sample bias.

Good:

• graduate employment mean salary average monthly salary gross income programme year
• BEng(CompSc) investment bank employer Goldman Sachs Morgan Stanley JP Morgan 2022 2023
• basic salary and gross income table average monthly salary graduate employment

Bad:

• 先找出所有提到平均薪资的项目和年份，再判断哪些文件最值得继续精读
• Tell me which programme ranks highest by average salary across all years

Step 1 — Classify the query (easy vs. hard)

Before retrieving anything, decide whether the question is easy or hard.

Also decide whether it is exact or fuzzy:

• Exact: the user already gave likely corpus terms, labels, names, years, or keywords. Start with grep.
• Fuzzy: the user is asking about themes, aliases, related concepts, or likely locations in the corpus. Start with rag_query.

Easy: the answer can be produced from a small number of directly retrieved passages. Examples: "What are the credit requirements for COMP3234?", "Which investment banks appeared in 2023?"

Hard: the answer requires collecting and aggregating evidence across many independent slices — years, degrees, or entity categories. Examples: "How many CS graduates entered investment banks each year 2017–2023?", "What is the maximum salary per degree 2017–2023?"

If cross-slice counting, comparison, or trend assembly is required, treat the question as hard.

Step 2 — Retrieval strategy

Easy question:

1. Use grep for exact-match lookups, field labels, and obvious literal searches; use rag_query for open-ended entity discovery.
2. Verify with targeted follow-up if needed.
3. If the question is about graduate employment patterns or explanations, sanity-check whether more than one year should be inspected before answering.
4. Answer directly.

Hard question:

1. If the hard question is also fuzzy, call rag_query once with a broad scoping query to identify: relevant years, degree names, file paths, section headings, entity aliases.
2. If the hard question is exact or table-driven, start with grep/read_file and move to code quickly; do not force a rag_query first.
3. rag_query output is for scoping only — do not read its numbers as exact counts or final answers.
4. Use the scoping result to narrow subsequent grep / read_file calls to specific candidates.
5. Do not open-endedly scan the whole corpus with grep or exec when a single scoping rag_query would clearly narrow the search space first.
6. For aggregations too large for manual reading, consider writing and running code over the narrowed candidate files instead of reasoning from retrieval alone.

Step 3 — Optional subagents for independent slices

After scoping a hard question, decide whether subagents are needed. For multi-file or multi-group tasks, consider using a subagent when the work can be split into independent slices. Launch subagents only when:

• the question is hard, AND
• the slices are truly independent and have little dependency on each other

Do not launch subagents for easy questions. Do not launch subagents when slices are not independent.

Each subagent task must specify:

• the original user question
• one assigned slice only (a single independent partition)
• the candidate files / sections / aliases from the parent's scoping result
• the subagent must produce explicit evidence for that slice only — NOT a global summary

If an assigned slice is still too large but remains separable, the subagent may further split it into smaller independent sub-slices. Keep delegation bounded and preserve explicit evidence chains from child slices back to parent slice outputs.

Step 4 — Assemble evidence before answering hard questions

For any hard question, build this compact evidence table before producing the final answer:

slice_key	matched entities	normalized label	count / value	source	status

Status must be: ok (fully verified), partial (some gaps), or failed (could not verify).

Charts and numeric totals must come from this evidence table — not from narrative inference or rag_query output alone.

Step 5 — Final answer

Easy questions: answer directly.

Hard questions:

• Lead with the grounded result.
• Claim only what is supported by the evidence table.
• For graduate employment conclusions, prefer evidence spanning multiple years; if only one year was available or checked, say so explicitly.
• If any slice has status partial or failed, explicitly state the result is incomplete and identify the missing slices.
• Do not add macro-level narrative explanations unless separately supported by retrieved evidence.
• Output this status line on its own line immediately before the answer text: [hard-query: subagents=yes|no, answer=complete|partial]

Images

Images in parsed markdown (e.g. ![](images/abc.jpg)) are relative to the markdown file's directory inside hybrid_auto/. Load with read_file for visual analysis.