📚 课程目录第3章 RAG技术入门

3. RAG技术入门

在金融合规场景中，大模型最危险的问题不是“不会答”，而是“答得像真的”。监管条文、内部制度、处罚案例往往存在版本差异、适用范围差异和时效差异，单靠模型参数记忆极易产生幻觉。RAG（Retrieval-Augmented Generation，检索增强生成）正是为解决这一问题而生的工程范式：它把“记忆”从模型参数中剥离出来，交给可更新、可追溯、可审计的外部知识库。

一、核心原理：先检索，再生成

RAG 的基本思想可以用一句话概括：在生成答案之前，先到可信知识源中找出与问题最相关的证据片段，再让模型基于这些证据组织回答。它把一次问答拆成两个阶段：检索阶段负责“找依据”，生成阶段负责“写结论”。

从概率角度看，普通大模型计算的是 P(答案 | 问题)，而 RAG 计算的是 P(答案 | 问题, 检索到的证据)。多出来的“证据”条件，正是合规问答中可解释性和可审计性的来源。检索通常基于向量相似度：把问题和文档块分别编码为高维向量，用余弦相似度或内积衡量语义接近程度，再结合关键词召回（如 BM25）做混合检索，最后用重排序模型精排。

RAG 不是“把文档塞进提示词”这么简单。真正决定效果的是三件事：文档切分粒度、检索召回质量、以及生成时对证据的约束强度。

二、方法流程与架构

一个可落地的金融合规 RAG 系统，通常包含离线索引和在线问答两条链路。离线链路负责把制度、法规、案例加工成可检索的知识；在线链路负责实时响应提问。

离线索引：
原始文档(PDF/Word/网页)
  → 解析与清洗(去页眉页脚、表格还原)
  → 分块(chunk_size=500, overlap=80)
  → 向量化(embedding模型)
  → 写入向量库 + 元数据(发文机关/生效日期/废止状态)

在线问答：
用户问题
  → 查询改写(补全简称、识别监管条线)
  → 混合检索(向量TopK=20 + BM25 TopK=20)
  → 重排序(Cross-Encoder精排Top5)
  → 提示词组装(问题+证据+引用要求)
  → 大模型生成
  → 答案+引用来源+置信度

架构上可分为四层：数据层（文档库、向量库、元数据库）、检索层（召回、重排、过滤）、生成层（提示词模板、大模型、输出校验）、治理层（权限、审计、版本、反馈闭环）。金融合规尤其要重视治理层，因为“谁在什么时间依据哪一版制度给出了什么答复”必须可回溯。

三、RAG 在金融合规领域的典型应用场景

金融合规的知识密度高、更新频繁、责任重大，是 RAG 价值最集中的领域之一。以下场景已在不少机构落地或试点：

应用场景	知识源	RAG 解决的问题	关键约束
监管条文问答	银保监/证监会/央行规章、通知	条文版本多、废止关系复杂	必须标注生效日期与废止状态
内部制度检索	员工手册、操作规程、授权表	制度分散、口径不一	按部门与岗位做权限过滤
反洗钱可疑分析	可疑交易特征、历史案例	案例经验难以复用	脱敏处理，禁止输出客户信息
合规审查辅助	审查要点清单、处罚案例	审查标准依赖个人经验	结论需人工复核，不得自动放行
销售适当性问答	产品说明书、风险等级规则	产品与客户匹配易出错	强制引用产品条款与风险提示

四、常见误区与复盘要点

初学者做金融合规 RAG，最容易踩的坑并不是模型选得不够强，而是知识工程没做扎实。以下误区值得反复复盘：

误区一：切块越细越好。切得太碎会丢失条文上下文，导致“断章取义”。合规条文常以“条—款—项”为结构，应按语义层级切分，而非固定字数硬切。
误区二：只做向量检索。纯向量检索对专有名词、编号（如“第X条”“X号文”）不敏感，必须与 BM25 等关键词召回混合使用。
误区三：忽略时效与废止。金融法规更新频繁，若元数据中没有生效日期和废止标记，模型可能引用已失效条文，这是合规事故。
误区四：不做拒答设计。当检索不到足够证据时，系统应明确回答“未找到依据”，而不是让模型自由发挥。
误区五：没有评估闭环。应建立“问题—召回—答案—人工判定”的评测集，持续度量召回率、引用准确率和拒答正确率。

复盘时建议重点看三类指标：召回是否漏掉了关键条文、引用是否真实存在于知识库、答案是否越过了证据边界。这三项比单纯的“回答流畅度”重要得多。

RAG 能显著降低幻觉，但不能消除幻觉。在金融合规场景中，任何面向监管报送、客户告知或自动决策的输出，都必须保留人工复核环节，并完整记录检索证据与生成日志。

理解 RAG 的关键，是把它看作一套“知识供给系统”而非单纯的模型技巧。检索质量决定上限，生成约束决定下限，治理机制决定它能否真正进入金融合规的生产环境。