拓冰网站定制 
1. 从速度到认知量化投资正在经历什么变化做了七八年量化策略开发我越来越强烈地感受到一个拐点过去我们拼的是谁的回测跑得快、谁的因子挖掘效率高、谁的执行延迟低但现在这些正在变成基础设施而不是核心竞争力。中金那份报告里提到的从速度到认知我理解说的就是这个意思——当算力、数据、执行通道都趋于同质化之后真正拉开差距的是对信息的理解深度和决策的认知层次。传统量化交易的核心逻辑是找到历史数据中的统计规律构建因子模型通过回测验证然后实盘执行。这套方法论在过去二十年里非常有效因为市场参与者的信息处理能力有限定价偏差会持续存在。但现在的情况变了——市场里充斥着各种高频策略、统计套利模型简单的线性因子早就被挖掘殆尽。你用一个普通的动量因子或者均值回归因子基本上很难获得稳定的超额收益。AI的介入改变了这个局面但改变的方式和很多人想的不一样。不是简单地用深度学习替代线性回归而是整个决策链条的重构。LLM带来的自然语言理解能力让机器可以处理研报、新闻、公告、社交媒体这些非结构化数据Multi-Agent架构让多个专业化AI可以协作完成从数据采集到决策执行的完整流程RAG技术则解决了大模型知识更新和事实准确性的问题。这三者结合起来形成了一套全新的量化投研范式。这篇文章我想从实操角度拆解这套新范式到底怎么落地。不管你是做传统因子挖掘的量化研究员还是刚接触AI的技术开发者或者是想把AI能力引入投研流程的从业者我都会尽量把每个环节讲透——包括技术选型的理由、参数配置的逻辑、实际踩过的坑以及那些文档里不会写的经验。2. 整体架构设计为什么是Multi-Agent LLM RAG2.1 传统量化流水线的瓶颈在哪里先说说传统量化投研流程的问题。一个典型的量化策略开发流程大致是这样的数据获取和清洗、因子构建和筛选、策略回测和优化、风险管理和实盘执行。每个环节都有成熟的工具链但环节之间的衔接往往依赖人工判断。比如因子构建阶段研究员需要阅读大量研报和论文来获取灵感这个过程高度依赖个人经验和阅读量。一个资深研究员可能一天能读十几篇研报提取出两三个可测试的因子想法。但面对每天市场上新增的海量信息这个速度远远不够。更关键的是人工阅读存在选择性偏差——你倾向于关注自己熟悉的领域和逻辑容易忽略跨领域的信号。回测阶段也有类似问题。传统的参数优化方法网格搜索、遗传算法本质上是在一个预设的搜索空间里找最优解但搜索空间本身是人为定义的。如果最优策略的参数组合不在你定义的搜索空间里那再怎么优化也找不到。风险管理和实盘执行环节传统做法是基于历史波动率设定阈值但市场状态切换时比如从低波动突然进入高波动基于历史数据的风控参数往往反应滞后。2.2 Multi-Agent架构如何重构投研流程Multi-Agent的核心思路是把一个复杂的投研任务拆解成多个子任务每个子任务由一个专门的Agent负责Agent之间通过消息传递协作。这听起来像是微服务架构的思路但关键区别在于每个Agent都具备基于LLM的推理能力能够根据环境变化自主调整行为。我目前搭建的架构大致包含以下几类Agent数据采集Agent负责从各类数据源获取原始数据包括行情数据、财务数据、新闻资讯、研报文本等。这个Agent的关键能力是自适应——当某个数据源出现异常或延迟时能自动切换到备用源。信息理解Agent利用LLM对非结构化文本进行解析提取关键信息。比如从一份财报中提取营收增速、毛利率变化、管理层指引等结构化字段或者从新闻中判断事件类型和影响方向。因子生成Agent基于理解后的信息结合历史数据生成候选因子。这个环节会用到RAG来检索相关的历史研究和类似因子的表现。策略回测Agent对生成的因子进行快速回测验证筛选出有效因子。这个Agent需要与回测引擎紧密集成。风险评估Agent实时监控组合风险敞口在市场状态变化时动态调整风控参数。执行优化Agent根据市场微观结构优化订单执行路径降低冲击成本。这些Agent之间不是简单的串行关系而是有反馈回路的。比如回测Agent发现某个因子在特定市场环境下失效这个信息会反馈给因子生成Agent促使其调整因子构建逻辑。2.3 RAG在量化投研中的关键作用RAG检索增强生成在这套架构里扮演的是知识底座的角色。LLM本身的知识有截止日期而且对于量化领域的专业内容通用LLM的理解深度往往不够。RAG通过外挂知识库的方式让LLM能够访问最新的研报、论文、公告等专业内容。具体到量化投研场景RAG主要解决三个问题第一是时效性。市场信息瞬息万变LLM的训练数据不可能覆盖最新事件。通过RAG每次查询时都从最新的知识库中检索相关内容确保决策依据是最新的。第二是准确性。LLM存在幻觉问题可能会编造不存在的财务数据或事件。RAG通过检索真实文档来约束生成内容大幅降低幻觉概率。第三是可解释性。量化策略最怕黑箱RAG可以追溯每个决策依据来自哪篇文档、哪个数据源方便事后归因分析。2.4 技术选型的考量在实际搭建这套系统时技术选型需要平衡几个因素性能、成本、可维护性、扩展性。LLM的选择上我目前采用的是混合方案日常的信息提取和分类任务用较小规模的模型7B-13B参数级别复杂推理和策略生成任务用更大规模的模型。这样可以在成本和效果之间取得平衡。小模型可以本地部署延迟低、成本可控大模型通过API调用按需使用。向量数据库方面我测试过几种方案。对于量化场景数据量通常在百万级文档以下用轻量级的向量数据库就足够了。关键是检索质量——需要针对金融文本做专门的embedding微调通用embedding模型在金融领域的检索效果会打折扣。Agent框架方面我倾向于自己搭建轻量级的消息传递机制而不是直接用现成的Agent框架。原因是量化投研的流程有很强的领域特殊性通用框架的抽象层次往往不匹配改造成本反而更高。3. 核心模块拆解与实操要点3.1 信息理解Agent的构建细节信息理解Agent是整个系统的入口它的输出质量直接决定了后续环节的效果。这个Agent的核心任务是把非结构化的文本转化为结构化的、可供量化模型使用的数据。以财报文本处理为例一份典型的A股年报有几百页包含大量表格和文字描述。传统做法是用正则表达式或模板匹配来提取关键字段但这种方法泛化能力差不同公司的披露格式差异很大。用LLM来处理就灵活得多。我会设计一套结构化的prompt要求模型从财报文本中提取以下字段营业收入及增速、净利润及增速、毛利率、ROE、经营性现金流、资产负债率、管理层讨论与分析中的关键表述、风险提示等。Prompt的设计有几个关键点要求模型输出JSON格式方便后续程序化处理对于每个提取的字段要求模型标注原文出处页码或段落方便人工复核对于不确定的字段要求模型输出null而不是猜测加入few-shot示例展示期望的输出格式实际跑下来提取准确率大概在85%-90%左右主要错误集中在表格跨页、单位不一致、非经常性损益的区分上。所以我会加一层校验逻辑对于关键财务字段用规则引擎从XBRL数据中提取作为交叉验证两者不一致时触发人工复核。注意LLM提取财务数据时最大的坑是单位问题。有的公司用万元有的用亿元有的用元。如果不做统一后续计算会出大问题。我的做法是在prompt中明确要求模型统一转换为元并在输出中标注原始单位。3.2 因子生成Agent的工作机制因子生成Agent是我觉得最有意思的部分。传统因子挖掘依赖研究员的直觉和经验而这个Agent可以系统化地探索因子空间。它的工作流程大致是首先从RAG知识库中检索与当前市场环境相关的研报和论文提取其中的因子逻辑然后结合历史数据将因子逻辑转化为可计算的表达式最后通过回测验证因子有效性。举个例子。假设RAG检索到一篇关于供应链集中度与股价表现的研报核心逻辑是当一家公司的前五大供应商集中度下降时说明供应链风险分散股价可能有超额收益。因子生成Agent会把这段逻辑转化为计算供应商集中度变化率做横截面排序构建多空组合。这个转化过程需要LLM具备一定的金融工程知识。我会在prompt中提供因子表达式的语法规范让模型按照规范输出。比如# 因子表达式示例供应商集中度变化 factor ( supplier_concentration_ratio(t) - supplier_concentration_ratio(t-4) ) / supplier_concentration_ratio(t-4) # 横截面标准化 factor_rank cross_sectional_rank(factor) # 多空组合 long_portfolio top_quantile(factor_rank, 0.2) short_portfolio bottom_quantile(factor_rank, 0.2)因子生成Agent会批量产出这类候选因子然后交给回测Agent验证。我设置的门槛是IC均值大于0.03IC_IR大于0.5多空组合年化收益大于8%换手率低于200%。满足这些条件的因子才会进入下一步。3.3 RAG知识库的构建与优化RAG知识库的质量直接决定了整个系统的上限。我在构建知识库时主要收录以下几类内容券商研报行业深度、公司深度、策略报告学术论文金融、经济、计算机领域上市公司公告年报、季报、重大事项财经新闻主流财经媒体内部研究笔记团队积累的因子逻辑和回测结果文档入库前需要做预处理PDF解析、文本清洗、分块chunking、embedding。分块策略很关键——块太大检索精度下降块太小上下文信息丢失。我的经验是对于研报类文档按段落分块每块控制在300-500字相邻块之间保留20%的重叠。Embedding模型的选择上我测试过几个方案。通用模型在金融文本上的检索效果一般主要问题是金融术语的语义空间和通用语料差异较大。后来我用金融领域的语料对embedding模型做了微调检索准确率提升了大概15个百分点。检索策略上我采用的是混合检索向量检索 关键词检索BM25然后做重排序。纯向量检索的问题是对于精确的财务数据查询比如某公司2023年营收向量检索可能返回语义相似但数据不对的文档。加入关键词检索可以弥补这个缺陷。实操心得RAG知识库需要定期更新和清理。过期的研报、被证伪的逻辑、失效的因子都要及时从知识库中移除或标记。否则LLM会基于过时信息做决策这在快速变化的市场里是致命的。3.4 回测Agent的工程实现回测Agent需要与回测引擎紧密集成。我用的回测引擎是自己搭建的核心考虑是速度和灵活性。速度方面用向量化计算替代循环用内存数据库替代磁盘IO灵活性方面支持自定义因子表达式、自定义调仓规则、自定义风控逻辑。回测Agent的工作流程是接收因子生成Agent输出的因子表达式在历史数据上计算因子值构建组合计算收益和风险指标输出回测报告。整个过程需要自动化不需要人工干预。回测中几个容易踩坑的地方前视偏差这是最隐蔽也最致命的错误。比如用当天的收盘价计算因子然后用当天的收盘价执行交易这就引入了前视偏差。正确的做法是用T日的收盘价计算因子用T1日的开盘价或VWAP执行交易。幸存者偏差回测时只用了当前还在上市的股票忽略了已经退市的股票。这会导致回测收益虚高。我的做法是使用包含退市股票的全样本数据。交易成本很多回测忽略交易成本导致换手率高的策略看起来很美实盘一跑就亏。我会在回测中扣除双边千分之三的交易成本对于高频策略还会加上冲击成本模型。过拟合这是量化策略的通病。因子在样本内表现很好样本外一塌糊涂。我的做法是严格划分样本内和样本外样本外数据在策略最终确定前绝对不碰。同时用多市场、多时间段做交叉验证。3.5 风险评估Agent的动态调整逻辑风险评估Agent的核心能力是识别市场状态切换并动态调整风控参数。传统风控用固定的波动率阈值但市场在不同状态下牛市、熊市、震荡市的波动率特征完全不同。我用的是基于隐马尔可夫模型HMM的市场状态识别方法。HMM可以把市场划分为几个隐含状态每个状态对应不同的收益和波动率分布。当模型判断市场从低波动状态切换到高波动状态时风险评估Agent会自动降低仓位上限、收紧止损线。具体参数上我设置了三个风险等级风险等级触发条件仓位上限单票止损组合止损低风险波动率15%95%-8%-5%中风险15%≤波动率25%70%-6%-8%高风险波动率≥25%40%-4%-12%这些参数不是拍脑袋定的而是通过历史回测优化出来的。优化目标是最大化夏普比率约束条件是最大回撤不超过15%。4. 完整实操流程从零搭建一套AI量化投研系统4.1 环境准备与依赖安装先列一下我用的技术栈和版本方便你复现Python 3.10向量数据库Milvus 2.3 或 Qdrant 1.7LLM推理vLLM 0.4本地部署或主流APIEmbedding模型BGE-M3 或金融领域微调版本回测引擎自研基于pandas numpy numbaAgent通信基于Redis的轻量级消息队列数据存储PostgreSQL结构化 MinIO非结构化安装核心依赖pip install vllm qdrant-client sentence-transformers pip install pandas numpy numba redis psycopg2-binary pip install pypdf pdfplumber beautifulsoup4如果你的机器有GPU建议至少24GB显存这样可以本地部署13B级别的模型。如果没有GPU可以用API方案但要注意数据隐私和调用成本。4.2 知识库构建的完整步骤第一步是文档采集。我写了一个爬虫框架支持从多个数据源采集研报和公告。采集频率是每天一次增量更新。第二步是文档解析。PDF解析用pdfplumber比PyPDF2的表格提取效果好很多。对于扫描版PDF需要用OCR我用的PaddleOCR中文识别准确率不错。第三步是文本分块。我写了一个基于语义的分块器不是简单地按字数切分而是根据段落和标题结构来分块。这样可以保证每个块有完整的语义单元。def semantic_chunk(text, max_length500, overlap100): paragraphs text.split(\n\n) chunks [] current_chunk for para in paragraphs: if len(current_chunk) len(para) max_length: current_chunk para \n\n else: if current_chunk: chunks.append(current_chunk.strip()) current_chunk para \n\n if current_chunk: chunks.append(current_chunk.strip()) return chunks第四步是embedding和入库。用BGE-M3模型生成向量维度是1024。存入Qdrant时同时存储原文、元数据来源、日期、作者、类型和向量。第五步是索引优化。Qdrant支持HNSW索引我设置的参数是m16, ef_construct200。这个参数组合在检索速度和准确率之间取得了不错的平衡。4.3 Agent系统的搭建与调试Agent系统的核心是消息传递机制。我用Redis的Pub/Sub来实现Agent之间的异步通信。每个Agent订阅自己关心的消息频道处理完后把结果发布到下游频道。import redis import json class BaseAgent: def __init__(self, name, redis_client): self.name name self.redis redis_client self.pubsub self.redis.pubsub() def subscribe(self, channel): self.pubsub.subscribe(channel) def publish(self, channel, message): self.redis.publish(channel, json.dumps(message)) def run(self): for message in self.pubsub.listen(): if message[type] message: self.handle(json.loads(message[data])) def handle(self, message): raise NotImplementedError调试Agent系统时最大的挑战是可观测性。多个Agent异步运行出了问题很难定位是哪个环节的错。我的做法是给每个消息加上trace_id所有Agent的日志都带上trace_id这样可以用ELK或类似工具做全链路追踪。4.4 因子生成到回测的完整链路假设我们要生成一个基于分析师预期上调的因子。完整链路是这样的信息理解Agent从研报中提取分析师预期数据输出结构化JSON因子生成Agent根据预期上调幅度和上调家数构建因子表达式回测Agent在历史数据上验证因子有效性如果因子有效进入因子库如果无效反馈给因子生成Agent调整逻辑这个链路我跑过很多次实测下来从信息提取到因子验证完成整个流程大概需要15-30分钟取决于文档数量和回测复杂度。相比人工流程通常需要几天效率提升非常明显。4.5 实盘部署的注意事项回测通过的策略在实盘部署前还需要做几件事模拟盘验证至少跑一个月的模拟盘观察策略在真实市场环境下的表现。模拟盘和回测的差异主要来自滑点和流动性如果差异过大说明回测的成本假设过于乐观。小资金实盘模拟盘通过后用少量资金实盘运行。这个阶段主要观察执行层面的问题比如订单成交率、撤单率、系统稳定性。逐步加仓小资金实盘稳定运行后逐步增加资金规模。每次加仓后观察一段时间确认策略容量足够。注意实盘部署时一定要有熔断机制。当策略出现异常亏损比如单日亏损超过3%系统自动停止交易并报警。这个机制在极端行情下能救命。5. 常见问题与排查技巧实录5.1 LLM输出不稳定的排查思路LLM输出不稳定是这套系统最常见的问题。同样的输入两次调用可能得到不同的输出。排查思路如下首先检查temperature参数。如果temperature设置过高比如0.8以上输出随机性会很大。对于信息提取类任务建议设置temperature0或0.1。对于创意生成类任务比如因子逻辑生成可以适当调高到0.3-0.5。其次检查prompt的明确性。如果prompt存在歧义LLM的输出就会不稳定。我的经验是prompt要尽可能具体明确输出格式、字段定义、边界条件。最后检查模型版本。不同版本的模型行为可能有差异建议固定使用一个版本并在prompt中记录版本信息。5.2 RAG检索质量差的优化方法RAG检索质量差通常有几个原因分块不合理块太大导致检索精度下降块太小导致上下文丢失。解决方法是调整分块策略对于研报类文档按段落分块每块300-500字。Embedding模型不匹配通用embedding模型在金融领域效果差。解决方法是用金融语料微调embedding模型或者使用专门针对金融领域训练的模型。检索策略单一纯向量检索对于精确查询效果差。解决方法是混合检索向量检索关键词检索然后重排序。知识库噪声知识库中包含大量无关或低质量文档。解决方法是定期清理知识库移除过期和低质量内容。5.3 Agent协作中的死锁与超时处理多Agent系统容易出现死锁——Agent A等Agent B的输出Agent B等Agent A的输出双方都卡住。解决方法是设置超时机制每个Agent处理消息时设置最大等待时间超时后抛出异常并记录日志。另一个问题是消息丢失。Redis的Pub/Sub不保证消息可靠投递如果Agent在处理消息时崩溃消息就丢了。解决方法是用Redis Stream替代Pub/SubStream支持消息持久化和消费确认。5.4 回测结果与实盘差异大的归因回测和实盘差异大通常有以下几个原因差异来源回测假设实盘现实解决方法交易成本固定费率冲击成本滑点加入冲击成本模型成交假设全部成交部分成交或未成交加入成交量约束数据延迟无延迟行情延迟加入延迟模拟市场影响无影响大单影响价格限制单笔订单规模我的做法是在回测中就加入这些现实约束虽然会降低回测收益但能让回测结果更接近实盘。5.5 系统性能瓶颈的定位与优化随着知识库增大和Agent数量增加系统性能可能成为瓶颈。常见的性能问题及优化方法LLM推理慢用vLLM做批处理推理或者用更小的模型处理简单任务。向量检索慢优化索引参数或者用GPU加速检索。数据库IO慢加缓存层热点数据放Redis。Agent通信延迟用消息队列替代HTTP调用减少同步等待。6. 一些踩坑之后的个人体会这套系统我从去年开始搭建中间踩了不少坑也走了很多弯路。最大的体会是AI不是万能的它擅长的是处理非结构化信息和生成候选方案但最终的决策和风控还是需要人的判断。另一个体会是数据质量比模型能力更重要。我见过太多团队花大量精力调模型但数据清洗和预处理做得很粗糙结果模型效果怎么都上不去。实际上把数据质量做好用中等规模的模型就能达到不错的效果。还有一点这套系统的维护成本不低。LLM在更新、知识库在增长、市场在变化系统需要持续迭代。如果只是搭起来跑一次那价值有限。真正有价值的是把它融入日常投研流程持续产生和验证因子想法。最后分享一个实用技巧在prompt中要求LLM输出置信度分数。对于低置信度的输出系统自动触发人工复核。这样可以大幅降低错误信息的传播概率同时把人工精力集中在真正需要判断的地方。 Multi-Agent+LLM+RAG：AI量化投研新范式实操指南
1. 从速度到认知量化投资正在经历什么变化做了七八年量化策略开发我越来越强烈地感受到一个拐点过去我们拼的是谁的回测跑得快、谁的因子挖掘效率高、谁的执行延迟低但现在这些正在变成基础设施而不是核心竞争力。中金那份报告里提到的从速度到认知我理解说的就是这个意思——当算力、数据、执行通道都趋于同质化之后真正拉开差距的是对信息的理解深度和决策的认知层次。传统量化交易的核心逻辑是找到历史数据中的统计规律构建因子模型通过回测验证然后实盘执行。这套方法论在过去二十年里非常有效因为市场参与者的信息处理能力有限定价偏差会持续存在。但现在的情况变了——市场里充斥着各种高频策略、统计套利模型简单的线性因子早就被挖掘殆尽。你用一个普通的动量因子或者均值回归因子基本上很难获得稳定的超额收益。AI的介入改变了这个局面但改变的方式和很多人想的不一样。不是简单地用深度学习替代线性回归而是整个决策链条的重构。LLM带来的自然语言理解能力让机器可以处理研报、新闻、公告、社交媒体这些非结构化数据Multi-Agent架构让多个专业化AI可以协作完成从数据采集到决策执行的完整流程RAG技术则解决了大模型知识更新和事实准确性的问题。这三者结合起来形成了一套全新的量化投研范式。这篇文章我想从实操角度拆解这套新范式到底怎么落地。不管你是做传统因子挖掘的量化研究员还是刚接触AI的技术开发者或者是想把AI能力引入投研流程的从业者我都会尽量把每个环节讲透——包括技术选型的理由、参数配置的逻辑、实际踩过的坑以及那些文档里不会写的经验。2. 整体架构设计为什么是Multi-Agent LLM RAG2.1 传统量化流水线的瓶颈在哪里先说说传统量化投研流程的问题。一个典型的量化策略开发流程大致是这样的数据获取和清洗、因子构建和筛选、策略回测和优化、风险管理和实盘执行。每个环节都有成熟的工具链但环节之间的衔接往往依赖人工判断。比如因子构建阶段研究员需要阅读大量研报和论文来获取灵感这个过程高度依赖个人经验和阅读量。一个资深研究员可能一天能读十几篇研报提取出两三个可测试的因子想法。但面对每天市场上新增的海量信息这个速度远远不够。更关键的是人工阅读存在选择性偏差——你倾向于关注自己熟悉的领域和逻辑容易忽略跨领域的信号。回测阶段也有类似问题。传统的参数优化方法网格搜索、遗传算法本质上是在一个预设的搜索空间里找最优解但搜索空间本身是人为定义的。如果最优策略的参数组合不在你定义的搜索空间里那再怎么优化也找不到。风险管理和实盘执行环节传统做法是基于历史波动率设定阈值但市场状态切换时比如从低波动突然进入高波动基于历史数据的风控参数往往反应滞后。2.2 Multi-Agent架构如何重构投研流程Multi-Agent的核心思路是把一个复杂的投研任务拆解成多个子任务每个子任务由一个专门的Agent负责Agent之间通过消息传递协作。这听起来像是微服务架构的思路但关键区别在于每个Agent都具备基于LLM的推理能力能够根据环境变化自主调整行为。我目前搭建的架构大致包含以下几类Agent数据采集Agent负责从各类数据源获取原始数据包括行情数据、财务数据、新闻资讯、研报文本等。这个Agent的关键能力是自适应——当某个数据源出现异常或延迟时能自动切换到备用源。信息理解Agent利用LLM对非结构化文本进行解析提取关键信息。比如从一份财报中提取营收增速、毛利率变化、管理层指引等结构化字段或者从新闻中判断事件类型和影响方向。因子生成Agent基于理解后的信息结合历史数据生成候选因子。这个环节会用到RAG来检索相关的历史研究和类似因子的表现。策略回测Agent对生成的因子进行快速回测验证筛选出有效因子。这个Agent需要与回测引擎紧密集成。风险评估Agent实时监控组合风险敞口在市场状态变化时动态调整风控参数。执行优化Agent根据市场微观结构优化订单执行路径降低冲击成本。这些Agent之间不是简单的串行关系而是有反馈回路的。比如回测Agent发现某个因子在特定市场环境下失效这个信息会反馈给因子生成Agent促使其调整因子构建逻辑。2.3 RAG在量化投研中的关键作用RAG检索增强生成在这套架构里扮演的是知识底座的角色。LLM本身的知识有截止日期而且对于量化领域的专业内容通用LLM的理解深度往往不够。RAG通过外挂知识库的方式让LLM能够访问最新的研报、论文、公告等专业内容。具体到量化投研场景RAG主要解决三个问题第一是时效性。市场信息瞬息万变LLM的训练数据不可能覆盖最新事件。通过RAG每次查询时都从最新的知识库中检索相关内容确保决策依据是最新的。第二是准确性。LLM存在幻觉问题可能会编造不存在的财务数据或事件。RAG通过检索真实文档来约束生成内容大幅降低幻觉概率。第三是可解释性。量化策略最怕黑箱RAG可以追溯每个决策依据来自哪篇文档、哪个数据源方便事后归因分析。2.4 技术选型的考量在实际搭建这套系统时技术选型需要平衡几个因素性能、成本、可维护性、扩展性。LLM的选择上我目前采用的是混合方案日常的信息提取和分类任务用较小规模的模型7B-13B参数级别复杂推理和策略生成任务用更大规模的模型。这样可以在成本和效果之间取得平衡。小模型可以本地部署延迟低、成本可控大模型通过API调用按需使用。向量数据库方面我测试过几种方案。对于量化场景数据量通常在百万级文档以下用轻量级的向量数据库就足够了。关键是检索质量——需要针对金融文本做专门的embedding微调通用embedding模型在金融领域的检索效果会打折扣。Agent框架方面我倾向于自己搭建轻量级的消息传递机制而不是直接用现成的Agent框架。原因是量化投研的流程有很强的领域特殊性通用框架的抽象层次往往不匹配改造成本反而更高。3. 核心模块拆解与实操要点3.1 信息理解Agent的构建细节信息理解Agent是整个系统的入口它的输出质量直接决定了后续环节的效果。这个Agent的核心任务是把非结构化的文本转化为结构化的、可供量化模型使用的数据。以财报文本处理为例一份典型的A股年报有几百页包含大量表格和文字描述。传统做法是用正则表达式或模板匹配来提取关键字段但这种方法泛化能力差不同公司的披露格式差异很大。用LLM来处理就灵活得多。我会设计一套结构化的prompt要求模型从财报文本中提取以下字段营业收入及增速、净利润及增速、毛利率、ROE、经营性现金流、资产负债率、管理层讨论与分析中的关键表述、风险提示等。Prompt的设计有几个关键点要求模型输出JSON格式方便后续程序化处理对于每个提取的字段要求模型标注原文出处页码或段落方便人工复核对于不确定的字段要求模型输出null而不是猜测加入few-shot示例展示期望的输出格式实际跑下来提取准确率大概在85%-90%左右主要错误集中在表格跨页、单位不一致、非经常性损益的区分上。所以我会加一层校验逻辑对于关键财务字段用规则引擎从XBRL数据中提取作为交叉验证两者不一致时触发人工复核。注意LLM提取财务数据时最大的坑是单位问题。有的公司用万元有的用亿元有的用元。如果不做统一后续计算会出大问题。我的做法是在prompt中明确要求模型统一转换为元并在输出中标注原始单位。3.2 因子生成Agent的工作机制因子生成Agent是我觉得最有意思的部分。传统因子挖掘依赖研究员的直觉和经验而这个Agent可以系统化地探索因子空间。它的工作流程大致是首先从RAG知识库中检索与当前市场环境相关的研报和论文提取其中的因子逻辑然后结合历史数据将因子逻辑转化为可计算的表达式最后通过回测验证因子有效性。举个例子。假设RAG检索到一篇关于供应链集中度与股价表现的研报核心逻辑是当一家公司的前五大供应商集中度下降时说明供应链风险分散股价可能有超额收益。因子生成Agent会把这段逻辑转化为计算供应商集中度变化率做横截面排序构建多空组合。这个转化过程需要LLM具备一定的金融工程知识。我会在prompt中提供因子表达式的语法规范让模型按照规范输出。比如# 因子表达式示例供应商集中度变化 factor ( supplier_concentration_ratio(t) - supplier_concentration_ratio(t-4) ) / supplier_concentration_ratio(t-4) # 横截面标准化 factor_rank cross_sectional_rank(factor) # 多空组合 long_portfolio top_quantile(factor_rank, 0.2) short_portfolio bottom_quantile(factor_rank, 0.2)因子生成Agent会批量产出这类候选因子然后交给回测Agent验证。我设置的门槛是IC均值大于0.03IC_IR大于0.5多空组合年化收益大于8%换手率低于200%。满足这些条件的因子才会进入下一步。3.3 RAG知识库的构建与优化RAG知识库的质量直接决定了整个系统的上限。我在构建知识库时主要收录以下几类内容券商研报行业深度、公司深度、策略报告学术论文金融、经济、计算机领域上市公司公告年报、季报、重大事项财经新闻主流财经媒体内部研究笔记团队积累的因子逻辑和回测结果文档入库前需要做预处理PDF解析、文本清洗、分块chunking、embedding。分块策略很关键——块太大检索精度下降块太小上下文信息丢失。我的经验是对于研报类文档按段落分块每块控制在300-500字相邻块之间保留20%的重叠。Embedding模型的选择上我测试过几个方案。通用模型在金融文本上的检索效果一般主要问题是金融术语的语义空间和通用语料差异较大。后来我用金融领域的语料对embedding模型做了微调检索准确率提升了大概15个百分点。检索策略上我采用的是混合检索向量检索 关键词检索BM25然后做重排序。纯向量检索的问题是对于精确的财务数据查询比如某公司2023年营收向量检索可能返回语义相似但数据不对的文档。加入关键词检索可以弥补这个缺陷。实操心得RAG知识库需要定期更新和清理。过期的研报、被证伪的逻辑、失效的因子都要及时从知识库中移除或标记。否则LLM会基于过时信息做决策这在快速变化的市场里是致命的。3.4 回测Agent的工程实现回测Agent需要与回测引擎紧密集成。我用的回测引擎是自己搭建的核心考虑是速度和灵活性。速度方面用向量化计算替代循环用内存数据库替代磁盘IO灵活性方面支持自定义因子表达式、自定义调仓规则、自定义风控逻辑。回测Agent的工作流程是接收因子生成Agent输出的因子表达式在历史数据上计算因子值构建组合计算收益和风险指标输出回测报告。整个过程需要自动化不需要人工干预。回测中几个容易踩坑的地方前视偏差这是最隐蔽也最致命的错误。比如用当天的收盘价计算因子然后用当天的收盘价执行交易这就引入了前视偏差。正确的做法是用T日的收盘价计算因子用T1日的开盘价或VWAP执行交易。幸存者偏差回测时只用了当前还在上市的股票忽略了已经退市的股票。这会导致回测收益虚高。我的做法是使用包含退市股票的全样本数据。交易成本很多回测忽略交易成本导致换手率高的策略看起来很美实盘一跑就亏。我会在回测中扣除双边千分之三的交易成本对于高频策略还会加上冲击成本模型。过拟合这是量化策略的通病。因子在样本内表现很好样本外一塌糊涂。我的做法是严格划分样本内和样本外样本外数据在策略最终确定前绝对不碰。同时用多市场、多时间段做交叉验证。3.5 风险评估Agent的动态调整逻辑风险评估Agent的核心能力是识别市场状态切换并动态调整风控参数。传统风控用固定的波动率阈值但市场在不同状态下牛市、熊市、震荡市的波动率特征完全不同。我用的是基于隐马尔可夫模型HMM的市场状态识别方法。HMM可以把市场划分为几个隐含状态每个状态对应不同的收益和波动率分布。当模型判断市场从低波动状态切换到高波动状态时风险评估Agent会自动降低仓位上限、收紧止损线。具体参数上我设置了三个风险等级风险等级触发条件仓位上限单票止损组合止损低风险波动率15%95%-8%-5%中风险15%≤波动率25%70%-6%-8%高风险波动率≥25%40%-4%-12%这些参数不是拍脑袋定的而是通过历史回测优化出来的。优化目标是最大化夏普比率约束条件是最大回撤不超过15%。4. 完整实操流程从零搭建一套AI量化投研系统4.1 环境准备与依赖安装先列一下我用的技术栈和版本方便你复现Python 3.10向量数据库Milvus 2.3 或 Qdrant 1.7LLM推理vLLM 0.4本地部署或主流APIEmbedding模型BGE-M3 或金融领域微调版本回测引擎自研基于pandas numpy numbaAgent通信基于Redis的轻量级消息队列数据存储PostgreSQL结构化 MinIO非结构化安装核心依赖pip install vllm qdrant-client sentence-transformers pip install pandas numpy numba redis psycopg2-binary pip install pypdf pdfplumber beautifulsoup4如果你的机器有GPU建议至少24GB显存这样可以本地部署13B级别的模型。如果没有GPU可以用API方案但要注意数据隐私和调用成本。4.2 知识库构建的完整步骤第一步是文档采集。我写了一个爬虫框架支持从多个数据源采集研报和公告。采集频率是每天一次增量更新。第二步是文档解析。PDF解析用pdfplumber比PyPDF2的表格提取效果好很多。对于扫描版PDF需要用OCR我用的PaddleOCR中文识别准确率不错。第三步是文本分块。我写了一个基于语义的分块器不是简单地按字数切分而是根据段落和标题结构来分块。这样可以保证每个块有完整的语义单元。def semantic_chunk(text, max_length500, overlap100): paragraphs text.split(\n\n) chunks [] current_chunk for para in paragraphs: if len(current_chunk) len(para) max_length: current_chunk para \n\n else: if current_chunk: chunks.append(current_chunk.strip()) current_chunk para \n\n if current_chunk: chunks.append(current_chunk.strip()) return chunks第四步是embedding和入库。用BGE-M3模型生成向量维度是1024。存入Qdrant时同时存储原文、元数据来源、日期、作者、类型和向量。第五步是索引优化。Qdrant支持HNSW索引我设置的参数是m16, ef_construct200。这个参数组合在检索速度和准确率之间取得了不错的平衡。4.3 Agent系统的搭建与调试Agent系统的核心是消息传递机制。我用Redis的Pub/Sub来实现Agent之间的异步通信。每个Agent订阅自己关心的消息频道处理完后把结果发布到下游频道。import redis import json class BaseAgent: def __init__(self, name, redis_client): self.name name self.redis redis_client self.pubsub self.redis.pubsub() def subscribe(self, channel): self.pubsub.subscribe(channel) def publish(self, channel, message): self.redis.publish(channel, json.dumps(message)) def run(self): for message in self.pubsub.listen(): if message[type] message: self.handle(json.loads(message[data])) def handle(self, message): raise NotImplementedError调试Agent系统时最大的挑战是可观测性。多个Agent异步运行出了问题很难定位是哪个环节的错。我的做法是给每个消息加上trace_id所有Agent的日志都带上trace_id这样可以用ELK或类似工具做全链路追踪。4.4 因子生成到回测的完整链路假设我们要生成一个基于分析师预期上调的因子。完整链路是这样的信息理解Agent从研报中提取分析师预期数据输出结构化JSON因子生成Agent根据预期上调幅度和上调家数构建因子表达式回测Agent在历史数据上验证因子有效性如果因子有效进入因子库如果无效反馈给因子生成Agent调整逻辑这个链路我跑过很多次实测下来从信息提取到因子验证完成整个流程大概需要15-30分钟取决于文档数量和回测复杂度。相比人工流程通常需要几天效率提升非常明显。4.5 实盘部署的注意事项回测通过的策略在实盘部署前还需要做几件事模拟盘验证至少跑一个月的模拟盘观察策略在真实市场环境下的表现。模拟盘和回测的差异主要来自滑点和流动性如果差异过大说明回测的成本假设过于乐观。小资金实盘模拟盘通过后用少量资金实盘运行。这个阶段主要观察执行层面的问题比如订单成交率、撤单率、系统稳定性。逐步加仓小资金实盘稳定运行后逐步增加资金规模。每次加仓后观察一段时间确认策略容量足够。注意实盘部署时一定要有熔断机制。当策略出现异常亏损比如单日亏损超过3%系统自动停止交易并报警。这个机制在极端行情下能救命。5. 常见问题与排查技巧实录5.1 LLM输出不稳定的排查思路LLM输出不稳定是这套系统最常见的问题。同样的输入两次调用可能得到不同的输出。排查思路如下首先检查temperature参数。如果temperature设置过高比如0.8以上输出随机性会很大。对于信息提取类任务建议设置temperature0或0.1。对于创意生成类任务比如因子逻辑生成可以适当调高到0.3-0.5。其次检查prompt的明确性。如果prompt存在歧义LLM的输出就会不稳定。我的经验是prompt要尽可能具体明确输出格式、字段定义、边界条件。最后检查模型版本。不同版本的模型行为可能有差异建议固定使用一个版本并在prompt中记录版本信息。5.2 RAG检索质量差的优化方法RAG检索质量差通常有几个原因分块不合理块太大导致检索精度下降块太小导致上下文丢失。解决方法是调整分块策略对于研报类文档按段落分块每块300-500字。Embedding模型不匹配通用embedding模型在金融领域效果差。解决方法是用金融语料微调embedding模型或者使用专门针对金融领域训练的模型。检索策略单一纯向量检索对于精确查询效果差。解决方法是混合检索向量检索关键词检索然后重排序。知识库噪声知识库中包含大量无关或低质量文档。解决方法是定期清理知识库移除过期和低质量内容。5.3 Agent协作中的死锁与超时处理多Agent系统容易出现死锁——Agent A等Agent B的输出Agent B等Agent A的输出双方都卡住。解决方法是设置超时机制每个Agent处理消息时设置最大等待时间超时后抛出异常并记录日志。另一个问题是消息丢失。Redis的Pub/Sub不保证消息可靠投递如果Agent在处理消息时崩溃消息就丢了。解决方法是用Redis Stream替代Pub/SubStream支持消息持久化和消费确认。5.4 回测结果与实盘差异大的归因回测和实盘差异大通常有以下几个原因差异来源回测假设实盘现实解决方法交易成本固定费率冲击成本滑点加入冲击成本模型成交假设全部成交部分成交或未成交加入成交量约束数据延迟无延迟行情延迟加入延迟模拟市场影响无影响大单影响价格限制单笔订单规模我的做法是在回测中就加入这些现实约束虽然会降低回测收益但能让回测结果更接近实盘。5.5 系统性能瓶颈的定位与优化随着知识库增大和Agent数量增加系统性能可能成为瓶颈。常见的性能问题及优化方法LLM推理慢用vLLM做批处理推理或者用更小的模型处理简单任务。向量检索慢优化索引参数或者用GPU加速检索。数据库IO慢加缓存层热点数据放Redis。Agent通信延迟用消息队列替代HTTP调用减少同步等待。6. 一些踩坑之后的个人体会这套系统我从去年开始搭建中间踩了不少坑也走了很多弯路。最大的体会是AI不是万能的它擅长的是处理非结构化信息和生成候选方案但最终的决策和风控还是需要人的判断。另一个体会是数据质量比模型能力更重要。我见过太多团队花大量精力调模型但数据清洗和预处理做得很粗糙结果模型效果怎么都上不去。实际上把数据质量做好用中等规模的模型就能达到不错的效果。还有一点这套系统的维护成本不低。LLM在更新、知识库在增长、市场在变化系统需要持续迭代。如果只是搭起来跑一次那价值有限。真正有价值的是把它融入日常投研流程持续产生和验证因子想法。最后分享一个实用技巧在prompt中要求LLM输出置信度分数。对于低置信度的输出系统自动触发人工复核。这样可以大幅降低错误信息的传播概率同时把人工精力集中在真正需要判断的地方。