Go Gonum 优化器的结束状态为什么不都代表找到最优解

Gonum 的优化器结束时返回的不是一个简单的“成功/失败”布尔值。Result.Status 描述的是优化过程怎样结束：有些状态表示满足了收敛条件，有些只表示迭代次数、运行时间或评估次数用完，还有些表示线搜索或目标函数出了问题。

官方地址：https://pkg.go.dev/gonum.org/v1/gonum/optimize

判断一次优化结果时，先看 Status.Early() 和 Status.Err()，再结合候选点、目标值、梯度与业务阈值；不能因为 Minimize 没有返回 Go error，就把结果当成全局最优解。

本文只讨论 gonum.org/v1/gonum/optimize 的结果语义和工程判定，不讨论某个算法对非凸问题的全局最优保证。

Gonum 的结束状态先按语义分组

optimize.Status 是优化过程的结束标签。官方枚举同时包含 Success、FunctionConvergence、GradientThreshold、StepConvergence 等收敛类状态，也包含 IterationLimit、RuntimeLimit、FunctionEvaluationLimit 和 Failure。它们都能让过程结束，但含义不同。

最容易混淆的是“结束”和“找到最优解”。例如达到 IterationLimit 说明预算用完，不说明当前点已经满足你的精度要求；Failure 更不应被当成正常收敛。相反，梯度阈值、函数收敛或步长收敛，说明算法满足了对应的停止条件，但仍应结合问题本身判断这个候选是否可用。

用 Early 和 Err 看清提前结束

Status.Early() 的语义是：优化在找到 minimum 之前结束。官方文档以达到最大迭代次数为例，说明这种状态下 minimum 还没有找到；而达到梯度范数条件时，Early() 不会把它当作提前结束。

Status.Err() 用来取得提前结束关联的错误。如果 Early() 为 false，它返回 nil。因此，项目代码至少要把“正常收敛”“提前但有原因”“结果返回但不满足业务阈值”分成三条路径。

package main

import (
    "fmt"
    "log"

    "gonum.org/v1/gonum/optimize"
)

func main() {
    problem := optimize.Problem{
        Func: func(x []float64) float64 {
            // 这是一个简单的凸目标函数，最小点在 (3, -2) 附近。
            dx, dy := x[0]-3, x[1]+2
            return dx*dx + dy*dy
        },
        Grad: func(grad, x []float64) {
            // 梯度必须与 Func 对应，避免收敛状态建立在错误方向上。
            grad[0] = 2 * (x[0] - 3)
            grad[1] = 2 * (x[1] + 2)
        },
    }

    result, err := optimize.Minimize(problem, []float64{0, 0}, nil, nil)
    if err != nil {
        // 这里处理参数、方法能力或初始化阶段的错误。
        log.Fatal(err)
    }

    fmt.Println("status:", result.Status.String())
    fmt.Println("early:", result.Status.Early())
    if statusErr := result.Status.Err(); statusErr != nil {
        // 只有提前结束关联了错误时才输出错误细节。
        fmt.Println("status error:", statusErr)
    }
    fmt.Println("x:", result.X, "f:", result.F)
}

这段代码里，外层 err 与 result.Status.Err() 不是同一个层次：前者是 Minimize 调用本身返回的 Go error，后者是状态对象对提前结束原因的描述。生产代码不要只保留前者。

不同状态应该怎样选择处理方式

比较状态时，先问“停止条件是否符合这次任务的验收条件”，再决定是否接受结果。一个离线搜索任务可以接受函数收敛；一个对误差有硬约束的拟合任务，还要读取目标值或梯度并与业务阈值比较。

如果一个状态落在“预算耗尽”或“Failure”一列，就不要仅凭当前 X 看起来合理而自动入库。候选点可以作为调试产物保存，但它的可信等级应与满足收敛条件的结果区分开。

项目里应该怎样读取一次优化结果

Result 包含 Location、Stats 和 Status。其中 Location 提供候选位置、目标函数值和梯度，Stats 记录主要迭代次数、函数/梯度/Hessian 评估次数与运行时长。它们组合起来，才能回答“停在哪里、为什么停、花了多少成本”。

推荐把判定逻辑写成一个小函数：先拒绝 Early() 为真的结果，再按任务需要检查 Status、目标值和梯度，最后把 Stats 写入日志或指标。这样既不会把限制状态误判为最优，也能为“为什么没有收敛”留下证据。

func accept(result *optimize.Result, maxF, maxGrad float64) (bool, string) {
    if result == nil {
        // 空结果不能进入后续业务流程。
        return false, "result is nil"
    }
    if result.Status.Early() {
        // 迭代、运行时间或评估次数耗尽时，先按未收敛处理。
        if err := result.Status.Err(); err != nil {
            return false, err.Error()
        }
        return false, "optimization ended early"
    }
    if result.F > maxF {
        // 目标函数值仍超过业务阈值，状态正常也不能接受。
        return false, "objective value is too large"
    }
    if len(result.Gradient) > 0 {
        // 用无穷范数式的最大绝对分量做一个轻量业务检查。
        maxAbs := 0.0
        for _, value := range result.Gradient {
            if value  maxAbs {
                maxAbs = value
            }
        }
        if maxAbs > maxGrad {
            return false, "gradient is too large"
        }
    }
    return true, result.Status.String()
}

这里的阈值是业务规则示例，不是 Gonum 的统一标准。不同尺度、不同损失函数和不同优化方法需要分别设定；同时记录 result.Stats，才能区分“目标函数难优化”和“预算给得太小”。

常见误区与速查结论

误区一：err == nil 就是最优。 外层 error 只说明调用没有以该错误返回，仍需解读 Status。

误区二：所有收敛状态都代表全局最优。 收敛条件通常描述局部停止依据，尤其在非凸问题上，不等于全局证明。

误区三：达到迭代上限也算成功。 限制状态是预算信息，应标记为需要复查，而不是悄悄当成稳定结果。

速查时可以记成三句话：Status 看为什么停，Early() 看是否提前停，Err() 看提前停有没有错误；最后再用 X、目标值、梯度和 Stats 完成业务验收。

相关问题

Gonum 的 FunctionConvergence 和 GradientThreshold 该选哪个？ 前者更侧重目标函数变化，后者更侧重梯度规模，按你的停止条件和尺度选择，并保留另一项指标做复查。

ErrNoProgress 出现时要不要重试？ 先检查变量尺度、初始点、梯度实现和步长设置；盲目重试同一组输入通常只会重复同一边界。