简介：《财务分析智能化：中小券商部署DeepSeek实现研报自动生成的架构设计》是一份面向券商数字化转型场景的技术方案文档，适合金融IT架构师、数据分析师及关注大模型落地的读者，主要解决中小券商在财务分析效率、研报生成质量与人力成本之间的平衡问题。文件为1个PDF，大小2.08MB，共31页，已有71人学习。文档从传统财务分析模式与研报生成流程的痛点切入，结合DeepSeek在自然语言处理与金融知识融合上的优势，系统阐述了研报自动生成的整体架构设计。内容涵盖数据层的数据采集与预处理、模型层的选型与微调、服务层的模块划分、应用层的功能设计，并针对数据质量、模型可解释性、系统安全等技术挑战给出了应对思路，同时包含案例分析与效果评估。整体条理清晰、目录完整，既有理论框架又有落地路径，可作为中小券商部署AI研报系统的参考方案。
1. 财务分析智能化不等于上大模型：中小券商先想清楚研报自动生成的边界
券商研究所做一份个股点评报告，常规流程是先从公告、财报、行业数据里抽取关键指标，再按固定模板填公司概况、财务分析、盈利预测和风险提示。真正需要研究员做判断的部分占比不高，大量工时消耗在数据搬运和格式套用上。中小券商的问题更具体：预算买不起千卡集群，合规要求数据不能出域，直接调用公有云 API 既难审计又难追溯。把 DeepSeek 的开源权重模型做私有化部署，围绕研报自动生成设计一套架构，是目前验证最多、也最贴合监管预期的路线。下文不讨论算法创新，按一份能落地的架构设计来讲：模型放在哪一层、推理服务怎么起、财务数据如何进入上下文、生成结果如何兜底。
2. 中小券商部署 DeepSeek 的架构层次与模型选型
2.1 三层架构：数据接入、模型推理、应用编排
多数中小券商一开始就想上分布式架构设计，动不动三集群起手，结果没有专职平台团队，模型服务反而成了孤岛。我一般建议按三层最小闭环来设计，每一层职责单一、可以独立扩容。
- 数据接入层：连接行情源、财报解析服务、公告爬虫、投研数据库，统一产出标准化的财务指标文件和可检索文本切片。
- 模型推理层：DeepSeek 权重部署在 GPU 内网，由 vLLM 或同类推理引擎提供 OpenAI 兼容接口。
- 应用编排层：运行研报生成、RAG 检索、合规检查等容器化服务，对外只暴露内部 API。
这三层之间通过内部 HTTP 调用，不跨网段，数据不出内网，符合中小券商的风控预期。模型后续更换时（从 DeepSeek 换其他开源模型），数据接入层和应用编排层都不需要重构，这是架构设计里最重要的一条解耦原则。团队如果只有两三个人，应用编排层也可以先用 Dify 这类低代码平台承接，但要把 RAG 检索和审计日志外置，避免被平台绑定。
2.2 模型选型：为什么不建议直接部署 DeepSeek-V3
DeepSeek-V3 是 671B 的 MoE 模型，单次推理激活参数约 37B，但完整权重加载仍需要 700GB 以上显存，FP8 量化后也要多张 80GB 显卡才能稳定跑出可用性能。这个规格对头部机构不构成压力，对中小券商却是实打实的预算与机房限制。常见做法是退一步选 DeepSeek-R1 蒸馏系列：DeepSeek-R1-Distill-Qwen-32B 或 14B。前者在财务推理、结构化输出上接近可用线，后者适合预算更紧、GPU 只有一块的场景。
选型还要看一个指标：研报自动生成是“长文本 + 结构化 + 数值准确”的任务，不是开放对话。R1 蒸馏版保留的推理能力可以用在“计算同比、环比增长”这类需要链式推导的步骤，但推理 token 会拖慢首 token 延迟。生产环境我一般按任务分离：做财务推算时开启 thinking，做报告正文生成时关闭 thinking，只保留普通补全能力。这里需要实施团队在推理框架层做一层开关控制，而不是换两套模型。
2.3 vLLM 部署 DeepSeek 的最小命令
以 DeepSeek-R1-Distill-Qwen-32B 为例，最小可用部署命令如下：
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name deepseek-report \ --port 8000参数说明：
--tensor-parallel-size 1：单卡启动。如果使用两张 24GB 显卡，改为2，vLLM 会自动做张量并行。--max-model-len 32768：把最大序列长度限制为 32K token。研报生成场景单次输出通常不超过 8K，限制长度能显著降低显存占用，避免 OOM。--gpu-memory-utilization 0.92：允许 vLLM 使用 92% 显存，剩余留给 CUDA context 和运行时开销。--served-model-name deepseek-report：给客户端用的模型别名。后续换模型时别名不变，应用层零改动。
如果 GPU 显存在 16GB 以下，可以先试用 Ollama 做本地部署验证流程，但生产不推荐：Ollama 对并发请求和动态 batching 的控制不如 vLLM 精细，在研报这类长输出任务上显存利用率偏低。
模型启动后，用 OpenAI SDK 验证连接：
from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="sk-local") resp = client.chat.completions.create( model="deepseek-report", messages=[{"role": "user", "content": "请提取以下财务数据中的营业收入和同比增速"}], temperature=0.2 ) print(resp.choices[0].message.content)api_key传任意值即可，vLLM 默认不校验，生产环境要换成网关鉴权。
2.4 架构组成与职责边界
| 层 | 运行组件 | 部署位置 | 关键依赖 |
|---|---|---|---|
| 数据接入层 | 财报解析、公告结构化 | 内部数据集群 | PostgreSQL / ClickHouse |
| 模型推理层 | vLLM、DeepSeek 权重 | GPU 内网 | NVIDIA 驱动 535+ |
| 应用编排层 | 研报生成 API、RAG 管道 | CPU 容器 | Redis、Elasticsearch |
| 合规审计层 | 审计日志、数据血缘 | 对象存储 | MinIO |
表里每一层都应独立扩缩容。模型推理层是唯一需要 GPU 的部分，其他层用普通服务器即可。还有一个容易被忽略的点：GPU 机器不要混部署其他业务，否则显存分片后相互干扰，单任务的生成速度会明显下降。
提示：显存紧张时不要手动把
--gpu-memory-utilization调得过低，vLLM 会在请求到来时自动回收空闲显存，预留太多反而缩小了动态批处理窗口。
3. 研报自动生成的管线实现：RAG、提示词与结构化输出
3.1 财务数据如何进入 DeepSeek 的上下文
证券公司的财报和公告以 PDF 为主，直接让大模型生成研报，它一定会编数字。原因是大模型没有实时数据，训练时点之后的新公告、更正数据它看不到。中小券商默认的兜底方案是做 RAG：先把财务数据转成文本块，再检索到提示词中，模型只负责基于检索结果写作。
一个最小可用的数据块设计如下表：
| 字段 | 内容 | 示例 |
|---|---|---|
| chunk_id | 唯一标识 | 2024Q3-600519-表3 |
| source | 来源文件 | 贵州茅台2024年三季报.pdf |
| section | 章节 | 主要财务指标 |
| content | 文本 | 营业收入 1231.23亿元，同比+16.9% |
| start_line | 起始行号 | 12 |
切分策略有讲究：财报中的表格必须按表整体切块，不能按行切，否则表头与数值分离后语义断裂。段落文本按 512 token 切、重叠 64 token，这样跨段落的因果信息不会丢。向量化模型优先用 bge-m3 这类中文效果稳定的，索引库可以用 Elasticsearch 的 dense_vector 字段。中小券商不一定需要单独搭 Milvus，ES 一个组件就能同时承担全文检索和向量检索。
3.2 研报生成提示词模板与参数设置
研报生成不能只给一句“写一篇研报”，输出结构不可控。我一般用三段式提示词：系统角色定义、检索数据、输出骨架。
你是持牌卖方研究员。根据【数据源】撰写业绩点评研报，遵守以下规则： 1. 所有数字必须能在【数据源】中找到对应值，找不到的写“不适用”； 2. 财务指标表只能输出数据源中包含的指标，禁止自行推算； 3. 出现矛盾时以最新公告为准； 4. 每条关键数据后标注来源 chunk_id。 【数据源】 {retrieved_chunks} 【输出骨架】 一、核心观点（不超过3条） 二、财务摘要（表格） 三、业务回顾（每块一段） 四、风险提示（不少于3条）调用参数建议：
| 参数 | 建议值 | 说明 |
|---|---|---|
| temperature | 0.2 | 降低随机性，保证数字一致 |
| top_p | 0.7 | 控制话题漂移 |
| max_tokens | 4096 | 覆盖多数点评报告 |
| frequency_penalty | 0.3 | 抑制术语重复堆砌 |
temperature 不建议低于 0.1。取 0.2 是因为生成财务摘要表时，模型需要一定的确定性，同时保留少数候选词处理同义表达。若调成 0，模型会反复选择 tokens，反而让长文生成出现机械重复。
3.3 结构化输出：让研报先变成 JSON 再变成文档
研报自动生成的最终产物要进入研究所后台或 OA 系统，纯文本没法接。常见做法是让模型输出 JSON，再由后处理服务转成 Word/PDF。
from openai import OpenAI import json client = OpenAI(base_url="http://localhost:8000/v1", api_key="sk-local") resp = client.chat.completions.create( model="deepseek-report", messages=[ {"role": "system", "content": "你是一个研报生成器，只输出 JSON。"}, {"role": "user", "content": prompt_text} ], temperature=0.2, max_tokens=4096, response_format={"type": "json_object"} ) data = json.loads(resp.choices[0].message.content) # 交叉验证：财务摘要字段必须能在检索源数据中找到 for item in data.get("financial_summary", []): assert item["value"] in source_values, f"数值不一致: {item['label']}"JSON 模式的逻辑是把研报拆成core_view、financial_summary、business_review、risk_warning四个字段，再由渲染服务套用内部模板生成正式研报。交叉验证放在 JSON 解析之后、渲染之前，这一步能拦截大部分数字幻觉。如果团队对 JSON 格式的稳定性不放心，可以把 response_format 去掉，在后处理时用json.loads配合异常重试一次。
4. 部署配置、成本估算与合规审计
4.1 显存估算：从一张 4090 到两卡 A800
中小券商首先要盘点现有 GPU 资源。不同规格模型所需显存差异极大，选错直接决定项目启动还是搁置。
| 模型规格 | 量化方式 | 最小显存 | 建议机器 |
|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-14B | INT4 | 8GB | 单张 RTX 4090 |
| DeepSeek-R1-Distill-Qwen-32B | FP16 | 64GB | 单张 A800 80G |
| DeepSeek-R1-Distill-Qwen-32B | AWQ INT4 | 20GB | 单张 4090 |
| DeepSeek-V3 | FP8 | 700GB+ | 不推荐 |
这里量化方式很关键。FP16 跑 32B 需要 64GB 显存，AWQ INT4 只需要约 20GB。如果机构只有一张 24GB 的 4090，用 AWQ 量化版 32B 就能运转，生成质量在研报场景几乎无损。AWQ 是 W4A16 结构，权重 4bit，激活保持 16bit，对涉及数值计算的财务指标处理比纯 INT4 GPTQ 更稳。
启动命令加上量化参数：
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B-AWQ \ --tensor-parallel-size 1 \ --quantization awq \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name deepseek-report--quantization awq会从模型目录中读取量化配置，不需要手动指定位宽，前提是模型权重本身已经是 AWQ 格式，下载时注意不要拉错分支。
4.2 吞吐与并发：先压测再扩容
研报生成不是高频交易场景，并发量很低。一个 20 人研究所，峰值同时可能只有 3-5 个生成任务。单张 4090 跑 32B AWQ，生成速度约 20-30 tokens/s，一份 3000 字研报折合约 4000 token，耗时 2-3 分钟。这个等待研究员可以接受，但不能接受的是并发任务排队导致单任务被拖到 10 分钟以上。
建议在部署后做一次简单压测，用hey或自写脚本向 vLLM 的/v1/chat/completions发请求：
hey -n 20 -c 5 -m POST -H "Content-Type: application/json" \ -d '{"model":"deepseek-report","messages":[{"role":"user","content":"写一段研报核心观点"}],"max_tokens":512}' \ http://localhost:8000/v1/chat/completions根据返回的平均延迟和 p99 延迟调整--max-num-seqs。vLLM 默认的并发批处理数 256 对单卡过高，我一般设为 16。并发设置太大时，每个请求都得等待其他请求的 token 生成完才输出，单任务的 P99 反而恶化。
4.3 合规与审计：本地部署只是起点
数据不出域是中小券商选择私有化部署 DeepSeek 的首要原因，但部署完成不等于合规闭环。审计与合规要落在生成链路的末端：
- 所有 prompt 和生成结果写审计日志，记录模型版本、提示词、raw_output、token 用量；
- 每条生成报告对应一组 RAG 数据源 chunk_id，形成可追溯信息链；
- 在报告自动生成后打上“由 DeepSeek 辅助生成，未经分析师审核不得外发”的标记。
我见过的一个失败案例是：AI 生成报告直接发给客户，结果模型不知道最新停牌公告，输出“建议持有”，酿成事故。所以流程上必须有人工审批节点，把报告状态从generated流转到reviewing，审核通过后才进入正式发布。这个审批流程不需要引入重型工作流引擎，在数据表里维护状态字段、由后台服务流转即可。
5. 验证研报生成质量：数字回验与引用回标
5.1 三层检查：数字、引用、逻辑
研报自动生成的效果不能拿对话流畅度评估，核心是数据和观点的可溯源。我的验证方式分三层。
第一层是数字核对。从生成报告里抽出所有数字，与检索源数据比对，重点检查财务摘要表内的数值是否一致。
import re def is_year(token: str) -> bool: if not re.fullmatch(r"\d{4}", token): return False return 1900 <= int(token) <= 2100 def verify_numbers(report_text: str, source_records: dict): errors = [] for num in re.findall(r"-?\d+\.?\d*[%亿元]?", report_text): # 排除“2024”这类年份 token if is_year(num): continue if num not in source_records.values(): errors.append(num) return errorssource_records.values()里放的是数据接入层产出的标准财务指标字段，营收、净利、增速、毛利率都在里面。校验出来的错误数字要按 chunk_id 反查来源，确认是模型编造还是数据源切块错误。
第二层是引用校验。检查每条引用标记是否能映射到真实数据块，比如[2024Q3-600519-表3]必须在索引库中存在。若生成时漏标，后处理直接拦截。
第三层是逻辑校验。由研究员人工抽查，重点关注观点与数据是否匹配，比如盈利预测和历史增速是否一致、风险提示是否覆盖近期公告。这一层短期无法自动化，但可以沉淀往次标注案例，后期训练轻量分类器辅助。
5.2 进阶技巧：把引用变成数据血缘
这里分享一个成本极低但收益明显的技巧：在提示词里要求模型对每条财务数据附上[来源: {chunk_id}:{行号}]标记。这样生成的报告天然自带数据血缘，审计时不需要再做额外解析对齐。
citations = re.findall(r"\[来源: (.*?)\]", report) for cite in citations: chunk_id, line_no = cite.rsplit(":", 1) check_source_exists(chunk_id, line_no) # 校验索引库中是否存在若某条引用无法通过校验，就将对应段落回退给模型重新生成，补充指令：“你引用的{chunk_id}不存在，请从数据源中重新找到正确数据后改写该段，保持其他段落不变。”这样不会破坏整体结构，还精准只修正出问题的段落。建议在研报自动生成架构上线第一天就加上这个能力，后续合规问询时，能直接回答每一条“从哪份文件、哪一行”来的。
本文还有配套的精品资源，点击获取
