Retrieval / Eval / GraphRAG 实战手册

面向对象: AI PM / AI BA / AI Architect / 金融零售业务架构师。 核心目标: 不再把 RAG 当成“向量库 + 大模型问答”, 而是训练把企业知识系统做成可评估、可审计、可上线、可复盘、可转作品集的能力。

---

1. 定位: 这份手册补什么能力缺口

已有资料已经覆盖了三个基础层:

这份手册重点不重复 RAG 基础, 而是解决五个更高级的能力缺口:

1. 能把“回答准确”拆成可测指标: query set、gold docs、chunk recall、context precision、answer faithfulness、citation support、permission/version tests。
2. 能解释评估指标对业务上线的意义: 指标不是学术报表, 而是决定能否 pilot、能否扩大范围、能否进入高风险流程的证据。
3. 能判断普通 RAG 与 GraphRAG 的边界: 什么时候需要实体关系、社区摘要、多跳路径, 什么时候普通 hybrid RAG 就足够。
4. 能把金融零售场景做成可审计知识系统: AML investigation、KYC checklist、credit policy assistant、merchant risk review、retail product knowledge assistant。
5. 能沉淀作品集: 不只展示 demo UI, 还展示 eval matrix、ADR、source readiness checklist、failure triage、release gate memo 和 interview story。

一句话:

企业 RAG 的核心竞争力不是“能回答”, 而是“能证明它基于正确来源、正确权限、正确版本、正确证据链回答, 且失败可定位、可修复、可复盘”。

---

2. 能力地图: 从 RAG Demo 到 Enterprise Knowledge System

成熟表达不是“我做了一个 RAG”, 而是:

我把某个业务知识域产品化成了一个可治理的 knowledge product, 设计了 retrieval eval stack, 用 golden set 验证检索、引用、权限和版本, 并用 ADR 判断是否需要 GraphRAG。

---

3. Retrieval Eval Stack

Retrieval eval stack 要把 RAG 失败拆成多个层级。否则最终答案错了, 团队只会争论“模型不行”还是“文档不行”, 无法定位真正瓶颈。

3.1 Query Set

Query set 是检索评估的入口, 不是随手写的问题列表。每条 query 都应代表一种业务任务、风险等级和评估意图。

Query set 的最小字段:

PM 关注 query set 是否覆盖真实价值和上线风险。BA 关注样本是否表达业务语义和异常路径。架构师关注样本是否能驱动检索、权限、版本、引用和日志设计。

3.2 Gold Docs

Gold docs 是每条 query 应该召回的权威证据。没有 gold docs, retrieval recall 无法计算, citation support 也无法严肃验证。

Gold docs 不等于“参考答案所在文档名”。生产级 gold docs 至少要精确到 section、page、paragraph、table row 或 chunk。

Gold docs 的维护原则:

• 每个 gold doc 必须来自 approved source, 不能引用草稿、过期文档或个人笔记。
• 每个 gold doc 要带版本、生效日期、失效日期和 owner。
• 每条 query 可以有多个 gold docs, 但要标明 primary evidence 与 supporting evidence。
• hard negatives 与 gold docs 一样重要, 因为金融场景常见“相似但错误”的政策误引。

3.3 Chunk Recall

Chunk recall 衡量系统是否把正确证据片段召回到候选列表中。它回答的是:

正确证据有没有被找出来?

常见指标:

PM 解读:

• 高频低风险客服助手可以接受较高 top-k 后再由 reranker 和生成层筛选。
• 高风险合规、信贷、AML 场景不能只看“top-10 命中”, 更要看 gold 是否进入最终 context。

BA 解读:

• 如果某类 query recall 低, 往往不是模型问题, 而是同义词、业务术语、政策结构、metadata 或 gold 标注问题。
• BA 应补充业务词表、别名、产品代码、地区映射、客户类型定义。

架构师解读:

• recall 低时先比较 BM25、dense、hybrid、rerank、query rewrite 和 chunk 策略。
• 记录每次 query 的 candidate trace, 否则无法解释为什么没召回。

3.4 Context Precision

Context precision 衡量最终放进 prompt context 的内容有多少是真正相关、可用、当前有效、权限允许的证据。它回答的是:

模型看到的上下文是否干净?

常见问题:

• top-k 召回了正确文档, 但 context 中混入大量相似错误资料。
• 新旧版本同时进入 context, 生成答案混合口径。
• 低可信来源排在前面, 权威政策被挤出 token budget。
• 用户无权访问的 chunk 在检索后才被过滤, 日志或缓存已经泄漏。

Context precision 的评估维度:

上线决策:

• context precision 低但 recall 高, 说明 retriever 初召回可用, 重点优化 rerank、metadata filter、context packing。
• context precision 高但 recall 低, 说明系统很保守, 可能回答覆盖不足, 需要扩展 query rewrite、synonym、chunking。
• 高风险场景应把“无权 chunk 进入 context”定义为 critical failure, 阈值为 0。

3.5 Answer Faithfulness

Answer faithfulness 衡量回答中的断言是否由给定 context 支撑。它回答的是:

模型有没有基于证据说话?

Faithfulness 不等于 correctness。回答可能忠实于 context, 但 context 本身错了或过期。因此要与 retrieval 和 source readiness 联合看。

评估方法:

上线决策:

• 如果 faithfulness 低, 不应扩大用户范围, 即使答案看起来流畅。
• 高风险场景中 unsupported critical claim 必须为 0。
• 如果 faithfulness 高但用户仍不满意, 可能是 query set、gold docs、context completeness 或 UX 问题。

3.6 Citation Support

Citation support 衡量引用是否真实支撑回答中的关键断言。它回答的是:

引用是证据, 还是装饰?

成熟系统不满足于答案末尾列几个链接, 而要做到 claim-level citation:

Citation support 指标:

PM 解读:

• 对员工助手, 引用可以提升信任和采纳。
• 对受监管流程, 引用是上线证据和审计证据, 不是体验增强项。

BA 解读:

• BA 应定义哪些断言必须引用: 金额阈值、资格条件、拒绝原因、合规要求、例外流程、客户沟通口径。

架构师解读:

• citation 要从 ingestion 就开始设计: page、section、table row、chunk_id、source_version、permission_group 都要保留。

3.7 Permission / Version Tests

权限和版本测试是金融零售 RAG 的强制门禁。它们不是普通准确率指标, 而是风险控制。

上线决策:

• 权限泄漏、草稿误用、过期关键政策误引都应定义为 critical failure。
• 任何 critical failure 未关闭前, 不进入生产或只允许隔离环境演示。
• 版本测试要纳入每次 ingestion、chunking、embedding、rerank、prompt 或模型变更后的回归。

---

4. RAGAS / Retrieval Metrics / LLM Judge 的 PM、BA、架构师解读

RAGAS 的关键价值是把 RAG 评估拆成多个可自动化或半自动化维度, 例如 faithfulness、answer relevance、context precision、context recall 等。它不是上线决策的全部, 但很适合作为评估框架的起点。

4.1 不要只堆指标: 指标要回答上线问题

4.2 PM 解读: 指标如何支撑产品决策

PM 不需要把每个公式背下来, 但必须能把指标翻译成上线策略:

PM 的上线 memo 应避免写“准确率达到 85% 所以上线”。更好的表达是:

在 180 条 golden set 中, 高频客服场景 faithfulness 94%、citation accuracy 96%、无 critical permission/version failure; 但信贷拒绝原因场景 unsupported claim 仍有 3 条, 因此建议先上线客服知识助手 pilot, 信贷场景保留人工复核并继续修复。

4.3 BA 解读: 指标如何反推需求和样本

BA 的关键工作是让指标背后有业务语义。

BA 不只是写用户故事, 还要写 eval stories:

作为 KYC 审核员,
当我询问非居民企业开户缺少哪些材料时,
系统必须基于当前有效 KYC 政策和客户类型定义返回缺件清单,
每个缺件项必须引用政策章节,
如果客户地区或实体类型不明确, 系统必须要求补充信息而不是猜测。

4.4 架构师解读: 指标如何驱动系统设计

架构师要把指标映射到可观测性和改造点。

架构师的目标不是让所有指标一次达标, 而是让每个失败都有 trace、owner 和修复路径。

4.5 LLM Judge 的使用边界

LLM judge 适合:

• 判断回答是否覆盖关键点。
• 初筛 faithfulness、groundedness、tone、completeness。
• 对比两个 prompt、两个 retriever、两个 reranker。
• 给 failure tags 和 triage reason。

LLM judge 不适合作为唯一依据:

• 最终合规判断。
• AML SAR/STR 是否提交。
• 信贷拒绝是否符合法规。
• 权限是否泄漏。
• 版本是否当前有效。
• 引用是否真实可打开。

推荐组合:

---

5. GraphRAG / Knowledge Graph RAG 决策

GraphRAG 不是“更高级的 RAG”默认替代品。它适合知识关系复杂、问题跨实体、跨文档、跨社区、跨路径时使用。普通 RAG 能解决的问题, 不要为了图谱而图谱。

5.1 普通 RAG 足够的情况

普通 hybrid RAG 通常足够:

判断原则:

如果答案的关键证据能通过 1-3 个权威 chunk 找到, 且关系不影响结论, 先用普通 RAG。

5.2 需要实体关系的情况

需要 entity relationship 的信号:

GraphRAG 在这些场景中的价值:

• entity resolution: 识别同一客户、商户、设备或受益人。
• relationship retrieval: 根据关系路径找到证据。
• path explanation: 把多跳路径转成可审计解释。
• risk context expansion: 从一个告警扩展到相关实体和历史模式。

5.3 需要社区摘要的情况

Microsoft GraphRAG 的核心启发之一是将文本转成实体和关系, 构建图谱, 再通过社区检测和摘要支持全局性、跨文档问题。社区摘要适合回答“一个知识域整体上有哪些主题、风险、模式、群组”。

适合 community summaries:

社区摘要的治理要求:

• 摘要要记录生成时间、输入来源范围、社区算法版本和摘要模型版本。
• 社区摘要不能覆盖底层证据; 高风险结论必须能 drill down 到节点、边和文档。
• 社区摘要需要定期刷新, 否则会变成新的过期知识源。

5.4 需要多跳路径的情况

Multi-hop path 是 GraphRAG 的高价值区域。典型问题不是“找一段政策”, 而是:

这个商户为什么被标为高风险?
因为它与三个被关停商户共享设备指纹,
其受益人与高风险行业实体存在历史关联,
并且近 30 天交易模式与某 AML typology 的路径相似。

多跳路径适合:

• AML investigation: customer -> account -> counterparty -> jurisdiction -> typology。
• Merchant risk review: merchant -> owner -> device -> linked merchant -> chargeback pattern。
• Credit policy assistant: borrower -> employer -> income type -> policy exception -> required document。
• KYC checklist: entity type -> ownership structure -> jurisdiction -> required document -> enhanced due diligence。

多跳路径的风险:

• 路径越长, 误连和误解风险越高。
• 图谱边的来源、置信度和更新时间必须可见。
• 不能把“路径存在”直接等同于“风险成立”。
• 高风险结论要保留人工判断, GraphRAG 输出应是 evidence map 和 rationale draft。

5.5 GraphRAG 决策矩阵

推荐路径:

1. 先做普通 RAG baseline, 建立 query set、gold docs、retrieval metrics 和 answer eval。
2. 识别普通 RAG 失败中是否存在“关系缺失”而不是“检索差”。
3. 如果失败主要来自实体歧义、多跳关系、跨文档主题, 再引入 graph-enhanced RAG。
4. 只有当业务问题需要全局社区摘要和路径解释时, 才建设 full GraphRAG。

---

6. 金融零售场景 Playbook

6.1 AML Investigation

关键设计:

• AI 输出应是 investigation assistance, 不是监管报送决策。
• 每个风险描述必须引用交易证据、typology 或 case source。
• 如果缺少 KYC、对手方或资金来源信息, 应显式列为 missing evidence。
• 图谱路径必须显示边的来源和时间, 不允许把弱关联写成确定事实。

6.2 KYC Checklist

关键设计:

• query set 必须覆盖 individual、sole proprietor、corporate、trust、non-resident、high-risk country。
• gold docs 要精确到文件清单表格行和 EDD 条款。
• 答案应区分“必须提交”“条件触发”“建议人工确认”。

6.3 Credit Policy Assistant

关键设计:

• AI 不能自动做授信裁决, 只能解释政策和起草人工复核材料。
• adverse action 相关输出必须走更严格 rubric 和专家复核。
• 如果资料来自模型评分而非政策条款, 输出要清楚区分“政策依据”和“模型信号”。

6.4 Merchant Risk Review

关键设计:

• Merchant risk 是 GraphRAG 的强候选, 因为关系本身经常是核心证据。
• 图谱边要有 provenance: 哪个系统、哪个字段、什么时间、置信度多少。
• 输出要区分 direct evidence、indirect link、risk indicator、required review action。

6.5 Retail Product Knowledge Assistant

关键设计:

• 内部依据与对客话术要分层, 不能把内部操作细节直接对客输出。
• 促销和费率表要 table-row citation, 不能只引用整个 PDF。
• 适合先做低风险 pilot, 快速积累 feedback loop 和 retrieval failure taxonomy。

---

7. 30 天 Lab: Retrieval / Eval / GraphRAG 作品集训练

Lab 目标: 用 30 天做出一套可展示的“金融零售知识助手评估与 GraphRAG 决策包”。建议选择一个主场景, 如 KYC checklist、merchant risk review 或 retail product knowledge assistant。

30 天验收标准:

• 有一个完整 query set, 不是零散问题。
• 每条样本至少包含 gold docs、expected behavior、risk tier 和 failure tags。
• 能解释普通 RAG 为什么够用, 或 GraphRAG 为什么必要。
• 有 release gate, 且 critical failure 明确为阻断项。
• 有作品集材料, 能展示 PM、BA、架构师三种视角。

---

8. 模板

8.1 Retrieval Eval Matrix

使用方式: 每一行是一条 query 的评估结果。初期可手工填, 后续可由 eval runner 自动生成。

评分建议:

8.2 GraphRAG Decision ADR

# ADR: [场景名] 是否采用 GraphRAG

## Status
Accepted for pilot / Deferred / Rejected for current scope

## Context
- 业务场景: merchant risk review
- 用户: acquiring risk analyst
- 当前 RAG baseline: 普通 hybrid RAG 在政策解释上表现稳定, 但在 linked merchant 和 shared device 风险解释上失败较多
- 关键失败证据: 30 条 query 中 8 条需要跨商户、设备、实控人关系; 普通 RAG 只能找到单个文档, 无法解释路径

## Decision
采用 graph-enhanced RAG, 暂不采用 full GraphRAG。

## Rationale
- 需要实体关系: merchant、beneficial_owner、device、address、chargeback_case
- 需要多跳路径: merchant -> device -> linked merchant -> terminated merchant file
- 不需要全局社区摘要作为第一阶段能力, 因为 pilot 用户主要审单, 不是做全域风险研究
- 图谱边可以从现有 onboarding、device fingerprint、case management 中获得 provenance

## Alternatives Considered
| 方案 | 优点 | 风险 | 结论 |
|---|---|---|---|
| 普通 hybrid RAG | 成本低, 上线快 | 无法解释 linked entity path | 不足以覆盖核心风险问题 |
| graph-enhanced RAG | 能保留文档问答并加入关系证据 | 需要 entity resolution 和 edge provenance | 采用 |
| full GraphRAG | 支持社区摘要和全局主题 | 构建和治理成本高 | 留到第二阶段 |

## Scope
- 纳入实体: merchant、owner、device、address、case、MCC
- 纳入关系: owns、shares_device、shares_address、has_chargeback_case、matches_typology
- 不纳入范围: 自动拒绝商户、自动关闭 case、客户外部沟通

## Evaluation
- path existence accuracy >= 95%
- edge provenance coverage = 100%
- path faithfulness critical failure = 0
- permission leakage = 0
- risk explanation unsupported claim = 0

## Consequences
- 需要建立 entity/edge data contract
- 需要维护 graph refresh job 和边来源审计
- 需要新增 path-level eval 和专家复核
- 需要 UI 展示路径证据和底层来源

8.3 Knowledge Source Readiness Checklist

评分建议: 1 = 不可用于 pilot, 3 = 可用于受控 pilot, 5 = 可进入生产评审。

Readiness gate:

8.4 Failure Triage Table

使用方式: 每个失败样本都要定位到链路环节, 否则无法形成可执行 backlog。

Failure severity:

---

9. Release Gate 设计

Retrieval/Eval/GraphRAG 项目应把上线门禁写清楚。门禁不是“平均分达标”, 而是分层证据。

发布建议:

• Prototype: 可使用公开或脱敏资料, 允许指标不完整, 但必须标明不可用于真实决策。
• Controlled pilot: 必须有 query set、gold docs、retrieval eval、citation check、权限/版本测试和人工复核。
• Production review: 必须有 release gate、monitoring、incident workflow、owner model、audit replay。
• High-risk workflow: AML、信贷、KYC、商户风险等必须保留 human-in-the-loop 和专家抽检。

---

10. 面试表达

10.1 30 秒版本

我不会把企业 RAG 只理解成向量检索。我的做法是先把知识源产品化, 明确 source-of-truth、版本、权限和引用锚点; 然后建立 retrieval eval stack, 用 query set、gold docs、chunk recall、context precision、faithfulness、citation support、权限和版本测试来做发布门禁。如果问题涉及实体关系、多跳路径或全局主题, 我会用 ADR 判断是否需要 GraphRAG, 而不是默认上图谱。

10.2 2 分钟版本

在企业知识助手里, 最危险的问题不是模型不会说话, 而是它基于错误资料、错误权限或错误版本说得很流畅。我会从三个层面设计。

第一是知识源治理。把政策、SOP、FAQ、案例、表格都当成 AI data product, 明确 owner、source-of-truth、metadata、effective date、permission group、citation anchor 和更新机制。

第二是 retrieval eval。每个场景建立 query set 和 golden set, 为每条 query 标注 gold docs、hard negatives、expected behavior、risk tier。然后分别评估 chunk recall、context precision、answer faithfulness、citation support、refusal、permission 和 version。这样最终答案错了时, 能定位是没检到、检错了、上下文混乱、模型幻觉、引用错配还是权限/版本问题。

第三是架构决策。普通 RAG 适合政策解释、KYC checklist、客服知识库这类答案主要来自文档片段的任务。GraphRAG 适合 AML、商户风险、复杂 KYC ownership 这类关系本身就是证据的任务。我会先用普通 RAG baseline 验证失败是否来自关系缺失, 再决定 graph-enhanced RAG 或 full GraphRAG。

上线时我不会只说一个准确率, 而会用 release gate: 权限泄漏为 0、critical unsupported claim 为 0、过期关键政策误引为 0、citation accuracy 达标、高风险样本专家复核通过。这样 PM 能决定 pilot 范围, BA 能维护业务样本, 架构师能设计可审计系统。

10.3 CTO 深挖

10.4 PM 深挖

10.5 BA 深挖

---

11. Source Anchors

---

12. 一页总结

Retrieval / Eval / GraphRAG 能力的成熟标志, 不是会搭一个问答 demo, 而是能回答下面这些问题:

• 正确知识源是谁拥有的, 哪个版本当前有效, 谁有权访问?
• 对哪些 query, 哪些 gold docs 必须被召回?
• chunk recall、context precision、faithfulness、citation support 分别是多少?
• 无答案、权限、版本、冲突、hard negative 是否有测试?
• LLM judge 评什么, deterministic checks 评什么, 专家评什么?
• GraphRAG 是因为关系证据必要而引入, 还是为了技术包装而引入?
• 失败能否定位到 source、chunk、retrieval、rerank、context、generation、citation、graph path 或权限层?
• release gate 是否能支撑 pilot、production review 和高风险场景审计?

对 AI PM, 这是一套产品上线证据。 对 AI BA, 这是一套业务需求和验收资产。 对 AI Architect, 这是一套可治理、可观测、可审计的知识系统架构。

作品集最有说服力的不是“我用了哪个模型”, 而是“我能把企业知识从资料堆变成可信 AI 能力, 并证明它在什么边界内可以上线”。