2. 金融RAG基础
在金融业务中，大模型直接回答问题的风险很高：它可能编造不存在的财报数据、误读监管条款，或把过时的利率政策当作现行规则。RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路，是让模型在生成答案前先“查资料”，把检索到的可信文本作为上下文，再组织语言输出。这一节我们先建立金融RAG的整体认知：它用在哪里、由哪些部件构成、与搜索和问答系统有什么本质区别。
一、金融领域的典型应用场景
金融RAG的价值集中在“知识密集、时效敏感、合规要求高”的任务上。常见场景包括：
- 投研问答与报告辅助：研究员询问“某公司近三年毛利率变化及原因”，系统检索年报、季报、公告后汇总，并标注数据来源。
- 监管合规检索：把银保监、证监会、央行发布的规则条文入库，回答“某类理财产品销售需要哪些适当性材料”。
- 客服与产品咨询：面向客户解释费率、赎回规则、风险等级，答案必须与产品说明书一致。
- 信贷与风控辅助：结合内部制度、行业政策和历史案例，辅助客户经理判断授信条件。
- 内部知识管理：把分散在制度库、邮件、会议纪要中的经验沉淀为可检索问答。
这些场景的共同点是：答案不能只靠模型“记忆”，必须落到可追溯的文档依据上。一旦答案错误，可能带来投资损失或合规处罚，因此可观测性和失败诊断在金融RAG中不是可选项，而是基础设施。
二、核心组件：检索器、生成器、知识库
一个典型的金融RAG系统由三个核心组件协同工作，外加贯穿全流程的编排与观测层。
| 组件 | 职责 | 金融场景关键点 |
|---|---|---|
| 知识库 | 存储并索引文档切片与向量 | 文档版本、生效日期、权限隔离、表格与数字解析 |
| 检索器 | 根据问题召回相关切片并排序 | 混合检索、时间过滤、同义词与金融术语归一 |
| 生成器 | 基于上下文组织答案并引用来源 | 禁止无依据推断、强制引用、数字一致性校验 |
知识库不是简单的文件堆。金融文档常包含大量表格、脚注和跨页条款，切片时要保留表头与上下文，否则检索到的片段会失去语义。检索器通常采用“向量检索+关键词检索”的混合策略：向量擅长语义匹配，关键词能精确命中产品代码、法规编号。生成器则需要在提示词中明确约束——只允许使用检索到的内容，无法回答时如实说明。
三、与传统搜索和问答系统的区别
传统搜索返回的是文档列表，由用户自己阅读和判断；传统问答系统（如FAQ库）依赖预设问题与答案的匹配，覆盖范围有限。RAG则把“检索”和“生成”串起来，直接给出自然语言答案，并附带来源。
- 输出形态：搜索给链接，FAQ给固定答案，RAG给带引用的综合答案。
- 知识更新：搜索依赖索引更新，FAQ需要人工维护，RAG更新知识库即可生效。
- 泛化能力：FAQ只能回答预设问题，RAG可以处理未见过但知识库中有依据的问题。
- 风险来源：搜索的风险是排序偏差，FAQ的风险是覆盖不足，RAG的风险是检索遗漏与生成幻觉叠加。
理解这一区别，才能明白为什么RAG的可观测性要同时覆盖检索和生成两个阶段：只看最终答案，无法判断错误是“没查到”还是“查到了但答错”。
四、方法流程与一个投研问答案例
以“某上市公司2023年净利润同比变化”为例，完整流程如下：
- 用户提问，系统识别意图与时间范围。
- 问题改写为检索友好的查询，补充公司名、年份等实体。
- 检索器从年报知识库召回相关切片，按相关性排序。
- 生成器读取切片，提取数字并计算同比，输出答案与引用。
- 观测层记录检索命中、耗时、引用来源和答案置信度。
{
"query": "某公司2023年净利润同比变化",
"retrieved_chunks": 5,
"top_source": "2023年年度报告_第45页",
"answer": "2023年净利润为12.3亿元，同比下降8.2%",
"citations": ["2023年年度报告_第45页"],
"latency_ms": 1840
}这段日志体现了可观测性的基本要素：检索了什么、用了哪条依据、答案是什么、耗时多少。后续章节会深入讲解如何基于这些字段做失败诊断。
五、常见误区与复盘
误区二：只关注生成模型选型，忽视切片策略和检索评估。很多失败案例的根因在知识库建设阶段，例如表格被切碎、条款跨页丢失。
误区三：答案没有引用或引用不可追溯。金融场景要求每个数字都能回到原文，否则无法通过合规审查。
复盘时建议追问三个问题：检索是否召回了正确依据？生成是否忠实于依据？系统是否留下了可诊断的日志？这三个问题构成了后续可观测性体系的骨架。