简介面向中小券商数字化转型需求这份PDF完整梳理了基于DeepSeek实现研报自动生成的分层架构方案。内容从传统财务分析与研报生成痛点切入覆盖DeepSeek技术原理、金融场景应用、数据层采集与预处理、模型选型与训练、服务层接口设计、应用层功能模块并延伸至部署实施步骤、技术挑战应对与案例效果评估体系完整、逻辑清晰。资源共1个PDF文件压缩包约2.08MB正文31页文字、目录、图表均显示正常方便直接查阅。读者既可借鉴其层次化架构设计思路与模型部署方法也可参考效率、质量、业务三类评估指标为规划AI金融落地提供实操性参考。已有71人浏览学习。1. 研报从三天到三小时中小券商部署DeepSeek的架构分水岭在中小券商里研报生产长期是一条人工流水线分析师从Wind和Choice手动导数据在Excel里算指标再对着模板写文字。一份深度报告从选题到发布三到五天是常态遇到市场热点大券商两小时出点评中小券商只能看着流量流失。DeepSeek这类大语言模型出现后很多人第一时间做了demo把财报丢进去几秒钟就能生成一段像模像样的分析。但demo能跑和生产线能跑是两回事——研报要引用准确数字、要过合规审核、要对接内部数据源背后是数据层、模型层、服务层、应用层的完整架构设计。这篇架构设计拆解的正是这件事在算力和人力都有限的前提下把DeepSeek从“能聊天”推到“能出报告”覆盖部署选型、数据管线、服务封装到上线验证。适合正在做LLM落地的架构师、量化团队和券商IT负责人也值得任何在强合规行业里做文档自动生成的团队参考。2. 部署选型先于架构设计DeepSeek的API、私有化与本地化边界2.1 三种部署路径与数据合规约束在券商环境里部署方式首先不是技术偏好问题而是数据合规问题。研报草稿里往往包含未公开的客户持仓、内部评级、调研纪要这些数据一旦离开内网就是事故。所以第一步要按数据敏感度划分部署边界。部署方式数据是否出境单token成本首token延迟维护成本适用场景官方API是低低无脱敏数据测试、低敏感辅助写作专有云私有实例否中中中生产环境数据不出域本地GPU部署否低电费折旧高高高频调用、深度定制微调我见过不少团队一上来就接官方APIdemo跑得很顺等要接真实交易数据时被合规拦下整个项目返工。正确顺序是先划分数据等级再决定哪些环节走哪条部署路径。常见做法是“内外分流”公开的新闻资讯走云端API做快速摘要内部财务数据走本地或专有云实例做生成主链路。2.2 本地部署的硬件基线Ollama与vLLM的显存测算本地部署大语言模型工具链首选Ollama和vLLM。Ollama胜在零配置适合原型验证vLLM做了PagedAttention显存管理吞吐高生产环境更推荐。# 方式一Ollama 快速起服务装完就能跑 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 方式二vLLM 起生产级 OpenAI 兼容服务 pip install vllm vllm serve deepseek-ai/DeepSeek-R1-Distill-7B \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000--quantization awq启用4比特量化显存占用大约是FP16的四分之一--max-model-len 8192控制上下文窗口上限设得越大KV Cache占显存越多--gpu-memory-utilization 0.9表示允许模型吃掉90%显存留出余量给推理计算。生产环境我会用Docker封装vLLM配合Supervisor或Kubernetes做进程守护避免OOM后服务直接挂掉。模型规模量化方式预估显存最低硬件建议7Bq4_k_m约5GB单张8GB卡14Bq4_k_m约9GB单张16GB卡32Bawq约20GB单张24GB卡或双卡70Bawq约40GBA100/H100或双卡并行显存估算要留buffer7B模型q4量化虽然只要5GB但加上KV Cache和推理中间张量8GB卡跑8192上下文已经接近极限。中小券商采购时我一般建议直接上两张24GB卡32B量化模型基本覆盖所有研报场景还能余出卡做向量检索。2.3 接口抽象层用OpenAI兼容协议隔离上游模型部署方式定了之后第二件事是接口设计。常见错误是业务代码直接绑定某个厂商的SDK换个模型就要改业务层。统一走OpenAI兼容协议是当前成本最低的抽象方式。from openai import OpenAI client OpenAI( api_keyEMPTY, # 本地端点不校验占位即可 base_urlhttp://localhost:8000/v1 # vLLM 本地端点 ) resp client.chat.completions.create( modeldeepseek, messages[{role: user, content: 分析这家公司的偿债能力给出流动比率和速动比率}], temperature0.3, # 研报生成用低温减少发散 max_tokens2048 ) print(resp.choices[0].message.content)base_url指向本地vLLM服务api_key填任意值因为本地不校验。这样设计后将来切回云端API、或者接入codex风格的编码模型来生成SQL查询语句都只改base_url和model名业务层零改动。deepseek api如何调用这个问题答案就是这一套——协议统一了调用方式就统一了。3. 数据层与研报生成管线从财务数据入库到结构化输出3.1 多源财务数据的采集与统一建模研报生成的前提是数据层能把口径统一的财务数据喂给模型。中小券商常见数据源包括Wind/Choice这类商业数据库API、交易所公告、财经新闻。难点不在采集在口径统一——同一个“净利润”有合并净利润、归母净利润、扣非净利润三种口径混用会让研报数字严重失真。import pandas as pd from sqlalchemy import create_engine engine create_engine(mysqlpymysql://analyst:pass10.20.1.8:3306/research) def load_financials(ts_code: str): # 数据服务统一封装屏蔽上游 Wind/Tushare 差异 df data_service.query(income, ts_codets_code, start2020Q1) df df.rename(columns{ n_income_attr_p: np_attr_parent, # 归母净利润 total_revenue: revenue }) df.to_sql(income_statement, engine, if_existsappend, indexFalse) return df字段重命名是第一步真正要命的是上游数据库对同一指标的算法差异。所以建表时一定要把口径写进字段注释让后续调数据的分析师和模型提示词都能看到定义。CREATE TABLE income_statement ( ts_code VARCHAR(16) NOT NULL, report_date DATE NOT NULL, revenue DECIMAL(20,2), net_profit DECIMAL(20,2), np_attr_parent DECIMAL(20,2) COMMENT 归母净利润, gross_margin DECIMAL(8,4), source VARCHAR(32), updated_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (ts_code, report_date, source) ) ENGINEInnoDB;复合主键(ts_code, report_date, source)防止同一来源的重复数据反复入库source字段标识数据来自哪家供应商排查口径差异时能快速定位是哪个源出了问题。3.2 数据清洗缺失值、复权处理与公告去重数据层的脏数据比模型幻觉还可怕因为模型会一本正经地把错数字写进研报。清洗流程里最常踩的坑有三个缺失值、除权除息、重复公告。问题现象处理方案缺失值部分季度指标为空按时间前向填充并打标记或丢弃该指标除权除息股价、每股指标跳变用复权因子统一为后复权口径口径不一净利润混淆合并/归母/扣非拆分独立字段提示词中强制声明口径重复公告同一财报被多个爬虫任务抓取按 ts_codereport_datetitle 去重# 除权除息处理用后复权价做收益率计算 def adjust_price(df: pd.DataFrame, factor_col: str adj_factor) - pd.DataFrame: df[close_adj] df[close] * df[factor_col] # 后复权价格 df[return] df[close_adj].pct_change() # 对数/算数收益率 return df后复权处理的关键是adj_factor复权因子的算法必须和上游数据商保持一致否则算出来的收益率曲线在除权日会出现假跳变。清洗完的数据我习惯落一份parquet快照方便后面回溯“这个数字在哪个版本的数据里是对的”。3.3 RAG与提示词工程让DeepSeek引用数据而不是编造大模型生成研报最大的风险是幻觉——它会用合理的语气编造不存在的营收数字。解决手段不是靠提示词里写“不要编造”而是RAG先把财报和公告切片入库生成时先检索再让模型基于检索到的片段作答。from sentence_transformers import SentenceTransformer import chromadb model SentenceTransformer(BAAI/bge-large-zh-v1.5) client chromadb.PersistentClient(path./report_index) col client.get_or_create_collection(financial_docs) def index_report(text: str, meta: dict, chunk_size768, overlap96): # 按长度切片overlap 避免切断语义完整句 chunks [text[i:i chunk_size] for i in range(0, len(text), chunk_size - overlap)] ids [f{meta[doc_id]}_{i} for i in range(len(chunks))] col.add( idsids, embeddingsmodel.encode(chunks).tolist(), documentschunks, metadatas[meta] * len(chunks) )chunk_size768对中文财报段落比较合适太短截断财务逻辑太长检索噪声大overlap96保证被切开的句子在相邻片段里都能完整出现。生成时的提示词模板我一般固定成以下结构你是券商研究员。基于以下检索片段撰写分析禁止使用片段之外的具体数字。 片段 {context} 任务分析该公司盈利能力输出结构化内容 1. key_metrics关键财务指标及数值 2. analysis250字以内的分析段落 3. risk风险提示三条以内生成时temperature0.2低温让模型更贴近检索片段减少自由发挥。输出要求结构化方便下游落库、审核和比对数字。RAG检索的top_k我建议取5到8太少覆盖不全太多会把不相关片段塞进上下文干扰生成。4. 服务层与应用层落地接口设计、监控与审核闭环4.1 服务层三大模块与FastAPI实现服务层是数据层和模型层之间的桥梁拆三个模块最干净数据服务模块负责对外提供统一取数接口模型调用服务模块负责封装LLM推理和RAG检索报告生成服务模块负责编排整个生成流程、落库和状态管理。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class ReportRequest(BaseModel): ts_code: str template: str 深度报告 # 模板类型决定提示词结构 with_risk: bool True # 是否输出风险提示段落 app.post(/api/v1/report/generate) async def generate_report(req: ReportRequest): # 1. 数据服务模块取财务数据 fin data_service.get_financials(req.ts_code) # 2. 检索服务模块取相关公告与新闻片段 ctx retrieval_service.search(f{req.ts_code} {req.template}) # 3. 模型服务模块组装提示词并调用 DeepSeek content llm_service.generate(fin_summaryfin, contextctx, templatereq.template) # 4. 报告服务模块落库返回草稿 ID 便于后续编辑与审核 draft_id report_service.save(req.ts_code, content) return {draft_id: draft_id, status: draft}接口设计上要保证幂等性同一个ReportRequest重复提交生成的draft_id应该相同。做法是以ts_code 模板 日期做业务键重复请求直接返回已有草稿避免分析师前端重试时产生多份重复报告。with_risk独立成参数是因为部分场景比如盘中快评不需要完整风险提示拆出来能减少不必要的token消耗。4.2 模型服务的性能监控与容错LLM服务和传统API的监控维度完全不同。除了常规的错误率还要盯首token延迟和token吞吐这两个指标直接决定分析师的使用体感。指标含义阈值建议p50/p95首token延迟用户从发起到看到首个字的耗时p95小于5秒token吞吐每秒生成token数影响成本按预算折算单次生成成功率完整生成不中断的比例大于99%RAG上下文命中率检索片段被模型实际引用的比例大于85%import time import logging logger logging.getLogger(llm_gateway) async def llm_with_monitor(prompt: str, max_tokens: int 2048): t0 time.time() try: resp await llm_client.chat(prompt, max_tokensmax_tokens, timeout120) duration (time.time() - t0) * 1000 logger.info({ event: llm_call, tokens: resp.usage.total_tokens, latency_ms: duration, status: ok }) return resp except TimeoutError: logger.error({event: llm_call, status: timeout, latency_ms: 120000}) raise HTTPException(503, 模型服务超时请稍后重试)120秒超时是因为深度报告的一次完整生成可能涉及数千token超时后前端要能明确感知“任务失败”而不是无限转圈。重试策略用指数退避第一次等2秒重试第二次4秒最多三次如果vLLM里有加载备用小模型可以考虑降级到7B模型先出一版简评保证业务不中断。监控上报建议直接对接Prometheus把上面的logger结构化字段转成metrics配合Grafana做可视化。4.3 应用层三类角色与人工审核闭环研报自动生成不能全自动必须有“人在回路”。应用层按角色拆成分析师、管理层、客户三类视图越界访问在接口层就要拦截。角色主要操作数据权限分析师编辑草稿、核对数据、提交审核本人及团队数据源管理层审核发布、统计工作量全量草稿与报告客户只读查看已发布研报已发布且已授权报告报告状态机用五态就够了draftAI生成草稿、editing分析师修改中、under_review提交审核、published发布、archived归档。权限用RBAC模型/api/v1/report/generate只对分析师角色开放管理层只有/pending_review的读权限客户端的/published接口按客户订阅关系过滤数据。审核这一步不能省它既是质量闸门也是合规要求的落地载体。5. 上线后的验证与调优用评测集守住研报质量下限研报质量评估不能靠“感觉这段写得好”要落到可量化的评测集上。上线前我建议先构建一个50到100条的评测集覆盖三类场景财报解读、行业点评、突发公告点评。每条评测样本包含原始数据、检索片段、人工撰写的基准答案以及抽取出的关键数字集合。评分维度我最看重三个数字正确性——生成文本中的每个具体数字都能在源数据中找到对应逻辑一致性——结论与论据不矛盾比如营收下滑就不该得出“成长强劲”的结论合规表述——不出现承诺性收益、不泄露未公开信息。数字正确性权重最高因为这是硬伤一票否决。import re def verify_numbers(text: str, source_df) - list: 从生成文本中抽取数字与源数据比对返回不一致项 errors [] for num in re.findall(r\d\.?\d*%?, text): # 数字可能带百分号需要统一口径解析 if not is_in_source(num, source_df): errors.append(num) return errorsis_in_source的匹配逻辑是先判断数字是否带百分号再在源数据对应字段里查是否存在相同数值。为了防止浮点精度问题比较时用“绝对值误差小于0.01”而不是严格相等。校验不通过的生成结果直接拦截进人工修改队列不让它流到审核环节。评测集真正的作用是挡住提示词回归。每次改模板、调参数先跑一遍评测集看数字错误率和逻辑不一致数有没有上升。我经历过一次“温度从0.2调到0.5后研报文采变好但数字错误率翻倍”的回归没有评测集根本发现不了。RAG参数也按评测集调chunk_size在512和1024之间对比top_k从5调到10哪个组合数字错误率最低就锁哪个。线上运行阶段每周抽10篇已发布研报重新跑数字校验错误率超过1%就要回溯是数据层更新出了问题还是提示词被改过。最后还有一个实用技巧生成端到端埋一个source_ref字段让模型在每个关键数字后面输出对应的检索片段ID这样分析师核数时一键跳转到原始出处把核数时间从半小时压缩到三分钟。本文还有配套的精品资源点击获取 中小券商用DeepSeek搭建研报自动生成架构实战
简介面向中小券商数字化转型需求这份PDF完整梳理了基于DeepSeek实现研报自动生成的分层架构方案。内容从传统财务分析与研报生成痛点切入覆盖DeepSeek技术原理、金融场景应用、数据层采集与预处理、模型选型与训练、服务层接口设计、应用层功能模块并延伸至部署实施步骤、技术挑战应对与案例效果评估体系完整、逻辑清晰。资源共1个PDF文件压缩包约2.08MB正文31页文字、目录、图表均显示正常方便直接查阅。读者既可借鉴其层次化架构设计思路与模型部署方法也可参考效率、质量、业务三类评估指标为规划AI金融落地提供实操性参考。已有71人浏览学习。1. 研报从三天到三小时中小券商部署DeepSeek的架构分水岭在中小券商里研报生产长期是一条人工流水线分析师从Wind和Choice手动导数据在Excel里算指标再对着模板写文字。一份深度报告从选题到发布三到五天是常态遇到市场热点大券商两小时出点评中小券商只能看着流量流失。DeepSeek这类大语言模型出现后很多人第一时间做了demo把财报丢进去几秒钟就能生成一段像模像样的分析。但demo能跑和生产线能跑是两回事——研报要引用准确数字、要过合规审核、要对接内部数据源背后是数据层、模型层、服务层、应用层的完整架构设计。这篇架构设计拆解的正是这件事在算力和人力都有限的前提下把DeepSeek从“能聊天”推到“能出报告”覆盖部署选型、数据管线、服务封装到上线验证。适合正在做LLM落地的架构师、量化团队和券商IT负责人也值得任何在强合规行业里做文档自动生成的团队参考。2. 部署选型先于架构设计DeepSeek的API、私有化与本地化边界2.1 三种部署路径与数据合规约束在券商环境里部署方式首先不是技术偏好问题而是数据合规问题。研报草稿里往往包含未公开的客户持仓、内部评级、调研纪要这些数据一旦离开内网就是事故。所以第一步要按数据敏感度划分部署边界。部署方式数据是否出境单token成本首token延迟维护成本适用场景官方API是低低无脱敏数据测试、低敏感辅助写作专有云私有实例否中中中生产环境数据不出域本地GPU部署否低电费折旧高高高频调用、深度定制微调我见过不少团队一上来就接官方APIdemo跑得很顺等要接真实交易数据时被合规拦下整个项目返工。正确顺序是先划分数据等级再决定哪些环节走哪条部署路径。常见做法是“内外分流”公开的新闻资讯走云端API做快速摘要内部财务数据走本地或专有云实例做生成主链路。2.2 本地部署的硬件基线Ollama与vLLM的显存测算本地部署大语言模型工具链首选Ollama和vLLM。Ollama胜在零配置适合原型验证vLLM做了PagedAttention显存管理吞吐高生产环境更推荐。# 方式一Ollama 快速起服务装完就能跑 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 方式二vLLM 起生产级 OpenAI 兼容服务 pip install vllm vllm serve deepseek-ai/DeepSeek-R1-Distill-7B \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000--quantization awq启用4比特量化显存占用大约是FP16的四分之一--max-model-len 8192控制上下文窗口上限设得越大KV Cache占显存越多--gpu-memory-utilization 0.9表示允许模型吃掉90%显存留出余量给推理计算。生产环境我会用Docker封装vLLM配合Supervisor或Kubernetes做进程守护避免OOM后服务直接挂掉。模型规模量化方式预估显存最低硬件建议7Bq4_k_m约5GB单张8GB卡14Bq4_k_m约9GB单张16GB卡32Bawq约20GB单张24GB卡或双卡70Bawq约40GBA100/H100或双卡并行显存估算要留buffer7B模型q4量化虽然只要5GB但加上KV Cache和推理中间张量8GB卡跑8192上下文已经接近极限。中小券商采购时我一般建议直接上两张24GB卡32B量化模型基本覆盖所有研报场景还能余出卡做向量检索。2.3 接口抽象层用OpenAI兼容协议隔离上游模型部署方式定了之后第二件事是接口设计。常见错误是业务代码直接绑定某个厂商的SDK换个模型就要改业务层。统一走OpenAI兼容协议是当前成本最低的抽象方式。from openai import OpenAI client OpenAI( api_keyEMPTY, # 本地端点不校验占位即可 base_urlhttp://localhost:8000/v1 # vLLM 本地端点 ) resp client.chat.completions.create( modeldeepseek, messages[{role: user, content: 分析这家公司的偿债能力给出流动比率和速动比率}], temperature0.3, # 研报生成用低温减少发散 max_tokens2048 ) print(resp.choices[0].message.content)base_url指向本地vLLM服务api_key填任意值因为本地不校验。这样设计后将来切回云端API、或者接入codex风格的编码模型来生成SQL查询语句都只改base_url和model名业务层零改动。deepseek api如何调用这个问题答案就是这一套——协议统一了调用方式就统一了。3. 数据层与研报生成管线从财务数据入库到结构化输出3.1 多源财务数据的采集与统一建模研报生成的前提是数据层能把口径统一的财务数据喂给模型。中小券商常见数据源包括Wind/Choice这类商业数据库API、交易所公告、财经新闻。难点不在采集在口径统一——同一个“净利润”有合并净利润、归母净利润、扣非净利润三种口径混用会让研报数字严重失真。import pandas as pd from sqlalchemy import create_engine engine create_engine(mysqlpymysql://analyst:pass10.20.1.8:3306/research) def load_financials(ts_code: str): # 数据服务统一封装屏蔽上游 Wind/Tushare 差异 df data_service.query(income, ts_codets_code, start2020Q1) df df.rename(columns{ n_income_attr_p: np_attr_parent, # 归母净利润 total_revenue: revenue }) df.to_sql(income_statement, engine, if_existsappend, indexFalse) return df字段重命名是第一步真正要命的是上游数据库对同一指标的算法差异。所以建表时一定要把口径写进字段注释让后续调数据的分析师和模型提示词都能看到定义。CREATE TABLE income_statement ( ts_code VARCHAR(16) NOT NULL, report_date DATE NOT NULL, revenue DECIMAL(20,2), net_profit DECIMAL(20,2), np_attr_parent DECIMAL(20,2) COMMENT 归母净利润, gross_margin DECIMAL(8,4), source VARCHAR(32), updated_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (ts_code, report_date, source) ) ENGINEInnoDB;复合主键(ts_code, report_date, source)防止同一来源的重复数据反复入库source字段标识数据来自哪家供应商排查口径差异时能快速定位是哪个源出了问题。3.2 数据清洗缺失值、复权处理与公告去重数据层的脏数据比模型幻觉还可怕因为模型会一本正经地把错数字写进研报。清洗流程里最常踩的坑有三个缺失值、除权除息、重复公告。问题现象处理方案缺失值部分季度指标为空按时间前向填充并打标记或丢弃该指标除权除息股价、每股指标跳变用复权因子统一为后复权口径口径不一净利润混淆合并/归母/扣非拆分独立字段提示词中强制声明口径重复公告同一财报被多个爬虫任务抓取按 ts_codereport_datetitle 去重# 除权除息处理用后复权价做收益率计算 def adjust_price(df: pd.DataFrame, factor_col: str adj_factor) - pd.DataFrame: df[close_adj] df[close] * df[factor_col] # 后复权价格 df[return] df[close_adj].pct_change() # 对数/算数收益率 return df后复权处理的关键是adj_factor复权因子的算法必须和上游数据商保持一致否则算出来的收益率曲线在除权日会出现假跳变。清洗完的数据我习惯落一份parquet快照方便后面回溯“这个数字在哪个版本的数据里是对的”。3.3 RAG与提示词工程让DeepSeek引用数据而不是编造大模型生成研报最大的风险是幻觉——它会用合理的语气编造不存在的营收数字。解决手段不是靠提示词里写“不要编造”而是RAG先把财报和公告切片入库生成时先检索再让模型基于检索到的片段作答。from sentence_transformers import SentenceTransformer import chromadb model SentenceTransformer(BAAI/bge-large-zh-v1.5) client chromadb.PersistentClient(path./report_index) col client.get_or_create_collection(financial_docs) def index_report(text: str, meta: dict, chunk_size768, overlap96): # 按长度切片overlap 避免切断语义完整句 chunks [text[i:i chunk_size] for i in range(0, len(text), chunk_size - overlap)] ids [f{meta[doc_id]}_{i} for i in range(len(chunks))] col.add( idsids, embeddingsmodel.encode(chunks).tolist(), documentschunks, metadatas[meta] * len(chunks) )chunk_size768对中文财报段落比较合适太短截断财务逻辑太长检索噪声大overlap96保证被切开的句子在相邻片段里都能完整出现。生成时的提示词模板我一般固定成以下结构你是券商研究员。基于以下检索片段撰写分析禁止使用片段之外的具体数字。 片段 {context} 任务分析该公司盈利能力输出结构化内容 1. key_metrics关键财务指标及数值 2. analysis250字以内的分析段落 3. risk风险提示三条以内生成时temperature0.2低温让模型更贴近检索片段减少自由发挥。输出要求结构化方便下游落库、审核和比对数字。RAG检索的top_k我建议取5到8太少覆盖不全太多会把不相关片段塞进上下文干扰生成。4. 服务层与应用层落地接口设计、监控与审核闭环4.1 服务层三大模块与FastAPI实现服务层是数据层和模型层之间的桥梁拆三个模块最干净数据服务模块负责对外提供统一取数接口模型调用服务模块负责封装LLM推理和RAG检索报告生成服务模块负责编排整个生成流程、落库和状态管理。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class ReportRequest(BaseModel): ts_code: str template: str 深度报告 # 模板类型决定提示词结构 with_risk: bool True # 是否输出风险提示段落 app.post(/api/v1/report/generate) async def generate_report(req: ReportRequest): # 1. 数据服务模块取财务数据 fin data_service.get_financials(req.ts_code) # 2. 检索服务模块取相关公告与新闻片段 ctx retrieval_service.search(f{req.ts_code} {req.template}) # 3. 模型服务模块组装提示词并调用 DeepSeek content llm_service.generate(fin_summaryfin, contextctx, templatereq.template) # 4. 报告服务模块落库返回草稿 ID 便于后续编辑与审核 draft_id report_service.save(req.ts_code, content) return {draft_id: draft_id, status: draft}接口设计上要保证幂等性同一个ReportRequest重复提交生成的draft_id应该相同。做法是以ts_code 模板 日期做业务键重复请求直接返回已有草稿避免分析师前端重试时产生多份重复报告。with_risk独立成参数是因为部分场景比如盘中快评不需要完整风险提示拆出来能减少不必要的token消耗。4.2 模型服务的性能监控与容错LLM服务和传统API的监控维度完全不同。除了常规的错误率还要盯首token延迟和token吞吐这两个指标直接决定分析师的使用体感。指标含义阈值建议p50/p95首token延迟用户从发起到看到首个字的耗时p95小于5秒token吞吐每秒生成token数影响成本按预算折算单次生成成功率完整生成不中断的比例大于99%RAG上下文命中率检索片段被模型实际引用的比例大于85%import time import logging logger logging.getLogger(llm_gateway) async def llm_with_monitor(prompt: str, max_tokens: int 2048): t0 time.time() try: resp await llm_client.chat(prompt, max_tokensmax_tokens, timeout120) duration (time.time() - t0) * 1000 logger.info({ event: llm_call, tokens: resp.usage.total_tokens, latency_ms: duration, status: ok }) return resp except TimeoutError: logger.error({event: llm_call, status: timeout, latency_ms: 120000}) raise HTTPException(503, 模型服务超时请稍后重试)120秒超时是因为深度报告的一次完整生成可能涉及数千token超时后前端要能明确感知“任务失败”而不是无限转圈。重试策略用指数退避第一次等2秒重试第二次4秒最多三次如果vLLM里有加载备用小模型可以考虑降级到7B模型先出一版简评保证业务不中断。监控上报建议直接对接Prometheus把上面的logger结构化字段转成metrics配合Grafana做可视化。4.3 应用层三类角色与人工审核闭环研报自动生成不能全自动必须有“人在回路”。应用层按角色拆成分析师、管理层、客户三类视图越界访问在接口层就要拦截。角色主要操作数据权限分析师编辑草稿、核对数据、提交审核本人及团队数据源管理层审核发布、统计工作量全量草稿与报告客户只读查看已发布研报已发布且已授权报告报告状态机用五态就够了draftAI生成草稿、editing分析师修改中、under_review提交审核、published发布、archived归档。权限用RBAC模型/api/v1/report/generate只对分析师角色开放管理层只有/pending_review的读权限客户端的/published接口按客户订阅关系过滤数据。审核这一步不能省它既是质量闸门也是合规要求的落地载体。5. 上线后的验证与调优用评测集守住研报质量下限研报质量评估不能靠“感觉这段写得好”要落到可量化的评测集上。上线前我建议先构建一个50到100条的评测集覆盖三类场景财报解读、行业点评、突发公告点评。每条评测样本包含原始数据、检索片段、人工撰写的基准答案以及抽取出的关键数字集合。评分维度我最看重三个数字正确性——生成文本中的每个具体数字都能在源数据中找到对应逻辑一致性——结论与论据不矛盾比如营收下滑就不该得出“成长强劲”的结论合规表述——不出现承诺性收益、不泄露未公开信息。数字正确性权重最高因为这是硬伤一票否决。import re def verify_numbers(text: str, source_df) - list: 从生成文本中抽取数字与源数据比对返回不一致项 errors [] for num in re.findall(r\d\.?\d*%?, text): # 数字可能带百分号需要统一口径解析 if not is_in_source(num, source_df): errors.append(num) return errorsis_in_source的匹配逻辑是先判断数字是否带百分号再在源数据对应字段里查是否存在相同数值。为了防止浮点精度问题比较时用“绝对值误差小于0.01”而不是严格相等。校验不通过的生成结果直接拦截进人工修改队列不让它流到审核环节。评测集真正的作用是挡住提示词回归。每次改模板、调参数先跑一遍评测集看数字错误率和逻辑不一致数有没有上升。我经历过一次“温度从0.2调到0.5后研报文采变好但数字错误率翻倍”的回归没有评测集根本发现不了。RAG参数也按评测集调chunk_size在512和1024之间对比top_k从5调到10哪个组合数字错误率最低就锁哪个。线上运行阶段每周抽10篇已发布研报重新跑数字校验错误率超过1%就要回溯是数据层更新出了问题还是提示词被改过。最后还有一个实用技巧生成端到端埋一个source_ref字段让模型在每个关键数字后面输出对应的检索片段ID这样分析师核数时一键跳转到原始出处把核数时间从半小时压缩到三分钟。本文还有配套的精品资源点击获取