简介这份演示文稿以2024年大模型技术演进为线索系统梳理发展背景、核心特点与产业政策并聚焦金融行业落地探索。资源面向金融科技从业者、AI产品经理及技术决策者帮助读者快速理解从技术原理到业务应用的完整路径。包体为单个pptx文件大小约23.25MB已有159人浏览学习适合作为内部培训或专题分享演示底稿。内容涵盖ChatGPT带来的范式变革、Transformer等关键节点、模型泛化与多模态能力以及各级支持政策要点重点展示金融场景中的智能问答、研报撰写、投研问答、合规助手、智能数据分析、尽调报告生成和代码助手等实践并讨论模型训练与微调、AI代理模式和高质量语料构建。整体兼顾宏观趋势与具体用例可作为金融行业智能化转型的入门参考。1. 大模型技术落地金融不是换个聊天机器人而是换一套生产力2024年再做金融行业的大模型项目技术本身已经不再是最大的门槛真正难的是怎么把一个千亿参数的通用底座变成能过合规审核、能在信贷和投研场景里真正干活的生产工具。这份《2024大模型技术及其在金融行业的应用探索》PPT的价值在于它把这件事拆成了两条线一条是技术演进与产业政策的宏观脉络另一条是从普通LLM到预训练的五层应用构建方法论并且给出了授信可行性报告、投研问答、合规助手这类具体场景的拆解路径。对于正在做金融科技、企业AI中台、数据平台建设或者刚被领导安排去研究大模型落地的人来说这份材料的参考价值在于它告诉你金融场景下大模型能力边界在哪、哪个层级够用、什么时候需要微调甚至重新预训练。2. 技术演进与政策土壤从逐层预训练到千亿参数金融凭什么敢上第一线2.1 大模型的“大”具体指什么参数、数据与算力只是表层大模型通常包含数十亿甚至数千亿个参数这些参数在训练过程中被调整以最小化损失函数。为了训练这些模型需要海量的文本、图像、音频数据用于让模型识别模式并做出预测。由于模型规模和数据量之大大模型通常需要高性能GPU集群、大量内存和存储空间。但参数规模只是表象金融从业者真正关心的应该是它带来的四种能力强大的泛化能力意味着模型在未见过的数据上也能表现良好多模态理解能力让它能同时处理文本、图像、视频等输入迁移学习能力让模型可以在一个任务上预训练然后在其他相关任务上微调而上下文学习能力则让它能根据对话历史理解和生成连贯回应。这些能力映射到金融场景是很有价值的。泛化能力意味着同一个底座可以复用在研报撰写、合规审查、客服问答等多个业务线不需要每个场景单独训练一个模型迁移学习意味着一个中型团队也能基于开源底座用少量业务标注数据做行业适配多模态能力则直接对应财报PDF、合同扫描件、K线截图这类真实资产。所以金融行业说“大模型技术”的时候本质上是在说一套可以复用的能力底座而不是某个具体的聊天机器人产品。2.2 从Word2Vec到GPT-4大模型发展脉络中的关键转折点大模型的发展脉络看起来是线性的但真正值得记住的节点其实很集中。2006年Hinton提出逐层无监督预训练方式解决了深度模型梯度消失的问题这算是最早的预训练思想雏形。2013年Word2Vec让词向量成为标准操作词与词之间的语义关系第一次可以数学化表达。2014年GAN的出现是生成模型的里程碑。2017年Google提出Transformer架构这个自注意力机制真正开创了NLP的新纪元后续的BERT、GPT系列全都是它的变体。2018年预训练加微调范式成型模型先在通用语料上预训练再在具体任务上微调成为此后多年的标准路线。2020年GPT-3参数规模达到1750亿算力需求开始变得“恐怖”。2022年ChatGPT发布引发全社会关注2023年则进入超大规模多模态预训练时代。年份事件对金融行业的意义2006逐层无监督预训练深度学习可行性验证2013Word2Vec词向量语义检索技术基础2017Transformer架构长文本处理能力起点2020GPT-31750亿参数大规模语言模型能力跃升2022ChatGPT发布对话式交互范式确立2023多模态预训练大模型财报图表类数据可处理2.3 政策端与需求端的双向推力为什么金融行业能踩中这波红利政策端在推动大模型应用方面给出了一套明确的顶层设计。2017年《新一代人工智能发展规划》是最早的国家级纲领而后续的《生成式人工智能服务管理暂行办法》则划定了监管红线这对金融行业其实是一种利好因为金融机构最怕的不是技术落后而是合规风险不确定。更值得关注的是“数据要素×”三年行动计划2024-2026年明确提出支持通用大模型和垂直领域大模型训练这等于给了金融行业一个明确的信号行业大模型是被鼓励的方向。地方层面的政策更细比如北京市明确到2025年底形成3到5个基础大模型产品、100个行业大模型产品这些目标数字会直接转化为金融企业的立项预算。需求端的数据同样是实打实的。SAS与Coleman Parkes的调研显示中国企业在“已部署生成式AI但尚未完全覆盖整合”维度上占比64%总应用比例83%位居全球第一。IDC的调研则指出知识管理场景是当前企业端最受青睐的AIGC应用场景全球市场和中国市场受访企业的期待应用比例分别为52%和52.2%。知识管理恰恰是金融行业最重资产的部分——研报、尽调报告、合规制度、历史项目档案这些都是天然的检索增强场景。政策给了绿灯需求端给了场景供给端模型能力又恰好到了可用的临界点金融行业的大模型落地就这样被推到了前台。3. 五种方法构建大模型商业应用从提示工程到预训练的选型坐标3.1 Level 1与Level 2通用LLM直接问答与提示词工程CoTPPT里把大模型商业应用划分成了五个递进层级从L1到L5分别对应“常人”到“大师”的能力水平。L1是直接部署通用LLM提供基础问答这时候模型回答依赖的是它预训练阶段学习到的通用知识没有企业数据注入。L1适合的场景非常有限比如员工规章制度答疑、技术文档初步检索因为问题一旦涉及到企业内部数据和金融领域专有名词通用模型就会开始一本正经地胡说八道。从实际项目角度看L1基本只适合做验证和演示不太能直接进入生产链路。L2开始引入提示词工程也就是通过精心构造Prompt让LLM扮演特定角色、按照特定思维链回答。很多人觉得提示词工程不就是写几句话的事实际上在金融场景里Prompt的结构化程度直接决定输出质量的稳定性。下面是一个典型的金融投研场景Prompt模板【角色设定】假设你是一位金融投研领域的专家拥有10年行业研究经验。 【任务背景】请从产业链上下游的角度分析该公司的市场竞争格局。 【约束条件】 1. 只基于给定的事实信息作答不编造数据 2. 回答结构产业定位 - 上游议价能力 - 下游需求 - 风险点 3. 涉及数据时标注来源 【输出格式】Markdown结构化输出每个结论附简短依据这里的核心逻辑是通过角色设定把模型的输出空间约束到金融专家的轨道上通过约束条件明确回答边界通过输出格式让结果可以直接进入下游报告流程。金融行业用提示词工程有一个很重要的习惯就是明确要求模型“不编造数据”并在输出中标注依据这样至少在形式上为后续的合规审查留了窗口。提示词工程虽然成本最低但它的问题也很明显模型的能力上限没有变化只是输出的组织方式变好了如果业务问题本身超出了模型的内部知识范围Prompt写得再精致也没用。3.2 Level 3RAG与Agent把企业知识注入大模型的关键一跃从L3开始方案才真正触及金融行业大模型落地的核心把企业自身数据接入模型推理链路。RAG检索增强生成的流程是把企业文档预先切分成Chunk经过Embedding模型向量化后存入向量数据库用户提问时将问题同样做Embedding在向量库中执行相似度检索召回Top-K相关内容然后把这些内容拼进Prompt交给大模型生成回答。同时Agent机制的引入让模型可以自主选择工具例如查询实时行情、调用数据库接口、获取外部研报。这套机制对金融行业的意义在于它第一次把“模型能力”和“企业知识”解耦了。信贷部门的授信档案、投研部门的行业报告、合规部门的制度文件都能通过RAG注入到问答链路中而不需要对模型本身做任何改动。在实际落地中向量化参数直接决定召回质量下面是一份我常用的参数配置参考参数项常见配置说明切分粒度 chunk_size300-500 tokens金融文档宜偏小减少跨主题污染切分重叠 overlap50 tokens避免句子被截断在边界Embedding模型通用文本向量模型或金融微调向量模型后者对财报术语更友好召回条数 TopK5-8过多会稀释上下文注意力相似度阈值0.6-0.8低于阈值宁可拒绝回答重排序 Rerank建议开启用交叉编码器精排召回结果这里有一个经常被忽略的细节切分粒度和Embedding模型要一起调。金融文档里大量存在“资产负债表、现金流量表、利润表”这类术语密集的内容如果切分过大会让一个Chunk里混入多个主题检索时召回的是一堆相关但无法精准回答的内容切分过小又会丢失上下文语境。我一般会在车型到300到500字符之间做几组对比用召回内容的准确率人工抽检来确定最佳参数而不是凭感觉写死一个数。3.3 Level 4与Level 5有监督微调与继续预训练的成本与边界L4是有监督微调SFT做法是准备一批“问题-标准答案”或“指令-响应”对在开源底座模型上做指令微调让模型学会金融术语、报告体例、合规话术。SFT和RAG最大的区别在于前者改变的是模型的“行为风格”和“表达习惯”后者改变的是模型的“知识来源”。如果业务场景要求模型输出的语气、结构和用词都要符合特定报告规范那就需要SFT如果只是知识不够优先用RAG补知识不要动微调。微调的参数设置上我一般用LoRA低秩适配rank值在8到64之间训练轮数控制在1到3轮学习率在1e-4到5e-5之间。数据集规模不需要很多几百到几千条高质量指令对就可以起步重点是数据质量而不是数量。L5继续预训练则是在通用底座上用大规模金融语料库对模型全部参数做进一步训练。这个层级的成本量级已经完全不同了需要高性能GPU集群、数十亿token的行业语料训练周期以周甚至月为单位。PPT里的分层逻辑很清楚L1是普通人L2是胜任者L3是专家L4是大师L5是领域宗师。金融行业的绝大多数业务场景到L3加L4就已经够用了继续预训练只有在需要掌握极其深度的行业知识、并且有强大算力支持的头部机构才会考虑。3.4 五层方法对比给具体金融场景选层级层级技术手段成本量级适用场景风险等级L1通用LLM直接问答极低员工制度答疑、泛知识检索高不可控L2提示词工程CoT低投研初筛、报告框架生成中L3RAG Agent中知识问答、尽调辅助、信审辅助低L4有监督微调LoRA/SFT中高研报生成、合规文本改写低需数据合规L5继续预训练极高行业级深度知识底座低但成本极高选自层级的判断标准其实很简单先问业务卡点在哪里。如果模型输出答非所问先排查是不是提示词没约束住如果知识不够优先做RAG如果RAG召回的内容够、但输出风格和规范不对再考虑SFT只有当前面所有手段都试过、仍然需要模型具备大量隐性行业知识时才去谈继续预训练。这个顺序反过来做大概率会踩进成本黑洞。4. 金融场景怎么拆授信报告、投研问答与合规助手的落地路径4.1 授信可行性报告场景拆解一类业务的数据与模型分工PPT里举的例子非常典型用大模型帮助信贷部门业务人员撰写《授信项目可行性报告》这份报告的原有人工撰写流程是针对申请授信的单一客户做详细调查涉及内部数据、外采数据、互联网数据以及远程和现场调研数据报告模板共计十七页。这个场景的复杂度在于数据来源的异构性极强信贷系统里的财务数据、外部采购的征信数据、互联网上的公开舆情、线下尽调形成的文本底稿它们的数据格式、更新频率、可信度都不一样。数据域来源存放位置生成方式客户基础信息信贷系统关系型数据库直接读取财务报表指标信贷系统/外采库结构化表规则计算模型解读征信与司法记录外采数据接口/数仓检索召回后引用舆情与行业资料互联网公开数据非结构化文档RAG召回模型归纳尽调底稿远程及现场调研音转文/手工录入大模型摘要提炼在这个场景里大模型承担的不是“从零写报告”而是“在数据齐备的情况下完成编排与起草”。模型需要先基于召回的数据生成报告框架然后逐个部分填充内容涉及数值引用的地方必须追溯到具体数据来源。实际落地时我一般会把整个流程拆成六步需求输入客户名称、行业、申请金额→ 多源数据接入信贷系统API、外采库、第三方接口→ 自动召回向量库检索结构化数据查询→ 模型分段起草先框架后正文→ 合规复核风控人员审查关键数据→ 定稿归档。前四步可以高度自动化后两步留人工这就是金融场景大模型应用的基本协作形态。4.2 知识驱动型智能问答从知识平台到专家级助手投研问答是另一个典型的L3场景。研究员面对的问题通常是“某产业链上游的议价能力如何变化”“某公司过去三年毛利率波动的原因是什么”这类问题需要同时依赖研报文档、财报数据、行业宏观信息和实时新闻。知识平台侧需要先把这些非结构化文档做清洗、切分、向量化入库检索侧需要支持关键词检索和向量检索的混合模式生成侧则要求模型在回答末尾标注引用来源。PPT里展示的星环TKH知识平台本质上就是干这件事的它把文档管理、向量化、检索、模型调用串成了一条链路。从实际项目踩坑经验看知识平台建设的第一步不是选模型而是盘点语料。很多金融机构的存量文档是扫描件PDF、图片型财报直接向量化效果很差需要先过一层OCR和版式还原再进入切分流程。这一层不做扎实后续RAG的召回精度再调也没用。4.3 研报撰写、合规助手与代码助手内容生产场景的边界研报撰写是L4微调比较理想的应用方向。券商研报有非常固定的格式行业概况、公司基本面、财务分析、盈利预测、风险提示而且用词风格高度统一。用几千篇历史研报做指令微调后模型可以输出符合体例的研报草稿研究员只需要修改数据和结论部分。合规助手的场景则需要强约束制度库、监管法规的准确性要求极高回答必须逐条引用条款原文所以它的架构通常以RAG为主检索不到就直接说查无此条绝对不能生成。智能尽调报告生成和代码助手也是PPT提到的方向。尽调报告和授信报告类似依赖多源数据召回加模板化生成代码助手则是面向金融科技研发团队帮他们写SQL查询、Python数据处理脚本、接口测试用例。代码助手这类场景在金融行业落地时有一个通用经验不能直接生成可执行代码而是生成带注释的伪代码或代码片段由研发人员确认后再执行避免模型生成有安全漏洞的代码直接进入生产环境。5. 避坑记录金融大模型项目里最常翻车的五个点5.1 检索命中了内容但模型还是答非所问现象RAG链路已经跑通向量库里也能搜到相关文档但模型给出的回答跟检索到的内容对不上甚至自己编了一套说法。原因切分粒度不匹配Chunk太大导致一个片段混入多个主题模型被无关信息干扰或者Embedding模型在金融术语上表征能力弱召回结果的相关性并不高。解决先人工查看召回的前5条内容是否真的能回答问题如果召回就不准换金融领域微调的Embedding模型配置Rerank重排如果召回准但生成错说明是Prompt里没有强调“仅基于检索内容作答”需要把约束条件写进System Prompt。5.2 SFT微调之后模型变笨了现象微调后金融术语确实说得更专业了但通用对话能力和基础推理能力明显退化甚至数学计算变差。原因训练数据过度集中在业务语料上多样性不足训练轮数太多导致过拟合学习率设置过高把底座模型的通用知识冲掉了。解决用LoRA低秩适配而不是全量微调rank值从16起调训练轮数控制在1到3轮业务语料和通用语料按7:3比例混合训练完成后必须做一次通用能力回归测评包括数学推理、代码生成、通用问答确认没有明显退化再上生产。5.3 模型在尽调报告里编造客户数据现象生成的尽调报告里出现了合理的财务数字但客户实际情况里根本没有这些数据且引用标注指向不存在的段落。原因大模型本质是概率生成当它发现上下文里缺少某个数据点时会倾向于用“看似合理”的内容填充缺口这被称为幻觉。解决在Prompt里强约束“未检索到的内容不得回答宁可留空”生成结果必须强制带引用锚点信审人员复核时直接点击引用查看原文段落形成可追溯的记录。更稳妥的做法是数据映射先行把结构化数据单独拿出来做插值填充不要让模型生成任何数值。5.4 Agent工具调用出现死循环现象Agent反复调用同一个工具或者选了错误的工具比如在需要查询财务数据时去调了天气接口最终消耗大量Token后返回无意义结果。原因工具描述写得不够精确模型无法判断工具的触发条件没有设置最大调用轮数工具返回格式不统一模型解析失败后反复重试。解决工具描述里必须写明触发场景和参数约束例如“仅当用户询问实时股价时调用该接口参数为股票代码”设置max_iterations最大步数限制为5工具返回统一为JSON格式并且增加超时控制和异常兜底逻辑。5.5 流式输出中断后后端还在继续生成现象用户在问答页面点了停止按钮前端界面停了但后端大模型还在继续生成Token费用持续累积。原因前端中止了网络请求但没有通知后端取消大模型推理任务后端的流式生成仍然在执行。解决前端用AbortController中断请求并向后端发送取消信号后端监听流的关闭事件检测到客户端断开后停止模型迭代SSE连接用[DONE]标记规范终止。金融场景中长文本生成耗时长中断控制做不好一个月浪费的算力成本可能相当可观。6. 生产化收尾Agent模式、SSE流式输出与微调的三个判断6.1 Agent模式怎么接从对话到工具调用的生产化改造PPT里提到的Agent模式AI代理落到工程层面通常是三种形态Plugin模式模型在对话中拦截特定关键词触发外部插件调用Function Calling模式模型根据函数描述生成结构化的调用参数由后端执行ReAct模式模型在推理和行动之间循环适合复杂任务分解。生产化改造时我一般用Function Calling作为首选把函数描述以JSON Schema方式注册给模型例如{ name: query_financial_statement, description: 查询上市公司财报关键指标, parameters: { type: object, properties: { stock_code: {type: string, description: 6位股票代码}, indicator: {type: string, enum: [revenue, net_profit, roe]} }, required: [stock_code, indicator] } }6.2 SSE流式输出与中断请求处理交互层的实时渲染常见做法是后端通过SSE协议推送大模型的流式输出前端用fetch配合ReadableStream逐段读取。这里的关键处理是需要配合abort控制前端停止操作示例代码中的中止逻辑可以直接用在金融场景的问答页面const controller new AbortController(); const response await fetch(/api/chat/stream, { method: POST, signal: controller.signal // 绑定中止信号 }); const reader response.body.getReader(); const decoder new TextDecoder(utf-8); while (true) { const { done, value } await reader.read(); if (done) break; // 流结束标记 renderChunk(decoder.decode(value)); // 逐段渲染 } // 用户点击停止时调用 controller.abort() 并通知服务端取消 document.querySelector(#stopBtn).onclick () controller.abort();6.3 训练还是微调三个判断问题每次做金融大模型方案答辩我都会要求团队先回答三个问题业务卡点是知识缺失还是表达不规范知识缺失优先RAG而不是微调是否需要对模型的通用能力做显著增强如果是就要走预训练而不是微调公司是否具备稳定的大规模算力和数据治理能力两者都不具备就先不要碰L5把L3和L4做扎实就够了。这三个问题过完技术上倾向于哪种方案基本就清楚了。从那以后我每次做金融大模型项目的技术方案都强制自己走一遍五层选型坐标先想到L2验证业务假设再决定要不要上RAG和SFTAgent工具链先接模拟数据再连生产。这份PPT的框架看起来是理论的但真按它走一遍能避掉不少因为选型错误导致的返工。希望帮到你。本文还有配套的精品资源点击获取 大模型金融落地指南：五层技术选型从提示工程到预训练
简介这份演示文稿以2024年大模型技术演进为线索系统梳理发展背景、核心特点与产业政策并聚焦金融行业落地探索。资源面向金融科技从业者、AI产品经理及技术决策者帮助读者快速理解从技术原理到业务应用的完整路径。包体为单个pptx文件大小约23.25MB已有159人浏览学习适合作为内部培训或专题分享演示底稿。内容涵盖ChatGPT带来的范式变革、Transformer等关键节点、模型泛化与多模态能力以及各级支持政策要点重点展示金融场景中的智能问答、研报撰写、投研问答、合规助手、智能数据分析、尽调报告生成和代码助手等实践并讨论模型训练与微调、AI代理模式和高质量语料构建。整体兼顾宏观趋势与具体用例可作为金融行业智能化转型的入门参考。1. 大模型技术落地金融不是换个聊天机器人而是换一套生产力2024年再做金融行业的大模型项目技术本身已经不再是最大的门槛真正难的是怎么把一个千亿参数的通用底座变成能过合规审核、能在信贷和投研场景里真正干活的生产工具。这份《2024大模型技术及其在金融行业的应用探索》PPT的价值在于它把这件事拆成了两条线一条是技术演进与产业政策的宏观脉络另一条是从普通LLM到预训练的五层应用构建方法论并且给出了授信可行性报告、投研问答、合规助手这类具体场景的拆解路径。对于正在做金融科技、企业AI中台、数据平台建设或者刚被领导安排去研究大模型落地的人来说这份材料的参考价值在于它告诉你金融场景下大模型能力边界在哪、哪个层级够用、什么时候需要微调甚至重新预训练。2. 技术演进与政策土壤从逐层预训练到千亿参数金融凭什么敢上第一线2.1 大模型的“大”具体指什么参数、数据与算力只是表层大模型通常包含数十亿甚至数千亿个参数这些参数在训练过程中被调整以最小化损失函数。为了训练这些模型需要海量的文本、图像、音频数据用于让模型识别模式并做出预测。由于模型规模和数据量之大大模型通常需要高性能GPU集群、大量内存和存储空间。但参数规模只是表象金融从业者真正关心的应该是它带来的四种能力强大的泛化能力意味着模型在未见过的数据上也能表现良好多模态理解能力让它能同时处理文本、图像、视频等输入迁移学习能力让模型可以在一个任务上预训练然后在其他相关任务上微调而上下文学习能力则让它能根据对话历史理解和生成连贯回应。这些能力映射到金融场景是很有价值的。泛化能力意味着同一个底座可以复用在研报撰写、合规审查、客服问答等多个业务线不需要每个场景单独训练一个模型迁移学习意味着一个中型团队也能基于开源底座用少量业务标注数据做行业适配多模态能力则直接对应财报PDF、合同扫描件、K线截图这类真实资产。所以金融行业说“大模型技术”的时候本质上是在说一套可以复用的能力底座而不是某个具体的聊天机器人产品。2.2 从Word2Vec到GPT-4大模型发展脉络中的关键转折点大模型的发展脉络看起来是线性的但真正值得记住的节点其实很集中。2006年Hinton提出逐层无监督预训练方式解决了深度模型梯度消失的问题这算是最早的预训练思想雏形。2013年Word2Vec让词向量成为标准操作词与词之间的语义关系第一次可以数学化表达。2014年GAN的出现是生成模型的里程碑。2017年Google提出Transformer架构这个自注意力机制真正开创了NLP的新纪元后续的BERT、GPT系列全都是它的变体。2018年预训练加微调范式成型模型先在通用语料上预训练再在具体任务上微调成为此后多年的标准路线。2020年GPT-3参数规模达到1750亿算力需求开始变得“恐怖”。2022年ChatGPT发布引发全社会关注2023年则进入超大规模多模态预训练时代。年份事件对金融行业的意义2006逐层无监督预训练深度学习可行性验证2013Word2Vec词向量语义检索技术基础2017Transformer架构长文本处理能力起点2020GPT-31750亿参数大规模语言模型能力跃升2022ChatGPT发布对话式交互范式确立2023多模态预训练大模型财报图表类数据可处理2.3 政策端与需求端的双向推力为什么金融行业能踩中这波红利政策端在推动大模型应用方面给出了一套明确的顶层设计。2017年《新一代人工智能发展规划》是最早的国家级纲领而后续的《生成式人工智能服务管理暂行办法》则划定了监管红线这对金融行业其实是一种利好因为金融机构最怕的不是技术落后而是合规风险不确定。更值得关注的是“数据要素×”三年行动计划2024-2026年明确提出支持通用大模型和垂直领域大模型训练这等于给了金融行业一个明确的信号行业大模型是被鼓励的方向。地方层面的政策更细比如北京市明确到2025年底形成3到5个基础大模型产品、100个行业大模型产品这些目标数字会直接转化为金融企业的立项预算。需求端的数据同样是实打实的。SAS与Coleman Parkes的调研显示中国企业在“已部署生成式AI但尚未完全覆盖整合”维度上占比64%总应用比例83%位居全球第一。IDC的调研则指出知识管理场景是当前企业端最受青睐的AIGC应用场景全球市场和中国市场受访企业的期待应用比例分别为52%和52.2%。知识管理恰恰是金融行业最重资产的部分——研报、尽调报告、合规制度、历史项目档案这些都是天然的检索增强场景。政策给了绿灯需求端给了场景供给端模型能力又恰好到了可用的临界点金融行业的大模型落地就这样被推到了前台。3. 五种方法构建大模型商业应用从提示工程到预训练的选型坐标3.1 Level 1与Level 2通用LLM直接问答与提示词工程CoTPPT里把大模型商业应用划分成了五个递进层级从L1到L5分别对应“常人”到“大师”的能力水平。L1是直接部署通用LLM提供基础问答这时候模型回答依赖的是它预训练阶段学习到的通用知识没有企业数据注入。L1适合的场景非常有限比如员工规章制度答疑、技术文档初步检索因为问题一旦涉及到企业内部数据和金融领域专有名词通用模型就会开始一本正经地胡说八道。从实际项目角度看L1基本只适合做验证和演示不太能直接进入生产链路。L2开始引入提示词工程也就是通过精心构造Prompt让LLM扮演特定角色、按照特定思维链回答。很多人觉得提示词工程不就是写几句话的事实际上在金融场景里Prompt的结构化程度直接决定输出质量的稳定性。下面是一个典型的金融投研场景Prompt模板【角色设定】假设你是一位金融投研领域的专家拥有10年行业研究经验。 【任务背景】请从产业链上下游的角度分析该公司的市场竞争格局。 【约束条件】 1. 只基于给定的事实信息作答不编造数据 2. 回答结构产业定位 - 上游议价能力 - 下游需求 - 风险点 3. 涉及数据时标注来源 【输出格式】Markdown结构化输出每个结论附简短依据这里的核心逻辑是通过角色设定把模型的输出空间约束到金融专家的轨道上通过约束条件明确回答边界通过输出格式让结果可以直接进入下游报告流程。金融行业用提示词工程有一个很重要的习惯就是明确要求模型“不编造数据”并在输出中标注依据这样至少在形式上为后续的合规审查留了窗口。提示词工程虽然成本最低但它的问题也很明显模型的能力上限没有变化只是输出的组织方式变好了如果业务问题本身超出了模型的内部知识范围Prompt写得再精致也没用。3.2 Level 3RAG与Agent把企业知识注入大模型的关键一跃从L3开始方案才真正触及金融行业大模型落地的核心把企业自身数据接入模型推理链路。RAG检索增强生成的流程是把企业文档预先切分成Chunk经过Embedding模型向量化后存入向量数据库用户提问时将问题同样做Embedding在向量库中执行相似度检索召回Top-K相关内容然后把这些内容拼进Prompt交给大模型生成回答。同时Agent机制的引入让模型可以自主选择工具例如查询实时行情、调用数据库接口、获取外部研报。这套机制对金融行业的意义在于它第一次把“模型能力”和“企业知识”解耦了。信贷部门的授信档案、投研部门的行业报告、合规部门的制度文件都能通过RAG注入到问答链路中而不需要对模型本身做任何改动。在实际落地中向量化参数直接决定召回质量下面是一份我常用的参数配置参考参数项常见配置说明切分粒度 chunk_size300-500 tokens金融文档宜偏小减少跨主题污染切分重叠 overlap50 tokens避免句子被截断在边界Embedding模型通用文本向量模型或金融微调向量模型后者对财报术语更友好召回条数 TopK5-8过多会稀释上下文注意力相似度阈值0.6-0.8低于阈值宁可拒绝回答重排序 Rerank建议开启用交叉编码器精排召回结果这里有一个经常被忽略的细节切分粒度和Embedding模型要一起调。金融文档里大量存在“资产负债表、现金流量表、利润表”这类术语密集的内容如果切分过大会让一个Chunk里混入多个主题检索时召回的是一堆相关但无法精准回答的内容切分过小又会丢失上下文语境。我一般会在车型到300到500字符之间做几组对比用召回内容的准确率人工抽检来确定最佳参数而不是凭感觉写死一个数。3.3 Level 4与Level 5有监督微调与继续预训练的成本与边界L4是有监督微调SFT做法是准备一批“问题-标准答案”或“指令-响应”对在开源底座模型上做指令微调让模型学会金融术语、报告体例、合规话术。SFT和RAG最大的区别在于前者改变的是模型的“行为风格”和“表达习惯”后者改变的是模型的“知识来源”。如果业务场景要求模型输出的语气、结构和用词都要符合特定报告规范那就需要SFT如果只是知识不够优先用RAG补知识不要动微调。微调的参数设置上我一般用LoRA低秩适配rank值在8到64之间训练轮数控制在1到3轮学习率在1e-4到5e-5之间。数据集规模不需要很多几百到几千条高质量指令对就可以起步重点是数据质量而不是数量。L5继续预训练则是在通用底座上用大规模金融语料库对模型全部参数做进一步训练。这个层级的成本量级已经完全不同了需要高性能GPU集群、数十亿token的行业语料训练周期以周甚至月为单位。PPT里的分层逻辑很清楚L1是普通人L2是胜任者L3是专家L4是大师L5是领域宗师。金融行业的绝大多数业务场景到L3加L4就已经够用了继续预训练只有在需要掌握极其深度的行业知识、并且有强大算力支持的头部机构才会考虑。3.4 五层方法对比给具体金融场景选层级层级技术手段成本量级适用场景风险等级L1通用LLM直接问答极低员工制度答疑、泛知识检索高不可控L2提示词工程CoT低投研初筛、报告框架生成中L3RAG Agent中知识问答、尽调辅助、信审辅助低L4有监督微调LoRA/SFT中高研报生成、合规文本改写低需数据合规L5继续预训练极高行业级深度知识底座低但成本极高选自层级的判断标准其实很简单先问业务卡点在哪里。如果模型输出答非所问先排查是不是提示词没约束住如果知识不够优先做RAG如果RAG召回的内容够、但输出风格和规范不对再考虑SFT只有当前面所有手段都试过、仍然需要模型具备大量隐性行业知识时才去谈继续预训练。这个顺序反过来做大概率会踩进成本黑洞。4. 金融场景怎么拆授信报告、投研问答与合规助手的落地路径4.1 授信可行性报告场景拆解一类业务的数据与模型分工PPT里举的例子非常典型用大模型帮助信贷部门业务人员撰写《授信项目可行性报告》这份报告的原有人工撰写流程是针对申请授信的单一客户做详细调查涉及内部数据、外采数据、互联网数据以及远程和现场调研数据报告模板共计十七页。这个场景的复杂度在于数据来源的异构性极强信贷系统里的财务数据、外部采购的征信数据、互联网上的公开舆情、线下尽调形成的文本底稿它们的数据格式、更新频率、可信度都不一样。数据域来源存放位置生成方式客户基础信息信贷系统关系型数据库直接读取财务报表指标信贷系统/外采库结构化表规则计算模型解读征信与司法记录外采数据接口/数仓检索召回后引用舆情与行业资料互联网公开数据非结构化文档RAG召回模型归纳尽调底稿远程及现场调研音转文/手工录入大模型摘要提炼在这个场景里大模型承担的不是“从零写报告”而是“在数据齐备的情况下完成编排与起草”。模型需要先基于召回的数据生成报告框架然后逐个部分填充内容涉及数值引用的地方必须追溯到具体数据来源。实际落地时我一般会把整个流程拆成六步需求输入客户名称、行业、申请金额→ 多源数据接入信贷系统API、外采库、第三方接口→ 自动召回向量库检索结构化数据查询→ 模型分段起草先框架后正文→ 合规复核风控人员审查关键数据→ 定稿归档。前四步可以高度自动化后两步留人工这就是金融场景大模型应用的基本协作形态。4.2 知识驱动型智能问答从知识平台到专家级助手投研问答是另一个典型的L3场景。研究员面对的问题通常是“某产业链上游的议价能力如何变化”“某公司过去三年毛利率波动的原因是什么”这类问题需要同时依赖研报文档、财报数据、行业宏观信息和实时新闻。知识平台侧需要先把这些非结构化文档做清洗、切分、向量化入库检索侧需要支持关键词检索和向量检索的混合模式生成侧则要求模型在回答末尾标注引用来源。PPT里展示的星环TKH知识平台本质上就是干这件事的它把文档管理、向量化、检索、模型调用串成了一条链路。从实际项目踩坑经验看知识平台建设的第一步不是选模型而是盘点语料。很多金融机构的存量文档是扫描件PDF、图片型财报直接向量化效果很差需要先过一层OCR和版式还原再进入切分流程。这一层不做扎实后续RAG的召回精度再调也没用。4.3 研报撰写、合规助手与代码助手内容生产场景的边界研报撰写是L4微调比较理想的应用方向。券商研报有非常固定的格式行业概况、公司基本面、财务分析、盈利预测、风险提示而且用词风格高度统一。用几千篇历史研报做指令微调后模型可以输出符合体例的研报草稿研究员只需要修改数据和结论部分。合规助手的场景则需要强约束制度库、监管法规的准确性要求极高回答必须逐条引用条款原文所以它的架构通常以RAG为主检索不到就直接说查无此条绝对不能生成。智能尽调报告生成和代码助手也是PPT提到的方向。尽调报告和授信报告类似依赖多源数据召回加模板化生成代码助手则是面向金融科技研发团队帮他们写SQL查询、Python数据处理脚本、接口测试用例。代码助手这类场景在金融行业落地时有一个通用经验不能直接生成可执行代码而是生成带注释的伪代码或代码片段由研发人员确认后再执行避免模型生成有安全漏洞的代码直接进入生产环境。5. 避坑记录金融大模型项目里最常翻车的五个点5.1 检索命中了内容但模型还是答非所问现象RAG链路已经跑通向量库里也能搜到相关文档但模型给出的回答跟检索到的内容对不上甚至自己编了一套说法。原因切分粒度不匹配Chunk太大导致一个片段混入多个主题模型被无关信息干扰或者Embedding模型在金融术语上表征能力弱召回结果的相关性并不高。解决先人工查看召回的前5条内容是否真的能回答问题如果召回就不准换金融领域微调的Embedding模型配置Rerank重排如果召回准但生成错说明是Prompt里没有强调“仅基于检索内容作答”需要把约束条件写进System Prompt。5.2 SFT微调之后模型变笨了现象微调后金融术语确实说得更专业了但通用对话能力和基础推理能力明显退化甚至数学计算变差。原因训练数据过度集中在业务语料上多样性不足训练轮数太多导致过拟合学习率设置过高把底座模型的通用知识冲掉了。解决用LoRA低秩适配而不是全量微调rank值从16起调训练轮数控制在1到3轮业务语料和通用语料按7:3比例混合训练完成后必须做一次通用能力回归测评包括数学推理、代码生成、通用问答确认没有明显退化再上生产。5.3 模型在尽调报告里编造客户数据现象生成的尽调报告里出现了合理的财务数字但客户实际情况里根本没有这些数据且引用标注指向不存在的段落。原因大模型本质是概率生成当它发现上下文里缺少某个数据点时会倾向于用“看似合理”的内容填充缺口这被称为幻觉。解决在Prompt里强约束“未检索到的内容不得回答宁可留空”生成结果必须强制带引用锚点信审人员复核时直接点击引用查看原文段落形成可追溯的记录。更稳妥的做法是数据映射先行把结构化数据单独拿出来做插值填充不要让模型生成任何数值。5.4 Agent工具调用出现死循环现象Agent反复调用同一个工具或者选了错误的工具比如在需要查询财务数据时去调了天气接口最终消耗大量Token后返回无意义结果。原因工具描述写得不够精确模型无法判断工具的触发条件没有设置最大调用轮数工具返回格式不统一模型解析失败后反复重试。解决工具描述里必须写明触发场景和参数约束例如“仅当用户询问实时股价时调用该接口参数为股票代码”设置max_iterations最大步数限制为5工具返回统一为JSON格式并且增加超时控制和异常兜底逻辑。5.5 流式输出中断后后端还在继续生成现象用户在问答页面点了停止按钮前端界面停了但后端大模型还在继续生成Token费用持续累积。原因前端中止了网络请求但没有通知后端取消大模型推理任务后端的流式生成仍然在执行。解决前端用AbortController中断请求并向后端发送取消信号后端监听流的关闭事件检测到客户端断开后停止模型迭代SSE连接用[DONE]标记规范终止。金融场景中长文本生成耗时长中断控制做不好一个月浪费的算力成本可能相当可观。6. 生产化收尾Agent模式、SSE流式输出与微调的三个判断6.1 Agent模式怎么接从对话到工具调用的生产化改造PPT里提到的Agent模式AI代理落到工程层面通常是三种形态Plugin模式模型在对话中拦截特定关键词触发外部插件调用Function Calling模式模型根据函数描述生成结构化的调用参数由后端执行ReAct模式模型在推理和行动之间循环适合复杂任务分解。生产化改造时我一般用Function Calling作为首选把函数描述以JSON Schema方式注册给模型例如{ name: query_financial_statement, description: 查询上市公司财报关键指标, parameters: { type: object, properties: { stock_code: {type: string, description: 6位股票代码}, indicator: {type: string, enum: [revenue, net_profit, roe]} }, required: [stock_code, indicator] } }6.2 SSE流式输出与中断请求处理交互层的实时渲染常见做法是后端通过SSE协议推送大模型的流式输出前端用fetch配合ReadableStream逐段读取。这里的关键处理是需要配合abort控制前端停止操作示例代码中的中止逻辑可以直接用在金融场景的问答页面const controller new AbortController(); const response await fetch(/api/chat/stream, { method: POST, signal: controller.signal // 绑定中止信号 }); const reader response.body.getReader(); const decoder new TextDecoder(utf-8); while (true) { const { done, value } await reader.read(); if (done) break; // 流结束标记 renderChunk(decoder.decode(value)); // 逐段渲染 } // 用户点击停止时调用 controller.abort() 并通知服务端取消 document.querySelector(#stopBtn).onclick () controller.abort();6.3 训练还是微调三个判断问题每次做金融大模型方案答辩我都会要求团队先回答三个问题业务卡点是知识缺失还是表达不规范知识缺失优先RAG而不是微调是否需要对模型的通用能力做显著增强如果是就要走预训练而不是微调公司是否具备稳定的大规模算力和数据治理能力两者都不具备就先不要碰L5把L3和L4做扎实就够了。这三个问题过完技术上倾向于哪种方案基本就清楚了。从那以后我每次做金融大模型项目的技术方案都强制自己走一遍五层选型坐标先想到L2验证业务假设再决定要不要上RAG和SFTAgent工具链先接模拟数据再连生产。这份PPT的框架看起来是理论的但真按它走一遍能避掉不少因为选型错误导致的返工。希望帮到你。本文还有配套的精品资源点击获取