Agentic RAG、GraphRAG 与 RuleRAG:构建可追溯业务证据链
本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 6 的配套学习笔记。 核心结论:RAG 的产物不是“几段相似文本”,而是可证明来源、版本、权限、时效和适用性的证据包。Agentic RAG 负责有预算地迭代检索,GraphRAG 负责关系与全局结构,RuleRAG 负责把条款候选交给确定性的规则适用性判断。
0. 学习目标、范围与术语边界
学完本文后,你应该能够:
- 区分检索相关性、证据充分性、答案忠实性和业务决策正确性;
- 设计 ingestion、chunk、metadata、embedding、sparse/dense、rerank 与 citation 链路;
- 实现权限、租户、时间、地域和规则版本过滤;
- 让 Agent 判断何时改写、分解、补充事实、再次检索和停止;
- 区分 GraphRAG 的 local search、global search 与普通向量检索;
- 设计规则条款的条件、结论、例外、优先级和生效区间;
- 让 LLM 负责候选检索和解释,让 Policy/Rule Engine 负责最终适用性;
- 构造包含原文片段、稳定引用、hash、版本和推导路径的 Evidence Bundle;
- 分层评估 ingestion、retrieval、rerank、evidence、generation 与 action;
- 为
OrderFlow-Agent输出可复现的退款规则证据链。
术语说明:
- Agentic RAG 是“Agent 动态决定检索步骤”的架构类别,不是单一协议;
- GraphRAG 在本文主要指以实体关系图、社区/层次摘要增强检索的方案类别,并参考 Microsoft GraphRAG;
- RuleRAG 在本文是工程组合名:
规则候选检索 + 结构化条件求值 + 可追溯解释,不是某篇论文定义的统一标准。
1. 普通 RAG 为什么不够
普通 Demo:
User Query-> Embedding-> Vector Top-K-> Concatenate Chunks-> LLM Answer生产业务还要回答:
查的是哪个租户和权限范围?文档是否在当前时间/地域/产品生效?关键词、编号和否定条件是否被 dense retrieval 漏掉?召回的是规则正文、例外还是旧版本?证据是否足够支撑结论?引用是否精确对应生成论断?动作是否由规则引擎重新校验?1.1 四个不同目标
| 目标 | 问题 | 典型指标 |
|---|---|---|
| Retrieval Relevance | 找到的内容是否相关 | Recall@K、MRR、nDCG |
| Evidence Sufficiency | 是否覆盖判断所需全部条件 | Required Evidence Recall |
| Generation Faithfulness | 输出是否由证据支持 | Claim Support、Citation Accuracy |
| Decision Correctness | 业务动作是否正确 | Action Accuracy、Policy Compliance |
相关文档可以不充分,忠实回答也可以忠实地依据错误版本。四层必须分别评估。
RAG 原始论文把生成模型与外部非参数记忆结合,解决知识密集任务的更新与来源问题;它没有替你完成权限、版本、规则求值和生产一致性。[P1]
2. 证据系统全景
Governance Plane Source Policy / ACL / Retention / Version / Quality / Delete / Audit ↙ ↘Ingestion Plane Query PlaneSource Connector User + AgentState -> Parse/OCR -> Intent/Need -> Normalize -> Query Rewrite/Decompose -> Chunk/Structure -> Fact Requirements -> Metadata/ACL -> Metadata/ACL Filters -> Quality Gate -> Sparse + Dense + Graph -> Embed/Index -> Fusion + Rerank -> Publish Snapshot -> Evidence Sufficiency -> Answer/Decision/Retry2.1 三种数据层
Canonical Source 原始政策、合同、知识文档、数据库事实
Retrieval Projection chunk、embedding、sparse index、graph、summary
Evidence Package 针对当前任务选出的可引用、可验证候选索引是可重建投影,不能反过来成为唯一原文。
2.2 Evidence 不等于 Context
Evidence Store 可以保存更多候选和元数据;Context Builder 再根据当前节点预算选择必要内容。这样 Eval 能区分“没检到”与“检到了但没给模型”。
3. Ingestion:检索质量从入库开始
3.1 Source Manifest
from datetime import datetimefrom typing import Literalfrom pydantic import BaseModel
class SourceManifest(BaseModel): document_id: str source_uri: str source_type: Literal["policy", "manual", "faq", "contract", "ticket"] tenant_id: str title: str version: str content_hash: str effective_from: datetime | None effective_to: datetime | None jurisdiction: str | None product_scope: list[str] acl: list[str] parser_version: str ingestion_run_id: str status: Literal["staged", "published", "superseded", "deleted"]3.2 发布而不是边写边读
discover source-> parse-> validate-> build all projections-> run quality checks-> create immutable index snapshot-> atomically switch active snapshot如果边解析边对线上可见,用户可能检到半份文档或新旧索引混合。
3.3 Parser Quality Gate
检查:
页数/段落数是否异常标题层级是否保留表格行列是否错位脚注/例外条款是否丢失OCR 置信度重复页与页眉页脚字符编码来源 hash3.4 Chunk 不是固定字符切割
| 内容 | 推荐边界 |
|---|---|
| 政策规则 | 条款、子条款、例外、定义 |
| API 文档 | endpoint / schema / error |
| FAQ | question-answer pair |
| 合同 | section/subsection + definitions |
| 工单 | issue、actions、outcome |
| 表格 | 语义行 + 表头上下文 |
每个 chunk 保存父级标题与相邻关系:
{ "chunk_id": "refund-v18-R001-C2", "document_id": "refund-policy-v18", "section_path": ["退款", "未发货", "例外"], "parent_chunk_id": "refund-v18-R001", "previous_chunk_id": "refund-v18-R001-C1", "next_chunk_id": "refund-v18-R001-C3"}3.5 Contextual Chunking
孤立 chunk 可能缺少文档标题、适用主体和上位定义。可以在索引时为 chunk 增加一段短上下文:
原始 chunk: 超过 48 小时仍未发货时,用户可申请全额退款。
索引上下文: 来自《平台普通商品退款规则》v18,章节“未发货退款”; 适用于非预售普通商品,跨境商品另见 R018。Anthropic Contextual Retrieval 公开方案把 chunk-specific context 与 embedding/BM25 结合。[S1] 工程上必须保留 raw_text 与 contextualized_text 两个字段,并记录生成上下文的模型/Prompt 版本;生成的上下文帮助检索,但不是可引用原文。
3.6 表格、图片与代码
表格:保留表名、表头、行键和单元格坐标图片:保存原图引用、OCR/视觉描述与置信度代码:按符号/函数/类切分,保留文件与行号公式:保留原始表达和变量定义例如补偿上限表不能把“用户等级”列与“最高金额”列拆到不同 chunk。对高风险表格应使用确定性解析或人工校验,不只依赖视觉模型描述。
4. Metadata:权限和时效不能只在文本里
4.1 Chunk Schema
class EvidenceChunk(BaseModel): chunk_id: str document_id: str document_version: str text: str content_hash: str source_uri: str section_path: list[str] tenant_id: str acl: list[str] jurisdiction: str | None product_scope: list[str] effective_from: datetime | None effective_to: datetime | None published_at: datetime language: str embedding_model: str embedding_version: str index_snapshot: str4.2 Filter-before-rank
authenticated identity-> allowed tenant/namespaces-> ACL/security classification-> valid-time/jurisdiction/product-> candidate retrieval-> relevance ranking不要把无权查看的 chunk 先召回,再交给模型删掉。
4.3 Effective Time
effective_from <= :decision_timeAND (effective_to IS NULL OR effective_to > :decision_time)“当前规则”与“订单发生时的规则”可能不同,Query Plan 必须明确 decision_time。
4.4 Index Version
一次 Run 固定 index_snapshot,避免多步检索分别命中新旧索引。紧急规则变更可让 Policy Engine 拒绝旧 Snapshot 的高风险动作,而不是静默混用。
5. Retrieval:Sparse、Dense、Hybrid 与 Rerank
5.1 Sparse Search
BM25/倒排适合:
规则编号 R001订单状态枚举 not_shipped专有名词精确错误码罕见关键词5.2 Dense Retrieval
向量适合:
口语与规范文本语义映射同义表达概念相关跨表述召回Dense Passage Retrieval 证明双编码器可用于开放域密集检索;BEIR 则展示不同 retriever 在域外任务上的明显差异,提醒我们没有通用最优检索器。[P2] [P3]
5.3 Hybrid Retrieval
Sparse Top-N ─┐ ├-> Fusion -> Candidate PoolDense Top-N ──┘常用 RRF:
RRF(d) = Σ 1 / (k + rank_i(d))Elastic 与 Qdrant 均提供公开 Hybrid/RRF 方案。[S1] 融合参数仍需基于业务数据校准。
5.4 Rerank
Candidate 100-> cross-encoder / late interaction / LLM reranker-> Evidence 10ColBERT 的 late interaction 在表示复用与细粒度匹配之间折中,可作为“召回后精排”的研究参考。[P4]
5.5 Parent/Neighbor Expansion
命中子条款后按需补:
定义父条款前后条件例外表头扩展必须记录原因,避免 top-k 变成无界上下文。
6. Query Rewrite 与 Decomposition
6.1 Rewrite 不能丢业务事实
输入:
三天了还没发货,能退吗?结构化检索意图:
{ "topic": "refund_eligibility", "facts": { "order_status": "paid", "logistics_status": "not_shipped", "hours_since_payment": 72 }, "required_evidence": [ "eligibility_rule", "merchant_exception", "refund_amount_limit" ], "decision_time": "2026-07-15T10:00:00Z"}6.2 Decomposition
复杂问题:
跨境预售订单 72 小时没发货,优惠券会退吗,还能补偿吗?拆成:
Q1 未发货退款资格Q2 跨境/预售例外Q3 优惠券退回规则Q4 补偿资格与金额上限Q5 多动作互斥/顺序6.3 HyDE
HyDE 先生成假设性文档再做 embedding,用于在缺少相关查询表达时提升无监督 dense retrieval。[P5] 在规则场景使用时,假设文本只能做检索向量,绝不能当证据。
6.4 Rewrite Eval
Required Constraint PreservationEntity/ID PreservationNegation PreservationTemporal Constraint AccuracySubquery CoverageRetrieval Recall Delta7. Agentic RAG:检索是有预算的状态机
7.1 状态图
analyze_need -> retrieve -> grade_candidates -> sufficient -> synthesize -> irrelevant -> rewrite -> incomplete -> decompose -> missing_fact -> call_tool/ask_user -> conflict -> retrieve_primary_source/human -> verify_citations -> answer/decision7.2 Retrieval State
class RetrievalState(BaseModel): retrieval_run_id: str goal: str query_plan: list[str] executed_queries: list[str] evidence_refs: list[str] missing_requirements: list[str] conflict_groups: list[str] iterations: int retrieval_calls: int rerank_calls: int tokens_used: int stop_reason: str | None7.3 Stop Conditions
required evidence coveredno new unique evidencesame query repeatedmax iterationsretrieval/token/cost deadlineprimary sources conflictpermission blocks required evidencehuman decision required7.4 证据评分输出
class EvidenceGrade(BaseModel): relevant: bool supports_requirements: list[str] missing_requirements: list[str] source_authority: str temporal_validity: str conflicts_with: list[str] next_action: Literal[ "sufficient", "rewrite", "decompose", "fetch_primary", "ask_user", "stop_insufficient", ]Self-RAG 与 Corrective RAG 都把“是否需要检索/证据是否合格/是否纠正”引入生成流程。[P6] [P7] 工程实现需要独立状态、预算和失败语义,不能无界自评。
7.5 No-progress Detector
class RetrievalProgress(BaseModel): query_fingerprint: str candidate_set_hash: str new_evidence_count: int newly_covered_requirements: list[str] repeated_query_count: int终止或换策略的条件:
连续两轮 candidate_set_hash 相同连续两轮没有覆盖新 requirementrewrite 与历史 query 高度重复同一冲突只重复召回双方换策略可以是 sparse -> dense、chunk -> parent、文本 -> graph、二手资料 -> primary source,而不是只改几个同义词继续消耗预算。
7.6 并行检索与确定性合并
多个子查询可以并行,但合并必须稳定:
每个 subquery 独立记录结果与错误按 evidence_id/content_hash 去重同一来源不同版本不合并保留每个候选被哪些 query 命中部分子查询失败时标记 missing requirement不能因为其中一个分支成功就把整个 Evidence Bundle 标为 sufficient。
8. Evidence Bundle:可验证的交付物
class EvidenceItem(BaseModel): evidence_id: str source_uri: str document_id: str document_version: str section_path: list[str] quote: str content_hash: str effective_from: datetime | None effective_to: datetime | None retrieval_query: str retrieval_rank: int rerank_score: float | None supports_claims: list[str]
class EvidenceBundle(BaseModel): bundle_id: str retrieval_run_id: str index_snapshot: str decision_time: datetime requirements: list[str] items: list[EvidenceItem] missing_requirements: list[str] conflicts: list[dict] status: Literal["sufficient", "insufficient", "conflicting"]8.1 Citation Object
用户可见引用可以简化,但内部必须保留:
source URIdocument/versionsection/spanexact quote or normalized excerptcontent hashindex snapshot8.2 Claim-Citation Matrix
{ "claim_id": "C1", "claim": "超过48小时未发货可申请全额退款", "evidence_ids": ["E-R001-1"], "support": "entailed", "citation_span_valid": true}8.3 Insufficient Evidence 是正常结果
{ "status": "insufficient", "known_facts": ["订单已支付72小时"], "missing": ["是否属于预售例外"], "next_action": "ask_user_or_query_order_product_type"}系统不能为了“总要回答”而把证据不足伪装成低置信结论。
9. GraphRAG:什么时候图比纯向量有价值
9.1 图模型
Nodes Entity / Document / Section / Event / Rule / Concept
Edges mentions / belongs_to / depends_on / exception_to / supersedes / applies_to / caused_by / supported_by
Community / Hierarchy 对密集子图生成分层摘要9.2 Local Search
适合:
某个商家有哪些关联投诉与规则?规则 R001 有哪些例外和依赖定义?订单事件与物流节点如何关联?从实体出发,结合邻居、文本单元和属性回答。
9.3 Global Search
适合:
近一个季度退款投诉的主要主题是什么?规则库有哪些跨文档冲突模式?利用社区/层次摘要聚合全局主题。Microsoft GraphRAG 的公开方案与论文重点讨论从局部到全局的 query-focused summarization。[S2] [P8]
9.4 什么时候不要用 GraphRAG
语料小且问题只是局部事实实体/关系提取质量低知识更新极快但图维护链路不成熟没有需要多跳或全局汇总的查询团队无法运维图、社区摘要和版本9.5 图的来源与版本
每条边应有:
edge_idsource_refsextractor_versionconfidencevalid_from/valid_torecorded_atstatus模型提取的边是带置信度的派生数据,不等于 Canonical Fact。
9.6 Entity Resolution
“上海商家 A”“A 商贸(上海)有限公司”“merchant_id=8921”可能是同一实体,也可能不是。合并流程应使用稳定业务 ID、别名、来源与人工规则;LLM 只提出候选:
class EntityMergeProposal(BaseModel): left_entity_id: str right_entity_id: str matching_signals: list[str] conflicting_signals: list[str] confidence: float source_refs: list[str]错误合并会把不同用户、商家或规则的边传播到所有多跳查询,通常比漏合并更危险。
9.7 Graph Delta 与 Community Summary
文档更新时不能只追加新图:
识别受影响 document/chunk/entity/edge-> tombstone 旧派生边-> 写入新版本边-> 重算受影响社区-> 重建相关层级摘要-> 发布 graph snapshot社区摘要保存成员集合 hash、生成模型/Prompt 和源 Snapshot。成员变化后,旧摘要不能继续伪装成当前全局事实。
9.6 RAPTOR、HippoRAG 与 LightRAG
RAPTOR 通过递归聚类与摘要构建树形检索;HippoRAG 借鉴长期记忆与图关联;LightRAG 探索图结构与双层检索的高效组合。[P9] [P10] [P11] 它们提供不同结构化检索思路,实际选型要用本地数据比较质量、延迟、成本和更新复杂度。
10. RuleRAG:检索候选,规则引擎裁决
10.1 为什么普通 chunk 不够
规则包含:
适用主体前置条件结论/动作例外优先级地域/产品范围生效与失效时间与其他规则关系只检索一句“超过 48 小时未发货可退款”可能漏掉下一段“预售商品除外”。
10.2 Rule Schema
class RuleRecord(BaseModel): rule_id: str version: str title: str jurisdiction: str product_scope: list[str] effective_from: datetime effective_to: datetime | None priority: int condition_ast: dict outcome: dict exception_rule_ids: list[str] depends_on_rule_ids: list[str] source_uri: str source_quote: str content_hash: str extraction_status: Literal["draft", "human_verified", "published"]10.3 条件 AST
{ "all": [ {"field": "order.status", "op": "eq", "value": "paid"}, {"field": "logistics.status", "op": "eq", "value": "not_shipped"}, {"field": "hours_since_payment", "op": "gte", "value": 48}, {"not": {"field": "product.type", "op": "eq", "value": "presale"}} ]}条件由受控 evaluator 求值,不让 LLM 自由解释布尔逻辑。
10.4 RuleRAG 流程
Verified Business Facts -> Build Rule Retrieval Query -> Hybrid Retrieve Candidate Rules -> Expand Definitions/Exceptions/Dependencies -> Filter Published + Effective + Jurisdiction + Product -> Deterministic Condition Evaluation -> Resolve Priority/Conflict -> Evidence Bundle -> LLM Explain Result -> Policy Engine Recheck Before Action10.5 决策表/策略引擎
DMN 提供决策模型与决策表标准;OPA/Rego 与 Cedar 提供策略表达/授权思路。[S3] RuleRAG 可以将检索到的候选映射到这些确定性执行层,但不能把自然语言检索结果直接当授权。
10.6 规则冲突
优先级示例:
更具体地域/产品规则> 更高显式 priority> 更新且当前生效版本> 一般规则冲突策略必须由业务 Owner 定义。模型只能解释已定义的优先级,不能自创法则。
10.7 规则抽取发布流程
Natural-language Policy -> Clause Segmentation -> LLM Rule Draft -> Schema Validation -> Symbol/Field Resolution -> Example + Counterexample Generation -> Deterministic Test Execution -> Human Policy-owner Review -> Signed Published Rule SnapshotDraft 中任何未解析术语都必须显式失败:
{ "rule_id": "R001", "status": "blocked", "unresolved_symbols": ["承诺发货时间"], "missing_definitions": ["预售商品"], "required_review": "policy_owner"}10.8 正例、反例与边界例
{ "rule_id": "R001", "tests": [ {"hours": 47, "product_type": "normal", "expected": false}, {"hours": 48, "product_type": "normal", "expected": true}, {"hours": 72, "product_type": "presale", "expected": false}, {"hours": 72, "product_type": "normal", "order_status": "cancelled", "expected": false} ]}规则 Snapshot 只有在测试通过和 Owner 签署后才能用于写动作授权。自然语言原文仍是审计证据,AST 是可执行投影。
11. OrderFlow-Agent RuleRAG 实例
11.1 规则
R001:普通商品支付超过 48 小时仍未发货,用户可申请全额退款。R001-E1:预售商品按承诺发货时间判断,不适用 48 小时规则。R002:物流连续 7 天无更新,标记物流异常并允许转人工处理。R004:平台自动补偿不得超过实付金额的 10%,且最高 5000 分。11.2 事实包
{ "order.id": "ORD-A1B2C3D4", "order.status": "paid", "order.paid_amount_cents": 12900, "product.type": "normal", "logistics.status": "not_shipped", "hours_since_payment": 72, "fact_versions": { "order": 8, "logistics": 3 }}11.3 候选与求值
{ "candidate_rules": ["R001", "R001-E1", "R004"], "evaluations": [ { "rule_id": "R001", "result": "matched", "satisfied_conditions": [ "order.status == paid", "logistics.status == not_shipped", "hours_since_payment >= 48", "product.type != presale" ] }, { "rule_id": "R001-E1", "result": "not_applicable", "failed_condition": "product.type == presale" } ]}11.4 决策证据
{ "decision": "refund_eligible", "responsible_party": "merchant", "allowed_action": "create_refund", "max_amount_cents": 12900, "rule_ids": ["R001"], "fact_refs": [ "order://ORD-A1B2C3D4?version=8", "logistics://ORD-A1B2C3D4?version=3" ], "evidence_bundle_id": "evb_01J...", "requires_confirmation": true}11.5 写动作前重新校验
等待用户确认后:
重查订单 version重查物流状态校验 Rule Snapshot 仍可执行校验确认参数 hashPolicy Engine 授权执行幂等退款查询最终状态RAG 决策证据不能冻结变化中的业务事实。
12. 权限、注入与证据安全
12.1 检索权限
文档 ACLchunk ACLsource connector credentialtenant namespacefield-level redactionpurpose limitation12.2 Indirect Prompt Injection
检索内容是不可信数据。防御:
来源 allowlist/quality gate指令与数据显式分隔内容安全标签只抽取当前任务字段文档文本不能修改系统策略工具调用仍走独立授权高风险证据需权威来源/人工12.3 Citation Leakage
即使回答已脱敏,引用链接或 quote 也可能泄露无权内容。Citation Renderer 必须再次做资源授权和字段脱敏。
12.4 Poisoning
恶意文档入库SEO/关键词堆叠劫持 sparse 排名embedding collision/相似文本淹没图中伪造高连接实体社区摘要污染需要来源签名/hash、发布审批、异常分布监控和 Snapshot 回滚。
13. 厂商与大厂公开方案对照
| 方案 | 公开能力 | 适合借鉴 | 需自行验证 |
|---|---|---|---|
| OpenAI Retrieval/File Search | vector store、file search、citation/annotations | 托管检索与工具集成 | chunk/版本/ACL 细节与迁移 |
| Anthropic Contextual Retrieval | 给 chunk 补文档语境,结合 BM25/embedding/rerank | ingestion context + hybrid | 自有语料的成本/收益 |
| Microsoft GraphRAG | entity graph、community report、local/global search | 全局主题与关系问题 | 索引成本、提取质量 |
| Azure AI Search | classic/agentic retrieval、hybrid、semantic rank | 企业 Search 与权限数据 | 服务版本与延迟预算 |
| Google Cloud RAG Engine | ingestion、retrieval、managed corpus | 托管数据/检索流水线 | 产品变更、区域和数据治理 |
| AWS Bedrock Knowledge Bases | data source、retrieval、generation、structured data | 云资源集成 | 业务规则求值与可迁移性 |
| Databricks Agentic RAG | 数据/检索/Agent/eval/治理集成 | Lakehouse 数据治理与评估 | 平台耦合和线上 SLO |
| Elastic/Qdrant | Hybrid、filter、RRF/fusion | 可解释检索管线 | schema/索引运维 |
官方入口见 [S1]、[S2] 与 [S4]。公开产品能力不能替代自己的 Eval Set。
14. RAG Evaluation:按链路归因
14.1 Ingestion
Parse Success RateStructure PreservationTable/OCR AccuracyMetadata CompletenessACL AccuracyIndex Freshness LagDuplicate Rate14.2 Retrieval
Recall@KPrecision@KMRR / nDCGRequired Evidence RecallEffective-version AccuracyUnauthorized Retrieval RateNo-answer Detection14.3 Rerank/Evidence
Rerank LiftEvidence Sufficiency AccuracyConflict Detection RecallException Retrieval RecallEvidence DiversityQuote/Span Accuracy14.4 Generation/Decision
Claim FaithfulnessCitation Precision/RecallCitation EntailmentUnsupported Claim RateRule Match AccuracyAction AccuracyPolicy Compliance14.5 System
Retrieval IterationsCalls / Tokens / Costp50/p95/p99 LatencyCache Hit RateIndex Snapshot AgeFailure/Retry RateRagas 与 ARES 提供了 RAG 自动化评估方法;论文结果应作为构建评估器的参考,而不是取代人工标注和业务成功条件。[P12] [P13]
15. 测试集设计
15.1 Golden Case
{ "case_id": "RAG-RF-001", "query": "普通商品支付72小时没发货,可以退款吗?", "decision_time": "2026-07-15T10:00:00Z", "identity": { "tenant_id": "shop-a", "roles": ["customer_support"] }, "required_rule_ids": ["R001"], "required_exception_ids": ["R001-E1"], "expected_decision": "refund_eligible", "forbidden_document_versions": ["refund-policy-v17"]}15.2 Case 类型
同义口语编号精确查询多条件分解否定与例外旧版本/未来版本跨地域/跨产品权限拒绝无答案来源冲突注入/投毒图多跳全局主题15.3 Counterfactual
移除关键规则 -> 应报告证据不足加入高相似旧规则 -> 不应误选加入跨租户更相关文档 -> 必须过滤把普通商品改为预售 -> 决策应改变把 72 小时改为 24 小时 -> R001 不匹配15.4 Offline/Online
Offline:固定 Snapshot、可重复、适合回归Shadow:真实流量不影响用户,比较候选链路Canary:小流量真正生效,监控安全与业务指标Online Eval:抽样人工/模型评审 + 环境结果16. 缓存与一致性
16.1 缓存键
tenantidentity/ACL fingerprintnormalized queryfiltersindex snapshotretriever/reranker versiontop-k缺少 ACL fingerprint 会造成跨权限缓存泄露。
16.2 三类缓存
Embedding CacheRetrieval Candidate CacheEvidence Bundle Cache最终业务决策不能只按 query 缓存,因为订单事实和 decision time 会变。
16.3 Snapshot 切换
build snapshot N+1-> validate-> publish active pointer-> new runs pin N+1-> old runs finish on N-> retain N for replay window-> retire according to policy16.4 Emergency Revocation
错误规则需紧急撤回时:
mark snapshot revokedPolicy Engine blocks high-risk actions from itrunning agents revalidate before writepublish corrected snapshotreplay affected decisions16.5 Retrieval Trace
{ "retrieval_run_id": "ret_01J...", "query_plan_version": "qp@7", "queries": ["普通商品 未发货 48小时 退款 例外"], "filters": { "tenant": "shop-a", "effective_at": "2026-07-15T10:00:00Z", "product": "normal" }, "index_snapshot": "policy-2026-07-15.3", "retrievers": ["bm25@2", "dense@embed-v5"], "fusion": "rrf@k60", "reranker": "cross-encoder@4", "candidate_count": 83, "evidence_count": 5, "stop_reason": "requirements_covered"}Trace 不默认保存完整敏感 query/chunk;可记录受控引用、hash 与脱敏字段。没有 Query/Filter/Snapshot/Version,最终答案即使有 citation 也难以复现。
16.6 成本归因
ingestion parser/OCR cost per documentembedding cost per published chunkgraph extraction and community summary costretrieval/rerank latency per queryagentic iteration cost per verified answerstorage/index cost per active snapshot比较方案时使用 cost per sufficient evidence bundle 或 cost per verified successful task,而不是只比一次 vector search 的毫秒数。
17. Failure Taxonomy
| 编号 | 失败 | 示例 | 首要层 |
|---|---|---|---|
| R01 | Parse Loss | 表格例外丢失 | Ingestion |
| R02 | Bad Chunk | 条件与结论被切开 | Chunking |
| R03 | Metadata Missing | 无有效期/ACL | Schema |
| R04 | Index Drift | 新文档未进入一个投影 | Index Pipeline |
| R05 | Query Loss | rewrite 丢否定/实体 | Query Planner |
| R06 | Retrieval Miss | 规则未召回 | Retriever |
| R07 | Wrong Version | 命中旧规则 | Filter |
| R08 | Permission Leak | 跨租户 chunk 进入候选 | ACL |
| R09 | Rerank Error | 例外被排到 top-k 外 | Reranker |
| R10 | Insufficient Misread | 证据不全仍回答 | Evidence Grader |
| R11 | Citation Error | 引用不支持论断 | Citation Checker |
| R12 | Graph Error | 错误实体合并/关系 | Graph Builder |
| R13 | Rule Eval Error | LLM 自由解释条件 | Rule Engine |
| R14 | Retrieval Loop | 无新证据仍重复查询 | Agent Runtime |
| R15 | Poisoning | 恶意文档控制回答/动作 | Governance |
18. 常见反模式
18.1 只用向量检索
规则 ID、枚举和数字条件常需 sparse;先测 Hybrid。
18.2 Top-K 越大越好
更多噪声、冲突、token 和注入面;应优化 Recall 与 Evidence Sufficiency。
18.3 Chunk 没有版本/ACL
相关性正确也可能泄露或引用旧规则。
18.4 让 LLM 判断规则布尔条件
复杂例外、数字和优先级应交给结构化 evaluator。
18.5 引用文档首页
用户和审计者无法定位支持论断的具体版本/条款/span。
18.6 GraphRAG 解决一切
图提取、实体消歧、更新和全局摘要成本很高;没有图型查询就不必引入。
18.7 用 LLM Judge 代替全部评估
检索 Recall、ACL、版本和最终数据库状态应由确定性或人工 Gold 校验。
18.8 RAG 结果直接触发写工具
Evidence Bundle 只支撑决策;写动作仍需业务事实刷新、Policy、确认和幂等。
19. 项目目录与实践任务
app/ rag/ sources.py parser.py chunker.py metadata.py publisher.py sparse_retriever.py dense_retriever.py fusion.py reranker.py query_planner.py evidence.py citation_checker.py agentic_loop.py graph_rag/ entities.py relations.py communities.py local_search.py global_search.py rule_rag/ schema.py parser.py retriever.py evaluator.py conflicts.py explainer.pytests/ ingestion/ retrieval/ citations/ graph/ rules/ security/ scenarios/data/ policies/ rag_eval.jsonldocs/ evidence_architecture.md rule_schema.md index_runbook.md实践顺序:
1. 建 Source/Chunk/Evidence Schema2. 用 20-50 条规则建立人工 Gold3. 先做 BM25 与 Dense 两个 baseline4. 加 Hybrid/RRF 与 Rerank5. 加 ACL/有效期/Snapshot6. 做 Query Decomposition 与 Evidence Grader7. 加 Citation Checker 与 insufficient 状态8. 把规则解析为 AST,用代码求值9. 只有图型问题明显时才试 GraphRAG10. 用 Eval、Shadow、Canary 证明收益20. 达标检查清单
Ingestion
- Source 有 URI、version、hash、ACL、有效期;
- Chunk 保留结构、父子和相邻关系;
- 索引 Snapshot 通过质量门禁后原子发布;
- Canonical Source 与索引投影分离;
- 能回滚错误 Snapshot。
Retrieval/Evidence
- 对比 Sparse、Dense、Hybrid 和 Rerank;
- 先做身份/ACL/时间过滤;
- Query Rewrite 不丢实体、否定和时间;
- Evidence Bundle 包含版本、span、quote、hash;
- 支持 sufficient/insufficient/conflicting。
Agentic/Graph/Rule
- 再检索有状态、预算和停止条件;
- Graph Edge 有来源、时间和置信度;
- 能说明 local/global search 适用边界;
- Rule 包含条件、结论、例外、优先级、有效期;
- 规则适用性由确定性 evaluator 校验。
Evaluation/Security
- 分别测 ingestion、retrieval、evidence、generation、decision;
- 有旧版本、例外、权限、无答案、冲突和攻击 Case;
- Citation 对每个 Claim 做 entailment/span 校验;
- 缓存键包含 ACL 与 Index Snapshot;
- 写动作前刷新业务事实与 Policy。
21. 面试与架构评审问题
- Retrieval Relevance 与 Evidence Sufficiency 有什么区别?
- 为什么规则检索通常需要 BM25 + Dense?
- RRF 解决什么问题,不能解决什么?
- 如何防止检索命中过期或越权文档?
- Agentic RAG 什么时候应继续检索,什么时候停止?
- Evidence Bundle 为什么要保存 Index Snapshot 和 hash?
- GraphRAG local/global search 分别适合什么?
- RuleRAG 为什么不能让 LLM 直接做最终条件求值?
- 如何验证引用真的支持具体 Claim?
- 紧急撤回错误规则时如何处理进行中的 Run?
- 如何证明 GraphRAG 的收益超过索引和运维成本?
- RAG 正确但最终动作错误,应该归因到哪里?
22. 参考资料与延伸阅读
以下资料用于核对公开产品能力、标准和论文原始思想。产品会演进;论文指标不能替代本地数据集与最终业务状态验证。
检索、图与规则工程
[S1] Hybrid Retrieval
- Elastic Reciprocal rank fusion;
- Qdrant Hybrid Queries;
- Anthropic Contextual Retrieval。
[S2] Microsoft GraphRAG
[S3] 规则与策略引擎
[S4] 大厂 RAG 平台
- OpenAI Retrieval 与 File Search;
- Microsoft Azure AI Search RAG overview;
- Google Cloud RAG Engine overview;
- AWS Knowledge Bases for Amazon Bedrock;
- Databricks Retrieval-augmented generation。
论文与评估
[P1] RAG
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020。
[P2] DPR
- Karpukhin et al., Dense Passage Retrieval for Open-Domain Question Answering, EMNLP 2020。
[P3] BEIR
- Thakur et al., BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021 Datasets and Benchmarks。
[P4] ColBERT
- Khattab and Zaharia, ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT, SIGIR 2020。
[P5] HyDE
- Gao et al., Precise Zero-Shot Dense Retrieval without Relevance Labels, ACL 2023。
[P6] Self-RAG
- Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, ICLR 2024。
[P7] CRAG
- Yan et al., Corrective Retrieval Augmented Generation, 2024。
[P8] GraphRAG
- Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization, 2024。
[P9] RAPTOR
- Sarthi et al., RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, ICLR 2024。
[P10] HippoRAG
- Gutiérrez et al., HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models, NeurIPS 2024。
[P11] LightRAG
- Guo et al., LightRAG: Simple and Fast Retrieval-Augmented Generation, 2024。
[P12] Ragas
- Es et al., Ragas: Automated Evaluation of Retrieval Augmented Generation, EACL 2024 System Demonstrations。
[P13] ARES
- Saad-Falcon et al., ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems, NAACL 2024。
23. 阶段总结
生产级 RAG 的核心链路是:
可信来源-> 结构化入库-> 版本/权限/时间过滤-> Hybrid Retrieval + Rerank-> Evidence Sufficiency-> 精确 Citation-> 规则/事实验证-> 有预算的再检索或停止Agentic RAG 让检索步骤动态化,但必须有状态、预算和终止条件;GraphRAG 让关系与全局主题可查询,但必须承担图提取和更新成本;RuleRAG 让自然语言规则可检索,但最终条件与优先级必须回到可测试的结构化求值。
真正的达标标准不是“回答里有几个引用”,而是面对一次具体业务动作,系统能证明:
用了哪些版本的业务事实;命中了哪些当前有效且有权访问的条款;哪些条件满足、哪些例外不适用;每个结论对应哪段原文;证据不足或冲突时为什么停止;写动作前如何重新校验。做到这一点,RAG 才从相似文本拼接升级为可审计的业务证据系统。