Go Gonum BFGS 与 NelderMead 对梯度的要求有什么区别

在 Gonum 的 optimize 包里，BFGS 和 NelderMead 的关键差别不是名字，而是它们对问题输入的要求：BFGS 是基于梯度的拟牛顿方法，通常需要在 optimize.Problem 中提供 Grad；NelderMead 是无梯度方法，只需要可靠的 Func。因此，目标函数能否稳定地给出梯度，决定了两者的第一轮选型。

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

有解析梯度、维度较高且希望减少盲目函数试探时，优先看 BFGS；目标函数不可导、梯度难以获得或梯度噪声很大时，先看 NelderMead。不要把“能计算函数值”误当成“适合所有优化方法”。

BFGS 为什么要求 Grad

BFGS 会利用当前位置的梯度来判断下降方向，并逐步维护一个逆 Hessian 的近似。Gonum 文档把它描述为拟牛顿方法，且说明普通 BFGS 的内存成本随输入维度按 O(n²) 增长。这里的 Grad 不是可有可无的额外输出，而是方法判断方向时使用的输入信号。

如果只写 Func 而强制选择 BFGS，问题就不是“结果可能差一点”，而是 Problem 与所选 Method 的能力要求不一致。optimize.Minimize 会根据方法需要检查问题字段；缺少必须字段时可能直接 panic。因此，BFGS 的最小结构应明确包含函数值和梯度：

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 + 4*dy*dy
        },
        Grad: func(grad, x []float64) {
            // Grad 必须把每个变量的一阶偏导写入对应下标。
            grad[0] = 2 * (x[0] - 3)
            grad[1] = 8 * (x[1] + 2)
        },
    }

    result, err := optimize.Minimize(problem, []float64{0, 0}, nil, &optimize.BFGS{})
    if err != nil {
        // API 错误和不收敛状态都应该交给调用方处理。
        log.Fatal(err)
    }
    if err := result.Status.Err(); err != nil {
        // Status.Err 能把失败状态转换成可判断的 error。
        log.Fatal(err)
    }
    fmt.Printf("最优点: %.4v, 函数值: %.4f\n", result.X, result.F)
}

这个例子中，Func 返回标量目标值，Grad 返回与 x 等长的梯度切片。只要梯度下标错位、漏写分量，BFGS 得到的下降方向就会失真；所以解析梯度必须和目标函数保持同一变量顺序。

NelderMead 为什么不要求 Grad

NelderMead 使用一组点组成的 simplex，通过比较各点的函数值来移动、扩张、收缩或缩小 simplex。它的定位是 gradient-free nonlinear optimization，所以 Problem 只提供 Func 也可以显式选择它。

同一个目标函数可以这样写：

package main

import (
    "fmt"
    "log"

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

func main() {
    problem := optimize.Problem{
        Func: func(x []float64) float64 {
            // 只提供函数值，模拟无法稳定提供解析梯度的目标。
            dx, dy := x[0]-3, x[1]+2
            return dx*dx + 4*dy*dy
        },
    }

    result, err := optimize.Minimize(problem, []float64{0, 0}, nil, &optimize.NelderMead{})
    if err != nil {
        // 函数值计算失败时，不要把错误伪装成优化结果。
        log.Fatal(err)
    }
    if err := result.Status.Err(); err != nil {
        // 结束状态仍需由调用方决定是否接受。
        log.Fatal(err)
    }
    fmt.Printf("最优点: %.4v, 函数值: %.4f\n", result.X, result.F)
}

NelderMead 省掉的是梯度输入，不是所有计算成本。它仍然需要反复调用 Func，如果一次函数评估要访问远程服务、执行复杂仿真或读取大量数据，函数求值次数本身就会成为主要开销。

两种方法对旧代码的影响

如果已有代码只定义了 Func，迁移到 BFGS 时要新增 Grad，而不是仅把构造器从 NelderMead 换成 BFGS。反过来，从 BFGS 改到 NelderMead，可以移除梯度实现，但应重新观察函数求值预算和收敛状态。

什么时候换成 NelderMead

以下情况更值得先考虑 NelderMead：目标函数包含离散分支或阈值，数值上不光滑；函数来自外部仿真器，只能拿到输入和输出；有限差分得到的梯度被噪声放大；或者当前目标只是先找到一个可用区域，再补充更精确的梯度实现。

不过，“没有解析梯度”不等于 BFGS 永远不能用。可以先评估有限差分或自动微分的稳定性、额外函数调用成本，以及梯度在整个搜索区域是否有意义。若梯度近似在关键区域跳动，BFGS 的线搜索与方向更新可能比无梯度方法更难调。

最小决策表

1. 能写出与目标函数严格对应的解析梯度，并且梯度计算比函数评估便宜：优先试 BFGS。
2. 只有函数值，目标函数不可导或梯度噪声明显：优先试 NelderMead。
3. 维度较大但确实需要梯度：不要只看 BFGS，也比较 Gonum 的 LBFGS；普通 BFGS 的二次内存成本可能不合适。
4. 函数评估很贵：无论选择哪种方法，都应把函数求值上限、缓存策略和结束状态纳入设计。

最后，先检查 API 契约，再比较算法名称：Func 描述你要优化什么，Grad 决定梯度方法能否获得方向信息，Method 决定 Gonum 怎样消费这些信息。这个顺序能避免把缺少 Grad 的问题误判成 BFGS 参数调得不够好。

相关问题

• BFGS 的 Grad 返回值为什么必须和输入变量一一对应？
• NelderMead 只使用函数值时，函数求值很慢该怎么处理？
• 普通 BFGS 和 LBFGS 的内存成本有什么区别？
• optimize.Minimize 的结束状态应该如何判断是否接受？