企业官网建设流程全解析

1. 项目概述：从“能搜到”到“能答对”的跨越

金融领域做RAG（Retrieval-Augmented Generation，检索增强生成），和通用场景完全是两个物种。通用场景里，用户问“如何做红烧肉”，检索结果偏一点问题不大，模型能靠自身知识兜底。但金融场景下，用户问的是“某公司去年第三季度的流动比率是多少”，或者“某项新规对资管产品估值的影响”，答案必须精确到数值、条款和出处。错一个小数点，或者把新旧法规混在一起，轻则误导投资决策，重则直接踩监管红线。

我做这个Financial RAG Demo项目，起因其实很朴素。当时团队需要处理一批财报PDF、招股说明书和研报，日常工作是让分析师反复翻阅这些动辄几百页的文档，把关键数据摘出来填进表格。这活儿大量重复、机械，但偏偏又特别考验准确性，人工干很容易疲劳出错。于是我们想做一个RAG服务，把这一步尽量自动化——不是让模型替代分析师做判断，而是让模型快速定位到原文片段，把相关的数据、条款、表述完整捞出来，再由人工做最终确认。

这个Demo虽然叫“Demo”，但绝对不是玩具级别。我把它设计成了一条完整的流程：文档解析、切片、向量化、存储、召回、重排、生成、引用溯源。每一步都针对金融文本的特点做了专门处理。整个项目跑下来，单次问答的端到端延迟大概在2到4秒，召回答案在测试集上的Top-5命中率能做到85%以上，生成答案的关键字段引用完整度也基本达到了可用的水平。

这篇文章写给谁？两类人。一类是想在金融场景做RAG落地的开发者，你会看到从0到1搭建一套服务时踩过的坑和绕过的弯；另一类是对RAG感兴趣但还没动手的产品或分析师，你会理解为什么金融RAG不能简单套用通用方案，以及“检索”和“生成”之间那层微妙的平衡关系。

我会按项目的真实推进顺序来拆解，先讲整体设计思路，再讲每个核心环节的实现细节，然后是完整流程演示，最后是排查问题和优化心得。全程不贴完整工程代码，但会把关键脚本的结构、配置和参数讲透，方便你直接复现。

2. 内容整体设计与思路拆解

2.1 金融RAG的难点：为什么不能直接套通用方案

先说说RAG的基本原理，方便没接触过的朋友快速跟上。传统的语言模型回答问题，全靠训练时“记住”的知识，知识有截止时间，也无法引用特定文档。RAG的思路是：在模型回答之前，先从你的私有文档库里检索出相关内容，把检索结果作为上下文拼接给模型，让模型基于这些材料作答。相当于给模型开卷考试，而不是闭卷瞎猜。

通用RAG流程听着简单——文档切块、向量化、相似度检索、丢给大模型——但金融场景有三个硬伤。第一个硬伤是数值敏感性。通用聊天可以把“大约”“大概”挂在嘴边，金融问答连近似都应该尽量避免。模型如果泛泛地概括“该指标有所改善”，分析师的内心是崩溃的，他需要的是“从1.2上升到1.5，增幅25%”。这就要求检索结果必须保留原始数值和上下文语境，而切块稍大，向量就能把一个数字淹没在一堆语义相近的文字中，召回时很难精确对应。

第二个硬伤是术语和实体歧义。金融文档里的“公司”可能指上市公司本身，也可能指其子公司；“计提”这个词在减值、拨备、负债场景里都有；甚至同样一句话，在新旧会计准则下含义完全不同。通用向量模型对这类歧义的区分能力有限，单纯靠语义相似度检索，容易把不同语境的内容混为一谈。

第三个硬伤是答案必须可溯源。分析师拿到一个靠RAG生成的结论，第一反应绝对不是“哇真智能”，而是“你这个结论是依据哪一段原文、哪一份文件得出的”。这在金融合规里叫audit trail（审计痕迹），没有引用的答案是零价值的。通用RAG系统很少把“引用溯源”当作一等公民来设计，很多人做到最后发现引用是模型瞎编的，那就全是负功。

基于这三个硬伤，项目的整体设计从一开始就不是“做一个通用的知识库问答”，而是“做一个带着镣铐跳舞的金融问答系统”——把精确性、可溯源性和领域适配性放在比“语义流畅”更高的优先级上。

2.2 整体架构选型：检索-重排-生成三级流水线

这个Demo采用了当前业界比较主流的RAG流水线，但每一级都做了金融化改造。整个架构可以拆成五个模块：

1. 文档解析层：负责把PDF、Word、Markdown等原始文件转换成结构化的纯文本，并尽量保留表格、标题、页眉等结构信息。
2. 离线索引层：对文本做切片，生成向量索引和关键词索引，双路召回的数据基础。
3. 召回层：用户问题进来后，同时走向量相似度检索和关键词检索，把两路结果合并。
4. 重排层：用一个更精细的模型对召回结果做二次打分，过滤掉语义相近但实际不对题的片段。
5. 生成层：把最终选中的文档片段作为上下文交给大模型，配合提示词工程生成带引用的答案。

选这条路而不是端到端训练一个金融问答大模型，原因很现实：端到端方案需要高质量标注数据，金融领域标注成本极高，而且模型更新迭代动辄重新训练，维护成本高。RAG方案则把“知识更新”变成“换文档重跑索引”，今天进来一百份新公告，明天系统就掌握了，不需要碰模型权重。对金融机构这种强知识时效性的场景，RAG无疑是性价比最高的路线。

2.3 关键决策记录：切片粒度、Embedding模型、检索策略的取舍

切片粒度是RAG里第一个要做的决策，金融场景直接决定了召回效果。切片太短，比如按256字符切，检索到的片段可能只覆盖了问题的半个前提，模型拿到碎片信息没法作答；切片太长，比如整页丢进向量库，语义虽完整，但向量在高维空间里被拉平了，相似度区分度下降，而且生成阶段塞进上下文的内容太多，可能淹没关键信息。

我最后选了分层切片策略。第一层按段落切，段落太长或太短的做二次调整，默认目标长度在600到800个中文字符之间，允许±20%浮动。第二层是有重叠的滑动窗口，相邻切片保持80到120字符的重叠。这个设计同时兼顾了语义完整性和检索精准度，重叠区域也能缓冲跨段信息被硬切造成的信息断裂。

Embedding模型用的是一套针对中文优化过的向量模型，而不是直接上通用英文模型。金融文档中有着大量特有名词、股票代码和统计数据，模型的中文理解能力必须过硬。向量维度我选了768维，这是模型输出的原生维度，不建议降维，降维会损失语义精度，金融场景不差那点存储空间，检索准确性优先。

检索策略上，纯向量检索对“语义相同写法不同”的查询很友好，但金融场景里很多查询是精确的：“净利润同比增长率”“每股收益”“不良贷款率”，这些词在文档里就以几乎不变的形式出现。所以我加了关键词检索通道，用BM25算法做传统倒排索引召回。向量召回负责找语义相似的段落，BM25负责锁定精确包含关键实体的段落，两路合并后再统一重排。这样做的直接收益是，对“某公司2022年ROE”这类查询，即使向量召回的片段排得不够靠前，BM25也能把它从文本的犄角旮旯里揪出来。

生成端大模型用的是一套支持中文长上下文、有一定金融知识基础的通用模型。为什么不用金融专用微调模型？因为专用微调模型通常更“懂”金融，但生成内容的创造性和灵活性反而受限，而且微调模型的版本更新周期长，难以跟上文档库的快速变化。检索系统负责“懂文档”，生成模型负责“懂表达”，这个分工更合理。

3. 核心细节解析与实操要点

3.1 文档解析处理：表格识别、PDF转文本的坑与对策

金融文档的很大一部分价值浓缩在表格里，而PDF解析工具对表格的还原能力参差不齐。我实测的结论是：用PDF直接抽取文本的方案，表格信息几乎必丢，或者说丢失得不成样子。

最初测试时，我们拿一份带复杂合并单元格的财报PDF，用某PDF解析库直接抽取文本，所有表格数据挤成了一坨，列与列之间没有分隔，行与行之间的对应关系完全乱了。向量化之后检索出来的片段，看起来每个数字都在，但没法确认哪个数字属于哪一列，属于表面上检索到了，实质上是无效信息。

后来换了表格识别工具，专门负责把PDF页面里的表格区域识别出来，输出成结构化的数据再说，虽然不能保证100%还原复杂表格，尤其遇到跨页的表格基本没办法合并，但单页内的表格识别率相当可观。我的对策是：解析结果不追求完美，但必须保证“可读的结构”。具体做法是把识别出来的表格转成Markdown格式存放，列与列用竖线分隔，这比纯文本效果好了不止一个量级。

标题层级也是一个被低估的信息。财报里“第三节 管理层讨论与分析”下面的两个字“概述”，和“第四节 财务数据”下面的“概述”，内容完全不同。如果解析时丢了标题层级，这两个“概述”切片在向量空间里会非常相似，检索时互相干扰。我要求解析器把文档的标题层级保留成Markdown的#、##、###结构，切片时会把标题信息拼进切片内容里，这样向量模型能感知到“这是哪一节的子内容”，语义区分度大幅提升。

3.2 切片工程：语义完整性与检索精度的折中

切片不是按字符数机械切分那么简单。我把“语义边界”作为第一优先级，句号和标题是天然的分段点，段落结束才考虑是否达到目标长度。如果某段特别长，超过目标长度的1.5倍，先按句号拆成几个子块，再组合相邻子块。

关于重叠窗口，业界有些方案喜欢20%到30%的绝对重叠比例，我试过一次后发现对金融文档来说偏高，同一条信息被重复索引三次甚至四次，召回时明明只有一段相关信息，却返回好几条几乎一模一样的切片，重排还得费力去重。我的参数是固定重叠80到120字符，而不是按比例。这主要为了保证跨切片的句子不被硬生生切断——如果一句话在切片边界处正好断成两半，那向量表达就会被砍得语义残缺，重排也对不齐。

还有一个被反复强调但很多人会忽略的点：切片要带元数据。每个切片除了正文内容，至少要带上来源文件名、页码、章节路径、切片的全局编号。这些元数据不仅仅是召回后展示用的，更关键的是在生成阶段做引用溯源时，模型能精确地说出“这个数据来自某文件第几页第几节”，这是分析师判断答案可信度的核心凭证。

3.3 向量索引与混合检索的具体配置

向量数据库层面，我对比过几种常见方案，最终选了一个支持向量+标量混合查询的向量数据库。为什么不用关系型数据库做纯向量检索？金融场景下，除了语义相似度，常常还要叠加硬性过滤条件。比如“只查2022年年报”“只查某公司的数据”“排除PDF格式的结果”，这些条件在向量库里叫“元数据预过滤”。

选型时考虑三个硬指标：一是支持亿级以下向量规模的毫秒级检索，对Demo项目完全够用但留了扩展空间；二是支持元数据过滤，查询时可以先过滤再检索，显著减少向量计算的候选集；三是运维成本要低，单机部署就能跑，不引入分布式依赖。

向量索引类型我选了HNSW（Hierarchical Navigable Small World，层级可导航小世界图），参数设置了M=16和efConstruction=100，这是兼顾召回率和索引构建速度的常见组合。M越大连接数越多，索引质量越高但吞内存，efConstruction越大构建越慢但图质量更好。对金融场景这种几万到几十万级别的切片量，这个配置足够。

混合检索的具体比例也踩过坑。最初我让每条通道各返回50条，再合并去重，算下来向量召回的命中率占比高得惊人，BM25的贡献好像微乎其微。但抽样看了查询结果后发现问题：BM25捞出来的结果，往往是“精确包含股票代码”却“语义不那么贴合”的片段——比如用户问“宁德时代2021年报”，BM25对“宁德时代”这个实体的匹配特别敏感，能锁定包含这个名字的核心段落，而向量召回给出的结果是“相关公司”“同行企业”，虽然语义上“相关”，但精确度差远了。所以我在合并策略里对BM25的Top K结果做了加权，让关键词命中的片段有更多进入重排阶段的机会。

3.4 重排模型与生成参数的经验配置

重排模型我选了一个轻量级的cross-encoder。它的思路是：召回模型是给“问题-候选文档”分别做embedding，在高维空间里比相似度，速度快但精度有限；重排模型则把“问题-候选文档”拼成一对，整体丢进模型里做一个二分类式打分，相似度判断更加精细，但计算量大得多，只能对召回后的Top N再做精排。

在Demo中，召回的Top 50条经过重排后只保留Top 10，这10条作为上下文给生成模型。我实测过一个关键阈值：如果重排后的Top结果得分过低，比如低于0.35（这个分数受模型和域内数据影响，最好自行标定），说明文档库里根本没有可靠答案。这种情况宁可让模型回答说“未检索到相关信息”，也别让它硬编。这是金融场景的铁律——宁缺毋滥。

生成参数上，温度（temperature）设得很低，0到0.3之间。金融问答不需要创造性发散，需要的是稳定复现事实。top_p设为0.9左右，主要为了做一定程度的随机采样防止固定句式卡壳。另外一个关键点是max_tokens，因为答案可能包含数据表格和引用列表，太短的生成上限会让答案被截断。我设置了动态上限，根据重排结果里上下文的总长度，按最长抽象模式预留生成空间，防止输出被生硬截断。

4. 实操过程与核心环节实现

4.1 数据准备：自制金融语料集与预处理流程

这个Demo的语料，我没有直接拿网上的公开财报下载，那样版权和格式都不可控。我整理了一份自制的模拟金融语料集，包含了几类典型的金融文档：模拟上市公司年报节选、模拟行业研究报告片段、模拟基金合同条款、模拟监管新规解读文章。每份文档控制在几页到几十页不等，目的不是做大数据量压测，而是覆盖足够多的金融文本样式，让链路里的每个环节都有代表性测试样本。

预处理流程顺一遍：

1. 统一文件命名规范，文件名中包含公司代码、年份、文档类型，例如[SIM2022]某模拟公司_2022年年度报告.pdf。
2. 转PDF时统一页面尺寸和字体嵌入，避免解析阶段因字体缺失导致文字乱码。
3. 解析入库前先人工过一遍，剔除扫描件、图片页、纯广告页这类无法直接解析的噪声。
4. 生成一份JSON格式的元数据清单，记录每个文件的页数、章节数、文件哈希，方便索引构建时快速做增量更新。

这个数据准备环节看着琐碎，但占了整个项目开发周期的大头，得有心理预期。文档解析的失败往往不是解析器不行，而是源头文件质量太差。

4.2 索引构建流程：解析、切片、向量化、写入

索引构建是一个离线的批处理脚本，我用Python编排整个流程：

第一阶段，文档解析。对PDF调用表格识别工具和文本抽取工具，输出结构化的Markdown文本。对Word文档则用公共库做HTML格式中转，保留标题和表格。这个阶段我会记录每篇文档的解析结果日志，包括页数、字符数、表格数，方便事后追踪哪篇文档解析失败。

第二阶段，切片。写了一个切片器，输入过滤掉空段落和过短段落（少于30个字符的段落基本是页面装饰），然后按3.2节的分层策略做语义分段和重叠窗口切片。每个切片输出成一个字典：{"doc_id": ..., "chunk_id": ..., "content": "...", "metadata": {"page": 3, "section": "管理层讨论"}}。

第三阶段，向量化。加载Embedding模型，把切片的内容拼接上标题路径，比如“[某模拟公司2022年报｜管理层讨论与分析｜流动比率] 流动比率较上年同期上升...”，这样向量模型能看到切片所在的纯语义位置。批量向量化，注意用GPU或者批量接口加速，CPU跑几百条切片也能忍，但上千条就开始明显拖时间了。

第四阶段，写入向量数据库。每条向量记录带上doc_id、chunk_id、content以及元数据，建立HNSW索引。同时把这批切片写入BM25索引库，用doc_id字段关联两边，保证混合检索时能按同一个文档ID去重合并。

4.3 查询链路实战：一次真实问金融细节全流程

选一个典型的查询来走一遍全流程。假设用户提问：“某模拟公司2022年的流动比率是多少，相比上年有何变化？”

第一步，查询预处理。把问题交给一个轻量级实体识别模块，尝试抽取“某模拟公司”“2022年”“流动比率”这三个关键实体。实体抽取失败也没关系，流程会退化到纯向量检索，但抽取成功可以帮助后续做元数据过滤，比如限定文档集为“某模拟公司2022年报”。

第二步，混合召回。问题文本向量化，向量数据库做相似度检索，返回Top 50。同一时间BM25索引做关键词检索，把“流动比率”“2022”等高权重词命中度高的片段捞出来，返回Top 30。两路合并，按文档ID去重，保留Top 60候选。

第三步，重排。60条候选拼接进重排模型打分，按得分降序取前10。如果Top 1得分低于0.35，直接让生成模块返回“未找到可靠答案”，不硬答。

第四步，生成。把Top 10片段作为上下文，拼进一个金融问答提示词模板。模板里明确要求：“请根据以下文档内容回答问题。若问题在文档中无明确答案，请直接说明未找到相关信息，不要编造。回答末请列出引用的原文片段编号。”

实际生成的结果是：

某模拟公司2022年年度报告披露，截至2022年12月31日， 公司流动比率为1.85，较上年同期的1.52上升0.33， 主要原因为公司当年经营活动现金流改善及短期借款减少。 （引用：文档[SIM2022]第12页“管理层讨论与分析”第3段）

引用溯源准确指向了切片元数据，分析师拿着这个结果可以快速翻到原报告对应位置做人工确认，这是整个链路里最有价值的一环。

4.4 全套代码目录结构与关键技术配置快照

项目代码结构大概长这样：

financial_rag_demo/ ├── configs/ │ ├── index_config.yaml # 索引构建参数 │ ├── retrieval_config.yaml # 召回参数 │ └── generation_config.yaml # 生成参数 ├── docs/ # 测试语料（markdown / PDF） ├── pipelines/ │ ├── build_index.py # 离线索引构建入口 │ ├── query_pipeline.py # 在线查询入口 │ └── eval_pipeline.py # 评测脚本 ├── services/ │ ├── doc_parser.py # 文档解析模块 │ ├── chunker.py # 切片器 │ ├── embedder.py # 向量化服务 │ ├── retriever.py # 混合检索 │ └── reranker.py # 重排服务 ├── prompts/ │ └── finance_qa.txt # 金融问答提示词模板 └── requirements.txt

一个比较核心的配置片段如下：

# index_config.yaml chunk: target_length: 700 overlap_chars: 100 min_length: 100 max_length: 1000 embedding: model_name: "BAAI/bge-large-zh-v1.5" dim: 1024 batch_size: 32 vector_db: index_type: "HNSW" m: 16 ef_construction: 100 bm25: k1: 1.5 b: 0.75

注意bge-large-zh-v1.5的输出维度是1024，不是768，直接用原生维度即可。BM25的k1和b参数是倒排索引的标准配置，控制词频饱和度和文档长度归一化的力度，对长短不一的金融文档，b=0.75是个比较稳妥的起点。

5. 常见问题与排查技巧实录

5.1 召回了相似片段但答案还是错：语义相关不等于事实正确

RAG上线后最常见的问题就是：检索出来的片段看着高度相关，模型却给出了错误答案。排查思路不能停在“换个更好的Embedding模型”上，要先定位问题到底出在哪一级。

我第一次遇到这类问题时，先打印了重排后的Top 5片段原文，对比正确答案后发现：Top 1片段确实提到了“流动比率”，但说的是一家同行公司的数据，文档里还同时出现了“某某公司”和“同行公司”，向量模型把“流动比率”这个语义词的权重拉得极高，忽略了文档主体是谁。问题不在检索，在于切片内容里文档主体信息表达不够强。

解决办法有两层。第一层，切片时把文档标题、公司名、股票代码拼进切片头部，让向量模型天然感知到主体是谁。第二层，在重排阶段加入硬性过滤条件，如果抽取到了问题里的公司实体，就要求候选片段内必须包含该实体，否则直接降权。这个过滤条件可以在检索阶段做，也可以用重排模型做规则对齐。

5.2 引用编号与答案对不上：生成模型自行编造引用

这是RAG系统里最危险的故障之一。模型生成的答案内容是从上下文里来的，但引用的编号却是自己瞎编的，明明引用了第3号片段，内容却对应第7号片段。分析师如果直接拿这个去复核文档，会浪费大量时间。

我做的第一层防护是提示词强约束，要求模型必须严格按照[引用编号]格式标注来源，并且引用编号只能从上文给的片段序号里选。但这种约束对某些大模型只是“尽力而为”，第二层防护是写了一个引用校验脚本：生成回答后，把答案里的每个引用编号和对应片段正文抓出来，做一个简单的关键词交验——提取引用片段和答案句的公共数字、年份、专有名词，如果公共部分太少，就标记为可疑引用，丢回去重新生成，或者从回答里删掉这句引用。

这个校验脚本不要求语义精确，但作为一层兜底，能拦截至少七八成明显的引用错位问题。

5.3 文数字相互矛盾：多来源冲突检测与置信度标注

一份年报里“管理层讨论”部分说“营业收入同比增长15%”，另一处“财务数据摘要”却写着“同比增长14.8%”。原因是不同章节对同一指标的统计口径有所差异，比如是否含税、是否包含非经常性损益。这属于金融文本的天然冲突。

RAG如果同时检索到这两个片段，让模型自由选择，它极有可能混合两个数字，编出一个13.9%之类的中间值。对这种多来源冲突，我不信任让模型自己判断，而是做了“来源冲突检测”预处理：在召回阶段，如果Top K片段里出现了多个不同数字对应同一指标的情况，就触发冲突处理逻辑——把这些候选片段的关键数值差异高亮出来，提示用户“检测到多来源数据不一致，请人工核对原文档”，而不是强行生成一个看似光滑的答案。

这个设计牺牲了一部分“智能感”，但杀了“人工复核成本”这个痛点。在金融场景里，宁可让系统暴露不确定性和矛盾，也不能让它给出看似确定实则虚假的答案。

5.4 长文档检索不到关键信息：分块召回与多查询展开

长文档切块后有一个经典困境：关键信息藏在文档中间，当前问题的表述方式又和原文差距很大。比如问题说“公司的短期偿债能力如何”，原文里却只出现了“流动比率”“速动比率”“经营性现金流”，没有一个字提到“短期偿债能力”。向量模型对这种抽象和具体的映射，哪怕语义再先进，也可能失手。

解决思路是“多查询展开”。把一个问题改写成多个不同表述的子查询，比如原问题改成三条子查询：“流动比率和速动比率情况如何”“短期偿债能力相关指标”“公司是否存在偿债风险”。三条子查询并行做混合检索，再把结果合并后统一重排。查全率明显提升，代价是查询延迟增加了300到600毫秒。对金融问答来说，这个延迟换召回率是非常划算的。

5.5 常见问题速查表

6. 评测方法与效果分析

6.1 金融问答评测集的设计原则

做一个RAG系统，评测集的质量决定了优化的方向。金融问答的评测不能只看“回没回答对”，标准答案必须包含三个维度：召回片段是否准确、生成答案是否完整、引用溯源是否正确。

我建了一套小型评测集，大概200个问题，分四类：数值抽取类（直接回答问题里的具体数字）、对比分析类（两年数据的比较）、条款查询类（合同或监管条款的定位）、推理总结类（需要综合多个片段整合答案）。每类问题的答案由人工标注，给出标准答案和对应的参考原文片段编号。

特别重要的是，评测集要包含“无答案问题”。金融文档库做不到100%覆盖用户问题，总会有文档里没有答案的情况。评测系统应该对这类问题回答“未找到”，而不是强行编造。无答案样例的引入，能逼着系统学会“宁可说不知道”，这对金融场景尤其关键。

6.2 召回率、MRR与Faithfulness的实测结果

我的评测脚本会计算三类指标：

• Recall@K：正确答案对应的片段是否出现在前K个检索结果里，K取5和10。
• MRR（Mean Reciprocal Rank）：第一个正确答案片段出现位置倒数的平均值，衡量正确片段能排多靠前。
• Faithfulness（忠实度）：生成答案里的关键事实点是否都能在引用片段里找到依据。Faithfulness的自动化评测比较复杂，我的实现是让生成答案里的数值和专有名词与各引用片段做交叉校验，凡是出现无法在任意引用片段中匹配到的数值，就判定为不忠实。

实测结果大致如下：

这个表现在Demo规模下已经比较理想，但要知道测试集只有200个问题，领域又聚焦，实网环境有更多噪声，指标表现会回落。

6.3 端到端延迟数据与可接受的优化方向

端到端延迟是金融RAG落地的另一条生命线。实测在单张消费级显卡上跑Embedding和重排，完整查询链路的延迟如下：

整体在1.8秒到3.3秒之间。金融问答场景里这个延迟是可以接受的，分析师操作时没有明显等待焦虑。如果后续要上生产环境，重点优化的是重排阶段，把这部分计算并行化或者改用更轻量的模型，能砍掉至少50%耗时。生成阶段受模型推理速度制约，除非换硬件或换成流式输出，否则优化空间有限。

7. 部署落地的真实体验与几个改进方向

整套系统部署起来不算复杂。我用Docker编排了三个服务：向量数据库容器、重排模型服务容器、主查询服务容器。Embedding模型和生成模型分别加载，运行期内存占用大约8GB左右，消费级16GB内存机器可以轻松支撑Demo运行。

部署过程中印象最深的坑是初始化加载模型时容易把显存和内存同时吃满，重排模型的batch size没调好直接OOM。解决办法是把重排的batch size调成1，牺牲一些吞吐，但稳定度大幅提升。

另一个体验是金融领域的反馈闭环特别重要。分析师使用后给出的反馈往往不是“准确度怎么样”，而是“这个数据的单位对不上”“这个是旧版公告的结论”“这两个条款有冲突，你别替我合并”。这些反馈都是评测集里很难构造的，需要真实业务场景的输入才能暴露。所幸RAG架构天然支持局部修复——发现问题，改切片策略、调检索规则、重跑索引，几个小时内就能迭代一版。这比重新训练模型要快太多了。

后续如果有余力，我想在三个方向上继续深入：一是做图表和数字的可视化回溯，让分析师能直接在页面上看到答案对应的原文高亮，而不是只给一个文本引用编号；二是在召回阶段引入知识图谱，把公司、行业、指标之间的关系显式建模，减少纯语义检索的歧义；三是做增量索引的自动化，新文档进来自动触发解析、切片、入库，把整个索引构建流程从离线批处理升级成持续数据管道。

最后说一个我用到现在最深的体会：金融RAG的价值评估，从来不是“这个AI能不能聊天”，而是“它能不能把找数据的时间从半小时压缩到三十秒，同时让人敢放心用它的答案”。所有的技术选型、参数调优、架构设计，如果能回到这个问题上来审视，就不会跑偏。上面的每个细节，都是我一点点用测试集和真实场景逼出来的，也希望这个Demo的记录，能帮你少走几条弯路。