審核、打分與分級規格

日期：2026-03-20 目的：定義 invoice_name_cluster -> SI 的審核流程、候選打分、金銀銅分級、AI 與眾包介面，以及最小 API 契約。 相關文件：

• C02-spec.md
• C03-schema.sql
• C10-cases.md
• R02-terms.md

1. 核心原則

審核流程真正要決定的不是某筆通路資料真不真，而是：

這個 invoice_name_cluster 應該對到哪個 SI

所以：

1. 審核單位是 invoice_name_cluster
2. barcode、圖片、通路資料、crowd 回報都只是證據
3. 打分的目的是縮小候選，不是取代審核
4. 金銀銅分級是成熟度，不是身份

2. 審核佇列的最小單位

每個 queue item 至多呈現 2 到 5 個候選 SI，至少要附上：

1. cluster_id
2. merchant_code
3. channel_code
4. store_tax_id
5. representative_pn
6. line_count
7. invoice_date_range
8. brand_hint
9. category_hint
10. candidate_count
11. top_candidate_score
12. review_reason
13. current_mapping_tier

3. 候選打分規則

3.1 建議特徵與權重區間

3.2 Veto 規則

命中以下任一條件，就不應直接 auto_confirm：

• 200 prefix
• 978/979 prefix
• 全零或 placeholder 條碼
• 明確 bundle / carton 文案，卻去支持 unit 候選
• 發票日期落在條碼有效期外
• 兩個互斥候選同時拿到高權重證據

3.3 放行門檻

auto_confirm 建議同時滿足：

• 總分 >= 85
• 與第二名差距 >= 12
• 沒有 veto
• 沒有高風險來源單獨主導

其他情況：

• 60 到 84：進人工審核
• 低於 60 或命中高風險條件：隔離或補證據

3.4 來源先驗

先驗可分三層，但不能取代其他證據：

• 低風險：pxmart_mega、pxgo、tomods、jpmed、homeda、weixinrx、matsukiyo
• 中風險：pxbox、dingding、rakuten、angelbaby、treebuy、costco、babyez
• 高風險：ckcare、yourchance、rakuten-amart、cosmed

3.5 品牌、品類、時間與店點的角色

• brand：高權重提示，不是唯一真值
• category：候選過濾與 sanity check
• store_tax_id：很適合同商家內消歧
• 時間：對條碼重用、包裝改版、通路誤貼很重要

4. 金級、銀級、銅級分級

4.1 兩種 tier 的差別

• mapping_tier：invoice_name_cluster -> SI 這條對應有多可靠
• item_tier：BI / SI 本身成熟到什麼程度

4.2 mapping_tier 標準

4.3 item_tier 標準

4.4 誰可以標什麼

4.5 實務操作原則

1. 清整時先標 mapping_tier
2. 新建 BI / SI 時，item_tier 先預設為 銅級
3. 眾包一致不等於直接金級
4. AI 不確定時應停在低級別並要求人工

5. 狀態機與決策類型

5.1 狀態機

open
  ↓
shortlisted
  ↓
under_review
  ↓
confirmed / rejected / needs_more_evidence / create_new_item

5.2 決策類型

• confirm_candidate
• reject_all
• needs_more_evidence
• create_new_item

6. 審核畫面最小需求

左側
- 代表發票名稱
- 同群組別名
- 商家 / 通路 / 統編
- 出現次數
- 日期範圍

中間
- 候選 A / B / C
- 候選名稱
- item_level
- 品牌 / 品類 / 規格
- package_form 與 net_content
- 主要 barcode
- 主要圖片
- 支持與衝突證據摘要

右側
- 確認候選
- 全部駁回
- 需要更多證據
- 新建商品

審核者至少要同時看到：

• 名稱與別名
• 品牌與品類提示
• item_level
• 容量與入數
• barcode 證據
• 圖片證據
• 通路、店點、時間範圍
• 候選的 item_tier
• 目前建議的 mapping_tier

7. AI 與眾包規格

7.1 AI 輸出格式

AI 或規則引擎若要提議分級，最少應輸出：

{
  "target": "mapping_tier",
  "label": "silver",
  "reasons": [
    "名稱相似度高",
    "容量與 item_level 一致",
    "同商家歷史對照支持"
  ],
  "blocking_flags": [],
  "needs_human_review": false
}

7.2 AI 禁止規則

遇到以下情況，AI 不應硬給 金級：

• 只有單一來源
• 命中 200、978/979、全零碼
• 同一條碼同時支持 unit 與 bundle/carton
• 候選分數太接近
• 發票名稱過短，例如只有 可樂、雞精、衛生紙
• 時間衝突未解

7.3 眾包任務類型

眾包不應自由上傳大雜燴，應只做候選確認任務：

1. candidate_confirm
2. barcode_confirm
3. image_confirm
4. new_item_triage

7.4 眾包禁止規則

眾包不應直接做這些事：

• 輸入最終商品代碼
• 自己宣告金級、銀級、銅級
• 自己新建正式商品

7.5 眾包結果怎麼換算成 tier

• 多數人都選 無法判定：保持 銅級
• 大多數人選同一候選，但仍有少量分歧：可升 銀級
• 多輪任務都穩定選同一候選，且和其他證據一致：可提議升 金級

但系統仍須再檢查：

• 風險 prefix
• 組合包污染
• 時間衝突
• 來源衝突

8. API 介面

8.1 GET /review/clusters

用途：取得待審核 cluster 清單。

查詢參數：

• merchant_code
• status
• limit
• cursor

回傳範例：

{
  "items": [
    {
      "cluster_id": 123,
      "merchant_code": "PXMART",
      "channel_code": "PXMART_ONLINE",
      "store_tax_id": "12345678",
      "representative_pn": "白蘭氏雞精6入",
      "line_count": 87,
      "invoice_date_range": ["2025-01-01", "2026-03-01"],
      "candidate_count": 3,
      "top_candidate_score": 0.93,
      "review_reason": "close_candidates",
      "current_mapping_tier": "bronze"
    }
  ],
  "next_cursor": "abc123"
}

8.2 GET /review/clusters/{cluster_id}

回傳至少應包含：

• cluster 基本資料
• 候選清單
• 每個候選的支撐與衝突證據
• 風險旗標
• 候選的 item_tier
• 目前建議的 mapping_tier

8.3 POST /review/decisions

請求範例：

{
  "cluster_id": 123,
  "decision_type": "confirm_candidate",
  "candidate_id": 1001,
  "reviewer": "alice",
  "mapping_tier": "silver",
  "decision_note": "名稱、容量、通路與歷史資料一致"
}

8.4 POST /crowd/tasks

請求至少應包含：

• task_type
• cluster_id
• candidate_ids
• question_text

9. 最小實作建議

1. 先做 rule-first 版本，不要一開始就做黑盒模型
2. 所有加分、扣分、降級都要能解釋
3. 每次審核結果都要能回寫成下一輪候選生成的歷史證據

10. 一句話收尾

這份文件現在同時負責審核流程、候選打分與金銀銅分級。
真正目標只有一個：替每個 invoice_name_cluster 選出最合理的 SI。