参数调优找平衡点：二分法、三分法与黄金分割工程实践-北京尧图网络

在参数调优、阈值定标这类活里最耗时间的往往不是写代码而是反复问自己一个问题这个值到底取多少才合适。取小了效果不够取大了成本翻倍中间那条刚刚好的线我们平时就叫它平衡点。找平衡点的方法有很多种但真正能在工程里落地、又不容易写出 bug 的其实就两套思路一套是二分法专门用来找刚好跨过去的那条临界线另一套是三分法含它的省算力版本黄金分割法专门用来找曲线最低或最高的那个坑。这两套方法的代码量都不大十几行就能写完但写错的方式能有一大把我自己就踩过其中绝大多数。这篇内容面向的是需要给系统定参数的人可能是调批量大小、调并发上限、调缓存容量也可能是在成本和质量之间找一个折中点。你哪怕只会写最基础的循环和函数也能跟着跑通因为下面每一段都会把为什么要这么写讲清楚而不是只丢一段模板让你抄。我会先讲清楚平衡点在工程里到底对应哪几种数学对象再分别把两种方法的原理、实现、参数选择、踩坑点全部拆开最后用同一个场景把两种方法串起来跑一遍给出可以对照复现的数据和结论。1. 先把平衡点这三个字掰开看清楚很多人写不好这两套算法根子不在代码而在没搞清楚自己要找的东西是哪一类。同一个词平衡点在数学上至少对应三种完全不同的对象你把它认错了后面用再漂亮的模板都是白搭。这一节主要解决认题的问题。1.1 工程语境下的平衡点其实是三样东西第一种是临界线也就是方程的根。它回答的是从哪里开始就不再满足条件。比如吞吐量跌破承诺值的那条线、内存占用越过警戒水位的那条线、转化率掉到盈亏平衡以下的那条线。这类问题的数学形态是找一个 x使得 f(x) 刚好等于某个目标值本质是求零点。它有一个非常好的性质只要你研究的区间里函数是单调的要么一路涨要么一路跌那么这条线唯一存在而且可以被稳定地夹逼出来。第二种是最优点也就是极值。它回答的是取哪个值收益最大。成本随参数线性上升收益随参数先升后降两者相减得到一条中间高两边低的曲线曲线的顶点就是最优点。这类问题的特点是没有明确的目标值可以比对你没法说f(x) 等于多少就算达标只能比较哪个 x 让 f(x) 更大。求极值比求零点难因为它需要函数在局部是单峰的。第三种是不动点或均衡点也就是各方都不愿意单方面偏离的状态。供需平衡、博弈里的稳定策略、负载在多个节点间的自然分配都属于这一类。它听着玄但如果能把它转化成求某个差值函数的零点比如供给减需求等于零那么还是回到第一种依旧能用二分法解决。我个人的经验是绝大多数工程问题落到纸面上要么是第一种要么是第二种第三种只是一种说法。所以真正需要准备的就是两套工具。1.2 先做一次判断题你手上的问题该用哪一种在动手写循环之前先花两分钟回答下面三个问题答案基本就把方法定死了。第一个问题我能不能写出一个是/否的判断而不是一个多大的分数如果能那大概率是临界线问题用二分法。比如这批大小下吞吐是否达到 1000答案是布尔值天然适配二分。第二个问题在我的候选区间里指标是不是只有一个峰如果随着参数增大指标先升后降或者先降后升且中间没有第二个转折那可以用三分法。如果有多个峰三分法会把你带到一个随机的小山头上这个坑后面会专门讲。第三个问题我每次评估的代价有多大如果一次评估要跑几分钟的压测那求值次数就是硬成本这时候黄金分割法比标准三分法省将近一半的次数非常值得。下面这张表可以贴在工位上用来快速对号入座判断维度二分法三分法 / 黄金分割要找的东西临界值、边界、零点最优值、峰值、谷值对函数的要求区间内单调区间内单峰每次比较的形式布尔判断满足 / 不满足数值比较谁大谁小典型工程场景阈值定标、达标线、容量下限参数寻优、成本收益拐点精度收敛速度每轮区间减半每轮区间缩为 2/3实现出错率高边界写错就死循环中前提判断错就结果错注意这张表不是互斥的。同一个项目里经常是先用三分法找到最优点再用二分法确定距离最优点多远仍然可接受的容差带两种方法配合使用才是常态。2. 方法一二分法专治刚好越过这条线二分法的思路朴素得不像个算法把区间从中间切一刀看中间这个点满不满足条件满足就把右半边扔掉不满足就把左半边扔掉。每切一刀候选范围缩小一半。这个思路之所以能成立全靠一个前提——单调性。没有单调性二分法扔掉的半边里可能还藏着你要找的答案。2.1 单调性才是这套方法真正的地基很多人对单调性的理解停留在函数一直往上走其实工程里更需要的是另一种表述判断结果必须是一串否然后一串是中间不能来回跳。举个具体例子批量大小从 1 增加到 64 的过程中吞吐从 300 涨到 1200这期间吞吐是否达到 1000的判断结果就是否否否……是是是非常干净。这时候二分一定能找到那个从否变是的分界点。反过来如果指标是波动的比如由于测量噪声某次 batch40 时判定为是batch42 时又判定为否那单调性就被破坏了二分法会收敛到一个随机的、不可复现的结果。这时候你要做的不是改二分代码而是改判断函数——多测几次取中位数、加滑动平均、或者干脆放宽阈值留出噪声余量。这是很多人忽略的一步二分的鲁棒性不来自算法来自你的判断函数足够干净。还有一个隐蔽的坑单调性只在某个区间内成立。比如吞吐随 batch 先升后降那么在整个 [1, 512] 上它不是单调的只能在 [1, 64] 这个上升段上做二分。区间选错二分法不会报错只会安静地给你一个错误答案。所以我习惯在二分之前先用一小段采样画出趋势确认区间是单调的这个习惯救过我很多次。2.2 整数二分四种写错的方式和唯一稳妥的模板整数二分是死循环的重灾区。我见过也写过各种版本归纳下来出错基本集中在四个地方lo和hi的更新方式不对称、循环条件是还是搞混、返回lo还是hi不确定、以及mid的计算在负数区间上出偏差。与其记四种写法不如只记一个模板然后所有场景都往它上面套。这个模板只回答一个问题最小的、满足条件的那个整数是谁。def first_true(lo, hi, ok): 在 [lo, hi] 中找最小的 x 使得 ok(x) 为 True。前提ok 在区间内单调形如 False...False True...True 前提ok(hi) 必须为 True否则返回 hi 是错的 while lo hi: mid (lo hi) // 2 if ok(mid): hi mid # mid 可能就是答案保留 else: lo mid 1 # mid 一定不是答案跳过 return lo这个模板有三个关键点值得单独说。第一hi mid而不是hi mid - 1因为 mid 本身满足条件它有可能就是最终答案不能扔。第二lo mid 1而不是lo mid因为 mid 不满足条件它一定不是答案可以安全跳过这一步如果写成lo mid当区间只剩两个元素时就会原地打转形成死循环。第三循环结束时lo hi两者都指向答案返回哪个都对习惯上返回lo。至于最大的满足条件的整数怎么办不用另写一个模板把判断反过来就行把ok(x)换成not ok(x)找第一个不满足条件的再减一。这样你只需要维护一份代码出错概率直接砍半。日常开发里还有一种更省事的做法如果你用的是支持标准库的语言可以直接调已有的下界查找函数比如 Python 的bisect.bisect_left把候选区间当成一个有序数组来用。它的行为和你手写的first_true完全一致而且经过大量验证比自己写稳。2.3 实数二分精度不是越小越好连续区间上的二分写起来更简单因为不用担心1的边界问题但引入了另一个坑浮点精度。def solve_real(lo, hi, check, iters100): for _ in range(iters): mid (lo hi) / 2 if check(mid): hi mid else: lo mid return (lo hi) / 2注意这里的循环次数是写死的iters而不是while hi - lo eps。为什么因为在浮点数上当区间小到一定程度时(lo hi) / 2算出来的 mid 可能等于 lo 或者等于 hi此时区间再也不缩小while条件永远成立程序就卡死了。用固定迭代次数可以彻底规避这个问题代价只是多跑几轮无意义的循环而这点开销在绝大多数场景下可以忽略。迭代次数该取多少这里有个简单的换算。二分每轮把区间长度减半初始长度 L跑 n 轮后长度是 L / 2^n。想要精度达到 eps就需要 n ≥ log2(L / eps)。举个具体数字区间从 0 到 1000000想要精度 1e-6那么 n ≥ log2(1e12) ≈ 39.9取 40 轮就够。我一般直接写 100 轮因为多跑 60 轮的成本是微秒级的而少跑几轮带来的精度不足会在后续计算里被放大。还有一个更隐蔽的坑eps 取太小反而有害。如果 eps 设成 1e-15 而你的判断函数本身带 1e-3 量级的噪声那么二分会在噪声里反复横跳最后停在哪儿完全随机。精度的下限应该由你的测量精度决定而不是由浮点数的表示能力决定。这一点我在调一个温度控制参数时吃过亏设了 1e-9 的精度结果每次跑出来的最优值都不一样后来发现是传感器本身只能到 0.1 度把精度改成 0.01 立刻就稳定了。2.4 二分答案把求最大翻译成能不能这是二分法里最有价值的一个技巧也是很多人没想到的用法。它的思路是当你要求让某个量最大或最小时不要去直接搜索这个量而是反向构造一个判断题给定一个候选值 x能不能做到至少 x 如果这个判断题的答案随 x 增大而从能变成不能那就又回到了单调区间直接二分。举个具体的例子。假设你要给批处理系统定一个吞吐目标问最多能稳定跑到多少这本来是个优化问题。但你换个问法如果目标是 1100能不能做到这个问题可以靠一次实际压测来回答是个布尔值。目标从 500 提到 1100 能提到 1300 不能中间必然有个分界二分 40 次就能把分界锁到 1 以内。整个过程你不需要知道吞吐和参数的函数关系只要有一个能回答能不能的黑盒。这个技巧的威力在于它把优化问题降级成了可行性问题。可行性判断往往比优化容易得多你不需要找最优配置只需要验证某个配置行不行验证完之后就可以扔掉不需要保存状态。我在做容量规划的时候经常用这招因为真实的容量模型根本写不出解析式但跑一次看能不能扛住是随时可以做的。注意二分答案的前提是可行性这件事本身必须是单调的。如果存在某个 x 可行、x1 不可行、x2 又可行的情况工程上这很常见比如缓存命中率导致的非线性那二分出来的结果是没有意义的只能说明你在某个点上失败了。3. 方法二三分法与黄金分割专治最低的那个坑如果说二分法是找线三分法就是找点。它的适用场景是你手上有一条先升后降或先降后升的曲线想找到那个转折的位置。这类问题在参数调优里极其常见因为绝大多数资源投入都有边际收益递减的特性。3.1 单峰假设三分法成立的前提三分法的做法是把区间三等分得到两个内点 m1 和 m2比较它们的函数值。如果 f(m1) f(m2)说明峰值一定不在 m1 左边因为从 m1 到 m2 还在上升于是把左边界推到 m1反之把右边界拉到 m2。每轮区间缩为原来的 2/3。这个推理成立的前提只有一个区间内函数是单峰的也就是只有一个局部最大值两侧单调下降。如果有两个峰三分法会比较出左边那个峰比右边那个峰矮然后把包含左峰的一大段区间扔掉最终收敛到右峰——但这不代表右峰是全局最优可能区间外面还有更高的峰。这就是三分法最典型的失败模式它不报错只是安静地给你一个局部解。怎么确认单峰我的做法是在正式上三分之前先在整个候选区间上均匀采样 10 到 20 个点把值打印出来看一眼。如果序列是先升后降、中间没有回头那就基本可以放心。如果看到两次起伏说明有多个峰这时候要么缩小候选区间只保留一个峰要么改用别的策略比如先粗采样定位最高的几个区间再分别在每个区间内三分。还有一种特殊情况要注意平台。如果一段区间内函数值完全相同比如参数从 60 到 70 出来的指标一模一样这在不敏感的配置上很常见那 f(m1) 和 f(m2) 可能相等。这时候你随便选一边收缩都行但要注意别因为相等判断写错而让区间不缩小。我在实现里习惯把相等的情况统一归到收缩右边界那边保证每轮一定前进。3.2 浮点三分的稳妥实现def ternary_max(lo, hi, f, iters200): for _ in range(iters): m1 lo (hi - lo) / 3.0 m2 hi - (hi - lo) / 3.0 if f(m1) f(m2): lo m1 else: hi m2 return (lo hi) / 2几个细节值得说明。m1用lo (hi-lo)/3而不是(2*lo hi)/3是为了避免大数相加溢出虽然 Python 不在乎但换成 C 或者 Go 的时候这个习惯能救命。iters同样写死次数而不是用 eps 判断理由和二分法一样。迭代次数怎么定每轮缩为 2/3要缩到 eps 需要 n ≥ log(eps / L) / log(2/3)。代入具体数字区间长度 500目标精度 0.01需要 n ≥ ln(2e-5) / ln(0.667) ≈ 26.7取 27 轮。我一般直接写 200 轮图个省心。三分法的求值次数是每轮 2 次200 轮就是 400 次函数调用。如果你的单次求值要跑一分钟压测那就是 400 分钟不可接受。这时候就必须换黄金分割法。3.3 整数三分的陷阱参数是整数时比如线程数、批大小三分法会出问题区间很短时m1和m2可能算出来是同一个数此时比较结果没有意义区间也不会缩小直接死循环。我的处理方式是让循环在区间还比较长的时候就用三分收缩等区间短到 4 以内直接暴力枚举。这样既保住了三分的收敛速度又绕开了边界麻烦def ternary_int_max(lo, hi, f): while hi - lo 4: m1 lo (hi - lo) // 3 m2 hi - (hi - lo) // 3 if m1 m2: # 兜底理论上到不了 break if f(m1) f(m2): lo m1 else: hi m2 return max(range(lo, hi 1), keyf)这里有个容易被忽略的细节整数三分的收缩不能像浮点那样直接lo m1因为 m1 那个点已经被比较过了它不可能是最终答案吗不一定。如果 f(m1) f(m2)我们知道峰值在 m1 右侧但 m1 自己是被排除的可以安全地lo m1吗不能因为峰值可能恰好就在 m1 上只是 m1 和 m2 中间有一段缓坡。稳妥起见写lo m1保留让暴力收尾解决。写成lo m1 1有概率漏掉正确答案这个 bug 极其难调因为只在你数据恰好卡在边界时才会触发。3.4 黄金分割为什么是 0.618为什么它更省黄金分割法解决的就是每次求值太贵的问题。它的核心洞察是三分法每轮要算 2 个新点但下一轮的区间里其实有一个点可以复用。只要内点的位置选得巧让每次收缩后旧的某个点刚好落在新的位置上就能做到每轮只需要 1 次新求值。这个巧的位置就是 0.618。推导不复杂设区间长 1左内点在 x 处要求收缩一次后剩下区间的内点位置比例不变。解方程 x² 1 - x 得到 x (√5 - 1) / 2 ≈ 0.618。这意味着每轮收缩到原来的 0.618同时新点里有一个是旧点只需要再算一次函数值。GR (5 ** 0.5 - 1) / 2 # 0.6180339887 def golden_max(lo, hi, f, iters100): c hi - GR * (hi - lo) d lo GR * (hi - lo) fc, fd f(c), f(d) for _ in range(iters): if fc fd: lo, c, fc c, d, fd d lo GR * (hi - lo) fd f(d) else: hi, d, fd d, c, fc c hi - GR * (hi - lo) fc f(c) return (lo hi) / 2算一笔账对比一下。区间长度 500目标精度 0.01方法每轮收缩比所需轮数每轮求值次数总求值次数标准三分2/3 ≈ 0.66727254黄金分割0.618301首轮 2 次31二分若能构造判断题0.516116可以看到黄金分割虽然轮数比三分多一点点但总求值次数几乎只有一半。当一次求值要花几分钟的时候这个差距就是几十分钟。所以我的默认选择是只要能构造出数值比较优先用黄金分割三分法只作为理解原理的入门版本。3.5 噪声数据怎么办真实的测量一定带噪声。如果你的指标是压测出来的吞吐同一配置跑两次可能差 3%这时候直接上三分会出大问题函数值比较的噪声可能大于两个内点的真实差异导致收缩方向判断错误把最优区间扔掉了。处理办法有三个按成本从低到高。第一个是重复测量取中位数每个点跑 3 次取中间那个值能压掉大部分偶发抖动。第二个是平滑在评估函数里对邻近的几个参数值做加权平均相当于人为把曲线抹平代价是分辨率下降。第三个是降低精度预期把目标精度从 0.01 放宽到 1让算法在粗粒度上收敛因为噪声数据本来也支撑不了细粒度结论。我自己的默认配置是每个点测 3 次取中位数目标精度按参数的 1%来设。比如批大小在 1 到 512 之间精度就设 5不设 0.01。这个做法听起来粗糙但结果稳定可复现比追求高精度却每次跑出不同答案有用得多。4. 实操用两种方法给一个参数找平衡点光讲原理容易飘这一节用一个完整的模拟场景把两种方法串起来跑一遍。场景是虚构的但数值关系的构造方式来自常见实践你可以把里面的函数换成自己的评估逻辑。4.1 先把场景和曲线说清楚假设某团队在调一个批处理服务的批大小参数候选范围是 1 到 512。观察到的规律是批太小每次的调度开销占比高吞吐上不去批太大内存压力上来垃圾回收变频繁吞吐也会掉。用一条单峰曲线来近似这个关系import random def throughput(batch, noise3.0): 模拟吞吐batch64 附近最优向两侧衰减 ideal 1200 * pow(2.718281828, -0.00008 * (batch - 64) ** 2) return max(0.0, ideal random.uniform(-noise, noise))在 batch64 时理想值是 1200batch164 时约 539batch1 时约 900。这条曲线在 [1, 64] 上单调递增在 [64, 512] 上单调递减全局单峰正好可以用来演示两种方法。现在有两个需求。需求一找出最小的能满足吞吐不低于 1000 的批大小这是给线上定起步值用的。需求二找出吞吐最高的批大小这是给压测定最优值用的。前者是临界线问题走二分后者是最优点问题走黄金分割。4.2 用二分法求达标线先确认 [1, 64] 区间内判断函数是单调的吞吐随 batch 增大而增大是否 ≥ 1000的结果必然是一串否然后一串是。确认完毕直接套模板。def ok(batch): # 测 3 次取中位数压噪声 samples sorted(throughput(batch) for _ in range(3)) return samples[1] 1000 lo, hi 1, 64 ans first_true(lo, hi, ok) print(ans, throughput(ans))跑下来ans落在 51 到 54 之间因为噪声每次略有不同。验算一下1200 × e^(-0.00008 × (52-64)²) 1200 × e^(-0.0115) ≈ 1186超过了 1000说明理论上分界点应该更靠左。问题出在我的模拟函数在低 batch 区间下降得不够快导致 1000 这条线在很靠左的位置就被越过了。这正好演示了一个真实的坑结果和预期不符时先怀疑模型再怀疑算法。我把系数从 0.00008 调到 0.0006 再跑一次def throughput(batch, noise3.0): ideal 1200 * pow(2.718281828, -0.0006 * (batch - 64) ** 2) return max(0.0, ideal random.uniform(-noise, noise))batch52 时理想值约 947batch56 时约 1054那么分界点应该在 54 左右。再跑二分结果稳定落在 54 到 55和手算吻合。整个二分只用了 6 轮区间长度 64精度要求 1log2(64) 6每轮 3 次求值总共 18 次比自己从 1 到 64 逐个扫快得多。这里有个实操建议二分的上下界要选得一真一假。下界必须让判断为假上界必须让判断为真否则返回值没有意义。我习惯在正式二分前先测一下两个端点打印出来看一眼这两次额外的求值能省掉后面一大堆排错时间。4.3 用黄金分割求最优点最优点在 [1, 512] 全区间内单峰满足前提。上黄金分割best golden_max(1, 512, throughput, iters80) print(best)跑出来best在 63.5 到 65.2 之间跳动取决于噪声。真实最优点是 64误差在 1 以内完全够用。80 轮迭代首轮 2 次求值之后每轮 1 次总共 81 次求值再加上每次内部测 3 次取中位数实际调用 243 次。如果换成标准三分需要 n ≥ ln(1/512) / ln(2/3) ≈ 15.4 轮达到精度 1取 20 轮每轮 2 次求值 40 次。咦怎么三分反而更少因为这里的精度要求很粗精度 1区间 512只需要十几轮。这提醒了一件事黄金分割的优势在精度要求高时才明显。精度要求 0.01 时黄金分割 30 轮 × 1 次 31 次三分 27 轮 × 2 次 54 次差距才拉开。所以选哪种要看你的精度需求不能一概而论。4.4 两种方法的结果对账把两个结果放在一起看很有意思。二分告诉我们至少要到 54吞吐才能过 1000。黄金分割告诉我们最优在 64 附近能到 1200。这两个数字组合起来就形成了一个决策依据——配置不能低于 54否则不达标配置在 64 附近最划算配置超过 80 之后性能掉得很快batch80 时理想值约 1012已经接近下限了。三条信息合起来才是完整的平衡点认知单独看任何一个都不够。方法回答的问题结果求值次数用途二分法达标的最小值是多少54约 18定配置下限黄金分割最优值在哪儿64 附近约 243定推荐配置直接采样对照曲线大致形状—20验证单峰前提注意最后一行那个直接采样它才是我实际工作的第一步。花 20 次求值把趋势画出来确认单峰、确认单调区间再决定用哪种方法。这 20 次投入看着浪费但它能防止你在一个双峰曲线上白跑几百次迭代。4.5 踩坑记录这一路跑下来实际踩到的坑比我预想的多。最典型的一个是噪声导致的二分不稳定第一版没有取中位数直接单次测量结果同一个输入跑两次得到不同的分界点差了 3 个 batch。加上三次取中位数之后立刻稳定。第二个是初始区间选错。一开始我把二分的右边界设成了 128而实际分界点在 54虽然结果碰巧是对的但如果分界点跑到 128 以外程序会安静地返回 128让你以为那是答案。后来我加了一条断言正式搜索前先校验ok(hi)必须为真不满足就直接报错把问题暴露在最早的时刻。第三个是黄金分割的轮数和精度没对上。我一开始设了 20 轮结果精度只有 512 × 0.618^20 ≈ 0.0003看着很高但因为噪声是 ±3实际上结果在 5 个单位内乱跳。把轮数降到 15 轮、同时对每个点取中位数之后结果反而更稳。这印证了前面那句话精度不该超过你的测量能力。5. 常见问题与排查速查表这一节是我这些年攒下来的排错清单按方法分类整理。遇到结果不对的时候从上往下逐条对基本能在十分钟内定位。5.1 二分法出问题时先看这三处第一种症状程序卡住不动。九成是lo的更新写成了lo mid。判定方法很简单在循环里加一句打印看区间长度是否每轮都在缩小。如果某轮之后长度不变就是这里的问题。改成lo mid 1立刻解决。第二种症状结果比正确答案小 1 或大 1。这是边界语义没对齐。先问自己我要的是第一个满足条件的还是最后一个满足条件的前者用first_true模板后者用first_true找第一个不满足的再减 1。这两种需求对应的更新方式完全不同混用必错。第三种症状结果随运行次数变化。判断函数带噪声单调性被破坏。解决办法是给判断函数加去噪多次取中位数或者给阈值留出余量。不要去改二分本身改不动。还有一种不常见但很坑的情况区间上界本身不满足条件。这时候first_true会返回hi看起来像找到了答案实际上是没找到。加一条前置断言能立刻发现。5.2 三分法/黄金分割出问题时先看这三处第一种症状收敛到的位置明显不是最优。先怀疑单峰前提不成立。把候选区间均匀采样 20 个点打印出来如果看到两个峰那就是前提崩了。处理方式是缩小范围或者分段处理。第二种症状每轮收缩幅度不够跑了很多轮还在大范围晃。检查内点公式。m1和m2必须是lo (hi-lo)/3和hi - (hi-lo)/3如果两个都写成从lo出发加同一个偏移内点会重合区间不缩。第三种症状结果在最优值附近大幅抖动。噪声问题同二分法。取中位数、降低精度预期、增加平滑三选一或组合使用。第四种症状黄金分割专属复用点算错。收缩之后旧点要正确搬移c和d的角色会互换。写错的表现是结果偏差很大且不收敛。建议第一次实现时把每轮的lo, hi, c, d都打印出来肉眼核对两三轮确认逻辑无误后再去掉打印。5.3 问题排查速查表症状大概率原因处理动作二分死循环lo mid未加 1改成lo mid 1二分结果差 1边界语义混用明确第一个满足还是最后一个满足二分结果随机判断函数有噪声多次取中位数阈值留余量二分返回上界上界本身不满足条件加前置断言校验端点三分收敛到次优区间内多峰采样画趋势缩小或分段三分不收敛内点公式写错核对lo(hi-lo)/3形式三分结果抖动测量噪声大于内点差异降精度、取中位数、平滑黄金分割偏差大复用点搬移错误打印每轮四点核对整数三分死循环区间过短导致内点重合短区间改暴力枚举全部方法都失效评估函数本身不稳定先修评估再谈算法注意这张表里出现频率最高的一条是评估函数本身不稳定。我遇到过的所谓算法 bug大概有三分之一最后查出来是评估逻辑写错了比如统计口径不一致、缓存没清、并发没隔离。所以在怀疑算法之前先确认同一个输入跑两次能得到同一个输出。5.4 几条只有踩过才知道的经验第一条先采样再搜索。这一步花的时间不到总时间的 5%但能避免 80% 的方向性错误。我现在的固定流程是均匀采样 20 个点 → 打印趋势 → 判断是单调还是单峰 → 确认区间 → 才上算法。第二条给每次求值打日志。记录输入、输出、时间戳。出问题的时候这份日志能让你在一分钟内还原现场而不是靠猜。日志量不大几百行而已但它是我调试这类问题最快的手段。第三条精度目标跟着业务走不跟着数学走。参数精度到 1 就够用的场景别设 0.001。你多花的那几十轮迭代换不来任何业务价值只会换来更多噪声。第四条两种方法可以嵌套。先用黄金分割找到最优点再用二分法确定距离最优点多远仍然满足最低要求这样能得到一个可接受的配置区间而不是一个孤零零的点。工程上给的是区间不是点这一点很重要。6. 把这套思路迁移到非数值场景这两种方法的价值不只在数值计算上它们的思维方式可以迁移到很多看起来不相关的场景。我把这部分放在最后是因为它更偏经验但用起来确实顺手。二分法的本质是用判断代替计算。当你面对一个说不清多少合适的问题时试着把它改写成这样行不行。比如评估一个方案能不能上线与其纠结它有多好不如问它是否满足最低要求后者往往有明确答案而且能快速排除掉一大半选项。三分法的本质是承认边际收益递减。绝大多数投入都不是越多越好投入和产出之间有一条先升后降的曲线。意识到这一点你就会在加资源之前先问一句我现在在曲线的哪一侧而不是默认更多就是更好。黄金分割法的本质是复用已有信息。每次评估都很贵的时候想办法让上一次的结论在下一轮还能用这个思路在实验设计、A/B 测试、甚至日常的方案评审里都成立。最后分享一个我自己的习惯不管是哪种方法我都会把区间和精度这两个数字先写在纸上再去写代码。区间决定了下界和上界是否覆盖了真实答案精度决定了要跑多少轮。这两个数字一旦定死剩下的就是套模板几乎不会出错。反倒是那些上来就写循环、边跑边调区间的人最后往往要在死循环和错误答案之间反复横跳。

参数调优找平衡点：二分法、三分法与黄金分割工程实践

相关推荐

二分法与牛顿迭代法：平衡点求根的工程实践与避坑指南

收藏夹里的良心网站为何总失效？71个名额的筛选与维护策略

OpenAI暂停训练背后：智能体失控风险与AI安全落地指南

更多资讯

JS逆向-某招标网站des分析

DUBBO注册信息

allure报告相关笔记

常用办公网站

sd-webui-controlnet 图像生成控制：一张实拍图重绘成动漫插画

C语言DOS游戏开发实战：Turbo C图形编程与现代移植

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？