聊到“百亿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在工具调用中无限循环
早期的推理循环有一个让人抓狂的bug：agent为了确认某个数据，反复调用检索工具，每次检索回来后发现自己还需要另一个维度数据，又发起新的检索，最终陷入十几轮工具调用无法收敛。
修复方式是给推理循环加了两把锁：最大工具预算，单次分析任务最多允许八次工具调用，超过后强制进入结论生成阶段；信息覆盖检查，每次观察后先判断当前已获取信息是否覆盖query改写阶段设定的所有子意图，全部覆盖则立即收敛输出。
这套机制上线后，单次任务的平均工具调用次数从十次以上降到了五次左右。
9.5 合规风险：投资agent的内容必须留好护栏
最后必须重点提醒所有想复现这套系统的人：投资分析场景的特殊性决定了它不能像普通聊天机器人一样“想说什么就说什么”。系统输出端必须设置多重合规护栏，包括：明确的风险提示声明；禁止出现绝对化表述，类似“一定涨”“稳赚”等词要直接拦截改写；对涉及具体投资标的的答案，强制附带“信息仅供参考，不构成投资建议”的声明；保留详细的分析日志以备追溯。
这些护栏不是为了应付监管，而是对自己系统的一种保护机制。有了这层约束，至少能避免因为agent一句不经意的话引发错误决策，最后责任落到系统建设者头上。
写到这里，我想把整个项目最核心的体会浓缩成一件事：百亿token本身不是问题，问题是如何在恰当的时间把恰当的信息放到模型眼前。数据清洗决定检索质量的下限，混合检索决定知识覆盖的广度，推理约束决定结论的可靠程度，缓存和成本优化决定系统能不能长期跑下去。如果你打算在自己的场景里复现这套架构，我建议先不要急着追求规模。把十万条高质量数据完整跑通整个链路，再逐步扩展数据量级。小数据下暴露出问题并修复的代价，比在大数据规模下推倒重来要低得多。
