问题转化：从选择算法到探索过程

在演化计算的实际应用中，一个常见的起点错误是——拿到任务先问“我该用 DE 还是 PSO”。这句话把算法选型放在了求解的入口，但它只回答了“用什么工具去搜索”，并没有回答“要搜索什么、什么算好、什么绝对不能违反”。而真正决定成败的，是问题定义的质量。

所谓问题转化，就是把“选择哪个算法”改写成“设计一个可探索的过程”：先明确真实问题中什么可以改变、改变之后如何评价、哪些约束必须满足，再让算法在这个搜索空间里迭代地生成与筛选候选。算法选择由此成为探索过程设计中的一环，而不是它的起点。

四个必须先落地的定义

可变对象：界定哪些参数、结构、策略或流程允许被调整，由此形成搜索空间与编码边界。没有它，候选解无法被表示，也无从生成。
评价方法：定义改变之后如何判断优劣，包括目标函数、评价指标、偏好方向，以及可行性与多样性等度量。评价方式实质上决定了搜索会朝哪个方向走。
核心约束：区分必须满足的硬约束与可权衡的软偏好。把硬约束混进目标函数里“打个折”，很容易产出看似得分很高、却根本无法部署的方案。
探索过程：把问题形式化为“候选生成—评价—反馈—再生成”的闭环，让评价结果反过来影响后续生成，而不是一次性定死求解思路。

转换带来的差别

面对一个参数优化任务，习惯性做法是“先选一个算法——比如 DE 或 PSO——然后开始调参”。转化之后的做法是依次回答三个问题：哪些参数可调？用什么指标（或哪几个相互冲突的指标）来评价？哪些约束绝对不能违反？回答完这三个问题，任务就已经被形式化为一个可接入演化求解器的多目标问题；此时再决定用哪种算法、以什么算子配置去探索，只是在闭环内部做一个可替换的工程决定。换言之，算法不是答案本身，它只是探索过程中可配置的一环，问题定义的质量才决定探索的上限。

常见误区

把“算法效果不好”直接归因于算法本身，却忽略了三件更根本的事：搜索空间定义含糊、评价指标与真实业务目标脱节、硬约束缺失。先修问题定义，再谈算法替换，往往比反复换算法更有效。

问题转化流程

图中把求解任务从“先选DE还是PSO”改写为可探索流程：先界定可变对象、评价方法、核心约束，再让候选生成、评价、反馈与再生成形成闭环。算法选择因此只是闭环内可替换的一环，问题定义质量才决定探索上限。

问题 1

在把“选择哪个算法”转化为“设计一个可探索的过程”时，第一步应当明确什么？

界定哪些参数、结构、策略或流程允许被调整，形成搜索空间与编码边界

先把种群规模固定为 100

先决定使用 DE 还是 PSO

先确定总迭代代数

问题 2

关于“评价方法”在问题转化中的作用，下列哪一项描述最准确？

评价方法由所选算法自动决定，与任务无关

评价方法要定义改变之后如何判断优劣，包括目标函数、指标、偏好，以及可行性与多样性等度量

评价方法只需在最后一轮迭代时计算一次

评价方法就是准确率越高越好，不需要其他指标

问题 3

某在线服务的部署要求是“P99 延迟不得超过 80 毫秒”。在问题转化中，它属于哪一类？

搜索空间的一个编码维度

必须满足的硬约束，探索产出的方案都不得违反

可以权衡、必要时放弃的软偏好

目标函数里的一个加分项

问题 4

把问题形式化为“候选生成—评价—反馈—再生成”的闭环，与一次性算法选型相比，关键差别是什么？

闭环一定比单次选型计算得更快

闭环让评价结果反过来改变后续生成，从而持续调整搜索方向，而不是一开始就把思路定死

闭环不再需要定义任何约束

闭环必须使用群体类算法才能成立

问题 5

为什么说“算法不是答案本身”？

因为算法实现中总会有缺陷

因为问题定义的质量决定探索上限，算法只是探索过程中一个可配置、可替换的组件

因为算法在并行硬件上运行会不稳定

因为演化算法必然收敛到局部最优

案例：推荐排序模型的多目标调优

阅读下面的场景，把任务从“选算法”改写为“设计可探索的过程”，并回答两个问题。

某在线推荐系统需要优化其排序模型。可调整的对象包括：学习率、正则系数、网络层数、注意力头数，以及特征组合策略。团队希望通过调优同时提升离线 AUC 并压低线上推理开销。可用的度量有：离线验证集 AUC、线上 P99 推理延迟、模型参数量、特征数量。已知的部署要求为：P99 延迟不超过 80 毫秒、显存占用不超过 12GB，且产出的模型必须能在现有推理框架上直接上线。在满足上述要求的前提下，团队更希望模型参数更少、延迟更低。目前团队争论的焦点是：到底该用 DE 还是 PSO。

1. 请把该任务写成“可变对象—评价方法—核心约束”的问题定义，并明确指出哪些属于硬约束、哪些属于软偏好。

Answer:
可变对象（搜索空间与编码）：学习率、正则系数、网络层数、注意力头数、特征组合策略——这些连续量与离散结构共同构成候选解的编码。评价方法：这是一个多目标问题——离线 AUC 需最大化，线上 P99 延迟与模型参数量需最小化，同时可把候选之间的多样性作为附加度量；AUC 与延迟之间存在明显目标冲突，因此评价结果应输出候选集合而非单一分数。核心约束：P99 延迟 ≤ 80 毫秒、显存 ≤ 12GB、可在现有推理框架直接部署，这三项属于必须满足的硬约束，任何候选方案一旦违反即不可行。软偏好：“参数更少、延迟更低”属于可在满足硬约束前提下权衡的软偏好，用于在可行解之间排序，而不是用于筛选。

2. 为什么不应先问“用 DE 还是 PSO”？请描述该任务如何组织为一个闭环探索过程，并说明怎样保证产出是可部署的。

Answer:
算法选择属于过程设计内部的一环，而不是求解起点：在搜索空间、评价方法与约束尚未明确之前，任何算法比较都缺乏统一的比较基准，讨论“DE 还是 PSO”只是在比较两个尚未被定义的探索过程。闭环组织方式：①候选生成——按搜索空间采样超参数与结构配置；②评价——在验证集上并行计算 AUC，并测量或估计推理延迟与显存占用，同时检查硬约束；③反馈——依据多目标优劣与偏好更新搜索分布与选择压力，把资源集中到更有希望的区域；④再生成——用更新后的分布产生新一代候选，循环往复。可部署性保障：把 P99 延迟、显存与框架兼容性作为硬约束，在生成或评价阶段直接判为不可行并剔除，避免出现“指标漂亮但无法上线”的方案；对延迟等昂贵指标可先用代理模型或小规模实测筛选，再对少量候选做完整验证。最终输出一组在目标权衡上分布良好的候选方案，交由工程与产品决策选择，而具体采用哪种算法（DE、PSO 或混合策略）只是闭环内部可替换的组件选择。