1. 从“百亿token”说起这个投资Agent到底想解决什么问题如果你关注AI应用最近半年应该经常听到“Agent”这个词。投资领域尤其热闹各种“AI炒股”“智能投顾”的噱头满天飞。但大多数玩意儿是把几个新闻关键词喂给大模型让它输出一段“看多”“看空”的废话本质上就是个套壳聊天机器人。我这次要讲的是一个完全不同的东西一个把数据底座建立在百亿token级别语料库上的投资Agent。它会读完整年的财报、公告、研报、宏观数据、产业链新闻甚至包括电话会议纪要、招股书、监管处罚文件等非结构化文本再通过多步骤推理给出带依据的投资判断。整个过程不需要人工去整理“重点”而是让Agent自己在海量文本中形成观点。听起来有点科幻但把它拆开来看核心其实就是三件事把百亿token的数据管好、让大模型在海量上下文里精准取用信息、以及设计一套可靠的投资推理闭环。这个项目我从数据清洗到推理评估做了两个多月踩坑无数今天把整个系统的工作原理、架构设计和实操细节一次性讲清楚。先说结论百亿token本身不是目标而是手段。只有当你的语料库足够大覆盖足够全Agent的“记忆”才不会变成“偏见”——就像分析师不能只看一家公司的三张报表他得了解行业、竞争对手、客户、政策和宏观环境。Token量级决定Agent视野的广度推理链路则决定它能不能把视野转化为有效判断。这篇内容面向的读者主要是正在做RAG系统但觉得检索效果不理想的人、想在金融领域落地大模型应用的工程师以及好奇“AI投资到底靠不靠谱”的产品经理。我会尽量把设计里的“为什么”也讲明白而不是只给结论。2. 整体架构设计从文档到投资决策的完整链路整个系统可以分成四层数据接入层、索引与存储层、推理编排层、输出与评估层。听起来很常规但每一层都有针对投资场景的特殊设计。数据接入层负责从多个渠道获取原始语料财报PDF、公告文本、券商研报、新闻资讯、交易数据JSON、宏观指标等。原始数据格式异常混乱PDF里既有扫描件也有文字版财报有的用表格有的用大段叙述研报动辄几十页且大量套话。所以接入层不只是“下载文件”还兼顾格式解析、去重、时间戳对齐和初筛。索引与存储层是百亿token的关键所在。这里我做了两级存储原始文档存储和向量索引。原始文档按parquet格式落盘按行业、发布时间、文档类型分区向量索引用在召回阶段。百亿token大约对应多少存储量按中文平均1.5字符/token计算大约150亿字符以UTF-8编码约300GB原始文本。向量化后如果用768维向量每条分块约500token总共约2000万个向量块仅向量文件就有60GB以上。这个体量已经超出单机内存舒适区必须上分布式检索或服务端向量数据库。推理编排层是Agent的大脑。它负责理解用户问题、制定信息获取计划、调用检索工具、阅读并组织上下文、进行多轮推理。我参考了ReAct模式但做了大量金融场景定制。Agent不是一次性把所有百亿token都塞进上下文——上下文窗口再大也扛不住百亿token——而是通过“提问-检索-阅读-再提问”的循环来逼近答案。这个过程类似分析师看材料先看目录找到重点章节精读核心内容发现新线索后继续追查。输出与评估层我们把Agent产出的判断和逻辑依据回测对照同时对“推理是否忠于证据”做人工抽检。整个系统的核心设计原则只有一个永远不要让模型在没有证据支持的情况下生成投资观点。所有结论至少需锚定一篇文档。为了落实这个原则推理层的大量工作是“找证据”而不是“想观点”。这跟外行理解的“AI炒股模型一拍脑袋说买”完全不同。3. 数据流水线全解从原始语料到可检索知识库3.1 数据源接入与格式归一化我实际接入的数据源有六类定期报告年报/半年报/季报、临时公告、券商研究报告、新闻资讯流、宏观行业数据库、交易所监管文件。每类数据的更新频率、文件格式、内容噪声都不一样清洗策略也不同。定期报告PDF为主重点是解析表格结构。我对接了多个解析器实测下来扫描版财报只能走OCR准确率约95%文字版则优先用PDF文本抽取表格用坐标定位重建。券商研报页数长、水印多、免责声明多。研报价值高的部分在“盈利预测”“评级调整”“核心假设”这些章节其余多是重复的市场综述。新闻资讯质量参差需要做严重的去重。同一事件会有几十家媒体转载标题略变内容基本相同。我用正文MinHash去重后又结合发布时间的近邻去重过滤掉了大约60%的冗余内容。宏观数据库通常是CSV或JSON字段规整直接导入宽表存储。注意财报PDF的表格解析是最大的坑。很多PDF的表格不是真正的“表格”而是用文本框拼出来的。你看起来是一张表抽取出来却是乱序文本。我的方案是先用坐标聚类识别行列结构再结合表头信息重建。这个步骤没有开箱即用的工具需要投入工程时间。3.2 清洗规则噪声去除、正文抽取与水印处理清洗决定了索引质量的上限。垃圾进垃圾出到这里体现得淋漓尽致。我在清洗流水线上做了这些事正文区域检测。很多PDF页面顶部是页眉、底部是页码两侧有图表注释。我用规则模型双路检测正文边界规则负责兜底模型负责处理规则覆盖不了的复杂版面。水印和免责声明去除。研报几乎每页都有“本报告仅供内部使用”“市场有风险投资需谨慎”等水印。这些内容不仅没价值还会在后续语义检索时产生严重噪声。我的处理方式是构建了一套高频模板库基于正则批量替换。表格内容转写为Markdown格式。这对后续大模型理解非常关键。原文的表格在PDF里是二维排版抽取后是一维文本。转成Markdown表格后大模型对数值关系的理解能力明显提升。去停用词和低信息段落。财报里大量套话比如“公司所处行业面临新的机遇与挑战”这类句子没有信息量。我用“信息熵规则模板”打分把低分段落直接丢弃。清洗后数据量会显著下降。我跑过一批月度的全市场公告数据原始体积约120GB清洗后剩约85GB其中表格内容占了很大比重。3.3 分块策略为什么固定窗口分块在财务场景不适用这是全文最重要的实操点之一。通用RAG常用固定大小分块比如每块512token这在金融场景表现很差。原因有三财务披露有极强的上下文关联。一家公司的年报里“经营活动产生的现金流量净额”必须和“净利润”放在一起对比才有意义。固定窗口很容易把这两个数据切成两半。同一事件往往跨文档存在。比如公司发布业绩预告三天后再发布修正公告两份文档描述的是同一件事但固定分块无法建立关联。表格结构需要整体保留。一个包含几十行数据的财务表格固定窗口分块会把它拦腰截断使模型完全读不懂。我采用的分块逻辑是结构感知层级分块先把文档解析成DOM树标题→章节→段落→表格。对每个叶子块按语义边界做自适应切分最小256token最大1024token。表格单独作为一个分块单元保证完整性。章节标题作为块的元数据参与向量编码和检索排序。这套方案让检索命中率Recall10从固定窗口的58%提升到了81%。提升主要来自表格完整保留和章节语义聚合。3.4 向量索引构建Embedding选型与分批建索引的工程实践Embedding模型的选择决定了语义检索的上限。我对比过几类主流中文向量模型包括开源通用模型和闭源API模型。最终选择的是在金融中文语料上表现最好的开源方案768维支持最长512token输入。这里有三个工程层面的细节值得分享第一Embedding输入长度限制问题。我的分块长度最大1024token而Embedding模型只支持512。所以我把分块拆成两段分别向量化然后取平均——稳妥但会损失一点精度。更优方案是优先保头部信息长块只编码前512token因为关键信息通常在章节开头。第二批量向量化的性能坑。我开始用单进程跑2000万分块的向量化预估要跑9天。后来按8卡分布式并行同时优化数据加载和请求并发压缩到了14小时。如果平台支持端侧向量化强烈建议自建推理服务别用慢速接口否则百亿token的周期不可接受。第三索引持久化。向量索引一定要做增量更新。每天新增语料可能几GB全量重建索引代价过高。我实现了“新数据先入库检索时新旧索引分别查询再合并结果”的方案延迟增加约30ms但免去了每日全量重建的烦恼。4. 检索不是“搜相似”探索式检索与上下文构建4.1 从单次检索到探索式查询传统RAG的应用方式是用户提一个问题系统做一次向量检索拿4-6个相关片段塞给大模型生成回答。这在知识问答场景还行但投资分析远复杂于此。举个实际例子。用户问“某公司今年利润大幅增长原因是什么是否可持续”要回答这个问题需要同时获取公司财报中的利润分项数据、管理层讨论与分析中的原因说明、行业新闻中关于产品价格的报道、券商研报中的供需判断。一次向量检索很难同时覆盖四个维度。所以我把单次检索改成探索式多路检索。Agent先拆解问题生成3-5个不同角度的子查询每个子查询用不同的检索策略然后合并结果、去重、汇总。比如上面那个问题Agent定义的子查询可能是该公司最新报告期净利润及同比变化公司报告期内主营业务收入分产品情况行业供需格局与价格走势券商对公司利润增长驱动因素的分析每个子查询独立走“向量召回关键词召回文档过滤”的复合通道最后汇总。这个设计显著提升了信息覆盖面但代价是需要几十次检索调用延迟从单次检索的0.5秒上升到4-8秒考虑到Agent的“思考”时间用户还是可以接受的。4.2 混合检索向量、BM25与时序过滤的三重奏纯向量检索在财务数据上有一个致命弱点它对精确数字和实体不敏感。你问“2023年营业收入”向量检索很可能召回一堆关于“2022年”“净利润”的内容因为它们的语义向量很接近。解决方案是混合检索向量召回负责“语义近义”匹配BM25关键词召回负责“精确实体”匹配时序过滤负责“时间范围”约束在金融场景时间过滤常常比语义匹配更重要。比如查某公司历史业绩若不限定时间范围排在最前面的永远是最近年份的文档可投资分析恰恰需要对照多年数据。我用的是RRF倒数排名融合算法合并多路结果。简单有效每路检索返回前100条每条记录一个分数最终得分是路数除以排名倒数之和最后对不同路数加权。实测下来混合检索的命中率相比纯向量检索提升约50%。4.3 上下文压缩与重排让Agent只读“该读的东西”百亿token意味着检索出来的候选可能有几十上百条。但模型上下文窗口有限而且塞入太多不相关信息会严重干扰推理质量。所以我在检索后加了“压缩-重排”两步。压缩阶段将对同一文档的多个分块做合并和去重再按与查询的相关性初步排序砍掉明显无关的。重排阶段使用重排模型Cross-Encoder对候选块精确打分取Top10-20。这里要强调重排模型一定要选金融场景适配的。通用重排模型容易把“提到关键词但语义不相关”的段落排到高位。例如“公司面临原材料价格上涨风险”和“原材料价格下降导致毛利提升”都包含“原材料价格”字样后者才是判断利润增长可持续性的关键。金融定制的重排模型对这类细微差别的判别能力要强得多。经过重排后最终喂给模型的上下文包含两部分可精读的Top5块全文级和可略读的Top10块只给摘要。这样模型既对关键证据有充分理解又保有一定视野宽度。5. Agent的“工作链”从提问到输出投资判断的完整流程5.1 理解问题生成信息获取计划整个投资Agent的推理起点是用户的输入可能是一句“分析某赛道的竞争格局”或“某公司是否值得长期跟踪”。我先用一个规划模型不能是最强模型但要有较强的指令跟随能力做任务拆解。拆解结果是一份行动计划包含需要的子问题清单、每个子问题对应的检索策略、以及预期的分析框架。例如“判断某公司新业务是否带来第二增长曲线”会被拆成市场空间有多大、公司投入多少资源、客户是否认同、与主业协同性如何、可比公司表现等。这个过程的核心是“以终为始”从最终要输出什么样的判断倒推需要哪些证据而不是漫无目的地读语料。5.2 证据收集读出关键词而不是靠模型死记硬背执行计划后Agent进入“收集证据”循环。此时每一个子问题都会被转成检索式走前面的混合检索流程。关键点来了Agent在取回文档后不直接读全文而是先使用一个轻量抽取模型提取与子问题相关的“关键词和数字”形成结构化证据。这步能显著减少噪声对决策的影响。比如子问题是“某公司近年毛利率趋势”抽取模型返回的可能是三年毛利率的数值、变化幅度、管理层归因。这部分结构化数据会进入Agent的“记忆暂存区”作为后续推理的锚点。5.3 基于证据链的推理输出整个推理链路是链式思考Agent先把证据按因果顺序组织再逐步推导结论每一步都注明对应证据。这种透明的推理过程不仅利于纠错也方便审计——审核人员能逐条检查Agent的每一步是否有材料支撑。这套推理框架借鉴了思维链思想但有两个关键差异每步推理必须有“引用锚点”锚定具体文档、章节、原句不产生悬空推理推理逻辑与投资逻辑对齐比如推导盈利变化时强制要求区分“量”和“价”的驱动、一次性因素与持续性因素等。如果你也想做投资Agent这两个差异点是决定效果是否专业的分水岭。普通RAG系统生成的结果是“摘要”这个系统生成的结果是“结论依据”区别就像“新闻报道”与“研究报告”的区别。5.4 限制语避免幻觉的最后一道防线百亿token系统生成长文时即使有证据支撑模型仍可能在表达中“脑补”一些细节。我给输出加了限制规则凡涉及数字、日期、百分比必须与原文一致否则宁可省略对原文没有明确说的事只能用“未在已检索材料中体现”来描述严禁推测结尾必须附“证据清单”列明材料来源和发布时间。这套限制让我在实际测试中明显降低了“一本正经胡说八道”的概率。早期版本不加限制时模型会在分析中虚构“同比增长30%”云云看起来非常专业但实际毫无根据加限制后这种情况基本消失。6. 评估这套Agent离线指标与实盘盲测的双重验证6.1 离线评估以人工标注为基准的命中率测试Agent训得好不好不能只看DEMO。我搭建了一套离线评测集包含300个问题覆盖行业分析、公司财报解读、事件点评、估值对比等场景。每个问题由分析师标注答案中必须出现的核心“知识点”作为评测标签。评测指标包括知识点召回率答案中召回标注知识点的比例、事实性错误数答案中与原文不符的表述数量和推理逻辑连贯性由人工打分。实测结果核心知识点召回率约82%平均事实性错误数每千字1.4个逻辑连贯性评分4.2/5。相比未加推理链的“直接问答模式”三个指标分别高了28个百分点、降低了3倍和提升了0.8分。6.2 实盘盲测不让Agent直接指挥资金离线结果好不代表实盘可用。我还有一档“影子盘”测试每天跑一次Agent的输出与真实分析师团队的观点对照。不拿真钱交易只做记录。六周盲测下来Agent观点的胜率和真实研报团队相比并不稳定有些领域宏观趋势判断Agent明显劣势有些领域财报数据异动捕捉则优于人类。这个结果我完全接受——Agent的价值不是替代分析师而是帮分析师在数亿token中发现人类注意不到的细节。它更像“超级搜索初筛助理”而不是“投资决策大脑”。另外我没有让Agent自动下单交易原因很简单当前系统的输出是分析逻辑而非交易信号缺少仓位管理和风险控制的闭环。如果你想让Agent直接管钱这条路还很长。6.3 持续监控数据漂移与模型退化的应对语料库每天更新模型能力也在迭代系统存在“静默退化”的风险——你以为它在正常工作实际因为数据清洗参数变化导致检索质量下滑最终输出质量大幅降低。我的应对是给每个数据源配置一个“数据健康检查”包括新入库数据量与近30日均值的偏差、清洗后数据保留率、索引成功率、检索无结果率。任何指标异常都触发告警自动暂停该数据源的检索避免脏数据污染结果。另外每月会抽取50条新近检索记录人工评估检索相关性。月评估能发现系统性偏差比如“某段时间因为公告格式变化导致解析失败”这些问题通常在人工评估前很难暴露。7. 实操过程中的九条血泪教训这两个多月踩过的坑比写出来的字还多。拣最重要的九条分享条条都值得收藏教训一Embedding模型不能用通用纯文本模型参数得够且要匹配领域。我一开始用了个轻量通用模型向量维度256召回率和重排结果表现都很差。换用768维金融语料优化模型后效果天壤之别。在百亿token场景模型参数量的影响会被放大不要舍不得算力。教训二PDF表格解析必须下血本。我一度想省事用现成开源库一把梭。结果财务表格被抽成错乱文本下游分析直接翻车。后来投入两周做了坐标聚类结构重建效果才稳定。这个环节没有捷径。教训三时间衰减权重必须做。早期检索结果不区分新闻时效2015年的旧闻和昨天的公告排在同等位置。后来对所有文档引入“时间衰减因子”将旧文档的相关性分打折效果才正常。金融场景里“旧闻重提”是很大的坑。教训四长文本摘要要分块进行不能一次性硬塞。早期用长上下文模型直接总结50页研报模型会抓不住重点、丢失关键数字。后来改成“章节摘要-摘要再汇总”的层级总结质量明显上来了。教训五增量索引是必须的。全量重建索引在100亿token场景不可接受光向量化就是十几个小时。合入增量机制后每天新增数据5分钟就能完成索引更新这个投入非常值得。教训六上下文窗口再大也有极限真正重要的是“精选”。与其把50个候选块都塞给模型不如重排后只喂10个高质量块。实测效果反而更好因为干扰少了。教训七要善于用“子查询”覆盖单次检索的盲区。一次查询不可能覆盖所有角度。Agent生成多路子查询是性价比最高的改进之一让回答质量提升明显。教训八输出格式和审核流程要做在前头。一开始直接输出自然语言长文人工后续核对证据非常痛苦。改成“带引用标注的Markdown独立证据清单”后人工抽检速度快了三倍。教训九百亿token不算什么关键是“可用密度”。原始语料里真正有决策价值的信息密度很低。清洗、去重、提纯比单纯堆积数据重要一万倍。8. 后续还能怎么进化三个明确的方向做完第一版后我复盘了三个值得继续深挖的方向方向一引入结构化知识图谱。现在系统主要靠文本语义检索对实体之间的关系理解较弱。如果预先构建“公司-股东-子公司-行业-产品”的知识图谱检索时可以先通过图谱做实体关联拓展再用图谱关系约束候选文档范围召回质量估计还能再升一截。方向二把交易数据和文本事件串起来。当前的系统只分析文本不看股价和交易量。如果把价格异动、成交量放大等指标作为文本阅读的“触发器”——比如先检测到某公司出现异动再反向搜索新闻、财报解释原因——Agent的分析能力会更强。方向三自我反思机制。现在Agent会生成最终结论但缺少“自我质疑”环节。如果加入一步复盘“我的结论假设了哪些条件如果这些条件不成立是否还有其他解释”输出质量可能会更接近经验丰富的分析师水平。这三个方向现在都已有初步实验但距离工程化还差得远。哪天跑通了再写续篇分享。按我自己跑下来的体会做这种量级的Agent真正难的从来不是大模型本身而是“怎么把数据治理好”和“怎么把证据链搭扎实”。大模型是放大器——数据质量高它的专业性会被放大数据脏乱差它会把垃圾加工成看上去很专业的废话。先把语料库当成产品来做Agent才不会变成一场华丽的魔术表演。最后分享一个小技巧给Agent的每一条检索指令都加上“允许承认无证据”。我发现模型一旦被允许说“该信息在现有语料中未找到”幻觉率会大幅下降。这个设置看起来简单实际效果比我调过的任何参数都明显。做投资Agent克制比聪明更重要。