百亿token这个词听起来像是营销话术但对我这种真正做过的人来说它是一个每天都在牙关打颤的数字。我手搓的这个投资分析Agent从数据管道到推理链路底层要流转的就是这个体量的文本——财报、研报、公告、新闻、宏观数据、会议纪要全塞进去之后我才真正意识到什么叫“信息过载不是理论问题而是工程问题”。这篇文章不聊K线不聊预测模型只讲一个事当你的Agent要吃下百亿token的资料库时它内部到底是怎么组织、怎么检索、怎么推理的。适合正在做大模型应用落地、尤其是做垂直领域知识库和RAG系统的开发者参考也适合对AI Agent有好奇、想知道“里面到底装了什么”的产品经理和研究员。我会按我实际的搭建顺序来讲从数据冶炼到检索命中再到决策链路和兜底机制每一步都说清楚为什么这么做。1. 我为什么要手搓一个百亿token级的投资Agent先交代一个反直觉的结论市面上现成的RAG框架和我见过的主流Agent脚手架在十万token的资料库上跑得飞快一旦上了亿级基本都会在检索召回率和延迟之间崩溃。我试过不止一个方案最后全部换成自己从头搭的流程。1.1 现成框架撑不住“全局记忆”这个需求投资分析这个场景对Agent的要求很特殊。它不是“查一下某个条款”那种单点问答而是要它带着整个市场历史背景去分析问题。比如用户问“某行业上一轮产能周期里龙头公司的毛利率拐点出现在哪个季度”如果Agent的记忆里只有几篇最新研报它根本答不出来必须在历史财报和行业深度报告里做一次跨时间、跨来源的全局检索。这里的核心矛盾是记忆体量越大单次检索的准确率就越是决定成败的命门。通用框架的混合检索和重排策略在百万token级别看着还行但到了几十亿甚至百亿级别索引粒度、分片策略、元数据过滤逻辑都得重新设计。与其在一堆黑盒配置里来回踩坑不如自己把每一个环节拆开看清楚到底哪里掉了精度。1.2 百亿token这个数字是怎么算出来的很多朋友问“你为什么非要百亿token少一点不行吗”这个数字不是我拍的是我盘出来的。我每天要处理的数据源包括A股和港股的定期报告、临时公告、券商深度报告、行业统计数据、宏观利率与流动性数据、头部公司的电话会议纪要以及全量的财经新闻流。光是把这些文本换算成token历史数据累加起来就非常可观。再加上我保留多个版本的历史快照做数据回溯总量自然就冲到了百亿级别。这个体量带来的直接后果是你不能再用“把所有东西装进上下文窗口”的思路了。哪怕未来上下文窗口可以塞下一千万token百亿级别的资料库依然要依赖“先粗筛、后精读”的架构。所以这个Agent从第一天起就不是靠模型记忆硬背而是靠着“外挂脑容量”来工作的。2. 百亿token的数据管道不是堆料是炼油数据管道是整个Agent的地基。前面这些描述可能有点抽象我换个说法如果你把资料库理解成一座矿山那百亿token就是矿石的总量但矿石里含多少“有效信息”完全取决于你选矿和冶炼的工艺。这个环节做不好后面所有检索和推理都是白费。2.1 数据清洗噪音才是最大的敌人很多人拿到原始文本第一反应是赶紧切片、做embedding其实这是最大的坑。我第一版Demo就是这么干的结果模型在检索时经常把公告里的“重要提示”和真正的财务数据混在一起召回的片段毫无逻辑。后来我把清洗做成了完整流水线每一步都盯着两个指标去重率和有效信息留存率。清洗的顺序我基本固定为几条统一格式PDF转出来的报告先做OCR修正去掉页眉页脚、目录、图表里的乱码去重同一份研报在多个平台反复出现标题微调但正文一样这部分按语义指纹去重能砍掉将近两成的冗余段落重组把原本跨页的表格和段落重新拼接避免切片时把一个完整段落劈成两半。这一步做完数据量立刻降了一截质量明显提升。很多做RAG的团队跳过这个“不性感”的环节等到上线后才发现检索精度上不去问题就出在这儿。2.2 切片策略固定长度是毒药切片是数据管道里学问最深的一环也是我反复调优最多次的地方。最早我也是无脑按512token固定切后来发现报告里的很多关键结论是跨段落的。比如研报的“投资评级”和“风险提示”往往不在一页但语义上必须放在同一个检索单位里。我的处理方式是“语义边界感知切片”优先按标题结构和段落边界切保留文档的层级关系超过上限的长文本再用句号、分号做二次切分不允许一句话被拦腰截断切出来的每个片段自动继承文档级元数据包括来源机构、报告日期、证券代码、行业分类等。这个设计在后续检索时的价值非常大。因为过滤条件可以直接用元数据来快速缩小范围而不是每次都全库扫描。2.3 向量化的工程选型与成本权衡百亿token要全部向量化计算成本是个绕不开的问题。我当时用的Embedding模型是某开源中文向量模型单条文本的向量维度设定在1024单次推理的batch size调得比较大配合GPU推理服务跑完全量数据大概花了两周。这个阶段我有几个实测建议不要只用一个Embedding模型要留出“换模型重跑看分数”的口子我后来换了另一版更适配金融文本的模型检索命中率提升了约8%向量和原文必须同库存储方便后续取原文做重排和生成每个文档版本要有状态字段方便做增量更新而不是每次全量重建索引。可以说数据管道这块做完整个项目的进度条才刚到三分之一。但后面所有检索和推理的“幻觉率”都取决于这三分之一的扎实程度。3. 检索与记忆让Agent在百亿token里翻旧账当数据和向量就位下一步要解决的就是怎么让Agent在几十亿token里精准地把那段“陈年旧账”翻出来。这个问题的难度远比在几千条文档里做问答要大得多。你会发现原来那些在演示Demo里“显得很聪明”的RAG到了这个规模会被打回原形。3.1 从向量检索到混合检索召回率怎么救回来的纯向量检索听起来高级但在金融文本里其实有天然短板。人名、公司名、数字、年份这类精确词向量匹配往往不如关键词来得准。比如问“某公司2021年二季度的营收增速”Embedding向量可能会把“2021年二季度”和“第一季度”的向量搞混因为它们在语义空间里实在太接近了。所以我的检索层做的是“混合检索”向量召回负责找出语义上相似的段落适合“找观点、找逻辑”关键词召回用BM25类的稀疏检索负责精确匹配证券代码、年份、指标名称这类实体词两路结果做融合再用Rerank模型对候选集做精排。这个组合救回了大量单个检索器漏掉的内容。我做过一次对比测试在5000条历史研报组成的测试集上单独向量检索的召回率大概在62%混合检索加精排之后升到了81%。提升幅度非常大而且这种提升是稳定可预期的。3.2 元数据过滤把大海捞针变成抽屉找针百亿token的全库检索如果每次都让检索器从头扫到尾性能和准确性都会很糟糕。我在清洗阶段强调的那个元数据继承在这里派上了用场。具体来说每个片段都挂着一串结构化标签检索时会根据问题里的实体做自动过滤。例如“某行业龙头公司2020年以来的产能变化”系统会自动解析出可能的公司名称和起始日期然后把它转成元数据过滤条件只在那家公司的所有切片里做召回。这样一搞每次检索的候选集从几百万片缩小到几千片检索延迟大幅下降噪音也随之减少。我的体会是在大型RAG系统中元数据过滤不是可选项而是必选项。没有这层抽屉任何全局检索的准确率都不会好看。3.3 语义缓存把重复检索的命根子留下来投资研究有个特点很多用户会反复问类似的问题比如“某公司最新一期财报表现如何”。这种问题如果每次都花几秒去检索重排用户会觉得系统很呆。我在检索层加了一道语义缓存。把用户问题的Embedding向量和已执行的查询做相似度比对如果超过阈值直接复用上次的结果。实测下来大约有三成左右的问题可以命中缓存平均响应时间降了一半以上。缓存不是简单的KV存储还需要处理时效性。财报日、重大公告日前后缓存必须主动失效否则会给出过时信息。我专门做了一套“基于日期敏感度的缓存刷新策略”快到期的数据直接跳过缓存走全链路计算。4. 决策链路从问题拆解到答案生成的完整推理流程检索只是工具Agent真正的核心价值在于怎么用检索结果做推理。投资问题往往是复杂的复合问题指望一次检索、一次生成就出答案基本都会翻车。我采用的是一套多阶段推理流程每一步都盯着可追溯性和准确性。4.1 问题拆解先想清楚“到底要回答什么”当一个用户问题进来时我会先让模型做一次“问题解析”拆出几个维度核心实体涉及哪个公司、行业或指数时间范围是某个季度、年度还是某个历史区间比较维度需要同比、环比还是需要跨行业对比输出形式只要一个数字结论还是要一段逻辑推演。这些信息不是用来给用户看的而是用来指导后续的检索和筛选。我一开始忽略了这个步骤模型经常对着大段的检索结果乱抓后来加了问题拆解之后答案的质量有了明显改善。4.2 多轮检索与交叉验证让答案有理有据拆解完成后Agent不会只用一轮检索就急着生成。它会根据拆解出的子问题分别走检索流程把每个子问题的候选片段都拉回来。然后进入交叉验证环节针对同一个结论至少需要两个独立的资料片段相互印证模型才会写进最终答案。比如问题问“某公司毛利率上升的原因”Agent会检索历年财报、行业研报和新闻公告当三处来源的表述一致时才给出“成本下降产品结构优化”的结论。如果只有单一来源答案里会注明“该结论主要依据某券商报告需结合其他信息判断”。这种方式本质上是在模仿研究员的工作习惯不轻信单一信源。它在模型层面的代价是增加了多轮推理的开销但换来的是事实性的显著提升。4.3 答案生成与引用标注可解释性不是加分项是生命线在投资场景里用户绝对不接受一个“没有出处的结论”。所以我的Agent生成的每一段结论后面都会自动挂上可点击的引用来源包括文档标题、发布日期、原文片段。这个设计在技术上并不复杂但需要检索阶段把每一片命中的文本都保留好溯源ID并一路传递到生成阶段。这样做的另一个好处是我可以在生成后做自动查重如果答案里的关键句子在引用块里找不到对应依据系统会标记为“疑似幻觉”要求模型重新生成或明确降低置信度。可以说这套引用机制既是给用户看的也是给系统自己兜底用的。5. 评测与风控没有这两样Agent就是颗定时炸弹很多人把Agent做完检索和生成就以为万事大吉了但我见过太多系统在线下演示时惊艳全场一上真实数据就崩得体无完肤。原因是缺少一个完整的评测与风控体系。我对这个Agent的所有改动都要先过一遍评测才算数。5.1 自建评测集拿什么衡量“答得好不好”公开的评测集大多是通用领域的用在投资场景上并不合适。我花了不少时间自己攒了一套评测集结构大概是三部分事实抽取题限定答案必须能从给定原文中找到直接证据逻辑推理题需要跨多篇文档得出结论时效判断题考察模型对“旧数据”和“新数据”的区分能力。每一道题都预置了参考答案和评分规则用大模型打分加人工抽检结合的方式评判。跑评测已经成为我每次调整参数、换模型、换切片策略之后必做的一步。不做评测就上线等于在没有任何仪表盘的情况下开一艘大船。5.2 幻觉兜底宁可说不知道也不能硬编投资场景里幻觉的代价极其高昂。一个编造出来的财务数字可能直接误导用户做出错误决策。所以我在推理链路的最后一步加了一个“证据强度判定”模块如果检索到的证据量不足以支撑答案系统会明确回复“目前掌握的资料不足无法给出可靠结论”如果证据之间存在明显矛盾系统会如实列出矛盾双方而不是强行给一个统一答案对于时效性敏感的问题系统会额外标注“该结论基于某个时间点的数据后续可能发生变化”。这套“宁缺毋滥”的兜底逻辑在评测集上把幻觉率压到了很低的水平。虽然它会让模型在部分问题上“看起来变笨了”但对我们来说这种笨恰恰是可信赖的体现。5.3 风控红线哪些内容绝对不能碰金融内容还涉及合规问题。我的Agent在系统层面写死了几条红线包括不直接提供买卖建议、不预测具体涨跌幅、不保证任何收益。它只做“事实和分析”的输出把决策权完全留给用户。这些红线不只是提示词里的一行字而是在输出前有一道独立的过滤服务用规则加模型双重校验。一旦命中敏感模式输出会被截断并引导用户“请咨询专业人士”。我一直认为这种领域的Agent第一目标是安全可用其次才是聪明高效。6. 回填与成本优化百亿token的可持续运行之道系统能跑起来只是开始能不能持续稳定地跑下去是另一道坎。百亿token级的Agent每天都要面对增量数据的回填、历史数据的更新和计算资源的账单。这一节聊聊我在这方面做的优化和踩过的坑。6.1 增量管线让“新数据”和“旧数据”各归其位金融数据每天都会新增不可能每次都全量重建索引。我的做法是引入增量管线每天定时拉取新增的公告、研报和新闻走完清洗、切片、向量化流程后只对新增部分建索引。同时对于已经入库的文档如果有新版本覆盖旧版本我会用版本号机制做软删除让检索时默认只命中最新版本。这个设计带来的一个问题是检索时如何处理“历史版本”和“最新版本”的关系。比如用户问“某公司三年前的年报数据”这时候不应该命中当前的最新版本而应该取历史快照。我在元数据里保留了“生效时间区间”检索时根据用户问题的时间范围自动匹配对应版本。这笔设计让系统在增量模式下依然能准确回溯历史信息。6.2 资源成本与响应延迟的平衡百亿token级别的检索链路如果每个环节都用最强的模型成本会非常吓人。我做了分级处理粗筛阶段用较小、较快的向量模型做初次召回保住吞吐量精排阶段只有粗筛命中的几千个候选才调用更强的模型做重排生成阶段根据问题复杂度动态选择模型简单事实类问题用轻量模型复杂推理类问题才上强模型。这套“分级模型架构”让整体综合成本降低了近一半同时在评测集上几乎没掉分。唯一需要注意的是分级会导致响应时间波动变大简单问题快、复杂问题慢但从用户体验来看这本身符合预期。6.3 监控与报警让系统自己告诉你它病了系统上线之后我每天看的最多的不是那些花哨的功能指标而是一系列基础监控数据检索失败率、检索平均耗时时长、无结果命中率、答案引用完整度。这些指标任何一个出现异常都意味着数据管道或者索引链路出了问题。我专门搭了一个监控面板按小时粒度统计这些指标并设置了阈值告警。有一次凌晨两点报警说无结果命中率突然飙升我查了半天才发现是某个上游数据源调整了接口字段导致当天新增数据切片全成了空内容。如果没有这个监控第二天早上用户们看到的就会是一堆“抱歉我没有找到相关信息”的尴尬回复。7. 从零到一的完整链路一套我可以复用的方法论整个项目做到今天如果让我把最核心的经验抽象成一套可复用的方法论我会把它归纳成三层。你可能不会做投资Agent但只要你做的是垂直领域的大模型应用这三个层级就有参考价值。第一层是数据层。所有垂直Agent的瓶颈最后几乎都会落在数据质量上。切片策略必须保留语义边界元数据字段必须能覆盖后续检索所需的所有过滤维度清洗环节要不惜工本做去重和噪声剔除。这一层做好了后面所有环节的难度都会按比例下降。第二层是检索层。混合检索加上元数据过滤是基本标配如果想要更精准再加Rerank精排。在此之上必须设计语义缓存和增量更新机制否则系统会在千万级数据量时很快变得又慢又笨。没有永远正确的一次性方案做迭代式优化才是常态。第三层是生成层。多阶段推理加交叉验证加证据强度判定加引用标注这一整套合起来才是Agent真正“靠谱”的来源。没有评测集和监控体系就不能谈迭代和优化因为你看不到改动带来的真实影响。我一直认为评测集不是项目的交付物而是项目持续运转的仪表盘。如果你正在做自己的Agent我建议你先不要急着上大模型、上复杂框架先把手里的数据管道和评测集搭起来。等你尝到“改动一个切分参数评测分数大幅度提升”的甜头就会理解我为什么这么强调地基工程。我做这个百亿token的投资Agent中间也想过放弃很多次。每次被召回率、幻觉率、成本账单折磨到头秃的时候最有效的放松方式反而是回到那一堆原始数据里重新读一遍某家龙头公司十几年的年度报告。你会看到一家企业如何从一个细分市场的玩家一步步成长为行业巨头也会看到某些曾经辉煌的名字如何一步步走向平庸。这种穿越周期的叙事才是做这个项目对我最迷人的副作用。数据终究不只是参数它是真实商业世界的投影。