6643 字
33 分钟

Agentic RAG、GraphRAG 与 RuleRAG:构建可追溯业务证据链

本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 6 的配套学习笔记。 核心结论:RAG 的产物不是“几段相似文本”,而是可证明来源、版本、权限、时效和适用性的证据包。Agentic RAG 负责有预算地迭代检索,GraphRAG 负责关系与全局结构,RuleRAG 负责把条款候选交给确定性的规则适用性判断。


0. 学习目标、范围与术语边界#

学完本文后,你应该能够:

  1. 区分检索相关性、证据充分性、答案忠实性和业务决策正确性;
  2. 设计 ingestion、chunk、metadata、embedding、sparse/dense、rerank 与 citation 链路;
  3. 实现权限、租户、时间、地域和规则版本过滤;
  4. 让 Agent 判断何时改写、分解、补充事实、再次检索和停止;
  5. 区分 GraphRAG 的 local search、global search 与普通向量检索;
  6. 设计规则条款的条件、结论、例外、优先级和生效区间;
  7. 让 LLM 负责候选检索和解释,让 Policy/Rule Engine 负责最终适用性;
  8. 构造包含原文片段、稳定引用、hash、版本和推导路径的 Evidence Bundle;
  9. 分层评估 ingestion、retrieval、rerank、evidence、generation 与 action;
  10. 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 Plane
Source 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/Retry

2.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 datetime
from typing import Literal
from 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 置信度
重复页与页眉页脚
字符编码
来源 hash

3.4 Chunk 不是固定字符切割#

内容推荐边界
政策规则条款、子条款、例外、定义
API 文档endpoint / schema / error
FAQquestion-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_textcontextualized_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: str

4.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_time
AND (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#

BM25/倒排适合:

规则编号 R001
订单状态枚举 not_shipped
专有名词
精确错误码
罕见关键词

5.2 Dense Retrieval#

向量适合:

口语与规范文本语义映射
同义表达
概念相关
跨表述召回

Dense Passage Retrieval 证明双编码器可用于开放域密集检索;BEIR 则展示不同 retriever 在域外任务上的明显差异,提醒我们没有通用最优检索器。[P2] [P3]

5.3 Hybrid Retrieval#

Sparse Top-N ─┐
├-> Fusion -> Candidate Pool
Dense 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 10

ColBERT 的 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 Preservation
Entity/ID Preservation
Negation Preservation
Temporal Constraint Accuracy
Subquery Coverage
Retrieval Recall Delta

7. 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/decision

7.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 | None

7.3 Stop Conditions#

required evidence covered
no new unique evidence
same query repeated
max iterations
retrieval/token/cost deadline
primary sources conflict
permission blocks required evidence
human decision required

7.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 相同
连续两轮没有覆盖新 requirement
rewrite 与历史 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 URI
document/version
section/span
exact quote or normalized excerpt
content hash
index snapshot

8.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
对密集子图生成分层摘要

适合:

某个商家有哪些关联投诉与规则?
规则 R001 有哪些例外和依赖定义?
订单事件与物流节点如何关联?

从实体出发,结合邻居、文本单元和属性回答。

适合:

近一个季度退款投诉的主要主题是什么?
规则库有哪些跨文档冲突模式?

利用社区/层次摘要聚合全局主题。Microsoft GraphRAG 的公开方案与论文重点讨论从局部到全局的 query-focused summarization。[S2] [P8]

9.4 什么时候不要用 GraphRAG#

语料小且问题只是局部事实
实体/关系提取质量低
知识更新极快但图维护链路不成熟
没有需要多跳或全局汇总的查询
团队无法运维图、社区摘要和版本

9.5 图的来源与版本#

每条边应有:

edge_id
source_refs
extractor_version
confidence
valid_from/valid_to
recorded_at
status

模型提取的边是带置信度的派生数据,不等于 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 Action

10.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 Snapshot

Draft 中任何未解析术语都必须显式失败:

{
"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 仍可执行
校验确认参数 hash
Policy Engine 授权
执行幂等退款
查询最终状态

RAG 决策证据不能冻结变化中的业务事实。


12. 权限、注入与证据安全#

12.1 检索权限#

文档 ACL
chunk ACL
source connector credential
tenant namespace
field-level redaction
purpose limitation

12.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 Searchvector store、file search、citation/annotations托管检索与工具集成chunk/版本/ACL 细节与迁移
Anthropic Contextual Retrieval给 chunk 补文档语境,结合 BM25/embedding/rerankingestion context + hybrid自有语料的成本/收益
Microsoft GraphRAGentity graph、community report、local/global search全局主题与关系问题索引成本、提取质量
Azure AI Searchclassic/agentic retrieval、hybrid、semantic rank企业 Search 与权限数据服务版本与延迟预算
Google Cloud RAG Engineingestion、retrieval、managed corpus托管数据/检索流水线产品变更、区域和数据治理
AWS Bedrock Knowledge Basesdata source、retrieval、generation、structured data云资源集成业务规则求值与可迁移性
Databricks Agentic RAG数据/检索/Agent/eval/治理集成Lakehouse 数据治理与评估平台耦合和线上 SLO
Elastic/QdrantHybrid、filter、RRF/fusion可解释检索管线schema/索引运维

官方入口见 [S1][S2][S4]。公开产品能力不能替代自己的 Eval Set。


14. RAG Evaluation:按链路归因#

14.1 Ingestion#

Parse Success Rate
Structure Preservation
Table/OCR Accuracy
Metadata Completeness
ACL Accuracy
Index Freshness Lag
Duplicate Rate

14.2 Retrieval#

Recall@K
Precision@K
MRR / nDCG
Required Evidence Recall
Effective-version Accuracy
Unauthorized Retrieval Rate
No-answer Detection

14.3 Rerank/Evidence#

Rerank Lift
Evidence Sufficiency Accuracy
Conflict Detection Recall
Exception Retrieval Recall
Evidence Diversity
Quote/Span Accuracy

14.4 Generation/Decision#

Claim Faithfulness
Citation Precision/Recall
Citation Entailment
Unsupported Claim Rate
Rule Match Accuracy
Action Accuracy
Policy Compliance

14.5 System#

Retrieval Iterations
Calls / Tokens / Cost
p50/p95/p99 Latency
Cache Hit Rate
Index Snapshot Age
Failure/Retry Rate

Ragas 与 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 缓存键#

tenant
identity/ACL fingerprint
normalized query
filters
index snapshot
retriever/reranker version
top-k

缺少 ACL fingerprint 会造成跨权限缓存泄露。

16.2 三类缓存#

Embedding Cache
Retrieval Candidate Cache
Evidence 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 policy

16.4 Emergency Revocation#

错误规则需紧急撤回时:

mark snapshot revoked
Policy Engine blocks high-risk actions from it
running agents revalidate before write
publish corrected snapshot
replay affected decisions

16.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 document
embedding cost per published chunk
graph extraction and community summary cost
retrieval/rerank latency per query
agentic iteration cost per verified answer
storage/index cost per active snapshot

比较方案时使用 cost per sufficient evidence bundlecost per verified successful task,而不是只比一次 vector search 的毫秒数。


17. Failure Taxonomy#

编号失败示例首要层
R01Parse Loss表格例外丢失Ingestion
R02Bad Chunk条件与结论被切开Chunking
R03Metadata Missing无有效期/ACLSchema
R04Index Drift新文档未进入一个投影Index Pipeline
R05Query Lossrewrite 丢否定/实体Query Planner
R06Retrieval Miss规则未召回Retriever
R07Wrong Version命中旧规则Filter
R08Permission Leak跨租户 chunk 进入候选ACL
R09Rerank Error例外被排到 top-k 外Reranker
R10Insufficient Misread证据不全仍回答Evidence Grader
R11Citation Error引用不支持论断Citation Checker
R12Graph Error错误实体合并/关系Graph Builder
R13Rule Eval ErrorLLM 自由解释条件Rule Engine
R14Retrieval Loop无新证据仍重复查询Agent Runtime
R15Poisoning恶意文档控制回答/动作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.py
tests/
ingestion/
retrieval/
citations/
graph/
rules/
security/
scenarios/
data/
policies/
rag_eval.jsonl
docs/
evidence_architecture.md
rule_schema.md
index_runbook.md

实践顺序:

1. 建 Source/Chunk/Evidence Schema
2. 用 20-50 条规则建立人工 Gold
3. 先做 BM25 与 Dense 两个 baseline
4. 加 Hybrid/RRF 与 Rerank
5. 加 ACL/有效期/Snapshot
6. 做 Query Decomposition 与 Evidence Grader
7. 加 Citation Checker 与 insufficient 状态
8. 把规则解析为 AST,用代码求值
9. 只有图型问题明显时才试 GraphRAG
10. 用 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. 面试与架构评审问题#

  1. Retrieval Relevance 与 Evidence Sufficiency 有什么区别?
  2. 为什么规则检索通常需要 BM25 + Dense?
  3. RRF 解决什么问题,不能解决什么?
  4. 如何防止检索命中过期或越权文档?
  5. Agentic RAG 什么时候应继续检索,什么时候停止?
  6. Evidence Bundle 为什么要保存 Index Snapshot 和 hash?
  7. GraphRAG local/global search 分别适合什么?
  8. RuleRAG 为什么不能让 LLM 直接做最终条件求值?
  9. 如何验证引用真的支持具体 Claim?
  10. 紧急撤回错误规则时如何处理进行中的 Run?
  11. 如何证明 GraphRAG 的收益超过索引和运维成本?
  12. RAG 正确但最终动作错误,应该归因到哪里?

22. 参考资料与延伸阅读#

以下资料用于核对公开产品能力、标准和论文原始思想。产品会演进;论文指标不能替代本地数据集与最终业务状态验证。

检索、图与规则工程#

[S1] Hybrid Retrieval#

[S2] Microsoft GraphRAG#

[S3] 规则与策略引擎#

[S4] 大厂 RAG 平台#

论文与评估#

[P1] RAG#

[P2] DPR#

[P3] BEIR#

[P4] ColBERT#

[P5] HyDE#

[P6] Self-RAG#

[P7] CRAG#

[P8] GraphRAG#

[P9] RAPTOR#

[P10] HippoRAG#

[P11] LightRAG#

[P12] Ragas#

[P13] ARES#


23. 阶段总结#

生产级 RAG 的核心链路是:

可信来源
-> 结构化入库
-> 版本/权限/时间过滤
-> Hybrid Retrieval + Rerank
-> Evidence Sufficiency
-> 精确 Citation
-> 规则/事实验证
-> 有预算的再检索或停止

Agentic RAG 让检索步骤动态化,但必须有状态、预算和终止条件;GraphRAG 让关系与全局主题可查询,但必须承担图提取和更新成本;RuleRAG 让自然语言规则可检索,但最终条件与优先级必须回到可测试的结构化求值。

真正的达标标准不是“回答里有几个引用”,而是面对一次具体业务动作,系统能证明:

用了哪些版本的业务事实;
命中了哪些当前有效且有权访问的条款;
哪些条件满足、哪些例外不适用;
每个结论对应哪段原文;
证据不足或冲突时为什么停止;
写动作前如何重新校验。

做到这一点,RAG 才从相似文本拼接升级为可审计的业务证据系统。

Agentic RAG、GraphRAG 与 RuleRAG:构建可追溯业务证据链
https://jupiter-ws.cn/posts/agent/agentic-rag-graphrag-rulerag/
作者
Jupiter
发布于
2026-04-13
许可协议
CC BY-NC-SA 4.0