AlphaSchema 解读｜把因子搜索从 LLM 黑箱里捞出来

做量化的朋友这两年应该没少折腾大模型挖因子。流程听起来顺——扔行情数据给 GPT，让它输出候选因子，回测、筛选、再迭代——但实际跑过就知道，有个问题一直杵在那儿：根本不知道 LLM 在往哪个方向搜。

现有的框架基本是把因子构建和搜索方向全交给 LLM 自己定，exploration 是隐式的。今天给出一个动量因子，明天给出一个波动率因子，语义上有什么关联、搜索是在收敛还是发散，很难控制也观测不到。跑得顺不顺，很多时候靠的是模型发挥和运气。

最近 arXiv 上这篇 AlphaSchema，就是冲着这个问题来的。

核心思路是把"我们要找什么样的因子"这个决策，从 LLM 的隐式推理里捞出来，变成一个显式的、可操作的语义空间。论文把每个候选因子定义成一个 schema plan，由五个维度组成：Event、Context、Qualities、Direction、Output。展开说就是：在什么行情事件下、在什么市场环境里、用哪些特征、朝哪个方向、输出什么样的信号。

这个设计的核心，是把 exploration（搜什么样的因子）和 implementation（把因子写成代码）拆开了。LLM 的角色被收窄——它只负责把 schema plan 翻译成可执行的因子代码。搜索方向的选择，由一个基于历史 reward 训练出来的 surrogate model 来引导，同时兼顾全局探索、局部突变和基于模型的 exploitation。

实验跑的是 A 股数据，结果上能找到预测能力和组合表现都不错的因子池。但比指标更有意思的是一个分析结论：同一个 schema plan，换不同的 LLM 去实现，最终因子的预测质量差别不大。论文的原话是"alpha mining quality is largely robust to the choice of LLM"，这其实在说一件事——语义空间定义清楚之后，具体用哪个模型来写代码反而没那么重要。

这个结论如果站得住，整个 LLM 挖因子的重心就要从"选模型、调 prompt"往"设计语义搜索策略"上移了。LLM 在这里的角色更像一个编译器，真正的智力活在于怎么定义 Event 和 Context 的粒度、怎么设计 schema 空间的结构。

当然，这篇的工作目前只覆盖了中国股票市场，框架的泛化能力需要更多验证。而且 schema 空间的初始设计本身就极度依赖领域知识——哪些 Event 和 Context 值得纳入，这本身就是一个很难自动化的决策。

但方向是好的。把因子搜索从隐式推理变成显式搜索，把 LLM 从决策者降级成翻译官，这在工程上意味着更可控、更可迭代。对真正在生产环境里跑因子的团队来说，这个思路比让模型自由发挥要踏实得多。