為什麼你的商品 Feed 永遠對不上供應商的：一份現場診斷

目錄錯配——同一個商品以三筆不同紀錄存在於你的 Feed、供應商的 Feed 與電商平台——是一個偽裝成字串比對 bug 的多模態資料問題。標題會說謊、SKU 會漂移、圖片集會分岔。這份診斷按照現場工程師實際遇到問題的順序，走過五個根因，最後停在「從源頭修好比對」的紀錄結構。

工單通常這樣寫：「供應商 Feed 有 41,203 個 SKU，我們目錄顯示 39,871，平台商品頁有重複。」有人提議模糊字串比對。它有效一週。然後供應商為了 SEO 把 4,000 個商品改名，比對層再次垮掉。以下是故障堆疊順序的診斷。

診斷一：你比對的欄位是最會說謊的那個

標題是行銷文案，不是身分。「Ultra-Comfort 人體工學辦公椅 附腰靠（黑）」和「Pro Ergo 椅—黑」是同一個商品；「V2」和「V2（2025 修訂版）」卻可能不是。任何主要靠標題文字做 key 的比對管線，都在繼承供應商的行銷日曆。

修法不是更強的字串演算法——是用更豐富的證據比對：圖片集、屬性區塊、類別路徑與說明文字，加權在一起。換句話說：比對本來就是多模態問題，純文字管線是綁著一隻手在做。

診斷二：你的嵌入模型訓練在錯的分布上

走向嵌入比對的團隊，通常抓一個通用模型。然後發現電商是一種方言：「PS5 DualSense Edge」要落在「PlayStation 5 Edge 控制器」旁邊，而「1TB」比「高速」重要得多。通用嵌入帶你走 80%；最後 20%——決定 4,000 個商品對得上還是 600 個的那一段——來自在真實目錄配對上調校過的領域相似度。

那個調校集是資料問題：跨平台與供應商的配對紀錄，圖文對齊。這正是結構化多模態資料集在賣的東西——橫跨 100 多個網域、約 每 1,000 筆 $0.25 的紀錄，圖片參照與文字欄位逐筆對齊。幾十萬筆跨平台商品配對紀錄，就是「每季微調一次」與「每年重建一次」的比對層之間的差別。

診斷三：比對的其中一側過期了

比對運作良好——然後供應商在週二發布更新，800 筆紀錄變了圖片、屬性或存在性。如果你的管線對快照比對，供應商的每次編輯都變成暫時性錯配，而你的去重指標悄悄劣化，直到有人重跑全量。

修法是營運性的：排程採集。供應資料集的同一套基礎設施也能跑週期性採集——Thordata 平台把資料集目錄與爬蟲 API（120 多個現成目標，約每 1,000 筆 $0.50–1.00）、原始住宅採集（公開滑桿，$2.00/GB 降至 $0.65/GB）放在同一個帳戶裡，於是比對的供應商側按排程刷新，而不是按危機刷新。

診斷四：平台層把一切都翻倍

你修好供應商比對，電商平台的 Feed 又帶著同一批商品的自家商品頁來了——不同標題、重修圖、不同 SKU。現在比對變成三方，而三套詞彙之間的紀錄身分，需要一個不屬於任何一方 SKU 的 join key。

可行模式：用多模態證據做比對，然後指派自己的標準 ID，並把每一側的來源掛在紀錄上：

# 示意：多模態紀錄 → 標準實體
def resolve(record):
    vec = embed(
        title=record["title"],
        attributes=record["attributes"],   # 品牌、尺寸、顏色、容量
        image=record["image_url"],         # 圖片嵌入與文字一起參與
    )
    match = index.search(vec, top_k=3)
    if match.score > THRESHOLD:
        return match.canonical_id           # 既有商品
    return mint_new_canonical_id(record)    # 真正的新 SKU

# 每一側保留自己的 ID，映射到標準 ID
catalog.upsert({
    "canonical_id": resolve(supplier_record),
    "source": "supplier_a",
    "source_sku": supplier_record["sku"],
    "image_hash": hash_image(supplier_record["image_url"]),
})

image_hash 那行比表面重要：影像身分活得過標題改寫，這讓它成為行銷驅動的目錄裡最穩定的 join key。

診斷五：沒有人能稽核比對結果

最後一個失敗是組織性的。採購問「這兩個商品頁為什麼合併（或沒合併）」，答案是「模型說的」。沒有來源——哪些欄位比對成功、出自哪些來源紀錄、分數多少——每一個比對決策都無法稽核，目錄團隊就會失去對整個比對層的信任。

這正是紀錄層級結構付第二次紅利的地方：如果資料集與採集層交付的紀錄帶有來源、時間戳與欄位層級譜系，比對層就能對每個決策出示證據。可稽核的比對活得住採購審查與採購人員的質疑；不可稽核的比對會被拿著試算表的實習生取代。

診斷即檢查清單

常見問答

這件事的資料側實際要花多少錢？
比圍繞它的工程便宜。以按筆計價，30 萬筆多模態試點大約 $75；維持新鮮的排程採集隨供應商數量規模化。這個問題昂貴的版本，其實是你已經在付的那個——重複的商品頁、對不上的庫存、人工對帳。

我們自己是平台，不是零售商——問題不同嗎？
同一個問題，放大版：你有 N 個供應商而不是一個，所以診斷四會相乘，而標準 ID 層變成你的核心產品。把這題做得好的平台，把比對層當核心 IP 在養，用資料集規模的證據餵它。

搜尋資料對目錄比對有幫助嗎？
間接但實在：商品查詢是同一批實體的第三套詞彙，而透過 SERP 監控（量價約每 1,000 次結構化回應 $0.70）觀察商品在搜尋中的浮現，既能驗證比對（這兩個「不同」SKU 是不是浮現在同一批查詢裡？），也能抓需求側漂移。在目錄管線旁邊跑持續 SERP 資料爬取的團隊回報：在影像身分之後，查詢重疊是最便宜的比對訊號。

一週內從哪開始？
從現在的錯配裡抽 500 對難例、人工標注，拿現有比對層去考它。如果失敗超過三分之一——標題為 key 的比對通常如此——拉一份過濾後的多模態資料集分片重跑。差距就是你的業務論證，一週就夠，不用一季。搜尋側驗證用結構化 SERP 資料試點，試用額度與爬蟲 API 相同。

整份診斷的一句話版本：你的 Feed 對不上，是因為身分從來就不是文字問題——它是證據問題；而把這題做贏的團隊，用結構化紀錄買證據，而不是從字串裡硬榨。