简介PPT围绕2024年大模型技术及其在金融行业的应用探索面向金融科技从业者、企业数字化转型规划人员及AI应用研究者。内容系统梳理了ChatGPT带来的技术与范式变革、大模型从逐层无监督预训练、Word2Vec、GAN、Transformer到超大规模多模态的发展历程并解读《新一代人工智能发展规划》《生成式人工智能服务管理暂行办法》等国家级政策及北京、上海等地支持措施同时说明大模型数十亿至数千亿参数、强泛化与多模态理解等特点。金融落地上重点介绍了智能问答、知识检索、数据分析、研报撰写、投研问答、合规助手、智能尽调报告生成、代码助手等场景还涉及五种快速构建大模型商业应用的方法、利用企业数据构建领域知识平台、训练与微调必要性、Agent模式构建以及高质量语料知识管理。压缩包包含1个pptx演示文稿共23.25MB结构完整。目前已有159人学习适合希望短时间内建立大模型金融应用全景认知的读者参考。1. 金融行业为什么先拥抱大模型从信息密度看技术选型金融行业每天处理的研报、公告、合同、监管问答和客服记录都是以文本为主的高密度信息流且大多有明确的格式和答案边界。大模型擅长的恰恰是“在长文本里找答案、归纳要点、按模板生成”所以这个领域比制造业、零售业更早出现可量化的落地场景。真正让金融项目卡壳的从来不是模型效果而是数据合规、结果可追溯和旧系统对接这三个工程问题。对从业者来说把“大模型技术及其在金融行业的应用探索”做成方案实际上是在做一次选型决策要么接通用 API 快速验证要么走 RAG 搭建私有知识问答要么上微调和私有化部署。下面按这条决策链往下走路线选择、最小可运行原型、评测方法和落地避坑适合正在做金融 AI 方案构思、预算申报或 POC 的算法、架构和数据同学直接参考。2. 把“大模型 金融”拆成四条技术路线API、RAG、微调与私有化部署怎么选在金融场景里大模型不是一个模型而是一组形态差异很大的技术选项。常见做法是先按“数据能不能出域”和“需要多强的定制能力”两条轴来分类能出域、快速验证用 API不能出域、知识更新快用 RAG需要稳定学习内部术语和写作风格再考虑微调连 GPU 资源都要自管则落到私有化部署。四个象限不是互斥关系实际项目通常是“RAG 微调 私有化”组合但起步一定从最轻的路径开始。2.1 公开 API 起步用最小 prompt 验证场景是否成立我一般建议先花一周时间把 20~50 条真实样本跑一遍通用大模型 API验证“这个场景的答案是否存在、是否稳定”。这一步的成本最低也最能提前暴露数据合规问题。下面是一个很典型的验证脚本骨架用 Python 直接调 OpenAI 兼容接口完成“抽取信贷文书中的关键要素”这类任务。import requests import json def extract_by_prompt(text, api_url, api_key, model): # 用 system prompt 限定角色和输出边界减少自由发挥 system_prompt ( 你是银行信贷审核助手。只能从给定材料中抽取字段 不要推理、不要补全。输出 JSON字段名固定为 客户名称, 贷款金额, 利率, 担保方式, 到期日。 ) payload { model: model, temperature: 0.1, # 抽取类任务压低随机性 max_tokens: 512, messages: [ {role: system, content: system_prompt}, {role: user, content: f材料内容\n{text[:3000]}} ] } headers {Authorization: fBearer {api_key}} resp requests.post(f{api_url}/chat/completions, jsonpayload, headersheaders, timeout60) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content) # 项目初期不追求容错先看结果形状这段代码的逻辑很直接system prompt 定义角色和输出协议temperature 压到 0.1 避免随机max_tokens 限制单个回答长度输入先截到 3000 字以内防止超限。参数说明上我建议在字段抽取类任务里把 temperature 固定为 0~0.2如果做研报摘要可以放宽到 0.6 左右但金融材料宁可保守。如果这一层验证出来的答案让业务方点头再花人力做后面的 RAG 和微调如果连通用模型都答不对先怀疑任务定义本身而不是急着换更大的模型。2.2 RAG 是金融落地的中坚为什么先做检索增强金融数据的显著特点是更新快、来源多、答案必须能找到出处。RAG 的核心是把“模型记住知识”改成“模型按需查知识库再回答”这对金融行业几乎是天然的契合机构内部的信贷制度、监管问答、产品说明书本来就是一批需要频繁更新的文档。把文档切块后向量化入库用户提问时先检索相关片段再把片段和问题一起交给模型生成答案可以同时缓解三个老问题——幻觉、知识过期、无法引用来源。常见做法是同时启用关键词检索和向量检索做混合召回因为金融术语缩写多纯向量检索容易把“LPR”和“贷款市场报价利率”的语义匹配做偏。如果团队不想从零搭这套链路常见做法是先用 Dify、FastGPT 或 RagFlow 这类开源编排平台把知识库和问答界面串起来验证通过后再迁移到内部生产组件。这个阶段不要过度纠结向量数据库选型Chroma、Milvus 或 Elasticsearch 都能跑通 POC关键是先把“检索片段准不准”这个核心问题暴露出来。2.3 什么时候才值得微调金融指令数据与参数改动如果业务要求模型“学会内部措辞”比如把“逾期 90 天以上”统一写成“不良”或者要模型严格仿照某类监管报告的句式RAG 改 prompt 解决不了这时候才轮到微调。金融微调最常见的是指令微调SFT数据量不需要很大质量优先整理 300~500 条“输入-期望输出”的问答对往往就能让模型在特定格式上稳定下来。数据格式一般是 JSONL一个更具体的例子如下。{instruction: 根据以下贷款申请信息生成初审意见。, input: 客户A注册资本500万申请流动资金贷款2000万抵押物为厂房评估值1600万近一年营收3000万。, output: 初审建议抵押物覆盖率80%低于本行85%准入线建议补充担保或压降额度至1700万。} {instruction: 解释什么是穿透式监管。, input: , output: 穿透式监管是指识别资管产品最终投资者与底层资产确保风险计提和投资者适当性管理落到实际承担风险的主体。}训练时需要注意的参数包括LoRA 的秩金融文本我用 r8 起步、学习率1e-4 到 2e-4 范围、训练轮数1~3 轮防止把意图记忆死。微调不是万能的它改变的是表达能力和知识边界内的稳定性改不了模型不知道的事实所以微调之后依旧要接检索。实际操作中我习惯把“微调前后各跑 100 条评测集”作为验收门槛否则很难判断训练到底改善了哪一类错误。2.4 私有化部署的边界GPU 规模、并发与投产成本当数据不能出域或者机构要求“模型必须部署在自有基础设施上”时就进入私有化部署。常见方案是拿开源权重如 Qwen、Llama、DeepSeek 系列在本地 GPU 上跑推理再用 vLLM、Ollama 这类推理框架对外提供接口。预算评估最容易翻车的地方是把“模型参数量”当作唯一指标实际上真正决定硬件的是并发和响应时间。下面这张表是我在做资源估算时常用的粗算口径。方案参数量级单卡推理显存int8 量化建议服务方式适合并发轻量助手7B 级约 8~12GB单卡 批处理个位数 QPS主力问答14B 级约 16~24GB双卡 vLLM 连续批处理十级 QPS复杂生成/微调底座70B 级约 48~80GB多卡并行并发低、任务重表格里的数字是按常见开源模型的 int8 量化经验估算的具体以你手上模型的实测为准。我的经验是先用 20 并发压测真实请求看 TP99再决定买几台机器一味堆 70B 大模型很容易让预算翻倍而金融问答里大部分请求其实用 14B 级模型加好的检索就够了。选什么参数量级的模型才算“够用”标准不是参数大小而是评测集上的通过率。3. 金融文档问答的最小实现文档切片、向量检索与引用生成金融领域最常见的第一个 POC 是“内部制度文档问答”把几十份 PDF/Word 制度文件放进一个问答系统员工用自然语言问“对公客户授信额度审批需要哪些材料”系统给出答案并标明出处。这个 POC 的完整链路包括文档解析、切片、向量化、入库、检索、生成和引用展示下面按落地顺序拆开讲。3.1 文档解析与切片切得不好检索效果差一半第一步是解析文档。制度文件多为 PDF 和 WordPDF 里又有扫描件和电子版之分扫描件要先做 OCR电子版直接用解析库提取文本。我一般先把所有文档统一转成纯文本再做清洗去掉页眉页脚、目录和重复空白。切片是一个容易被低估的环节切得太大导致检索命中后上下文混杂无关内容切得太小又让跨段信息断裂。常见做法是按“标题层级 段落 字符数”混合切片先按标题拆出章节再对过长章节按固定长度切。import re def split_document(text, chunk_size512, overlap64): # 按 Markdown 标题先拆大块章节信息在后续引用展示里要用 units re.split(r(?m)^#{1,3} .*$, text) chunks [] for unit in units: if len(unit) chunk_size: chunks.append(unit.strip()) continue start 0 while start len(unit): end min(start chunk_size, len(unit)) if end len(unit): # 在句子或换行边界断开避免从词中间截断 end max(unit.rfind(。, start, end), unit.rfind(\n, start, end)) 1 if end start chunk_size // 2: end start chunk_size chunks.append(unit[start:end].strip()) start max(end - overlap, start 1) return chunks这段代码做两件事先把文档按标题切成大块再对超长块做定长切片。参数上chunk_size512 和 overlap64 是起步值不是最优值。金融制度文档建议 chunk_size 取 300~600 之间overlap 取 10%~15%如果文档是合同这种条款式结构可以再小一点到 200~300保证单条条款不被切开。切片后要额外存一个 metadata 字段记录来源文件名和章节标题这一步在未来做来源引用时逃不掉。3.2 向量入库与检索参数top_k、相似度阈值与混合召回切片完成后把每块文本用 Embedding 模型转成向量写入向量库。金融场景我建议选择中文效果稳定的向量模型并单独用一批行业术语做召回测试而不是只看公开 benchmark。入库代码的骨架大致如下。from openai import OpenAI import chromadb client OpenAI(base_urlhttp://localhost:8000/v1, api_keylocal) # 本地推理服务的 OpenAI 兼容端口 def embed_texts(texts): resp client.embeddings.create(modelbge-large-zh, inputtexts) return [item.embedding for item in resp.data] # 建立集合并写入切片 collection chromadb.Client().get_or_create_collection(fin_regulation) collection.add( ids[fchunk_{i} for i in range(len(chunks))], documentschunks, metadatas[{source: 授信管理制度.pdf, section: 第四章} for _ in chunks], embeddingsembed_texts(chunks) ) def retrieve(query, top_k8, threshold0.5): res collection.query(query_texts[query], n_resultstop_k) return [(doc, meta, dist) for doc, meta, dist in zip(res[documents][0], res[metadatas][0], res[distances][0])]检索参数里最值得调的是 top_k 和相似度阈值。top_k 默认 8 在知识库小于几千块时够用但如果制度库有几十万块建议先做粗召回取 20~30 条再用重排序模型精排到 8 条。相似度阈值是防幻觉的第一道闸门距离超过阈值的检索结果直接丢弃宁可回答“找不到材料”也不要让模型硬编。金融行业对拒答的容忍度远高于对编造的容忍度这一点一定要在系统设计里提前约定。3.3 提示词模板与来源引用把“生成自由度”关进笼子检索完成之后进入生成环节。金融问答的 prompt 和通用聊天大不一样核心是给模型画圈只能基于给定片段回答、禁止推理补全、必须带引用编号。我常用的模板如下。def build_prompt(question, retrieved_chunks): context \n\n.join( f[{i1}] 来源{meta[source]} {meta[section]}\n{doc} for i, (doc, meta, _) in enumerate(retrieved_chunks) ) return [ {role: system, content: ( 你是金融机构的合规问答助手。回答只能基于用户消息里标记为[来源]的文本 禁止使用外部知识补全如果检索材料不足以回答问题回复“未在现有制度中找到依据”。 每条结论末尾标注对应来源编号例如来源1。 )}, {role: user, content: f问题{question}\n\n检索材料\n{context}} ]这段模板的关键参数是“来源编号必须出现在答案末尾”。这个设计让审计人员可以逐条回溯答案是金融项目上线前必须满足的硬要求。另一个容易遗漏的点是给模型一个明确的“找不到”话术而不是让它自由发挥。实践里很多模型在检索材料矛盾时倾向于各打五十大板金融场景这时候应该回退到“依据不足请咨询业务部门”避免给出模糊结论。4. 金融场景的模型评测与迭代用 100 条真实提问验收质量金融行业做大模型项目最容易出现的流程缺陷是模型还没评就急着调调完又说不清变好了哪里。评测集是让项目从“演示好看”走向“投产可用”的尺子没有评测集后面所有 prompt 调优和微调都变成黑匣子。我对待评测的态度是宁可花一周时间整理 100 条真实问题也不要只拿 10 条演示问题反复自测。4.1 建立评测集三个靠谱的问题来源评测问题必须贴近真实使用场景而不是开发人员自己编的通用问题。常见做法是从三个渠道收集一是客服和业务系统的历史提问记录这是最真实的用户表达二是业务方在需求评审里列出的典型问题清单三是从制度文档本身反推的必考问题比如“对公客户准入有哪些红线”。每条问题要配一个“黄金答案”和“采分点”采分点由业务专家提前写好至少包含两个可核验的事实要素。如果人手不够可以先用业务方的标准答复当作答案基线。4.2 打分维度与基线正确性、引用、拒答率分开记评测指标不要只算一个“通过率”至少拆成四个维度来记答案正确性是否包含黄金答案的采分点、引用可溯性每个结论是否能对应到检索片段、格式规范性是否按业务要求的字段输出、越权回答率无关问题是否被拒答。下面给一个简单的评测脚本骨架用来把大模型输出和黄金答案逐条对照。import json def evaluate_item(item, model_answer): # 打分规则采分点命中 引用存在 拒答准确 golden_points item[golden_points] hit sum(1 for p in golden_points if p in model_answer) point_score hit / len(golden_points) has_citation 来源 in model_answer or (来源 in model_answer refuse_ok (item[expect_refuse] and 未找到依据 in model_answer) or \ (not item[expect_refuse] and 未找到依据 not in model_answer) return { point_score: point_score, has_citation: has_citation, refuse_ok: refuse_ok } with open(fin_eval_set.jsonl, encodingutf-8) as f: for line in f: item json.loads(line) # call_model 与 retrieve 是项目里已有的函数这里只演示评测逻辑 answer call_model(item[question], retrieve(item[question])) print(item[id], evaluate_item(item, answer))打分脚本本身很简单真正的功夫在评测集标注。采分点不能写得像模型输出一样长尽量落到“数字、日期、条件、排除项”这类可机械核对的要素。另外拒答准确性要单独算因为金融场景宁可漏答不可错答如果一个模型在 100 条里对了 95 条但把 5 条高风险问题编了答案它仍然不能上线。4.3 迭代顺序先调检索再调生成最后才上微调拿到评测结果后优化顺序有讲究。我见过太多团队一上来就改 prompt改到第 20 版发现效果提升很小原因其实是检索阶段就没有把正确材料找出来。正确的顺序是先用 20 条问题检查召回结果看正确片段是否在 top_k 里召回不到位先调切片大小、embedding 模型和混合检索权重召回到位但答案不对再改 promptprompt 稳定后仍有格式问题才考虑微调。大模型上下文长度也是一个常被忽略的因素如果检索出的 8 段材料加问题超出模型上下文不要盲目截断应该减少 top_k 或对段落做压缩摘要而不是删掉尾部材料因为被删的可能恰是答案所在。5. 金融大模型落地避坑指南数据合规、上下文窗口与旧系统对接的排查记录这一章是血泪经验汇总。金融项目跑 POC 时模型往往表现不错一进联调和试运行就四处冒烟。下面列的五类问题是我在实际项目实施里反复遇到的按“现象 → 原因 → 解决”写清楚可以直接对照排查。5.1 数据出域被合规卡死项目在验证阶段就停摆现象是 API 验证效果很好业务也认可但数据合规评审一票否决理由是客户信息不能直接送第三方模型服务。原因是通用 API 的数据留存策略无法满足金融机构的客户隐私与跨境管理要求。解决办法是提前把数据分级公开信息如央行公告、政策文件可以走 API客户信息、交易数据、内部制度一律假设不能出域涉及客户数据的场景直接走私有化部署或专有云并把脱敏管线前置到数据入库前而不是在 prompt 里做字符串打码。提示在项目立项时就把“数据能不能出域”写进方案的一页纸能省掉后续大量返工。5.2 上下文窗口用完了把尾部材料截断答案缺关键条款现象是当问题涉及多份制度交叉时模型回答经常缺最后一条该引用的条款且引用编号对不上。原因是 prompt 组装时把“超出上下文长度”的尾部直接截断了但答案位置正好在那段被删的材料里。解决办法是改用“检索结果压缩”先按相关度精排到 5 段以内再对每段做保留关键句的压缩最后拼进 prompt如果还不够就换更长上下文的模型。不要舍不得丢弃低相关片段多塞不等于答得更准。5.3 检索阈值设得太松没找到材料也硬答现象是知识库里明明没有某产品的费率规则系统还是给出一个编造的数字。原因是相似度阈值设成 0 或者没有阈值检索结果无论多远都送进生成环节。解决办法是给检索加一道硬路由只保留超过阈值的片段当所有片段都低于阈值时直接返回“未在已上传制度中找到依据”并触发人工补录流程。阈值具体多少要以评测集为准我常用 0.4 起步然后看“漏检率”和“错检率”两个指标去做折中。5.4 评测集偷懒迭代像是玄学现象是每次改完 prompt开发说效果好了业务说没感觉。原因是评测只有十几条演示问题且没有标定黄金答案模型偶发性答对一次就被人当成了提升。解决办法是固定评测集版本、固定打分脚本每次变更前后各跑一遍把四个维度的分数差距打印出来建议把评测集纳入 Git 管理prompt 和评测结果一起走版本记录。这样每一次改动到底是变好还是变坏都有据可查而不是靠印象拍脑袋。5.5 按显存买机器上线后被并发打爆现象是几台机器跑 70B 模型内部演示很流畅20 个人同时用就开始排队超时。原因是估算只看模型显存占用量没看推理吞吐和批处理能力。解决办法是用 vLLM 这类带连续批处理的推理框架做一次 20 并发压测记录 TP99 延迟和令牌吞吐如果并发要求高优先降模型规模加量化其次才是堆卡。另一个常见做法是给前后端中间加一个排队与限流层把“瞬时超时”转成“排队提示”对内部员工体验更友好。6. 从 POC 到生产最后一步把监控、审计与回滚做成默认配置POC 演示通过之后真正的工程工作才开始。金融生产环境对系统的要求不是“聪明”而是“可审计、可回滚、可追踪”。6.1 上线前必须补上的四类设施第一是全量日志每一次问答都要记录用户、问题、检索片段、模型输出、耗时分和版本号日志保留周期按机构要求定这笔存储不能省。第二是 prompt 和模型版本管理prompt 不能直接写在业务代码里要放到配置中心每次修改留一个版本号方便出问题时快速精确回滚。第三是权限隔离知识库的可见范围要按岗位控制信贷审查看不到理财销售的话术库避免跨部门信息泄露。第四是监控面板除了常规的响应时间还要盯“无依据回答率”和“拒答率”两个业务指标一旦异常快速告警。6.2 灰度切换与人工复核换系统也要有后悔药上线节奏建议采用双轨灰度新系统先和旧流程并行两周按 5%~20% 流量逐步放量每一单都保留人工复核环节。业务人员看到的是“AI 预答 人工确认”确认数据通过反馈接口回流到评测集成为下一轮优化的素材。这样的设计让系统在任何时刻都可以回退到纯人工模式团队不会因为一次坏案例而陷入被动。我自己的习惯是把“能不能回滚”当作比“效果多两个点”更优先的决策依据。金融系统出一次错代价不只是算力损耗用户信任一旦受影响再好的模型也很难挽回。希望这篇文章里的路线拆解和踩坑记录能帮你少走一段弯路让你在推进大模型金融应用的时候能把更多精力放在真正有价值的业务问题上而不是被工程细节反复绊倒。本文还有配套的精品资源点击获取