界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
文档与办公 · SKILL.md

rag-debugger

rag-debugger

【文档与办公】Use when a RAG system is returning bad answers — hallucinations, wrong content, missing exact terms, low recall, slow responses, stale data, citation errors, tenant data leakage, or any production retrieval failure. Walks the 9-layer diagnostic chain backward from output to root cause. Triggers on phrases like "RAG returning wrong answers", "hallucin…

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

name: rag-debugger description: Use when a RAG system is returning bad answers — hallucinations, wrong content, missing exact terms, low recall, slow responses, stale data, citation errors, tenant data leakage, or any production retrieval failure. Walks the 9-layer diagnostic chain backward from output to root cause. Triggers on phrases like "RAG returning wrong answers", "hallucinating", "can't find document", "wrong tenant data", "low recall", "RAG is slow", "missing citations".

RAG Failure Diagnosis

When a RAG answer is wrong, walk the layers backward from output to root cause. Most "the LLM hallucinated" reports are actually upstream failures that surface at generation.

Critical principle: don't fix downstream when upstream is broken. Tuning the reranker won't help if the parser dropped the table.

The diagnostic chain

For any wrong answer, walk in this order. The first layer where you find a problem is your root cause — stop walking there.

Wrong answer
  │
  ├─ Layer 9: LLM generation
  │     Did the LLM ignore evidence it had?
  │     check: was the correct chunk in the context window?
  │
  ├─ Layer 8: Context packing
  │     Did the right chunk reach the LLM?
  │     check: was it retrieved but dropped before packing?
  │
  ├─ Layer 7: Reranker
  │     Did rerank bury the right chunk?
  │     check: was the right chunk in pre-rerank candidates but not top-k?
  │
  ├─ Layer 6: Fusion (RRF)
  │     Did fusion lose a strong single-retriever hit?
  │     check: was it top-3 in BM25 or dense alone but buried after RRF?
  │
  ├─ Layer 5: Retrieval (dense)
  │     Did dense find the right chunk?
  │     check: similarity score; close to top hits?
  │
  ├─ Layer 4: Retrieval (sparse / BM25)
  │     Did BM25 find the right chunk?
  │     check: does the chunk contain query terms? Stop-words eating query?
  │
  ├─ Layer 3: Filtering
  │     Did filters wrongly exclude the right chunk?
  │     check: replay query without filters; does it appear?
  │
  ├─ Layer 2: Chunking
  │     Was the answer split across chunk boundaries?
  │     check: does the answer text exist in any single chunk?
  │
  └─ Layer 1: Parsing / Ingestion
        Was the source content captured at all?
        check: does the raw document contain the answer?

Failure modes by layer

LayerSymptomLikely causeFix direction
1 ParsingAnswer not in any chunk; raw doc has itParser dropped table, lost footer, OCR failedBetter parser (Unstructured.io / LlamaParse), OCR quality gates, chunk quality scoring
1 IngestionDocument not indexedFailed job, deletion bug, tombstoneAudit ingestion logs, idempotency check
2 ChunkingCondition separated from ruleFixed-size split mid-statementDocument-aware chunking, parent-child, overlap
2 ChunkingTable broken across chunksNaive splitter cut the tableAdaptive chunking, preserve tables whole
3 FilteringRight chunk filtered outMetadata mismatch, tenant filter too aggressive, version filterAudit filter logic; check effective_to / version
3 FilteringPost-filter killed recallTop-k all filtered after retrievalSwitch to pre-filtered ANN
4 SparseExact term not matchedTokenizer issue, stop-words too aggressiveCheck tokenization; rebuild with correct analyzer
5 DenseParaphrase not matchedDomain-weak embedder, chunk size wrongTest domain embedder; adjust chunk size
5 DenseProper noun missedModel never saw the proper nounHybrid (BM25 catches it)
6 FusionStrong hit buriedOne retriever had 1 great hit, other had 50 mediocreInspect rank-by-rank; consider weighted RRF
7 RerankerWrong chunk preferredReranker mismatched to domainTry different reranker; eval on labeled pairs
7 RerankerLength biasLong irrelevant beat short relevantLength normalization; switch reranker
8 PackingRight chunk droppedAggressive top-k, dedup removed unique answerLoosen top-k; smarter dedup
8 PackingLost in the middleRight chunk at end of long contextMove highest-scored first
9 GenerationLLM ignored evidenceWeak grounding prompt; model priorsStrict grounding; structured output; abstention threshold
9 GenerationHallucinated citationCitation present, chunk doesn't support claimPer-claim citation checking; answer contract validation

Common failure patterns (signature → layer)

PatternSignatureLikely layer
Plausible but wrongCoherent answer, no citation matches9 or 8
"I don't know" when answer existsRight chunk never retrieved4–6
Outdated answerNewer version exists, old retrieved3 (version filter) or 5 (no freshness signal)
Wrong tenant dataInfo from another customer3 — security incident, page someone
Repeated / redundantSame content cited multiple times8 (no dedup)
Right facts, wrong combinationEach fact cited, combination invented9 or 2 (lost connector across chunks)

How to apply

When the user reports a RAG failure:

  1. Get the trace. Ask for: query, classification (if any), filters applied, all retriever outputs with scores, RRF result, rerank result, context sent to LLM, LLM response. If they don't have this — that's the first problem to fix (audit logs per §39.2).

  2. Check Layer 1 first. Does the answer exist in any chunk? If no, stop. Nothing downstream matters. Recommend parser / ingestion fixes.

  3. Walk forward layer by layer. At each layer, ask: was the right chunk present? The first layer where it disappears is the root cause.

  4. Match against common patterns — they short-circuit the walk.

  5. For tenant data leakage: page immediately. Pre-filter chokepoint is broken; this is a security incident, not a quality issue.

Anti-patterns to watch for

  • "It's just hallucinating, raise the temperature lower" → almost never the answer; check upstream first
  • "Add more chunks to context" → if retrieval is wrong, more wrong chunks won't help
  • "Try a bigger model" → bigger model with same broken retrieval is still broken
  • "Tune the reranker" before checking that the right chunk is in the candidate pool

Reference: full playbook §40 (failure taxonomy), §39.2 (audit log schema).

我的收藏