9B/27B双模型如何撑起可审计金融智能？Mint-Agent实战解析

从“9B/27B凭什么叫板千亿参数”说起：我如何把Mint-Agent做成可审计的金融智能

金融场景里让AI真正上手做事，最折磨人的永远不是“准确率差多少”，而是“这结论万一错了，你能不能把整条决策链拎出来给稽核的人看”。过去大半年我把所有精力压在一个叫Mint-Agent的项目上——用9B主推理模型加27B复核模型的双层结构，在财报抽取、财务分析、合规话术识别这些真实任务上，跑出了比预期更好的成绩，部分指标甚至超过了市面上打着千亿参数旗号的商用系统。这篇文章想把整个项目的设计逻辑、可审计链路怎么落地、双模型怎么分工、实测结果如何，以及我踩过的几个真坑完整讲一遍。不管你是做金融NLP、智能投研系统，还是想在垂直领域里用中小规模模型替代大模型，这篇都值得看完。

先说结论：在金融垂直场景里，模型参数规模带来的边际收益，远没有各种榜单宣传的那么线性。千亿模型在通用常识和复杂推理上确实有碾压性优势，但金融智能把任务高度拆碎之后，真正吃“基础语言能力”的环节变少了，吃“结构化知识、工具调用、证据绑定、口径规范”的环节变多了——而后这些维度，恰好是可以用工程手段补出来的。下面我按项目推进的时间线，把关键决策和踩坑记录都摊开讲。

1. 金融任务的能力分层：为什么“不是所有问题都值得上大模型”

接手项目时，业务方提的需求是“要追上当前最强的商用金融AI”。但我在前期调研里发现，通用大模型在金融任务上有三块很明显的短板：第一，回答几乎不给你留追溯空间，问它就是一段流畅的“根据公开信息”，完全无法定位到具体的财报页码或条款编号；第二，金融专有术语、报表口径、监管定义的颗粒度不够，回答泛泛但经不起追问；第三，在天天调接口的agent场景里，按token计费的商用接口价格非常难看，业务方根本承受不起高频调用。所以项目从第一天起就定下了两个目标：用可控规模的开源模型做出可追溯的金融决策链路；在预算可承受的范围内把效果拉到接近甚至超过商用千亿模型。

要达成这两个目标，第一件事是把金融任务做能力分层。我把任务分成四层：

• 第一层：结构化信息抽取。比如从财报里抽营收、净利、现金流，从公告里抽日期、金额、关联方。本质是“格式化信息定位”，拼的是检索精度和字段边界感知，不拼推理。
• 第二层：标准化流程交互。例如查行情、算收益率、核对科目余额、判断涨跌幅，规则清晰、有标准答案。
• 第三层：组合推理分析。比如“这家公司自由现金流连续三年下滑但净利润在涨，问题出在哪”，需要跨字段、跨年报、跨指标的综合判断。
• 第四层：合规风险与审计判断。比如某笔交易是否符合关联交易披露标准、某产品话术是否触犯夸大承诺红线。这层不仅要求结论正确，还要求给出依据、推理过程和可复核的证据链。

很明显，从第一层到第四层，对模型能力的需求是逐渐升高的。但这里有个关键数据：我们统计过实际的智能问答、报告生成、投研辅助场景，第一和第二层任务加起来占了大概65%到70%。换句话说，如果一刀切全上大模型，等于拿高成本去跑大量结构化任务，而模型真正发挥推理优势的场景只有三成左右。

Mint-Agent的核心思路就是基于这个比例设计的：把第一、二层全部固化到9B模型加规则模块的处理管线里，把第三、四层交给27B模型做重推理。9B在这里不是“弱化版大模型”，而是金融任务的快车道。模型小，单次推理成本低、延迟低，可以高频调用；同时配合外部的字段校验器和规则引擎，把正确率兜住。27B则是慢车道，负责高价值、高风险、需要完整推理链的任务。

2. 可审计金融智能的落地：证据链、操作轨迹、结果可复现缺一不可

“可审计”在金融AI里是最容易被喊成口号的概念。很多团队做完一个问答系统就说自己“可解释”，但真到合规检查时拿不出任何能复现的证据。Mint-Agent项目的一大半工作量不在模型训练上，而在把“审计”变成系统的原生物理属性。

金融审计本质上问三个问题：你依据什么做的判断？你经过了哪些步骤？同样的输入能不能复现同样结论？对应到AI系统里就是证据链、操作轨迹、结果可复现。我在系统里把这三点拆成了四个物理层：

2.1 四层审计链路的工程化设计

第一层是输入留痕。所有进入系统的文档、数据表、请求参数，全部保存原始快照并计算存储哈希。万一事后有人质疑某次结论，先验证“喂给模型的原材料有没有被动过”。这是审计的最小单元，没有原始输入，后面一切追溯都无从谈起。

第二层是决策依赖记录。系统记录每一个关键输出点是由哪几条证据支撑的——比如模型回答“该公司流动比率下降”时，必须自动绑定对应的财报页面、行次、数值。这层实现起来最难，因为它要求模型在生成自然语言结论时，同步产出结构化的证据引用索引。我们的做法是在微调阶段引入证据标注任务，强制模型按“结论+证据ID列表+依据片段”的格式输出。注意，这不是简单的prompt技巧，而是数据层面就按这个结构组织标注，模型训练出来之后才能稳定跟随。

第三层是工具调用轨迹。金融agent必然大量调用外部工具：行情接口、计算器、数据库。系统记录每一次工具调用的入参、出参、耗时和异常标志。这层实现难度低，只要工具封装层不偷懒，每个action都写log就行，但价值非常大——很多时候问题不在模型想错了，而在工具喂错了。没有工具轨迹，你永远无法定位责任边界。

第四层是模型行为快照。包括模型版本、温度参数、top_p采样值、上下文长度截断位置。这些看起来是技术细节，但金融合规审计一旦走到“为什么两次同一问题回答不一致”时，这些参数就是唯一的解释依据。

2.2 三道输出约束：把“不出错”变成结构设计

可审计不能只靠事后查，更理想的状态是在生成时就逼着模型沿着可审计的路径走。我在输出层加了三道约束：

• JSON Schema级输出强制。所有涉及金额、日期、科目、比率的字段，一律走结构化输出通道，模型不能自由发挥格式。金额就是“value+currency”结构，日期就是ISO8601，科目就是枚举值。这样后续任何校验逻辑都能直接在结构化数据上做，不用再解析自然语言。
• 证据绑定强制。模型给出任何带断言性质的句子前，系统先检查上下文里是否存在对应的证据块。如果找不到，就触发“无法回答并说明缺失项”的兜底逻辑。在金融场景里，说“不知道”比说“我认为”安全一百倍。
• 数值一致性校验。模型引用某个财务数值时，系统用解析出的结构化字段做比对，不一致立刻报警。这里我强调一下：数字字段必须像银行系统做借贷平衡校验一样强校验，不能依赖模型的自我纠错。

这套约束最考验人的地方，是怎么避免把生成能力压死。我最终的平衡方案是：约束不作用在token层面，而是作用在“输出通道选择”层面——让9B模型先决定当前输出走哪个通道（结构化字段通道、自由文本通道、还是工具调用通道），再在对应通道内做严格约束。模型保留了表达灵活性，但关键信息永远落在受控通道里。

3. 双模型架构的取舍：为什么是9B+27B，而不是单个13B或者70B

Mint-Agent选择双模型方案，过程里其实纠结过好几次。最初考虑过单模型：一个13B的模型扛所有任务。但对比下来，13B在第四层任务（合规判断、复杂推理）上还是不够稳，而在第一、二层任务上又比9B贵，属于两头不占优的尴尬定位。

接着又考虑过直接上70B。70B在推理能力上确实强很多，但参数量上去之后，部署成本和响应延迟同步上来了。关键是在金融工具调用场景里，70B模型在“subset准确率”上并不会比27B好太多——这里的瓶颈已经不在语言能力，而在对工具契约的理解和指令跟随的稳定性。举个例子：调用行情工具时，模型需要严格按照入参schema生成JSON请求体。这个问题上70B和27B的差距很小，但9B通过微调也能达到可用水平。换句话说，工具调用的准确率主要取决于微调数据和工具契约本身的清晰度，而不是模型规模。

3.1 路由规则：不依赖分类模型，用规则加打分机制

双模型架构最怕路由拍脑袋。我设计了一套基于“任务复杂度预估”的轻量路由规则，不依赖额外的分类模型，而是用规则加打分：

• 命中工具调用模板（查行情、算指标、抽字段）且验证结果有标准答案的，直接走9B。
• 请求包含“分析”“判断”“解释”“风险”等高层语义词，且上下文里有多份报告或跨期数据时，自动升级到27B。
• 纯自然语言问答但无工具需求时，先走9B；若9B输出的置信度低于阈值，再交27B复核。

这套规则在实际运行中非常稳。核心原因还是金融任务的高度模板化——用户问“XX股票今天涨了吗”和“YY债券到期收益率是多少”，底层处理的模式高度一致，根本不需要上模型做意图分类。规则路由反而更可控、更容易审计：你随时可以说清楚“这条请求为什么去了9B、为什么去了27B”。

3.2 27B的复核机制：生成者+证伪者

27B在Mint-Agent里不只是“大号的第二决策者”，更多扮演复核者的角色。关键路径是：9B完成一次判断或生成后，如果任务属于第三、四层，系统把9B的原始回答、相关证据块和工具输出打包成一个复核单元，交给27B做“证伪式检查”——注意，不是让27B重新做一遍，而是让它重点找出9B回答里可能存在的错误、遗漏或过度推断。

这种“生成者+证伪者”的结构，比两个模型同时生成再投票更高效。原因在于，证伪任务对模型的“怀疑能力”要求高，而“怀疑能力”在大模型上表现得更稳定。9B可能会在“从数据到结论”这步上犯错，但27B做“检查这个结论是否被数据支持”时，准确率远高于它自己完成完整推理。实测下来，27B复核能拦截掉大约60%到70%的9B高风险错误，这个比例非常可观。

4. 超越千亿参数系统的秘密：数据权、控制权和评测集的公平性

说“超越千亿级前沿系统”，我并不觉得这是什么神秘的模型能力胜利，而是一种很现实的工程逻辑：在垂直金融场景里，可控模型加结构化数据加上下文工程，足以在准确率和稳定性上压倒通用大模型。这里的关键词是“数据权”和“控制权”。

4.1 知识注入的颗粒度控制

千亿模型知识面广，但金融知识贵在“准”不在“广”。Mint-Agent的微调语料来自上市公告、监管文件、财报审计报告、机构研报摘要四类数据，每份都切成带标注的证据单元。这种精细的知识注入有两个直接好处：

第一，模型回答财务问题时，更倾向于使用语料里真实出现过的口径和数字，而不是自己脑补。第二，模型能自然学会“引用来源”的格式，因为语料本身就带出处标记。知识注入不是往模型里塞书，而是让模型理解“在这套金融语言系统里，什么说法是成立的，什么说法是需要标注来源的”。千亿模型的隐性知识在通用领域很有用，但在金融这种对措辞极敏感的场景里，隐性知识反而可能是负担——你不知道它什么时候会把一个过时的口径当成现状说出来。

4.2 可控的上下文工程：给模型划一条合规边界

第二个关键技巧是上下文里的“边界控制”。Mint-Agent在每次请求前都会做一次合规性上下文注入——把一个动态更新的“金融应答边界”模板插入系统提示词，里面写明了哪些情况不能直接给结论、哪些词汇禁止用于承诺性描述、哪些问题必须先引导用户提供材料。这个模板只有几百个token，但对模型行为的约束力极强。

举个例子：用户问“这个理财产品保本吗”。9B模型在没接合规边界模板时，可能按通用知识回答“理财有风险，不保本”；接了模板后，模型会先判断用户是否已经看过风险揭示书，再决定回答口径。这种“边界优先”的机制，是千亿模型很难做到的——它的系统提示词被通用性绑架了，不可能为一个金融场景做到这么细粒度的策略注入。

4.3 评测集里的隐性偏差

我还想提一个可能不太中听但很现实的观点：市面上很多“千亿模型吊打小模型”的评测，用的数据集本身就是从通用语料里采样生成的，天然偏向通用能力。而在金融领域，一旦评测集换成“真实柜台问答记录+财报引用任务+审计复核场景”，千亿模型的优势会被迅速拉平，小模型加工程补强的组合反而更容易胜出。Mint-Agent在对标测试里能排到前面，有一部分原因是我们评测集更贴近真实业务的长尾分布，而不是去迎合benchmark里的标准题型。这里也提醒所有做金融AI的同行：评测集设计的颗粒度，直接影响你对模型真实能力的判断。

5. 实测对比与三个印象深刻的坑

这一节直接说数据和踩坑，都是真金白银换来的经验。

5.1 内部测试集上的对比结果

我把Mint-Agent（9B/27B组合）和某千亿参数商用模型在四类典型任务上做了对比，数据来自内部测试集：

前三类任务Mint-Agent都赢了，最后一个复杂分析任务输了一点。这个结果完全符合我们的设计逻辑：结构化、工具化、证据化的任务，9B+27B组合有优势；纯粹开放式、高度依赖隐性知识的综合分析，千亿模型的反击空间就出来了。这个短板我们在后续版本里通过扩大27B复核覆盖面和引入外部知识图谱做了缓解。

5.2 数字精度的“幻觉区”：金额单位吃掉了三位

项目刚上线时，我们发现9B模型在抽取金额时偶尔会把“1,234万元”抽成“1234万元”，或者把“净利润率”和“毛利率”搞混。问题不在模型理解不了，而在于最开始没有给数字字段加类型校验。修复方案是在输出通道里加“金额/比率/日期”三段式校验器，数字经解析器转成结构化对象再返回。从此以后，数字格式错误几乎绝迹。这个坑让我彻底明白：金融AI里数字字段必须像银行系统一样做强校验，不能把希望寄托在模型自我纠错上。

5.3 长文档里的证据偏移：90页招股书里数据打架

有一次实测，用户上传了一份接近90页的招股书，9B模型从第30页抽到的数据跟第70页的数据打架了。追踪下来发现是长上下文注意力分散，模型过多关注了开头章节。解决方式有两个：一是在检索阶段做分块召回，只把相关段落送进上下文，不搞全文硬塞；二是要求模型在引用时带上页码和章节号，系统再对页码做存在性校验。这两招组合之后，证据偏移的问题降低了八到九成。

5.4 工具数据卫生问题：行情接口返回0元收盘价之后

这个坑最隐蔽，也给所有做金融agent的同行提个醒。我们的行情工具偶尔会返回异常值，比如某只股票因停牌返回0元收盘价，9B模型拿到0元后没有怀疑数据异常，反而一本正经地分析“该股下跌100%”——关键是它还能分析得非常有条理，把原因都编圆了。复盘后我们做了两件事：第一，工具出参的元数据（数据状态字段、异常标志位）也纳入上下文，让模型能感知数据可信度；第二，在规则层增加强规则：“价格为零”“字段为空”时不准分析，直接转人工确认。结论是：模型犯错很多时候不是它自己的错，工具层的数据卫生必须优先解决，否则后面一切都是空中楼阁。

6. 部署和成本计算：9B/27B组合在真实环境里的账

最后聊落地环节，模型效果再好，部署成本不现实也是白搭。Mint-Agent在成本结构上的优势非常明显，这也是我敢在项目里坚持双模型组合的直接原因。

6.1 推理成本的实际对比

我按内部压测数据算过一笔账：千亿商用模型跑一次复杂金融问答的平均成本，约等于27B模型的12到15倍，约等于9B模型的40到60倍。如果按单日处理10万次请求的规模计算，9B/27B方案在GPU租赁成本上能省出一支小型研发团队的工资。这还不算数据合规带来的隐形成本——商用闭源接口把数据送到外部处理，在很多金融机构的合规审查里根本过不了关，自己部署开源模型反而成了唯一合规选项。所以Mint-Agent采用本地化部署，反而是合规倒逼出来的最优解。

6.2 部署参考规格

生产环境我们用了两张A800卡，各80GB显存，27B模型开4bit量化跑推理，9B模型开8bit量化跑推理。白天高峰时两个模型共享GPU池，夜间低峰时27B批量处理复核队列。实测单次推理延迟：9B在0.8到1.2秒，27B在1.5到2.5秒。对金融场景的问答和报告生成来说，这个延迟完全可接受。唯一要注意的是量化对模型精度的影响，我们在金融数值输出通道上专门做了精度回归测试，4bit量化对正确率的影响控制在0.3%以内，可以放心用。

6.3 迭代和模型版本管理

Mint-Agent目前以微调开源基座模型为主，但已经开始把真实业务里的错误样本回流到训练集做增量微调，大约每两到三周更新一版。这条路径走通之后，系统的可审计性会更强——每个模型版本对应的错误修复记录都可追踪，审计人员能直接回溯“这个错误在哪个版本修复、修复时引入了哪些新语料”。这里也催生了一个工程习惯：跑金融模型，日志里一定要记录每次推理用到的prompt版本和模型版本。我们曾为了复现一次客户投诉里的回答，花了一下午才定位到是某个prompt模板改版导致的差异，从那以后我把prompt版本管理直接纳入了部署流程。这个细节看着小，关键时刻真能救你一命。

最后再分享一点实操体会

Mint-Agent这个项目做到现在，我最大的感受是：金融AI的竞争，不在模型的参数数量级上，而在“你对自己的判断有没有把握给出证据”。9B/27B能干成千亿参数系统的事，不是因为我们发现了什么神奇的模型配方，而是我们把金融任务里的“证据、步骤、边界、校验”这四个关键词当真了而已。

如果你也要做金融agent，我的建议是从模型的输出结构开始设计，不要在模型选型上纠结太多——先把审计链路、工具层数据卫生和数字强校验这三件事做扎实，模型规模反而不是决定成败的那一环。等到你的系统能把每个结论都追溯到一条可证明、可复现、可审计的链路时，即使模型只有9B，你也有底气跟任何人说：这个智能系统，能扛住金融圈最挑剔的稽核目光。