OCR 標籤核對：不可讀文字與錯誤文字

目的與適用邊界

在改動已知的預期答案之前，先查明 OCR 失敗始於來源像素、偵測幾何、辨識器輸出，還是驗證規則。

本教學定義的是一項工程評估，而不是可直接執行的產品認證。目前 Deyi Vision 公開的 PC 範例涵蓋在已確認樣本影像上執行的 EAN-13 工作流程。工程程式碼中的原生 OCR 與偵測部分，使用前必須對照已安裝的執行環境、已綁定的模型和作業進行核查。瀏覽器範本並不能證明可在瀏覽器中執行：規劃中的 OpenCV.js 後端需要另行驗證。雲端辨識必須明確核准所涉及的影像範圍、服務商、模型和費用。評估存檔不是可執行的發布套件。相機、韌體和驅動程式的相容性需要單獨檢查。下列紀錄表中的所有數值均為假設，不是 Deyi Vision 的量測結果，也不是客戶結果。

準備佐證

分別保留原始的窄條邊界案例和正常高度的欄位。每次實驗中預期批號都保持不變。寫出一份失敗紀錄，使另一位工程師無需猜測用的是哪幅影像或哪個版本，就能回放。紀錄中要包括原始來源影像、受影響的區域、實際輸出、預期處置，以及第一個出現偏差的中間結果。要記明該現象出現在回放中、即時取像中，還是兩者都有。修正之後，重新執行原來的失敗案例，以及之前成功的相鄰條件。靠排除某個區域或接受缺失結果來消除一次警報的做法，改變的是要求，而不是解決了原因。如果失敗仍未解決，應讓受影響的操作保持在 Review 或禁止狀態，並寫明原因；不要把未經測試的變通辦法標成已驗證的解決方案。OCR 標籤核對是一項資料完整性任務，而不是在找看似合理的字詞。定義每個欄位、欄位位置、預期字元集、精確比對規則，以及預期值的可信來源。批號欄位、日期欄位和產品名稱可能需要不同的規則。在正規化空白或大小寫之前，先保留文字偵測多邊形和辨識器的輸出。不要悄悄地把 I 替換成 1，或把 O 替換成 0：這會讓錯誤的標籤看起來正確。原始工程佐證中有一個窄條形的 OCR 邊界案例，其結果為 NoResult 或 Review；加大裁切範圍並不能證明辨識已普遍可用。可讀的欄位仍可能是錯誤的批號；而預期值本身正確，也不能成為把它填進不可讀欄位的理由。從最早可觀察到的偏差開始排查。把儲存的同一份來源資料，分別送入未改動的基線和候選方案回放，並比較中間影像、區域、數值和結果狀態。如果來源資料本身不同，這種比較就無法再把問題隔離到演算法上。一次只改動一個懷疑的原因，執行之前先寫下預期的效果；假設不成立時，保留這個否定的結果。要區分不可讀的佐證、規則不相符、缺少相依項目和執行故障；它們需要不同的補救辦法。回放可以重現軟體故障，卻無法驗證即時觸發、照明時序或實體剔除路徑。這些取像和產線檢查要作為獨立的後續實驗另行進行。

操作步驟

1. 更改參數之前，先回放原始裁切圖，記錄 NoResult/Review，不要用預期批號去替代。
2. 比較欄位的實際來源高度、遺失的字元邊距和偵測器多邊形；區分准入階段的拒絕與辨識後的不相符。
3. 先檢視正規化之前的原始文字，並測試易混淆字元，但不要為了硬讓它通過而放寬允許的字元集。
4. 以修正後的取像設定或欄位幾何重新擷取，並作為新的輸入儲存，而不是當作原測試的修復版本。

解讀試驗

已記載的工程邊界使用 160 × 8 的素材，預期為 LOT123；NoResult 或 Review 是如實的結果。160 × 64 的基線並不能證明任意更大的欄位都能正常工作。對窄條影像做填充或拉伸，會改變實驗本身，也無法抹去原來的失敗。

紀錄表

兩種工程視角

故障診斷

• 如果文字只有在把答案輸入給模型之後才變正確，這次實驗就無效。
• 如果多邊形截掉了筆畫，應先修復取像或對映，再去調整字典或比對規則。

驗收與交接

只有在查明最早出現故障的環節、並評估了一次獨立的新取像之後，才可關閉該診斷。要保留原來的邊界結果及其完整分母。

將來源影像、預期判定、確切版本和完整的結果紀錄放在一起保存。在選定最終參數之前，先凍結評估集。如果這些答案之後被用來調整工作流程，就要把該集合標記為開發資料，並另取一套獨立的驗收集。Review、NoResult、執行錯誤和缺漏的取像都要保留在分母中；不要透過篩掉資料列把它們變成合格。可重現的失敗案例要與成功樣品一併保存。交接內容應寫明：誰可以修改配方，如何還原先前獲核准的版本，以及在驗收之前哪些設備輸出保持禁止。僅憑軟體結果，並不能證明移動中的實體工件到達了正確的去向。