聊到“百亿token”和“投资agent”这两个词放在同一个标题里大多数人第一反应是这是不是哪个量化团队在炫技真不是。我在这个项目上从零开始手搓了一整套投资分析agent系统中间踩了无数坑也把很多“看起来高大上”的方案按在地上摩擦过。先把结论摆在最前面百亿token这个量级真正要解决的不是“模型能不能读完”而是“海量数据怎么组织、怎么检索、怎么让agent只拿该拿的信息来推理”。这篇文章我会从数据管道的搭建、向量化检索、记忆机制、决策逻辑、再到推理编排和成本优化一条线完整讲清楚配合真实实操中的参数和取舍。适合正在做RAG类应用、想搞懂投资分析与大模型结合方式、以及所有好奇“百亿级知识库到底怎么落地”的人。哪怕你目前只处理百万级别数据这套架构思路同样能直接平移。1. 百亿token到底是个什么概念先别被这个数字唬住1.1 用生活化类比理解百亿token的体量假设一个token大概对应0.75个英文单词或者0.6到1个中文字符一百亿token落在地上差不多是七十五亿个英文单词。什么概念《红楼梦》全文也就七十多万字一百亿token相当于上万本《红楼梦》叠在一起。如果是新闻资讯类语料大概覆盖了过去五到八年的全市场公告、财报、宏观数据摘要、热点事件和大量行业知识。这个量级的文本指望任何大模型原生上下文窗口一口吞下去都是不现实的。哪怕未来上下文窗口继续扩大成本和检索精度也会让“全部塞进上下文”成为最差方案。所以“百亿token手搓投资agent”这个标题真正指的事情是你拥有了一座巨大的文本数据仓库然后用工程手段把它变成agent可以随时调取的结构化记忆。1.2 为什么投资场景需要百亿token而不是10万token有人会问我做投资分析给agent喂几百篇研报不就行了吗我的回答是单纯做短线情绪分析几百篇确实够。但如果你想要agent理解一家公司的历史沿革、行业周期的位置、上下游关系、以及历史上类似事件发生后的市场反应那就必须依赖长周期、跨来源的海量非结构化文本。百亿token不是拿来“全文阅读”的它是拿来“出题考核”的。agent每次回答问题时检索系统从这一百亿token里捞出最相关的几百个片段交给模型去理解推理。这个“从海量数据里精确捞取”才是整个系统真正的技术分水岭。1.3 谁适合读这篇需要什么前置知识我会尽量写得像一个工程复盘而不是学术论文。你只要满足三个条件就能顺畅读完全文了解Python基础语法哪怕没写过完整工程项目也没关系。大概知道大模型API怎么调用比如会构造一个简单的提示词请求。对投资分析的常识性框架有一定认知比如至少听过市盈率、市净率、财报、舆情这些词。如果你目前是零基础建议先把Python和数据处理的入门知识补一补再回来看这篇。这篇文章的重点是架构设计和实操细节不会手把手教编程基础。2. 整体架构设计与方案取舍为什么我选择手搓而不是套框架2.1 先搞明白“投资agent”在这个系统里的具体定义很多人误解了“agent”这个词以为就是一个带记忆的聊天机器人。在这里投资agent指代一个能完成“收集信息-整理证据-形成观点-提示风险-给出行动建议”完整闭环的自动化系统。它不是简单问答它会自己判断什么时候需要检索历史数据什么时候需要调用实时行情接口什么时候需要对比同行业其他公司并在最后给出一份带有置信度和风险提示的投资分析结论。我最初也尝试过直接用现成的Agent框架和RAG方案快速搭一个原型。原型跑通只花了三天但当我开始往里面接入真实投资数据、处理上万份财报PDF、清洗乱七八糟的新闻源时问题全面爆发有的框架在处理超长PDF时内存直接撑爆有的在召回时把完全不相关的公司信息混进来有的连基本的时间过滤都做不了。到了这一步我才决定全部推倒重来自己手搓。2.2 手搓的决定性理由可控性、成本、定制化我总结下来选择手搓不是情怀是以下三个现实因素第一可控性。投资数据对时效性和准确性要求极高。比如一条新闻发布时间晚了一小时可能导致整个分析结论过时。自研管道要求每一环节可监控、可重放、可修正框架里封装好的黑盒流程很难做到这个颗粒度。第二成本。百亿token的数据处理如果用某个托管平台的现成向量化服务按全量处理一次来计算费用会非常惊人。自研方案可以把那些低价值的段落用轻量级关键词索引存下来只有高价值部分才做完整向量化综合成本能降一个数量级。第三定制化。通用RAG框架的默认分块大小、检索逻辑、排序策略都是基于“论文问答”优化的。投资场景里一份财报、一条公告、一篇深度研报它们的重要程度和可信度完全不同。在通用框架里你很难给不同数据源设置不同的权重和过期策略自研之后这些都可以按需配置。2.3 系统五大模块的总体画像整套系统按数据流分成五个核心模块串起来就是一条流水线数据接入与清洗层负责从公开数据源获取公告、财报、新闻、行情快照做去重、去噪、格式化。知识存储与索引层分为原始文本存储、向量索引、关键词索引、结构化摘要存储四部分。混合检索引擎负责把用户的自然语言查询转换成关键词检索和语义检索两条线再统一重排。推理与决策模块这是Agent大脑所在位置负责调度检索、阅读结果、分析证据、生成结论。行动与反馈模块负责生成最终输出、触发预警、记录日志、收集人工反馈。模块间通过消息队列解耦。数据清洗是异步的检索是实时的推理是同步的。这样的好处是数据管道即使在凌晨跑批白天也不影响实时查询。3. 手搓核心管道百亿token的数据清洗、分块与索引策略3.1 数据源分层与优先级设计不是所有数据都值得一视同仁地处理。对于投资分析场景我把数据源分成三个层级第一层级是强结构化高置信数据比如上市公司财报、正式公告、监管文件。这类数据权威性最高直接决定基本面分析质量必须全文向量化并且保留全文原文以备查验。第二层级是半结构化资讯数据比如财经新闻、券商研报摘要、行业统计。这类数据量大、更新快需要做摘要向量化同时保存全文供回溯。第三层级是弱结构化和噪音较多的数据比如社区讨论、论坛帖子、自媒体内容。这类数据情绪价值大于事实价值一般不直接作为决策依据只做情绪热度统计和关键词监控。这个分层的意义巨大。百亿token听起来很多但如果把第三层级数据全部做详细加工性价比极低。我把三层数据分开建管道处理成本差异非常明显。3.2 清洗去重看似不起眼实际是决定检索质量的第一步这个环节是我踩坑最多的地方没有之一。原始网页拿下来之后页面导航、广告、底部的“相关阅读”这些东西会混进正文里。如果直接切分喂给模型检索出来的片段经常是一堆无意义文字让agent误以为找到证据。我的处理流程是统一编码格式处理BOM头和乱码字符。用正文抽取算法提取主体内容去掉导航栏、页脚、脚本代码。做URL归一化把同一篇文章的移动版、PC版、带追踪参数的版本合并。对全文计算SimHash指纹设定阈值剔除近似重复文字。对财报和公告这一类文档重点保留表格和数字因为表格中的财务数据往往是结论的关键支撑。去重这步最怕“过度清洗”。我试过一种激进的段落级去重策略结果把同一季度内多家公司公告里相似的政策性套话全部删掉导致后来检索“行业政策影响”时找不到关键原文。后来我改成“文档级指纹段落级重复率双阈值”方案才平衡了去重率和完整度。3.3 分块策略按语义段落切割还是固定长度切割分块是RAG系统里最容易被低估的环节。很多人上来就按512个字符硬切切出来的块经常一句话拆成两半语义断裂严重。我在项目里最终采用的方案是“三明治分块法”先用段落边界做基础切分每个段落自然成为一个候选块再把相邻的短段落合并目标是让每个块大约包含300到500个token最后给每个块增加一个重叠窗口把前一个块的结尾和后一个块的开头各截取50个token拼进当前块。这个重叠窗口的作用是防止关键信息恰好落在切分缝上。举一个实际出现的例子某公司公告里有一句话“公司将终止收购计划”如果恰好被切成“公司将终止”和“收购计划”两段检索“收购进度”时第二段虽然能命中但第一段的否定语义丢了agent可能给出完全反方向的结论。加上窗口重叠后这类bug的出现频率大幅下降。3.4 增量索引与全量重建百亿token不可能频繁整体重建刚开始做的时候我犯过一个严重的错误每次更新数据就全量重新向量化一遍。当时数据量在千万级一次全量跑下来要十几个小时基本等于没法用。后来改成增量更新机制每日新增数据先进入热区缓存满足一定条数后批量向量化写入当前索引每周做一次合并段整理每月在低峰期做一次全量索引重建消除累积的碎片和无用版本。对应到投资场景还有一个特殊考虑老数据不能随便丢。两年前某行业的一条政策新闻在当下可能因为相似事件再次成为热点这时候agent就需要回溯到那条老数据。所以索引层必须做冷热分离热点年份和当前行业热点覆盖的时段放在快速索引更早期的数据用压缩存储需要时再按需解压检索。4. 向量化与检索让agent真正具备“读遍百亿token”的体感4.1 嵌入模型选型中文投资语料对向量模型的考验在向量化选型上我先后对比过多种开源和商用嵌入模型。投资语料有几个特点专业术语密集、数字与上下文强相关、时常出现中英文混排比如“PE TTM”“ROE”“EPS”。这些特点让很多在通用语料上表现优异的嵌入模型直接翻车。我最终的选型逻辑是优先选择专门针对中文优化的模型在中文相似度评测集上要有公开指标做参考。要求模型能处理最多512token以上的输入长度方便长段落整体编码。在实际样例上人工评测“检索相关性”不只看公开榜单分数。实际测试时我会抽二十个典型query比如“某公司连续三年的毛利率变化”“新能源汽车补贴退坡对行业利润的影响”然后看返回片段里有多少是真正有效答案。选型阶段花了整整两天但这个投入换来后续检索质量的整体稳定。4.2 向量数据库选型内存、召回精度、成本怎么平衡百亿token全量向量化的存储压力比大多数人想象中大得多。一个512维向量用float32存储就是2KB如果全量一亿个片段就是200GB。这个量级如果用纯内存方案成本非常惊人。我的选型决策基于以下三点考量数据规模匹配当前百亿token对应约数百万到千万级向量片段不一定要上分布式单机高性能向量库完全能扛。时效性要求投资场景对插入延迟有一定要求新公告出来最好几分钟内就能被检索到所以不支持增量插入的库直接排除。混合检索能力纯向量检索在股票代码、专业缩写这些“关键词强相关”的场景下会失灵所以库里必须集成关键词匹配能力或者能在检索前做布尔过滤。最终我选择了一款开源向量库作为核心存储配合一个轻量级的倒排索引组件承担关键词检索。实测在千万级向量规模下单次混合查询延迟稳定在200毫秒以内完全满足实时问答需求。4.3 混合检索向量召回关键词召回重排序三段式只靠向量检索在投资场景里会出两种典型问题。第一种是“语义相近但实体无关”比如你问A公司的盈利能力向量模型可能把B公司的类似表述也捞回来因为两段话语义结构太像了而模型没听懂公司名是不同实体。第二种是“专用术语召回失败”比如精确搜索“商誉减值”向量检索大概率会把“商誉”“减值”拆开理解返回一堆泛泛而谈的内容。解决办法是混合检索分三条路同时走语义路先把query编码成向量在向量索引里做ANN检索取回top100。关键词路用BM25算法在倒排索引里按关键词匹配取回top50。结构化过滤路如果query里识别出股票代码、财报年度、行业标签就用元数据过滤在结果集里精确定位。三条路的候选汇合后进入重排序阶段。我使用的是交叉编码器rerank方案把query和候选片段拼在一起做深度语义匹配输出相关性分数。这个环节能把前面粗召回里的噪音果断砍掉。最终只有重排序分数达到阈值的结果才会进入agent的上下文窗口。4.4 命中阈值与结果裁剪宁可少给不要给错这一点是我最想强调的实操经验。很多RAG系统的问题不是召回太少而是召回太杂。给了agent十个片段其中三个不相关大模型有概率把不相关的内容也写进推理过程导致结论被污染。我在系统中设置了双重保险相关性阈值重排序后得分低于设定值的片段直接丢弃哪怕召回总量很少也绝不硬凑。引用强制校验agent在生成结论时每一条关键判断后面必须跟上引用来源编号如果某个判断没有对应引用我会在后续校验层里标记“无依据结论”。刚开始使用时我总担心阈值设太高会让agent变成“信息哑巴”。但跑了两个月的实际案例后我确认投资分析宁可结论偏保守、引用充分也不要给一堆似是而非的证据。5. 记忆机制短期、长期和工作记忆如何支撑多轮投资分析5.1 短期记忆会话窗口内的上下文管理投资分析很少是单轮对话就能完成的。用户可能会先问“某公司最近经营情况怎么样”再追问“那这和它去年说的战略方向一致吗”最后还会问“跟同行比它的优势还在不在”。这三连问中后面两个问题严重依赖第一轮的上下文。我参照常见的大模型对话管理方案把会话最近十轮交互内容和检索到的数据片段共同作为短期记忆放在每次请求的上下文里。短期记忆不是无限增长的。超出窗口后早期的对话内容会被浓缩成摘要替原始文本进入上下文。这样既保留了关键用户意图又不会无限挤占token预算。5.2 长期记忆跨会话的持久化知识投资分析有个很实际的场景用户上周问过“某行业当前景气度如何”这周又问“这个行业有没有转弱迹象”。如果系统没有长期记忆第二问就得重新检索全部资料浪费大量计算资源和时间。我设计了两个长期记忆层。第一个是“用户偏好层”记录用户常关注的行业、喜欢的分析维度比如有人重视现金流有人重视市场份额后续检索时会给对应数据源加权重。第二个是“积累结论层”把agent过去生成且被用户确认有效的分析结论以摘要形式存储下来后续遇到同类问题时优先检索这些历史结论避免重复推理。长期记忆最大的坑是“记忆污染”。如果一条过时的错误结论被长期存储它会在之后很长的周期里反复影响判断。所以在写入长期记忆前必须经过置信度打分只有检索证据充分、且和当前公开数据无明显冲突的结论才允许入库。5.3 工作记忆每次推理时的临时信息组织工作记忆对应的是agent在单次任务推进过程中产生的中间信息。比如agent决定先查行业数据再查公司财报最后对比同行估值。这些中间查询获得的结果需要有一个临时空间暂存后续生成结论时引用。很多人忽略工作记忆的设计导致agent在一个任务里重复检索相同内容。我在系统里给每个分析任务建了一个临时工作区把已经检索到的片段去重后按主题归组之后的每一步推理都可以直接引用不必重新检索。这个改动让单次分析的平均token消耗降低了差不多两成同时推理流程明显变快。5.4 查询改写用户问完一个问题agent要先具备“翻译能力”用户的查询往往简短模糊比如“半导体最近怎么样”。如果直接拿去检索返回内容会很发散。我在检索引擎前面加了一个查询改写层由大模型把用户问题转成一连串具体检索子意图。比如“半导体最近怎么样”会被改写成以下检索计划近一个季度半导体行业指数走势头部晶圆厂最新月度营收和产能利用率行业政策或重大事件时间线卖方机构对半导体景气度的最新研判产业链上下游的库存变化信号改写后分别执行不同方向的检索任务再把结果合并进工作记忆。这一步极大提升了检索针对性尤其适合投资领域这种“一个模糊问题背后有明确分析框架”的场景。6. 投资决策逻辑从信息检索到观点生成的完整链条6.1 信号收集基本面、技术面、资金面、情绪面四维框架投资决策不能只看单一维度的信息。我的agent在设计时按四条线并行收集信号基本面关注财务数据、盈利能力、资产负债结构、成长性指标和经营现金流技术面关注价格趋势、成交量和关键均线位置资金面关注融资融券余额的变化、主力资金净流入流出、机构持仓变动情绪面关注新闻舆情的情感倾向、社区讨论热度和搜索指数趋势。四条线的信号最终以结构化JSON格式汇总到决策引擎。这里不得不提一个实践心得专业投资者和普通用户看重的维度不一样——专业用户喜欢看那些能直接改变估值模型预期的信号比如毛利率拐点、应收账款异常上升而普通用户可能更关心涨跌直观感觉。系统的信号权重表需要支持按用户类型动态调整。6.2 证据链构建结论必须有依据禁止凭空断言因为大模型天然的生成特性它非常容易在分析中“脑补”。比如用户问“某公司是否值得投资”模型可能直接给出“由于公司拥有技术优势因此值得关注”这种空泛话。为了对抗这个问题我在决策引擎里强制要求证据链结构。证据链包含四个要素事实依据、来源引用、时效标签和置信度。以判断依据为例其结构大致是{ claim: 公司第三季度毛利率环比提升2.3个百分点, evidence_source: 公司第三季度财报_利润表, publish_date: 2025-10-30, confidence: 0.92, reasoning_note: 营收增长同时销售费用率下降毛利率改善主要由规模效应驱动 }所有判断先以这种结构生成中间节点再汇总成段落化结论。任何没有证据支撑的断言都会被标记为“待验证”在最终输出中降低权重或直接省略。6.3 回测与样本外验证分析框架不能做“看图说话”投资分析系统的准确性必须用历史数据回测。我在开发过程中把过去五年内发生的典型投资事件整理成测试集比如特定行业的政策冲击、龙头公司的业绩爆雷、宏观流动性拐点让agent回到事件前的时间点进行分析再看它给出的判断和实际走势是否一致。这轮回测抓出了不少问题。印象最深的是一次测试中agent始终倾向于忽略负面数据只引用支持性的正面证据属于典型的确认偏误。后来我在信号汇总阶段增加了“负面信号强制呈现”机制要求agent在给出结论前必须列出一正一反两种证据再说明为什么最终判断倾向于某一侧。样本外验证也非常重要。我刻意留出近半年的数据不参与调参专门用于每轮修改后的最终验证。没有这层验证系统很可能会在历史数据上表现良好但在未来数据上一团糟。6.4 结论输出模板与合规风险提示投资分析agent的输出必须带一套标准结构不能只给用户一句“建议买入”。我的系统输出的模板固定为五段核心结论一句话概括当前判断。关键证据列出整条证据链中最有影响力的五到八条。风险提示至少列出三条可能导致判断失准的因素。关键监测指标接下来需要重点跟踪的数据指标。免责说明明确提示内容仅供参考不构成投资建议。强制设置这个模板的初衷很直接避免用户把agent的输出当成“投资圣旨”。在真实的投资决策链条中agent只承担信息收集和初步分析的角色最终决策必须由人类自己完成。7. 推理引擎与提示词编排让agent学会自我校验7.1 ReAct式推理循环思考、行动、观察的迭代我在决策引擎中采用了类似ReAct模式的推理循环。agent不是一次提示词就输出结果而是循环执行“思考-行动-观察”若干轮直到确认证据充分才进入最终结论生成。为了让你理解这个过程我简化描述一下典型的执行流程第一轮agent收到“分析当前消费行业景气度”的任务思考后判断需要先获取消费板块整体行情和社零数据于是发起对应的检索行动观察返回结果。第二轮agent观察到社零数据增速放缓决定进一步检索消费细分龙头的最新财报和机构观点执行新一轮检索行动。第三轮agent发现宏观数据与微观公司表现存在背离又主动检索历史上类似背离出现后的行业走势。直到第三轮结束agent判断信息已能满足分析需求才进入结论生成阶段。7.2 提示词模板系统提示词里必须写清什么我整理了一套在生产环境长期打磨过的系统提示词要点分享几个核心规则角色设定要明确但不要死板。要让agent知道自己是“投资研究分析助手”而不是“股票推荐机器”。工具边界要写死。比如查询当日行情用什么函数、检索历史公告用什么函数每次行动必须显式调用工具不允许编造数据。输出约束要具体。比如“所有结论必须引用检索到的资料编号禁止无引用断言”“风险提示部分必须至少写三条”。自我检查机制要内置。在提示词末尾增加一步“在给出最终结论前请检查是否遗漏了与你结论相反的证据。若有请说明理由。”这些提示词细节看上去琐碎但它决定了agent在自由度很高的任务里是否跑偏。7.3 工具调用与路由机制不同问题要路由到不同工具。比如“未来走势预测类”不能只靠检索文本必须附带行情接口的实时数据“财务解读者”需要调用财报解析模块做指标抽取。我在路由层维护了一个意图列表每个意图绑定一组工具组合。路由的准确度直接影响agent表现。我最初用关键词规则做路由效果很差因为自然语言有太多变体。后来改成“小模型分类规则兜底”先让一个轻量级分类模型判断意图类别再辅以关键词正则校验错误率降到了可接受范围。7.4 幻觉抑制最终输出前强制引文一致性校验生成阶段完成后还会执行一道独立的校验程序用规则检查模型生成的每一句判断是否能在检索结果中找到对应支撑。具体做法是把生成文本拆分成断言句提取句子里的关键实体和数字再与检索结果片段做匹配。如果某一断言完全找不到对应出处该断言会被单独标红要求模型重写或删除。这套校验不能做到百分之百消灭幻觉但对于杜绝“凭空捏造数据”这一类危害最大的问题有非常显著的效果。在三个月实测里产出内容的数据类幻觉从早期的一周十几个降到了平均两三周一个而且大多数时候还是因为检索源本身就存在同主题歧义。8. 成本、性能与部署优化百亿token不是一次性买卖8.1 全量向量化的成本估算与分档处理我把真实的成本结构拆给你看。假设一亿个文档片段每个片段400token总共四百亿token需要向量化。如果全部走商用embedding接口按常见定价折算单次全量处理费用会是六位数以上。如果每天还有增量数据持续进来月成本非常可观。所以我采用了分档规则高价值数据财报公告、深度研报摘要使用最强效能的嵌入模型完整向量化。中等价值数据新闻正文、行业统计使用轻量级嵌入模型保留维度信息但降低精度。低价值数据论坛、自媒体噪音内容只做关键词索引不做语义向量化。这样的分档处理让全量成本压到原本的三成左右而检索质量几乎没有明显下降。原因在于投资场景里真正决定结论质量的核心数据永远是那百分之二十的高价值信息源。8.2 缓存策略相同问题不重复计算投资分析中用户会反复查询高度相似的问题尤其是“某公司当前基本面如何”这类高频问题。如果不做缓存每次刷新页面都要重新检索再加上一次完整推理成本和延迟双重爆炸。我设置了三层缓存结果缓存同一个query在短期内直接复用上次的最终回答适合五分钟内的重复查询。检索缓存检索结果按“查询改写后的多组关键词向量”做键值存储一天内的重复检索直接命中。片段级缓存对于热度极高的一批公司核心跟踪池相关的高价值片段预载入热内存查询时优先走索引。缓存键必须包含时间维度。投资数据的时效性非常敏感一周前的检索结果可能已经过时。所以所有缓存都带有时间戳超过有效期自动绕过缓存直查。8.3 并发与延迟优化实时问答必须控制在秒级针对实时问答场景我要求端到端延迟不超过三秒。这里分享三个影响最大的优化动作第一是检索和推理并行化。用户发起问题后检索引擎在改写查询的同时预加载一批候选数据不必等改写完成才启动检索。第二是对热数据做预计算。核心公司的常见分析维度在后台预先完成一轮推理用户提问时直接替换参数产出结果。第三是重排序阶段采用batch处理。把粗召回的所有候选片段一次打包放进rerank模型而不是逐条推理。做完这三项优化之后常见的“某公司分析类”问题延迟从五六秒降到了两秒左右体感上基本与普通搜索引擎一致。8.4 监控、日志与迭代机制不观测等于没做系统上线只是开始。我在整个链路里埋了完整日志每个环节都记录关键指标。数据管道记录清洗丢弃率、分块平均长度、增量索引延迟检索环节记录召回总数、重排后保留数、平均分生成环节记录结论引用覆盖率、断言无引用率、输出token数。每周我会拉一份质量报告重点看两个异常指标一是无引用断言的比例是否上升二是检索结果里前三名平均分是否下降。前者指向模型推理稳定性问题后者指向索引新鲜度问题。根据指标变化调整清洗规则或索引重建频率整个系统才能在持续运行中保持稳定的质量曲线。9. 常见问题与排查实录我替你踩过的坑9.1 召回结果相关但无用到底哪里出了问题有一段时间系统频繁出现这种状况从语义上看检索结果确实和用户问题高度相关但内容是泛泛而谈的行业套话对具体结论没有帮助。排查后发现原因出在分块阶段——大量文本被切成了语义完整但信息密度极低的段落嵌入模型给这些段落打了虚高相似度挤掉了那些信息密度高但措辞完全不同的真正有价值片段。解决方案是给分块阶段增加密度过滤计算每个片段的信息密度指标比如数字出现频率、专有名词数量、时间实体数量密度过低的片段降权处理只在召回数量不足时兜底使用。上线后召回质量立刻上了一个台阶。9.2 时间错乱大模型把老新闻当成了新事件实测中遇到过最危险的错误之一是agent把一条两年前的旧政策解读当成了当下新发生的事件来引用导致分析结论完全脱离现实。原因是检索系统没有做严格的时间过滤重排序模型又对时间不敏感模型看到“政策发布对行业影响重大”就直接采信了。修复措施是双管齐下在检索阶段强制绑定时间范围过滤条件凡是和query时间不匹配的结果直接排除在生成阶段要求模型明确输出每条引用的发生时间并把时间校验加进引文一致性检查中。从那以后时间错乱问题基本绝迹。9.3 精确数字被清洗规则干掉数据处理管道的去重和清洗逻辑曾经误伤过一批关键数字。原因是当时采用了一条激进的启发式规则删除含有大量重复模板文字的文章段落。结果有些财报电话会议记录里管理层反复强调的核心数据也被连带删掉了因为那段话在会议纪要里以类似措辞出现了好多次。这个坑给我的教训是清洗规则必须分层执行高危动作只能作用在低价值数据源上高价值数据源的清洗要保守再保守。现在我对财报核心章节只做格式统一和HTML标签去除不做任何内容级别的过滤。9.4 agent在工具调用中无限循环早期的推理循环有一个让人抓狂的bugagent为了确认某个数据反复调用检索工具每次检索回来后发现自己还需要另一个维度数据又发起新的检索最终陷入十几轮工具调用无法收敛。修复方式是给推理循环加了两把锁最大工具预算单次分析任务最多允许八次工具调用超过后强制进入结论生成阶段信息覆盖检查每次观察后先判断当前已获取信息是否覆盖query改写阶段设定的所有子意图全部覆盖则立即收敛输出。这套机制上线后单次任务的平均工具调用次数从十次以上降到了五次左右。9.5 合规风险投资agent的内容必须留好护栏最后必须重点提醒所有想复现这套系统的人投资分析场景的特殊性决定了它不能像普通聊天机器人一样“想说什么就说什么”。系统输出端必须设置多重合规护栏包括明确的风险提示声明禁止出现绝对化表述类似“一定涨”“稳赚”等词要直接拦截改写对涉及具体投资标的的答案强制附带“信息仅供参考不构成投资建议”的声明保留详细的分析日志以备追溯。这些护栏不是为了应付监管而是对自己系统的一种保护机制。有了这层约束至少能避免因为agent一句不经意的话引发错误决策最后责任落到系统建设者头上。写到这里我想把整个项目最核心的体会浓缩成一件事百亿token本身不是问题问题是如何在恰当的时间把恰当的信息放到模型眼前。数据清洗决定检索质量的下限混合检索决定知识覆盖的广度推理约束决定结论的可靠程度缓存和成本优化决定系统能不能长期跑下去。如果你打算在自己的场景里复现这套架构我建议先不要急着追求规模。把十万条高质量数据完整跑通整个链路再逐步扩展数据量级。小数据下暴露出问题并修复的代价比在大数据规模下推倒重来要低得多。