問題轉化：從選擇演算法到探索過程

在演化計算的實際應用中，一個常見的起點錯誤是——拿到任務先問「我該用 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. 請把該任務寫成「可變對象—評價方法—核心限制」的問題定義，並明確指出哪些屬於硬限制、哪些屬於軟偏好。

解答：
可變對象（搜尋空間與編碼）：學習率、正則係數、網路層數、注意力頭數、特徵組合策略——這些連續量與離散結構共同構成候選解的編碼。評價方法：這是一個多目標問題——離線 AUC 需最大化，線上 P99 延遲與模型參數量需最小化，同時可把候選之間的多樣性作為附加度量；AUC 與延遲之間存在明顯目標衝突，因此評價結果應輸出候選集合而非單一分數。核心限制：P99 延遲 ≤ 80 毫秒、顯存 ≤ 12GB、可在現有推論框架直接部署，這三項屬於必須滿足的硬限制，任何候選方案一旦違反即不可行。軟偏好：「參數更少、延遲更低」屬於可在滿足硬限制前提下權衡的軟偏好，用於在可行解之間排序，而不是用於篩選。

2. 為什麼不應先問「用 DE 還是 PSO」？請描述該任務如何組織為一個閉環探索過程，並說明怎樣保證產出是可部署的。

解答：
演算法選擇屬於過程設計內部的一環，而不是求解起點：在搜尋空間、評價方法與限制尚未明確之前，任何演算法比較都缺乏統一的比較基準，討論「DE 還是 PSO」只是在比較兩個尚未被定義的探索過程。閉環組織方式：①候選生成——依搜尋空間取樣超參數與結構配置；②評價——在驗證集上平行計算 AUC，並測量或估計推論延遲與顯存佔用，同時檢查硬限制；③回饋——依據多目標優劣與偏好更新搜尋分布與選擇壓力，把資源集中到更有希望的区域；④再生成——用更新後的分布產生新一代候選，循環往復。可部署性保障：把 P99 延遲、顯存與框架相容性作為硬限制，在生成或評價階段直接判為不可行並剔除，避免出現「指標漂亮但無法上線」的方案；對延遲等昂貴指標可先用代理模型或小規模實測篩選，再對少量候選做完整驗證。最終輸出一組在目標權衡上分布良好的候選方案，交由工程與產品決策選擇，而具體採用哪種演算法（DE、PSO 或混合策略）只是閉環內部可替換的組件選擇。