做这个项目的起因其实特别直接——我一直在做智能体应用开发去年陆续聊过不少垂直领域的落地需求后发现A股投研分析是“大模型看着好用落地处处碰壁”的典型场景。客户要的是这样一种效果输入一句需求比如“帮我找找受益于AI算力扩张、现金流稳健的A股标的”系统能自动梳理产业链、拉财报、读公告、追踪新闻最后产出一份带依据、可复核的分析结论。纯粹靠大模型硬答是做不到这个效果的于是我最终把方案锁死在“RAG智能体”的组合上做成了一套端到端的A股智能选股分析智能体。这篇文章是这次开发全流程的复盘内容包括架构取舍、知识库设计、检索调优、智能体工作流实现以及一堆常规文档里不会写的踩坑记录。准备做RAG项目或者想往垂直领域落智能体的朋友可以直接参考里面的思路和坑位。1. 为什么非要用RAG智能体而不是把大模型当“万事通”1.1 我最初试纯大模型时踩的坑第一期demo我偷懒直接拿大模型做“股票问答”。结果一句话总结看似什么都能聊细看没有一句能直接信。最典型的是让模型帮我把某行业的龙头公司按营收排序它会一本正经给出五六家公司但其中有几家早就已经不再是行业头部队列年份也说不清楚让它解释某只票最近为什么异动它给出的原因往往是训练数据里学到的历史相似行情而非当下真实事件。这就是我反复强调的“知识冲突”问题训练语料里的静态信息和当下的市场动态天然存在时间差模型自己根本意识不到。更麻烦的是数据幻觉。股票分析最忌讳六位代码错一个、财报数字多一个零但大模型在生成这类内容时为了“回答得完整”会主动把缺的信息补齐成看起来合理的数值。我做了一个小范围的抽样测试让模型在不联网的情况下回答二十个涉及真实财务指标的问题粗对率不到一半。这个数字直接让我把“纯LLM方案”划掉了。1.2 RAG管知识智能体管流程既然单靠模型不行第一反应是上RAG把财报、公告、研报、新闻切块后向量化检索召回相关内容再交给模型生成。RAG解决了“不知道”的问题让模型能基于知识库内容回答而不是凭空编。但做着做着就会发现另一个缺口——股票分析不是一个“问一句答一句”的回合制游戏而是一个多步骤的决策过程。“找AI算力概念里现金流稳健的公司”这句话背后至少包含三件事先判断什么是AI算力产业链、再筛选概念相关标的、还要逐个核查财务指标和近期公告。这需要系统动态决定“先做什么、再做什么、查哪些数据、用哪些工具”也就是流程编排。这就是我把智能体架构加进来的原因。简单说RAG负责外挂记忆和事实供给智能体负责任务拆解和工具调度。知识库是弹药库智能体是指挥官两者配合才能完成完整的分析动作。这个定位后来贯穿了整个项目设计。2. 总体架构与数据链路设计2.1 模块划分与信息流整个系统的结构我拆成了四层信息流是一条清晰的链路从数据源进边处理边沉淀最终在智能体层产出决策报告。采集层负责对接不同数据源加工层负责清洗、切块、入库服务层提供检索和重排能力最上面是智能体执行层。数据源 ├── 财报数据(EPS/ROE/现金流) ├── 公告与研报 ├── 行情与资金流数据 ├── 新闻资讯(按行业/个股打标) │ ▼ 采集清洗层 → 统一JSON格式去除重复时间戳对齐 │ ▼ 切块与向量化层 → 按业务类型分集合存储 本体关系映射 │ ▼ 检索服务层 → 多路召回(向量BM25) → 重排 → 压缩 │ ▼ 智能体执行层 → 任务拆解 → 工具调用 → 生成与自检这个架构最大的特点是数据与决策解耦知识库只负责“有什么”智能体只负责“怎么用”。好处是后续替换模型、调整提示词、扩充数据源都不会牵一发动全身。我在项目中期至少大改过三轮智能体工作流但这套模块边界始终没动省下的返工时间非常可观。2.2 数据采集管道设计财报、公告、行情与新闻缺一不可A股智能选股和通用问答的一个核心差异是数据维度必须全。单有财报做不了事件驱动单有行情做不了基本面判断。最终我只保留了四类数据源每类的处理方式完全不同。数据类别核心字段更新频率入库方式财报数据营收、净利润、ROE、现金流、负债率季度更新全量清洗后增量入库公告与研报标题、公告类型、正文、发布机构实时/每日按公告ID去重切块入库行情与资金流收盘价、涨跌幅、成交量、北向资金每日收盘后数值型存储不做文本切块行业新闻标题、摘要、来源、涉及个股标签小时级事件抽取标签化后入库财报数据是结构化的数值型信息不适合直接丢进向量库我单独存成结构化记录靠工具层取数公告和新闻是非结构化文本才是RAG知识库的主要对象。这个区分非常重要很多人一上来把数值和文本混在同一个集合里结果查出来的结果既没有精确财务指标也没有完整上下文。具体到入库管线我有几个细节是反复调过的。一是公告去重必须用公告编号而不是标题因为不同平台转载时标题可能微调但公告编号是唯一的。二是新闻数据要解析正文后把涉及的公司名称统一替换成市场通用的简称或代码否则会出现“苹果”和“Apple”之类概念词切割后的检索混乱。三是数据时间戳一定要保留到分钟级这不只是入库要求后期排序权重会用到。2.3 知识库的“本体”设计把A股业务概念变成可检索的约束如果只是把一堆文档切一切丢进向量库那就只是最基础的RAG做不到行业级效果。我在这个项目里重点做了“本体”层面的设计让知识库不只是散文档而是一张有关系的业务网。什么是本体你可以把它理解为数据模型层面的概念约束。比如在A股分析场景里我定义了这样几种实体股票(Stock)、行业(Sector)、概念(Concept)、公司事件(CompanyEvent)、财务指标(FinancialMetric)。这些实体之间有明确的关系比如“贵州茅台属于白酒行业”“AI芯片是AI算力概念下的子方向”“某公司发布股权激励计划属于公司事件”。把这些关系做成结构化约束后检索过程就多了一层“路由能力”。具体实现上我用的是“向量库关系边表”的混合体关键动作是给每条知识打上本体类型标签。举个例子某条新闻“某公司发布年度业绩预告预计净利润同比增长40%”入库时不仅做向量化还会抽取出涉及股票X、事件类型业绩预告、指标净利润增长。这样当用户问“近期哪些公司发布过业绩预喜公告”时系统可以直接按结构化条件过滤检索结果再结合语义相似度补充排名。纯向量检索这时候很难精确命中因为“业绩预喜”和“净利润同比增长”不是同义词关系但本体关系能把它关联起来。这一块其实就是近来常说的Ontology RAG和GraphRAG思路的简化落地。我没有把知识图谱做得很重因为完整图谱的构建和维护成本在A股这种动态场景里非常高昂但抽取实体和关键关系来做约束与路由性价比相当高也是我后续项目中一直保留的设计。3. 核心环节实现索引、检索、重排与增强生成3.1 文本切块与向量化边界、粒度与召回质量切块是RAG项目里最容易被低估的一环。很多人直接用固定长度硬切切到一半把一段财报讨论和另一段毫无关联的新闻拼在一起检索出来的结果自然又碎又乱。我在这个项目里花了两周专门调切块策略最终形成了一套和业务类型绑定的规则。内容类型切块策略块大小重叠区间公告正文按章节标题切每个章节独立成块300~500字左右50字新闻事件按段落切保留标题时间前缀200~400字20字研报分析按结论逻辑段组织优先保留对仗式观点400~600字100字财报文本说明保持整段完整禁止跨章节拼接整段一起入块0为什么公告要按章节切因为A股公告有相对固定的格式重要提示、交易概述、风险提示都是独立章节混在一块会让模型分不清信息来源层级。新闻数据必须带标题和时间前缀是因为单纯的正文切块会让模型丢失“这是什么时间谁说了什么”的核心语境。向量化模型我对比过几款主流的Embedding模型中文场景下BGE系列和基于同义句对比训练的模型表现比较稳定金融语料上明显优于通用英文模型。最终选了BGE-M3的中文版本它最大的优势是同时支持短句和长文检索对公告这种长文本的召回效果更好。向量维度固定为1024通过带语义权重的余弦相似度计算相关度。有个实操提醒向量化时不要对整篇财报做平均池化后塞进一个向量。财报信息密度极高平均池化会把“净利润暴增”和“商誉减值”这种关键差异互相抵消成模糊的中间值。按小粒度切块后保留原文比任何“精妙压缩”都可靠。3.2 多路召回与重排向量检索不是唯一解法我在这批项目里反复实验得到一个结论纯向量检索在A股场景下的召回质量不够稳定。主要原因是金融语言存在大量同义异构比如“净利润增长”和“利润同比上升三成”语义相似但词面完全不同反过来“高增长”和“高估值”在语义空间里可能距离较近但在分析语境里含义天差地别。向量检索只靠语义相似度打分很容易召回到“听起来相关但实际无关”的内容。所以我的检索层改成了多路召回重排的结构。多路召回同时运行两条通道向量通道负责语义相似BM25关键词通道负责精确术语匹配。两个通道各召回前20条合并去重后进入重排模型重新打分。重排器我用的是Reproducible的基于交叉编码器的中文Rerank模型它比向量相似度更精细因为它会给“查询-文档”对整体相关性打分而不是只比对“查询向量-文档向量”的距离。实验结果直接体现在指标上加入重排后Hit率提升了近15个百分点。下面是某一轮测试的对比记录方案Top-3命中率Top-5命中率平均首条相关度仅向量检索42%58%0.74向量BM25多路51%66%0.79多路重排模型63%78%0.86还有一个细节时间衰减权重。在新闻类文档的相关性得分上我会叠乘一个时间衰减因子越新的内容权重越高。这个设计在“近期利好/利空”类查询里收益特别大。有一次用户问“某公司最近有什么负面新闻”如果不加时间权重检索系统极可能把半年前的旧负面翻出来当最新事件这是股票分析里不可接受的错误。3.3 智能体决策工作流从“一次性问答”到“多步分析任务”有了知识库和检索能力接下来就是把智能体用起来。我最开始把智能体做成“一个Agent走天下”一个大模型收到问题后自行决定调什么工具。结果在复杂任务上经常出现工具漏调、逻辑跳跃的问题。后来换成了“主引擎多个子Agent”的分层结构稳定很多。主Agent不直接处理具体工具它只做两件事理解任务意图和拆解执行路径。比如输入“找出XX概念下资产负债率低于40%的龙头公司”主Agent会先把任务拆成三步先定位概念相关公司、再逐家核实资产负债率指标、最后按市值和营收排序筛选龙头。每个子步骤交给对应的子Agent执行。概念路由Agent负责把行业/概念表述映射到知识库中的本体标签处理“AI算力”和“算力基础设施”这种同义概念的归一。财报分析Agent调用结构化财务接口只负责取数、算指标、做横向对比不承担语义理解类任务。公告事件Agent检索公告库提取事件类型、时间、涉及主体输出结构化事件列表。综合研判Agent汇总前三个Agent的输出结合RAG检索的新闻与研报内容统一生成最终分析结论。这种“一个主控四个专职”的架构好处是每个子Agent的提示词可以写得非常聚焦判断准确率远高于一个全能提示词。我实测下来单任务意图识别准确率从78%提升到92%左右多步任务的完成率也明显提高。所谓Agentic RAG本质就是让检索不再是“一次性查找”而是嵌入到任务链路里被反复调用并支持根据中间结果调整下一步检索方向。3.4 提示词与输出约束让模型学会“分清事实和判断”模型生成环节其实是最容易被忽略的。很多人以为检索做好了答案自然就准确了。实际上就算检索结果完全正确大模型生成时仍然可能发生两种情况一是把不同来源的数字混着算得出错误结论二是把检索到的“预测性观点”直接叙述成“确定事实”。我在提示词里强制加入了“证据边界”指令把输出格式固化成了下面这种模板请基于提供的检索举证材料回答不要使用记忆中的具体数值。 回答需遵守 1. 每个结论后标注【来源序号】 2. 明确区分【事实陈述】与【主观判断】 3. 如果检索材料内的数据互相矛盾需明确指出矛盾点不可自行抹平 4. 对未检索到的内容说“当前知识库未覆盖”不要补充推测数据。这个模板的实际价值远超我的预期。之前自动生成的分析报告里经常出现“利润稳定增长”这种模糊表述普通人看不出风险但做投资的人一看就知道模型在“说废话”。加上证据边界的约束后生成的结论在可复核性上提升了一个量级——每个关键判断都能追溯到原文。另外我在生成前加入了一个“查询压缩”步骤把用户的原始提问和之前轮次的上下文重新组织成一条自包含的检索query避免多轮对话中指代问题导致的检索错误。4. 实测效果、常见问题与复盘心得4.1 评测指标与实验对比项目上线前后我做了大量离线测试除了基础的检索命中率还重点评测了“最终答案的可执行性”。我在内部定义了一套五级评分标准从高到低分别是结论正确且数据可复核、结论正确但来源不够直接、结论泛化但方向正确、结论存在一处明显错误、幻觉输出。用这套标准评估了一个含一百多条真实分析需求的数据集结果是达到前两级的比例稳定在67%左右。为了说明架构的作用我也做了个对照实验同一批问题分别交给纯大模型、单轮RAG、RAG智能体工作流三套方案。结果如下方案得分前两级占比幻觉输出占比平均响应时间纯大模型18%44%3秒单轮RAG45%12%5秒RAG智能体工作流67%4%12秒响应时间变长是智能体多步调用的必然代价但这个代价换来了任务完成度的显著提升在实际使用场景中是可以接受的。后续我通过并行化检索和结果缓存把这套流程的平均响应时间压缩到了8秒左右。4.2 高频问题与排查技巧实录开发过程中踩过的坑很多我把几个最有代表性的列出来这些常规文档里基本不会写。问题一检索到过时信息但相关度排名很高。早期新闻检索不做时间衰减用户问“最近一周某行业动态”返回的却是一个月前的旧新闻。后来我在重排阶段给每条结果加上了按发布时间衰减的惩罚系数并且对超过设定时限的新闻强制降低分数问题基本解决。问题二财报分析时模型总把“增长率”算错。这不是检索问题而是提示词没有明确数值计算规则。比如同比和环比经常混用。我后来在财报Agent的提示词里增加了一条“所有计算必须先明确基准期并输出计算公式后再给结果。”模型会在答案中写出“(本期值-上期值)/上期值”从根源上减少了计算过程不透明造成的错误。问题三公告内容被切碎导致事件全貌丢失。股权激励公告经常是二十页PDF按章节切块后单块只覆盖“激励计划概述”或“授予对象名单”。模型只凭部分信息会误判成“大额股权激励”。解决办法是对公告类文档在按章节切块的同时额外保留一份“全文摘要块”生成时优先查看摘要块建立整体认知再查看细粒度块引用细节。问题四智能体陷入死循环。有一次子Agent在调用财报接口时返回空数据Agent不断重试同一个工具而不切换策略。我在工作流中加入了一条“失败熔断”规则同一个工具调用失败超过两次子Agent必须改变计划要么换一个工具要么向主Agent上报异常。这从根本上杜绝了无脑重试导致的超时问题。4.3 复盘心得与可复用的设计建议如果这个项目让我重新做一遍我会在前期就优先做两件事一是把评测集建得更完整而不是等到开发中期才开始积累测试用例二是尽早引入本体关系设计它带来的收益远比想象中更大。对我来说一套可复用的RAG知识库设计方法比一堆调参记录更值钱。这套方法后来已经被我复用到了金融以外的行业项目中。另外必须说一点A股智能选股这个方向技术本身只是支撑业务场景的风险意识更重要。系统必须明确区分“信息检索辅助”与“投资建议”我的做法是在最终报告中每次都附带“风险提示”并显著标明“本内容基于公开数据的客观整理不构成投资建议”。省得用户把分析报告当操作指令我以为这是底线思维不搞容易出问题。结束语这个项目做下来我最大的体会是RAG和智能体从来不是互相替代的关系而是解决不同层面问题的组合。RAG解决“模型不知道”的尴尬智能体解决“只回答不行动”的局限。真正难的不是某一个环节的先进程度而是数据、索引、检索、生成、工具调度这条链路能否在业务场景里闭合。如果这篇文章能帮你少踩几个坑那我这套复盘的价值就已经到达了。后续我打算把“可复用RAG知识库设计模板”整理成一套更清晰的文档到时候再拿出来继续分享。