做量化的朋友应该都有同感LLM这波热度和早几年深度学习进入量化不一样。前几年大家关心的是预测准不准现在更实际的问题是LLM到底能在交易链路的哪个环节真正落地。我自己折腾了好几个月研究笔记的核心始终绕不开一句话——从交易什么到如何执行。前者是信号生成层后者是执行策略层而LLM恰好可能是把这两层重新串起来的那个变量。这篇笔记就是我近期实验和思考的整理版适合正在琢磨LLM辅助算法交易怎么落地的人参考无论你是有量化基础的程序员还是刚接触大模型的交易员都能从中找到可执行的思路。1. 从交易什么到如何执行先看清LLM入场的切入点1.1 传统框架里这两层是怎么拆的经典的算法交易框架里alpha研究和执行研究是两拨人干的活。alpha团队负责解决交易什么——什么标的值得买、什么时机值得进、仓位给多重他们产出的是信号、评分、目标价。执行团队负责解决如何执行——信号已经到手了怎么在最小滑点、最小市场冲击的前提下把订单发出去他们考虑的是拆单、择时、限价偏移、流动性判断。这两层之间用什么样接口衔接通常是一个信号文件或者数据库alpha端产生建议做多XXX权重2%执行端拿到这个指令再去算VWAP、TWAP、IS算法参数。传统方法里这个接口是很薄的——信号本身不含推理过程执行端也不关心alpha为什么这么判断。这种拆法在历史上是合理的因为两边的知识结构完全不同。alpha端需要的是信息处理能力财报、新闻、行业数据、量价图形而执行端需要的是市场微观结构理解订单簿、冲击模型、盘口博弈。一个人很难同时做好两件事。1.2 LLM真正改变的是中间链路LLM出现以后这个拆法的前提被动摇了。原因在于大语言模型天然同时具备两类能力理解复杂信息、生成结构化指令。它读财报、读新闻、理解行业逻辑拍了板然后还能直接输出建议分批买入、每笔间隔多少分钟、用限价单这类可执行指令。你可以把传统链路理解成传纸条选菜的人写好单子递给厨师厨师照着做两个人基本不沟通。LLM出现后理论上选菜和掌勺可以是同一个大脑——但它不是天生就会掌勺中间那一整套怎么把想法变成安全、合规、低冲击的订单的环节才是真正的难点。这里有一个很关键的点LLM带来的核心价值不是预测更准而是中间层的表达能力。以前文本数据进来只能被压缩成一个情绪分数现在它可以保留完整语义、给出推理链条、输出带依据的判断。这就让交易什么和如何执行之间有了被重新设计的空间。1.3 哪些场景适合用LLM做算法交易我自己的判断是LLM不适合高频链路。盘中毫秒级决策、逐笔TICK级别的微观博弈那是传统模型和专用系统的地盘LLM 2到5秒的推理延迟根本跟不上。但它非常适合中低频和中短周期的场景。适合的方向大概有三类。第一类是事件驱动财报暴雷、突发公告、行业政策变动这种信息密度高、文本为主、时效性在分钟级以上的场景LLM的理解能力比传统NLP强得多。第二类是复杂信号融合把研报观点、产业链逻辑、市场情绪和量价数据放在一起做综合判断这是LLM的看家本领。第三类是执行策略的决策支持已经决定要买某个标的但怎么买、拆几单、什么节奏、什么价格类型LLM可以基于市场状态给出一个框架性的建议再由执行引擎细化。说到底LLM入场的切入点不是取代信号或执行任何一端而是把两端的决策缝隙填上。后面两章我就分别从交易什么和如何执行展开讲我具体怎么做的。2. 交易什么用LLM生成可用的标的信号2.1 喂给LLM的数据管线怎么搭很多人上来就把原始新闻全文丢给LLM让它分析结果上下文窗口被无关信息占满输出质量稀烂。我试过几个版本之后现在的数据管线大致是四步。第一步是原始文本清洗。去广告、去重复、去无意义符号尤其是从财经网站抓下来的内容经常夹带大量推荐位和推广文字这些会严重干扰判断。第二步是事件类型分类财报发布、业绩预告、高管变动、股东增减持、行业政策、研报评级先把事件定性再决定用哪套prompt模板去处理。第三步是时间对齐这个特别容易忽略——公告发布时间和可交易时间不是一回事必须把事件时间对齐到最近的可交易时点否则回测里全是未来函数。第四步是上下文组装把相关新闻、历史事件、当前行情快照组合成一个研究单元而不是零散地一条条喂。我通常会把最近的3到5条相关新闻按相关性和时间加权加上一段简单的价格走势摘要比如20日均线位置、近期波动率区间组装进一个上下文。这个做法的核心逻辑是LLM需要足够的背景才能做出有依据的判断但背景太多又会稀释重点。组装的时候注意控制总长度我一般把token控制在1500到2500之间既给足信息又不至于让模型看不过来。2.2 Prompt设计三层结构角色、任务、输出约束跟LLM打交道的经验告诉我prompt设计直接决定信号质量而一个好的交易分析prompt至少要分三层。第一层是系统角色。不是简单说你是分析师而是明确给出一段决策上下文比如你是一名有10年经验的股票基本面分析师擅长结合财务数据、行业逻辑和市场情绪进行多空判断。角色设定的本质是缩小模型的输出空间让它生成的内容收敛到符合这个身份的话语体系里。第二层是任务路径。要把复杂的分析任务拆成有顺序的子任务比如第一步判断事件属性第二步分析影响方向第三步评估影响强度第四步给出综合评分。为什么要拆因为如果你只问一句这新闻是利好还是利空模型会走捷径直接根据文本里带的情绪词下结论而不是做真正的推理。拆步子能强制它走完整的推理链路。第三层是输出约束。明确告诉它输出什么样的结构、字段、取值范围。这一层直接影响后面程序能不能消费它的输出。我自己常用的一句是只输出JSON不要输出任何解释性文字但这句话还不够更可靠的做法是用JSON Schema约束下一小节专门讲。这里有一个我自己反复验证过的细节在任务路径里加入如果信息不足请明确说不知道比单纯让它硬猜要可靠得多。LLM有很强的被迫回答倾向你给它一个必须填空的框架它倾向于填一个看起来合理的答案。把无法判断变成合法输出可以显著减少幻觉类错误信号。2.3 结构化输出让模型的判断变成机器可读的JSON信号层要对接下游程序输出必须是严格结构化数据。我早期踩过一个坑用纯文本让模型输出JSON它经常在JSON前后附上解释性段落或者markdown代码块标记解析器直接被搞挂。后来我改用Function Calling机制模型会被强制按我定义的函数参数结构输出这个问题基本绝迹。一个典型的多因子评分的Schema大概长这样{ signal: { direction: long | short | neutral, confidence: 0.0, factor_scores: { fundamental: 0, sentiment: 0, liquidity: 0 }, reasoning: , evidence: [] } }注意confidence字段是浮点数factor_scores是0到100的分数evidence是支撑结论的原文片段列表。这里有一个设计考量与其让模型直接输出买入/卖出这种粗粒度指令不如让它输出多因子分数和置信度再用规则做一次映射。原因很简单——LLM的数值判断是概率性的直接输出二元方向很容易来回漂移但多因子分数在合成之后会稳定得多而且便于做仓位控制。映射规则我放在prompt之外用代码实现综合分大于70且置信度大于0.6映射为做多信号小于30且置信度大于0.6映射为做空信号其他情况一律判为中性。这样LLM只负责它擅长的理解和打分规则层负责它不擅长的确定性和风控边界。2.4 一个标的筛选的完整示例拿一个实际场景演示一下。假设我有一则新闻内容是某公司公告三季度营收同比增长25%净利润同比增长18%同时宣布回购计划。数据管线清洗后我把它和公司近三个月公告列表、当前市盈率分位数、近20日收益率标准差组装成上下文然后调用上面的prompt结构。模型输出的JSON大概是这样的{ signal: { direction: long, confidence: 0.72, factor_scores: { fundamental: 82, sentiment: 68, liquidity: 55 }, reasoning: 营收和利润双增基本面因子得分较高回购计划对市场情绪有提振但当前流动性一般注意大单冲击。, evidence: [三季度营收同比增长25%, 净利润同比增长18%, 宣布回购计划] } }这个结果进入信号库之后score 82的fundamental和0.72的置信度满足做多触发条件于是生成一个带权重的做多信号。但这个信号还没有到执行层——它只是完成了交易什么这一步。非常重要的认知是这个信号必须带有时间戳、事件ID和置信度后续执行层要根据这些元数据来决定何时不执行——比如信号已经过期24小时以上、或者置信度跌到阈值以下就应该自动作废。3. 如何执行信号落地到订单的链路设计3.1 为什么执行层不能直接交给LLM这是我踩了最多坑的地方也是我认为最需要讲清楚的原则。LLM可以参与执行决策但绝对不能直接下单。原因有三个。第一是确定性执行层每个订单都必须有明确的方向、数量、价格类型、有效时间任何一个模糊字段都可能造成事故而LLM的输出天生是概率性的同样的输入可能给出不同的参数。第二是延迟执行决策往往需要在几十到几百毫秒内完成LLM的推理时间以秒计根本来不及。第三是合规和风控订单必须经过完整的权限校验、仓位检查、异常检测这些规则是硬性的、不能有概率的。打个比方LLM更适合当调度员——它根据天气、路况、乘客需求判断现在适合打车、选择快车还是拼车但具体怎么踩油门、走哪条道、什么速度过弯仍然是驾驶员执行引擎的事。你要是让调度员直接开车大概率出事故。3.2 中间翻译层把LLM的想法变成订单指令所以我在信号层和执行层之间加了一个策略翻译层Bridge Layer它的职责是接收LLM的结构化输出校验、翻译成执行引擎能读懂的指令。完整的链路是这样信号层生成信号后会附带最近的相关事件摘要和模型分析JSON一起送进翻译层。翻译层首先做Schema校验字段类型对不对、数值在不在合理范围内、方向字段是不是枚举值之一。然后做逻辑校验如果模型说做多但factor_scores里fundamental只有40分这就是内部矛盾需要打回重算或者标记降级。接着做仓位校验把信号量与当前持仓、可用资金、风控限额对比超限就拒绝或者缩减。校验通过之后翻译层会生成一组成层的执行指令模板。举一个具体的例子LLM输出建议逐步建仓分三批使用限价单翻译层会把它翻译成{ action: place_child_orders, orders: [ {side: buy, quantity: 0, price_type: limit, offset_bps: -10, validity: day}, {side: buy, quantity: 0, price_type: limit, offset_bps: -5, validity: day}, {side: buy, quantity: 0, price_type: limit, offset_bps: 0, validity: day} ] }注意这里订单的quantity是0这是一个故意的设计——实际数量由执行引擎根据账户资金、流动性分布、冲击成本模型来计算LLM根本不需要管具体数字。翻译层的输出是模板参数占位具体数值由执行引擎填充。3.3 执行引擎里的决策分工真正下单的执行引擎负责的是LLM不擅长的数学计算和微观层面决策。它做的事情包括根据当前盘口的深度分布计算每笔订单的具体数量避免单笔订单超过市场平均深度的一定比例根据历史波动率计算限价偏移offset避免限价挂得太远导致不成交或成交价偏离预期根据市场状态正常、高波动、停牌前动态调整下单节奏和撤单策略。那么LLM在执行层到底参与了什么我自己目前的做法是LLM只负责三个宏观决策。第一是拆单策略的选择是一次性下完、还是均分拆单、还是按流动性加权拆单第二是价格类型的选择市价单、限价单、还是冰山单这取决于当前市场流动性和对冲击的容忍度第三是异常暂停的判断如果盘口出现极端情况比如瞬间剧烈波动、成交量异常放大LLM可以基于上下文判断是暂时观望还是继续执行。这个分工的理论基础其实可以拿Attention机制里的QKV来理解——query就是交易目标key是当前市场状态的特征value是可行的动作选项。传统执行模型只有固定映射LLM则可以在推理过程中动态匹配目标和状态给出更灵活的决策建议。这确实是把交易什么和如何执行打通的那一块。3.4 一个事件驱动执行的完整时序我把一个完整的执行时序写出来大家能更直观地看到LLM在哪一层发挥作用。假设某只股票盘中突发公告内容是高管增持。信号层在500毫秒内抓取到这条公告完成清洗和组装调用LLM分析得到短期情绪利好、建议关注流动性风险的判断综合评分68分、置信度0.65。这个分数没有触发做多阈值所以进入观察列表不产生执行动作——这是最普通也最重要的路径绝大多数信号不应该走到执行。但如果是另一条公告——业绩大幅超预期评分达到85、置信度0.78信号层生成做多信号送到翻译层。翻译层检查持仓发现当前该标的仓位已经是上限的80%可用加仓空间只有20%于是自动将信号权重缩减为原计划的20%。接着翻译层把缩减后的目标数量填入订单模板交给执行引擎。执行引擎拿到分3笔、限价单、每笔间隔15分钟的模板后开始计算当前买一档深度只有5万股我的第一笔订单不能超过这个深度的50%也就是2.5万股当前波动率年化35%限价偏移设置在买一价下移5个基点避免冲击同时保证成交概率。第一笔发出后执行引擎持续监控成交情况如果盘口恶化会主动撤单并延长间隔。整个过程中LLM只在开始时做了一次判断中间所有的微操都是执行引擎的活。4. 工程落地选型、回测与成本控制4.1 模型选型API调用还是本地部署这条话题每次聊都很热我直接给结论研究阶段无脑用API生产阶段看频率和敏感度做混合。API方案的好处是模型能力强、上下文窗口大、更新迭代自己跟着用就行不需要操心部署。缺点是每次调用都有网络延迟成本按token累积同时数据隐私是个问题——虽然大部分商用API承诺不保留数据但真正涉及自研策略的文本很多人心里还是犯嘀咕。我的做法是研究阶段用API验证思路生产阶段把核心数据管线留在本地。本地部署开源权重模型的优势是延迟可控、数据不出内网、长期成本能压下来。劣势也很明显需要GPU资源部署维护工作量不小而且开源模型的综合推理能力目前和头部商用模型还有差距尤其是在复杂金融语境的理解上。一个比较务实的折中是混合架构高频、敏感的执行环节用本地小模型做格式化和基础判断低频、高难度的分析环节调用API大模型。4.2 结构化输出和推理质量的工程技巧为了保证LLM输出的稳定性我有几个工程上的小技巧。第一个是尽量用Function Calling而不是自由文本输出前面说过这是稳定性的根本保障。第二个是给模型加上思考要求我通常在任务路径里加入一句先分析再输出JSON这能让模型在输出结构化结果之前先走一遍推理虽然多花一点token但信号质量明显提升。第三个技巧是缓存复用——相同或高度相似的新闻文本在短时间窗口内可以直接复用之前的分析结果既省成本又降低重复调用带来的延迟。第四个是异步处理信号采集和LLM分析不要阻塞主循环用消息队列做解耦让执行引擎永远不等待模型推理。还有一个参数细节值得单独说temperature。我见过很多人直接用默认值这在交易场景里是大忌。我的设置是prompt层的分析和打分用0.1到0.2执行建议层用0.2到0.3。这个区间的输出既有一定的多样性避免每次结果完全雷同又不会因为温度太高而出现离谱的幻觉。top_p我习惯放在0.85附近两者配合使用信噪比会好很多。4.3 回测时容易踩的隐藏坑LLM信号做回测比传统因子回测多出几个很隐蔽的坑。第一是未来函数。LLM分析基于的是事件时间还是你拉取数据的时间这中间哪怕只有几百毫秒的偏差在回测里都可能被放大。我早期回测一个事件驱动策略年化收益高得离谱最后定位到的问题就是数据对齐用了回调时间而不是公告时间导致信号里混入了未来信息。修复方式是所有文本数据在入库时强制打上事件发生时间戳回测时只能使用那时戳之前的信息。第二是不可复现性。LLM的输出有随机性即使固定了temperature不同批次的结果也会有细微差异。这意味着同一个回测跑两遍结果不完全一样。正规做法是每次回测保存当时的模型配置、参数、输入数据版本并且多次运行取统计分布而不是单次净值曲线。我在实验里通常每个策略跑5遍取中位数和标准差来评估。第三是token成本没有计入回测。模型调用是要花钱的一天几百个信号、每个信号几千token月度成本可能超过预期。回测的盈亏必须扣除token费用否则结果虚高。这个坑我踩过后面专门做了成本复盘。4.4 延迟和token成本怎么算给个参考量级。我用一个中等复杂度的prompt做单次信号分析输入约1500 token输出约300 token在商用API上成本大约人民币几分钱单次端到端延迟在2到5秒之间。如果信号频率是每小时20次一天交易时段4小时就是80次调用成本几块钱延迟方面完全够中低频策略使用。但你要是想把它用在秒级或者毫秒级的策略上目前的成本模型和延迟都不支持。延迟优化我能给出的最有效手段是结果缓存和预计算。比如很多事件是定期的——财报、经济数据发布、月度销售数据你可以提前把prompt模板和上下文组装预置好事件一触发立即调用能省掉组装时间。同时给模型输出做流式解析不用等全部token生成完才开始校验这对有一定延迟压力的场景很有帮助。5. 踩坑记录典型问题与排查速查表5.1 高频问题的排查速查表实践几个月我把高频问题整理成了一张速查表团队内部也在用。这里直接分享出来症状可能原因排查方向与解法输出JSON不合法或字段缺失Schema过于复杂或模型版本不支持Function Calling简化Schema字段控制在8个以内升级到支持结构化输出的模型版本相同输入得到不同结论temperature过高或Prompt缺少固定化的推理路径将temperature降到0.1~0.2增加few-shot示例固定格式信号频繁在阈值边缘跳动打分规则对文本情绪过于敏感增加滑动窗口平均提高置信度阈值模型引用不存在的公告内容幻觉缺少事实核查要求输出evidence字段并代码校验该片段是否出现在原始文本中回测收益异常高未来函数或数据对齐错误检查时间戳是事件时间还是获取时间重新梳理数据管线实盘滑点远大于回测回测未模拟延迟和流动性变化在回测中加入成交延时和按盘口深度滑点模拟调用成本超预算缓存策略缺失或Prompt过长增加相似文本聚类缓存裁剪上下文到必要长度这张表是在真实迭代中沉淀出来的每一条都对应过我实际的排障经历。遇到问题先对着表定位能省下大量试探时间。5.2 我印象最深的三个坑第一个坑是关于方向的。某次测试中模型对一条净利润同比下滑但环比改善的公告给出了做多判断我当时以为模型逻辑错了后来看推理字段才发现它认为环比改善已经出现、拐点可能临近。这个推理本身不算错但它默认放大了环比改善的权重而我的策略逻辑里同比优先。最终解决方式是给prompt加了一行明确约束判断方向时以文本中的绝对值变化为主同比和环比冲突时优先采信同比。若无法判断请输出neutral。如果没有这行模型给出的信号经常和我预设的因子框架打架。第二个坑是模型的固有乐观倾向。我统计过一段时间内LLM输出方向分布发现多头信号占比明显高于空头信号这可能是训练语料里财经媒体天然偏多头叙事导致的。后来我引入了先验修正——如果一段时间内模型输出的多空比超过某个阈值自动下调置信度效果立竿见影策略净暴露显著下降。第三个坑是关于执行层的。早期我把拆单建议直接交给LLM生成具体参数结果模型在一次高波动行情里建议快速市价单一次下完差点造成不必要的冲击成本。后来我意识到具体参数必须由执行引擎根据数学模型计算LLM只能给方向和框架性建议。设计好边界之后这个问题再也没有出现过。5.3 从研究到小仓位实盘的路线建议如果看这篇文章的你想自己尝试我给一条稳妥的路线参考。第一步离线信号验证把历史事件数据跑一遍对比LLM信号和随机选择的表现找出稳定优势的细分场景。第二步模拟盘验证至少跑2到4周用真实行情但不真下单重点观察信号延迟、执行滑点和系统稳定性。第三步小仓位实盘用总资金1%到2%跑起来设定硬性的日亏损上限和最大回撤阈值。第四步持续监控每日统计模型输出的schema错误率、超时率、信号拒绝率任何一项指标异常都要先停再查。在这整个过程中我特别建议保留一个人工干预入口。无论系统自动化到什么程度最终都应该有一个可以一键暂停全部信号的开关。LLM交易系统最大的风险不是模型不准而是你在某个环节过度信任了自动化把不该有的风险敞口留在了无人看管的地方。我个人现在走到哪一步了信号层的多因子评分已经在稳定运行执行层的策略翻译链完成了几轮迭代实盘只用了很小的仓位在跑。踩过这些坑之后最大的经验是LLM在交易里的价值从来不是取代哪个环节而是把理解和执行这两件本来割裂的事重新接到一起。让它做人脑擅长的事——理解、推理、建议让代码做代码擅长的事——计算、校验、执行这套分工目前看是走得通的我也会继续沿着这个方向往下做的。