1. 项目缘起与整体架构设计1.1 为什么选择RAG而不是微调做A股智能选股这个方向最开始团队内部争论了很久到底是走大模型微调路线还是走RAG检索增强路线。我们最终选了RAG为主、轻量微调为辅的混合方案原因很实际。A股市场的特点决定了知识更新频率极高。财报按季度发布、政策随时出台、行业事件每天都在发生如果走全量微调路线每次新数据进来都要重新训练一轮成本高不说还容易出现灾难性遗忘——模型学了新财报把老的行业逻辑忘了。而RAG的核心优势就是知识外挂把最新的研报、财报、公告、行情数据切块存进向量库检索时动态拼进上下文模型本身不需要频繁变动。另一个关键考量是可解释性。选股这件事用户天然会问“为什么选这只”。纯微调模型的输出是黑盒而RAG可以明确告诉你这条结论来自哪份研报的第几段、哪份财报的哪个指标。这在合规和用户信任层面是刚需。当然RAG也不是银弹。我们踩过的坑是纯RAG在需要深度推理的场景比如多期财务数据交叉验证表现不如微调模型。所以最终方案是——RAG负责事实召回微调负责推理风格对齐两者配合。1.2 智能体的角色分工设计这个项目不是单一模型而是一个多智能体协作系统。我们参考了Agentic RAG的思路把整个选股流程拆成几个专职智能体数据采集智能体负责从行情接口、公告接口、研报库拉取原始数据做清洗和结构化。检索智能体接收用户query改写检索意图去向量库和多路数据源召回候选信息。分析智能体对召回内容做财务指标计算、行业对比、估值判断。风控智能体检查推荐标的是否触碰ST、退市风险、行业禁投等红线。报告生成智能体把前面所有结果整合成一份可读的选股分析报告。这种拆分的好处是每个智能体职责单一prompt可以针对性优化出问题也容易定位。坏处是链路长延迟高需要做并行化和缓存。1.3 技术栈选型与理由组件选型理由大模型DeepSeek系列 本地部署Qwen中文金融语料表现好本地部署保证数据不出域向量库Milvus支持混合检索亿级向量性能稳定编排框架自研轻量编排 AgentScope参考避免框架黑盒方便调试数据源行情API 公告解析 研报PDF解析多源交叉验证微调LoRA轻量微调成本可控风格对齐够用选Milvus而不是FAISS是因为我们需要标量过滤向量检索的混合查询。比如“在新能源行业、市值50亿到200亿之间、最近一个月有机构调研的股票里找和‘固态电池量产’语义最相关的”。FAISS做不了这种带条件的检索Milvus可以。2. 核心细节解析与实操要点2.1 知识库构建切块策略决定检索上限RAG项目里切块策略是地基。切得不好后面检索再优化也救不回来。我们试过三种方案第一种是固定长度切块比如每512个token一刀切。问题是财报里的表格和段落经常被切断检索出来的片段语义不完整。第二种是按段落切遇到空行就切。比固定长度好但研报里经常有长段落一个段落讲三个逻辑检索时全被召回噪声大。最终采用的是语义切块重叠窗口先用规则识别文档结构标题、表格、段落再在段落内部按语义相似度做二次切分相邻块之间保留15%的重叠。重叠的作用是防止关键信息刚好落在切分边界上被割裂。具体参数上我们最终定的是单块目标长度300到500字重叠50到80字。这个范围是实测出来的——太短召回信息不足太长噪声多且浪费上下文窗口。注意财报表格一定要单独处理不能当普通文本切。我们的做法是把表格转成Markdown格式每个表格作为一个独立块并在块头部加上表名和单位说明。2.2 向量化模型的选择与踩坑embedding模型我们对比了三个通用中文embedding、金融领域embedding、以及大模型自带的embedding接口。通用模型在金融术语上表现一般比如“市盈率”和“PE”它可能认为是两个东西。金融领域embedding明显更好但对新出现的概念比如“低空经济”覆盖不足。大模型embedding接口效果好但成本高、延迟大。最终方案是金融领域embedding为主配合关键词检索做兜底。也就是混合检索向量召回Top50BM25关键词召回Top50然后做RRF融合排序。这样既保证了语义理解又不会漏掉精确匹配的关键词。实测下来混合检索比纯向量检索的hit rate提升了大概18个百分点。这个提升在选股场景里很关键因为漏掉一份关键研报可能就错过一个逻辑。2.3 检索意图改写让query更懂行用户输入的query往往很口语化比如“帮我找找最近有啥好股票”。这种query直接拿去检索效果很差。我们加了一个检索意图改写智能体做三件事第一把口语query转成结构化检索条件。比如上面那句会被改写成时间范围最近一周类型机构推荐/评级上调行业不限附加条件有明确上涨逻辑。第二做query扩展。比如“固态电池”会扩展出“半固态电池”“全固态电池”“硫化物电解质”等相关术语提高召回率。第三做query分解。复杂query拆成多个子query分别检索再合并结果。比如“新能源里估值低且机构在调研的”会拆成“新能源 低估值”和“新能源 机构调研”两路检索。这个改写环节看起来简单但对最终效果影响巨大。我们做过消融实验去掉改写环节检索准确率下降超过25%。3. 实操过程与核心环节实现3.1 数据管道的搭建数据管道是整个项目最脏最累的部分。A股数据源质量参差不齐公告格式五花八门研报PDF解析经常出错。我们的管道分四层第一层采集。行情数据走接口定时拉取公告走交易所公开接口研报走PDF解析。这里的关键是去重和版本管理——同一份研报可能有多个版本同一份公告可能被多个源重复抓取。第二层清洗。PDF解析出来的文本经常有乱码、页眉页脚、表格错位。我们写了一套规则清洗重点处理去除页眉页脚、修复断行、表格转Markdown、识别并保留章节结构。第三层结构化。把非结构化文本里的关键信息抽出来比如财报里的营收、净利润、毛利率研报里的评级、目标价、核心逻辑。这一步用大模型做信息抽取配合规则校验。第四层入库。结构化数据进关系库文本块进向量库两边通过doc_id关联。实操心得数据管道一定要做幂等设计。同一份数据重复跑不能产生重复记录。我们早期没注意这点导致向量库里同一份研报存了七八遍检索结果全是重复的。3.2 多智能体编排的实现编排层我们没用现成框架而是自己写了一个轻量的DAG调度器。核心逻辑是每个智能体是一个节点节点之间通过消息队列传递数据支持串行和并行。举个例子一次完整的选股请求流程是这样的用户query进入先过意图改写智能体输出结构化检索条件。检索条件分发给检索智能体同时去向量库、关系库、行情接口拉数据。召回结果送给分析智能体做财务计算和逻辑梳理。分析结果送给风控智能体做红线检查。通过检查的结果送给报告生成智能体输出最终报告。整个链路里检索和分析可以并行做部分工作我们做了异步优化把平均响应时间从12秒压到了4秒左右。3.3 提示词工程与上下文管理多智能体系统里prompt管理是个大工程。我们的做法是prompt模板化版本管理。每个智能体的prompt存在配置文件里支持热更新和A/B测试。上下文管理上最大的挑战是上下文窗口有限但召回内容很多。我们的策略是检索阶段召回Top100粗排到Top20。精排阶段用一个小模型做相关性打分选出Top5到Top8。最终拼进上下文的除了这5到8个块还有结构化的财务指标摘要和风控结论。这样既保证了信息量又不会撑爆窗口。实测下来精排环节能过滤掉大概70%的噪声。4. 常见问题与排查技巧实录4.1 检索命中率低的排查思路检索命中率低是RAG项目最常见的问题。我们的排查顺序是排查项检查方法常见问题切块质量随机抽100个块人工看块太碎或太长语义不完整embedding质量拿已知query测相似度模型不匹配领域检索策略对比纯向量vs混合检索漏掉关键词匹配query改写看改写后的query是否合理改写过度或不足索引更新检查最新数据是否入库增量更新失败我们遇到过一次典型问题某天开始检索结果突然变差。排查发现是数据管道的一个增量任务挂了导致最新三天的研报没入库。所以监控索引新鲜度很重要我们后来加了一个告警超过24小时没更新就报警。4.2 大模型幻觉的抑制选股场景里模型胡说八道是要出事的。我们用了三层抑制第一层检索约束。prompt里明确要求“只基于提供的资料回答资料里没有的信息不要编”。第二层引用校验。模型输出的每个结论都要标注来源后处理环节校验来源是否真实存在。第三层数值校验。财务数据这类硬信息从结构化库里直接取不让模型自己算。即便如此还是会有漏网之鱼。我们的兜底方案是风控智能体做最终检查发现明显不合理的输出直接拦截。4.3 性能优化的几个关键点多智能体RAG的链路很长性能优化是必须的。我们做了这几件事缓存相同query的检索结果缓存相同股票的财务指标缓存。并行检索和分析里能并行的步骤全部并行。流式输出报告生成用流式用户不用等全部生成完。模型分级简单任务用小模型复杂任务才调大模型。优化前后P99延迟从20多秒降到了6秒以内。这个体验差距是巨大的。4.4 常见问题速查表问题现象可能原因解决方向检索结果不相关query改写失败/embedding不匹配检查改写日志换embedding模型回答内容空洞召回块质量差/上下文太短优化切块增加召回数量数值错误模型自己算数改为从结构化库取值响应超时链路太长/模型太慢加缓存并行化模型分级重复推荐去重逻辑缺失在检索和输出层都加去重风控漏检规则覆盖不全定期review风控规则库5. 项目复盘与后续扩展方向5.1 做对了什么回头看这个项目有几个决策是对的。混合检索是其中之一纯向量检索在金融场景真的不够用。多智能体拆分也是对的虽然链路长了但每个环节可优化、可监控、可替换。数据管道幂等设计虽然前期麻烦但后期省了无数事。还有一个隐性决策没有过度依赖现成框架。我们参考了AgentScope等框架的设计思路但核心编排自己写。好处是出了问题能定位到代码行坏处是开发工作量大。对于要长期维护的项目这个取舍是值得的。5.2 踩过的坑最大的坑是早期低估了数据清洗的工作量。我们原以为数据管道两周能搞定实际花了两个月。PDF解析、表格识别、公告去重每一项都比想象中复杂。第二个坑是prompt版本管理混乱。早期prompt直接写在代码里改一次要重新部署。后来抽成配置文件支持热更新效率才上来。第三个坑是没有做检索质量监控。上线初期全靠人工抽查后来加了自动化的hit rate监控和告警才能及时发现退化。5.3 后续可以扩展的方向这个项目后续还能往几个方向走。一是加入GraphRAG把股票、行业、产业链、事件之间的关系建成图谱检索时不仅召回文本还能召回关系路径。二是引入更多模态比如把K线图、财报图表也纳入检索。三是做个性化根据用户的历史偏好调整检索和排序策略。我个人在实际操作中的体会是RAG项目里检索质量决定上限工程实现决定下限。模型选型固然重要但切块、检索、排序这些“脏活”才是真正拉开差距的地方。很多团队花大量时间调模型却忽略了知识库本身的质量这是本末倒置。最后分享一个小技巧定期做检索质量的回归测试。我们维护了一个包含200个query的测试集每次改动后跑一遍看hit rate有没有下降。这个习惯帮我们避免了好几次线上事故。
