企业官网建设流程全解析

简介：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": f"Bearer {api_key}"} resp = requests.post(f"{api_url}/chat/completions", json=payload, headers=headers, timeout=60) 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 的秩（金融文本我用 r=8 起步）、学习率（1e-4 到 2e-4 范围）、训练轮数（1~3 轮，防止把意图记忆死）。微调不是万能的，它改变的是表达能力和知识边界内的稳定性，改不了模型不知道的事实，所以微调之后依旧要接检索。实际操作中，我习惯把“微调前后各跑 100 条评测集”作为验收门槛，否则很难判断训练到底改善了哪一类错误。

2.4 私有化部署的边界：GPU 规模、并发与投产成本

当数据不能出域，或者机构要求“模型必须部署在自有基础设施上”时，就进入私有化部署。常见方案是拿开源权重（如 Qwen、Llama、DeepSeek 系列）在本地 GPU 上跑推理，再用 vLLM、Ollama 这类推理框架对外提供接口。预算评估最容易翻车的地方是把“模型参数量”当作唯一指标，实际上真正决定硬件的是并发和响应时间。下面这张表是我在做资源估算时常用的粗算口径。

表格里的数字是按常见开源模型的 int8 量化经验估算的，具体以你手上模型的实测为准。我的经验是：先用 20 并发压测真实请求，看 TP99，再决定买几台机器；一味堆 70B 大模型很容易让预算翻倍，而金融问答里大部分请求其实用 14B 级模型加好的检索就够了。选什么参数量级的模型才算“够用”，标准不是参数大小，而是评测集上的通过率。

3. 金融文档问答的最小实现：文档切片、向量检索与引用生成

金融领域最常见的第一个 POC 是“内部制度文档问答”：把几十份 PDF/Word 制度文件放进一个问答系统，员工用自然语言问“对公客户授信额度审批需要哪些材料”，系统给出答案并标明出处。这个 POC 的完整链路包括文档解析、切片、向量化、入库、检索、生成和引用展示，下面按落地顺序拆开讲。

3.1 文档解析与切片：切得不好，检索效果差一半

第一步是解析文档。制度文件多为 PDF 和 Word，PDF 里又有扫描件和电子版之分，扫描件要先做 OCR，电子版直接用解析库提取文本。我一般先把所有文档统一转成纯文本，再做清洗，去掉页眉页脚、目录和重复空白。切片是一个容易被低估的环节：切得太大导致检索命中后上下文混杂无关内容，切得太小又让跨段信息断裂。常见做法是按“标题层级 + 段落 + 字符数”混合切片，先按标题拆出章节，再对过长章节按固定长度切。

import re def split_document(text, chunk_size=512, overlap=64): # 按 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_size=512 和 overlap=64 是起步值，不是最优值。金融制度文档建议 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_url="http://localhost:8000/v1", api_key="local") # 本地推理服务的 OpenAI 兼容端口 def embed_texts(texts): resp = client.embeddings.create(model="bge-large-zh", input=texts) return [item.embedding for item in resp.data] # 建立集合并写入切片 collection = chromadb.Client().get_or_create_collection("fin_regulation") collection.add( ids=[f"chunk_{i}" for i in range(len(chunks))], documents=chunks, metadatas=[{"source": "授信管理制度.pdf", "section": "第四章"} for _ in chunks], embeddings=embed_texts(chunks) ) def retrieve(query, top_k=8, threshold=0.5): res = collection.query(query_texts=[query], n_results=top_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"[{i+1}] 来源：{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", encoding="utf-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 模型和混合检索权重；召回到位但答案不对，再改 prompt；prompt 稳定后仍有格式问题，才考虑微调。大模型上下文长度也是一个常被忽略的因素：如果检索出的 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 预答 + 人工确认”，确认数据通过反馈接口回流到评测集，成为下一轮优化的素材。这样的设计让系统在任何时刻都可以回退到纯人工模式，团队不会因为一次坏案例而陷入被动。

我自己的习惯是，把“能不能回滚”当作比“效果多两个点”更优先的决策依据。金融系统出一次错，代价不只是算力损耗；用户信任一旦受影响，再好的模型也很难挽回。希望这篇文章里的路线拆解和踩坑记录能帮你少走一段弯路，让你在推进大模型金融应用的时候，能把更多精力放在真正有价值的业务问题上，而不是被工程细节反复绊倒。

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