2. RAG基础与金融场景
在金融行业落地大模型时，最棘手的问题往往不是模型本身不够聪明，而是它不知道"我们公司最新的信贷政策是什么"，也说不清"某只基金近三年的回撤数据"。检索增强生成（Retrieval-Augmented Generation，RAG）正是为解决这类问题而生：它让模型在生成回答前，先去外部知识库中检索相关证据，再基于证据组织语言。本节将拆解RAG的基本原理与流程，并结合智能投顾、合规问答、信贷审核三类金融场景，说明其数据特点与落地要点。
一、核心原理：为什么RAG适合金融
大模型的参数化知识存在三个天然短板：时效滞后（训练截止后发生的事件无法感知）、事实幻觉（对不确定内容仍会自信编造）、不可溯源（无法说明答案依据）。RAG通过"外挂知识"的方式缓解这三点：知识以文档、表格、数据库记录等形式存放在外部存储中，检索器负责找到与问题最相关的片段，生成器只负责"读懂并复述"这些片段。
从信息流角度看，RAG把一次生成拆成两条链路：一条是离线索引链路，把原始金融文档切分、向量化、写入向量库；另一条是在线检索生成链路，把用户问题向量化后召回、重排、拼装上下文，再交给大模型生成答案。两条链路的交汇点是向量索引，它决定了系统"能看见什么"。
关键认知：RAG的效果上限由检索质量决定，而非生成模型。检索不到正确证据，再强的模型也只能编造；检索到噪声证据，模型会被误导。因此金融RAG的第一优先级是"检索准"，第二才是"生成好"。
二、检索增强生成的标准流程
一个可落地的金融RAG流程通常包含六个环节，每个环节都有金融场景特有的注意事项：
- 文档接入与解析：接入PDF研报、Word制度、Excel台账、数据库表。金融文档常含复杂表格、脚注、印章，解析时需保留表头与单位，避免"金额单位丢失"。
- 切分（Chunking）：按语义或结构切分，制度类按条款切，研报类按段落切。切分过大引入噪声，过小丢失上下文，通常300～800字为宜。
- 向量化（Embedding）：用嵌入模型把文本转为向量。金融术语密集，建议选用在中文金融语料上表现较好的模型，并对"年化收益率""不良率"等术语做同义词扩展。
- 索引与存储：写入向量数据库，同时保留原文、来源、权限标签等元数据。权限标签是后续隔离的基础。
- 检索与重排：先向量召回Top-K，再用重排模型精排。金融问答常需混合检索：向量召回语义相近，关键词召回精确匹配产品代码、监管文号。
- 生成与引用：把重排后的片段拼入提示词，要求模型"仅依据给定材料回答，并标注来源"。这一步直接决定答案可审计性。
# 检索生成链路的关键参数示例
retriever:
top_k: 20 # 向量召回数量
rerank_top_n: 5 # 重排后保留片段数
score_threshold: 0.35
chunk:
size: 500
overlap: 80
prompt: |
仅依据以下材料回答，若材料不足请说明"暂无依据"。
材料：{context}
问题：{question}
要求：标注每条结论的来源文档与条款号。三、金融领域典型应用与数据特点
RAG在金融的落地并非"一套流程打天下"，不同场景的数据形态、时效要求和风险等级差异显著。下表对比三类典型应用：
| 场景 | 核心问题 | 主要数据源 | 数据特点 | 风险等级 |
|---|---|---|---|---|
| 智能投顾 | 产品推荐、组合解读、市场问答 | 产品说明书、行情数据、研报 | 时效性强、数值密集、需个性化 | 高（涉适当性） |
| 合规问答 | 制度查询、监管条文解释 | 内部制度、监管文件、处罚案例 | 版本多、条款细、要求可溯源 | 极高（涉合规） |
| 信贷审核 | 材料核验、政策匹配、风险提示 | 信贷政策、客户材料、征信报告 | 强隐私、结构化+非结构化混合 | 极高（涉隐私） |
三类场景对RAG提出的共同要求是可溯源与权限可控。智能投顾若推荐了不适合客户风险等级的产品，可能触发适当性违规；合规问答若引用了已废止的旧版制度，会直接误导业务；信贷审核若把A客户的征信信息检索进B客户的上下文，则构成严重的数据泄露。因此，金融RAG从设计之初就必须把"谁能检索到什么"作为一等公民，而非事后补丁。
四、常见误区与复盘
误区一：把RAG当成"万能问答机"。很多团队上线后发现模型答非所问，第一反应是换更大的模型，但真正的问题往往是切分把一条完整制度拆成两半，或向量模型对金融术语不敏感。复盘时应先看检索命中率，再看生成质量。
误区二：忽视元数据与权限标签。若索引时只存文本不存来源和权限，后续做权限隔离只能推倒重建。正确做法是在文档接入阶段就为每个片段打上"部门、密级、生效日期、适用产品线"等标签。
误区三：用同一套检索策略服务所有场景。合规问答需要精确匹配条款号，信贷审核需要按客户ID过滤，智能投顾需要结合实时行情。把过滤条件、召回策略、提示词模板按场景参数化，比追求"一个通用RAG"更现实。
复盘一个真实教训：某机构合规问答上线初期，因未对制度版本做过滤，模型同时检索到2019版和2023版《操作风险管理指引》，生成了一个"混合版"答案，被合规部门判定为不可用。修复方式是在元数据中增加"生效状态"字段，检索时强制过滤已废止版本。这个案例说明，金融RAG的很多问题不是算法问题，而是数据治理问题。
理解RAG的双链路结构与权限过滤位置，是后续讨论权限隔离与敏感信息防护的前提。金融场景的特殊性在于：检索到的每一条片段都可能携带客户隐私或未公开信息，因此"检索"本身就是一个需要授权的动作，而不是一个中性的技术步骤。