艾弥儿符号回归（symbolic regression）在很长一段时间里都被归为机器学习里的"慢速赛道"：遗传规划跑上几小时是常态，稀疏回归又受制于手工候选库，强化学习版本则常常调不动收敛。直到NeurIPS上这篇基于Transformer的端到端符号回归方法出来，这个方向才出现了一个真正不一样的技术路线——在大规模合成表达式数据上训练模型，把"给定采样点、输出数学表达式"当成一个序列生成任务，推理时一次前向传播直接给出表达式，不需要搜索。这篇文章不打算复述论文摘要，我想换一个实际操作者的视角，把这套方法的关键设计拆开来讲：数据怎么生成、模型怎么搭、推理时常数怎么处理、后校验怎么做，以及复现时最容易踩到的那些坑。
1. 符号回归的本质难题：搜索空间太大，传统方法太慢
1.1 遗传规划、稀疏回归、强化学习各自卡在哪里
符号回归的任务目标一句话就能说清：给定一组输入输出样本{(x_i, y_i)}，找到一个数学表达式f，使得y约等于f(x)。难就难在表达式的组合空间是离散且无限的，一个简单的函数可以用无数种等价方式表示，而数据本身只能提供有限约束。
传统的解决思路本质上都绕不开"搜索"这个词。遗传规划把表达式当作个体，通过选择、交叉、变异在种群中演化，问题在于采样效率太低。我拿gplearn跑过一个物理方程反演任务，演化了几个小时，最后得到一个长得像咒语的长表达式，里三层外三层的嵌套结构，既没有可解释性，数值稳定性也差。种群很容易陷入局部最优，而且会发生明显的"表达式膨胀"。
稀疏回归（SINDy这类）把方向拧到另一边：不搜结构，只在一个预设函数库里做稀疏组合。好处是快、稳定，可它的上限完全取决于你人工给的候选库。目标函数里只要出现一个库里没有的函数族，结果就必然是错的。这个"库是你给的"的设定，在真实科学发现场景里往往是最先被打破的假设。
基于强化学习的深度方法（DSO）试图用策略网络直接生成表达式，用环境的奖励信号来优化。思路很新颖，但训练体验非常糟糕：奖励稀疏、方差极大，reward shaping几乎要手工雕琢，换个随机种子结果就可能天差地别。这类方法在实际复现时花费的调参时间远超预期。
这三类方法的共同痛点是：推理阶段都必须回到表达式空间里做搜索。搜索就意味着慢，也意味着结果不稳定。
1.2 端到端思路登场：让模型直接"回忆"表达式
2022年的NeurIPS上有篇文章（Kamienny等人发表的《End-to-end Symbolic Regression with Transformers》）提了一个很大胆的反问：为什么非要搜索？能不能让模型在大规模合成的表达式数据上预先训练，推理时直接输出表达式？
这个思路把符号回归从一个搜索问题变成了一个条件生成问题。给定一组采样点，模型直接预测对应的表达式序列。训练阶段确实需要海量数据，但表达式本身可以用语法随机生成，本质上数据无限；推理阶段只需要一次前向传播，比遗传规划快几个数量级。
"端到端"三个字在这里的含义很具体：从原始数据点到最终表达式，中间不经过人工设计的特征、不需要预定义候选库、也不做迭代搜索。模型学习到的不是"如何搜索更好的表达式"，而是"这类数据形态对应什么样的数学结构"。换句话说，模型见过上亿个表达式之后，看到一组新数据时是在做结构识别而非结构搜索。
1.3 为什么是Transformer而不是CNN/RNN
一个很自然的问题：序列到序列任务以前大量用RNN/LSTM，为什么这个工作选择Transformer？
第一，输入侧的信息形态不适合RNN的逐点处理。采样点集合虽然可以按x排序，但模型真正需要捕捉的是不同位置函数值之间的全局依赖——比如一个函数在某个区间的振荡频率，直接影响整个表达式中三角函数的参数。Transformer的注意力机制天然擅长建模这种全局关系，而RNN对长距离依赖的建模能力始终受限于步数。
第二，训练效率要求很高。这类模型动辄需要在数百万甚至上千万个样本上训练，每个样本的输入序列长度是几百个点，输出表达式可能有几十上百个token。用LSTM在这种数据规模下训练，时间成本高到不现实。Transformer可以高度并行，训练效率远胜递归结构。
第三，Transformer在结构化序列生成任务上的成功先例太多了。代码生成、语义解析、数学问题求解，这些都涉及"从连续编码到离散结构序列"的映射。符号回归的输出恰好就是一个带层级结构的表达式序列，把它看成一种"数学语言"，问题就被纳入了序列生成的成熟范式。当然Transformer并不是没有代价。它对输入顺序敏感，对数值输入不友好，浮点数怎么进词表需要专门设计。这些后面都会展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 端到端符号回归的完整数据流：输入点、输出前缀、全程编码
2.1 输入侧：采样点如何变成有顺序的token序列
端到端模型的第一步，是把目标函数在若干采样点上的取值表示成模型能接受的输入序列。给定目标函数f(x_1,...,x_d)，在定义域内采样N个点，得到N个y值。这里要处理两个问题：点的顺序怎么定，点的位置信息怎么传。
顺序问题比较直观的做法是把x值从小到大排序，把对应的(y_1, y_2, ..., y_N)作为主体输入序列。排序让输入具备了确定性，模型不会因为同一组点以不同顺序输入而产生不同输出。更稳妥的做法是把x_i和y_i打包成一个token对喂给编码器，让模型显式知道每个y值对应的自变量的位置。如果只输入y的序列而完全不传x，模型就必须从位置编码里强行推断采样位置，这实际上是给模型增加了一个不必要的负担。
数值的编码方式同样关键。浮点数没法直接当token用，词表是有限的。通常做法是做一个数值tokenizer，把浮点数量化成词表id。最简单的做法是按区间分桶，但分桶会带来量化误差，而且桶边界处的数值会被不连续地编码，模型很难理解"3.14和3.15几乎相等"这层含义。更好的做法是把浮点数拆成符号、尾数、指数结构化表示，让数值在token空间里也保持某种连续性。这个细节我在第6部分还会重点讲。
不管用哪种方式，编码之前通常都要对y序列做标准化。否则一批函数的取值在1e-6量级，另一批在1e6量级，注意力分数的数值范围会非常不稳定。
2.2 输出侧：把表达式树压平成前缀表示
表达式的天然结构是一棵树：根是运算符，叶是变量或常数。模型不能直接输出树，它输出的是token序列。用什么方式把树序列化，是个有讲究的设计。
目前最常用的是前缀表示法（Polish notation），先输出运算符再输出它的子表达式。比如"2*x + sin(y)"被表示为+ * 2 x sin y。前缀表示最大的好处是：解码器输出的token流一旦满足"操作数数量"的约束，就能无歧义地还原成表达式树，完全不需要处理括号匹配问题。
词表设计上，变量是固定token（x1、x2等），运算符也是固定token（+、-、*、/、sin、cos、exp、log等）。常数则是最棘手的一块：常数的取值是连续的，词表不可能为每个浮点数分配一个token。常见的做法是"常数token池"或者"常数占位符"，具体策略后面单独说。
输出序列的长度不固定，短的只有一个token，长的可能有几十上百个。所以解码器需要有一个特殊的EOS（序列结束）token，让模型告诉推理端"这棵表达式树写完了"。没有EOS的约束，模型会无限生成下去，在资源开销上非常危险。
2.3 模型骨架：编码器负责"看懂"数据，解码器负责"写出"公式
端到端符号回归的模型主体是标准的Transformer encoder-decoder结构，和机器翻译的架构几乎同构。编码器吃进采样点序列，输出每个位置的上下文表示；解码器从BOS（序列开始）token出发，自回归地逐个生成表达式token，每一步都把已生成的token重新喂回解码器，直到产出EOS。
这里有几个设计点值得留意。编码器端的位置编码表达的是"这是第几个采样点"，不代表"采样点对应的x坐标是多少"。所以要保证x坐标信息通过输入token显式传给模型，而不是指望位置编码替你完成。解码器端需要标准的因果掩码，保证在生成第k个token时看不到后面的token。由于前缀表示法天然是一个从左到右的展开过程，因果掩码和树的层级结构是兼容的。
模型规模不需要太大。符号回归任务不要求模型学习海量语义知识，但要求模型能捕捉数值序列的细微差异。我实测下来，编码器和解码器各6~12层、embedding维度256到512的中等规模模型在这个任务上已经表现得相当好。盲目加大模型带来的收益有限，训练成本却会快速上升。原论文的经验也支持这一结论。
3. 训练集才是真正的护城河：表达式生成与预处理
3.1 语法采样：如何控制表达式的"难度分布"
训练数据的生成是整个技术路线成立的前提。核心做法是用一个语法递归构造表达式树：每一步随机决定当前节点是叶子（变量或常数）还是内部节点（某个运算符），内部节点再递归生成子表达式。这看起来简单，里面其实藏着大量讲究。
第一个坑是树的形状分布。如果递归时完全随机选择左右子树，会产生大量病态结构：一边是深度很大的子树，另一边是光秃秃的叶子。这种不对称树在实际科学问题中很少出现，但会被大量生成，导致训练分布偏离真实需求。实践中通常用泊松分布或者截断几何分布来控制子树的节点数，让表达式规模的分布落在我们期望的区间。
第二个坑是常数的取值范围。如果常数从[-1e6, 1e6]里均匀采样，一方面会带来数值稳定性问题，另一方面会让训练集里充满带极端系数的表达式，模型根本学不到"常见函数"的典型尺度。一般把常数限制在一个适中范围，比如[-10,10]或[0.1,10]，同时保留一定比例的无常数表达式，避免模型对常数产生过剩的预期。
第三个坑是运算符比例。sin和cos的比例、乘除的比例、幂函数和对数的比例，都需要刻意控制。某个运算符出现太少，模型几乎学不会生成它。尤其是除法和对数这种容易触发定义域问题的运算符，如果不做过滤，训练集里会攒下大量非法样本（比如log(0)、x/0），模型在推理时也就学会了生成一堆无效表达式。
3.2 化简去重：别让训练集充满0=0、x+x=2x这类废样本
随机生成的表达式有一类很隐蔽的问题：大量表达式在数学上等价或者数值上几乎等价的。比如sin(0)乘任意表达式都等于0，x+1-1在数值上几乎处处等于x。如果训练集里充满这种等价样本，模型学到的是"看到这种数值模式就输出某个特定表达式"的表面映射，而不是"这种数值模式的底层结构是什么"。
解决这个问题需要多层级的化简。第一层用字符串级规则做快速化简：被0乘的子表达式整体替换为0，加0的子表达式去掉，除以1去掉，1次方的幂去掉。第二层再用符号代数库做更复杂的等价判断，但在大数据集上逐样本跑SymPy非常慢。更实用的工程做法是数值去重：随机在一批采样点上比较两个表达式的输出值，如果完全一致，就判定它们近似等价，只保留一个。这个trick在复现时非常值得采纳。
另外要控制"平凡表达式"的比例。如果训练集里一半样本都是x这样的单token表达式，模型会产生严重的长度偏好，推理时倾向于输出短而错误的表达式。一般会给训练样本设一个最小复杂度阈值，或者用重要性采样让不同规模的分布更平缓。
3.3 采样点配置：域的选择、点数的取舍、归一化的门道
有了表达式，还要为每个表达式随机生成采样点，形成模型的输入。
定义域的选择直接决定模型见过的函数形态。如果训练时定义域永远固定在[-1,1]，模型就只见过这个范围内的数据形态，推理时遇到[-10,10]上采样的函数就会失效。更好的做法是在训练时随机化定义域：在[-10,10]、[-5,5]、[0,10]、[-1,1]这些范围中随机选，也可以让每个维度独立抽样。
采样点数N是一个权衡量。N太小，比如只有10个点，包含的信息量不足以区分两个相近函数；N太大，比如1000个点，输入序列过长，训练开销陡增。原论文和社区复现里常用的N在100到200之间，单变量场景下基本够用。多变量场景由于维度增加，输入长度增长很快，需要更谨慎地设计采样方案。
归一化方法也需要讲门道。如果不做归一化，不同函数的值域跨度极大，训练稳定性会很差。但如果把每个样本的y值减去均值除以标准差，模型的全局尺度感知就会被破坏——它可能算出正确的结构，系数却差一个数量级。折中方案是把标准化用的均值和标准差作为额外token拼进输入序列，让模型在需要时能够恢复部分尺度信息。
4. 推理不是简单地把模型跑一遍：束搜索、合法性校验与常数精修
4.1 从token序列到表达式树：前缀解码的约束
训练完成后，推理阶段的第一步是让模型对新的数据点做前向传播，用束搜索生成一组候选表达式token序列。束搜索宽度一般在10到50之间。宽度太小会丢最优解，宽度太大计算量增长明显。符号回归有个得天独厚的优势：我们可以用真实数据来验证候选表达式的拟合程度，所以束搜索的排序标准不完全是模型概率，还要结合长度惩罚，避免模型偏爱输出短表达式。
解码得到的token流不能直接当成最终答案。一个很常见的坑是模型生成的token流不符合前缀表达式的语法。比如+ * x这样的序列，在解析时会缺少操作数。所以在解码完成后必须有一个解析器，把token流解析成表达式树，解析失败的直接丢弃。更高效的做法是在束搜索过程中就维护一个"待填充操作数数量"计数器，序列如果提前结束而计数器没有归零，就立刻剪枝，避免生成无效序列浪费计算。
前缀解码还有一个好处：我们可以从token流的长度直接推断出表达式树的节点数。给定前缀序列，每出现一个二元运算符，就需要新增两个操作数槽位；每出现一个叶子，就消耗一个槽位。这个约束可以在解码时实时检查。
4.2 常数处理：模型的产出通常还不够精确
端到端符号回归最微妙的部分是常数。模型可能正确识别出表达式结构是"常数乘以x"，但生成的常数是3.14，而真实常数是π。如果不做后处理，最终的拟合误差会一直卡在常数精度上。
处理常数主要有三种策略。第一种是常数token池：训练时从固定常数列表中选值，把每个常数实例化成一个token，推理时模型直接从池里选。优点是简单可控，缺点是池子的覆盖度有限，很难覆盖任意精确值。第二种是常数占位符加数值微调：模型输出一个特殊token表示"这里是一个常数"，生成完整表达式骨架后再用数值优化器（如BFGS、L-BFGS）去拟合常数。优点是常数精度可以逼近浮点数极限，缺点是引入了额外优化步骤，而且数值优化可能陷入局部最优。第三种是混合策略：模型既可以选常数token池里的具体值，也可以输出占位符，让后处理优化器决定最终值。
我自己的项目里主要用"占位符加BFGS"，常数token池作为辅助。优化器负责精度，常数池负责把模型引导向常见的常数组，比如π、e、1/2、√2这些物理里频繁出现的值，避免优化器从零开始盲目搜索。
4.3 最终筛选：用真实误差而不是模型置信度来排序
束搜索会生成一堆候选表达式，模型自己会给每个候选一个序列概率。但序列概率高的候选不一定拟合最好。模型可能学会生成"看起来很合理的结构"，但数值上对不上号。
正确的筛选方式是把所有候选表达式逐一在原始采样点上计算预测值，用真实的误差（RMSE或者R²）来排名。这一步虽然多了一次前向计算，但价值在于把模型的生成能力和验证能力解耦。模型负责产出一批结构合理的候选，验证阶段负责挑出真正匹配数据的那一个。
这个后验证步骤还能顺带剔除一类特殊的垃圾候选：token序列合法，但数学上无意义，比如除零、对负数取对数、数值溢出。这些表达式在真实采样点上根本无法计算，但它们的token序列完全是合法前缀表示。如果没有后验证阶段，这类候选会污染最终结果。
我还会建议保留多个不同结构的候选表达式，而不是只输出排名第一的。在科研场景中，如果排名靠前的候选结构差异很大，说明数据对表达式结构的约束不够，需要补充数据或扩大采样范围；如果前几个候选结构高度一致，那结果就比较可信。这样的不确定性信息，对科学发现的决策非常有价值。
5. 基准评测与已知短板：效果很好，但别盲信"端到端"
5.1 对标遗传规划：速度碾压，精度看分布
在公开的符号回归基准（比如Feynman Symbolic Regression Benchmark）上，端到端Transformer方法的好成绩是可以复现的。单变量简单函数几乎能做到秒出结果，遗传规划通常需要几分钟到几小时才能找到可接受解。这种速度差异在需要交互式分析的场景里是革命性的——你可以当场试几百组数据，而不是跑一组就要等半天。
但精度要分情况讨论。目标函数的复杂度一旦超出训练集的复杂度分布，Transformer的准确率会快速下滑。遗传规划虽然慢，但它不依赖训练分布，面对任意复杂度的函数都有一定概率找到近似解。于是出现了一个很实际的格局：在常见表达式上，Transformer碾压传统方法；在极端复杂或者罕见结构上，Transformer可能直接失败，而遗传规划至少还在搜索。
工程落地时不要把Transformer当成传统方法的替代品。我采用的组合方案是：先用Transformer在毫秒级产出几个高概率候选，再用这些候选初始化遗传规划种群。这个思路既利用深度生成模型的速度，又保留传统搜索的完整性，效果比单独使用任一方法都稳。
5.2 泛化的边界：分布内无敌，分布外很吃力
端到端方法最容易让人误解的地方是它具备"科学发现的创造力"。实际上它的泛化能力严重受限于训练分布。训练时如果把表达式最大深度限制在6层以内，推理时遇到深度为10的表达式，模型会退化得很厉害。这不是模型不够聪明，而是它压根没见过这个复杂度的训练样本。
更微妙的失败模式是结构外推。假设训练集里几乎都是多项式和三角函数的混合体，目标却是一个包含Bessel函数的表达式。模型大概率会生成一个看起来有点像Bessel的伪表达式，可能是一堆sin和cos的组合，数值上却完全对不上。我一度以为是代码bug，后来才意识到这是分布外表达式的典型症状：模型在它的表达能力范围内尽力凑一个表达式，但这个表达式没有数学上的解释力。
因此，如果要在特定科学领域使用这个工具，强烈建议按领域调整训练数据的分布。处理物理方程，就在训练集里增加物理常见结构（二次项、周期项、指数衰减等）；处理生物数据，就加大比率和Logistic结构比例。这一步能显著提升模型在目标领域的零样本准确率。
5.3 噪声鲁棒性与高维困境：实测中的翻车场景
真实科学数据几乎总有噪声，而符号回归非常容易过拟合噪声。训练数据是完全无噪声的，如果推理时输入带噪声的数据点，模型会把数值波动当作有意义的结构信息来"解读"，于是开始编造表达式。实测下来，1%的噪声基本无压力，5%的噪声会导致准确率明显下降，10%以上噪声就会出现大量胡编乱造。
缓解手段是在训练时就对y值注入少量噪声，作为数据增强。这样模型有机会学到忽略小幅波动，只关注整体趋势。这个trick实现成本极低，但显著提升实际场景中的鲁棒性。
高维场景是另一个大坑。变量数一多，需要采样的点数呈指数增长。每个维度只采样2到3个点，输入长度已经很大，但每个维度的覆盖极不充分，模型很难区分"这个变量到底在不在表达式里"。高维符号回归目前仍然是开放难题，端到端Transformer并没有本质性解决，只是在低维上把速度提升了一个数量级。我在三维以上的复杂函数上，还是建议先做特征筛选或者分组，把维度降下来再上符号回归。
6. 从论文到工程：我踩过的坑和给后来者的建议
6.1 数值token化的坑：浮点数分词会左右模型认知
我在复现时踩得最深的坑就是浮点数的token化。一开始图省事，把浮点数离散成固定精度的字符串，比如"3.14"作为一个token。结果模型对数值比较的感知彻底失灵，把3.14和3.15当成完全无关的token。后来换成值域分桶，比如把[-10,10]分成4096个桶，效果还是不理想——桶边界附近的数值被不连续地编码，模型很难学会数值的连续性。
最终采用的方法是把浮点数拆成符号、尾数、指数三个字段分别编码。比如-2.5e3被拆成[sgn=-, mantissa=2.5, exp=3]三个token。这种表示让模型在token空间里就能感知到数值大小、方向和数量级的关系。这和机器翻译里的sub-word分词思路相似，但更符合数值语义。如果你用现成代码库，可以先跑默认数值tokenizer，但一定要检查模型在不同数值尺度下的行为，特别是尺度差异大的数据。
归一化又是一个坑。前面说了不归一化训练不稳定，但标准化又会让模型丧失尺度感知。我最后采用的做法是：每个训练样本在标准化后，把均值和标准差作为额外token拼在序列末尾。这样模型自己决定是否需要使用尺度信息，在推理阶段表现非常稳定。
6.2 训练成本与数据规模：什么时候该放弃自己训练
训练一个端到端符号回归模型的成本并不低。以单变量为例，假设生成2000万个训练样本，每个样本输入长度200，输出长度平均30，在4到8张A100上要跑数天。多变量场景的资源消耗还要更高。
所以如果不是为了发论文或者做深度学术研究，我建议先跑现成的预训练模型。社区里已经有E2E符号回归模型的开源实现，直接加载权重推理通常就够用。只有当现成模型在特定领域的分布上严重不匹配时，才考虑在自己的数据分布上做微调。微调的数据量可以控制在几百万条，训练时间和成本比从零预训练低一个量级。
如果你确实要自己训，数据质量比数据量更值得花时间。宁可只有500万个高质量、去重、化简过的样本，也不要5000万个充满等价表达式和非法样本的脏数据。
6.3 值得尝试的扩展：常数池、多目标拟合、科学发现流程
最后聊几个我认为价值很高的扩展方向。
第一是常数池设计。把训练数据中出现频率最高的常数做成一个池子，推理时优先从池子取值。物理方程恢复场景中效果极好，因为π、e、1/2、√2这些常数反复出现，模型只要记住它们，就不需要完全依赖数值优化器从零拟。
第二是多目标拟合。标准符号回归是拟合一个y等于f(x)，但很多实际任务需要同时拟合多个输出，比如从轨迹数据同时恢复位移方程和速度方程。Transformer架构天然支持多任务输出，decoder部分改成输出多个表达式序列即可。在自动驾驶、机器人控制这类场景里，多目标拟合的价值很大。
第三是把端到端模型嵌入完整科学发现流程。我目前在项目里使用的管线是：Transformer生成候选表达式，数值优化精修常数，BIC做模型选择，拟合优度检验评估可信度。这套管线比单独跑遗传规划或单独跑Transformer都稳定，产出的结果也更容易被领域专家接受。
端到端Transformer符号回归真正改变了这个领域的实用面貌：它把符号回归从"最慢的AI方法之一"变成了"常见情形下几乎即时反馈的工具"。不过越用越会意识到，它的本质仍然是基于训练分布的快速检索，而不是真正的数学洞察。但这并不妨碍它成为极其强大的工程工具。有条件自己训一套的话，把训练数据分布设计好；只打算直接用的话，一定给它配一个合格的后处理流程，别让模型输出的原始token流直接当结果交付。