金融大模型：架构变革、工程实践与 Agent 智能体的前沿探索

导读本文整理自恒生电子研究院 AI 首席技术专家林金曙，在 DAcon 上海站 2026 的分享，他系统梳理了金融行业落地大模型的三重挑战：合规刚性、数据安全与业务严谨性。基于恒生电子在券商、基金、银行等机构的实际项目经验，团队从长文档检索、财务信息抽取、审核规则执行等高频场景出发，探索了一套以 PageIndex 与 Agentic RAG 为核心的检索架构，以及以“好需求”定义与大模型选型为抓手的审核工程方法。

主要内容包括以下几个部分：

背景与趋势：金融行业的特殊性决定了大模型的落地路径

2. 场景分享：从实际落地案例看大模型价值

3. 工程实践：踩过的坑与爬出来的方法

4. Agent 探索：从工具调用到自主规划

未来展望：不卷织布速，卷机器驾驭力

分享嘉宾｜林金曙恒生电子研究院 AI首席技术专家

编辑整理｜韩珊珊

出品社区｜DataFun

背景与趋势：金融行业的特殊性决定了大模型的落地路径

金融行业的大模型应用无法照搬通用方案。三家外部约束构成了技术选型的硬边界：合规要求每段生成内容可溯源、结果需人工确认；安全要求私有化部署、数据不出域；严谨要求私域数据与业务系统无缝挂接，数据质量优先于模型能力。

在这些约束下，团队得出的第一个判断是：不要试图用通用模型覆盖一切，而应基于大模型重构金融 IT 架构。传统系统烟囱林立、智能化程度低、需求响应慢。新架构的方向是业务能力原子化（Skills）、金融大模型插件化，以及面向大模型友好的数据层（AIDB）。这不是锦上添花，而是决定大模型能否真正进入生产环境的门槛。

场景分享：从实际落地案例看大模型价值

机构运营场景中，机构客户临柜办理业务需提供两百多件材料，操作路径极其曲折。团队将这类流程抽象为：系统应用性的最高标准是不需要用户学习。大模型的作用不是替代交易系统，而是将用户的自然语言意图转译为系统操作序列——好比从“看地图”进化到“听导航”。

投顾理财场景则暴露了另一个痛点：监管放开后理财经理需要面对全量保险产品，某真实案例中客户购买保险后两个月自杀，家属理赔时才发现条款要求“投保满六个月”。传统搜索只能定位到条款段落，无法完成“检索→判断→告知”的闭环。RAG 只解决“看懂”，真正的业务闭环仍需调用原有系统接口。

托管运营的案例更具冲击力：某头部基金公司 CIO 半夜来电求助，每季度几千个指标的信披报告，错一个指标督察长就要被罚款，二三十人专职审报告仍频出错。团队用大模型搭建审核系统，将净值、勾稽关系等规则自动化，极大降低审核压力。

而投行场景中，一份蜜雪冰城招股书长达 1300 页，传统 RAG 直接失效——这引出了工程实践中最核心的一战：长文档检索。

工程实践：踩过的坑与爬出来的方法

搜-金融长文档检索的四大难题

长文档检索面临四个典型困境：文档超长导致切出数千个 chunk，向量库检索效率极低；“营业收入”这种高频词在五十处出现，无法区分哪个才是目标章节；表格中的数字和表头被分在不同 chunk，模型看到数字但不知含义；而“哪些公司净利润超过 XX 亿”这种问题必须扫完所有页才能回答。

团队没有陷入“调优向量模型”的局部最优，而是回到第一性原理：金融文档受监管严格约束，目录与章节结构本身就是最强的索引。人找文档时，先翻目录再定位页码，而不是全局关键词搜索。于是诞生了 PageIndex 方案：离线解析文档标题层级，建立“章节名↔页码范围”的映射。查询时先匹配目录，将检索范围从 300 页压缩到 3 页，再在定位范围内做精细 chunk 检索。结果是表格完整、来源精准、噪音极低。

但单次检索仍无法解决复杂推理问题。Agentic RAG 将任务拆解为子问题，动态调用 PageIndex、BM25、向量检索等工具，自我评估信息是否足够，不足则继续检索。团队给出的金融实践建议是 PageIndex 与 Agentic RAG 组合使用，单 chunk 召回准确率超过 95%。一个反常识的决策是：团队在 2023 年主动去掉了向量检索。理由在于金融查询中有大量精确匹配（代码、专有名词、数字），向量模型的“语义近邻”反而引入噪声，BM25 在金融精确查询场景反而更准。这一判断后来被 OpenAI 的无向量化 RAG 技术路径所印证。

抽与审：好需求 vs 差需求

许多项目一开始就失败，不是因为大模型太笨，而是业务知识与经验没有进入上下文。团队将“差需求”定义为：丢给模型一篇几百页底稿，说“审一下”。而“好需求”必须告诉模型三件事：在哪里看（限定章节范围而非全文）、看什么（用业务语言描述字段如“注册资本”，而非系统拼音缩写）、怎么判（将 SOP 写成可执行的判断条件，如“发行总股本以‘股’为单位”）。

选型方面有一个惨痛教训。最初使用 Qwen3-32B，为了把准确率堆上去，写了 530 条规则、4300 行配套代码，团队半年内三人离职。换成 Qwen3-235B（四张 H800 或 H20，一次性投入约六十万）后，规则砍掉大半，准确率提升约四十五个百分点。结论是：用小模型省下的算力钱，远不够覆盖人力成本和隐性损失。

上下文工程同样关键。原 prompt 约两万四千 token，新 prompt 压缩到不足三千 token。核心做法是一百八十个财务指标按需拼入 prompt，章节目录与表头信息动态使用，避免一次性塞入。最难的事不是模型推理，而是让模型在恰当的时机看到恰当的信息。团队还总结了模型的能力边界：擅长语义理解、意图识别、从非结构化文本抽字段、改写摘要、分类打标；不擅长高精度数值计算、跨段落勾稽比对、长链条多步推理、实时高并发零容错。把计算和逻辑校验交给

Agent 探索：从工具调用到自主规划

金融行业需要的 Agent 不是聊天机器人，而是能够操作业务系统的执行者：读文件、调接口、写结果、必要时提问人。

OpenClaw 在金融场景暴露了四个短板：权限边界模糊，缺乏只读与需审批写入的细粒度分级以及高风险操作前的强制确认；审计不足，执行轨迹粒度不够，无法向监管解释决策来源；插件无管控，没有金融级安全审核，模型容易误调工具；幻觉无兜底，没有高风险操作拦截清单和结构化中间状态存储。

三件事必须同时成立：模型自身的任务拆解、规划、反思能力以及长上下文和 Function Call 的稳定性；下游工具足够成熟，业务能力拆成原子 Skill，用 MCP 协议接入，失败可重试；资源对模型友好，包括文档结构化（AIDB）、知识分片、接口描述业务化。

在投顾 Agent 的实战中，每个 Skill 需明确所需物料、数据来源和权限级别（只读、只调代码、写需人工确认）。最容易缺失或过期的物料包括超过两年未更新的风险测评、非实时的产品申购状态、未同步的适当性规则。接口描述的大模型友好改造同样重要：旧描述“基金分红历史信息”改为“【查询】基金分红【过去指定时间，如去年、上个月等】范围内的分红记录”，要求清晰（带上时间、业务标签）、一致（避免 JJJJ 这类缩写）、业务性（复杂功能封装为组合接口）。

长期要做两件事：一是业务能力 Skills 化，将烟囱式系统拆成颗粒合适的原子 Skill，统一注册、统一描述、统一权限管控；二是接口对大模型友好，加功能说明、入参业务含义、前置条件、典型返回示例，把字段命名改成业务语义，区分实时与历史、查询与变更。困难不在技术，而在于业务侧愿不愿意开放自己的能力——这需要组织层面推动。