金融大模型应用与智能体建设：从选型到实战的落地方案

简介《2025金融大模型应用与智能体建设案例集》是一份面向金融行业的大模型落地案例参考适合金融机构科技人员、AI产品经理、业务规划者等阅读。资源基于“鑫智奖”评选成果精选50余个来自银行、保险、证券、信托等领域的标杆实践覆盖智能客服与营销、智能风控与合规、知识管理与智能问答、运维安全与测试智能化、投顾与业务管理、创新技术与平台建设六大核心场景并设有金融大模型解决方案选登。内容涉及虚拟数字人、AI合规官、智能问答系统、大模型驱动的智能运维、多智能体投顾等具体案例能帮助读者理解技术选型、场景设计、落地路径与常见问题。资源共1个PDF文件压缩包大小7.75MB目录清晰便于按模块查阅。目前已有70人学习适合作为金融智能化转型与智能体建设的参考手册。1. 金融大模型应用与智能体建设为什么现在值得认真做2025 年做金融大模型应用最难的不是模型不好用而是落地的姿势不对。同一个基座模型有人拿去接知识库做研报问答有人做成交易风控的实时分析助手还有人直接让它操作内部系统里的查询和审批流程——交付物的形态完全不同。这份主题里反复出现的词是“智能体”它对金融场景的意义在于金融业务从来不是单轮问答而是一连串带有状态、权限和审计要求的操作链条。智能体把大模型从“能回答”推进到“能干活”但金融行业的“能干活”有额外约束结果可解释、过程可回溯、权限受控、不能瞎调用工具。这篇文章按照从业者视角把金融大模型应用与智能体建设这个标题拆开来讲。先说明底座模型怎么选、微调和量化部署的边界在哪再给金融级 RAG 的落地方案解决文档切分、表格处理和召回质量随后落到智能体的工具调用、工作流编排和多智能体协作并给出一套可运行的贷前审批智能体代码骨架最后用评测和工程化技巧收尾。适合正在做金融行业大模型项目的算法工程师、后端开发和技术负责人也适合想从通用 Agent 转向行业落地的开发者——这套路径能直接回答“金融场景和大模型结合第一版到底该做成什么样”。2. 选型与基座金融大模型应用先定边界再定模型2.1 金融场景为什么不能直接拿通用模型上线金融行业对模型输出有四个通用场景之外的要求一是知识时效性监管规则和市场数据是持续变化的训练数据截止到某个时间点的模型无法覆盖最新口径二是数值准确性金融问题经常涉及金额、比例、日期模型对数字的幻觉代价极高三是低容错率回答错了不只是体验问题而是可能触发合规风险四是私有化倾向客户资料、持仓数据、交易流水等敏感信息决定了多数金融机构无法接受纯公网 API 调用。因此金融大模型应用的项目起点不是选一个最大的模型而是先定义边界哪些环节可以用通用模型能力哪些必须走私有化部署哪些根本不该交给大模型。常见做法是混合架构——交互和语义理解走模型数值计算和状态校验走代码知识检索走 RAG操作执行走智能体工具。模型只是链路里的一环选型的目标是在准确率、成本和合规三者之间找平衡点。2.2 底座选型对比开源商用、参数规模与部署条件金融场景的底座选型通常在三类之间权衡闭源 API、开源可商用模型和金融领域微调模型。闭源 API 的优势是效果稳定、迭代快适合非敏感场景的快速验证开源模型的优势是私有化部署、数据不出域适合核心系统和监管报送场景微调模型则是在开源基座上用金融语料做增量训练适合需要特定输出格式和专业术语一致性的场景。维度闭源 API开源基座私有化金融微调模型数据安全依赖供应商协议数据不出域数据不出域效果起点高中高中高领域更稳单次调用成本按 token 计费固定硬件成本固定成本训练成本上线周期天级周级月级适用场景智能问答、辅助写作知识库、智能体格式强约束的生成任务参数规模上7B~14B 模型适合推理型 GPU 单卡或双卡部署响应速度快适合智能体高频调用32B~70B 模型效果更好但需要多卡并行或量化适合离线批处理和复杂分析任务。注意不要单看榜单分数要拿自己业务里的 200 条典型问题做盲测金融行业的口径一致性、拒答率和数字准确率比通用能力重要得多。2.3 领域微调的三个关键参数与一份数据准备清单当决定走微调路线时LoRA 是最常见的低成本方案。训练时重点盯三个参数lora_rank决定可训练参数量金融任务一般取 16~32太小学不住术语太大容易过拟合learning_rate建议从 2e-4 起调LoRA 学习率普遍需要比全参微调高一到两个量级max_seq_len至少要覆盖任务中最长的输入金融公告和监管文本经常超过 4096 token建议直接设为 8192 或更高。# finetune_lora.py - 金融领域 LoRA 微调最小示例 from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, TaskType model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct, torch_dtypeauto) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r32, # lora_rank金融术语多取 32 保证容量 lora_alpha64, # 缩放系数通常为 r 的 2 倍 lora_dropout0.05, # 防止微调阶段过拟合到语料格式 target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj] ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filesfinance_instructions.jsonl, splittrain) def format_example(example): prompt f你是金融领域专家。请根据以下材料回答问题。\n材料{example[context]}\n问题{example[question]}\n回答 return {prompt: prompt, completion: example[answer] tokenizer.eos_token} dataset dataset.map(format_example) tokenizer.padding_side right def tokenize(example): text example[prompt] example[completion] enc tokenizer(text, truncationTrue, max_length8192, paddingmax_length) enc[labels] enc[input_ids].copy() return enc tokenized dataset.map(tokenize, remove_columnsdataset.column_names)训练数据里指令的写法直接影响模型输出习惯。材料字段放检索回来的知识片段问题字段是用户提问回答字段是业务专家写好的标准答案。数据准备阶段不要只盯数量300~500 条高质量种子数据跑通流程再逐步扩大到 5000 条以上。常见的坑是数据里只有问题和答案、缺少材料字段——模型会误以为所有回答都该凭记忆输出和 RAG 链路对接时表现会变差。3. 金融级 RAG知识检索比模型生成更容易翻车3.1 为什么金融 RAG 要单独设计切分策略金融领域的知识载体和通用场景有明显差异财报 PDF 是表格密集版式招股书动辄几百页且上下文强依赖研究报告充满图表交叉引用监管公告有严格的结构化字段。通用的按固定 chunk 大小切分方案在这里几乎必翻车。比如把资产负债表从中间切断模型检索到的片段就缺少表头和单位把“上表所示”和上一段表格切到不同的 chunk检索结果就完全失效。所以金融 RAG 第一步是文档解析治理而不是向量化。PDF 要先做版面分析识别标题、段落、表格、页眉页脚再决定切分边界。明文 PDF 可以用解析库直接抽取扫描件必须走 OCR而表格类内容最好转成 Markdown 或 HTML 结构后再入库这样模型能理解行列关系而不是看到一堆被截断的数字。3.2 切分参数实验chunk_size 与 overlap 的量化对比切分参数直接影响召回质量。给出一组在金融文档上实测可用的参数范围但强调必须用自己的语料跑小实验验证。参数推荐区间影响说明chunk_size512~1024 token召回粒度与上下文完整性金融表格建议 512长文本叙事建议 1024chunk_overlap80~200 token跨段语义连续术语密集文档取 150 以上切分策略按文档结构优先层级完整性标题/段落/表格识别后再切推荐做法是先按文档结构切出自然的标题块每个块内部如果超过chunk_size再二次切分。代码里保留每个 chunk 的来源元数据文档名、章节路径、页码、表格序号。元数据的作用不只是追溯还能在检索后做过滤——比如用户只问“2024 年年报里的营收”就可以用文档类型和年份字段先做结构化过滤缩小向量检索范围大幅提升精度。# rag_prepare.py - 结构感知的金融文档切分 from langchain_text_splitters import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter headers_to_split_on [ (#, H1), (##, H2), (###, H3), ] # 第一步先按文档标题结构切保住层级完整性 md_splitter MarkdownHeaderTextSplitter(headers_to_split_on, strip_headersFalse) sections md_splitter.split_text(markdown_document) # 第二步超过阈值的标题块再按语义边界二次切分 text_splitter RecursiveCharacterTextSplitter( chunk_size1024, chunk_overlap150, separators[\n\n, \n, 。, , , ], ) chunks [] for section in sections: if len(section.page_content) 1024: chunks.append(section) else: sub_chunks text_splitter.split_text(section.page_content) for i, sub in enumerate(sub_chunks): chunks.append(Document( page_contentsub, metadata{ **section.metadata, sub_chunk_index: i, doc_name: doc_name, page: page_number, } ))MarkdownHeaderTextSplitter负责保结构RecursiveCharacterTextSplitter负责兜底超长块。分隔符数组按语义粒度从大到小排列先按段落再按中文句号最后才按逗号和空格——这样可以避免把一句完整的金融结论拦腰切断。strip_headersFalse的目的是让标题随 chunk 一起入库检索时模型能看到“第三章 经营情况讨论与分析”这样的上下文信号。3.3 混合检索与重排序金融问答最后一公里的精度提升向量检索对语义相似敏感但对精确数字和专有名词不敏感。金融问题经常是“2023 年 ROE 是多少”这种数值型问题向量召回可能把 2022 年的数据排到前面。解决方法是混合检索向量召回 关键词/全文召回并行再用重排序模型融合。常见的实现是向量检索取 Top 50BM25 关键词检索取 Top 50合并去重后交给bge-reranker这类交叉编码器模型重排最终只取 Top 5 进上下文。重排序模型比 embedding 模型更贵但更准因为它是对“候选文档-问题”做逐对相关性打分而向量检索只是把问题和文档各自编码后算相似度。这个环节通常能把金融问答的命中率提升 15~25 个百分点属于投入产出比最高的优化项。4. 金融智能体应用从工具调用到多智能体协作4.1 金融智能体和通用 Agent 的差异点在哪里通用 Agent 追求的是“让模型自主完成任务”金融智能体在自主性前面加了三道约束权限边界、操作留痕和监督审批。比如同样做“查一下这个客户的风险等级”通用 Agent 可以直接调数据库金融智能体必须走统一接口、记录操作日志并在涉及资金变动或外部发送动作时进入人工确认环节。实际项目中金融智能体通常采用受控自主的设计把动作分为三类只读查询类可以直接执行内部操作类需要用户确认外部发送或资金操作类则需要双人复核或审批流。智能体的价值不是让模型获得更多权限而是在权限框架内把“找哪个系统、用什么参数、按什么顺序调用”这件事自动化。4.2 用 MCP 或函数调用把业务系统接入智能体工具接入是智能体建设的技术核心。2025 年的主流方案是让模型不直接拼 SQL 或调接口而是通过函数调用或 MCPModel Context Protocol协议暴露一组“技能”模型按需选择。MCP 的好处是标准化服务端把业务能力封装成工具和资源客户端统一提供给模型新增一套业务系统不需要改智能体主代码只需要新增一个 MCP 服务。# mcpserver.py - 利润表查询 MCP 服务示例 import json import sqlite3 from mcp.server.fastmcp import FastMCP mcp FastMCP(finance-service) mcp.tool() def query_income_statement(company_code: str, year: int, quarter: int) - str: 查询上市公司利润表关键科目。company_code 为股票代码如 600519quarter 传 0 表示全年。 conn sqlite3.connect(finance.db) cur conn.cursor() cur.execute( SELECT revenue, net_profit, gross_margin FROM income_statement WHERE company_code? AND year? AND quarter?, (company_code, year, quarter) ) row cur.fetchone() conn.close() if row is None: return json.dumps({error: 未查询到数据请检查公司代码或报告期}, ensure_asciiFalse) return json.dumps({ company_code: company_code, year: year, quarter: quarter, revenue: row[0], net_profit: row[1], gross_margin: row[2] }, ensure_asciiFalse) mcp.run(transportstdio)MCP 工具函数名和描述是给模型看的写得越具体模型选错工具的概率越低。query_income_statement这种命名配合说明中的参数单位和边界条件比“execute_query”一堆自由参数可靠得多。注意工具本身的校验逻辑是金融智能体的防守底线——模型传参错误时不能只报异常要返回模型能读懂的提示信息让它自动修正重试。4.3 工作流编排Dify 和 Coze 这类平台在金融场景怎么用智能体平台的价值在于把“模型工具知识库流程”可视化编排。在金融项目里Dify 这类开源平台适合私有化部署Coze 适合快速搭建外部展示型应用。但需要清醒认知平台解决的是编排问题不是数据问题也不是合规问题。金融智能体的工作流建议至少包含四个节点意图识别、知识检索、工具调用、人工兜底。意图识别先判断用户问题属于知识问答、数据查询还是业务操作知识检索走 RAG 链路工具调用走 MCP 服务当模型置信度低或操作敏感时转入人工处理。这个流程在平台上可以用对话流/工作流编辑器搭出来但核心的检索质量和工具封装还是要在代码层做扎实。4.4 多智能体架构情报收集、策略分析、风险校验的角色拆分复杂金融任务单靠一个 Agent 串行处理容易出现上下文过载和职责混乱。常见的做法是拆成多智能体协作情报智能体负责抓取和汇总信息策略智能体负责生成分析结论风险智能体负责对结论做合规校验。三个角色各用一套系统提示词和工具集通过一个调度器串联或并行工作。多智能体的关键设计是不要让 Agent 之间直接对话而是通过结构化消息传递结果。金融场景下每个中间结果都要能被审计A 智能体生成的“推荐买入”不能只作为文本传给 B而应该带上数据来源、置信度和分析依据的字段结构。5. 贷前审批智能体实战从业务拆解到可运行代码5.1 业务目标与智能体能力清单贷前审批是一个适合作为智能体建设首战的场景流程标准化、数据源明确、结果可验证。业务目标是让小微信贷的客户经理输入企业名称后智能体自动完成工商信息核验、司法风险扫描、财务数据汇总结案。按传统方式这套流程需要登录三个系统、复制粘贴六份报告耗时约四十分钟智能体目标是把时间压缩到五分钟以内同时保证每个数据点都有来源可查。能力清单拆解为四件事企业工商信息查询外部数据源、司法诉讼记录检索结构化接口、财务报表读取RAG工具、审批建议生成模型规则约束。对应到智能体设计上就是四个工具加一个输出模板。5.2 审批智能体工作流实现与参数调优# credit_agent.py - 贷前审批智能体主逻辑简化版 from openai import OpenAI import json client OpenAI(base_urlhttp://localhost:8000/v1, api_keylocal-model) SYSTEM_PROMPT 你是一名信贷审批分析助手。你的任务是根据提供的企业信息生成贷前审查建议。 规则 1. 只使用工具返回的数据做分析不得编造任何数据。 2. 工商状态异常、有未结清诉讼、财务指标恶化时必须给出风险提示。 3. 审批结论只能是三个等级通过、审慎通过、拒绝。 4. 输出格式为 JSON字段包括conclusion, reason, risk_factors, data_sources。 TOOLS [ { type: function, function: { name: get_company_registration, description: 查询企业工商注册信息包括经营状态、注册资本、成立日期, parameters: { type: object, properties: { company_name: {type: string, description: 企业全称} }, required: [company_name] } } }, { type: function, function: { name: get_company_litigation, description: 查询企业司法诉讼记录返回涉诉数量、案件类型和标的金额, parameters: { type: object, properties: { company_name: {type: string, description: 企业全称} }, required: [company_name] } } } ] def call_tool(tool_name, args): if tool_name get_company_registration: return {status: 存续, registered_capital: 500万, establish_date: 2015-06-01} elif tool_name get_company_litigation: return {case_count: 2, unsettled: 1, total_amount: 120万} messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: 请审查上海某某科技有限公司的贷款申请}) for _ in range(5): # 最多迭代 5 轮防止工具调用死循环 resp client.chat.completions.create( modellocal-model, messagesmessages, toolsTOOLS, tool_choiceauto, temperature0.1, # 审批场景低温度保持输出稳定 max_tokens1024, ) msg resp.choices[0].message if msg.tool_calls: messages.append(msg) for tc in msg.tool_calls: result call_tool(tc.function.name, json.loads(tc.function.arguments)) messages.append({ role: tool, tool_call_id: tc.id, content: json.dumps(result, ensure_asciiFalse) }) else: print(msg.content) break这段代码展示了智能体的核心循环模型决定调什么工具拿到返回结果后再继续推理直到不再请求工具、输出最终结论。关键参数说明循环上限 5 轮是防止模型在工具调用中空转temperature0.1压低随机性输出格式不直接限定 JSON 而是靠 system prompt 约束配合模型自身能力在解析层做兜底校验。5.3 提示词约束与输出解析的边界处理审批场景的提示词不能写成“你是一个有用的助手”要写成一段带规则的评审手册。上面代码里用编号列出四条硬规则比一段模糊的“请客观分析”有效得多。实际项目中建议再加两条拒绝时必须有对应的数据依据审慎通过时必须列出需补充的材料清单。输出解析的坑在于模型偶尔会输出 JSON 之外的内容比如解释性文字。生产环境要写一个宽容解析器先尝试json.loads失败则用正则截取第一个{到最后一个}的片段再解析。如果解析还是失败就返回重试指令让模型重新生成。这个兜底逻辑是金融智能体上线前最容易漏掉的部分。6. 评测驱动迭代金融智能体效果度量与上线前的一个必要技巧金融智能体不能只看回答是否“像样”要按能力维度分开评测。常见的评测集至少覆盖四类任务知识问答覆盖 RAG 召回、数据查询覆盖工具调用、分析报告覆盖生成质量、风险拒答覆盖安全边界。每个任务准备 50~100 条标注样本标注字段包括正确性、完整性、格式合规性和幻觉程度。评测要区分模型能力和系统能力。比如用户问“这家公司的毛利率是多少”如果知识库里有数据但没召回问题出在检索链路而不是模型如果召回了但模型算错问题出在推理链路。上线后建议持续记录三种不可接受表现数据幻觉模型说出工具返回中不存在的数据、工具误用调用错误的接口或参数、流程逃逸跳过了必备的确认步骤。业务方对智能体的信任靠的是这些负面指标的持续收敛。这个评测集要固化下来每次更换模型版本、修改系统提示词或调整检索参数后都跑一遍全量回归。最后给一个上线前的必要技巧给智能体加一层协议审计日志。不只记录用户输入和最终输出而是记录每一步的工具调用细节包括选中了哪个工具、传了什么参数、返回了什么结果、模型在拿到结果后做了哪一步推理。做法是在工作流中间件里埋点把所有事件写成一个 JSON 事件流。这层日志既是评测集的自动素材来源又是以后排查问题的关键入口。在金融场景可回溯性往往比效果本身更能决定项目能不能上线。后续迭代时拿这批真实工具调用记录去构造新的评测用例比业务方凭记忆写样本高效得多这也是让智能体持续变好的核心节奏。本文还有配套的精品资源点击获取