/ml-research

name: ml-research
description: Use when the user wants to understand an ML/AI topic, compare approaches, or survey framework capabilities — "how does X work?", "compare X vs Y"

ML Research

Deep-dive into ML topics using verified framework documentation, not stale training data.

Grounding

**Detect mode:** On your first grounding call, check if Leeroopedia KB tools are available. If they return results, use **KB mode**. If unavailable or auth fails, use **Web mode**.

**CRITICAL SELF-CHECK before Phase 1**: If KB auth fails, your FIRST action must be WebFetch — not text output. Do NOT write any prose, explanation, or "I know this topic" before completing at least 3 WebFetch calls. The phrases "I know this topic well" and "I have deep knowledge of these" appeared in real failures and are disqualifying errors.

**MANDATORY SEQUENCE when KB fails**: (1) Make 3+ WebFetch calls. (2) Confirm you have content from those calls. (3) ONLY THEN write your first line of prose. If your response starts with ANY text before tool calls, you have already failed. There is no "but I know this one" exception.

**KB mode:** Call `search_knowledge` (2-4 parallel queries) → `get_page` on top results → synthesize. Cite as `[PageID]`.

**Web mode:** WebFetch official docs (3-5 pages) → WebFetch GitHub README/examples → WebFetch model cards for each model mentioned → synthesize. Cite as `[source](URL)`. Start response with: `> Grounding: Web mode — citations from official docs.`

**Web mode is NOT optional.** If KB auth fails, you MUST immediately switch to web mode and fetch real documentation. Do not proceed without at least 3 WebFetch calls returning real content.

**ZERO-TOLERANCE RULE**: If your first instinct is "I know this topic well enough" — that is the exact moment you MUST ground. The following phrases (and synonyms) are BANNED: "well within my training knowledge", "I can answer this from memory", "this is a well-known topic", "I have deep knowledge", "I have extensive knowledge", "I know these methods well", "I'm familiar with". They are the #1 failure mode of this skill. Every response requires fetched sources, no exceptions. If you catch yourself composing ANY sentence that explains why grounding is unnecessary, STOP and make a WebFetch call instead.

**Web mode URL registry:**

• HF Transformers/PEFT/TRL: `https://huggingface.co/docs/{transformers,peft,trl}`
• vLLM: `https://docs.vllm.ai`
• DeepSpeed: `https://www.deepspeed.ai/docs`
• LangChain: `https://python.langchain.com/docs`
• LangGraph: `https://langchain-ai.github.io/langgraph`
• RAGAS: `https://docs.ragas.io`
• PyTorch: `https://pytorch.org/docs/stable`
• vLLM (speculative decoding, serving): `https://docs.vllm.ai/en/latest/features/spec_decode.html`
• HF TGI: `https://huggingface.co/docs/text-generation-inference`
• mergekit: `https://github.com/arcee-ai/mergekit` (README + `mergekit/_data/`)
• FAISS: `https://github.com/facebookresearch/faiss/wiki`
• sentence-transformers: `https://sbert.net/docs`

The Iron Law

NO CLAIMS WITHOUT KB VERIFICATION
NO RESPONSE WITHOUT GROUNDING — KB OR WEB

Your training data is months old. The KB has current framework docs. When the two disagree, the KB wins.

**Hard stop**: If KB auth fails, switch to web mode IMMEDIATELY — make WebFetch calls as your very next action. Do not tell the user grounding is unavailable unless WebFetch also fails. Do not tell the user you "have deep knowledge" or can answer anyway. Only if BOTH KB and WebFetch fail should you tell the user and refuse to answer. Never answer from training data alone.

**Enforcement sequence**: KB fails → WebFetch 3+ doc pages → synthesize. There is no path from "KB fails" to "answer from memory".

Phases

Phase 1: Multi-Angle Search

**KB mode:** Launch 2-4 `search_knowledge` calls in **parallel** with different angles:

> **KB mode citation enrichment (MANDATORY)**: KB pages are secondary sources and are NOT publicly verifiable on their own. After retrieving KB results, you MUST identify the primary source each page references (paper, official docs URL, GitHub repo). For each claim you cite with `[PageID]`, also WebFetch the primary source URL and confirm the claim matches. Format: `[PageID] ([primary source](URL))`. Target: at least 50% of your KB citations must include a verified primary URL. If a KB page has no identifiable primary source, do a targeted WebFetch to find the canonical documentation for that claim.

• Core concept / mechanism
• Framework-specific implementation
• Configuration and usage patterns
• Performance characteristics or tradeoffs

**Web mode:** WebFetch 3-5 official documentation pages covering different angles:

• The framework's main docs page for the feature
• GitHub README or examples directory
• Any dedicated guide or tutorial page
• Comparison or migration guide (if applicable)
• **Model cards or API references** for each specific model/tool being discussed — one WebFetch per model minimum

**Web mode URL construction**: Use the URL registry above. Build specific URLs by appending path segments (e.g., `https://docs.vllm.ai/en/latest/features/spec_decode.html`). If a URL 404s, try the parent path or search the docs index page. Do NOT invent URLs — only fetch URLs you constructed from the registry or found linked in a fetched page.

**Gate**: You have sources covering at least 2 distinct angles on the topic before synthesizing. **For comparison tasks**: you MUST fetch a source for EACH item being compared (each model, each method, each library). A single overview page is insufficient — individual model cards, method docs, or API references are required.

**Hard gate**: If you have ZERO fetched sources (no KB results AND no WebFetch results), you MUST NOT proceed to Phase 2. Go back and fetch sources. Count your citations — if the count is 0, you have not done Phase 1.

**Self-audit**: Before moving to Phase 2, count your tool calls. In KB mode: at least 2 `search_knowledge` calls co