2025金融AI调研报告解读：大模型选型、RAG与Agent落地实践

简介：这份《2025年金融服务业中国AI现状与趋势调研报告》PDF，基于对全球约600位金融专业人士的问卷调查，重点剖析中国市场AI应用格局，适合金融机构决策者、AI产品经理及行业研究员快速把握前沿动态。报告显示，生成式AI已成为金融领域关键技术，40%中国受访者正使用或评估该技术，并推动数据分析、欺诈检测、个性化服务、投资组合优化及网络安全等战略用例走向成熟；同时指出AI工厂等计算基础设施投资强劲，企业正从探索AI转向部署高价值用例，生成式AI也日益成为驱动业务变革的催化剂。资源为单文件PDF，共1.35MB，内含完整目录、图表与调研数据，便于按章节定位查阅，可作为行业报告精读、内部培训或市场分析的基础材料。目前已有138人学习下载。

1. 2025年金融服务业中国AI调研报告，先看它想回答哪几个问题

拿到《2025年金融服务业中国AI现状与趋势调研报告.pdf》这类文件，第一反应不应该是转发给领导，而是先确认它到底在回答哪几个问题。这份报告的价值通常集中在四处：AI在金融业务里已经落在哪些环节、大模型选型往哪条路线走、本地部署和外部API的边界在哪里、2025年会冒出来什么新变量。对做解决方案架构、AI产品经理和信贷/风控/量化开发的人而言，这三个信息点直接决定你接下来一个季度的技术预算和排期。看报告时建议先跳过图表页，直接找「调研范围+样本构成+统计口径」这一节，口径对不上，后面的百分比就没有比较意义。

2. 报告里的AI技术栈拆解：从大模型选型到本地部署配置

2.1 金融AI的三类应用形态：对话、RAG、Agent

报告里出现频率最高的应用形态基本可以归成三类。第一类是对话式助手，典型场景是智能客服、投顾问答和内部知识问答，这类系统2024年已经大面积上线，2025年的重点转移到回答质量和人工接管率。第二类是RAG（检索增强生成），把产品说明书、尽调报告、监管公告灌进知识库，让模型基于给定材料作答，这是现在金融AI落地最稳的一条路，因为答案可以被溯源。第三类是AI Agent，它不只是回答问题，而是去执行一个多步骤任务，比如自动读取授信材料、调用风控接口、生成审批摘要，最后把结果回填到业务系统。

从调研报告的统计方式来看，三类形态通常对应不同的评估指标。对话看首轮解决率和转人工率，RAG看重命中率和幻觉率，Agent则看任务完成率和中断次数。看报告时如果发现某个厂商的「AI落地案例」全停留在第一类，那说明它的技术栈还没往深走，这类信息对你的架构选型参考价值有限。

2.2 通用模型与垂直金融模型的取舍：不要只看榜单分数

选型是报告里信息量最大的部分。通用开源模型（比如Qwen系、DeepSeek系）的优势是迭代快、社区生态成熟、部署资料齐全，适合绝大多数对话和文档理解场景。垂直金融模型通常是在通用底座上做过金融语料继续训练或者指令微调，在术语理解、政策口径上表现更稳，但更新滞后，而且往往绑定特定厂商的API。

我一般用三张表来对比候选模型：基础能力（百科、数学、代码）、金融专项（利率计算、产品条款理解、财报数据抽取）、工程属性（显存占用、推理延迟、是否支持函数调用）。注意最后一列，金融Agent场景对函数调用有硬要求，一个新模型即使问答榜单分数再高，如果function calling不稳定，排期就得往后放。

2.3 本地部署与API调用的边界：算力、延迟和数据隔离

报告里「本地部署」的讨论热度这两年一直在涨，核心原因不是成本，而是数据隔离。金融场景的客户资料、交易流水、授信材料通常不允许出域，这就决定了你至少需要一个本地推理环境。常见的部署配置有两档：7B到14B规模的模型搭配单张24GB显存卡，可以承担内部知识问答和文档抽取；70B级别以上则需要多卡并行或者量化方案，一般留给对准确率要求极高的场景。

延迟上也有账要算。API调用虽然首期投入低，但每次请求往返多几十毫秒，放在实时风控链路里就是不可接受的增量；而本地部署在batch推理模式下可以把单Token延迟压到很低。我的建议是「双轨制」：离线场景（文档处理、报表生成）先上本地开源模型，在线场景（客服、营销文案）保留外部API作为备选，中间用统一网关做路由和灰度。

对比维度	本地开源模型	外部API
首期成本	服务器与运维投入高	按量付费，启动快
数据控制	完全域内	依赖供应商数据协议
推理延迟	可控，可优化	有网络抖动风险
模型能力	落后商用API半个版本	更新快，多模态全
适合场景	知识库问答、文档抽取	营销文案、探索性实验

3. 从报告到可复现：金融AI应用落地的最小路径

3.1 用Ollama在本地跑通一个金融问答模型的部署配置

先不要急着上微调和分布式，最稳妥的第一步是本地把一个小模型跑起来。Ollama是目前上手成本最低的本地推理工具，拉到模型后用一份Modelfile就能把金融系统提示词和推理参数固化下来：

cat > Modelfile <<'EOF'
FROM qwen2.5:7b
PARAMETER temperature 0.2
PARAMETER top_p 0.7
PARAMETER num_ctx 8192
SYSTEM 你是金融业务助手。回答必须基于给定材料，不得编造数据；涉及金额、日期、收益率时，必须引用材料原文并标注出处。
EOF

ollama create fin-assist -f Modelfile
ollama run fin-assist

这里几个参数是关键。temperature设0.2是为了让输出贴近材料原文，金融问答宁可保守也不要发散；num_ctx开到8192，是为了让模型能一次性读完一篇完整的产品说明摘要；SYSTEM指令里明确写了「不得编造数据」，这比任何后处理规则都先堵住幻觉入口。启动后可以用一条 curl 验证服务是否就绪：

curl http://localhost:11434/api/generate \
  -d '{"model": "fin-assist", "prompt": "什么是七日年化收益率？", "stream": false}'

这一步跑通后，你就有了一个可控的本地推理基座，后续的RAG和Agent都是在这个接口之上加逻辑。

3.2 把尽调报告和监管公告变成可检索知识库

本地模型只解决「会说话」，金融业务还要求「有依据」。常见做法是用向量库把文档切片编码，查询时先检索再交给模型生成。最小实现不需要上重型框架，一个embedding模型加Faiss就够了：

from sentence_transformers import SentenceTransformer
from faiss import IndexFlatIP
import numpy as np

model = SentenceTransformer("BAAI/bge-large-zh-v1.5")

docs = [
    "该产品为固定收益类，业绩比较基准为3.2%，不保本。",
    "投资者可在开放日申请赎回，赎回到账时间为T+1。",
    "本基金投资于债券资产的比例不低于80%。",
]

# 归一化后使用内积等价于余弦相似度
vectors = model.encode(docs, normalize_embeddings=True)
index = IndexFlatIP(vectors.shape[1])
index.add(np.asarray(vectors).astype("float32"))

def search(query, top_k=2):
    q_vec = model.encode([query], normalize_embeddings=True)
    scores, ids = index.search(np.asarray(q_vec).astype("float32"), top_k)
    return [(docs[i], round(float(scores[0][j]), 4)) for j, i in enumerate(ids[0])]

print(search("赎回需要多久到账"))

这段代码的逻辑是：先把文档变成向量建索引，查询时把问题向量化后在索引里做相似度检索。 normalize_embeddings=True 这行不能省，它把向量归一化后，Faiss的内积计算结果就是余弦相似度，阈值才有跨库可比性。实际生产里要把docs换成数据库里读过切片的内容，并额外存一份chunk_id到原文的映射，用于最后给模型引用。

3.3 用AI Agent编排合规审阅的调用链

报告里2025年明显加强的一个词是「AI Agent」，在金融里的典型形态是一个合规审阅Agent：收到一份入网材料后，自动解析PDF、抽取出关键字段、调用黑名单接口比对、汇总风险点、生成审阅意见。没有Agent时这些步骤靠人工复制粘贴，有了Agent之后就是一条服务链。核心编排逻辑并不神秘，就是「循环-工具-记忆」三个要素：

tools = {
    "extract_entities": extract_entities,      # 抽取公司名、股东、受益人
    "check_watchlist": check_watchlist,        # 调黑名单接口
    "score_policy": score_policy,              # 打分卡规则引擎
}

def run_agent(task, memory={}):
    plan = ["extract_entities", "check_watchlist", "score_policy"]
    for step in plan:
        result = tools[step](task, memory)
        memory[step] = result
        if step == "check_watchlist" and result["hit"]:
            return {"decision": "reject", "reason": result["match"]}
    return {"decision": "review", "reason": memory}

这个循环看起来简单，但它是Agent能稳定工作的原因：每一步的输出都写进memory，下一步可以读取，逻辑是显式的，出问题能定位是哪一个环节。关键参数是 memory 的字段结构，建议固定成JSON schema，后面接审计日志和可视化时能省很多事。金融Agent不需要多聪明，需要的是可解释、可回放、可中止。

4. 金融AI测试与上线排错：评估集、指标和三个常踩的坑

4.1 评估集怎么建：标注规范与指标表

金融AI上线前最大的阻力不是模型效果，而是「你说它好，怎么证明」。我从做风控项目的经验里总结了一套评估集搭建方法：从线上日志里抽真实问题，脱敏后人工写参考答案，按业务模块分层。每类场景至少50条，覆盖正常问题、边界问题、冲突材料三类。指标不能只看准确率，要配合下面这套表：

指标	计算方式	金融场景目标
准确率	标准答案完全匹配占比	高于85%
关键要素命中率	答案是否含金额/日期/条款关键点	高于90%
幻觉率	模型输出未在材料中出现的断言	低于3%
拒答率	无依据时主动拒绝回答的占比	高于70%
平均延迟	请求到完整响应的秒数	低于3秒

4.2 用pytest写一个可回归的冒烟测试

评估集建好后，一定要落成自动化测试。pytest在这个场景里比专门的评测框架更友好，因为可以无缝对接CI，每次换模型参数都能跑一遍回归。金融场景里「回答必须带关键实体」是个硬约束，把它写成断言：

import pytest
from app.rag import build_chain

CASES = [
    ("该产品业绩比较基准是多少", ["3.2%"]),
    ("赎回什么时候到账", ["T+1"]),
]

@pytest.mark.parametrize("question,expected_terms", CASES)
def test_answer_contains_terms(question, expected_terms):
    chain = build_chain()
    answer = chain.query(question)
    for term in expected_terms:
        assert term in answer, f"答案缺少关键实体: {term}"

parametrize 的作用是把测试用例表和测试逻辑分离，新增用例只改列表不加代码。注意断言只查关键实体，不查完整句子，因为生成式模型的表达本来就不固定，查实体能避免「意思对了字不一样」的误杀。跑一次这条用例集，模型换版本、温度系数改动、知识库重建后是否引入回归，一目了然。

4.3 三个常踩的坑：数值幻觉、长文本截断、金额格式

第一个坑是数值幻觉。模型在转换单位时最容易出错，比如把「亿元」读成「万元」，或者把年份和数值拼接错。这种问题靠评测集抓不完，要在生成链路里加一层数值校验器，把答案里的数字和检索原文的数字比对，不一致就重生成。

第二个坑是上下文窗口。报告和产品条款经常超过模型窗口，切片策略如果按固定字符数切，很容易把一条完整条款切成两半，导致检索命中但内容残缺。常见做法是优先按标题和段落边界切，并让切片之间保留少量重叠，重叠量设50到100个字符即可。

第三个坑是金额和日期的格式不统一。同一篇材料里「3.20%」和「3.2%」可能同时出现，评测时直接做字符串比对会误报。建议在数据清洗阶段统一数字格式，把百分比、千分位、货币单位都归一化后再入库和再比对，这一步能砍掉大量假阳性问题。

5. 2025趋势里的三个进阶方向与验证方法

报告标题里的「趋势」部分，大多数内容可以归结为三个方向，而且每个方向都有可以在本周内动手验证的办法。

第一个方向是从单轮问答走向多步Agent编排。2024年的落地案例大多是一个问题配一次检索配一次生成，2025年的样本会明显转向「一单业务一次完整作业流」。验证方法是选一个现有的人工流程，拆出步骤编号，数一数哪些步骤调了外部系统，这些就是Agent的候选工具点。不需要一步到位，先把其中两步串起来跑通就是有效进展。

第二个方向是多模态进入单据识别和双录质检。材料里的合同扫描件，不再只走OCR后进文本模型，而是直接把图像送进多模态模型理解版面。想低成本验证，把十张不同版式的合同首页和它们的JSON化结果喂给一个开源多模态模型，对比字段抽取的准确率，重点看盖章遮挡和手写批注区域，这部分是传统OCR方案的痛点。

第三个方向是评测自动化，也就是把趋势报告里的能力指标转成你自己系统的持续监控。我现在会在每次线上请求后把问题和回答以JSONL格式落盘，然后跑一个定时任务做三类检查：回答是否为空、是否包含检索引用、是否触发拒答策略。命令很简单：

jq -r 'select(.refused == true) | .question' ./logs/answers_$(date +%F).jsonl | wc -l

这条命令把当天所有拒答的问题统计出来。拒答率不是越高越好，如果持续高于10%，说明知识库覆盖不足；如果突然降为零，反而要警惕模型开始编造。把这三个方向分别设成三个可量化的小实验，一周一个，2025年的预算和排期才真正有着落。

本文还有配套的精品资源，点击获取