Item Master 正式規格

日期：2026-03-19 目的：定義以 發票名稱群組 -> SI 為中心的 item master 架構，並說明既有做法應該如何重新定位。 相關文件：

• C01-eli5.md
• C03-schema.sql
• Q01-channel-qc.md
• Q02-barcode-inventory.md

1. 問題定義

本專案最重要的任務不是單獨建立「barcode 主檔」，而是建立一個能穩定輸出下列結果的系統：

發票名稱群組 -> SI -> BI

其中：

• BI 代表商品家族。
• SI 代表實際可售版本。
• barcode、通路資料、圖片、群眾蒐集都屬於證據來源。

2. 目標與非目標

2.1 目標

1. 把 發票名稱 穩定映射到 SI。
2. 讓 barcode、通路資料、圖片、群眾蒐集成為可追溯的證據。
3. 區分單品、組合包、箱購三種可售層級。
4. 在證據不足時，允許進審核或待補證據，不強迫做錯誤映射。

2.2 非目標

1. 不以逐筆人工審核所有通路網站資料作為主要工作模式。
2. 不把 channel_master 直接當作最終主檔。
3. 不把 barcode 直接定義為最終商品 key。

3. 核心設計決策

3.1 審核單位

主要審核單位是：

invoice_name_cluster -> SI

只有在候選彼此打架時，才回頭追查哪一筆通路證據、barcode 證據或 crowd 證據比較可信。

3.2 兩層身份

• BI：商品家族，例如 白蘭氏雞精、可口可樂、品客原味。
• SI：可售版本，例如 330ml 單罐、6 入組、24 入箱。

發票資料通常應先對到 SI，再視需求往上彙總到 BI。

3.3 barcode 的角色

barcode 的正確角色是：

• item attribute
• evidence link
• 候選召回訊號

它不是唯一身份鍵，原因包含：

• 會有 200 prefix、978/979、全零 placeholder 這類風險碼。
• 同碼可能同時出現在單品、組合包、箱購頁。
• 不同時間點可能有條碼重用或包裝改版。
• 通路網站、人工上傳、群眾回報都可能把碼貼錯商品。
• 即使碼本身合法，也不代表這一筆 Barcode-PN 關聯一定正確。

3.4 為什麼 barcode 很重要，但不能單獨當真相

barcode 的商業價值很高，因為：

• 它是外部世界最常見的商品 key
• 很多下游系統、客戶與合作方都會期待 Barcode-PN
• 它比純名稱更容易跨來源對齊

但它不能直接被當成唯一真相，原因是：

1. barcode 只能證明「有一個碼」，不能自動證明「這筆資料中的碼和商品關聯一定正確」
2. 同一個碼在原始資料中，可能被貼到錯頁、促銷頁、組合包頁或箱購頁
3. 合法的 barcode 仍可能配到錯的名稱、錯的圖片、錯的包裝層級
4. 外部世界交付常用 Barcode-PN，但內部建主檔時若直接以此當唯一主鍵，會把原始污染一起放大

所以：

barcode 很重要
但它應該是高權重證據與交付欄位
不是單獨決定真相的唯一主鍵

3.5 對外交付若需要 Barcode-PN

若對外部客戶、合作方或下游系統需要交付 Barcode-PN，本規格的建議是：

1. 可以交付 Barcode-PN
2. 但交付值應來自已確認的 SI
3. Barcode-PN 應視為 item master 的輸出格式，不是 item master 的唯一定義方式

實務上建議：

• 高信心 Barcode-PN：可直接交付
• 有風險旗標的 Barcode-PN：需標注風險或暫不發布
• 同碼多包裝衝突的情況：先以 SI 解決後，再決定是否輸出一對一 Barcode-PN

3.6 channel_master 的角色

channel_master 應定位為：

• 候選池
• 證據池
• 覆蓋率盤點來源

它不應直接等於正式 item master。

4. 既有兩條能力線的定位

4.1 發票名稱 ML

這條能力線應保留，但定位為：

• 同商家發票名稱聚類
• 品牌與品類提示
• 候選生成
• 重複群組整理

不應要求它單獨完成最終身份判定。

4.2 PN-barcode 連結

這條能力線也應保留，但定位為：

• 高權重證據邊
• 同商家高精度比對線索
• 驗證與縮小候選的輔助工具

不應直接當最終 key。

5. 核心資料流

發票行
  ↓
同商家發票名稱聚類
  ↓
產生候選 SI
  - 歷史已確認對照
  - 發票名稱相似度
  - channel_master 證據
  - barcode 證據
  - 圖片證據
  - crowd 證據
  ↓
候選打分
  ↓
決策
  - 自動確認
  - 人工審核
  - 需更多證據
  - 新建商品
  ↓
確認結果
發票名稱群組 -> SI -> BI

6. 哪些因子影響 BI / SI

規則可以濃縮成兩句：

• 同一款東西，只是買法不同，通常同 BI、新 SI。
• 已經是另一款東西，才考慮新 BI。

7. 單品、組合包、箱購規則

item master 至少要分出三種 item_level：

• unit
• bundle
• carton

建議判定順序：

1. 文案明確含 箱購、整箱、/箱、整箱出貨，優先視為 carton。
2. 文案明確含 組合、套組、超值組、買 N 送 M、加贈，優先視為 bundle。
3. 2入、24包、x3 這類訊號只代表規格時，不應單獨把商品判成 bundle。
4. 若同一個 barcode 同時出現在 unit 與 bundle/carton 文案裡，應先保留 unit 為正式候選，其餘留在證據層。

8. 分類與品牌的定位

brand 與 category 都很重要，但角色不同：

• BI / SI 管身份
• category 管貨架、導航、查詢、報表
• brand 管品牌結構、搜尋聚合與提示

既有 c0~c2 分類樹與品牌系統可以直接接進來，但不應被拿來取代身份鍵。

9. 最小營運模型

1. 對每個 invoice_name_cluster 產生 2 到 5 個候選 SI。
2. 用多種證據組合打分，而不是單一來源說了算。
3. 分數高、與第二名差距大、且沒有 veto 時，才可自動確認。
4. 其餘進人工審核、群眾確認或待補證據。

10. 金級、銀級、銅級的定位

金 / 銀 / 銅 不是身份層，不用來取代 BI / SI。
它們是成熟度分級，用來回答「這個商品或這個對應目前可靠到什麼程度」。

10.1 item_tier

item_tier 用在商品本身，回答的是：

這個 BI 或 SI 本身整理得夠不夠完整、夠不夠穩

建議定義：

• 銅級
  • 已建立 BI / SI
  • 但只有單一來源或欄位仍缺很多
  • 仍可能有名稱、條碼、包裝層級待釐清
• 銀級
  • 主要欄位已完整
  • 至少有兩種證據支持，或已有一次人工確認
  • 可以內部使用，但仍可能有少量衝突待消化
• 金級
  • 身份穩定，主要衝突已清掉
  • 條碼、包裝層級、容量、名稱與時間關係清楚
  • 可作為正式 item master 下游使用

10.2 mapping_tier

mapping_tier 用在：

invoice_name_cluster -> SI

它回答的是：

這個發票名稱群組，對到這個 SI 的可信度有多高

建議定義：

• 銅級
  • 還在候選階段
  • 只有弱證據或單一來源支持
  • 不應直接當正式映射
• 銀級
  • 至少兩種證據支持，或已有一次人工確認
  • 可內部使用，但仍應保留審核與回滾空間
• 金級
  • 多種證據一致
  • 無高風險 prefix、placeholder 或明顯包裝污染
  • 已人工確認，或高信心規則與歷史表現都穩定

10.3 為什麼要分成兩層

因為：

• 商品本身很成熟，不代表每個發票名稱都已經正確對到它。
• 某個發票名稱對應很穩，也不代表整個商品資料已經補齊。

例子：

• 白蘭氏雞精 6 入組 這個 SI 可能已是 金級 item
• 但某個模糊發票名稱 雞精禮盒 對到它，可能仍只是 銅級 mapping

11. 對團隊既有做法的結論

12. 落地優先順序

1. 先把發票名稱聚類做好。
2. 再建立最小 BI / SI 層。
3. 把 PN-barcode 與 channel_master 轉進證據層。
4. 最後才放大自動化比例。

13. 一句話收尾

這個專案真正要穩住的，不是「某個 barcode 是不是完美」，而是「這個發票名稱群組最後要對到哪個 SI」。