企业官网建设流程全解析

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 清洗规则：噪声去除、正文抽取与水印处理

清洗决定了索引质量的上限。垃圾进，垃圾出，到这里体现得淋漓尽致。

我在清洗流水线上做了这些事：

1. 正文区域检测。很多PDF页面顶部是页眉、底部是页码，两侧有图表注释。我用规则+模型双路检测正文边界，规则负责兜底，模型负责处理规则覆盖不了的复杂版面。
2. 水印和免责声明去除。研报几乎每页都有“本报告仅供内部使用”“市场有风险，投资需谨慎”等水印。这些内容不仅没价值，还会在后续语义检索时产生严重噪声。我的处理方式是构建了一套高频模板库，基于正则批量替换。
3. 表格内容转写为Markdown格式。这对后续大模型理解非常关键。原文的表格在PDF里是二维排版，抽取后是一维文本。转成Markdown表格后，大模型对数值关系的理解能力明显提升。
4. 去停用词和低信息段落。财报里大量套话，比如“公司所处行业面临新的机遇与挑战”，这类句子没有信息量。我用“信息熵+规则模板”打分，把低分段落直接丢弃。

清洗后数据量会显著下降。我跑过一批月度的全市场公告数据，原始体积约120GB，清洗后剩约85GB，其中表格内容占了很大比重。

3.3 分块策略：为什么固定窗口分块在财务场景不适用

这是全文最重要的实操点之一。通用RAG常用固定大小分块（比如每块512token），这在金融场景表现很差。原因有三：

1. 财务披露有极强的上下文关联。一家公司的年报里，“经营活动产生的现金流量净额”必须和“净利润”放在一起对比才有意义。固定窗口很容易把这两个数据切成两半。
2. 同一事件往往跨文档存在。比如公司发布业绩预告，三天后再发布修正公告，两份文档描述的是同一件事，但固定分块无法建立关联。
3. 表格结构需要整体保留。一个包含几十行数据的财务表格，固定窗口分块会把它拦腰截断，使模型完全读不懂。

我采用的分块逻辑是结构感知层级分块：

• 先把文档解析成DOM树（标题→章节→段落→表格）。
• 对每个叶子块按语义边界做自适应切分，最小256token，最大1024token。
• 表格单独作为一个分块单元，保证完整性。
• 章节标题作为块的元数据，参与向量编码和检索排序。

这套方案让检索命中率（Recall@10）从固定窗口的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定义的子查询可能是：

1. 该公司最新报告期净利润及同比变化
2. 公司报告期内主营业务收入分产品情况
3. 行业供需格局与价格走势
4. 券商对公司利润增长驱动因素的分析

每个子查询独立走“向量召回+关键词召回+文档过滤”的复合通道，最后汇总。这个设计显著提升了信息覆盖面，但代价是需要几十次检索调用，延迟从单次检索的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的每一步是否有材料支撑。

这套推理框架借鉴了思维链思想，但有两个关键差异：

1. 每步推理必须有“引用锚点”，锚定具体文档、章节、原句，不产生悬空推理；
2. 推理逻辑与投资逻辑对齐，比如推导盈利变化时强制要求区分“量”和“价”的驱动、一次性因素与持续性因素等。

如果你也想做投资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，克制比聪明更重要。