Go Gonum optimize 怎样按运行时间停止优化

Go Gonum optimize 要限制一次优化最多运行多久，直接在 optimize.Settings 中设置 Runtime，例如 Runtime: 2 * time.Second。当到达时间边界时，结果的状态会变成 RuntimeLimit；它表示本次搜索按预算结束，不等于已经找到满足业务精度的最优解。

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

最重要的两个判断是：Runtime 为零表示不启用时间上限；时间只在方法的 MajorIteration 检查，因此它是优化过程的预算边界，不是强制打断当前函数调用的外部超时。

Runtime 到底限制了什么

Settings.Runtime 的类型是 time.Duration。它限制的是一次 Minimize 运行允许消耗的时间，零值表示不限制。Gonum 会在主要迭代节点检查时间，超出后返回 RuntimeLimit 状态。

这和 HTTP 请求的 context 超时不是一回事：如果你的目标函数本身一次调用就很慢，Runtime 检查要等到方法回到下一次主要迭代，不能替你取消一个已经开始的函数调用。需要取消外部 I/O 或远程任务时，仍应在目标函数内部设计可取消边界。

在 Settings 中设置时间预算

把时间单位写成 Go 的 time.Duration，比直接填写整数更容易审查。下面的示例给优化任务设置 2 秒预算，同时保留一个函数求值上限，避免单一条件失效时资源无限增长。

package main

import (
    "fmt"
    "log"
    "time"

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

func main() {
    problem := optimize.Problem{
        Func: func(x []float64) float64 {
            // 目标函数只读取 x，返回待最小化的标量值。
            dx := x[0] - 3
            dy := x[1] + 1
            return dx*dx + dy*dy
        },
    }

    settings := &optimize.Settings{
        // Runtime 是时间预算；零值表示不启用这个上限。
        Runtime: 2 * time.Second,
        // 第二道保险限制函数求值次数，防止单次计算过多。
        FuncEvaluations: 10000,
    }

    result, err := optimize.Minimize(problem, []float64{0, 0}, settings, nil)
    if err != nil {
        // Minimize 的返回错误与 Result.Status 是两条不同信息，分别处理。
        log.Fatal(err)
    }
    fmt.Println(result.Status, result.Stats.Runtime)
}

示例中的 FuncEvaluations 不是题目主角，它用于说明组合条件：时间预算控制总时长，函数求值次数控制目标函数调用量。两者可以同时设置，但最终哪个条件先触发，要以返回状态为准。

Runtime 只在 MajorIteration 检查

官方文档特别说明，Runtime 只在方法的 MajorIteration 检查。由此可以得到三个实际结论：

• 超时判断不保证精确落在设置的那一秒，当前主要迭代或函数评估完成后才可能进入检查点。
• 目标函数、梯度或 Hessian 如果单次耗时很长，观察到的总耗时可能超过预算。
• 使用并发评估时，已经开始的评估不会因为 Runtime 到期而凭空消失，收尾仍由优化器完成。

所以 Runtime 适合做服务级的“软预算”，而不是替代每个外部调用的硬超时。若函数内部访问数据库、文件或网络，应为这些调用单独设置超时，并让目标函数在取消后返回可处理的结果或错误。

用 Result 判断是到期还是收敛

Minimize 返回的 Result 同时包含位置、统计数据和状态。不要只看 result.X 或 result.F 就认为找到了最优解；先判断状态，再决定是否接受结果。

func acceptResult(result *optimize.Result) (bool, string) {
    switch result.Status {
    case optimize.RuntimeLimit:
        // 时间到期时保留候选值，但不能把它标记成已收敛。
        return false, "时间预算耗尽，保留候选结果等待下一轮"
    case optimize.Success, optimize.FunctionConvergence, optimize.GradientThreshold, optimize.StepConvergence:
        // 这些状态代表某种收敛或成功语义，仍需结合业务阈值复核。
        return true, "优化器报告已达到收敛条件"
    default:
        // 其它状态可能是迭代、评估次数或方法失败，应记录原因。
        return false, result.Status.String()
    }
}

如果要记录实际消耗，还可以读取 result.Stats.Runtime、MajorIterations 和各类评估次数。RuntimeLimit 说明停止原因，Stats.Runtime 说明统计到的运行时长，两者不要混为同一字段。

把时间预算和其它停止条件组合起来

选值时先看目标函数的成本，再决定是否叠加其它边界。目标函数稳定且单次很快，可以主要依赖 Runtime；目标函数昂贵或可能卡住，则要同时限制函数调用次数，并在函数内部处理外部资源超时。

注意，设置越多不代表结果越可靠。时间、次数和精度条件之间可能互相竞争：预算太短会频繁得到候选解，阈值太严又会让任务几乎总是以限制状态结束。应该把终止状态和业务验收阈值一起写入日志，而不是只记录一个浮点结果。

线上使用时的处理清单

1. 为每个优化任务定义一个明确的时间预算，并使用 time.Millisecond 或 time.Second 表达。
2. 如果目标函数包含外部调用，为外部调用单独设置超时，不把 Runtime 当作强制取消器。
3. 持久化 Status、Stats.Runtime、评估次数和最终候选位置。
4. 只有通过业务精度检查并且状态符合要求时，才把结果写入正式配置或模型。
5. 遇到 RuntimeLimit 时，可以把候选解作为下一轮的初始点，但要明确它是预算截断结果。

常见问题

Runtime 设置为零会怎样？

零值表示不启用运行时间上限。此时可以通过 MajorIterations、评估次数、收敛阈值或方法自身状态结束。

RuntimeLimit 是错误吗？

它首先是一个终止状态，表示时间预算触发。是否算业务失败，要看你的任务是否要求必须收敛；不能仅凭返回了候选位置就当作成功。

为什么实际耗时可能比 Runtime 长？

因为 Runtime 在主要迭代处检查，当前函数、梯度、Hessian 或已启动的并发评估需要先完成。想缩短尾部延迟，要降低单次评估成本或给外部依赖增加独立取消机制。

总结

Go Gonum optimize 的时间上限入口是 Settings.Runtime，到期后通过 RuntimeLimit 表达停止原因。正确做法是把它当作优化预算，结合 Result.Status 和 Stats.Runtime 判断结果是否可接受，并为目标函数内部的慢调用设置自己的超时。