简介这份演示文稿系统梳理大模型技术发展历程、核心特点、产业政策与落地路径重点聚焦金融行业场景适合金融科技从业者、AI产品经理及数字化转型人员参考。内容涵盖ChatGPT引发的范式变革、Transformer架构演进、大模型规模化参数与算力需求以及企业级应用体系建设的五类方法并结合智能问答、知识检索、研报撰写、合规助手、智能数据分析等金融案例展示生成式AI在业务中的具体切入方式。同时围绕模型训练与微调的必要性、AI代理Agent模式构建、高质量语料治理等实务环节给出管理思路帮助读者理解从技术选型到落地运营的关键动作。资源为1个PowerPoint演示文稿pptx格式压缩包大小23.25MB章节结构完整清晰便于按目录顺序学习。已有159人学习该资料适合作为从技术认知到金融行业应用的系统性学习材料。1. 大模型在金融行业的真实门槛不在算力而在知识边界2024 年我身边真正把大模型用起来的金融团队没有一个是靠“问它什么都知道”赢得信任的。大家最务实的做法是把大模型当成一个可控的文本处理内核接在研报、公告、合同这些私有文档后面让它只回答能引用出处的问题。这个标题里讲的“大模型技术及其在金融行业的应用探索”本质上不是在探索聊天机器人而是在探索一条可审计的知识管线把语料切碎、向量化、召回、再组织成最终答案。文章往下按这条线展开先讲清楚为什么 RAG 是金融场景的首选路线再看具体业务场景做什么然后给出一套可运行的最小方案和参数配置最后把最容易翻车的地方逐个拆开。适合正在做技术选型、或者刚接到“金融 大模型”试点任务的工程师照着走一遍。2. 拆开2024年的大模型技术栈金融场景为什么先选RAG而不是微调2.1 大模型的能力边界与幻觉根源2024 年的开源大模型在中文长文本理解和指令遵循上已经能进企业内部业务流。参数规模带来的收益很直接能从财报附注里读出借贷方向的变化能把招股书里分散的关联方信息拼成一张关系网能按指定的输出格式生成固定字段。这些能力本质上来自预训练阶段积累的统计规律所以模型擅长的是“补全”和“联想”而不是“查证”。幻觉由此而来。生成阶段每一个 token 都是概率采样结果模型在写下一句话时目标是让输出看起来更像人话而不是让输出与某个数据源一致。金融行业最常见的反例都藏在细节里把某个财务指标说反了、把公告日期提前了一年、把“未分配利润”解释成“已分配”。这不是模型笨是它的生成目标里根本没有“查证”这个动作任何只靠提示词约束的方案都压不住这类问题。还有一个常被低估的边界是上下文长度。2024 年主流模型的上下文窗口从 8k 到 128k 不等表面看很长但一份完整的券商研报常常是 40 页到 80 页全部塞进去既不经济模型也记不住中间的细节。上下文窗口的正确用法是装“检索回来的几个片段 问题 系统指令”而不是装整本书。理解这一点后面 RAG 管线的设计就顺理成章了。2.2 金融行业为什么不能直接拿通用问答来用金融数据有三个特征和通用问答场景差别很大。一是知识更新快上市公司公告按小时级别在变化预训练模型的知识是静态的永远滞后二是术语和语境封闭“缩表”“非标”“对赌条款”这些词在不同语境下含义差别很大通用模型容易混淆三是业务要留痕任何一个结论都要能追溯到原文段落不是“说得对”就行而是要“说得有出处”。这三点叠加决定了金融场景不能指望模型“自身会”而是要让模型“查出来才会”。这也是 2024 年行业里落地节奏最快、业务价值最清晰的应用几乎都是基于 RAG 的文档问答和文档处理而不是直接做微调的通用助手。RAG 的知识更新成本很低语料变化时只需要重新切片、重新入库不需要重训模型。同时可追溯性天然强生成答案能附带引用片段业务人员可以反向核对原文这正好对上“留痕”的硬要求。从实施成本看RAG 也比微调友好得多。微调一个 7B 模型至少需要一批高质量标注数据金融领域的数据标注要业务人员参与成本高、周期长、口径难统一。RAG 只需要把存量 PDF、Word、公告原样入库先跑通业务闭环再用积累的高质量问答对去微调节奏更稳。2.3 三种技术路线的分工RAG、微调与Agent的配合常见做法是把三条路线放在同一个技术栈里分工而不是二选一。RAG 负责“回答需要外部知识的问题”微调负责“让模型适配特定输出格式和专业口吻”Agent 负责“需要多步工具调用的流程”比如查行情、算指标、再汇总成简报。我一般这样选型问题答案藏在机构内部文档里的先走 RAG。输出格式非常固定、且已积累上千条优质样例的考虑微调。需要跨系统操作的才上 Agent。2024 年项目里最常见的误区是把这三个概念混成一团对着一个需求同时上三套方案最后项目周期翻倍。正确的做法是先想清楚业务里哪一步是知识检索、哪一步是格式转换、哪一步是工具调用再决定投入哪条路线。模型选型也跟着收窄知识问答场景优先选中文长文本理解稳定的开源基座模型格式生成场景选指令遵循好的模型Agent 场景要看工具调用能力。部署时还要考虑量化精度和显存的平衡INT4 量化能省显存但会损失一点长文本稳定性INT8 更稳但需要更大的显存。这些取舍没有标准答案只能按手头资源和业务重要程度来定。3. 金融应用落地场景拆解研报问答、摘要抽取和合规审查怎么分工3.1 文档知识问答让研报和公告变成可追索的条目金融行业里 RAG 落地最多的场景是“文档知识问答”。典型输入是几百份上市公司公告、行业研报、内部制度文件业务人员可以直接提问“这家公司 2024 年上半年海外收入占比是多少”“这份合同里划款条件改了什么”。这个场景能做成的关键是切片后的段落与问题之间存在可检索的语义关联2024 年的开源嵌入模型已经能稳定做到这一点。落地形态通常是一个内部问答入口。用户输入问题系统先做向量检索把最相关的 4 到 6 个片段捞出来再连同问题和系统提示词一起交给生成模型。前端展示答案时必须列出引用片段和出处页码这一条往往决定业务方愿不愿意用。没有引用再准的答案也被怀疑有引用错了也有地方修改。权限隔离也要提前做不同团队能看到的知识库可能不同至少要按文档来源做一层过滤。文档问答的维护量不在模型而在文档更新。每次新公告发布要触发增量更新流程把新文本切片、入库、替换旧版本。如果不做增量更新知识库会越积越旧最终回退到“模型瞎编”的状态。金融场景里知识库新鲜度比模型大小更要紧。3.2 投研辅助摘要、结构化抽取与信息关联第二类场景是把大模型当成“阅读加速器”。常见做法是对长篇研报做摘要提炼投资逻辑、风险提示和关键假设再进一步把文字段落抽取成结构化字段比如营收、净利润、同比变动、毛利率、现金流。结构化抽取的价值在于接进已有投研数据库让下游报表和预警系统能继续用。大模型的摘要能力可以大幅缩短分析师翻阅长文的时间但摘要质量需要评估不能只看流程是否跑通。这类任务更依赖提示词设计和输出约束而不是模型大小。实践中我会用 JSON Schema 做输出格式约束强制模型按固定字段返回。字段缺失时要让模型返回 null而不是凭空填一个数字。{ company_name: string, report_title: string, key_metrics: { revenue: number | null, net_profit: number | null, yoy_growth: number | null, gross_margin: number | null }, risk_factors: [string], source_page: string }因为财务字段一旦错位下游报表系统会直接跑出脏数据所以这类场景宁可模型说“不知道”不要模型“猜一个”。输出校验层要加在生成之后用正则或规则脚本检查关键字段是否符合数值格式不符合就重新生成或标记为异常。3.3 风控与合规审查从规则匹配升级到语义判断第三类场景是文本审查比如合同条款审查、舆情监测、合规问答。过去主要靠关键词规则准确率不稳同义表达一换规则就失效。大模型带来的提升在语义层面能识别“未取得销售资格即对外开展业务”和“先收款后补手续”这类变体表述也能把非结构化文本中的风险信号抽出来。在合规场景里大模型更适合做辅助初筛而不是下结论。常见部署是先用模型做粗筛把疑似有问题的段落推给人工复核复核结论再回流作为下一轮微调的训练数据。这既满足业务方对人工审核责任的要求也解决了“不信任黑匣子”的问题。输出侧要保留完整的输入文本、模型判断以及置信度信息方便回溯追责。这类项目容易被低估的部分是预处理。金融文本里大量存在扫描件和表格需要先做 OCR 和版面还原把表格转成 Markdown 或 CSV 再进入切片流程。OCR 错字会直接污染检索质量所以在预处理阶段就要做文本校对和乱码清洗否则审查覆盖面再广也是空的。第 4 章的技术方案就是面向这三类共性需求搭出来的。4. 搭建最小可运行的金融文档问答切分、嵌入、检索生成的完整参数链4.1 选型参数模型尺寸、嵌入模型和向量库怎么搭配常见做法是追求“能跑多快”和“能控多严”。对于金融内部试点比较稳的搭配是部署一个 7B 到 14B 的开源基座模型一台 24GB 显存的单机就能跑推理。嵌入模型要选中文语义理解稳定、支持归一化的开源模型。向量库选本地可跑的 FAISS 或带过滤功能的 pgvector数据量在百万级以内都能覆盖要接团队权限体系时pgvector 更合适因为可以 SQL 过滤文档来源。环节推荐方向说明生成模型7B/14B 中文长文本模型24GB 显存可推理金融场景不盲目追最大参数嵌入模型bge 等中文语义嵌入支持归一化检索效果比维度大小更重要向量库FAISS / pgvector单机原型 FAISS需要权限过滤换 pgvector分块大小500800 字中文场景太大丢定位太小丢语义召回数 k46 个片段太少漏信息太多稀释上下文注意模型尺寸不只看显存要看任务。14B 在长文本归纳上比 7B 明显更稳但推理速度也慢将近一倍。先在小规模语料上验证效果再决定是否换更大的模型不要一开始就上最大参数。4.2 切分与入库实现分块大小和重叠是召回的第一道闸门金融文档的结构通常是有序的标题、段落、表格、注释。切片最怕两件事把一段完整因果关系切开把标题和正文分离。下面是常用的切分方式把粗粒度分隔符和长度限制结合起来优先按自然段落切再用长度兜底。from langchain.text_splitter import RecursiveCharacterTextSplitter # 金融研报最稳的是“段落优先、长度兜底”切分 splitter RecursiveCharacterTextSplitter( chunk_size800, # 单块目标长度中文场景500~800字召回最稳 chunk_overlap120, # 重叠用于缓解“切断句意”带来的损失 separators[\n\n, \n, 。, , , ], keep_separatorTrue, ) # pdf_text 已经由 PDF 解析器抽取为纯文本 chunks splitter.split_text(pdf_text) print(f得到 {len(chunks)} 个片段平均 {sum(map(len, chunks)) // len(chunks)} 字)先按双换行切自然段再按句号、分号补切重叠 120 字保证被切断的句意至少有一部分落在相邻块里。chunk_size 不能拍脑袋金融问题喜欢跨段落比较块太小导致单个块形不成完整语义块太大又让向量检索精度下降。实践上研报用 800 字、合同条文用 500 字更合适因为合同条款本身结构短切大块反而把不同条款混在一起。切片之后不要急着入库先抽查一批片段确认标题没有单独成块、表格没有被拆散。表格类内容建议单独提取按行列转成文本或保留 Markdown 格式否则向量化之后表格语义会丢失。对于多页 PDF还要在片段里保留页码和来源文件字段这是后续引用溯源的基础。4.3 嵌入与向量入库归一化和索引是要点from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) # 文本入库并保存到本地保证金融数据不出内网 vectorstore FAISS.from_texts( textschunks, embeddingembedding_model, ) vectorstore.save_local(./finance_rag_index)归一化打开后余弦相似度和内积等价召回结果更稳定。嵌入模型的选择要用自己场景里的真实问题去检验而不是看公开榜单实测中 bge 系列在中文金融文档上表现不错但换一个行业就可能出现明显偏差。save_local 只适合单机原型多人协作时建议换成 pgvector 或 Milvus并加上文档来源字段做权限过滤。4.4 检索与生成temperature 和 top_k 要一起调from langchain_community.llms import Ollama from langchain.chains import RetrievalQA llm Ollama( modelqwen2.5:14b, temperature0.1, num_ctx8192, ) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue, ) question 这家公司2024年主营业务收入构成有什么变化 resp qa.invoke(question) print(resp[result]) for doc in resp[source_documents]: print(引用, doc.page_content[:100])k 设为 4让生成模型拿到 3 到 5 个片段互相补充又不互相稀释。温度 0.1 是金融场景的常用值再低显得机械再高容易放开约束开始自由发挥。num_ctx 要大于所有片段加问题加提示词的总长度否则生成阶段会直接截断。检索出的片段里混入不相关信息时先检查提示词是否明确写了“只依据给定上下文回答没有依据就说不知道”。这一句话往往比换更大的模型更管用。5. 排查与避坑金融大模型项目中最容易翻车的5个环节5.1 检索到了答案照样编RAG幻觉的边界比想象的宽现象检索返回的片段里明明有正确数据生成的答案却把数值写错甚至把“同比增长”说成“环比增长”。原因检索和生成是两条独立链路生成阶段只拿到片段模型在组织文本时为了“说得顺”会自行补全数值和逻辑。解决把温度压到 0.1 以下并在提示词里强制要求“只回答片段中存在的数值缺失时明确说不知道”。更硬的方案是在生成后加一层数值校验把片段中的数字与答案中的数字做比对不一致就拦截。金融场景里这类校验脚本成本很低价值却很大。5.2 切分把句子腰斩召回不到完整事实现象文档里明明有一整段主营业务收入说明检索时却只召回后半截模型给出的理由对不上号。原因固定长度切分在段落中间下手把一句完整因果拆成两半向量只带着一半信息入库召回自然偏差。解决切分优先用结构分隔符先按标题和段落切再补长度控制表格和脚注单独处理。验证时做一个“召回率抽样脚本”把每个问题对应的前 3 个片段打出来人工扫一遍几轮就能暴露切分问题。5.3 上下文窗口用完了长问题直接降智现象问题本身不长但片段加提示词一拼接生成模型开始重复输出或者丢掉了之前已经给出的观点。原因片段数量多、每个片段又长加上系统提示词里的示例累计 token 数逼近 num_ctx 上限模型在长序列上注意力衰减。解决先算预算给最终答案留 1000 token 左右其余分配给片段召回数设为 4单块控制在 500 到 800 字。如果答案长度需求大就上调 num_ctx同时把单块长度往下压保证总 token 不超限。5.4 数据不出内网和安全约束打架现象团队想用商用 API 快速验证但客户要求文本不能离开内网。原因金融数据安全边界把外部 API 直接堵死不是技术选型问题是项目能不能立项的前提。解决把演示环境切到单机本地部署嵌入模型和生成模型都跑在内网向量库不暴露公网端口敏感字段在切片前先做脱敏。所有一体机方案本质都是这套逻辑差别只是谁来运维。启动任何项目前先确认数据边界再决定模型部署形态顺序不能反。5.5 业务方不认可输出因为验收指标没对齐现象工程师说“准确率 90%”业务方不信因为抽查几题就发现了硬伤。原因准确率定义和业务口径不一致。业务方更关心的是“这个结论有没有依据”“我回哪里能找到原文”。解决验收标准里同时放三个维度的指标答案相关性、忠实度、引用命中率。让业务方直接标注一小批测试集把模型输出和原文并列展示确认引用是否真的支撑了答案。指标可以自动化计算但前提是测试集来自业务真实问题而不是工程师自己编的。6. 投入前的验证用三个指标让业务方认可大模型产出6.1 从人工印象到可复测的三项指标我习惯在项目启动第二周就拉一个 30 到 50 题的评测集题目来源是业务人员自己提的真实问题。指标只盯三个答案相关性、忠实度、引用命中率。忠实度是金融里最该卡死的项它衡量答案是否忠于引用片段低于 0.8 就要回溯片段拼接逻辑和提示词设计。答案相关性衡量模型是否答在了问题上引用命中率衡量检索环节有没有返回真正有用的段落这两项卡的是 RAG 管线的两端。评测不用全自动化可以让业务方对答案打分也可以在生成结果里随机抽样做人工复核。关键在于跑分过程可复现避免“今天感觉不错、明天换个语料就崩”的印象流验收。基线分数落定后后续每一次调整模型、切分参数或提示词都往同一套测试集上回测对比分数变化。6.2 下一阶段的路径从单点问答走向Agent编排验证通过后再谈扩展。常见进阶路径是把 RAG 问答能力封装成内部服务再叠加工具调用让模型去查行情接口、取数据库字段最后汇总生成日报。每一步增加一个新工具就回来重跑那 50 题评测集防止能力叠加后反而伤害原有准确率。个人经验是工具调用带来的失效模式比 RAG 更多比如模型拿到了正确工具但给了错误参数这种情况只能靠大量样例积累去校准。我自己遇到新场景时会先用 5 天搭一个最小管道再用 50 道真问题跑基线分达不到门槛就不往生产走。这个习惯帮我挡掉了不少“听起来很美”的项目。验证指标过关才谈得上部署和推广否则再大的模型也只是演示壳。这一套方法不一定最省事但能让金融场景的落地从“探索”变成“可控交付”。希望帮到你。本文还有配套的精品资源点击获取 大模型金融落地指南：RAG如何破解知识边界与幻觉难题
简介这份演示文稿系统梳理大模型技术发展历程、核心特点、产业政策与落地路径重点聚焦金融行业场景适合金融科技从业者、AI产品经理及数字化转型人员参考。内容涵盖ChatGPT引发的范式变革、Transformer架构演进、大模型规模化参数与算力需求以及企业级应用体系建设的五类方法并结合智能问答、知识检索、研报撰写、合规助手、智能数据分析等金融案例展示生成式AI在业务中的具体切入方式。同时围绕模型训练与微调的必要性、AI代理Agent模式构建、高质量语料治理等实务环节给出管理思路帮助读者理解从技术选型到落地运营的关键动作。资源为1个PowerPoint演示文稿pptx格式压缩包大小23.25MB章节结构完整清晰便于按目录顺序学习。已有159人学习该资料适合作为从技术认知到金融行业应用的系统性学习材料。1. 大模型在金融行业的真实门槛不在算力而在知识边界2024 年我身边真正把大模型用起来的金融团队没有一个是靠“问它什么都知道”赢得信任的。大家最务实的做法是把大模型当成一个可控的文本处理内核接在研报、公告、合同这些私有文档后面让它只回答能引用出处的问题。这个标题里讲的“大模型技术及其在金融行业的应用探索”本质上不是在探索聊天机器人而是在探索一条可审计的知识管线把语料切碎、向量化、召回、再组织成最终答案。文章往下按这条线展开先讲清楚为什么 RAG 是金融场景的首选路线再看具体业务场景做什么然后给出一套可运行的最小方案和参数配置最后把最容易翻车的地方逐个拆开。适合正在做技术选型、或者刚接到“金融 大模型”试点任务的工程师照着走一遍。2. 拆开2024年的大模型技术栈金融场景为什么先选RAG而不是微调2.1 大模型的能力边界与幻觉根源2024 年的开源大模型在中文长文本理解和指令遵循上已经能进企业内部业务流。参数规模带来的收益很直接能从财报附注里读出借贷方向的变化能把招股书里分散的关联方信息拼成一张关系网能按指定的输出格式生成固定字段。这些能力本质上来自预训练阶段积累的统计规律所以模型擅长的是“补全”和“联想”而不是“查证”。幻觉由此而来。生成阶段每一个 token 都是概率采样结果模型在写下一句话时目标是让输出看起来更像人话而不是让输出与某个数据源一致。金融行业最常见的反例都藏在细节里把某个财务指标说反了、把公告日期提前了一年、把“未分配利润”解释成“已分配”。这不是模型笨是它的生成目标里根本没有“查证”这个动作任何只靠提示词约束的方案都压不住这类问题。还有一个常被低估的边界是上下文长度。2024 年主流模型的上下文窗口从 8k 到 128k 不等表面看很长但一份完整的券商研报常常是 40 页到 80 页全部塞进去既不经济模型也记不住中间的细节。上下文窗口的正确用法是装“检索回来的几个片段 问题 系统指令”而不是装整本书。理解这一点后面 RAG 管线的设计就顺理成章了。2.2 金融行业为什么不能直接拿通用问答来用金融数据有三个特征和通用问答场景差别很大。一是知识更新快上市公司公告按小时级别在变化预训练模型的知识是静态的永远滞后二是术语和语境封闭“缩表”“非标”“对赌条款”这些词在不同语境下含义差别很大通用模型容易混淆三是业务要留痕任何一个结论都要能追溯到原文段落不是“说得对”就行而是要“说得有出处”。这三点叠加决定了金融场景不能指望模型“自身会”而是要让模型“查出来才会”。这也是 2024 年行业里落地节奏最快、业务价值最清晰的应用几乎都是基于 RAG 的文档问答和文档处理而不是直接做微调的通用助手。RAG 的知识更新成本很低语料变化时只需要重新切片、重新入库不需要重训模型。同时可追溯性天然强生成答案能附带引用片段业务人员可以反向核对原文这正好对上“留痕”的硬要求。从实施成本看RAG 也比微调友好得多。微调一个 7B 模型至少需要一批高质量标注数据金融领域的数据标注要业务人员参与成本高、周期长、口径难统一。RAG 只需要把存量 PDF、Word、公告原样入库先跑通业务闭环再用积累的高质量问答对去微调节奏更稳。2.3 三种技术路线的分工RAG、微调与Agent的配合常见做法是把三条路线放在同一个技术栈里分工而不是二选一。RAG 负责“回答需要外部知识的问题”微调负责“让模型适配特定输出格式和专业口吻”Agent 负责“需要多步工具调用的流程”比如查行情、算指标、再汇总成简报。我一般这样选型问题答案藏在机构内部文档里的先走 RAG。输出格式非常固定、且已积累上千条优质样例的考虑微调。需要跨系统操作的才上 Agent。2024 年项目里最常见的误区是把这三个概念混成一团对着一个需求同时上三套方案最后项目周期翻倍。正确的做法是先想清楚业务里哪一步是知识检索、哪一步是格式转换、哪一步是工具调用再决定投入哪条路线。模型选型也跟着收窄知识问答场景优先选中文长文本理解稳定的开源基座模型格式生成场景选指令遵循好的模型Agent 场景要看工具调用能力。部署时还要考虑量化精度和显存的平衡INT4 量化能省显存但会损失一点长文本稳定性INT8 更稳但需要更大的显存。这些取舍没有标准答案只能按手头资源和业务重要程度来定。3. 金融应用落地场景拆解研报问答、摘要抽取和合规审查怎么分工3.1 文档知识问答让研报和公告变成可追索的条目金融行业里 RAG 落地最多的场景是“文档知识问答”。典型输入是几百份上市公司公告、行业研报、内部制度文件业务人员可以直接提问“这家公司 2024 年上半年海外收入占比是多少”“这份合同里划款条件改了什么”。这个场景能做成的关键是切片后的段落与问题之间存在可检索的语义关联2024 年的开源嵌入模型已经能稳定做到这一点。落地形态通常是一个内部问答入口。用户输入问题系统先做向量检索把最相关的 4 到 6 个片段捞出来再连同问题和系统提示词一起交给生成模型。前端展示答案时必须列出引用片段和出处页码这一条往往决定业务方愿不愿意用。没有引用再准的答案也被怀疑有引用错了也有地方修改。权限隔离也要提前做不同团队能看到的知识库可能不同至少要按文档来源做一层过滤。文档问答的维护量不在模型而在文档更新。每次新公告发布要触发增量更新流程把新文本切片、入库、替换旧版本。如果不做增量更新知识库会越积越旧最终回退到“模型瞎编”的状态。金融场景里知识库新鲜度比模型大小更要紧。3.2 投研辅助摘要、结构化抽取与信息关联第二类场景是把大模型当成“阅读加速器”。常见做法是对长篇研报做摘要提炼投资逻辑、风险提示和关键假设再进一步把文字段落抽取成结构化字段比如营收、净利润、同比变动、毛利率、现金流。结构化抽取的价值在于接进已有投研数据库让下游报表和预警系统能继续用。大模型的摘要能力可以大幅缩短分析师翻阅长文的时间但摘要质量需要评估不能只看流程是否跑通。这类任务更依赖提示词设计和输出约束而不是模型大小。实践中我会用 JSON Schema 做输出格式约束强制模型按固定字段返回。字段缺失时要让模型返回 null而不是凭空填一个数字。{ company_name: string, report_title: string, key_metrics: { revenue: number | null, net_profit: number | null, yoy_growth: number | null, gross_margin: number | null }, risk_factors: [string], source_page: string }因为财务字段一旦错位下游报表系统会直接跑出脏数据所以这类场景宁可模型说“不知道”不要模型“猜一个”。输出校验层要加在生成之后用正则或规则脚本检查关键字段是否符合数值格式不符合就重新生成或标记为异常。3.3 风控与合规审查从规则匹配升级到语义判断第三类场景是文本审查比如合同条款审查、舆情监测、合规问答。过去主要靠关键词规则准确率不稳同义表达一换规则就失效。大模型带来的提升在语义层面能识别“未取得销售资格即对外开展业务”和“先收款后补手续”这类变体表述也能把非结构化文本中的风险信号抽出来。在合规场景里大模型更适合做辅助初筛而不是下结论。常见部署是先用模型做粗筛把疑似有问题的段落推给人工复核复核结论再回流作为下一轮微调的训练数据。这既满足业务方对人工审核责任的要求也解决了“不信任黑匣子”的问题。输出侧要保留完整的输入文本、模型判断以及置信度信息方便回溯追责。这类项目容易被低估的部分是预处理。金融文本里大量存在扫描件和表格需要先做 OCR 和版面还原把表格转成 Markdown 或 CSV 再进入切片流程。OCR 错字会直接污染检索质量所以在预处理阶段就要做文本校对和乱码清洗否则审查覆盖面再广也是空的。第 4 章的技术方案就是面向这三类共性需求搭出来的。4. 搭建最小可运行的金融文档问答切分、嵌入、检索生成的完整参数链4.1 选型参数模型尺寸、嵌入模型和向量库怎么搭配常见做法是追求“能跑多快”和“能控多严”。对于金融内部试点比较稳的搭配是部署一个 7B 到 14B 的开源基座模型一台 24GB 显存的单机就能跑推理。嵌入模型要选中文语义理解稳定、支持归一化的开源模型。向量库选本地可跑的 FAISS 或带过滤功能的 pgvector数据量在百万级以内都能覆盖要接团队权限体系时pgvector 更合适因为可以 SQL 过滤文档来源。环节推荐方向说明生成模型7B/14B 中文长文本模型24GB 显存可推理金融场景不盲目追最大参数嵌入模型bge 等中文语义嵌入支持归一化检索效果比维度大小更重要向量库FAISS / pgvector单机原型 FAISS需要权限过滤换 pgvector分块大小500800 字中文场景太大丢定位太小丢语义召回数 k46 个片段太少漏信息太多稀释上下文注意模型尺寸不只看显存要看任务。14B 在长文本归纳上比 7B 明显更稳但推理速度也慢将近一倍。先在小规模语料上验证效果再决定是否换更大的模型不要一开始就上最大参数。4.2 切分与入库实现分块大小和重叠是召回的第一道闸门金融文档的结构通常是有序的标题、段落、表格、注释。切片最怕两件事把一段完整因果关系切开把标题和正文分离。下面是常用的切分方式把粗粒度分隔符和长度限制结合起来优先按自然段落切再用长度兜底。from langchain.text_splitter import RecursiveCharacterTextSplitter # 金融研报最稳的是“段落优先、长度兜底”切分 splitter RecursiveCharacterTextSplitter( chunk_size800, # 单块目标长度中文场景500~800字召回最稳 chunk_overlap120, # 重叠用于缓解“切断句意”带来的损失 separators[\n\n, \n, 。, , , ], keep_separatorTrue, ) # pdf_text 已经由 PDF 解析器抽取为纯文本 chunks splitter.split_text(pdf_text) print(f得到 {len(chunks)} 个片段平均 {sum(map(len, chunks)) // len(chunks)} 字)先按双换行切自然段再按句号、分号补切重叠 120 字保证被切断的句意至少有一部分落在相邻块里。chunk_size 不能拍脑袋金融问题喜欢跨段落比较块太小导致单个块形不成完整语义块太大又让向量检索精度下降。实践上研报用 800 字、合同条文用 500 字更合适因为合同条款本身结构短切大块反而把不同条款混在一起。切片之后不要急着入库先抽查一批片段确认标题没有单独成块、表格没有被拆散。表格类内容建议单独提取按行列转成文本或保留 Markdown 格式否则向量化之后表格语义会丢失。对于多页 PDF还要在片段里保留页码和来源文件字段这是后续引用溯源的基础。4.3 嵌入与向量入库归一化和索引是要点from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) # 文本入库并保存到本地保证金融数据不出内网 vectorstore FAISS.from_texts( textschunks, embeddingembedding_model, ) vectorstore.save_local(./finance_rag_index)归一化打开后余弦相似度和内积等价召回结果更稳定。嵌入模型的选择要用自己场景里的真实问题去检验而不是看公开榜单实测中 bge 系列在中文金融文档上表现不错但换一个行业就可能出现明显偏差。save_local 只适合单机原型多人协作时建议换成 pgvector 或 Milvus并加上文档来源字段做权限过滤。4.4 检索与生成temperature 和 top_k 要一起调from langchain_community.llms import Ollama from langchain.chains import RetrievalQA llm Ollama( modelqwen2.5:14b, temperature0.1, num_ctx8192, ) qa RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue, ) question 这家公司2024年主营业务收入构成有什么变化 resp qa.invoke(question) print(resp[result]) for doc in resp[source_documents]: print(引用, doc.page_content[:100])k 设为 4让生成模型拿到 3 到 5 个片段互相补充又不互相稀释。温度 0.1 是金融场景的常用值再低显得机械再高容易放开约束开始自由发挥。num_ctx 要大于所有片段加问题加提示词的总长度否则生成阶段会直接截断。检索出的片段里混入不相关信息时先检查提示词是否明确写了“只依据给定上下文回答没有依据就说不知道”。这一句话往往比换更大的模型更管用。5. 排查与避坑金融大模型项目中最容易翻车的5个环节5.1 检索到了答案照样编RAG幻觉的边界比想象的宽现象检索返回的片段里明明有正确数据生成的答案却把数值写错甚至把“同比增长”说成“环比增长”。原因检索和生成是两条独立链路生成阶段只拿到片段模型在组织文本时为了“说得顺”会自行补全数值和逻辑。解决把温度压到 0.1 以下并在提示词里强制要求“只回答片段中存在的数值缺失时明确说不知道”。更硬的方案是在生成后加一层数值校验把片段中的数字与答案中的数字做比对不一致就拦截。金融场景里这类校验脚本成本很低价值却很大。5.2 切分把句子腰斩召回不到完整事实现象文档里明明有一整段主营业务收入说明检索时却只召回后半截模型给出的理由对不上号。原因固定长度切分在段落中间下手把一句完整因果拆成两半向量只带着一半信息入库召回自然偏差。解决切分优先用结构分隔符先按标题和段落切再补长度控制表格和脚注单独处理。验证时做一个“召回率抽样脚本”把每个问题对应的前 3 个片段打出来人工扫一遍几轮就能暴露切分问题。5.3 上下文窗口用完了长问题直接降智现象问题本身不长但片段加提示词一拼接生成模型开始重复输出或者丢掉了之前已经给出的观点。原因片段数量多、每个片段又长加上系统提示词里的示例累计 token 数逼近 num_ctx 上限模型在长序列上注意力衰减。解决先算预算给最终答案留 1000 token 左右其余分配给片段召回数设为 4单块控制在 500 到 800 字。如果答案长度需求大就上调 num_ctx同时把单块长度往下压保证总 token 不超限。5.4 数据不出内网和安全约束打架现象团队想用商用 API 快速验证但客户要求文本不能离开内网。原因金融数据安全边界把外部 API 直接堵死不是技术选型问题是项目能不能立项的前提。解决把演示环境切到单机本地部署嵌入模型和生成模型都跑在内网向量库不暴露公网端口敏感字段在切片前先做脱敏。所有一体机方案本质都是这套逻辑差别只是谁来运维。启动任何项目前先确认数据边界再决定模型部署形态顺序不能反。5.5 业务方不认可输出因为验收指标没对齐现象工程师说“准确率 90%”业务方不信因为抽查几题就发现了硬伤。原因准确率定义和业务口径不一致。业务方更关心的是“这个结论有没有依据”“我回哪里能找到原文”。解决验收标准里同时放三个维度的指标答案相关性、忠实度、引用命中率。让业务方直接标注一小批测试集把模型输出和原文并列展示确认引用是否真的支撑了答案。指标可以自动化计算但前提是测试集来自业务真实问题而不是工程师自己编的。6. 投入前的验证用三个指标让业务方认可大模型产出6.1 从人工印象到可复测的三项指标我习惯在项目启动第二周就拉一个 30 到 50 题的评测集题目来源是业务人员自己提的真实问题。指标只盯三个答案相关性、忠实度、引用命中率。忠实度是金融里最该卡死的项它衡量答案是否忠于引用片段低于 0.8 就要回溯片段拼接逻辑和提示词设计。答案相关性衡量模型是否答在了问题上引用命中率衡量检索环节有没有返回真正有用的段落这两项卡的是 RAG 管线的两端。评测不用全自动化可以让业务方对答案打分也可以在生成结果里随机抽样做人工复核。关键在于跑分过程可复现避免“今天感觉不错、明天换个语料就崩”的印象流验收。基线分数落定后后续每一次调整模型、切分参数或提示词都往同一套测试集上回测对比分数变化。6.2 下一阶段的路径从单点问答走向Agent编排验证通过后再谈扩展。常见进阶路径是把 RAG 问答能力封装成内部服务再叠加工具调用让模型去查行情接口、取数据库字段最后汇总生成日报。每一步增加一个新工具就回来重跑那 50 题评测集防止能力叠加后反而伤害原有准确率。个人经验是工具调用带来的失效模式比 RAG 更多比如模型拿到了正确工具但给了错误参数这种情况只能靠大量样例积累去校准。我自己遇到新场景时会先用 5 天搭一个最小管道再用 50 道真问题跑基线分达不到门槛就不往生产走。这个习惯帮我挡掉了不少“听起来很美”的项目。验证指标过关才谈得上部署和推广否则再大的模型也只是演示壳。这一套方法不一定最省事但能让金融场景的落地从“探索”变成“可控交付”。希望帮到你。本文还有配套的精品资源点击获取