新闻详情

新闻详情

首页 / 资讯中心 / 详情

RAG智能体实战:A股智能选股分析系统开发复盘

发布时间:2026/10/2 19:51:54来源:尧图网络
RAG智能体实战:A股智能选股分析系统开发复盘
先说个背景。我长期做自然语言处理应用落地平时也拿AI做些投资研究辅助工具。去年四季度开始我给自己定了一个项目用RAG检索增强生成技术做一个面向A股的智能选股分析智能体。不是那种“AI荐股”的噱头而是把财报、公告、研报、舆情这些公开信息统一收进知识库让大模型基于检索结果做推理分析输出有依据、可追溯的公司研究简报。这个项目从前期的技术验证到最终跑通完整链路前后花了大概五周中间换过框架、调过切片策略、被PDF表格折磨过、也被Agent死循环坑过。这篇文章我会把整个开发流程从头到尾复盘一遍包括架构选型理由、每个模块的实现细节、实际踩坑的完整排查过程以及最后效果评估的硬数据。如果你是正在做RAG应用、智能体开发或者对“大模型金融数据”这个方向感兴趣这篇复盘应该能帮你少走不少弯路。1. 为什么用RAG做选股传统量化工具解决不了的三个痛点A股市场的信息量非常庞大但和美股、港股不同A股的公开数据源特别分散。财报在巨潮资讯和交易所官网公告散落在各个平台券商研报要单独购买数据服务新闻舆情更是分布在几十个财经网站和社交平台上。传统做量化选股的人要么依赖结构化因子数据PE、PB、ROE这些要么靠人工盯盘筛新闻。这两种方式都有明显的盲区。第一个痛点是数据孤岛。结构化数据只能反映“公司财务状态如何”但回答不了“公司为什么出现这种状态”。比如一家公司毛利率突然从25%掉到15%财务报表只告诉你结果不告诉你原因。原因大概率藏在年报的“经营情况讨论与分析”章节、调研纪要、或者是某条关于原材料涨价的新闻里。因子模型抓不到这种信息关键词工具也很难跨平台把这些碎片拼起来。RAG天然适合干这个事——把异构的数据源统一切块、向量化、存进知识库然后用语义检索把相关段落找出来再交给大模型做归纳推理。第二个痛点是语义理解。传统搜索是关键词匹配搜“新能源龙头”只会把标题或正文里出现过“新能源”三个字的文档捞出来。但很多细分领域龙头公司财报里写的是“动力电池装机量全球市占率第一”通篇没有“新能源”三个字。关键词搜索会直接漏掉。向量检索能通过语义相似度把“动力电池装机量全球第一”和“新能源龙头”关联起来。这个差异在A股这种概念板块特别多、公司喜欢用专业术语的市场里差距尤其明显。第三个痛点是决策可解释性。我要的不是黑箱给我一个“买入”或“卖出”的信号而是一份带引用的分析依据“这家公司2024年净利润同比增长32%主要原因是海外收入占比提升依据是2024年年报第12页的营收拆分段落”。RAG天然支持这种可追溯输出——模型每说一个结论背后都对应知识库里的一段原文。对于真正拿来做投资辅助的人来说这一点比纯生成式AI靠谱得多。回头解释一下为什么选A股。A股有一个对开发者很友好的特征信息披露体系相对标准化。上市公司定期报告、临时公告、问询函回复都有统一格式而且公开可获取。这就让“建一个高质量知识库”变成了一件可行的事。另外A股的信息不对称现象客观存在这恰恰是语义检索和知识库能做增量价值的地方。这个项目立项之初我给自己定的核心目标是用户用自然语言描述一个投资偏好比如“寻找高股息且现金流稳定的公用事业公司”系统能自动完成三件事——第一从知识库召回相关公司的基本面信息和近期动态第二通过智能体调用行情数据接口补充实时数据第三输出一份结构化的分析报告包含关键指标解读、风险提示和信息来源引用。整个链路围绕“先检索、后推理、再验证”展开。2. 整体架构与技术选型从“能跑通”到“能生产”的决策过程技术选型是这个项目里最花时间、也最值得复盘的部分。我第一个版本只用LangChain做了一个很简单的RAG demo就是从知识库检索几篇文档然后丢给GPT让它回答。这个demo跑通只花了两天但离“智能体”还差得远。真正的智能体需要能调用外部工具行情接口、数据计算模块、能多轮推理、能动态规划任务。这就要在“RAG框架”和“Agent框架”之间做整体架构决策。2.1 技术栈对比与选型结论我把市面上主流的技术方案拉了一个对比表这是我最终选型的核心依据方案核心优势打开后的问题适合场景LangChain生态最全组件丰富社区方案多抽象层多调试链路长Agent编排复杂熟悉代码愿意花时间自己搭所有模块的团队LlamaIndex文档数据接入能力强索引策略多Agent能力偏弱函数调用支持一般做纯知识库问答Agent需求弱的场景Dify可视化工作流Agent配置简单自带知识库管理自定义逻辑受限于平台抽象能力快速搭建应用Agent场景丰富后期维护方便原生开发完全可控性能上限最高所有组件都要自己写周期长有平台工程团队的大厂最后我选了Dify作为主体开发框架但中间的知识库构建和评测并没有用Dify自带的知识库功能而是自己用Python写了一套完整的文档处理和检索管线。这个决策的原因很实际Dify的Agent编排工具调用、上下文变量管理、节点流程控制做得确实成熟帮我省了大量底层工作流代码。但Dify的知识库切片策略和召回调参空间不够灵活金融文档的格式又比较特殊我需要自己做精细化控制。知识库管线通过API对接到Dify两边各取所长。2.2 模型选型的几个考量LLM方面我先后测过几款模型。最终主力用的是DeepSeek-V3备用模型是通义千问Max。选择理由有两点一是中文财务文本理解能力这两个模型对长文本财报的归纳能力明显比同参数量的其他开源模型稳定二是函数调用Function Calling的准确率在需要输出结构化JSON的场景比如让模型决定调用哪个工具、提取哪些参数这两个模型的表现是达到可用标准的。Embedding模型用的是BAAI的bge-large-zh-v1.5这是我们评测下来中文财务语义检索效果最稳的开源模型MTEB中文检索基准上排名靠前而且是MIT协议可以商用。向量数据库用了Qdrant因为它的Payload过滤功能配合Dify的Agent上下文管理比较方便后续要扩展Metadata级别的过滤比如只搜某个行业、某个报告期不用改架构。2.3 四层架构的整体设计整个系统分四层每层的职责边界非常清晰数据接入层负责从Tushare、AKShare、巨潮资讯爬虫拉取财报、公告、龙虎榜、资金流向等数据统一清洗后落库。这层有独立的调度任务按披露周期财报季/日常公告和日频行情数据分别运行。知识库层处理上文提到的文档切片、向量化、索引构建。知识库按行业和文档类型打标方便后续元数据过滤。这层是RAG质量的核心也是后面花时间最多的部分。Agent编排层Dify承担。内容包括多个Agent节点、工具调用配置、多轮对话管理。Agent节点之间通过变量传递数据上游Agent的产出比如筛选出的候选股票列表变成下游Agent的输入。应用交互层一个简单的Web界面和API服务。用户输入投资偏好后系统异步执行Agent工作流最终返回结构化的分析报告。这套架构设计隐含的一个关键选择是把RAG检索能力做成知识库Agent的“工具”而不是整个系统的主干。也就是说“检索知识库”和“调用行情接口”在Agent看来是平级的两个工具。Agent会先判断当前任务需要哪个工具再决定调用顺序和参数。这个设计的优势是灵活性——最终用户问“为什么这家公司毛利率下滑了”Agent会去查知识库问“今天北向资金买了什么”Agent会去调行情接口问“帮我对比两家公司的估值和增长情况”Agent会把两个工具串起来用。这是典型的Agentic RAG思路不是被动地“先检索再回答”而是主动规划“检索什么、检索几次、怎么用检索结果”。3. RAG落地的核心环节知识库建设、切片与召回优化RAG项目有个很反直觉的规律决定效果上限的80%因素在数据侧只有20%在模型侧。你换了更贵的模型不如把文档切片策略调好。把知识源处理好检索召回率能肉眼可见地提升一个档次。这个部分我把整个流程拆开细讲包括每个步骤背后的取舍逻辑。3.1 知识源处理从PDF到干净文本的漫长预处理知识源分五类定期报告年报、半年报、季报、临时公告重大合同、股东增减持、问询函回复、券商研报通过研报数据API获取这部分用了外部数据服务、新闻舆情财经新闻站抓取按公司关联度打标、调研纪要投资者关系互动平台的问答记录。最大的坑在财报PDF。上市公司年报PDF有两种典型问题一种是文字版PDF但版式复杂表格和正文交错排布直接按页提取会得到大量半截表格另一种是扫描件必须走OCR。我试过三种处理方案的组合PyMuPDFfitz负责快速提取文字层保留“页面-段落-表格”的结构信息。pdfplumber专门处理表格能提取出单元格级别的数据。实测下来pdfplumber对A股财报常见的三线表还原度最高但速度慢一份两百页的年报要跑两分多钟。OCR兜底针对扫描版PDF用PaddleOCR的表格识别模型做版面还原但只对确实没有文字层的文件用因为OCR的精度天然有上限。这个预处理流程跑出来的脏数据比例大约在5%到8%集中在表格跨页、单元格合并、特殊符号百分比符号被拆开、单位“万元”和数字分页这几个常见问题上。针对表格跨页的问题我最后写了一个后处理脚本先按“报表编号公司代码”做表格碎片匹配跨页的表格片段在匹配后重新拼接。这个脚本花了一个下午买到了至少能提升3%召回率的效果。3.2 切片策略固定窗口切分是毒药在RAG项目里切片策略直接决定检索质量的底线。我之前做过一个科技类知识库用固定512字符切分效果还行但金融文档完全不是这么回事。金融文本的语义单元是“段落群”而不是“句子”。比如年报的经营分析章节典型结构是“报告期内公司实现营业收入XX亿元同比增长XX%主要系以下原因1下游需求回暖2新产品量产交付3海外市场拓展取得突破毛利率同比提升X个百分点”。这整段是一个完整的因果链如果按固定窗口切前半段被切进切片A原因列表被切进切片B用户提问“为什么这家公司营收增长了”向量检索在切片A找到了“营收增长XX%”但真正回答“为什么”的原因说明在切片B里召回结果就不完整。我最终用的是“结构感知切片”策略按文档本身的层级来切优先按章节标题切一级标题、二级标题章节内部按段落切段落超过500字时用滑窗按句群切割窗口400字、重叠50字表格单独处理整表转成自然语言描述后作为一个独立切片元数据里标记“表格类型”。这个策略跑下来的效果和固定窗口切分对比语义召回率recall5提升了接近9个百分点。核心原因是结构感知切片保住了文档原有的“上下文完整性”模型检索到一段文字时读到的是一段有头有尾的完整论述而不是半截语料。表格转自然语言这个细节值得多说两句。财报里最关键的财务数据全部在表格里但表格直接向量化效果很差——多维表格的结构信息行头、列头、单位在向量化时会被压缩掉。我的做法是写了一个模板化的表格解释器把三线表转成“主语谓语宾语”的陈述句“2024年第一季度营业收入单位万元为123,456万元较上年同期增长15.32%”。这样一条记录变成一个高信息密度的文本句子检索的时候“2024年Q1营业收入增长”就能精准匹配到。3.3 混合检索与重排序只靠向量是不够的金融场景有一个很致命的检索问题实体名一致但语义完全无关。比如搜“宁波银行”向量检索可能召回所有金融板块的银行股文档因为“宁波银行”和“银行板块”在语义空间里距离很近。反过来搜“某公司毛利率下滑的原因”如果文档里只用了一句“主要受原材料价格上涨影响”没有出现“毛利率下滑”这几个字纯BM25关键词检索又会漏。所以最终召回策略是混合检索BM25关键词召回 向量语义召回两路各取Top50合并去重后统一进入重排序Rerank阶段。BM25负责精确匹配实体名、财务术语向量负责语义匹配意图两者互补。重排序用的bge-reranker-v2-m3模型把Top100的候选压缩到Top5才真正把相关文档精排到模型context里。这个组合的实际效果对比我后面会有专门一节用评测数据说明。概括一下单向量检索的hit5只有62%左右混合检索之后hit5到了78%加上重排序之后hit5稳定在85%以上而且模型回答的幻觉率明显降低因为Rerank把高质量片段顶到前排低相关片段被滤掉了。3.4 知识库更新机制财报季的搬运危机A股的知识库有一个动态性问题新财报发出来之后旧财报的信息过时了。公司2024年半年报发布后年报数据就只剩参考意义。如果不处理数据时效性检索系统会把过时信息和高频交易信息混在一起给到Agent模型输出就会混乱。我设计的方案是按“报告期”做元数据级隔离。知识库里每一条切片都带“报告期”和“公告日期”两个字段。检索时默认只查最新报告期只在用户明确要求历史对比时才放行历史切片。这个思路很简单但让Agent的输出准确性有了根本保障——它不再可能把2022年的营收数据和2025年的混在一起比较了。4. 智能体决策链路设计从“有信息”到“会推理”知识库把“信息”准备好了接下来的问题是怎么让大模型用这些信息做推理。这个环节我前后改了三版最后跑通的方案是“多角色Agent分工协同”。4.1 为什么不是一个Agent而是四个最初版本是一个全能Agent把知识库工具、行情工具、计算工具全部挂给它。实测效果很差原因是“上下文噪声”太高——Agent一次收到的工具说明和候选文档太多决策路径反而模糊。出现的事故包括用户要分析A公司Agent却调用了B公司的行情数据要做基本面分析Agent却去查了龙虎榜选股逻辑跑偏。后来参考了业界多智能体协作的思路拆成四个专职Agent各管一段选股Agent负责从用户描述中提炼筛选条件生成候选股票池。它主要做信息抽取和条件匹配不涉及复杂推理。基本面分析Agent调用知识库检索工具拉取候选公司的财报、公告、研报片段按统一模板分析盈利能力、成长性、偿债风险、现金流质量。风险过滤Agent专门检索负面信息包括监管问询函、股东减持、财务疑点应收账款暴增、经营活动现金流和净利润长期背离、商誉占净资产比过高等。输出“该股票的风险标签列表”。报告生成Agent汇总前三个Agent的输出生成最终的分析报告同时生成“信息溯源列表”每条结论后面跟着来自知识库的原始引用片段。四个Agent串行执行通过Dify的节点流程控制。前一个Agent的输出是后一个Agent的输入任何一个环节失败都会中断并返回错误信息。4.2 Prompt设计中的三个关键约束Agent听话程度90%取决于Prompt怎么约束。我在每个Agent的System Prompt里做了几个铁律第一条明确禁止超出检索结果做事实判断。Prompt原文大意是“你是基本分析助手基于检索到的资料回答不许使用检索结果之外的常识性数据。如果检索资料不足回答‘资料不足’并建议用户补充搜索条件”。这个约束是减少幻觉的第一道防线。第二条双向论证机制。要求Agent同时给出看多论据和看空论据而不是只找验证用户预设的素材。这是基于经典的行为金融学研究——人的决策天然有“确认偏误”只关注支持自己观点的信息AI Agent如果不强制约束会天然复现这种偏误。用户说“帮我看看这家公司值得关注吗”如果知识库里有60%正面信息和40%负面信息Agent要有能力把40%的负面信息完整呈现在风险段落里。第三条结论必须带证据链。最终报告里的每一个关键数值后面要有醒目标注标明结论对应的切片ID。展示格式是“[来源切片编号/文档名/段落号]”。这条约束让报告的可验证性大幅提升——我能直接回溯到原始财报段落确认模型没有编数字。4.3 工具调用与上下文管理的工程细节Agent在日常运行中会动态调用行情接口获取实时数据。这里涉及一个工程细节知识库切片里的数据是静态的财报数据定期更新但股票价格、换手率、资金流向这些是实时数据必须在推理发生时现查。我在Dify里配置了三个自定义工具实时行情工具输入股票代码返回最新价、涨跌幅、成交量、换手率、市盈率、市净率。财务指标计算工具输入股票代码和报告期返回ROE、毛利率、净利润增速、负债率等核心指标。这个工具直接查结构化数据表不走RAG速度和准确率都高很多。龙虎榜查询工具输入股票代码和时间区间返回近日的主力动向。上下文管理上有一个小坑要提前防行情工具返回的数据包有时候特别大比如龙虎榜明细几十条记录直接塞进上下文会浪费大量token还可能冲淡知识库检索信息的权重。我的做法是在工具返回前加一个“摘要前置”的提炼步骤——工具返回原始数据后先让一个轻量模型结构化成紧凑摘要只保留日期、代码、涨跌幅、净买入额这几个字段再进Agent上下文。实测这种方式能把单次Agent调用的token消耗省掉30%以上同时输出质量不降反升。4.4 一个完整的运行流程示例拿这个系统跑一个真实场景看看效果。用户输入“帮我筛一下A股里面过去三年ROE都大于15%今年一季度利润率还在提升的消费类公司。”整个Agent工作流的执行路径是选股Agent接收任务从提示词里抽取筛选条件。它调用了财务指标计算工具检索出一个约20家公司的初选池消费板块近三年ROE15%营收增长为正。基本面分析Agent接力用知识库检索工具拉取这20家公司的最近年报切片重点是“经营情况分析”章节和财务报表附注逐家生成简评。风险过滤Agent复核检索新闻和公告知识库给每家公司打风险标签。有几家因为最新的减持公告被标记“近期股东减持”有一家因问询函未回复被标记“合规风险”。报告生成Agent汇总输出最终报告。报告按筛选条件逐项展示符合条件的公司每家公司包含核心指标表、投资要点带引用切片ID、风险提示、信息来源索引。这个流程跑一次大约需要40秒取决于知识库检索数量和LLM生成速度输出质量比我一开始预期的好。原因是四个Agent各司其职后每个Agent的上下文都非常聚焦——基本面分析Agent只处理财报切片风险过滤Agent只处理负面信息切片都不会被无关信息干扰。5. 复盘四个最深的坑与完整排障链路任何项目复盘如果不讲踩坑价值至少减半。这个项目过程中我遇到了四个比较典型的技术问题每一个都花了不少时间定位根因。我把排查链路完整写下来这对正在做类似项目的开发者参考价值最大。5.1 坑一财报PDF表格抽取后乱码和数字错位现象第一版知识库建完之后检索质量一直上不去。抽查召回结果发现部分切片内容出现了明显的表格错位——单元格A的数字跑到了单元格B的位置“万元”和“亿元”单位被切在切片边界单位信息丢失。排查过程我一开始以为是pdfplumber的抽取逻辑参数问题调试了各种参数组合table_settings里的lines_straight、vertical_strategy等效果没有根本改善。后来发现问题出在两份不同来源的PDF上——巨潮资讯和上交所官网披露的年报PDF生成方案不一样一些页面是文本型PDF表格结构是真实的另一些是扫描后套了OCR文字层的假文本PDF表线是图片pdfplumber根本识别不出来。根因确认对全量样本做了一次透视抽样100份年报发现约有30%的PDF表格结构无法用规则解析OCR版和数据层缺失的混合状态是主因。解决方案分两路处理。第一路对pdfplumber输出结果做“数字连续性校验”——如果相邻格子的数字类型百分比、金额、日期和表头语义不匹配标记为可疑表格自动转OCR处理。第二路对确定无法可靠解析的表格用目标检测模型直接对表格区域截图再走PaddleOCR的表格识别管线。加上之后表格解析错误率从约8%降到了2.5%以内。5.2 坑二检索返回大量低相关片段模型被带偏上下文污染现象某个测试案例里用户问“某公司半导体业务2024年的增长逻辑是什么”系统给出的回答竟然东拉西扯提到了该公司的新能源充电桩业务和游戏业务但真正的半导体业务描述一个字没提。排查链路我首先怀疑是Prompt里没有强调聚焦回答于是先在提示词上调整。调完之后问题依旧。接着我打开了Dify的检索日志查看召回Top5到底召回了什么——结果发现Top5里有三条来自该公司2024年报的“公司业务概览”章节该章节用大篇幅描述了多元化业务布局只有占比很小的一段提到了半导体而且“半导体”三个字只出现了一次用的是“半导体器件及集成电路”。但模型在生成时面对三条泛泛的业务介绍选择了平均用力的方式。根因确认问题不在Prompt在检索阶段。底层原因是切片粒度太大——年报“业务概览”章节的切片包含了太多业务类别向量化之后语义被稀释了导致“半导体业务”的具体细节被平均语义淹没。解决方案对“业务介绍”类章节单独做了子段落级切片不再和年报其他内容混在一个切片里再加上重排序阶段引入bge-reranker模型做精排问题彻底解决。这个教训是RAG的检索优化永远要先于提示词优化用更好的召回内容比用更强的指令约束带来的提升更直接。5.3 坑三Agent进入死循环反复调用工具停不下来现象有一次用户问“分析一下最近一周市场上热度最高、但基本面有分歧的股票。”这个任务对Agent来说有歧义——“热度最高”需要调行情工具“基本面有分歧”需要检索知识库而Agent在不断权衡这两个信息源的时候陷入了“查行情→发现温度高→想查基本面→查完基本面→觉得情绪变了→又回头查行情”的循环。Dify显示单次任务跑了67个节点Token消耗是正常情况的近十倍。排查过程这个问题的核心不是模型笨而是任务描述本身有模糊性Agent无法确定“最终输出到底以哪个信息源为准”。老旧的多轮推理缺乏终止条件。解决方案两个改动。第一是给Agent设置“最大轮次限制”在工具调用链条中设置上限默认5轮超限即强制生成当前分析并输出“部分分析可能不完整”的提示。第二是优化Prompt强化“行动优先级”逻辑定义当任务涉及实时行情时实时数据先查一次基本面数据后查实时数据只在生成报告时再刷新一次禁止在分析中途反复调用行情接口。这个改动之后类似的死循环没有再发生过。5.4 坑四评测没有统一基准无法判断优化是否有效现象项目中期我对知识库做了一堆调优切片策略调整、检索融合方式优化、Rerank参数但很难说清楚到底效果变好了还是变差了——每次人工试几个问题感觉都差不多但回答质量参差不齐。解决方案我花了两天时间构建了一个“历史回溯评测集”。方法是从过去一年的市场新闻里筛选出50个知名事件反向构造评测问题比如“某公司2024年10月被实控人减持请问减持公告后公司的股价和基本面表现如何”“2025年一季度某行业景气度下滑的导火索是什么”然后让系统看图回答再用答案覆盖率和事实准确率两个指标做量化评估。评测指标选了两个Hit Rate命中率正确答案所依赖的知识库切片是否出现在系统检索返回的Top5中。这是衡量检索质量的指标。幻觉率系统回答中的关键事实性断言在引用切片中能找到原文依据的比例。这是衡量生成可靠性的指标。评测集建成后每次改动都能跑出量化结果。最终版本相比第一版检索Hit率提升了20多个百分点幻觉率从18%压到了5.6%。这两项指标就成了整个项目的基线也是后面每次迭代是否值得合入的判断依据。6. 最终效果、可用性分析与后续扩展方向项目交付时我对整个系统的能力边界做了比较全面的测试。结论分成两部分做得好的是什么以及力所不及的是什么。先看硬数据。基于上面说的历史回溯评测集对比了几个检索方案的最终效果方案组合检索Hit5回答幻觉率平均单次回答时间纯向量检索 Top5直接进上下文62.4%18.3%6.2秒混合检索BM25向量Top5直接进上下文78.1%11.5%7.1秒混合检索 bge-reranker重排 Top585.7%5.6%8.5秒重排对提升质量的作用基本等于“免鉴定”千万别跳过。时间上多了1秒多换来的是15个百分点的命中率提升和超过一半的幻觉率压缩这笔性价比太高了。从“智能体完成任务成功率”的角度看我跑了一个含20个典型任务的验收清单包含“公司基本面分析”“同行业横向对比”“风险信号排查”“概念板块选股”四种任务类型。最终统计19个任务在无人干预的情况下成功生成了符合格式要求的报告1个任务因为知识库中缺乏该公司的最新季报信息Agent主动输出了“资料不足无法完成分析”并建议补充数据源。这个“主动拒绝”的行为比什么都硬——说明Agent学会了识别自己的知识边界。但也要说实话这套系统有明确的能力边界。盘中高频博弈比如“今天午后哪个板块资金流入最强”不是它能干的事一是实时行情数据更新有延迟二是知识库的信息更新机制面向的是日频维度不适合做盘中策略。另外大模型对复杂财务异常模式的识别能力还没有达到专业审计师的水平——“存货周转率下降叠加应收账款翻倍”这类复合风险信号Agent只能提示存在异常解释不了深层的财务操纵动机。这些局限坦白讲是当前阶段大模型知识库架构的通用能力边界不全是工程问题。关于扩展方向我列了几个明确的路线GraphRAG落地把知识库升级为“实体-关系图”公司、行业、产品、供应链、股东之间的关系网络。这样选股Agent就能做多跳推理从“某下游客户砍单”这个新闻推演到“上游供应商订单减少”再到“相关公司业绩承压”这条链。这比纯向量的非线性检索更接近行研分析师的真实思考方式。2025年业内有很多团队在做“Ontology RAG”基于本体的检索增强本质就是用领域知识图谱约束检索范围这在金融场景的价值非常大。Agentic RAG深化当前版本Agent对知识库的调用是“一次性检索”未来可以改成“对话式检索”——Agent根据第一轮检索结果决定第二轮检索的方向比如看到一个风险信号决定深挖审计报告和问询函回复像真正的分析师一样多轮迭代收集信息。预测增强在知识库基础上再接微调过的时序预测模型把量价信息和财务因子整合进推荐逻辑把Agent从“解释过去”升级到“辅助判断未来”。最后分享一个实际项目管理的小心得。这类技术项目的风险不在“功能能不能实现”而在“效果能不能被验证”。如果一开始就定义好评测指标和评测集后面做每个决策都有锚点不会因为某个方案短期效果不直观就被放弃。我在第一个版本跑通后的第三天就停了所有功能迭代花了两天专门做评测集这个决策后来被证明是全场最值回票价的投入。技术方向上的判断我的态度是2026年正在成为智能体应用从概念演示走向工程化落地的分水岭。像Dify这类低代码平台解决了流程编排的问题但真正决定生产效果的还是底层的数据质量和检索链路质量。工具会不停更替对数据、业务和模型能力的理解才是长期竞争力。这也是我在这个项目里最大的收获——一个能用的AI应用落地的难点永远不在“AI”三个字母上而是在需求拆解、数据工程和效果验证这些笨功夫里。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

Claude Code 接入开源模型实战:SageMaker 部署 Kimi/GLM + LiteLLM 路由降本 70% |TaoToken 统一 Key 通道 2026/10/2 20:42:35

Claude Code 接入开源模型实战:SageMaker 部署 Kimi/GLM + LiteLLM 路由降本 70% |TaoToken 统一 Key 通道

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
Claude Code 工具与插件:把 MCP 配置改到 TaoToken 的完整指南 2026/10/2 20:42:35

Claude Code 工具与插件:把 MCP 配置改到 TaoToken 的完整指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
生成式到代理式跃迁:构建保险后援数字分身|QCon上海 2026/10/2 20:42:35

生成式到代理式跃迁:构建保险后援数字分身|QCon上海

🌊 专注 AI 大模型与前沿科技深度解析,习惯从工程师视角拆解技术热点,让我们一起在技术浪潮中保持清醒与好奇 🚀生成式到代理式跃迁:构建保险后援数字分身|QCon上海 上周帮一位转行的朋友看简历&#xff0c…

阅读更多 →
多多开|拼多多几十单发票挨个点慢在哪?怎么批量申请? 2026/10/2 20:42:35

多多开|拼多多几十单发票挨个点慢在哪?怎么批量申请?

上个月月底,我把攒了一整个月没处理的发票单摊在屏幕上,数了数,四十三笔。从第一笔点进去,到第四十三笔点完提交,我中间看了两次表。前后加起来两个多小时。可事后回想,真正花在“点”这个动作上的时间&…

阅读更多 →
神策 SDK 接入自托管埋点服务:从网络请求到 ClickHouse 的排查顺序 2026/10/2 20:42:35

神策 SDK 接入自托管埋点服务:从网络请求到 ClickHouse 的排查顺序

神策 SDK 接入自托管埋点服务:从网络请求到 ClickHouse 的排查顺序 已有神策 SDK,想把事件写入自己的 ClickHouse,最容易误判的不是 SQL,而是“请求有没有送到正确的机器”。浏览器控制台无报错不代表事件入库;Supers…

阅读更多 →
如何为KiCAD MCP Server开发一个新MCP工具:从Zod Schema到pcbnew实现的5步完整教程 2026/10/2 20:42:29

如何为KiCAD MCP Server开发一个新MCP工具:从Zod Schema到pcbnew实现的5步完整教程

如何为KiCAD MCP Server开发一个新MCP工具:从Zod Schema到pcbnew实现的5步完整教程 【免费下载链接】KiCAD-MCP-Server KiCAD MCP is a Model Context Protocol (MCP) implementation that enables Large Language Models (LLMs) like Claude to directly interact …

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉