配方回測

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