PSO优化Transformer时间序列预测超参数实战

1. 先说清楚：把PSO和Transformer凑一起，到底在调什么

时间序列预测这个方向，Transformer 早就不是什么新鲜东西了。谁都能在几十分钟里搭一个 Encoder-Decoder 或者纯 Encoder 的结构出来，跑通训练，画出预测曲线。但如果真拿它去做业务里的负荷预测、销量预测、传感器趋势预测，麻烦事马上就来了：d_model取 64 还是 128？注意力头数取几个？层数堆两层还是四层？学习率是 1e-4 还是 5e-4？滑动窗口长度取 24 还是 96？这些超参数彼此耦合得很紧，改一个往往要连带调整好几个，而每试一组配置就得从头训练一遍。一年前的项目里，我在一台单卡机器上手工试了三十多组配置，前后耗掉快两周，最后拿到的方案也只比初始的默认参数好一点点，那感觉相当糟糕。

粒子群算法 PSO（Particle Swarm Optimization）就是来解决这个问题的。它属于群智能优化里最朴素也最好用的一类：一群“粒子”在超参数空间里飞，每个粒子记住自己走过的最好位置，同时参考整个群体当前的最好位置，不断调整速度和方向，几十代之后整个群体会往表现好的区域收敛。我用它来给 Transformer 的超参数做自动搜索，省掉了大量手工试错，更重要的是它不需要梯度信息，对这个“黑盒训练 + 验证集打分”的场景适配得非常好。

这篇内容适合两类人看：一类是已经把 Transformer 时序模型跑通、但卡在调参和效果瓶颈上的算法同学；另一类是听说过 PSO 但不知道怎么把它落到深度学习工程里的人。我会把编码方案、适应度函数设计、完整代码、算力预算控制、踩过的坑全部摊开讲，参数怎么定、为什么这么定都写清楚，照着改改就能跑。全文涉及到的数据集和场景都用虚构代称，方法本身是通用的。

2. 方案设计：为什么是PSO，而不是网格搜索或贝叶斯优化

2.1 Transformer做时序预测的真实痛点：参数地狱与耦合效应

先说清楚痛点在哪，不然容易把优化器当成万能药。Transformer 用于时间序列预测，超参数大概能分三类。第一类是结构参数：d_model、注意力头数nhead、编码器层数num_layers、前馈层维度dim_feedforward、dropout 比例。第二类是训练参数：学习率、权重衰减、batch size、学习率调度策略的预热步数。第三类是数据形态参数：输入窗口长度seq_len、预测步长pred_len、是否做差分、归一化方式。

这三类参数之间的耦合非常强。举个实际的例子：把d_model从 64 提到 128，模型容量上去了，但原来的学习率 1e-3 就偏大，训练容易在第三四个 epoch 开始震荡；同时 batch size 如果还保持 32，每个 batch 的梯度噪声就偏大，配合大模型更容易过拟合。也就是说，单独看每一个参数的“合理取值区间”是有意义的，但组合起来的最优点很难靠单变量扫描找到。这就是为什么很多人调参调到后面干脆放弃，退回一个“能跑就行”的配置。

还有一个更隐蔽的问题：参数和数据规模不匹配。同一套结构参数，放在只有几千条样本的数据集上会严重过拟合，放在几十万条样本上又容量不足。所以超参数搜索必须和具体数据集绑在一起做，不能抄别人的最佳实践。

2.2 PSO在这里扮演的角色：黑盒超参搜索器

PSO 的直觉很好理解。想象一群鸟在一片未知的山地里找食物最丰富的地方，每只鸟不知道整片地形，但它知道自己飞过的位置里哪块最好，也能看到同伴群里目前最好的位置在哪。于是它一边向自己记忆中的好位置靠，一边向群体的好位置靠，同时保留一点随机探索的惯性。对应到数学上就是三个部分：惯性项（保持原速度方向）、认知项（向个体历史最优靠拢）、社会项（向全局历史最优靠拢）。

把它用在超参数搜索上，一个“位置”就是一个完整的超参数组合，一个“适应度”就是这个组合下模型在验证集上的误差。PSO 不需要目标函数可导，不需要知道超参数和损失之间的解析关系，甚至可以容忍适应度带噪声（深度学习训练本身就有随机性）。这两点非常关键，因为 Transformer 的训练损失曲面绝对谈不上光滑，随机种子换一下结果就能差好几个百分点。

我选 PSO 而不是遗传算法，还有个工程上的理由：PSO 的代码量极小，核心更新就五六行，没有交叉、变异、选择那一堆算子，也没有编码解码的麻烦（虽然离散参数还是要单独处理）。对一个人维护的项目来说，代码越少越不容易出错。

2.3 和网格搜索、贝叶斯优化的横向对比

不能说 PSO 一定最好，得看场景。我把这几种方案在实际项目里的表现整理成一张表，方便你判断自己该用哪个。

关键判断依据是单次评估成本和参数维度。如果一次训练只要两三分钟，参数有八九个，PSO 和随机搜索的性价比最高，因为种群天然可以并行评估，20 个粒子开 4 个进程，一轮下来也就十几分钟。如果一次训练要几个小时，那贝叶斯优化更划算，因为它能用更少的评估次数找到好点，但要注意它本质是序列的，不好并行。

还有一点容易被忽略：PSO 的搜索是有记忆和方向的，它会在迭代中逐渐收缩到某个区域，这在小预算下是优势（收敛快），在大预算下反而是劣势（容易早熟收敛到局部最优）。所以我一般会配一个线性递减的惯性权重，前期探索、后期开发，具体在 2.4 节说。

3. 粒子编码与适应度函数：这套方案最核心的设计

3.1 位置向量的编码方案：连续空间承载混合类型参数

PSO 的标准形式是在连续空间里飞的，但我们的超参数里有整数（层数、头数）、有类别（激活函数）、有跨数量级的（学习率）。最省事的做法是统一映射到一个连续向量，再在解码时做变换。我通常把搜索空间定义成一个字典，每个维度写明类型、范围、变换方式。

# 搜索空间定义：每个维度是一个 dict SEARCH_SPACE = { "seq_len": {"type": "int", "low": 24, "high": 168, "step": 12}, "d_model": {"type": "choice","choices": [32, 64, 96, 128, 192]}, "nhead": {"type": "choice","choices": [2, 4, 8]}, "num_layers": {"type": "int", "low": 1, "high": 4}, "dropout": {"type": "float", "low": 0.0, "high": 0.5}, "lr_log10": {"type": "float", "low": -5.0, "high": -2.7}, # 存 log10(lr) "weight_decay_log10": {"type": "float", "low": -6.0, "high": -2.0}, "batch_size": {"type": "choice","choices": [16, 32, 64, 128]}, } DIM = len(SEARCH_SPACE)

几个设计上的考虑值得展开说。

学习率必须在对数空间里搜索。如果直接在 [1e-5, 1e-2] 的线性空间里飞，粒子落在 1e-3 到 1e-2 之间的概率是 90%，落在 1e-5 附近的概率几乎为零，搜索会严重偏斜。取 log10 之后区间是 [-5, -2.7]，均匀分布就合理多了。这个技巧看着小，但不做的话学习率搜索基本等于白做。权重衰减同理。

nhead和d_model有整除约束。这是硬约束，粒子飞到d_model=96, nhead=8这种组合是无效的（96 不能被 8 整除时 PyTorch 会直接报错）。处理方式我试过两种：一是解码时若非法就映射到最近的合法值，二是给适应度加一个巨大的惩罚值。我更倾向第一种，因为惩罚会让粒子在这个区域反复被“弹开”，浪费评估次数。

seq_len用整数加步长。步长设 12，是因为多数业务数据的采样周期是小时级，12 小时一个周期比较自然。步长太细会让搜索空间无谓地变大，実際上 24 到 168 之间取 13 个值足够了。

3.2 解码函数：把粒子位置还原成可训练的配置

解码函数是整个方案的枢纽，写错了后面全是错的。我把它单独抽成一个纯函数，方便测试。

import math def decode(position, space=SEARCH_SPACE): """把连续位置向量解码成合法超参数字典""" cfg = {} for i, (name, spec) in enumerate(space.items()): v = float(position[i]) if spec["type"] == "float": # 位置向量本身已归一化到 [low, high] cfg[name] = min(max(v, spec["low"]), spec["high"]) elif spec["type"] == "int": v = min(max(v, spec["low"]), spec["high"]) steps = round((v - spec["low"]) / spec.get("step", 1)) cfg[name] = int(spec["low"] + steps * spec.get("step", 1)) elif spec["type"] == "choice": idx = int(round(min(max(v, 0), len(spec["choices"]) - 1))) cfg[name] = spec["choices"][idx] # 后处理：还原对数参数 cfg["lr"] = 10 ** cfg.pop("lr_log10") cfg["weight_decay"] = 10 ** cfg.pop("weight_decay_log10") # 硬约束修复：d_model 必须能被 nhead 整除 while cfg["d_model"] % cfg["nhead"] != 0 and cfg["nhead"] > 1: cfg["nhead"] //= 2 return cfg

choice类型的处理要特别小心。如果按连续值去飞再取整索引，那“相邻索引”之间的语义距离是不均匀的——d_model从 32 跳到 64 和从 128 跳到 192 是完全不同的两件事。我的做法是让粒子在这个维度上飞，但速度上限压得很小（见 3.4），保证它不会在候选值之间来回横跳。另一种更严谨的做法是给每个候选值一个“质心”并按距离映射，但对 5 个以内的候选值，收益不明显，我没再折腾。

3.3 适应度函数：验证集误差为主，训练成本为辅

适应度函数决定了整个搜索往哪走，它的设计比 PSO 本身的参数重要得多。我用的是加权形式：

fitness = val_metric + λ1 * overfit_penalty + λ2 * time_penalty

val_metric是验证集上的主指标。回归任务我一般同时看 MSE 和 MAE，但 PSO 只能优化标量，所以选一个作为主指标，另一个作为日志记录。如果业务更关心相对误差，用 sMAPE 或 WAPE 更合适——这一点必须和实际使用场景对齐，别闷头优化 MSE 最后发现业务看的是峰值误差。

overfit_penalty处理的是过拟合。我用的形式是max(0, val_loss - train_loss * k)这类惩罚，或者更简单粗暴：如果验证损失连续 N 个 epoch 不降，说明这组配置容量过剩，给一个固定惩罚。加上这一项之后，搜索明显倾向于更保守的结构参数。

time_penalty是算力约束。如果不加，PSO 会无脑往大模型、大窗口的方向跑，因为那样训练集上的损失总是更低。加一个α * log(训练耗时)之后，搜索会主动避开那些“只提升 0.5% 但训练慢三倍”的配置。这个权衡在实际项目里非常重要，模型上线后的推理延迟也是成本。

还有几个必须注意的点：

验证集和测试集必须严格分开，PSO 的每一次评估都只能看验证集。搜索过程中反复看测试集，等于把测试集当验证集用，最后报出来的指标一定是虚高的。我在早期项目里犯过这个错，搜了 200 轮之后测试集指标好得离谱，上线才发现完全对不上。

每次评估都要固定随机种子，否则同一个配置跑两次结果能差 3%，PSO 会把这些噪声当成真实信号去追，轨迹会变得很乱。我的做法是评估阶段用固定种子，最终训练时才用多 seed 取平均来降低方差。

3.4 速度限制与惯性权重：让粒子别飞出搜索空间

标准的 PSO 更新公式是这样的：

v[i] = w * v[i] + c1 * r1 * (pbest[i] - x[i]) + c2 * r2 * (gbest - x[i]) x[i] = x[i] + v[i]

w是惯性权重，c1、c2是个体学习因子和社会学习因子，r1、r2是 [0,1] 的随机数。三个参数的取法我踩过几次坑，总结如下。

惯性权重必须线性递减。固定w=0.7的话，前期探索不足，粒子很快就挤在一起；固定w=0.9的话，后期收敛不下来，一直在最优点附近抖。我用的方案是从 0.9 线性降到 0.4，跨越整个迭代周期：

def inertia(iter_idx, max_iter, w_start=0.9, w_end=0.4): return w_start - (w_start - w_end) * iter_idx / max_iter

c1 和 c2 可以做反向调整。前期强调个体经验（c1大）有利于分散探索，后期强调群体经验（c2大）有利于收敛。我常用的是c1: 2.5 → 0.5，c2: 0.5 → 2.5的线性过渡。不过说实话，在只有 8 维的搜索空间里，c1=c2=2.0固定也能跑出差不多的结果，这个调整属于锦上添花。

速度上限是必须的。v_max一般取每维搜索范围的 15%~20%。不设上限的话，粒子一次更新就能飞出边界，被裁剪回边界后速度还保留着，接下来几代全在边界上贴着，等于浪费了这些粒子。我在choice类型的维度上把v_max压到 0.5 甚至更小，就是为了避免索引横跳。

4. 从数据到收敛：完整实操流程

4.1 数据预处理与滑窗构造：先堵住泄漏的口子

这部分和 PSO 没关系，但它是所有时序模型的地基，做错了再好的优化器也救不回来。时序数据的预处理有三个必须守住的原则。

第一，划分必须按时间顺序切，不能随机打乱。随机打乱会让模型在训练时“看到未来”，验证集指标会虚高到离谱。我通常按 7:1.5:1.5 或 8:1:1 切分训练、验证、测试，切完再构造滑窗。

第二，标准化统计量只能从训练集算。均值和标准差如果用了全量数据，测试集的分布信息就泄漏进来了。正确做法是先在训练集上fit，然后对验证集、测试集只做transform。

第三，滑窗的目标不能跨过划分边界。构造样本时，如果某个样本的输入窗口在训练集、目标落在验证集，这个样本应该丢弃，否则验证阶段的输入里混着训练尾部，评估就不干净了。

import numpy as np def build_windows(series, seq_len, pred_len): """series: shape (T,) 或 (T, C) 的单变量/多变量序列""" X, Y = [], [] n = len(series) - seq_len - pred_len + 1 for i in range(n): X.append(series[i:i + seq_len]) Y.append(series[i + seq_len:i + seq_len + pred_len]) return np.asarray(X, dtype=np.float32), np.asarray(Y, dtype=np.float32)

要注意seq_len在 PSO 里是被优化的变量，所以滑窗构造不能只做一次。我的做法是：为每个数据集预先算好最大窗口长度（比如 168）对应的样本池，然后在适应度函数里按当前seq_len从池子里裁切。这样避免每评估一次就重新扫一遍原始序列，能省不少时间。

提示：如果你的数据有明显的周期性（日周期、周周期），在输入里显式加入时间特征（小时、星期、是否节假日）通常比单纯加大seq_len更有效。这类特征也可以放进 PSO 的搜索空间，作为一个 0/1 开关。

4.2 Transformer基线模型：保持简洁，别在结构上玩花样

搜索超参数需要一个稳定的基线模型。我的建议是结构写死、只暴露超参数，这样 PSO 优化的目标才清晰。如果连结构都在变（今天加个卷积前端，明天加个注意力池化），搜索空间会变得无法解释。

下面是我常用的一个轻量基线，纯 Encoder 加线性输出头，位置编码用正弦形式。相比完整的 Encoder-Decoder，它在中小规模时序数据上训练更快、过拟合更少，实测往往不输。

import torch import torch.nn as nn import math class PositionalEncoding(nn.Module): def __init__(self, d_model, max_len=512): super().__init__() pe = torch.zeros(max_len, d_model) pos = torch.arange(0, max_len).unsqueeze(1).float() div = torch.exp(torch.arange(0, d_model, 2).float() * (-math.log(10000.0) / d_model)) pe[:, 0::2] = torch.sin(pos * div) pe[:, 1::2] = torch.cos(pos * div) self.register_buffer("pe", pe.unsqueeze(0)) def forward(self, x): return x + self.pe[:, :x.size(1)] class TSFormer(nn.Module): def __init__(self, cfg, n_features, pred_len): super().__init__() self.proj = nn.Linear(n_features, cfg["d_model"]) self.pos = PositionalEncoding(cfg["d_model"]) layer = nn.TransformerEncoderLayer( d_model=cfg["d_model"], nhead=cfg["nhead"], dim_feedforward=cfg["d_model"] * 4, dropout=cfg["dropout"], batch_first=True, activation="gelu", ) self.encoder = nn.TransformerEncoder(layer, num_layers=cfg["num_layers"]) self.head = nn.Linear(cfg["d_model"], pred_len * n_features) self.pred_len, self.n_features = pred_len, n_features def forward(self, x): # x: (B, seq_len, C) h = self.proj(x) h = self.pos(h) h = self.encoder(h) h = h.mean(dim=1) # 时序池化 return self.head(h).view(-1, self.pred_len, self.n_features)

这里有个细节值得说：batch_first=True一定要开，否则输入维度是(seq_len, B, C)，后面所有维度推理都容易搞混。另外dim_feedforward我直接设成4 * d_model，没有让它参与搜索——它能带来的收益相对小，但会让搜索维度增加，不划算。

训练循环里我固定用AdamW、余弦退火加线性预热、早停patience=8。早停是省算力的关键：大部分烂配置在 10 个 epoch 内就能看出不行，没必要跑完 100 个 epoch。

4.3 PSO主循环：并行评估是提速的核心

代码不长，但每一行都有讲究。核心是把种群评估做成并行，因为粒子之间天然独立。

import numpy as np from concurrent.futures import ProcessPoolExecutor def pso_search(evaluate_fn, space, dim, n_particles=16, n_iter=15, w_start=0.9, w_end=0.4, c1=2.0, c2=2.0, seed=42): rng = np.random.default_rng(seed) # 1) 初始化：每维在 [low, high] 内均匀采样 lows = np.array([space[k].get("low", 0) for k in space]) highs = np.array([space[k]["high"] if space[k]["type"] != "choice" else len(space[k]["choices"]) - 1 for k in space]) X = rng.uniform(lows, highs, size=(n_particles, dim)) V = rng.uniform(-0.1, 0.1, size=(n_particles, dim)) * (highs - lows) v_max = 0.2 * (highs - lows) pbest_X = X.copy() pbest_f = np.full(n_particles, np.inf) gbest_X, gbest_f = None, np.inf history = [] for it in range(n_iter): # 2) 并行评估整个种群 with ProcessPoolExecutor(max_workers=4) as ex: scores = list(ex.map(evaluate_fn, X)) scores = np.array(scores, dtype=np.float64) # 3) 更新个体最优与全局最优 better = scores < pbest_f pbest_X[better] = X[better] pbest_f[better] = scores[better] idx = int(np.argmin(pbest_f)) if pbest_f[idx] < gbest_f: gbest_f, gbest_X = pbest_f[idx], pbest_X[idx].copy() # 4) 速度与位置更新 w = w_start - (w_start - w_end) * it / n_iter r1 = rng.random((n_particles, dim)) r2 = rng.random((n_particles, dim)) V = (w * V + c1 * r1 * (pbest_X - X) + c2 * r2 * (gbest_X - X)) V = np.clip(V, -v_max, v_max) X = np.clip(X + V, lows, highs) history.append((it, gbest_f)) print(f"iter {it:02d} | gbest={gbest_f:.5f}") return gbest_X, gbest_f, history

几个工程细节必须提醒。

进程池的 worker 数要匹配机器。max_workers=4是在单卡机器上的安全值，每个 worker 都要占显存，开太多会 OOM。如果你有多卡，更好的做法是每个 worker 绑定一张卡。另外，ProcessPoolExecutor在 Linux 上默认 fork，模型和数据集是否会被复制导致内存翻倍，要看具体写法，必要时用spawn启动方式。

适应度函数必须能容错。粒子会飞到各种奇怪组合上，训练时偶尔出现 NaN 损失、显存不足、维度不匹配都正常。我在evaluate_fn外面包了 try/except，任何异常直接返回一个很大的惩罚值（比如 1e6），而不是让整个搜索崩掉。

初始化不要纯随机。纯随机会让第一代里的粒子分布非常散，浪费评估次数。我通常会额外塞几个“先验经验点”进去，比如手动调过觉得还不错的配置，占种群的四分之一左右。这样第一代就能保证有一个不太差的基准，后续搜索从它附近展开。

4.4 参数回填与最终训练：别直接信PSO的结果

PSO 跑完给你的是 gbest 位置，解码出来是一组配置。但这组配置是在早停 + 固定种子 + 可能子采样的数据上评估出来的，和最终上线模型不是一回事。中间要做一个“重训 + 校准”的动作。

我的流程是这样的：拿到 gbest 配置后，先用完整数据、更多 epoch、3 个不同随机种子各训练一次，看三个结果的均值和方差。如果方差特别大（比如验证损失标准差超过均值的 8%），说明这组配置对初始化敏感，本身就不可靠，应该退回去看 PSO 历史里排名第二、第三的配置，选一个更稳的。这一步看起来多余，但它救过我好几次——有一次 gbest 在搜索阶段表现极好，实际重训三次里有两次崩了，后来换成排名第三的配置才稳定下来。

最终训练还要做一件事：在验证集上重新校准早停点。搜索阶段用的是固定的patience，最终训练可以放宽一点，同时画出训练/验证损失曲线，人工确认没有异常震荡。

4.5 结果对照：一次模拟数据集上的实测记录

为了让效果有个参考，我用一个模拟的多变量数据集（约 1.2 万条，8 个特征，采样周期小时级，含日周期和周末效应）做了一次完整实验。基线是手工配置，PSO 版本迭代 15 代、种群 16。所有结果都是三个随机种子取平均。

两个观察值得说。第一，PSO 找到的seq_len=72比我手工设的 48 大不少，配合更大的 dropout 0.31，说明这组数据里长期依赖比我想的更重要，同时模型容量需要正则来压住过拟合——这是手工调参很难同时想到的组合。第二，MAE 从 0.412 降到 0.361，相对提升约 12%，这个量级在实际业务里已经能感知到了，但它不是“碾压式”的提升，别对自动调参有不切实际的期待。

另外要注意，收敛结果的训练耗时比基线高了 60%。如果线上推理有延迟约束，这个配置未必能直接上，得回到适应度函数里把时间惩罚项的系数调大，重新搜一轮。

5. 踩坑实录：这些问题不提前知道会浪费你一周

5.1 常见问题速查表

下面这些是我和同事在真实项目里遇到过的，按出现频率排序。

5.2 三个容易被忽略但极其致命的细节

细节一：验证集指标的选择会直接改变搜索方向。一开始我用 MSE 做适应度，搜出来的模型在平稳段表现很好，但峰值处的预测明显偏低。原因是 MSE 对大误差敏感但被大量小误差稀释了，模型学会了“保守预测”。后来换成 WAPE（加权绝对百分比误差），峰值段的偏差明显改善。这件事的教训是：适应度函数必须和业务指标对齐，不能图省事用 MSE。

细节二：PSO 的评估次数比你想的贵得多。16 个粒子 × 15 代 = 240 次训练。就算每次只要 2 分钟，串行也是 8 小时，并行 4 路还要 2 小时。这还没算上数据加载、模型初始化的开销。所以开搜之前一定要先跑一个“预算估算”：单次评估耗时 × 总次数 ÷ 并行度，看看能不能接受。如果不能，优先减少种群规模而不是减少代数——粒子太少会让搜索空间覆盖不足，代数少一点至少还能拿到一个不错的局部解。

细节三：不要把 PSO 的搜索空间设得太宽。我见过有人把d_model从 16 搜到 1024，把num_layers从 1 搜到 12。这种搜索空间里，绝大部分区域的模型要么训不动要么直接 OOM，评估效率极低。正确做法是先用经验把范围压到一个合理区间（比如d_model在 32~192，层数 1~4），让 PSO 在这个“高质量子空间”里精细搜索。搜索空间的设计本身就是一种先验知识的注入，范围定得好，PSO 的效果能提升一大截。

5.3 算力预算不够时的三个降本手段

不是每个人都有多卡机器，下面是我在单卡环境下常用的降本组合，能把 240 次训练压到 1 小时以内。

手段一：代理评估。搜索阶段不用全量数据，只取训练集的前 30%，epoch 上限从 100 降到 25。这样单次评估从 2 分钟降到 20 秒左右。缺点是评分的绝对值和最终结果有偏差，但排序关系大体保持，PSO 只需要排序正确就够了。搜完之后再拿完整数据做最终训练。

手段二：评估缓存。粒子飞过之后可能会回到之前评估过的位置附近，如果解码后的配置完全一致，直接返回缓存结果。我见过一次搜索里 240 次评估有 30 多次是重复配置，纯属浪费。

手段三：种群分阶段。第一代用 24 个粒子做广度覆盖，之后每代只保留 12 个粒子做精细搜索，同时把已经评估过的位置从初始化里排除。这个做法有点“作弊”的意味，但在预算紧张时确实管用。

6. 还能往哪扩：这套框架的适用边界

PSO 加 Transformer 这个组合，本质上是一个通用黑盒超参搜索框架，Transformer 只是被搜索的对象。想清楚这一点之后，扩展方向就很自然了。

最直接的扩展是把损失函数的权重也纳入搜索。比如多步预测里常给近端步长更高权重，这个权重系数完全可以作为一个连续维度交给 PSO。另一个扩展是特征选择：如果输入有几十个候选特征，给每个特征一个 0/1 开关，让 PSO 一起搜，虽然维度会涨到几十维，但 PSO 在高维上比网格搜索强得多。还有一种是搜集成权重：训练几个不同配置的模型，用 PSO 搜它们加权融合的系数，这个场景下适应度函数极其便宜（不用重新训练），PSO 几分钟就能跑完。

但也有明确的边界。如果单次训练要几个小时，别用 PSO，评估次数根本不够，还不如贝叶斯优化。如果参数维度超过 30，也别用，标准 PSO 在高维空间里会退化得很厉害，得换 CMA-ES 这类协方差自适应的算法。还有就是数据量很小（几千条以内）的时候，超参数的影响远不如数据质量和特征工程，这时候花两天调参不如花两天做特征，我在早期项目里在这上面浪费过不少时间。

最后分享一个我在实际使用中的习惯：每次跑 PSO 之前，我都会先把手工调出来的“保底配置”塞进初始种群，并且记录下整个搜索历史。哪怕 PSO 最后找到的配置更好，那个保底配置也能作为一个对照组，让我确认提升到底来自哪里。搜索历史里的第二名、第三名也很有价值——它们往往比 gbest 更稳健，在需要上线的场景里，我经常选的是它们而不是 gbest。这套流程跑顺之后，一个中等规模时序项目的调参周期能从两三周压缩到三四天，剩下的时间就可以真正花在特征和数据上。