1. 课程导入与金融RAG全景
欢迎进入《金融RAG端到端应用项目实战》。在动手写第一行检索代码之前，我们需要先建立一张完整的“作战地图”：金融业务到底难在哪里，RAG为什么能成为当前最务实的解法，以及我们将用怎样的端到端架构把一个个零件装配成可上线的系统。本章不写复杂代码，但会决定你后续29章的学习效率。
一、学习目标：从“会用工具”到“能交付系统”
本课程的目标不是教你调用某个大模型API，而是让你具备独立交付金融RAG应用的能力。具体来说，完成全部章节后，你应当能够：
- 理解原理：说清RAG的检索、增强、生成三阶段各自解决什么问题，以及金融场景下的特殊约束。
- 搭建链路：从文档解析、切分、向量化、索引、召回、重排到生成，独立完成端到端流水线。
- 评估效果：用召回率、忠实度、答案相关性等指标量化系统表现，而不是凭感觉判断“答得还行”。
- 工程落地：掌握缓存、权限过滤、引用溯源、日志监控等生产级能力，让Demo变成产品。
一句话概括：本课程培养的是“金融领域RAG系统工程师”，而不是“提示词调参师”。
二、金融场景痛点：为什么通用大模型直接上场会翻车
金融行业对信息的准确性、时效性和合规性要求极高。把通用大模型直接接入业务，通常会暴露以下几类问题：
| 痛点类型 | 典型表现 | 业务后果 |
|---|---|---|
| 知识时效 | 模型训练数据截止，不知道最新财报、公告、利率调整 | 给出过期结论，误导决策 |
| 事实幻觉 | 编造不存在的财务数据、监管条款、产品收益率 | 合规风险与信任崩塌 |
| 专业术语 | 对“久期”“拨备覆盖率”“可转债转股价”理解偏差 | 答非所问，专业度不足 |
| 数据私密 | 内部研报、客户资料不能上传公网模型 | 数据泄露与监管处罚 |
| 可解释性 | 无法说明答案来自哪份文件、哪一页 | 无法审计，难以采信 |
这些痛点决定了金融场景不能只靠“更大的模型”，而需要一套能接入私有知识、可追溯、可控制的增强机制。
三、RAG核心价值：给大模型装上“可查证的外脑”
RAG（Retrieval-Augmented Generation，检索增强生成）的核心思想是：在生成答案之前，先从可信知识库中检索相关内容，再让模型基于这些内容作答。它把“记忆”从模型参数中剥离出来，交给可更新、可审计的外部知识库。
对金融业务而言，RAG带来四个直接价值：
- 时效可控：知识库更新即可生效，无需重新训练模型。
- 事实可依：答案有检索片段作为依据，显著降低幻觉。
- 来源可溯：每条结论都能标注出处文档与页码，满足审计要求。
- 数据可控：敏感资料留在本地或私有环境，只把必要片段送入模型。
RAG不是万能的。它擅长“基于已有资料回答问题”，但不擅长需要复杂推理、跨文档计算的任务。理解边界，才能选对方案。
四、端到端项目整体架构与实战路线图
本课程的项目是一个面向金融研报与公告的智能问答系统。整体架构可以拆成离线索引与在线问答两条链路，二者共享同一个向量知识库。
围绕这张架构图，我们的实战路线分为六个阶段：
- 数据准备：收集研报、公告、财报，完成格式统一与清洗。
- 索引构建：文档解析、语义切分、向量化并写入向量库。
- 检索优化：混合检索、元数据过滤、重排模型提升召回质量。
- 生成控制：提示词约束、引用标注、拒答策略，保证答案可信。
- 评估调优：建立评测集，量化指标，迭代切分与检索参数。
- 工程部署：缓存、并发、权限、监控，让系统稳定上线。
五、常见误区与复盘提醒
误区一：把RAG当成“万能问答”。RAG只能基于检索到的内容作答，知识库没有的信息，系统应当明确拒答，而不是让模型自由发挥。
误区二：只关注生成模型，忽视检索质量。检索错了，再强的模型也只能“一本正经地胡说”。金融场景中，召回质量往往比模型选型更关键。
误区三：切分越细越好。切得太碎会丢失上下文，切得太粗会引入噪声。切分策略必须结合金融文档的章节结构来设计。
误区四：没有评估就上线。没有评测集和指标，优化就是盲人摸象。评估层必须从第一天就纳入设计。
请记住本课程的一条主线：检索决定上限，生成决定下限，评估决定方向，工程决定生死。接下来的章节，我们将沿着这条主线，一步步把架构图上的每个模块变成可运行的代码与可交付的系统。