配方回测

Recipe Backtesting 让你通过活动配方回放一组经过筛选的图像，并逐图获得客观的性能报告。它会对完整配方、每个模型、每条 Node-RED 规则、每个通过/失败阈值进行运行，因此输出将准确反映生产将如何执行。

把它视为你 vision 配方的回归测试套件。

为什么重要

在 Backtesting 之前，验证配方变更的唯一方式是等待新部件沿生产线下线。使用 Backtesting，您可以保留一个永久库，包含复杂捕获样本，在几秒钟内对新配方进行全面测试，并将旧运行与新运行并排比较。客户认可将成为一个客观的对话，而不是凭直觉判断。

学习目标

在本指南结束时，您将能够：

• 构建一个具有代表性图像的 test set，并带有通过/失败的地面真值标签
• 对活动配方运行一个 backtest，并读取混淆矩阵
• 深入分析 escapes and overkills 以诊断问题所在
• 按标签、生产线或捕获周对良率结果进行分组，以捕捉模型漂移
• 通过 HTTP 触发 backtest 运行，以实现计划或 CI 风格的自动化

核心概念

Recipe Backtesting 有两个组成模块。它们位于左侧导航中的 Recipe Backtesting 条目之后。

概念	定义
Test Set	一个可重复使用的 JPEG 集合及其地面真值标签。测试集独立于任何特定配方，相同的测试集可以对不同的配方或同一配方的不同版本进行运行。测试集可以导入、导出，并在相机之间共享。
Backtest Run	对一个测试集在当前活动配方上执行的时间点快照。运行是不可变的，后续对测试集重新标注不会改变先前运行的结果。

创建测试集

从左侧导航，打开 Recipe Backtesting → Test Sets，然后点击 Create Test Set。为其命名并添加描述，描述将可搜索并显示在运行报告中。

创建后，测试集在编辑器中打开，但尚无图像。标题栏包含以下关键操作：Add Images、Import from Library（在“Add Images”下拉中）、Export，以及 Start Backtest（在测试集有图像之前处于禁用状态）。

添加图像

填充测试集有两种方式：

1. Click or drag JPEG images into the upload area. Only JPEG is accepted, and every image must match the camera's capture resolution exactly.
2. Import from Library, the faster option for production cameras. This pulls previous captures directly off the camera with all their embedded metadata intact (capture time, trigger ID, original pass/fail, tags, inspection target).

The Import from Library dialog lets you filter by capture number, trigger ID, capture date range (5m / 30m / 1h / 12h / 1d shortcuts), notes, recipe name, pass/fail, and an Advanced Filters panel for inspection target / region / search area. The Include Trainset Images toggle is on by default. The Alignment Fails Only toggle is useful when you are specifically verifying an aligner fix.

Production captures carry their history

Images brought in from the Library retain the camera serial number, original capture time, the recipe version that produced them, and the full JSON metadata of the original production result. That means you can reuse the original pass/fail as the ground truth rather than re-labeling from scratch. You can also correct it if standards have changed since.

After import, the editor shows the images with a quick summary (image count, ground-truth count, total size) and a Test Set Distribution breakdown by capture week and system name.

标注 Ground truth

Ground truth 是每张图像的真正通过/失败判定，即您，操作员，认为结果应该是什么。Ground truth 是使得准确性、Escape 与 Overkill 指标成为可能的基础。

单击图像以打开 Image Viewer。若图像来自生产捕获并已导入，原始的 search areas 和通过/失败结果已可用，您可以复用或更正它们。若图像没有嵌入元数据（例如较旧的导出、手动上传），请单击 Set Up Labeling 将图像与 currently active recipe 的 search areas 关联起来。

一旦图像完成链接，每个 search area 将获得自己的 Pass / Fail / Unknown 单选按钮。若不确定，请将某个 search area 保留为 Unknown，这些行不会计入准确性计算，但仍会对总体产量产生贡献。

每个搜索区域独立标注

如果你的配方在一个部件上有三个搜索区域，测试集中每张图像都需要 三个 ground truth labels，每个区域各一个。右侧统计区分 Images（捕获次数）与 Ground Truth Labels（标注的搜索区域数）。

你也可以为每张图像添加一个 description（关于此捕获的要点）和 tags（行号、位移、缺陷类型等）。Tags 可在运行报告中搜索，并可用于对产量分解进行分组。

开始回测

一旦测试集至少包含一张图像，请单击 Start Backtest。为此次运行命名。相机会：

1. Pause any active inspection，在运行期间将忽略传入触发。
2. 遍历测试集中的每张图像。
3. 对每张图像执行 entire 当前活跃的 recipe（包括每个 Node-RED 节点、每条 pass/fail 规则，以及该配方在生产环境中通常驱动的任何执行或 I/O 集成）。
4. 将每个结果存回 Library 与 Haystack，完全就像实际生产捕获一样。

Backtests fire the same I/O as production

因为运行会执行完整的 recipe，每个 Node-RED 输出节点 实际触发、Modbus 写入发生、MQTT 消息发布、HTTP 调用发出。请勿在连接到实时生产线的摄像头上运行 backtests，除非你已准备好应对这些副作用。理想情况下，在第二台专用于验证的摄像头上运行 backtests。

读取运行报告

运行是永久性的。打开 Recipe Backtesting → Backtest Runs 以查看每一次历史运行，按测试集筛选，并打开任意一条。

运行报告分为三部分：混淆矩阵、产出报表，以及逐图像 drill-down。

混淆矩阵

	Ground Truth: Pass	Ground Truth: Fail
Recipe: Pass	True Positive	Escape
Recipe: Fail	Overkill	Correct Reject

• True Positive，配方和 ground truth 在通过方面达成一致。你需要这个。
• Correct Reject，配方和 ground truth 在失败方面达成一致。你也希望看到这个。
• Escape，配方显示通过，但图像实际有缺陷。这几乎总是最严重的失效模式，意味着有不良部件离开了生产线。
• Overkill，配方显示失败，但图像其实为良品。这是误拒绝：生产线正在丢弃良品。

点击任一单元格即可将图像列表筛选为仅包含这些捕获，随后点击图像即可跳转到其 Library 条目，并显示完整的 Haystack 跟踪。

Escapes 和 Overkill 都是症状，修复方法不同

Escapes 通常意味着模型漏检了缺陷，或 Node-RED 阈值设置过于宽松。Overkill 通常意味着阈值过于严格，或训练集偏向困难的阳性样本。混淆矩阵会告诉你哪种故障是主导；优先修复那一个。

良率与循环时间

运行头部显示整体良率（通过总数 / 捕获总数）以及 平均循环时间，其定义为总运行时长除以图像数量。这是相机能够实现的最精确的循环时间估计，因为它运行的是与生产相同的 Node-RED 流。

按标签或系统的良率分解

The Yield Report → Advanced Distribution 视图按标签或系统（生产线）分组良率。这可以帮助你发现总体数字隐藏的两类问题：

• Line bias，第 37 行显示 98% 的良率，第 59 行显示 40%。你的训练集可能在第 37 行上过采样。
• Model drift，两个月前的捕获良率正常，但本周的捕获下降。部件已发生漂移，或照明已改变，配方需要刷新。

过滤、标记与导出

标签与描述可让你以实用的方式切分运行报告：

• 按 line-37 过滤，以在将修复推广至其他生产线之前确认修复效果
• 按 defect:crack 过滤，以验证某一特定故障模式现已被捕捉
• 按捕获周过滤，查看配方在近期部件与黄金集上的表现差异

完整的运行报告可以导出为 PDF，以便与客户共享，在验收会议中非常有用，因为客观数字胜过并排截图比较。

使用 HTTP 自动化

Recipe Backtesting 的每个操作都可以通过相机的 HTTP API 调用。常用的自动化模式：

• Node-RED interval trigger，按周计划，Node-RED 将最近 7 天的生产捕获加入滚动测试集并启动一次运行。如果良率低于阈值，则发出警报。
• CI gate，在通过导入端点部署配方版本之前，脚本触发回测并在准确度回落至低于上一版本时阻止部署。
• PLC trigger，PLC 可以在特定 ID 上触发数字输入，Node-RED 捕捉后启动回测。运行完成后，PLC 通过 Modbus 或 Ethernet/IP 将通过/不通过结果回传。

有关 POST /backtest_sets/{id}/runs 端点及相关测试集 CRUD 端点，请参阅相机 Swagger UI 的 API Reference 部分，地址为 http://CAMERA_IP/edge/v2/docs。将 CAMERA_IP 替换为相机的实际 IP。

构建一个良好的测试集

真正能够捕捉到实际回归的测试集与让你产生错误信心的测试集之间的区别在于平衡。

• Pass/fail balance，目标使良样本与不良样本的数量大致相等。一个 95% 通过的集合会让每个配方看起来都很优秀。
• Defect coverage，客户关心的每一种失效模式都需要至少几个实例。如果在测试集中从未见过某一缺陷，就没有证据表明该配方能捕捉到它。
• Time balance，应跨越数周或数月来拉取捕获，而不仅限于今天。生产线会漂移（照明变化、零件更换供应商等），你的测试集应反映这种漂移。
• Line balance，如果配方在 50 条生产线上运行，测试集应包含来自这些生产线的捕获，而不仅仅是你工作台上的那一条。
• Edge cases，那些勉强通过或勉强失败的棘手捕获，是重新训练带来实际收益的地方。用这些示例来丰富测试集。
• Volume，10 张图像足以对变更进行初步回归测试；100 张以上足以做出统计意义明确的准确度断言。

多组测试集以应对演变中的准则

如果客户更改其通过准则，你目前需要逐个重新标注图像。一个实际的解决方法是：保留一个大家共同认可的 stable 测试集，以及一个跟踪演变准则的 current 测试集。当当前准则稳定后，可以将它们合并回稳定集。

今日测试的功能与范围

回测在 完整的 recipe 级别 下运行，并评估最终聚合的通过/不通过输出。也就是说：

• 适用于 Classification、Segmentation、Measurement 和 OCR 的 recipes。任何通过 Node-RED 流向单次通过/不通过的流程均可测试。
• 路线图：模型级回测正在推进。未来版本您将能够在 per-ROI 级别标注真实标签，并直接比较 segmenter 或 classifier 的输出，而无需依赖 Node-RED 阈值。数值输出（例如测量距离、多类别分类）将获得超越通过/不通过的专用指标。

相关资料

• Waterfall Principle
• Improving Models
• Node-RED Basics