别再凭直觉选参数：系统扫描找到最优点

看曲线的形状，而非单点——一个叫做 Sweep 的习惯

阈值、图像分辨率、批量大小——这些参数大多都是凭直觉选择的。试一两个，选看起来效果最好的那个。

从验证成本大幅下降的那一刻起，我就停止了这样做决定。我不再选择单个点，而是从头到尾扫过整个范围，观察曲线的形状。甜蜜点、膝点、陡崖——这些都要在你测量整个形状后才会显现。单个数据点什么都看不出。

而能否进行 Sweep，核心取决于验证有多便宜。当一次运行成本很高时，人们就会退而求其次，凭直觉决策。所以第一步是降低验证成本——这比什么都重要。

工程实践中到处都是魔法数字（代码里满是具体数值，但却没有明确的理由支撑）。阈值、图像分辨率、批量大小、超时。你怎么决定这些参数？说实话——通常是凭直觉。最多试一两个值，选看起来效果最好的那个。

当这套系统把验证成本降低了一个数量级时，我就改变了做法。与其选择单个点，我开始从头到尾扫过整个范围，观察曲线的形状。这就是一个 Sweep。

曲线能告诉你单个点看不到的东西

拿 OCR 文本检测时使用的图像分辨率举例。"分辨率越高准确率越高"——直觉告诉我们这样。所以如果你凭直觉走，会毫不犹豫地选更高的分辨率。

但当我在一个范围内改变分辨率，同时测量准确性（CER，越低越好）和处理速度时，得到了这样一条曲线。

图 1：分辨率扫描曲线。x 轴是延迟，y 轴是错误率。736 是速度和准确度的甜蜜点：相比 960，错误率只增加 1.3 个百分点（9.4% → 10.7%），而速度快了一倍。降到 480，准确度急剧崩溃（错误率从 10.7% 跳升到 35% —— 增加了三倍多）。曲线的拐点——膝点——恰好在 736。注：n=6，样本量较小 = 方向性验证。

中间的 736，是显而易见的"甜蜜点"。相比 960，错误率仅增加 1.3 个百分点（9.4% → 10.7%），而处理速度快了一倍。如果降到 480，准确度就会崩溃（错误率从 10.7% 暴升到 35% —— 增加三倍多）。曲线的拐折——膝点——恰好在 736。

如果我凭直觉选了 960，就得继续付出两倍的时间来换取一点点准确率的提升。如果选了 480，文本根本读不清。这个甜蜜点只有在我同时测量了两端和中间之后才变得清晰可见。仅凭一个数据点，你永远找不到它。

还有一样只有曲线才能揭示的东西：膝点——那个超过它就基本看不到进一步改进的折点。

当我扫描阅读理解准确率如何随着训练数据增加而上升时，在困难案例上，准确率在超过某个数据量后就平了（一个非常小的量级）。无论你再添加多少数据，难的情况都不会改进。过了膝点，投入就浪费了——这是一个信号，说明真正需要的是另一个杠杆（比如模型容量）。

这个也是从一两个数据点看不出来的。只有当你画出整条曲线，才能看到"这里之外什么都不起作用"的边界在哪。

为什么现在 Sweep 成为可能

Sweep 是一个老想法。但也许在实践中没有那么多人真正彻底地做。原因很简单：太贵了。手工尝试十一个阈值意味着需要十一次验证运行。这个数字足以让人怀疑自己的理智。

改变来自于这套系统从验证过程中移除了人的参与。一旦你把帧序列烤到磁盘上，就能并行运行十一个不同的配置，完全无需手动操作。之前需要一个人拿着设备，每个配置手工录一次，现在一切都在一个批次中完成。从验证成本下降的那一刻，"扫描整个范围看曲线形状"就比"凭直觉选单个点"更可靠、更划算。Sweep 是我为这套系统的效率提升找到的第一个应用。

不要凭直觉设置魔法数字。阈值、分辨率、批量大小——大多数情况下，这个特定的值没有理由非要是这样。

扫描整个范围，看曲线，而不是单个点。甜蜜点和陡崖只有在你测量了完整形状后才会显现。特别是膝点——那个"超过这里就什么都改进不了"的折点——是切换到另一个杠杆的信号。

能否进行 Sweep 取决于验证有多便宜。当单次验证运行成本很高时，人们就会回到凭直觉决策。所以先降低验证成本。之后，Sweep 就成为显而易见的选择。

下期：当你同时对多个目标（速度 × 准确度 × 成本）观察那片扫描点云时会看到什么——走向 Pareto。扫描和读取前沿是同一枚硬币的两面。

最初发布于 LYR Performance Note #021 —— 系列"测量与调优——正确地测量，然后拟合设置"的一部分。完整集合见 lyr.jp/en/research。