RAG 系统入门

RAG（Retrieval-Augmented Generation）是在推理时检索外部证据，再把获授权、版本正确的内容组装给模型。它解决的是知识访问与证据问题，不会自动解决业务权限、工具副作用、长期记忆或模型行为适配。

---

RAG 在 AI 系统中的位置

Offline path
Sources → Parse → Chunk → Metadata → Embed → Versioned Index

Online path
User + Identity → Query → Permission Filter → Retrieval
                → Context Assembly → Generation
                → Citation Validation → Human/Policy Review

RAG 是 Context Engineering 的一种动态信息来源。System Policy、当前业务状态、Tool Result 和 Memory 仍有各自的来源、权限与生命周期。

---

什么时候应该使用 RAG

---

三个必须先定义的 Contract

1. Ingestion Contract

{
	"document_id": "POL-001",
	"version": "2026-09-08",
	"content_hash": "sha256:...",
	"data_class": "internal",
	"permission_scope": ["care-staff"],
	"parser_version": "...",
	"chunker_version": "...",
	"embedding_contract": "policy-index-v3",
	"status": "active"
}

它回答：来源是谁、能不能用、哪个版本有效、如何更新和删除、失败时是否进入 quarantine。

2. Retrieval Contract

定义 query normalization、query/document embedding compatibility、mandatory filters、top-k、distance/score semantics、timeout、no-result 和 trace。

3. Answer Contract

{
	"answer": "...",
	"claims": [{ "text": "...", "source_ids": ["POL-001#p2#c3"] }],
	"status": "supported",
	"review_required": false
}

status 可以是 supported、partial、conflict 或 no_answer。引用编号必须来自程序提供的 retrieved chunks，不能让模型自己发明。

---

Offline Ingestion Pipeline

source manifest
  → validate permission / format / hash
  → parse or OCR
  → normalize without losing lineage
  → chunk with metadata
  → embed with exact model/config
  → write versioned index
  → completeness and retrieval smoke test

Chunk 不只是 text

每个 chunk 至少保存：

• document_id、document_version、chunk_id；
• page、section、heading path 或 timestamp；
• content_hash 与 source anchor；
• data class 与 permission scope；
• parser、chunker、embedding、index version；
• active/superseded/deleted 状态。

不存在通用的 chunk_size=500。合同、FAQ、表格和代码的边界不同；应该比较 structure-aware、recursive 或其他候选，并用 retrieval dataset 决定。

---

Retrieval Embedding 与 Index Compatibility

Query 与 Document 必须使用兼容的 embedding contract。更换 model、dimension、normalization、query prefix 或 distance function 后，通常需要新索引。

old index ── current traffic
new index ── backfill → verify → shadow query → regression
                         → canary → cutover → rollback window

不能把新旧向量混进同一个空间，也不能把不同模型的 similarity score 直接横向比较。

---

Permission-Aware Retrieval

权限过滤必须发生在把内容交给模型之前：

actor + tenant + purpose
        ↓
mandatory ACL / metadata filter
        ↓
rank only allowed candidates

“先检索全部文档，再在 Prompt 里告诉模型不要泄露”不是访问控制。Filter decision、tenant、policy version 和 candidate IDs 应进入审计记录，但日志不能泄露完整敏感内容。

---

Grounding 与 Citation

Grounding 需要检查“每个 factual claim 是否被 evidence 支持”，而不是回答里是否出现 [1]。

Deterministic check 可以证明 source ID 存在，但“source 是否真的支持 claim”仍需要 rubric、Judge 校准或人工抽检。

---

Failure Taxonomy

只有先定位层级，才知道应该改 parser、chunking、filter、retriever、context assembly 还是 answer contract。

---

Evaluation Dataset

一条可靠 case 至少包含：

case_id: RAG-017
question: '...'
actor_scope: ['care-staff']
reference_document_ids: ['POL-001']
reference_claims: ['...']
expected_status: supported
failure_tags: ['version-sensitive']

Dataset 需要覆盖：

1. 普通相关问题；
2. 关键词相似但业务不相关的 hard negatives；
3. no_answer；
4. superseded 与 conflicting policy；
5. 中文、英文、缩写和拼写变化；
6. tenant、role 和 permission 边界。

检索可按任务选择 Recall@k、MRR、nDCG 或命中率；生成再检查 Faithfulness、Answer Relevancy、citation support 与人工 judgement。指标必须连同 dataset、corpus、model、index 和 filter version 报告。

---

常见错误

---

动手练习

用一组 synthetic policy 完成：

1. source manifest 与版本化 chunks；
2. 一个本地 index；
3. mandatory permission filter；
4. supported、partial、conflict、no-answer 四类输出；
5. 10 条 retrieval cases 和失败分类；
6. 一次文档更新、删除与 index rebuild 演练。

完成证据

• manifest、chunk sample 与 index manifest；
• query trace 与 ranked results；
• claim-source validation；
• dataset 与真实 metric report；
• update/delete/rebuild 结果；
• 已知限制与下一步 ADR。

---

自检

• 能画出 offline ingestion 与 online query 两条路径。
• 能区分 retrieval failure 和 generation failure。
• Permission filter 在模型看到内容之前执行。
• Citation 能回到 document/version/page/chunk。
• 没有固定 chunk size、top-k 或 similarity threshold 的万能配方。
• 文档能更新、撤销、删除和重建索引。
• 没有足够证据时系统返回 no_answer。