3. RAG核心概念与原理
检索增强生成（Retrieval-Augmented Generation，RAG）是一种把“外部知识检索”与“大模型生成”组合起来的推理架构。它的核心思想是：模型在回答前，先去知识库中检索与问题相关的证据片段，再把这些片段作为上下文交给生成器，从而让回答既有语言组织能力，又有可追溯的事实依据。在金融场景中，这一点尤其关键，因为监管文件、研报、公告、产品说明书和内部制度都要求答案准确、可解释、可审计。
一、核心原理：检索器与生成器的协作机制
RAG 可以拆成两个角色：检索器（Retriever）负责“找证据”，生成器（Generator）负责“写答案”。检索器通常把用户问题编码成向量，在向量库中做相似度搜索，返回 Top-K 个候选片段；生成器则把“问题 + 检索片段”拼成提示词，生成最终回答。二者不是简单串联，而是通过上下文窗口、重排序和引用标注形成闭环。
一个典型的金融 RAG 数据流如下：用户提问 → 查询改写 → 向量检索 → 重排序 → 上下文组装 → 大模型生成 → 引用与校验。其中“重排序”常被忽略，但它决定了最终进入生成器的片段质量。金融文本中大量存在“同一术语不同口径”的情况，例如“不良率”在银行、信托、租赁中的定义不同，重排序阶段需要结合业务标签和时效性做二次筛选。
二、方法流程：从索引到生成的工程链路
在工程实现上，RAG 通常分为离线索引和在线推理两条链路。离线阶段完成文档解析、分块、向量化和入库；在线阶段完成查询改写、检索、重排序、上下文组装和生成。金融文档往往包含表格、脚注和跨页条款，分块策略不能只按固定字数切分，而应结合标题层级和语义边界。
# 金融RAG在线推理伪代码
query = rewrite(user_question, domain="金融")
candidates = vector_store.search(query, top_k=20)
reranked = rerank(candidates, business_tag="银行理财", time_weight=0.3)
context = assemble_context(reranked[:5], max_tokens=3000)
answer = llm.generate(
prompt=build_prompt(query, context),
temperature=0.2,
citation=True
)
return answer, reranked[:5]参数选择上，Top-K 不宜过大，否则会引入噪声并挤占上下文；温度建议偏低，金融问答更强调稳定和可复现。引用标注应保留原文片段编号，便于人工复核。
三、与微调、纯生成方案的对比
很多团队会问：既然可以微调，为什么还要 RAG？两者并不互斥。微调改变的是模型参数，适合学习风格、格式和领域语言习惯；RAG 改变的是输入上下文，适合注入最新事实和可追溯证据。纯生成方案则完全依赖模型内部知识，在金融场景中容易产生“看似合理但无出处”的回答。
| 方案 | 知识更新 | 可追溯性 | 成本 | 金融适用性 |
|---|---|---|---|---|
| 纯生成 | 需重新训练 | 弱 | 低 | 不适合强监管问答 |
| 微调 | 需增量训练 | 中 | 中高 | 适合风格与分类任务 |
| RAG | 更新知识库即可 | 强 | 中 | 适合研报、公告、制度问答 |
| RAG+微调 | 知识库+参数双更新 | 强 | 高 | 适合复杂金融助手 |
四、金融场景适用性分析与常见误区
金融场景对 RAG 的吸引力来自三点：第一，知识时效性强，监管规则和市场数据频繁变化；第二，答案需要引用来源，满足合规审计；第三，业务口径复杂，需要把机构、产品、时间等维度纳入检索过滤。典型场景包括：理财产品说明书问答、上市公司公告解读、内部信贷制度检索、投研报告摘要与风险提示生成。
适用性判断清单：
- 知识是否频繁更新？是 → 优先 RAG。
- 答案是否需要引用原文？是 → 必须 RAG。
- 问题是否涉及多口径对比？是 → RAG + 业务标签过滤。
- 是否只需固定格式分类？是 → 可考虑微调。
常见误区：把 RAG 当成“万能问答”，忽略分块质量、重排序和引用校验；或者只做向量检索，不做关键词混合检索，导致专有名词和数字召回失败。金融文本中的“2024年”“第X条”“年化收益率”等关键信息，往往需要 BM25 与向量检索互补。
复盘时建议关注三个指标：召回率、引用准确率和答案忠实度。召回率低，说明索引或查询改写有问题；引用准确率低，说明重排序或上下文组装有偏差；忠实度低，说明生成器可能脱离证据自由发挥。只有把检索器和生成器当作一个整体来调优，RAG 才能在金融业务中稳定落地。