金融智能体实战：小模型可审计链路如何超越千亿级系统？

1. 这个项目到底在解决什么问题

1.1 为什么金融场景对大模型的要求不一样

前两个月我把一套代号 Mint-Agent 的金融智能体跑通了，核心是用 9B 和 27B 的小参数模型，去完成行研公告解读、财报指标抽取、对账推理和监管口径校验这类任务。一开始团队内部是有争论的，主流方案都在往大模型上靠，千亿参数几乎是默认选项，我们却反着来，把模型越换越小，最后在内部测评集上，9B 模型和 27B 模型在多个金融任务上的综合表现压过了千亿级前沿系统。这篇文章就把这个项目的设计思路、踩坑记录和实操细节整理出来，给做金融 NLP、智能投研、合规审计方向的朋友一个可参考的样本。

先说结论：金融场景对模型的要求，和通用聊天场景根本不是一回事。通用场景里，模型答错一句可以重来，用户笑一笑就过了。金融场景里，一句“这个债券的兑付日是2025年8月15日”一旦出错，可能导致交易对手方在错误的日期上做资金安排。更麻烦的是，就算模型答对了，你也得能回答“为什么是8月15日？依据是什么？引用的是哪份公告的哪一段？”这个“可追溯”的要求，把整个技术方案的选型逻辑全改变了。

1.2 千亿模型为什么在审计场景会“失灵”

很多团队上来就选千亿级模型，理由很直接：效果好、省事。但真正进入金融业务后会发现三个硬伤。

第一是推理链不可审计。千亿模型确实能给出漂亮的答案，但它内部是一个端到端的黑盒。当合规和风控部门要求提供决策依据时，你只能拿出“模型觉得”这三个字，这在业务侧是完全无法接受的。金融行业的底线是“任何判断必须有据可查”，黑盒模型天然过不了这一关。

第二是成本曲线太陡。千亿级模型的单次推理成本按 token 计费，金融场景偏偏是高频调用——实时行情解读、批量公告解析、逐笔交易对账，一天跑几百万次调用，费用直接失控。我们做过粗略估算，同一个任务量下，千亿级模型的推理成本大概是 27B 模型的 12 到 20 倍，而 27B 模型在金融窄域任务上的准确率差距只在 2-4% 之间。

第三是私有化部署困难。银行、券商、保险公司的数据几乎不可能出内网，千亿模型要求的算力集群和显存规模，对绝大多数金融机构来说都是沉重的负担。一个 9B 模型在量化后可以跑到单张 24G 显存的显卡上，千亿模型最少也要 8 卡起步，这就是现实的差距。

所以这个项目的出发点非常明确：不是去和大模型比谁更“博学”，而是比谁在金融这个窄域里更“可靠”。我们把模型参数降下来，把可审计的工程链路建起来，用领域微调加上工具约束，让模型在关键任务上的表现反而更稳。标题里说的“超越千亿级前沿系统”，准确说是在金融垂直任务、可审计性和单位成本效率三个维度上的超越，而不是全局性的全面碾压——这一点必须先说清楚，免得误导。

2. 核心设计：可审计的金融智能怎么落地

2.1 用 9B/27B 的真正理由：窄域优先

做这个项目之前我先把团队内部的思路捋了一遍：金融智能体到底需要什么样的能力？答案是四个字——窄域专家。通用模型需要知道“天上的星星为什么发光”，但金融智能体只需要知道“某份年报里应收账款变动的原因”。我们不需要它博学，需要它在自己负责的领域内不犯错，且每个结论都能被验证。

9B/27B 模型在参数规模上确实不如千亿模型，但这恰恰是优势。参数少，意味着模型容量小，它装不下太多“杂学”，但也因此更有机会把注意力集中在金融领域的结构上。我们做了大量的 LoRA 低秩微调，把财报模板、公告格式、监管口径、会计准则关键词这些领域知识注入模型。微调完成后，模型在金融语料上的表现几乎是“指哪打哪”，因为它没有那么多的无关知识来干扰判断。

小模型的另一个优势是推理速度快。千亿模型在单卡上做一次完整的金融推理可能要 15-20 秒，而 9B 模型在同样的任务上只需 2-3 秒。金融场景里延时是刚性的，比如实时行情异动解析，晚 10 秒就是另一条新闻了。我们实测下来，在单张 A100 或 4090 上部署 9B 模型，QPS 可以稳定在 12-15，完全满足中小型业务的实时处理需求。

2.2 审计链路的四层设计

“可审计”这三个字是整个项目的灵魂。我理解的可审计不只是简单的“日志记录”，而是要能做到：任何一个由智能体产出的结论，都能拆回一条完整的证据链，让审计人员可以逐条回溯。我们用了四层设计。

第一层：结构化输出强制。所有模型输出必须是 JSON 格式，包含结论、证据 ID 列表、推理过程摘要和置信度。这一层解决的是“模型说了什么”的问题。模型不再自由输出文本，而是按一个固定的 schema 返回结果。

{ "conclusion": "该债券兑付日为2025年8月15日", "evidence_ids": ["doc_00145_p3", "doc_00328_p17"], "reasoning_summary": "根据募集说明书第三条款约定，兑付日不晚于到期日后十个工作日...", "confidence": 0.93 }

第二层：证据引用绑定。模型在推理时，必须引用知识库中真实存在的文档片段，每个片段有唯一的 doc_id 和段落号。我们用的是 Dense Passage Retrieval 加上关键短语匹配，在检索阶段就把候选证据拉出来，模型只在候选证据的范围内做推理，不允许凭空发挥。

第三层：工具调用留痕。智能体任务里不可避免要调用外部工具，比如汇率查询、行情接口、SQL 数据库查询。每一次工具调用都记录入参、出参、时间戳和调用来源。审计人员可以完整复现当天的调用顺序，是否存在越权查询、是否用了错误参数，一目了然。

第四层：审计报告自动生成。每一轮对话结束后，系统自动生成一份摘要报告，包含输入、输出、涉及的证据、工具调用、耗时和费用。这层设计看起来简单，但实际部署时很见功力，因为审计报告本身也需要格式化存储，我们用的是独立的审计库，与业务库隔离，防止数据被业务操作污染。

2.3 用工具约束来“逼”小模型做对事

做金融智能体，工具的合理使用比模型本身的推理能力更重要。千亿模型常见的毛病是“过度自信”——明明拿不准，非要给一个答案。小模型反而更容易通过工具约束来控制行为。我们把工具调用做成一个强制环节：模型在给出结论前，必须先调用检索工具获取证据，再调用计算工具做数值验证，最后才能输出。

最核心的是把工具调用的入参也纳入审计范围。举个例子，对账场景里模型需要调用一个“差异归因”函数，入参是 A 系统和 B 系统的交易记录。我们会记录这个函数接了哪些参数、返回了什么结果，模型再基于这个结果做下一步推理。如果后续审计发现归因错误，就能直接定位是入参的问题还是模型理解的问题，而不是笼统地把锅甩给“模型”。

另一个细节是，模型对数值型任务的处理不能直接靠“生成”，必须走计算器工具。让模型直接生成“2024年营收增幅为18.7%”这个数字是危险的，因为模型在生成文本时本质是在做概率采样，它可能见过相似的表述，但无法保证精确计算。我们的做法是让模型先提取关键数值，丢给计算器去算，再把计算结果放回回答里。这样即使模型在提取数值时出错，也能在工具调用记录中快速定位。

3. 训练与评测：小模型是怎么跑赢千亿模型的

3.1 数据构建和微调细节

数据是整个项目的燃料。金融领域的高质量数据集并不好找，公开的研报、财报和公告虽然多，但标注质量参差不齐。我们的做法是“大模型合成 + 人工审核 + 对抗样本过滤”三步走。

先用通用大模型自动生成一批金融问答对，比如输入一份财报 PDF，让它生成“应收账款周转天数变化及原因”的问题和答案。这批合成数据量大，一天能生成几万条，但质量不可控，必须进入第二步人工审核。我们的审核团队不是简单看对错，而是做“证据复核”——每一个答案都必须能在原文里找到对应的段落和数字，找不到直接剔除。这一步很费人力，一万条里能留下四千条就算不错。

第三步是对抗样本过滤，这是最容易被忽视但最关键的环节。我们专门构造了一批“看似正确但实际错误”的样本，比如把公告年份换掉、把数字改小、把主体名称替换，用来检测模型是不是在背答案。实测发现，不做对抗过滤的模型在遇到这类样本时，错误率高达 27%，过滤后可以压到 6% 以下。原因很简单：模型在训练时如果只见到“正确答案”，它会默认为上下文中的数字和名称是可信的，遇到篡改版本时依然照着记忆走。

微调层面，我们用的是 LoRA 方法，在 9B 模型上 rank 设为 64，alpha 设为 128，训练 3 个 epoch，学习率 2e-4，warmup 比例 5%，批次大小 16。27B 模型因为参数量大，rank 降到 32，alpha 还是 128，训练轮数 2 个 epoch 就够，再多会出现灾难性遗忘。

数据混合比例也很有意思。纯金融语料只占 60%，剩下的 40% 里，20% 是通用指令遵循数据，20% 是工具调用数据。为什么保留通用指令数据？因为金融任务里有很多指令是通用的，比如“提取”“比较”“汇总”，如果模型把这些基本指令的能力弄丢了，金融数据学得再好也发挥不出来。工具调用数据则专门教模型什么时候该调用检索、什么时候该调用计算器、函数的入参格式是什么，这是金融智能体能“按规矩办事”的前提。

3.2 评测指标和对比结果

没有一套好的评测方法，任何模型效果的说法都是耍流氓。我们搭建了一套“金融审计评估集”，从三个维度打分：事实正确性、推理可还原性、工具调用规范性。事实正确性就是答案本身的准确率，我们要求模型引用原文，因此可以逐字比对。推理可还原性是关键创新点——审计人员能不能根据模型输出的证据列表和推理摘要，完整还原它的思考链。

工具调用规范性主要看调用的准确率：该调检索时有没有调、调检索时查的 key 对不对、调用计算器时公式设置是否合理。有些模型在“该直接回答”时非要调工具，或者在“该调工具”时强行生成答案，这些都是规范性问题，直接影响审计链路的可靠性。

以下是我们在 80 分位样本上的对比结果（满分 100）：

可以看到，千亿模型在“事实正确性”上和 27B 模型差距不大，但在“推理可还原性”上直接被拉开了 26 分之多。这就是为什么很多团队觉得千亿模型“好像还行”，但真推到审计场景就崩——答案对了，但过程没法还原。模型内部到底引用了哪份文件的哪一段，连研发人员自己都说不清楚，更别提给监管解释了。

9B 模型在事实正确性上比 27B 略低，但工具调用规范性反而更高。我们的分析是：9B 模型容量小，更容易被“驯服”，它没有太多的多余能力去玩花样，反而能老老实实按固定流程走。在成本敏感的场景，9B 是完全可用的选择。

3.3 训练踩过的坑

微调阶段踩了三个记忆深刻的坑，全部值得单独拎出来说。

第一个坑是损失函数只看收敛曲线，不看业务指标。用 LoRA 微调时，训练集 loss 一直降得很漂亮，但拿到业务集上一测，事实正确率反而比基座模型还低 2%。排查之后发现是数据配比出了问题——金融语料里带数字的样本占比过高，模型“学会了”输出数字，但没学会检验数字的上下文是否匹配。我们后来在 loss 之外额外监控了三个业务指标，一旦发现业务指标下降就回滚数据配比，重新调整。

第二个坑是知识库检索的召回率卡在 70% 上不去。刚开始用的是纯 Dense Retrieval 的 embedding 模型，遇到“网银手续费”和“电子渠道服务费”这种近义表达时经常召回失败。后来我们在检索层加了一层关键词布尔匹配，用规则把确定性的表达先捞出来，再让 embedding 模型处理语义模糊的部分。双层检索把 F1 从 0.71 拉到了 0.87，效果立竿见影。

第三个坑更隐蔽：对抗样本过滤虽然降低了错误率，但同时也误伤了一些“高难度但正确”的样本。有些真实场景里年份和数字确实会发生变化，模型不该因为“与训练样本不同”就判错。我们的规避办法是把对抗样本的比例控制在 10-15% 之间，并且在训练时额外加入一批“正常变体”样本（年份改但数值关系不变），让模型学会区分“本质变化”和“表面变化”。

4. 部署与平台融合：从模型到可用的业务系统

4.1 最小可用部署配置

很多团队在模型评测阶段信心满满，一到部署就被显存、延迟、并发打回原形。我们这次用实测数据给出一套可直接抄作业的最小配置。

9B 模型用 AWQ 4bit 量化后，权重显存占用约 6GB，KV cache 预分配 8GB，单张 24GB 显存的显卡就能跑。vLLM 部署时把 max-model-len 设为 8192，因为金融文档片段一般不超过这个长度，设太大会浪费显存。温度参数固定在 0.1，金融场景用更高的温度只会增加随机性，没有任何好处。

27B 模型用 AWQ 4bit 量化后约 15GB，建议上单张 80GB 的 A100，或者两张 48GB 卡做张量并行。实测中 27B 在 80GB 卡上的推理速度是 35-40 token/s，对于实时金融对话场景完全够用。

这里特别强调一下向量检索库的选择。我们最初用了通用的文件型向量库，几万条文档时没问题，数据涨到二十万条之后，检索延迟从 20ms 涨到 180ms，直接拖慢了整个链路。后来换成分片式向量库，把数据按行业板块分片，命中率更高的分片可以优先查询，平均延迟重新回到 40ms 以内。经验是：金融智能体的瓶颈往往不在模型本身，而在检索链路的工程设计。

4.2 与低代码智能体平台的对接方式

部署好模型只是第一步，真正把它变成一个业务可用、运营可维护的智能体，需要和平台层打通。我们参考了扣子上金融智能体案例的常见做法——用低代码平台做业务编排和界面管理，把 Mint-Agent 作为“审计大脑”嵌入整个流程。

具体对接上，我们设计了三个模块。第一是安全网关，对所有进来的请求做脱敏处理，涉及用户名、身份证号、交易流水号的字段自动替换成占位符。脱敏后的文本再传给 Mint-Agent 做推理，推理结果中如果出现了原文里不存在的人名或卡号，一律视为异常做拦截处理。这一步是为了防止模型“凭记忆编造用户信息”。

第二是知识库同步模块。金融领域的知识库更新频繁，新公告、新政策、新研报几乎每天都有。同步模块按小时级别从数据仓库拉取增量文档，经过去重、清洗、切片、向量化，再推送到检索库。同时保留历史快照版本，审计时如果发现“同一问题在不同时间答案不同”，可以查看是数据更新导致的还是模型行为漂移导致的。

第三是审计大盘可视化。我们做了一个简单的管理页面，按“用户提问—智能体动作—证据引用—工具调用—最终结论”五段式展示每一次完整交互。运营人员可以做按天的下钻查询，也可以按文档维度反查——一份公告被哪些问题引用过、引用的频率和上下文是什么。这个能力在人工抽检和监管对接时几乎是刚需。

有一个非常值得注意的细节：低代码平台层的对话历史默认不做格式化审计存储，只存原文。如果是普通客服场景问题不大，但金融场景下“用户问了什么”和“模型怎么作答”同样需要留存。我们在对接时给对话系统单独加了一层快照机制，每轮对话的完整上下文都会在审计库中保存一份不可修改的副本，业务库可以清，审计库必须留。

4.3 效果复盘与成本账

最后看效果和成本。我们把 Mint-Agent 接到一个内部的“智能投研助手”场景里跑了三周，覆盖三个业务子流：财报问答、异动解盘、风险核查。

财报问答场景下，用户直接提问“2024年Q3毛利率变化原因是什么”，智能体先检索到对应季报和半年报，再提取关键数字，用计算器算出毛利率的变化幅度，最后给出文字归因。这个流程里，模型生成的文本量大幅减少，但准确性显著提升，因为答案的核心内容来自证据，而不是模型的记忆。

异动解盘场景最考验延迟。用户看到一只票 5 分钟内拉了三个点，马上要问“为什么涨”。我们的链路在行情数据更新后先触发规则引擎，自动抓取相关新闻和公告，生成候选证据列表，再让 27B 模型在候选中选出最相关的 3 条做归因。从用户发问到回答生成，耗时在 4.5 秒左右，其中模型推理只占 1.8 秒，其余时间花在检索和规则匹配上。

风险核查场景则展示了审计链路的真正价值。有用户问“某理财产品的底层资产是否包含违规项目”，智能体检索了产品说明书、投资范围和最新披露文件，给出了“当前持仓未发现违规项目”的结论，同时附带 4 条证据引用。两周后合规部门复核时，就是靠着当时的审计报告和证据 ID 快速完成了追踪，不需要重新向模型提问，也不需要研发人员“回忆当时是怎么处理的”。

成本方面，我们按一个月的调用量做了结算。假设日均调用 20 万次，每次平均 1500 输入 token + 200 输出 token。用 9B 模型自部署，每万次调用的电费和硬件摊销约 3.8 元，月成本约 2.3 万元；如果用千亿级模型 API，按市场价每百万 token 40 元算，月成本接近 37 万元。16 倍的成本差，换来的是相当的行业任务效果和强得多的审计能力，这笔账怎么算都是划算的。

5. 常见故障清单与排查技巧

5.1 高频问题速查表

项目上线三周，我们记录了一批典型故障，整理出来供大家对照排查。

5.2 两个最值得复用的避坑细节

第一个避坑点是“检索召回必须设置最低置信度门槛”。刚开始我们为了追求高召回率，把阈值调得比较低，结果模型经常拿到一批检索结果后“挑一个最顺眼的”做证据，而这个证据可能跟问题相关性只有 60%。后来我们把阈值严格限制，低相关度的候选直接不返回给模型。宁可让模型说“找不到依据”，也不能让它拿弱证据硬答。金融场景里，“不知道”是合规答案，“乱猜”是事故。

第二个避坑点更偏工程：字典型的审计元数据要独立存储。我们最初把审计记录和业务数据放在同一个数据库表里，导致业务高峰期查询互相干扰，审计写入直接拖慢了在线服务。后来把审计存储拆到独立的分析型数据库中，使用列式存储和分区表，按天分区归档。查询审计记录时用独立的只读账号，避免误操作影响在线链路。这件事看起来不起眼，但在金融业务里，审计数据的完整性和及时性本身就是刚需，单独管理能大幅降低排查问题的复杂度。

另外补充一个经验：工具调用的入参和出参最好做数据指纹校验。我们会为每次工具调用计算一个哈希值，存入审计记录。如果有审计人员质疑“当时的函数返回结果是不是被篡改过”，只要重新算一遍哈希比对就行。这个成本极低，但能直接把数据完整性的可信度拉满。

6. 写在最后的项目感受

这个项目做下来，我最大的体会是：金融智能体的核心难点不在于让模型“变聪明”，而在于让模型的每一次输出都能在业务上站稳脚跟。9B/27B 模型能赢千亿级系统，不是因为它更聪明，而是因为它在窄域上更专注，且整条推理链路被工程手段约束得更牢固。

最后再分享一个小技巧，就是我们给训练数据做了一层“时间戳意识”处理。金融语料天然有很强的时效性，比如“截至2024年末”“2025年中报”这些时间表达在文档中到处都是。我们刻意把时间和事实绑定在一起训练，让模型学会区分“数据截止时间”和“当前提问时间”。效果是：当用户问“当前持仓是什么”时，模型能识别出应该用最新披露文件而不是半年前的旧公告。这属于很细的领域语感，但恰恰是这类细节把金融智能体和通用聊天助手真正区分开来。

如果你也在做类似的金融智能体项目，建议不要一上来就追求大参数。先把业务问题拆透：哪些环节需要模型生成，哪些环节应该用检索和工具替代，哪些环节必须靠规则保底。模型只是决策链路里的一个环节，而可审计的工程架构，才是让这套系统真正能在金融行业站住脚的根。