這幾年指導學生的時候常遇到的問題就是學生會說「因為 OOO 做不出來，所以改用 XXX 方法」，有的甚至直接跳到 metaheuristic 方法，或者學生就等著看老師要怎麼辦，抑或是看能不能就直接更換題目。這種時候都讓我感到相當痛苦。
要知道「做不出來」(是主觀能力認定)與「此問題無解」(是客觀事實否定) 其實有天淵之別，為了避免學生在「原方法尚未分析清楚」的情況下任意切換方法，導致研究方向失控或失去理論基礎。我將我的想法整理如下，對於特別在(控制理論、隨機系統、最佳化、金融工程)領域適用：
什麼不是更換研究方法的理由：
以下理由都不足以支持換方法：
- 「跑不出答案(跑了很多次)」、「電腦算不動」、「算法不 converge 」、「結果怪怪的」、「找不到答案」、「證不出來」、「資料拿不到」、「code不會寫」、「文獻看不懂」
- 「我看別人（文獻）用這方法有效」、「別人(文獻)都這樣用」
- 「我覺得 metaheuristic 方法 GitHub 上有現成 package 比較簡單」
- 「我不知道怎麼 debug」
只說「做不出來」其實本身沒有任何意義。小心屬於「執行結果不如預期」而非「方法原理上不可行」作為更換方法的動機。
要換方法應先提交 Failure Analysis Report：
未提交前，不應任意更換方法，也不該自行更動研究方向。目的是要讓人看得出來，你已經有試過各種「系統性修正」，而不是亂試新方法，Failure Analysis Report 至少包含：
- 原方法的完整理論與演算法描述
- 問題的 objective、constraints、dynamics
- 參數設定
- 算法步驟
- 預期應滿足的最佳性條件（如 KKT、Bellman、HJB）
- 預期應滿足的穩定性條件（如 Lyapunov function）
- 預期應滿足的強健性條件
- 預期應滿足的算法複雜度條件
- 預期應滿足的近似條件
- 明確指出「哪裡做不出來」，只說「做不出來」= 無效論證。學生應回答：
- 失敗發生在哪一行計算？
- 是gradient / Jacobian / Hessian 算不出來？
- 約束是否不相容？
- 數值解是否跳出可行域？數值誤差？
- dynamics 無法滿足？
- initial condition 是否導致 divergence？
- 實驗/模擬結果是否可重現？(不同資料集都指向同一結論)
- 模擬結果不佳？
- 合理的失敗原因推論（有理論或合理假設），例如：
- 模型非凸 → local solver 卡在 local minima
- state/control constraint 過於嚴格 → 無可行解
- dynamics stiffness 太高 → 數值爆炸
- objective/loss scale 不當 → 需要 normalization
- 多期多目標計算
- Impossibility claim 的證明: 若你要宣稱「這個問題做不到 / 不可能」必須附上 理論或模擬證據，例如：
- 證明無可行解
- 顯示最佳性條件（KKT / Bellman）不可同時滿足
- 顯示系統缺失某robustness/stability/performance
- 指出該問題在某些條件下為 NP-hard
- 提供反例或實驗結果，清楚展示失敗原因
「做不出來」、「不可能」等說法，不可能會被直接接受。我預期學生應該要提供：
- 具體失敗證據（至少一種）
- 數值例子(宣稱非凸應該繪製其非凸的圖例)
- 圖表
- log / 訊息
- constraint violation
- Optimality Condition (e.g., KKT) violation
- Complexity analysis
- 數值或者理論反例
- 至少三種「結構化修正」嘗試。例如最佳化問題：
- 調整 step size
- 改 initial condition
- 放寬或修改 constraint
- scaling / normalization / shifting
- convex surrogate、linearization / relaxation
- 理論上合理的 heuristic（不是隨便 metaheuristic）
- greedy algorithm with provable approximation ratio 是合理的 heuristic；而 genetic algorithm without convergence guarantee 則不是。
- 求解器更換 (Gurobi/MOSEK/CVX)
對採用「新方法」的要求：必須有合理性證據
允許換方法的合理理由示例：
- 新方法與研究問題結構更一致（例如 convex 問題改用 QP）
- 可以證明更好的 optimality/stability/robustness 性質
- 可以證明可行性、收斂性
- 文獻中有具體、可查證的支持
不合理理由示例：
- 「github上有現成套件」
- 「我覺得 metaheuristic 比較方便」
- 「網路上有人這樣用」
- 「我自己跑起來比較順」
若新方法無法在 「理論上更強」 或與 「結構更相容」 則禁止更換。未達以上要求就換方法，應視同無效研究行為。不僅浪費自己時間也浪費指導教授時間。
反思：
研究不是亂試方法，特別在遇到困難的時候，應該要去理解原方法限制在哪？為什麼失敗？雖然說是這樣說，但是可能更多時候師生立場不同，可能學生觀點會認為是老師們都是站著說話不腰疼，只會在旁邊指指點點，但是在我這邊，其實情況更多時候都是相反，是我本人自己(而非學生)跳下去解決問題，重寫理論、重跑模擬、重寫論文幾乎是家常便飯。如果長期都是這樣，那指導學生的意義何在？因此這些關於「什麼是合格的研究方法」以及在方法失敗時的分析與回報的標準，確實應該是在研究最早期就應該先說清楚。
沒有留言:
張貼留言