1. 项目背景与目标拆解从“问答工具”到“选股智能体”这个项目最初的起点其实不是“我要做一个RAG”而是“我受够了每天在行情软件、研报网站、财报PDF之间来回倒腾”。做A股选股这件事散户和量化研究员都会遇到一个共同的尴尬信息极度碎片化。你要看一家公司的基本面得去翻财报PDF你要看市场情绪得去刷新闻你要看行业政策得去翻研报和金十数据等到你想把这些信息汇总成一个判断往往已经过去一两个小时而且大概率你已经忘了之前看过什么。我当时的目标很明确能不能把所有跟A股选股相关的非结构化数据包括财报、公告、研报摘要、行业新闻、政策解读全部扔进一个知识库然后让大模型基于这个知识库来回答问题、给出选股建议同时还能在我需要的时候去拉取实时行情做二次校验说白了这就是典型的RAG加Agent的框架知识库负责“记忆”Agent负责“思考和行动”实时数据接口负责“落地验证”。很多人一提到RAG就以为只是“向量检索加对话”但实际上在A股这个场景里如果没有Agent的编排能力纯RAG的幻觉问题会非常致命。比如你问“XX公司去年的净利润增长率是多少”如果知识库里的财报PDF是去年5月发布的里面写的是2023年报数据而今天是2025年那么一个不带Agent的RAG肯定会把过时数据当成正确答案给你这在投资决策里是绝对不能接受的。所以这个项目的核心设计原则从一开始就定下来了RAG管长记忆和深度分析Agent管意图判断和工具调度实时行情接口管时效性兜底。1.1 核心需求解析这个项目到底要解决什么问题先把这个项目要解决的问题拆成四层来看。第一层是“信息获取层”你要能把不同来源、不同格式的数据统一收进来PDF、HTML、TXT、Markdown、CSV都得处理而且得处理好表格和长文本第二层是“知识组织层”你得让数据能“按需取用”这就涉及到切分策略、向量化、索引结构我见过太多人栽在这一步以为随便切几刀扔进向量库就行第三层是“推理决策层”大模型要能根据用户的自然语言问题判断该检索什么、该调什么工具、该计算什么指标这是智能体和纯RAG最大的区别第四层是“时效校准层”A股是强时效市场昨天和今天的判断可能完全相反所以系统必须能在关键时间节点拉取实时价格、涨跌幅、量比数据来修正知识库里的滞后信息。这四个层级的需求不是孤立的它们之间是递进依赖的。如果你的知识组织做得烂向量检索出来的都是一堆碎片大模型再聪明也拼不出完整图景如果你的推理决策层不包含工具调用逻辑那即使检索到了准确信息也没法结合实时数据进行动态验证。所以这个项目的复盘我要按我实际开发的顺序来讲先搭RAG底座再叠Agent层最后缝合实时数据管道这样每个环节的问题都能说清楚“为什么这么做”。1.2 我为什么选择Agentic RAG而非纯RAG这里要展开讲一个很关键的架构决策。市面上绝大多数RAG教程包括很多所谓的企业知识库方案做的是“问答式RAG”用户提问系统检索、拼接上下文、大模型作答。这在文档问答场景里够用但A股选股不一样它天然是一个多跳推理加工具调用场景。举一个具体的例子“帮我找出最近一周发布业绩预增公告、且主力资金连续净流入超过3天、同时股价还没大涨的消费电子公司。”这个问题如果用纯RAG做你先把“业绩预增公告”相关的知识塞给模型再把“资金流向”相关的知识也塞给模型模型大概率会给你一个看似合理但根本无法验证的答案因为“主力资金连续净流入超过3天”这个信息根本不在你的知识库里它存在于行情API里。所以我在设计时直接就走到了Agentic RAG的路线上意图识别模块先判断用户的问题需要哪些信息然后分两类去取数一类走RAG检索知识库另一类走工具调用去实时拉数据最后再汇总给决策模型做综合判断。这种架构本质上就是把“静态知识”和“动态数据”剥离让大模型不要用过期知识去回答需要实时验证的问题。相关热词里出现的agentic rag、多智能体、dify智能体平台这些概念本质上都是在解决同一个问题大模型不擅长精确计算和实时联动你得给它配上工具和流程。我的最终实现是LangChain框架管编排和工具封装向量存储用MilvusEmbedding模型用BAAI/bge-large-zh-v1.5决策模型用的是DeepSeek和Qwen两个做对比实验。后面会讲每一步的具体配置和踩坑过程。2. 数据管道构建A股知识库的垃圾进垃圾出问题A股数据处理的第一个坑往往不是算法问题而是数据本身太脏。如果你的知识库里装的是垃圾那无论你RAG的检索策略多先进出来的结果都是垃圾这就是“garbage in garbage out”的经典翻车。先说数据源。我做这个项目时主要收了四类数据每一类的清洗方式完全不一样第一类是财报PDF覆盖全部A股上市公司的年报和季报。这类数据的特征是结构稳定、表格密度极高、页数多。年报动辄一两百页里面大量内容是模板化的“公司业务概要”“董事会报告”真正对选股有用的无非是“经营情况讨论与分析”和三大财务报表。所以对财报PDF的清洗策略不是整本入库而是先用规则加模型混合的方式抽取关键章节再做结构化解构。第二类是公告包括业绩预告、业绩快报、重大合同、股东增减持、股权质押等。公告的格式相对松散各家公司的用词习惯不一样但好在标题里通常会带关键词比如“业绩预增公告”“关于获得政府补助的公告”等。我一开始用正则把这些公告全量灌进知识库结果发现检索效果非常差因为公告里大量冗余的“本公司董事会及全体董事保证本公告内容不存在任何虚假记载……”这类的套话会污染向量语义。后来优化为提取公告正文中语义密度最高的“核心段落”包括数字和结论性表述再把原文折叠起来存成参考链接。第三类是研报摘要主要抓取券商公开发布的策略报告和个股点评。这个数据源质量极高但同样要处理版权和时效问题我只保留了近一年的摘要数据而且对“首次覆盖”“买入评级”“目标价”这类信号词做了额外标注因为这些词对选股判断有强信号作用。第四类是新闻和政策文本包括财经新闻、行业要闻、监管政策。这类数据的问题在于噪音太大同一条新闻可能被多家媒体转载内容高度重复而且标题党的比例不低。我的处理方式是做了一个轻量级的去重和热度过滤同时用文本摘要模型把长新闻压缩成100字以内的核心语义节点这样既能减少向量库冗余又能提高检索命中率。2.1 文本切分策略固定窗口切分是最大的坑如果你在网上搜RAG教程百分之九十会教你用固定窗口切分比如每512个token切一段带128个token的重叠。这个方案在通用文档上勉强能跑但在A股财报和研报场景下效果极其糟糕我第一版就是这么干的检索效果一塌糊涂。举例说明一份贵州茅台的年报里“经营活动产生的现金流量净额”这个指标在“管理层讨论”和“财务报表附注”两个地方都会出现如果按固定窗口切这两个位置大概率被切成不同的chunk而且各自上下文都不完整。当你提问“茅台的经营现金流怎么样”向量检索可能只召回其中一个chunk甚至可能召回的是附注里毫无上下文的一串数字。我的解决方案是结构感知切分针对不同文档类型设计不同的切分规则。财报类按章节层级切先从PDF中抽取标题层级按“一级标题加二级标题”锁定切分边界每个chunk尽量控制在600到800个中文字符左右公告类按语义段落切用句号和段落边界做自然切分同时把标题里的强信号词作为元数据注入chunk研报摘要用滑动窗口加语义去重因为研报的段落没有明确边界我结合Embedding的相似度把连续的低相似度文本段识别为新段落起点。实测下来结构感知切分比固定窗口切分在Hit Rate上提升了大概22%到25%这是整个项目里性价比最高的一次优化。2.2 向量化与混合检索单靠向量会漏掉关键信息Embedding模型的选择上我对比过OpenAI的text-embedding-ada-002、BGE-large-zh-v1.5、M3E-base以及后来出的text2vec-large-chinese。结论很直接对于中文金融文本BGE-large-zh-v1.5的综合表现最稳金融术语的语义区分度比OpenAI的英文模型转中文要好得多而M3E-base在短文本上不错但长金融文档的召回效果偏弱。但向量检索不是万能的有两个致命问题。第一A股里大量关键信息是数值型的比如“营收同比增长23.5%”里的“23.5%”Embedding模型对数字的表达能力很差你把整个文档向量化后检索“哪些公司去年营收增长超过20%”它会把“增长”这个词的语义放得很重但数字会被稀释得很厉害。第二财报里大量同义异构的表述比如“归母净利润”和“股东应占溢利”指的是同一个东西向量检索有可能召回但不太稳定。所以我在检索层直接上了混合检索BM25稀疏检索加向量稠密检索然后再用RRFReciprocal Rank Fusion做结果融合。BM25负责精确关键词命中向量负责语义相似度召回两者取交集和并集后再排序。同时在召回的chunk里我还用正则预标注了所有数字模式把“同比增长XX%”“净利润XX亿元”这类关键数值块结构化提取出来作为额外的匹配特征。这套混合检索架构上线后召回质量明显上了一个台阶。纯向量的Hit Rate大约在60%上下混合检索能稳定干到82%左右配合Rerank之后Top-5答案的相关性明显更贴合问题意图。2.3 元数据注入让知识库具备筛选能力这一步很多人会忽略但它在真实项目中价值极大。所谓元数据注入就是让每个chunk不只是存文本内容还要携带它的“来源标签”股票代码、公告日期、文档类型、相关行业、财报期次、主要实体等。为什么要这么做因为RAG在金融场景里经常需要带条件的检索。比如你问“中远海控最近三个月的营收预测”如果知识库没有元数据标记向量检索会把中远海控过去五年的所有财报chunk全部召回但你其实只需要最近三个月的。有了日期和股票代码的元数据我可以在检索后端加上过滤stock_code601919发布日期大于某一天这样返回的chunk都是符合时间窗口的精准数据。这个设计的另一个好处是可以做权限和范围控制。比如在实盘环境中某些数据的发布时间不能早于当前时间避免未来函数这就靠元数据里的发布日期做硬过滤。3. Agent层设计与工具编排从“能说”到“能算能查”RAG底座做完之后就进入Agent层。这也是这个项目区别于普通知识库问答的核心所在。我用的Agent架构是LangChain里的OpenAI Function Calling模式但因为主力模型是国产的Qwen和DeepSeek所以实际是通过两层封装实现的第一层是模型本身的Function Call能力DeepSeek和Qwen都原生支持工具调用协议第二层是LangChain的StructuredTool封装把我的外部数据接口统一包装成模型可调用的函数对象。Agent的工作流程大概是这样用户提问进来先经过一个轻量的意图分类器判断这个问题的类型是“查询型”“计算型”“对比型”还是“综合决策型”然后Agent根据类型选择工具路径。查询型问题直接走RAG检索计算型问题会调用实时行情接口加财务计算工具综合决策型问题则是一个多步骤的流程先RAG召回基本面信息再调用行情工具拉实时数据最后汇总到决策模型生成最终建议。3.1 工具调用设计实时行情接口与财务计算能力集成这里要重点说一下工具调用的设计细节。我把能力拆成了四个工具模块实时行情工具封装了A股行情API提供个股最新价、涨跌幅、成交量、换手率、量比、主力资金净流入等字段。模型在需要判断“最近是否突破均线”“是否放量”这类问题时会自动拼接股票代码调用这个工具。财务指标计算工具输入一个股票代码工具会先从财务数据库中拉取最近八个报告期的关键财务数据然后在端侧用Python代码动态计算“营收增速、净利增速、毛利率变化、ROE趋势、负债率”等衍生指标而不是让大模型自己心算因为大模型的数学能力尤其是财务口径上的计算极不可靠。公告事件工具封装了公告检索API按股票代码和日期范围拉取公告标题及摘要供Agent判断“最近有没有大事发生”。行业板块工具输入行业名称返回该行业当前的涨跌排行、估值分位、资金流向用于判断行业景气度和横向对比。工具设计的核心原则是“把计算和验证交给代码把推理和抉择交给模型”。大模型应该负责理解意图和生成结论而所有需要精确数字的操作必须让代码来完成。无数人在这上面翻车就是因为让大模型直接基于上下文做计算结果算出来的数据假到离谱。3.2 模型选择与调优DeepSeek、Qwen和GPT的对比实验模型层面我做了三轮对比实验分别用GPT-4o-mini、Qwen2.5-72B和DeepSeek-V3跑同样的Agent任务记录任务成功率、工具调用正确率、最终答案的准确性和推理耗时。先看结论DeepSeek-V3的综合表现最好特别是在中文金融术语的理解和工具调用参数拼接上几乎很少出现“调用工具时参数写错”的问题而这在Qwen上碰到过不少。GPT-4o-mini的工具调用协议最标准但中文理解上偶尔出现别扭的翻译腔而且价格贵得多。Qwen2.5-72B在长文本理解上很强但工具调用时存在“一次调用返回多个动作”的倾向导致Agent状态管理变得复杂。另一个重要发现是温度参数。做RAG检索问答时我把温度设成0.1保证输出稳定忠于上下文但Agent决策场景下温度设在0.4到0.5之间效果更好因为太低的温度会让模型过于保守不愿意主动调用工具去验证信息几乎总是试图直接从上下文里憋出一个答案。经过观察这个项目最终采用“问答场景0.1、工具调度场景0.4、投资分析总结场景0.3”这样的分级温度配置。3.3 语境窗口管理与上下文拼装策略Agent跑起来之后你很快会遇到一个工程问题上下文太长。一个完整的Agent执行流程可能包含多个工具的返回结果、多段RAG召回片段、历史对话记录全部塞进Prompt很容易打爆模型上下文窗口或者让模型在信息海洋里迷失重点。我采用的策略是“三明治拼装法”。最上层是最新的用户问题和当前意图中间层是工具返回的结构化数据摘要我要求所有工具在返回数据时都先通过一个压缩函数做字段截断只保留关键指标和代码不带冗余文本最下层才是RAG召回的文本chunk列表。而且RAG召回的chunk数量不是固定取Top-4或Top-5而是根据当前问题的复杂度动态设定简单问题检索Top-3综合决策问题最多检索Top-6超过这个数字信息增益会迅速衰减反而干扰模型判断。这个策略其实是跟Agent的执行反馈强相关的每次Agent要调用下一步工具时只把与该步骤相关的上下文传给模型而不是把整个执行历史完整丢过去。简单说就是让模型“每次只看到当前需要的信息”而不是“一次看到所有能看的信息”。4. 检索优化与Rerank实战准确率是怎么提起来的RAG项目的核心体验指标就是检索质量检索质量不行后面模型再强也白搭。这一章专门复盘我在检索环节踩过的坑和最终采用的方案。4.1 向量检索的坑相似度阈值与归一化第一版上线的时候发现一个很诡异的现象用户问“新能源汽车行业龙头”答案里居然出现了一堆关于电池材料生产商的描述。我一开始以为是Embedding模型的问题后来排查发现问题出在向量检索的相似度阈值上。Milvus默认返回的相似度分数是原始距离值不同模型的分数分布不一样如果不做归一化就会出现“相对高的分数”被当成“绝对精准的匹配”。解决方案是在向量导入时对每个chunk的Embedding做L2归一化再统一用余弦相似度作为度量方式。同时我把召回阈值从固定的0.75调整成了动态策略——先按相似度倒序取前20个候选再结合BM25得分做融合最后再做一次Rerank而不是在最开始就硬性截断。4.2 为什么需要Rerank粗排和精排的职责分离RAG里的两阶段检索其实很像招聘筛选向量检索和BM25是HR粗筛简历只要匹配度高就进池子Rerank就是技术面试官要细看内容质量、上下文匹配度、时间合理性最终决定谁进入候选名单。我用的Rerank模型是bge-reranker-large这个模型比bge-large的向量检索模型更适合做交叉编码的精排因为它能把“问题加chunk”拼接成一个整体输入建模两者之间的深层交互关系。粗排阶段Top-20的chunk经过Rerank之后我保留Top-5进入生成环节这个筛选力度刚好。这里有一个实测数据值得分享加入Rerank之后Top-5的命中准确率从大概65%提升到了89%左右。代价是额外的推理耗时每个查询大约增加250到400毫秒但这点延时对A股选股场景完全值得。4.3 时间衰减权重让旧知识别捣乱A股知识库有个特殊性旧数据的价值衰减极快。去年的“热门赛道”今年可能就是“过气题材”一个季度前的爆款研报可能早就被市场消化完毕。如果不加时间衰减RAG很容易把已经失效的“旧王”当“新王”推给用户。我的做法是在检索打分阶段引入时间衰减系数chunk的最终得分等于Rerank分数乘上一个时间衰减因子越新的数据权重越高衰减速度根据文档类型差异化调整。比如行情类数据和行业快讯半衰期设为7到10天财报类数据半衰期设为90天研报摘要的半衰期设为45天。这样即使旧文档的语义相似度很高也会在时间维度上被压分把位置让给更新的信息。5. 实操过程中的典型案例与Bug排查过程这一章分享几个我在开发部署过程中遇到的最典型的故障案例每个案例背后都藏着一个值得记录的设计失误。5.1 案例一LLM在财报数值计算上疯狂翻车有一次测试用户问“宁德时代2024年上半年营收同比增长多少”。Agent先通过RAG检索到了年报原文chunk里面明确写了“2024年上半年实现营业收入XXXX亿元同比增长XX%”。当时我还特意打印了日志确认chunk内容完全正确但大模型给出的答案是“同比增长约30%”和原文的“34.5%”差了4.5个百分点。排查后发现问题出在生成阶段的Prompt模板上。我原来的模板只给了“请根据以下资料回答问题”没有明确要求模型直接引用原文中的数字这给了模型“自由发挥”的空间它可能用了上下文里其他年份的数字然后做了近似估算。修复方案是双管齐下。第一步在生成Prompt里加入硬性约束和角色设定“你是严谨的证券研究员回答中的财务数据必须与参考资料保持一致若参考数据缺失或不完整请明确回答‘资料不足’。”第二步在RAG检索后的上下文里注入结构化字段把chunk中预提取的数字块作为“扫描数据”单独传给模型并要求“优先引用扫描数据字段中的精确数字”。这样把大模型从“阅读理解加记忆”的负担里解放出来它只需要做“引用粘贴和逻辑组织”。5.2 案例二多Agent并发运行时内存被击穿项目后期我尝试了多Agent架构让三个Agent同时干活一个管基本面搜索一个管实时行情分析一个管新闻情绪扫描。结果在并发压测时频繁出现OOM崩溃日志里全是“CUDA out of memory”和“Connection reset by peer”。排查后发现问题不在显卡显存而是LangChain的工具执行框架会为每个Agent维护独立的执行栈和消息列表多个Agent并发跑时这些历史消息被保留在内存里没有一个自动清理机制。尤其是有Agent进入循环调用工具的死循环时历史消息会指数级膨胀。解决方案是引入“Agent执行预算”机制给每个Agent的执行轮数设定上限默认最多执行5轮工具调用超过即强制终止并返回已收集到的部分结果同时在每轮工具调用结束后对历史消息做截断只保留最近两轮的核心摘要丢弃原始工具返回体。修复后系统稳定了很多倍并发能力提升了一个量级。5.3 案例三Retrieval重复和上下文拥挤导致幻觉有一次回答“银行板块当前估值分位”问题时系统返回了5个chunk其中有三个其实是同一篇研报的不同切片段落内容高度重叠。模型基于这些重复信息生成了结论看起来逻辑严密但其实只覆盖了单一来源这就是典型的“重复召回导致的信息盲区”。修复方法是引入MMRMaximal Marginal Relevance多样性排序在做最终Top-5筛选时不仅要看chunk和问题的相关性还要计算chunk之间的差异性相关性高但和已选chunk高度重复的就降权。这个优化让回答内容覆盖的文档来源数明显增加单一来源垄断结论的情况几乎消失了。6. 评测体系、效果指标与后续可扩展的空间作为项目复盘评测这部分必须讲清楚。没有评测体系你是没法判断“这次优化到底有没有用”的。我搭了一个相对轻量的评测集包含大约500个真实投资分析问题分成四大类事实查询类“XX公司2023年净利润是多少”、推理洞察类“XX公司现金流恶化可能带来什么风险”、对比分析类“对比XX和YY两家公司的成长性”、综合决策类“当前市场环境下哪些板块值得重点关注”。每一条评测都有人工标注的标准答案和关键考察点。评测维度上我重点看三个指标Hit Rate、答案准确率、端到端耗时。Hit Rate评测检索环节只判断召回的chunk中是否包含能回答问题的关键信息答案准确率是人工打分看模型基于召回内容生成的最终答案是否可靠端到端耗时主要用来评估系统实际使用体验尤其是Rerank和多Agent调度带来的延迟成本。经过多轮优化后最终的成绩大概是召回命中率87%左右答案准确率约82%金融场景里这个数已经很能打了端到端平均响应时间3.8秒其中RAG检索和Rerank合计约1.2秒Agent工具调度和生成占了剩下的时间。这里面最耗费功夫的不是增加模型参数而是数据处理、元数据设计和检索策略的组合优化数据和工程细节才是决定天花板的模块。再聊一下后续扩展。这个项目的架构天然适合加东西比如把深度研报PDF的整本解析能力再强化加入图表OCR识别让模型能“看”财报图表或者把多Agent的并发调度能力再做好一点实现基本面结论和实时情绪的联动校验也可以把记忆模块升级成长期记忆体保留用户在历史对话中的关注点和持仓偏好让每个用户的选股建议更个性化。最后再分享一个小经验就是这个项目让我深刻体会到的做RAG智能体最容易低估的是数据工程的耗时占比。你以为你在写Agent逻辑写Prompt实际上百分之六十的时间都在处理数据清洗PDF、设计切分规则、写元数据、做去重和压缩。数据底座不牢固上层全部白搭。如果你也想做类似方向我建议把时间分配大致定为六成给数据三成给检索优化一成给Agent编排和模型调参。这样节奏会顺很多效果也更容易落地。