AI 底层逻辑 / 经典论文
Retrieval-Augmented Generation：RAG 原理
- Paper: https://arxiv.org/abs/2005.11401
399 行ai-foundations/papers/02-retrieval-augmented-generation.md
Retrieval-Augmented Generation 论文与系统架构解读
Source Anchors
- Paper: https://arxiv.org/abs/2005.11401
- 原论文: Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020.
- 关键词: RAG, retriever, generator, parametric memory, non-parametric memory, knowledge-intensive NLP.
读这篇论文的目标: PM/BA/架构师分别要学到什么
PM 视角
- PM 要理解 RAG 不是“给大模型接一个搜索框”，而是一种让 AI 产品基于企业知识回答的能力架构。
- 它的产品价值是把“模型会说”升级为“模型能基于正确资料、正确权限、正确版本回答”。
- PM 需要识别适用场景: 政策问答、制度解释、客服辅助、审查辅助、调查辅助、研究助理。
- PM 也要识别不适用场景: 没有可信资料源、答案必须由规则引擎确定、需要强实时交易执行、权限边界不清。
- 好的 RAG 需求不应只写“上传文档后问答”，而要写清楚来源、引用、拒答、权限、版本、反馈和评估。
- PM 在面试中要能讲出闭环: 用户问题 -> 检索证据 -> 生成答案 -> 引用来源 -> 用户反馈 -> 评估迭代。
BA 视角
- BA 要把“知识问答”拆成可验证的业务需求和数据需求。
- 关键不是模型能不能回答，而是哪些资料允许被用来回答、哪个版本有效、什么答案必须引用。
- BA 要定义问题类型: 查找型、解释型、比较型、流程指导型、合规判断型、案例总结型。
- BA 要梳理知识资产: 政策文档、SOP、FAQ、产品手册、合同模板、监管规则、审批记录、案例库。
- BA 要设计元数据: 业务线、地区、产品、客户类型、生效日期、失效日期、版本、密级、Owner。
- BA 要准备验收集: 高频问题、边界问题、无答案问题、过期政策问题、权限隔离问题、冲突资料问题。
架构师视角
- 架构师要理解论文中的基本抽象: retriever、generator、passages、marginalization。
- 架构师还要把论文原型落到企业系统: ingestion、parsing、chunking、embedding、index、rerank、context packing、generation、citation、eval、monitoring。
- 企业 RAG 的难点不只是向量数据库，而是端到端的信息治理链路。
- 权限过滤必须在检索前或检索中发生，不能等生成后再遮蔽。
- 架构师要把失败类型变成可观测性指标: 无召回、错召回、陈旧源、权限泄漏、引用错配、上下文冲突、幻觉。
- 关键架构决策必须沉淀为 ADR: 检索策略、chunk 粒度、reranker、引用策略、版本治理、评估门禁。
RAG 要解决的问题: Parametric Memory vs Non-Parametric Memory, Knowledge-Intensive Tasks
Parametric Memory
- Parametric memory 指模型权重中隐含保存的知识。
- 例如模型知道某些事实，是因为训练数据被压缩进参数。
- 优点是推理时快速，不依赖外部系统。
- 缺点是不可直接查看来源、难以更新、可能过时、难以审计。
- 在金融零售场景，参数记忆不能作为正式政策解释或合规判断的唯一依据。
- 如果模型回答“该客户是否需要额外 KYC 文件”，没有来源版本和适用范围，就无法通过审计。
Non-Parametric Memory
- Non-parametric memory 指模型外部的可检索知识库。
- 原论文中主要是 Wikipedia passages 的 dense vector index。
- 企业场景中可以是政策库、流程库、合同库、工单库、监管规则库、知识图谱。
- 优点是可更新、可删除、可分权、可审计、可引用。
- 缺点是要维护 ingestion、索引、检索质量、权限过滤、版本管理和监控。
- RAG 的核心思想是把生成模型的语言能力与外部记忆的可治理能力结合起来。
Knowledge-Intensive Tasks
- Knowledge-intensive tasks 是需要外部事实知识才能完成的任务。
- 典型任务包括开放域问答、事实校验、实体解释、复杂知识问答、文档摘要。
- 企业中的例子包括政策解释、KYC 文件判断、AML typology 查询、贷款准入说明、客服话术生成。
- 这些任务的答案会随时间、地区、产品线和监管要求变化，因此天然适合外部知识检索。
- 原论文的意义在于证明: 预训练 seq2seq 模型如果结合检索式外部记忆，可以在知识密集型任务上更可靠。
Original RAG Architecture: Retriever, Generator, Retrieved Passages, Marginalization Intuition
总体结构
- 原始 RAG 由 retriever 和 generator 两部分组成。
- Retriever 根据输入问题 x 找相关 passages z。
- Generator 在问题 x 和 passage z 条件下生成输出 y。
- 可以把 retriever 理解成“查资料的人”，generator 理解成“基于资料写答案的人”。
- 论文使用 dense retrieval 思路，把问题和文档段落映射到向量空间。
- 检索阶段返回 top-k passages，生成阶段利用这些 passages 形成回答。
Retriever
- Retriever 学习的是 p_eta(z | x): 给定问题 x 时选择 passage z 的概率。
- 它不是简单关键词搜索，而是语义检索。
- 原论文的外部记忆是大规模 Wikipedia dense index。
- 企业实现中，retriever 还必须处理 query rewrite、metadata filter、permission filter、hybrid retrieval、candidate merge。
- Retriever 决定 RAG 的事实上限: 正确资料没有召回，generator 再强也只能猜。
- 因此企业 RAG 评估必须单独看 retrieval recall，而不能只看最终答案。
Generator
- Generator 学习的是 p_theta(y | x, z): 基于问题和 passage 生成答案。
- 它利用预训练语言模型的表达能力，把证据组织成自然语言。
- Generator 的价值是综合、解释、改写和结构化输出。
- 它的风险是在证据不足时补充未被来源支持的内容。
- 企业 RAG 要把 generator 定位为“受控的证据解释器”，而不是“全知专家”。
- 高风险场景应要求只基于上下文回答、必须引用、资料不足时拒答。
Retrieved Passages
- Retrieved passages 是被检索出来的一组候选证据。
- 原论文中 passage 是 Wikipedia 文本片段。
- 企业中 passage 可能来自 PDF 段落、网页、知识库条目、法规条款、表格、工单记录。
- Passage 不只是文本，还应带 metadata、权限、版本、来源定位和有效期。
- 如果 chunk 太短，语义不完整；如果 chunk 太长，召回不精确且上下文成本高。
- 如果 metadata 不完整，后续无法做权限过滤、版本过滤、引用和审计。
Marginalization Intuition
- 论文中的关键直觉是: 模型不必只相信一个 passage。
- 它可以在 top-k passages 上对 latent document 做 marginalization。
- 通俗说，就是“多个候选资料都可能支撑答案，模型对这些可能性加权综合”。
- 这样可以缓解 top-1 检索不完美的问题。
- 但企业系统不能只停留在概率综合，因为用户和审计方要知道最终答案依据哪些来源。
- 现代 RAG 通常把这个思想工程化为 top-k retrieval、rerank、context packing、citation verification。
RAG-Sequence vs RAG-Token Intuition
RAG-Sequence
- RAG-Sequence 假设整段输出主要基于同一个 passage 或同一组候选 passages。
- 它对每个 passage 生成完整答案概率，再在 passage 维度加权。
- 直觉是: “为整个回答选择资料，然后写完整回答。”
- 它适合答案相对集中、可由一个主要条款支撑的问题。
- 现代常见 RAG pipeline 更接近这种模式: 检索若干段落，拼上下文，一次生成。
- 优点是简单、稳定、容易做引用；缺点是处理多事实组合时灵活性有限。
RAG-Token
- RAG-Token 允许生成每个 token 时基于不同 passage。
- 直觉是: “答案的不同部分可以从不同资料取证据。”
- 它适合多跳问题、比较问题、跨文档综合问题。
- 例如比较两个贷款产品在准入、费用、地区限制上的差异。
- 工程上 RAG-Token 更复杂，也更难解释每个 token 的来源。
- 企业系统通常不逐 token 实现，但要吸收其思想: 每个关键事实点都应能绑定自己的引用。
Modern Enterprise RAG Architecture
End-to-End Pipeline
- Ingestion: 接入 SharePoint、Confluence、PDF、Word、HTML、邮件归档、监管网站、知识库 API。
- Parsing: 解析标题、正文、表格、页码、脚注、OCR、修订痕迹，避免把格式噪声变成知识噪声。
- Chunking: 按标题层级、段落、语义边界、表格结构切分，并保留父子层级。
- Metadata: 记录 document_id、chunk_id、title、section、page、url、owner、version、effective_date、expiry_date。
- Domain metadata: 金融场景还需要 region、business_line、product_code、customer_segment、confidentiality。
- Embedding: 将 chunk 和 query 转成向量，模型选择要评估中文、术语、成本、隐私、可复现性。
- Index: 建立向量索引、关键词倒排索引、元数据索引，支持增量更新、删除、回滚和版本对比。
- Hybrid retrieval: 结合 dense vector 与 BM25，兼顾语义相似和产品代码、法规编号、金额阈值等精确匹配。
- Permission filtering: 按 RBAC/ABAC 在检索前或检索中应用，不允许模型看到无权资料。
- Rerank: 对初召回候选重新排序，降低相似但错误资料排在前面的风险。
- Context packing: 在 token 预算内组织证据，去重、保留多样性、保留引用锚点、优先有效版本。
- Generation: 要求模型只基于上下文回答，输出结论、依据、适用范围、例外、不确定项和下一步。
- Citation: 将关键断言连接到 source_id、version、page、section、chunk。
- Eval: 分别评估检索、答案、引用、拒答、权限、版本、延迟和成本。
- Monitoring: 监控 zero-hit rate、retrieval score、rerank score、citation coverage、拒答率、用户反馈、索引新鲜度。
设计要点
- Enterprise RAG 的第一原则是 grounded answer，而不是 fluent answer。
- 资料治理质量决定系统天花板: 过期、重复、无 owner 的资料会放大模型风险。
- Hybrid retrieval 通常比纯向量更适合金融零售，因为金融知识中有大量精确编号和术语。
- Context packing 不是简单拼接 top-k，而是按任务组织证据: 定义、规则、例外、示例、冲突条款。
- Citation 不是答案末尾贴链接，而是关键事实点可追溯到具体版本和位置。
- Eval 必须进入发布门禁: 模型、prompt、chunking、index、reranker 任一变更都可能影响答案质量。
- Monitoring 要能定位错误来自哪里: 没检到、检错了、资料旧了、上下文冲突了、生成幻觉了、引用错了。
RAG Failure Taxonomy
| Failure | 表现 | 典型原因 | 治理手段 |
|---|---|---|---|
| No retrieval | 知识库有答案但系统说找不到 | chunking 差、query 改写差、过滤过严 | hybrid retrieval、同义词、召回评估 |
| Wrong retrieval | 检到相似但错误资料 | 产品名相似、地区相似、旧政策相似 | metadata filter、rerank、负样本评估 |
| Stale source | 引用过期政策 | 版本字段缺失、默认不过滤旧版本 | effective_date、expiry_date、版本状态 |
| Permission leak | 用户看到无权资料 | 检索后过滤、索引混租、缓存污染 | 检索前权限过滤、租户隔离、权限日志 |
| Citation mismatch | 引用不支持答案断言 | 后处理随意贴来源、句子未校验 | claim-level citation verification |
| Context conflict | 上下文含冲突资料 | 新旧政策混入、地区混入、草案混入 | 冲突检测、适用范围澄清、人工确认 |
| Answer hallucination | 资料不足仍编答案 | prompt 弱、模型过度自信、无拒答机制 | groundedness check、低信心拒答、verifier |
Taxonomy 的使用方式
- PM 用它定义用户体验: 什么时候拒答，什么时候提示资料不足，什么时候要求人工确认。
- BA 用它设计验收样例: 每类 failure 至少有测试问题。
- 架构师用它设计 trace: 每次回答要能回放 query、候选、过滤、上下文、答案、引用。
RAG vs Fine-Tuning vs Long Context vs Knowledge Graph vs Search
| 方案 | 适合解决 | 优势 | 局限 | 金融零售判断 |
|---|---|---|---|---|
| RAG | 基于企业资料的问答、解释、总结 | 可更新、可引用、可权限控制 | 检索链路复杂 | 政策、流程、制度问答首选 |
| Fine-tuning | 风格、格式、分类、领域表达 | 输出稳定，行为可塑 | 不适合频繁更新事实 | 可训练口径和格式，不宜存政策事实 |
| Long context | 单个大文档或案件包阅读 | 架构简单，少建索引 | 成本高，版本和权限难治理 | 适合单案审阅，不适合全企业知识库 |
| Knowledge graph | 实体关系、规则关系、路径解释 | 结构化、可推理 | 建模成本高，文本覆盖弱 | 与 RAG 互补，适合 AML 和客户关系 |
| Search | 找文档、列表排序 | 成熟、透明、可控 | 不直接生成解释 | 可作为 RAG 底座和 fallback |
取舍原则
- 事实频繁变化且必须引用: 优先 RAG。
- 只需统一输出格式和语气: fine-tuning 或 prompt 足够。
- 单个文档很长但范围固定: long context 可先试。
- 需要关系推理和规则路径: knowledge graph + RAG。
- 用户只想找文件而不是生成解释: search 足够。
- 成熟企业架构通常不是五选一，而是 search + RAG + graph + eval 的组合。
Financial Retail Use Cases
Compliance Policy Assistant
- 用户: 合规经理、产品经理、分行运营主管、客服质检。
- 问题: “某信用卡营销话术是否符合最新监管要求？”
- 知识源: 监管规则、内部合规政策、营销审批规范、历史违规案例。
- RAG 价值: 快速定位条款，生成解释和引用。
- 风险: 过期监管规则、地区差异、草案误用、引用错配。
KYC Document Review
- 用户: KYC 审核员、客户经理、运营后台。
- 问题: “该客户类型开户还缺哪些文件？”
- 知识源: KYC 政策、客户类型定义、文件清单、例外流程、监管要求。
- RAG 价值: 把分散政策转成缺件说明。
- 风险: PII 泄漏、客户类型误判、不同地区要求冲突。
AML Investigation
- 用户: AML 调查员、风险分析师。
- 问题: “这个告警为什么可能涉及分层交易？”
- 知识源: AML typology、调查手册、监管通报、历史 SAR 案例、交易图谱摘要。
- RAG 价值: 解释告警理由，提示调查路径，引用 typology。
- 风险: 把相似案例当定论、泄露调查信息、生成法律结论。
Customer Service
- 用户: 一线客服、智能客服、网点员工。
- 问题: “客户问提前还款是否收手续费，该怎么解释？”
- 知识源: 产品政策、费率表、FAQ、客服话术、例外处理流程。
- RAG 价值: 降低查找成本，提高口径一致性。
- 风险: 错误引用费率、忽略所在地、把内部话术直接对客。
Lending Policy Explanation
- 用户: 信贷产品经理、审批人员、客户经理。
- 问题: “为什么这个客户不符合某贷款产品准入？”
- 知识源: 准入政策、风险规则、收入证明要求、抵押品规则、审批例外。
- RAG 价值: 把复杂政策解释成拒绝原因和补件建议。
- 风险: 生成歧视性解释、暴露模型细节、混淆政策规则与评分模型。
Requirements-to-Eval Mapping for RAG
| 需求 | 测试方式 | 指标 | 验收示例 |
|---|---|---|---|
| 能回答政策问题 | 高频政策问答集 | Answer correctness | >= 90% 人工判定正确 |
| 必须基于来源 | 检查答案关键断言 | Citation coverage | 关键断言 100% 有引用 |
| 引用必须准确 | 判断引用是否支撑断言 | Citation accuracy | >= 95% |
| 找不到资料时拒答 | 无答案问题集 | Refusal accuracy | >= 90% 正确拒答 |
| 不用过期政策 | 旧版本干扰测试 | Freshness accuracy | 100% 不误引过期有效性 |
| 权限隔离 | 多角色同问 | Permission leakage rate | 高危泄漏为 0 |
| 支持地区差异 | 多地区政策问题 | Metadata filter accuracy | >= 95% |
| 支持复杂综合 | 多文档多事实问题 | Groundedness | >= 85% |
| 响应可接受 | P95 延迟 | Latency | 内部助手 P95 < 8s |
| 成本可控 | 每问题成本 | Cost per answer | 符合业务预算 |
Eval 原则
- 评估集要有 gold answer、gold source、allowed source version 和 expected refusal。
- 检索评估与答案评估要分开；retrieval recall 不足时，优化 generator 没有意义。
- 样例要覆盖高频、长尾、边界、恶意、权限、过期、冲突。
- Eval 应成为 CI/CD 门禁，而不是上线前手工抽查。
Architecture ADRs for Enterprise RAG
| ADR | 决策 | 理由 | 后果 |
|---|---|---|---|
| RAG vs Fine-tuning | 政策、流程、监管资料类问答采用 RAG | 资料频繁更新，需要引用、权限和审计 | 必须建设 ingestion、索引、评估和监控链路 |
| Chunking Strategy | 使用结构感知 chunking，保留标题层级、页码、父子关系 | 金融政策依赖章节语境，固定长度切分容易丢适用范围 | parsing 复杂度上升，但引用和召回更稳 |
| Retrieval Strategy | 采用 hybrid retrieval，结合 dense vector、BM25、metadata filter | 金融术语、产品代码、法规编号需要精确匹配 | 需要候选合并、去重、分数归一和 rerank |
| Permission Model | 检索前或检索中执行 ABAC/RBAC 过滤 | 生成后遮蔽不能防止模型读取敏感上下文 | 索引、查询、缓存和日志都要携带权限属性 |
| Citation Strategy | 每个关键断言绑定 source_id、version、page 或 section | 金融场景要求可审计，泛泛列参考资料不够 | prompt、context packing、后处理和 UI 都要支持 claim-source mapping |
| Source Versioning | 所有来源按版本入库，默认只检索当前有效版本 | 过期政策是高风险错误来源 | ingestion 必须处理生效日期、失效日期、撤回状态和 owner |
| Eval Gate | 模型、prompt、索引、chunking、reranker 任一变更都跑回归评估 | RAG 质量来自链路组合，局部变更可能导致全局退化 | 需要评估集、自动报告、发布门禁和异常回滚 |
| Human-in-the-loop | 合规、AML、信贷解释等高风险答案进入人工复核或标注为辅助建议 | 模型输出不应替代最终合规或授信裁决 | 产品流程要支持采纳、驳回、备注、反馈回流和审计 |
Security and Governance: Access Control, PII, Source Version, Audit Log, Prompt Injection
Access Control
- RAG 权限要覆盖文档、chunk、索引、检索结果、上下文、日志、引用跳转。
- 推荐用 ABAC 表达地区、部门、岗位、客户归属、密级、用途。
- 用户无法打开原文时，模型也不应能检索该原文。
- 缓存必须按用户权限、租户和资料版本隔离。
PII
- PII 包括姓名、证件号、账号、地址、电话、交易明细、设备标识。
- Ingestion 阶段应识别、标注和必要时脱敏 PII。
- 评估样本、日志、反馈样本要遵守最小化保存原则。
- AML/KYC 场景要区分“调查员可见”和“答案中不应外显”。
Source Version
- 每个答案应知道自己引用的是哪个 source version。
- 文档更新后，历史答案应显示“基于当时版本”。
- 监管政策版本治理要包含发布机构、生效日期、废止日期、内部审批状态。
Audit Log
- 审计日志应记录用户、时间、问题、权限上下文、检索候选、过滤原因、上下文、模型版本、prompt 版本、答案和引用。
- 日志本身也可能包含敏感信息，需要脱敏、访问控制和保留期限。
- 高风险场景还应记录人工复核结论。
Prompt Injection in Retrieved Docs
- Retrieved docs 可能包含恶意文本，例如要求模型忽略系统指令或泄露资料。
- 防护原则是把检索内容视为不可信数据，而不是系统指令。
- 可用手段包括 prompt hierarchy、来源信任分级、可疑指令过滤、content sanitization、后置 policy checker。
- 对外部网页和用户上传文档尤其要小心。
10 Interview Questions with Answer Outlines
| 问题 | 答案要点 |
|---|---|
| 1. RAG 解决了大模型的什么问题？ | 参数记忆不可审计、难更新、可能过时；RAG 用外部知识库提供可更新、可引用、可治理的事实依据。 |
| 2. Parametric memory 和 non-parametric memory 有何区别？ | 前者在模型权重中，推理快但难编辑；后者在外部知识源中，可更新可审计但需要检索和治理。 |
| 3. RAG-Sequence 和 RAG-Token 的区别？ | RAG-Sequence 为整段答案选资料；RAG-Token 允许答案不同部分用不同资料；企业要支持多事实多引用。 |
| 4. 为什么企业 RAG 不能只用向量检索？ | 金融知识有产品代码、法规编号、金额阈值、地区和版本限制；hybrid retrieval 加 metadata filter 更稳。 |
| 5. 最危险的 RAG failure 是什么？ | 权限泄漏、过期来源、引用错配和错误召回都高危；靠权限前置、版本治理、citation verification 和评估门禁控制。 |
| 6. 如何评价 RAG 系统？ | 分层评估 retrieval recall、MRR、metadata filter accuracy、answer correctness、groundedness、citation accuracy、refusal accuracy、延迟和成本。 |
| 7. RAG 和 fine-tuning 如何取舍？ | 频繁变化且需引用的事实用 RAG；输出风格、格式、分类行为可 fine-tune；常见组合是 RAG 管知识，fine-tuning 管表达。 |
| 8. 如何防止 retrieved docs prompt injection？ | 把检索内容当不可信数据，声明文档不是指令，并配合来源分级、过滤、sanitization 和后置安全检查。 |
| 9. 金融客服为何区分内部依据和对客话术？ | 内部政策可能含不适合对客展示的操作细节；对客话术要简洁、合规、中性，二者权限和目标不同。 |
| 10. RAG 答错时如何排查？ | 依次检查召回、rerank、context packing、版本、权限、prompt、groundedness、citation。 |
Common Misunderstandings
- 误解: 有向量数据库就是 RAG。纠正: 向量库只是 RAG 的索引层之一。
- 误解: RAG 可以完全消除幻觉。纠正: 错检索、冲突上下文和弱引用仍会导致幻觉。
- 误解: 文档越多越好。纠正: 未治理文档越多，错误召回和过期来源风险越高。
- 误解: 长上下文可以替代 RAG。纠正: 长上下文不能替代权限、版本、引用和资料运营。
- 误解: Fine-tuning 可以把企业知识都学进去。纠正: 频繁变化且需审计的事实不适合只放进参数。
- 误解: 引用只要看起来像链接就行。纠正: 引用必须真实支撑答案断言。
- 误解: RAG 准确率只看最终答案。纠正: 要拆成 retrieval、rerank、context、generation、citation、refusal 多层指标。
- 误解: 把全部文档给模型更聪明。纠正: 权限和最小必要原则是企业 RAG 底线。
- 误解: RAG 上线后就稳定。纠正: 文档、模型、prompt、用户问题都会变化，需要持续运营。
- 误解: RAG 只是技术团队的事。纠正: PM 定义价值，BA 定义知识和规则，架构师定义边界和治理。
1-Page Executive Summary
- RAG 的本质是把大模型生成能力和外部知识库的可检索、可更新、可治理能力结合起来。
- 原论文提出 retriever 找 passage，generator 基于 passage 生成答案，并通过 marginalization 处理检索不确定性。
- RAG 解决的是 knowledge-intensive tasks 中的事实来源问题，不只是提升语言流畅度。
- Parametric memory 在模型参数中，难更新、难审计；non-parametric memory 在外部知识库中，可版本化、权限化和引用。
- 企业 RAG 的核心目标是 grounded answer: 答案有依据、依据可追溯、资料可更新。
- 现代企业 RAG 需要 ingestion、parsing、chunking、metadata、embedding、index、hybrid retrieval、rerank、context packing、generation、citation、eval、monitoring。
- 主要失败类型包括 no retrieval、wrong retrieval、stale source、permission leak、citation mismatch、context conflict、answer hallucination。
- 金融零售非常适合 RAG，因为政策、监管、KYC、AML、客服和信贷解释都依赖动态文本资料。
- 金融场景也要求更强治理: 权限前置、PII 控制、版本有效性、审计日志和人工复核。
- RAG 不应被理解为“向量数据库 + LLM”，而应被设计成知识治理与答案生成平台。
- PM 负责场景价值、用户体验、引用要求和拒答策略。
- BA 负责知识源、元数据、业务规则、验收样例和评估集。
- 架构师负责端到端链路、ADR、安全边界、可观测性和发布门禁。
- RAG 与 fine-tuning、long context、knowledge graph、search 并非互斥。
- 稳健架构通常把 search 作为底座，RAG 作为解释层，graph 作为关系层，eval 作为质量门禁。
- 一句话总结: RAG 的难点不是让模型读资料，而是让正确的人在正确权限下基于正确版本资料得到可引用、可审计、可复盘的答案。
Follow-up Reading and Experiments
Follow-up Reading
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: 原始 RAG 论文。
- Dense Passage Retrieval: 理解 dense retriever 的基础。
- Fusion-in-Decoder: 理解多文档输入生成架构。
- REALM 与 Atlas: 理解 retrieval-augmented language model 的后续发展。
- Self-RAG 与 HyDE: 理解自适应检索和检索增强技巧。
- ColBERT: 理解 late interaction retrieval。
- Enterprise Search: 理解 BM25、fielded search、facets、权限过滤。
- AI Governance: 理解审计、模型风险管理、数据治理。
Experiments for PM
- 选一个政策文档，设计 20 个真实用户问题。
- 标注正确答案、引用条款、拒答条件和用户期望体验。
- 对比普通 LLM、长上下文、RAG 三种方案的产品差异。
Experiments for BA
- 为 KYC 文件清单场景设计元数据模型。
- 字段至少包括客户类型、地区、产品、文件类型、生效日期、例外条件、密级。
- 写 30 条验收问题，其中包含无答案、权限、版本冲突和地区差异问题。
Experiments for Architect
- 构建小型 RAG pipeline: ingest 10 个政策文档，chunk，embedding，hybrid retrieval，rerank，generate，cite。
- 对比固定长度、按标题、父子 chunk 三种策略。
- 对比纯向量、纯 BM25、hybrid retrieval 的 recall@5。
- 加入过期政策测试 stale source，加入恶意片段测试 prompt injection。
- 为每次回答记录 trace，并从日志定位错误原因。
Capstone Suggestion
- 做一个“零售金融政策助手”作品集项目。
- 输入贷款政策、KYC 文件清单、客服 FAQ、合规话术规范。
- 输出员工问答、对客话术、引用条款、适用范围、风险提示。
- 必备能力包括角色权限、版本过滤、引用跳转、拒答、评估集和监控 dashboard。
- 作品集重点不是炫技，而是展示你能把 PM 需求、BA 规则和企业架构治理连成可上线方案。