说实话做投研这行最不缺的就是信息缺的是处理信息的时间。每天早上一睁眼券商研报、公司公告、行业新闻、宏观数据、调研纪要堆成山一个人根本刷不过来。我断断续续做了半年多的AI投研系统折腾了不少方向也推翻过几次重来现在把整套设计思路、模块拆解、实现细节和踩过的坑都整理成这篇杂记希望给正在搭这类系统的朋友一点参考。这里说的“投研系统”不是要替代研究员而是把信息处理链路自动化让AI先把材料分类、抽取、打标签把真正需要人判断的东西提到人面前来。适合谁看写代码的工程师、量化研究员、想给团队配置投研助手的负责人都可以读下去。1. 先想清楚“有效”到底指什么做系统之前别急着选模型、写代码先回答一个问题什么叫做“有效”在我接触过的团队里很多人一开始的诉求是“用AI读研报”“用AI写纪要”但聊深了才发现真正想解决的是三类完全不同的痛点。1.1 三类典型用户与各自痛点第一类是买方研究员。他们的痛点是信息过载每天要覆盖十几个行业、几十家公司每家公司要看公告、新闻、财务数据、同业对比。人工筛一遍要两三个小时最后真正用来形成判断的可能只有一两条关键信息。他们需要的不是再多的阅读器而是有人先把材料按“事件类型”分类好按“影响程度”粗排一遍序。第二类是量化与研究组合型团队。他们不仅看文本还想把文本变成结构化因子比如从财报里抽出收入增速、毛利率变化从公告里判断事件是利好还是利空。这个过程的痛点在于文本是非结构化的PDF版式五花八门人工提取费时费力还容易出错AI抽取又怕数字不准。他们要的是“可信的结构化抽取”不是花哨的自然语言问答。第三类是风控或者投委会场景。他们不直接读原始材料但需要审阅AI给出的研究结果核心诉求是可解释、可查证。比如AI说“某某公司应收账款风险上升”他们一定要能反查到这是从哪张表、哪个附注里得出来的中间经过了什么推理。如果AI只给个结论没有证据链这个系统在风控环节就是废的。1.2 有效系统的四条评价标准绕了一圈以后我在设计目标上收敛成了四条硬指标后续所有模块都以这四个字来衡量覆盖、准度、时效、可解释。先说覆盖。数据源必须足够全A股公告、港股公告、行业研报、宏观数据、社交媒体舆情按业务需要接齐。缺一个关键来源系统就可能对某类重大风险“盲视”。再是准度。抽取出来的每个数字、每个标签都要有置信度宁可拒绝回答也不能乱报这是投研场景和大模型聊天场景最本质的差别。然后是时效。公告晚上十点发布系统最好十点一分就能触发分析流程早上八点前把结论推进用户工作流。最后是可解释。任何一条自动生成的信号都要能一路回溯到原始文档标注清楚是哪一段原文触发的。这四个标准里最容易在前期被忽略的是“可解释”。很多团队用AI做了漂亮的分析报告业务方当时觉得很强但一旦被追问“这个结论哪来的”就发现链条断了系统从此被打入冷宫。我把话放前面投研系统的可解释性不是锦上添花是生死线。2. 系统架构怎么搭从数据到决策的完整链路明确了目标以后下一步是搭整体架构。我采用的不是市面上花哨的“Agent全家桶”而是一条很朴素的分层链路。事实证明越朴素的架构越容易落地。2.1 五层架构模型整体上分五层数据采集层、清洗加工层、知识沉淀层、分析推理层、触达应用层。数据采集层负责从交易所、资讯商、券商平台拿到公告、研报、财务数据的原文注意抓增量而不是反复全量拉取大多数平台的接口费用是按调用量计的做增量下发能省不少成本。清洗加工层负责把PDF转文本、表格还原、乱码修复、编码归一这是最琐碎却最关键的一层原始材料不干净后面所有环节都会放大错误。知识沉淀层把清洗后的非结构化文本切片、做向量化、写入知识库同时把实体关系抽出来维护成公司、行业、股东、高管之间的关联网络。分析推理层才是大模型发挥作用的地方负责事件识别、观点抽取、风险信号生成由一组分工明确的Agent协作完成。触达应用层是给用户的工作台包括晨报推送、公司事件列表、研究问询接口。举个例子感受一下一份上市公司的定增公告PDF格式发出来采集层抓下来清洗层把PDF解析成Markdown文本知识沉淀层把关键段落截成切片并标注来源页码分析层识别出“定向增发”事件、参与对象、募资金额、投向项目最终触达层把它推送到关注该公司的研究员工作台里变成一条事件卡片。这条链路不长但每一层都有自己的坑。2.2 为什么直接调用大模型API不够用不少朋友问过我代码也不复杂直接把公告全文扔给大模型让它输出结论不就行了吗没错做Demo可以做系统不行至少有三个过不去的坎。第一个坎是时效性。大模型的知识截止日期是固定的新发布的公告它没见过你必须把公告内容检索出来拼进Prompt它才能回答。这就决定了投研系统必然要走检索增强生成的路线而不是靠模型本身的知识回答问题。第二个坎是可解释性。直接调用模型你能拿到结论但拿不到稳定的证据链。即便模型复述了原文中的一句话你也没法保证这句话一定来自文档。真正的做法是把知识库切片与生成过程硬绑定每个结论带出切片ID用户点一下就能看到原始上下文。第三个坎是成本与稳定性。金融领域的问题表述复杂动不动超长文本直接调用模型做开放问答Token消耗巨大输出还不稳定。但改成“字段抽取、结构化输出”的范式之后Prompt是固定的模板输出是固定的JSON既方便校验又能大幅压低成本。我把两种方案对比列一下对比维度直接调大模型APIRAG检索增强架构领域微调时效性依赖训练数据截止日知识库实时更新依赖微调数据版本可解释性弱无法溯源强切片带引用弱内部参数变化准确性波动大容易幻觉较稳可加校验层稳定但只限单一任务落地成本低适合验证中需建管线高需要训练数据集适用场景概念验证、辅助写作长期系统、多数据源高频固定格式任务我最后的选择是“RAG为主、微调为辅”。高频且格式固定的抽取任务比如财报里特定科目数值的提取用微调一个小模型跑速度快、成本低而开放式分析、推理、观点汇总这些任务交给RAG架构上的大模型来做。3. 核心模块设计与实操要点架构定下来后就要细化到具体模块了。这几个模块是投研系统的核心骨架做扎实了系统才立得住。3.1 财报与公告的结构化抽取财报和公告的结构化抽取是投研场景里最典型的硬骨头。我第一版做得粗糙直接把PDF整篇丢给模型让它读结果资产负债表里有的数字读错了有的单位差了一万倍搞得我不敢再往下做。后来调整了做法总结起来就一句话先版面还原再模板抽取最后大模型校验三层各干各的活。版面还原阶段用OCR和版面分析工具把PDF转成带坐标的文本块识别出表格区域和正文区域这一步最大的坑是PDF里经常有扫描件清晰度不够必须先做图像增强和倾斜矫正否则后面的表格识别全乱。模板抽取阶段针对资产负债表、利润表、现金流量表这种结构固定的部分用正则和规则先把科目名和数值抓出来同时记录数值在原文中的位置这一步准确率能做到九成以上。最后大模型校验阶段把抽出来的数值表和原始段落一起喂给模型让它交叉检查单位和逻辑关系比如总营收是否等于各分部营收之和、净利润是否小于营收出现可疑项就打标记让人工复核。这里有个细节容易忽略单位归一化。同一份PDF里有的科目单位是“元”有的是“万元”还有的是“千元”大模型一不留神就会把它们当成同一个数量级。我的做法是模型输出时强制加一个单位字段由后置规则统一折算成“万元”折算后和同行业历史值做合理性校验偏离过大直接拦截。3.2 增量事件识别与标签化第二个核心模块是把每一条新公告识别成结构化事件。这个模块的设计原则是不要让它自由发挥而是先给一组固定的事件类型让它做分类和参数抽取例如定增、回购、股权质押、业绩预告、诉讼仲裁、资产出售、关联交易、高管变动、分红方案、停牌复牌。每一类事件都定义了需要抽取的字段。以“回购”为例需要抽的是回购金额上限、回购价格上限、用途、实施进度字段定义清楚之后大模型的输出就能对齐数据库结构后续才能做统计、做排序、做触发规则。如果模型判断事件不属于任何已知类型就丢进“待人工分类”池积累多了再补充事件模板而不是让模型现场发明一个新类型。事件标签化之后的下游应用是信号触发。我设计了一套简单的评分规则比如“回购金额占总市值比例超过1.5%”触发一个中性正面结构信号“实际控制人大比例质押”触发风险信号。规则全部写在代码里不靠模型判断级别这样每一步都有明确逻辑被业务方质疑时也能直接说清楚。3.3 行业研报的观点抽取与追踪研报处理和公告处理又有不一样的地方。公告是事实性文本抽字段就好研报是观点性文本要抽的是逻辑链。我把任务从“写摘要”改成“抽观点拉证据链”。具体做法是让模型从每篇研报中提取出三个层次核心结论、关键假设、风险提示。核心结论要拆成“标的、方向、幅度、时间范围”四个要素例如“某公司2025年净利润同比增长20%-25%”关键假设要记录预测依赖的前提例如“假设原材料价格保持稳定”“假设新产能下半年满产”风险提示则抽原文明确提到的负面可能。这套数据沉淀下来价值很大。你可以拉着一家被三家券商覆盖的公司把三家对同一指标的预测放在一起对比看哪家上调了、哪家下调了预测分歧在扩大还是收窄。当半数以上研报同时上调盈利预测时系统会激活一条趋势提示告诉研究员“卖方情绪在边际改善”这个功能用户反馈很好因为它是人眼刷几十页PDF很难快速统计出来的维度。4. 多Agent协作机制怎么设计聊完模块得说说现在比较热门的Agent机制。我这个系统确实用到了多Agent协作但和网上宣传的“Agent满天飞”不是一回事——更像是给一条流水线配了几个分工明确的工人各干各的绝不跨界。4.1 角色分工信息采集、基础分析、质量复核、结果输出系统里长期运行着四类Agent分工非常明确。信息采集Agent只负责检索和聚合不分析。用户问“最近有没有人和我说过这家公司的风险”它只负责从知识库里把相关公告、新闻、研报切片找出来按时间排序输出不掺任何观点。基础分析Agent负责干活把信息采集Agent给出的切片拿来识别事件、抽取观点、判断情绪生成带字段的结构化结果。质量复核Agent是第二双眼睛重点核查数字逻辑和引用来源比如检查分析Agent输出的结论是否真的能在原始文档中找到对应支撑引文ID是否指向了正确的切片。结果输出Agent站在最后负责把通过复核的内容整理成用户友好的排班报表、事件卡片或问答回复。这套角色边界带来的最大好处是“责任清晰”。哪个环节出了错直接看是采集的问题、分析的问题还是复核的问题不会出现几个Agent互相推诿、在Prompt里绕圈子翻旧账的情况。我把边界写死在调度层的配置里Agent之间不允许直接对话只能通过中间件传递结构化消息省掉了大量自然语言交互的不可控性。4.2 用状态机和消息格式代替自由对话很多参考LangChain用多个Agent直接聊天我试过效果灾难——上下文一长Agent就开始把之前所有对话内容塞进PromptToken飞涨回答还互相覆盖。后来我改用了一个很朴素的机制任务状态机加结构化消息。每条任务从创建到完成经历几个状态待收集、分析中、复核中、可输出、已驳回。每个状态只能由对应的Agent去推进比如只有质量复核Agent能把任务置为“已驳回”而“已驳回”的任务会带着驳回原因回到基础分析Agent手里修正修正后再次进入复核最多循环两轮仍不过就转人工。这个机制保证了低质量结果不会流向用户也避免了Agent对话无限循环。Agent之间传递的消息统一是JSON格式字段分为三层{ task_id: task_001, status: analysis_done, inputs: { query: ..., source_ids: [doc_001_chunk_02, doc_007_chunk_11] }, outputs: { event_type: share_buyback, params: {amount: 50000, unit: 万元}, evidence_ids: [doc_001_chunk_02] } }所有字段都有明确的Schema定义哪个Agent往哪个字段写数据都严格限制。这一版出来之后系统变得非常稳因为它本质上不是一堆Agent在聊天而是一个分布式任务系统挂了几张智能卡。4.3 上下文记忆与状态回写多Agent协作还有一个实际问题如何让后一个Agent知道前一个Agent做过什么。我的做法是在任务ID下面挂一个“工作记录板”分析Agent写入它的中间结论复核Agent写入复核意见信息Agent写入检索过程的URL清单。后续任何Agent需要上下文直接查工作记录板就行不需要把Agent之间的历史消息统统塞进Prompt。工作记录板也是审计日志。哪天用户怀疑某个结论运维可以直接导出记录板里所有操作步骤看到每一步是谁处理的、依据是什么。这对要过合规的团队来说是刚需对个人研究型使用者也很有用等于给系统加了一层“过程透明”。5. 常见问题与排查经验系统上线后真正考验人的不是功能设计而是日常运行中的各种问题。这里整理几个高频问题和排查思路。5.1 幻觉问题从源头掐断而不是事后补救投研系统最怕的就是幻觉。我见过最离谱的一次模型在回答某公司财务指标时一本正经地编了一个收入增速实际上年报里根本没有这个数。如果研究员直接把数值抄进报告这就是事故。我的根治办法是两条腿走路。一是强制结构化输出凡是涉及数字、日期、金额的字段模型必须从给定文本中提取并附上原文片段ID不允许“无中生有”式的生成。二是增加兜底规则层如果该字段在原文中没有找到模型必须输出null而不是估算值再由规则层对null值做缺失标记。有了这个机制幻觉从“编造一个数”变成了“承认找不到”安全性完全不一样。5.2 数据时效与增量更新策略系统的价值建立在数据新鲜度上但增量更新在建知识库的时候容易踩坑。最初我用全量重灌的方式每天晚上把当天得到的所有文档重新向量化写库跑一次要两个多小时早上数据还是旧的。后来改成按文档批次增量入库只处理新抓到的文件。增量入库最大的坑是“过度分割”。同一个PDF里的上下文被切进不同切片导致检索时各拿一半分析Agent看不到完整内容判断自然歪。解决方法是切片时带上父子关系每个切片记录来源文档ID和章节路径检索时不仅返回命中切片还返回它的兄弟切片和所属大段落让分析Agent一次拿满上下文。这个改动让问答准确率提升非常明显。5.3 评估迭代怎么判断系统真的变好了不少系统上线之后就没有然后了因为没有评估机制。投研系统没有评估机制会退化模型版本一升级、数据格式一变以前跑得好好的流程突然输出垃圾你可能一周后才发现。我维护了一个专门的评测集包含大约一千条真实数据和对应的标准答案分两类抽取评测和问答评测。抽取评测针对的是财报字段逐项比对模型输出和人工标注是否一致用准确率和字段缺失率两个指标衡量每次大模型版本升级前跑一遍防止回归。问答评测是一组固定的问题比如“列出过去三个月该公司所有股权质押事件”之类的真实业务问题人工提前写好参考答案用规则和语义相似度综合打分。版本迭代我坚持小步快跑一次只改一个变量。这周只换Embedding模型、下周只调检索TopK、再下周只改Prompt模板每次改动都跑评测集对比。上线之后关注业务指标而不是模型指标尤其盯着“推送给用户的信号里多少条被点开、多少条被保存”这才是“有效投研系统”最真实的答卷。6. 一些实操下来的个人体会做这个系统的过程中我最深的感触是技术选型不是第一位的流程设计才是。一开始我也被各种新框架吸引但后来发现把数据管好、把角色边界定好、把回溯链路打通比用哪个大模型重要得多。另外一个想说的是别贪多。如果让我重新来一次我会从一个高频小任务切入比如先只做“公告事件分类和推送”验证价值后再逐步接研报、接新闻、接宏观数据。我一开始希望一个系统解决所有问题结果做了很多功能没人用维护起来还特别累。聚焦用户每天必须做的那件事让AI把它做到让人需要依赖系统才算真正立住。如果这个系统要扩展我下一步会重点做两件事一是把知识图谱做深让公司与上下游、股东、行业之间的关联关系真正参与检索而不仅仅是用关键词匹配二是把用户反馈闭环做起来研究员在界面上的每一次“有用/没用”标记都回流到数据层去调整事件规则和评分参数。这两件事推进的方向都是让系统从“读得懂文件”走向“读得懂业务”。