简介这是一份面向金融科技与AI投研从业者的DeepSeek证券机构投研助手构建方案系统阐述如何基于金融文档语义理解实现投资观点自动提取。全文544页、54个章节从投研场景痛点出发覆盖整体架构设计、数据源体系构建、文档预处理、分词与停用词定制、实体识别、语义理解、数据标注、模型训练与调参全流程内容完整、条理清晰支持目录跳转与书签定位。资源包为单个PDF文件大小15.11MB核心配套文档便于阅读与检索。已有109人下载学习适合金融领域算法工程师、NLP开发者和投研平台架构师作为系统化参考。1. 证券机构投研场景里堆积如山的PDF观点提取不该靠人肉一家中型券商研究所每个交易日要消化上百份卖方研报评级、目标价、盈利预测散落在几十页PDF里。把我们预计公司未来三年净利润复合增速25%维持买入评级这句话抽出来还要带上出处页码和上下文语境过去要么靠研究员手工摘录要么写正则死磕买入增持这些显式关键词。前者耗费人力后者漏掉大量语义变体——建议加大配置底部特征明显不排除进一步上调这些表述没有标准关键词但每一个都是明确的投资观点。这套标题指向的事情很直接以DeepSeek的语义理解能力为底座把金融文档中的投资观点自动提取成结构化数据落到数据库里供检索、统计和二次分析。它解决的痛点是观点与文本的分离即研报里的判断性信息无法被机器直接消费。适合券商自建投研中台、基金公司的智能投研项目、以及做金融NLP的工程团队参考。整套方案的关键拆解点在于文档怎么解析、语义怎么理解、观点怎么定义、抽取结果怎么验证。2. DeepSeek语义理解在金融观点抽取上的选型理由与管线设计2.1 为什么规则正则和微调模型都顶不上通用大模型先分清一件事金融文档的观点提取和实体识别是两类任务。实体识别要的是公司名、人名、日期、金额边界清晰用BERT加序列标注就能做到不错的准确率。但投资观点是语义级的一段话算不算观点方向看多还是看空评级是首次给出还是维持这些判断高度依赖上下文单靠词表匹配一定漏。正则在金融表达面前非常脆弱。同一家券商研究员今天写买入下季度写维持推荐再下季度写我们认为当前估值具备吸引力建议积极配置三个表述指向同一个动作但正则只能覆盖前两种。BERT分类能解决一部分变体问题可金融研报动辄几十页观点往往散落在公司分析、行业景气、风险提示多个小节BERT的输入窗口扛不住这种长程依赖。通用大模型在投研场景的真实优势有三点。第一长上下文处理能力让它能一次读入一个完整小节再输出判断信息不丢。第二few-shot能力让接入成本压得很低不需要为每种文档类型单独训练一版模型这在多券商多风格的研报场景里特别值钱。第三输出可控性好配合结构化输出协议可以直接拿到JSON落库。DeepSeek在中文长文档上的稳定性以及API和本地化部署两条路都能走让它在证券这类对数据出域敏感的场景里成了常见选择。2.2 五段式处理管线从PDF到结构化观点的最小闭环整套系统要能稳定运行至少拆成五层解析、清洗、分块、抽取、校验。不拆分的话后面每一步排错都不知道该看哪一层出了问题只能对着完整链路瞎猜。我的常规拆法如下表处理层输入输出典型依赖文档解析PDF文件页面文本、表格、坐标信息PyMuPDF、pdfplumber文本清洗原始文本去除页眉页脚和目录后的正文规则加位置过滤语义分块清洗后文本语义完整的长段落块标题层级加滑动窗口观点抽取文本块JSON观点记录DeepSeek API或本地服务校验聚合JSON记录去重后的结构化观点集规则加二次推理五层里最容易被低估的是第一层和第三层。不少项目把精力全压在Prompt上结果PDF解析出来满页是第2章 3 CONTENTS或者段落被页边距截成两半喂给模型后输出质量立刻崩掉。做投研文档抽取文本干净度直接决定抽取准确率的天花板这块不花时间后面补多少提示词都白搭。2.3 投资观点数据模型抽取结果落库之前的字段约束在写抽取代码之前先把数据模型定下来。观点记录的核心字段一般按这样设计CREATE TABLE investment_opinion ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_source VARCHAR(255) COMMENT 研报文件名或来源, doc_date DATE COMMENT 报告发布日期, company_code VARCHAR(16) COMMENT 公司代码, company_name VARCHAR(64) COMMENT 公司名称, rating_direction ENUM(BUY,HOLD,SELL,NOT_CLEAR) COMMENT 评级方向, rating_raw VARCHAR(64) COMMENT 原文评级表述, target_price DECIMAL(12,2) COMMENT 目标价, target_price_period VARCHAR(32) COMMENT 目标价有效期描述, confidence_score DECIMAL(3,2) COMMENT 抽取置信度, source_text TEXT COMMENT 观点原文摘录, source_page INT COMMENT 原文页码, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );字段设计有几个关键细节。rating_direction用枚举约束方向rating_raw保留原文的原始表述既方便做统计又保留追溯能力。confidence_score不是模型给的软概率而是校验阶段根据上下文是否完整算出来的启发式分数比如有没有出现但风险不确定性等转折词。source_page必须保留研究员点开结果时能跳回原文核实这个能力在机构场景里比准确率数字更刚需。target_price_period用来存未来12个月2026财年这类表述因为目标价脱离有效期就没有比较意义。3. 用DeepSeek API实现投资观点自动提取的可执行步骤3.1 DeepSeek API接入方式与关键参数设置接DeepSeek的做法和接其他国产大模型API基本一致接口协议兼容OpenAI格式迁移成本很低。最小可用的调用代码如下from openai import OpenAI client OpenAI( api_keysk-xxxxxxxxxxxx, # 从DeepSeek开放平台获取 base_urlhttps://api.deepseek.com # 兼容OpenAI协议 ) resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, max_tokens2000, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f{document_text}\n\n请提取投资观点。} ] )几个参数必须注意。temperature在抽取任务里要压到0.1以下观点抽取不是创作随机性会直接变成幻觉。response_format设成json_object之后模型强制输出合法JSON省去从Markdown代码块里扒JSON的麻烦这个在金融机构落地时特别重要下游系统要直接消费结构化结果。max_tokens建议留足观点原文摘要加JSON结构一般要800到1500个token太短会被截断导致JSON不完整。3.2 面向金融观点的系统提示词与输出格式锁定抽取类任务的Prompt核心是告诉模型什么才算观点。我常用的系统提示词框架是先定义观点边界再给输出格式再用两个例子锁定走查逻辑SYSTEM_PROMPT 你是证券研报分析助手。你的任务是从研报文本中提取投资观点。 投资观点定义为针对特定上市公司或行业的评级判断、目标价预测、盈利预测、买卖建议。 仅包含事实描述如公司去年营收增长10%不算观点除非该描述附带了投资判断。 输出JSON格式 { opinions: [ { company_name: 公司全称, rating_direction: BUY|HOLD|SELL|NOT_CLEAR, rating_raw: 原文中的评级表述, target_price: 数字或null, opinion_summary: 不超过50字的中文观点概括, supporting_text: 观点对应的原文片段保留关键句 } ] } 要求 1. 同一公司出现多次评级表述时全部列出不要合并。 2. 增持买入强烈推荐建议配置归入BUY。 3. 减持卖出回避归入SELL。 4. 中性持有标配归入HOLD。无法判断返回NOT_CLEAR。 5. 没有观点时返回 {opinions: []}。 这里有个容易踩的坑supporting_text字段必须是原文摘录不能是模型自己组织的句子。否则下游做人工复核时会发现引用片段在原文里根本搜不到这会直接毁掉系统在机构客户那里的可信度。可以在校验环节用原文包含关系做自动检查抽出来之后拿supporting_text到原文档里做子串匹配匹配不上就标记为可疑记录。3.3 长文档拆分送审观点定位、二次确认与低置信度兜底单次调用搞定整篇文档在理论上可行但实践中我宁愿拆成三段定位、抽取、确认。第一步先用较小的文本块判断这一段是否存在观点第二步做详细抽取第三步对评级方向不明确的记录做二次追问。这样拆分能显著降低单次请求的token数也能在定位阶段就把无观点段落筛掉节省大头成本。def extract_opinions_with_retry(doc_text: str, max_retry: int 2): for attempt in range(max_retry): try: resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: doc_text} ] ) payload json.loads(resp.choices[0].message.content) return payload[opinions] except json.JSONDecodeError: continue return []重试逻辑只针对解析异常做兜底不该盲目重试整个推理模型输出不稳定时重复算往往得到同样的错。更有效的做法是把每次调用的完整请求与响应落到日志里出问题时用最小复现集排查Prompt。调用链路日志化之后后端能看清哪个文本块触发了低质量抽取比事后翻样例快得多。3.4 API与本地部署的选型数据合规决定一切证券机构对数据出域有严格限制这直接决定部署形态。文本脱敏后走API的方式适合快速验证但内部投研系统的常见做法是内网部署同源模型服务数据全程不出内网。本地部署的代价在显存和吞吐抽取任务每页都要过模型几百份研报就是几百万token硬件规划和API按量计费需要做成本权衡。提示本地部署时建议保留API兼容层业务代码不用改切换部署形态只改base_url为后续升级留出余地。4. 金融PDF前置处理解析还原、语义分块与表格视图隔离4.1 PDF解析层的坑表格、页眉页脚与跨页段落断裂金融PDF是三类内容的混合体正文、表格、图表注释。PyMuPDF直接抽文本遇到跨页表格会把表头拆散遇到被页脚截断的段落会丢掉后半行这些都是在做语义理解之前必须先解决的装配问题。处理顺序一般是先用pdfplumber抽表格把表格区域对应坐标记录下来再从页面文本中剔除这些区域避免表格内容混入正文段落import pdfplumber def extract_pdf_pages(pdf_path: str): pages [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: tables page.extract_tables() table_text_blocks [] for table in tables: for row in table: table_text_blocks.append( | .join(cell or for cell in row)) text page.extract_text() or pages.append({ page_number: page.page_number, body_text: text, table_text: \n.join(table_text_blocks) }) return pages表格单独存放的意义在于投研报告里的评级和目标价表格往往比正文里的散句更精确直接混进正文反而干扰段落层面的观点判断。分块抽取时表格走单独的抽取Prompt正文走正文的Prompt两个结果合并时以正文为主、表格做交叉验证。跨页断句的修复常见做法是看上一页末尾有没有句号、问号、感叹号没有就把下一页开头接续上来这个规则对研报正文基本够用。4.2 语义分块策略按小节边界切而不是按固定窗口切分块的目标是让每个送入模型的文本单元语义自洽。固定窗口切分最大的问题是把行业景气度向好我们维持推荐和但原材料价格上行风险需要关注切成两块前者被识别成强看多转折信息全丢了。各家方案对比如下分块策略优点缺点适用场景固定窗口加重叠实现简单控制token成本语义边界不可控易截断转折快速原型验证按标题层级切块语义完整观点集中依赖文档结构图表干扰大正式系统首选按段落加句子边界语义块粒度适中段落短时上下文不足需要精细抽取时正式系统里我倾向于标题层级优先、长度兜底的两级策略。先用文档目录或标题字体特征把整篇拆成小节小节约2000到4000字超过长度上限就按句子边界二次切分并保留上一块末尾的500字作为上下文重叠。这样既保住转折词的完整性又不会让单次请求的token数失控。4.3 页眉页脚噪音剔除与段落断裂修复的规则化处理页眉页脚过滤不值得用模型规则加坐标就够。研报页眉通常是公司名称加报告标题页脚是第X页和券商免责声明位置固定、格式重复。解析时记录每个页面文本块的坐标框过滤掉顶部和底部各15%的区域再用正则把页码变体清掉import re def clean_noise(text: str) - str: text re.sub(r第\s*\d\s*页?\s*共\s*\d\s*页, , text) text re.sub(r\b\d{1,3}\b\s*/\s*\d{1,3}\b, , text) # 页码对 lines [line.strip() for line in text.splitlines() if line.strip()] # 连续重复3次以上的行视为页眉/页脚特征 freq {} for ln in lines: freq[ln] freq.get(ln, 0) 1 filtered [ln for ln in lines if freq[ln] 3] return \n.join(filtered)这段代码的逻辑值得拆开说。两个正则清的是最常见的页码变体频率去重处理的是每页都重复出现的券商名称和地址信息判断依据是页眉页脚在同一份报告里的重复次数必然高于正文语块。这个规则对超过30页的深度研报很有效但对只有几页的点评类报告要小心正文中同一句话重复三次的情况虽少但不是没有。段落断裂修复放在噪音剔除之后研报PDF转出的文本经常出现投资要点和我们认为被拆成两个文本块的情况根源在字体内嵌方式需要按坐标Y排序后把同一行的块合并再按行聚合为段落。坐标排序对精度要求高误合并会引入跨栏文本所以合并前先判断两个块的x坐标是否属于同一栏跨栏文本宁可不合并也不要错合。5. 用回归集验证、缓存复用和错误分类驱动抽取质量迭代5.1 标注集与语义匹配裁判抽取效果的客观度量抽取系统的准确率不能靠人工抽查得建一个可重复的回归集。常见做法是挑十份不同类型研报深度报告、点评报告、行业周报各几份人工逐句标注出每份报告里的观点句和评级方向标成JSON作为golden set。每次改Prompt或换模型版本都在这个集合上跑一遍看抽取结果和标注结果的匹配情况。匹配规则上评级方向用精确匹配目标价用容差匹配误差3%以内视为命中观点句用语义相似度匹配。相似度匹配建议用DeepSeek做裁判比词向量更贴合金融文本的改写特点def judge_match(extracted: str, annotated: str) - bool: prompt f判断下面两句话是否表达同一投资观点。 抽取结果{extracted} 标注原文{annotated} 只回答 是 或 否。 resp client.chat.completions.create( modeldeepseek-chat, temperature0, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content.strip() 是注意这里temperature必须设成0裁判任务不允许任何随机性。整个回归集跑完统计准确率和召回率任何一个类别数据异常就反向定位到对应文本块和Prompt规则而不是盲目加few-shot样例。5.2 文档指纹缓存与增量更新降低重复计算成本观点抽取是重计算操作同一份研报被重复解析很常见研究员看一遍、风控看一遍、量化团队再导一遍。在解析层面对文档做哈希指纹变化才触发重新抽取否则直接读缓存结果能省掉大量重复token成本import hashlib def doc_fingerprint(pdf_path: str) - str: with open(pdf_path, rb) as f: return hashlib.md5(f.read()).hexdigest()缓存粒度建议按文档加版本号来设计研报常有修订版文件名一样但内容变了。哈希兜住的是内容变更但公司公告出了更新这类源数据层面的语义变化要靠上游触发的显式失效不要指望哈希能判断语义是否过期。5.3 从错误样例反推改Prompt不如先改前置处理持续优化抽取质量真正有效的手段是从错误集中找规律。比如golden set里发现目标价字段经常抽成null把错误样例打印出来看是不是目标价只出现在表格里而正文没有文字描述。按错误类型归类分别对应三种修法表格抽取没接进管线、Prompt里没有目标价提取指令、原文本身就没给目标价。用错误分类驱动优化比套用网上的万能Prompt模板靠谱得多。抽取系统的天花板由文档预处理质量决定模型能力只是最后一公里的执行者每次迭代只改一处改完重跑回归集对比F1这是最稳的节奏。最后给一个具体技巧在把DeepSeek当作抽取引擎的同时让它兼任复核员把抽取结果和原文片段一起送回模型问一句这段原文是否支持上述评级方向的判断能有效拦截幻觉和断章取义。复核动作只针对低置信度记录整体耗时增加不到5%但漏判率能肉眼可见地降下来这个双通道设计比单次抽取加人工抽检更适合作业流程。本文还有配套的精品资源点击获取 用DeepSeek从金融PDF中自动提取投资观点：管线设计与实践
简介这是一份面向金融科技与AI投研从业者的DeepSeek证券机构投研助手构建方案系统阐述如何基于金融文档语义理解实现投资观点自动提取。全文544页、54个章节从投研场景痛点出发覆盖整体架构设计、数据源体系构建、文档预处理、分词与停用词定制、实体识别、语义理解、数据标注、模型训练与调参全流程内容完整、条理清晰支持目录跳转与书签定位。资源包为单个PDF文件大小15.11MB核心配套文档便于阅读与检索。已有109人下载学习适合金融领域算法工程师、NLP开发者和投研平台架构师作为系统化参考。1. 证券机构投研场景里堆积如山的PDF观点提取不该靠人肉一家中型券商研究所每个交易日要消化上百份卖方研报评级、目标价、盈利预测散落在几十页PDF里。把我们预计公司未来三年净利润复合增速25%维持买入评级这句话抽出来还要带上出处页码和上下文语境过去要么靠研究员手工摘录要么写正则死磕买入增持这些显式关键词。前者耗费人力后者漏掉大量语义变体——建议加大配置底部特征明显不排除进一步上调这些表述没有标准关键词但每一个都是明确的投资观点。这套标题指向的事情很直接以DeepSeek的语义理解能力为底座把金融文档中的投资观点自动提取成结构化数据落到数据库里供检索、统计和二次分析。它解决的痛点是观点与文本的分离即研报里的判断性信息无法被机器直接消费。适合券商自建投研中台、基金公司的智能投研项目、以及做金融NLP的工程团队参考。整套方案的关键拆解点在于文档怎么解析、语义怎么理解、观点怎么定义、抽取结果怎么验证。2. DeepSeek语义理解在金融观点抽取上的选型理由与管线设计2.1 为什么规则正则和微调模型都顶不上通用大模型先分清一件事金融文档的观点提取和实体识别是两类任务。实体识别要的是公司名、人名、日期、金额边界清晰用BERT加序列标注就能做到不错的准确率。但投资观点是语义级的一段话算不算观点方向看多还是看空评级是首次给出还是维持这些判断高度依赖上下文单靠词表匹配一定漏。正则在金融表达面前非常脆弱。同一家券商研究员今天写买入下季度写维持推荐再下季度写我们认为当前估值具备吸引力建议积极配置三个表述指向同一个动作但正则只能覆盖前两种。BERT分类能解决一部分变体问题可金融研报动辄几十页观点往往散落在公司分析、行业景气、风险提示多个小节BERT的输入窗口扛不住这种长程依赖。通用大模型在投研场景的真实优势有三点。第一长上下文处理能力让它能一次读入一个完整小节再输出判断信息不丢。第二few-shot能力让接入成本压得很低不需要为每种文档类型单独训练一版模型这在多券商多风格的研报场景里特别值钱。第三输出可控性好配合结构化输出协议可以直接拿到JSON落库。DeepSeek在中文长文档上的稳定性以及API和本地化部署两条路都能走让它在证券这类对数据出域敏感的场景里成了常见选择。2.2 五段式处理管线从PDF到结构化观点的最小闭环整套系统要能稳定运行至少拆成五层解析、清洗、分块、抽取、校验。不拆分的话后面每一步排错都不知道该看哪一层出了问题只能对着完整链路瞎猜。我的常规拆法如下表处理层输入输出典型依赖文档解析PDF文件页面文本、表格、坐标信息PyMuPDF、pdfplumber文本清洗原始文本去除页眉页脚和目录后的正文规则加位置过滤语义分块清洗后文本语义完整的长段落块标题层级加滑动窗口观点抽取文本块JSON观点记录DeepSeek API或本地服务校验聚合JSON记录去重后的结构化观点集规则加二次推理五层里最容易被低估的是第一层和第三层。不少项目把精力全压在Prompt上结果PDF解析出来满页是第2章 3 CONTENTS或者段落被页边距截成两半喂给模型后输出质量立刻崩掉。做投研文档抽取文本干净度直接决定抽取准确率的天花板这块不花时间后面补多少提示词都白搭。2.3 投资观点数据模型抽取结果落库之前的字段约束在写抽取代码之前先把数据模型定下来。观点记录的核心字段一般按这样设计CREATE TABLE investment_opinion ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_source VARCHAR(255) COMMENT 研报文件名或来源, doc_date DATE COMMENT 报告发布日期, company_code VARCHAR(16) COMMENT 公司代码, company_name VARCHAR(64) COMMENT 公司名称, rating_direction ENUM(BUY,HOLD,SELL,NOT_CLEAR) COMMENT 评级方向, rating_raw VARCHAR(64) COMMENT 原文评级表述, target_price DECIMAL(12,2) COMMENT 目标价, target_price_period VARCHAR(32) COMMENT 目标价有效期描述, confidence_score DECIMAL(3,2) COMMENT 抽取置信度, source_text TEXT COMMENT 观点原文摘录, source_page INT COMMENT 原文页码, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );字段设计有几个关键细节。rating_direction用枚举约束方向rating_raw保留原文的原始表述既方便做统计又保留追溯能力。confidence_score不是模型给的软概率而是校验阶段根据上下文是否完整算出来的启发式分数比如有没有出现但风险不确定性等转折词。source_page必须保留研究员点开结果时能跳回原文核实这个能力在机构场景里比准确率数字更刚需。target_price_period用来存未来12个月2026财年这类表述因为目标价脱离有效期就没有比较意义。3. 用DeepSeek API实现投资观点自动提取的可执行步骤3.1 DeepSeek API接入方式与关键参数设置接DeepSeek的做法和接其他国产大模型API基本一致接口协议兼容OpenAI格式迁移成本很低。最小可用的调用代码如下from openai import OpenAI client OpenAI( api_keysk-xxxxxxxxxxxx, # 从DeepSeek开放平台获取 base_urlhttps://api.deepseek.com # 兼容OpenAI协议 ) resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, max_tokens2000, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f{document_text}\n\n请提取投资观点。} ] )几个参数必须注意。temperature在抽取任务里要压到0.1以下观点抽取不是创作随机性会直接变成幻觉。response_format设成json_object之后模型强制输出合法JSON省去从Markdown代码块里扒JSON的麻烦这个在金融机构落地时特别重要下游系统要直接消费结构化结果。max_tokens建议留足观点原文摘要加JSON结构一般要800到1500个token太短会被截断导致JSON不完整。3.2 面向金融观点的系统提示词与输出格式锁定抽取类任务的Prompt核心是告诉模型什么才算观点。我常用的系统提示词框架是先定义观点边界再给输出格式再用两个例子锁定走查逻辑SYSTEM_PROMPT 你是证券研报分析助手。你的任务是从研报文本中提取投资观点。 投资观点定义为针对特定上市公司或行业的评级判断、目标价预测、盈利预测、买卖建议。 仅包含事实描述如公司去年营收增长10%不算观点除非该描述附带了投资判断。 输出JSON格式 { opinions: [ { company_name: 公司全称, rating_direction: BUY|HOLD|SELL|NOT_CLEAR, rating_raw: 原文中的评级表述, target_price: 数字或null, opinion_summary: 不超过50字的中文观点概括, supporting_text: 观点对应的原文片段保留关键句 } ] } 要求 1. 同一公司出现多次评级表述时全部列出不要合并。 2. 增持买入强烈推荐建议配置归入BUY。 3. 减持卖出回避归入SELL。 4. 中性持有标配归入HOLD。无法判断返回NOT_CLEAR。 5. 没有观点时返回 {opinions: []}。 这里有个容易踩的坑supporting_text字段必须是原文摘录不能是模型自己组织的句子。否则下游做人工复核时会发现引用片段在原文里根本搜不到这会直接毁掉系统在机构客户那里的可信度。可以在校验环节用原文包含关系做自动检查抽出来之后拿supporting_text到原文档里做子串匹配匹配不上就标记为可疑记录。3.3 长文档拆分送审观点定位、二次确认与低置信度兜底单次调用搞定整篇文档在理论上可行但实践中我宁愿拆成三段定位、抽取、确认。第一步先用较小的文本块判断这一段是否存在观点第二步做详细抽取第三步对评级方向不明确的记录做二次追问。这样拆分能显著降低单次请求的token数也能在定位阶段就把无观点段落筛掉节省大头成本。def extract_opinions_with_retry(doc_text: str, max_retry: int 2): for attempt in range(max_retry): try: resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: doc_text} ] ) payload json.loads(resp.choices[0].message.content) return payload[opinions] except json.JSONDecodeError: continue return []重试逻辑只针对解析异常做兜底不该盲目重试整个推理模型输出不稳定时重复算往往得到同样的错。更有效的做法是把每次调用的完整请求与响应落到日志里出问题时用最小复现集排查Prompt。调用链路日志化之后后端能看清哪个文本块触发了低质量抽取比事后翻样例快得多。3.4 API与本地部署的选型数据合规决定一切证券机构对数据出域有严格限制这直接决定部署形态。文本脱敏后走API的方式适合快速验证但内部投研系统的常见做法是内网部署同源模型服务数据全程不出内网。本地部署的代价在显存和吞吐抽取任务每页都要过模型几百份研报就是几百万token硬件规划和API按量计费需要做成本权衡。提示本地部署时建议保留API兼容层业务代码不用改切换部署形态只改base_url为后续升级留出余地。4. 金融PDF前置处理解析还原、语义分块与表格视图隔离4.1 PDF解析层的坑表格、页眉页脚与跨页段落断裂金融PDF是三类内容的混合体正文、表格、图表注释。PyMuPDF直接抽文本遇到跨页表格会把表头拆散遇到被页脚截断的段落会丢掉后半行这些都是在做语义理解之前必须先解决的装配问题。处理顺序一般是先用pdfplumber抽表格把表格区域对应坐标记录下来再从页面文本中剔除这些区域避免表格内容混入正文段落import pdfplumber def extract_pdf_pages(pdf_path: str): pages [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: tables page.extract_tables() table_text_blocks [] for table in tables: for row in table: table_text_blocks.append( | .join(cell or for cell in row)) text page.extract_text() or pages.append({ page_number: page.page_number, body_text: text, table_text: \n.join(table_text_blocks) }) return pages表格单独存放的意义在于投研报告里的评级和目标价表格往往比正文里的散句更精确直接混进正文反而干扰段落层面的观点判断。分块抽取时表格走单独的抽取Prompt正文走正文的Prompt两个结果合并时以正文为主、表格做交叉验证。跨页断句的修复常见做法是看上一页末尾有没有句号、问号、感叹号没有就把下一页开头接续上来这个规则对研报正文基本够用。4.2 语义分块策略按小节边界切而不是按固定窗口切分块的目标是让每个送入模型的文本单元语义自洽。固定窗口切分最大的问题是把行业景气度向好我们维持推荐和但原材料价格上行风险需要关注切成两块前者被识别成强看多转折信息全丢了。各家方案对比如下分块策略优点缺点适用场景固定窗口加重叠实现简单控制token成本语义边界不可控易截断转折快速原型验证按标题层级切块语义完整观点集中依赖文档结构图表干扰大正式系统首选按段落加句子边界语义块粒度适中段落短时上下文不足需要精细抽取时正式系统里我倾向于标题层级优先、长度兜底的两级策略。先用文档目录或标题字体特征把整篇拆成小节小节约2000到4000字超过长度上限就按句子边界二次切分并保留上一块末尾的500字作为上下文重叠。这样既保住转折词的完整性又不会让单次请求的token数失控。4.3 页眉页脚噪音剔除与段落断裂修复的规则化处理页眉页脚过滤不值得用模型规则加坐标就够。研报页眉通常是公司名称加报告标题页脚是第X页和券商免责声明位置固定、格式重复。解析时记录每个页面文本块的坐标框过滤掉顶部和底部各15%的区域再用正则把页码变体清掉import re def clean_noise(text: str) - str: text re.sub(r第\s*\d\s*页?\s*共\s*\d\s*页, , text) text re.sub(r\b\d{1,3}\b\s*/\s*\d{1,3}\b, , text) # 页码对 lines [line.strip() for line in text.splitlines() if line.strip()] # 连续重复3次以上的行视为页眉/页脚特征 freq {} for ln in lines: freq[ln] freq.get(ln, 0) 1 filtered [ln for ln in lines if freq[ln] 3] return \n.join(filtered)这段代码的逻辑值得拆开说。两个正则清的是最常见的页码变体频率去重处理的是每页都重复出现的券商名称和地址信息判断依据是页眉页脚在同一份报告里的重复次数必然高于正文语块。这个规则对超过30页的深度研报很有效但对只有几页的点评类报告要小心正文中同一句话重复三次的情况虽少但不是没有。段落断裂修复放在噪音剔除之后研报PDF转出的文本经常出现投资要点和我们认为被拆成两个文本块的情况根源在字体内嵌方式需要按坐标Y排序后把同一行的块合并再按行聚合为段落。坐标排序对精度要求高误合并会引入跨栏文本所以合并前先判断两个块的x坐标是否属于同一栏跨栏文本宁可不合并也不要错合。5. 用回归集验证、缓存复用和错误分类驱动抽取质量迭代5.1 标注集与语义匹配裁判抽取效果的客观度量抽取系统的准确率不能靠人工抽查得建一个可重复的回归集。常见做法是挑十份不同类型研报深度报告、点评报告、行业周报各几份人工逐句标注出每份报告里的观点句和评级方向标成JSON作为golden set。每次改Prompt或换模型版本都在这个集合上跑一遍看抽取结果和标注结果的匹配情况。匹配规则上评级方向用精确匹配目标价用容差匹配误差3%以内视为命中观点句用语义相似度匹配。相似度匹配建议用DeepSeek做裁判比词向量更贴合金融文本的改写特点def judge_match(extracted: str, annotated: str) - bool: prompt f判断下面两句话是否表达同一投资观点。 抽取结果{extracted} 标注原文{annotated} 只回答 是 或 否。 resp client.chat.completions.create( modeldeepseek-chat, temperature0, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content.strip() 是注意这里temperature必须设成0裁判任务不允许任何随机性。整个回归集跑完统计准确率和召回率任何一个类别数据异常就反向定位到对应文本块和Prompt规则而不是盲目加few-shot样例。5.2 文档指纹缓存与增量更新降低重复计算成本观点抽取是重计算操作同一份研报被重复解析很常见研究员看一遍、风控看一遍、量化团队再导一遍。在解析层面对文档做哈希指纹变化才触发重新抽取否则直接读缓存结果能省掉大量重复token成本import hashlib def doc_fingerprint(pdf_path: str) - str: with open(pdf_path, rb) as f: return hashlib.md5(f.read()).hexdigest()缓存粒度建议按文档加版本号来设计研报常有修订版文件名一样但内容变了。哈希兜住的是内容变更但公司公告出了更新这类源数据层面的语义变化要靠上游触发的显式失效不要指望哈希能判断语义是否过期。5.3 从错误样例反推改Prompt不如先改前置处理持续优化抽取质量真正有效的手段是从错误集中找规律。比如golden set里发现目标价字段经常抽成null把错误样例打印出来看是不是目标价只出现在表格里而正文没有文字描述。按错误类型归类分别对应三种修法表格抽取没接进管线、Prompt里没有目标价提取指令、原文本身就没给目标价。用错误分类驱动优化比套用网上的万能Prompt模板靠谱得多。抽取系统的天花板由文档预处理质量决定模型能力只是最后一公里的执行者每次迭代只改一处改完重跑回归集对比F1这是最稳的节奏。最后给一个具体技巧在把DeepSeek当作抽取引擎的同时让它兼任复核员把抽取结果和原文片段一起送回模型问一句这段原文是否支持上述评级方向的判断能有效拦截幻觉和断章取义。复核动作只针对低置信度记录整体耗时增加不到5%但漏判率能肉眼可见地降下来这个双通道设计比单次抽取加人工抽检更适合作业流程。本文还有配套的精品资源点击获取