多語言HS歸類：非英文產品描述該怎麼分類？

非英文語言的產品描述，要怎麼做HS歸類自動化？

要靠一套針對產品事實（功能、材質、成分、用途）運作的歸類引擎，而不是靠比對英文文字的相似度。GRI（歸類總則）是一套與語言無關的法律推理規則，只要歸類引擎把GRI 1到6編寫成一套確定性的邏輯，就能對任何語言描述的產品進行歸類。GingerControl的HS歸類API支援中文、德文、西班牙文、法文、日文、韓文、葡萄牙文、義大利文、荷蘭文等40多種語言的產品描述，在正式營運流量下六位碼層級準確率達96%，不論原始語言為何，套用的都是同一套GRI推理邏輯。

為什麼HS歸類這件事，方法論比語言更重要？

國際上採用的HS制度是統一的。「純棉針織短袖T恤」不論用英文、中文還是西班牙文描述，都歸屬HS 6109.10。歸類引擎真正需要理解的，是這項產品到底是什麼（一件純棉針織上衣），而不是描述文字用哪種語言寫成。文字比對型的API，通常先把描述翻譯成英文，再拿去跟HTS節文字比對，等於在文字比對誤差之外，又疊加了一層翻譯誤差。真正理解產品事實的GRI邏輯歸類引擎，套用的是同一套法律推理，不會因為語言而改變。

摘要： 多語言HS歸類對文字比對型API來說是結構性的難題，因為這類方法論的核心，仰賴的是英文文字的相似度比對，翻譯這一步，還沒開始歸類就已經先引入誤差。GingerControl的HS歸類API是針對產品事實（功能、材質、成分、用途）運作，而不是比對英文文字，所以不需要經過翻譯，就能跨語言完成歸類。這套API支援50多種語言的產品描述，在正式營運流量下，各語言的六位碼層級準確率都達到96%。對服務全球的第三方物流業者、擁有非英文賣家商品目錄的電商平台，以及國際物流平台來說，這代表同一套歸類API就能處理數十種語言混合的多來源商品目錄，不需要另外設計語言分流邏輯。單一產品端點平均回應時間為36秒，批次端點可在3到5分鐘內處理200筆項目，在正式營運層級可擴展到每日20萬筆以上的歸類量。對95%以上不具爭議的產品來說，這套API可以直接送出結果，不需要人工介入，語言不是限制。

最後更新：2026年5月

為什麼文字比對型歸類API在非英文描述上容易失準

多數自動化HS歸類API，把歸類當成一個文字比對問題來處理：把產品描述做向量化，把HTS節文字也做向量化，再找出最接近的配對。這套方法在處理非英文描述時，會出現兩種結構性的失準情況。

翻譯誤差會疊加在歸類誤差之上。 文字比對型API如果先把「棉針織短袖T恤」（中文描述純棉針織短袖T恤）翻譯成英文，翻譯這一步就會先引入雜訊。翻譯結果可能是「cotton woven T-shirt」，也可能是「cotton knitted short sleeve shirt」，取決於用的翻譯模型。接下來拿翻譯結果去做文字比對，又會再疊加一層誤差。最終結果就是非英文描述的準確率，普遍低於同一套API處理英文描述時的準確率，原因就在於翻譯這一層，本身就是歸類之前一個會漏失資訊的步驟。

有些語言沒有能直接對應HTS節文字的說法。 HTS節文字是用法律英文寫成，帶有特定的專業用語（「寢具用品」「完整或已完工物品」「以計量劑量或零售包裝供應」）。其他語言的概念架構不見得一樣。舉例來說，直接把一段日文產品描述跟英文HTS節文字做逐字比對，很可能漏掉真正決定歸類的概念對應關係。

更麻煩的是，這些失準往往是無聲無息發生的。API吐出一個稅則號別，進口人照著申報，錯誤要等到稽核時才會浮現。文字比對型API在處理非英文描述時，準確率通常比處理英文描述時低10到20個百分點。

為什麼GRI邏輯歸類能跨語言運作

GRI（歸類總則）是一套與語言無關的法律邏輯。GRI 1規定，歸類要依節文字本身以及類注、章注來決定。節文字講的是產品的事實，不是英文字串。當歸類引擎把產品理解成一組事實（這是一件棉質衣物、針織構造、短袖、上身穿著），GRI 1就會把它導向6109節（T恤、汗衫、背心及類似衣著，針織或鉤織）。原始描述用什麼語言寫，不會改變這些底層事實。

GingerControl的API是針對產品事實運作。這套引擎會依序進行：

從描述中擷取產品事實：不論原始語言為何，都能擷取材質成分、構造方式、功能、用途、尺寸、包裝方式等資訊
對這些事實套用GRI 1到6：依法律規則判定應歸屬的節
套用類注與章注：作為排除與納入的判斷依據
參照CROSS判例：確保與既有先例一致
回傳HS稅則號別：連同一份記載歸類依據的推理鏈

回應內容裡的推理鏈是用英文呈現的（因為HTS本身是英文），但原始描述可以用50多種支援語言中的任何一種輸入。推理鏈會明確引用所套用的GRI規則以及相關法律依據，這正是報關業者做歸類時會產出的同一種文件紀錄。

常見的多語言歸類情境

情境：來自中國供應商的中文產品描述 第三方物流業者從中國供應商那裡收到中文產品資料。目前多數業者的做法是靠分析師人工翻譯。改用GingerControl的API之後，中文描述可以直接送去歸類，不需要先經過翻譯這一步。回應裡的英文推理鏈，直接就是美國進口報關可用的歸類依據文件。

情境：德文技術規格書 進口德國工業設備的業者，收到的是德文技術規格書，裡面包含精確的材質成分與工程公差。GingerControl的API可以直接處理德文描述，把Stahl（鋼）、Aluminium（鋁）、Edelstahl（不鏽鋼）、Gusseisen（鑄鐵）這類德文技術用語，當成產品事實來處理。

情境：西班牙文電商平台賣家目錄 一個服務西班牙與拉丁美洲市場的電商平台，賣家目錄以西班牙文建立。賣家上架商品時附上西班牙文描述，平台需要據此完成HS歸類，用來計算跨境關稅。GingerControl的API可以直接對西班牙文描述做歸類，不需要另外要求賣家提供英文翻譯。

情境：日文消費性電子產品 一家消費性電子產品經銷商，向日本製造商採購，拿到的是日文產品規格書，裡面用日文技術用語描述元件、材質與功能。GingerControl的API可以直接處理這些日文描述，套用第85章／第90章邊界判斷邏輯，不需要另外設計語言分流機制。

支援語言

這套API支援以下語言的產品描述，並完整套用GRI邏輯：

亞洲語言： 中文（簡體與繁體）、粵語、日文、韓文、越南文、泰文、印尼文、馬來文、他加祿文、印地文、孟加拉文、坦米爾文、烏爾都文
歐洲語言： 德文、法文、西班牙文、義大利文、葡萄牙文、荷蘭文、波蘭文、俄文、烏克蘭文、捷克文、斯洛伐克文、匈牙利文、羅馬尼亞文、保加利亞文、希臘文、瑞典文、挪威文、丹麥文、芬蘭文、土耳其文
中東與非洲語言： 阿拉伯文、希伯來文、波斯文、史瓦希里文、阿姆哈拉文
拉丁美洲西班牙文與葡萄牙文變體： 墨西哥西班牙文、阿根廷西班牙文、巴西葡萄牙文

支援語言清單以外的語言，這套API仍然可以接受描述輸入，但準確率可能低於正式營運基準。如果你的商品目錄使用清單以外的語言，歡迎聯絡我們進行該語言的準確率驗證。

API如何在請求與回應中處理語言

請求內容：description欄位可以接受任何支援語言的文字，不需要另外指定語言參數，系統會自動偵測語言。

{
  "description": "棉针织短袖T恤",
  "country_of_origin": "CN"
}

回應內容：HS稅則號別、稅疊與推理鏈都以英文回傳（因為HTS本身是英文），原始描述會原封不動附在回應中。

{
  "hts_code": "6109.10.0012",
  "tariffs": {
    "general_rate": "16.5%",
    "special_rate": "Free",
    "Section 301": [...],
    "Section 122": [...]
  }
}

如果平台需要用原始語言把結果呈現給終端使用者，可以在平台自己的呈現層，把英文推理鏈翻譯回原始語言。結構化的JSON輸出格式，讓這一層的再翻譯工作變得直接好處理。

為什麼多語言歸類在2026年變得更重要

有三個趨勢正在提高多語言HS歸類的重要性：

跨境電商成長。 服務多個地區的電商平台，會接受賣家用自己的母語上架商品，平台再據此完成HS歸類，用來計算跨境關稅。人工翻譯根本無法規模化。

全球第三方物流營運。 第三方物流業者在拓展非英語市場客戶時，收到的產品資料是用客戶的語言寫成。先翻譯再歸類，等於讓每個SKU的成本翻倍，還多引入一層翻譯誤差。

供應商以原始語言提供的產品資料。 進口人從供應商那裡收到的產品規格，用的是供應商自己的語言。要求先翻譯成英文才能歸類的流程，會多出額外步驟，也多一層誤差來源。

以上每個趨勢都指向同一個結論：能直接處理非英文描述的歸類API，能拿掉一個工作流程上的瓶頸，也不會引入翻譯誤差。

多語言HS歸類效能數據

端點	指標	數值
單一產品端點	平均回應時間	36秒
單一產品端點	中位數（P50）	30秒
單一產品端點	P95	79秒
單一產品端點	P99	108秒
批次端點	每次呼叫項目數	200
批次端點	完成時間	3到5分鐘
批次端點	正式營運日處理量	20萬筆以上
批次端點	企業層級每小時處理量	100,000筆歸類
六位碼跨語言準確率	正式營運流量下約96%（各語言間誤差在正負1個百分點以內）

各語言之間的效能表現一致，因為底層架構完全相同：不論原始語言為何都會擷取產品事實，套用GRI 1到6作為確定性法律邏輯，強制套用類注與章注，並參照CROSS判例。延遲時間與準確率不會因為支援語言不同而有明顯落差。

常見問題

API會不會先把描述翻譯成英文再做歸類？

不會。API會直接從原始語言的描述中擷取產品事實，並對這些事實套用GRI邏輯。先翻譯成英文，會在歸類之前先引入翻譯誤差，這正是多數多語言歸類方案容易失準的原因。直接針對產品事實運作，就能避開翻譯這個會漏失資訊的步驟。

如果我的產品描述混雜多種語言怎麼辦？

混合語言的描述（例如材質規格用中文寫、品牌名稱用英文寫）會分別從提供相關資訊的語言中擷取產品事實。推理鏈會清楚記載，哪些事實是從哪個語言擷取出來的。

非英文描述能不能用來對非美國目的地做歸類？

六位碼HS稅則號別是國際通用的，所以美國進口歸類回傳的六位碼，同樣適用於其他國家。完整的美國稅疊（Section 301、232、122、第99章）則是美國專屬的規則。如果目的地不是美國，就要套用當地的關稅稅則；API回傳的六位碼，是目的地國關稅分析的起點。

多語言歸類的準確率，跟純英文歸類比起來如何？

GingerControl的API在所有支援語言下，六位碼層級的準確率都維持在約96%，誤差在正負1個百分點以內。文字比對型API在處理非英文描述時，準確率通常會下降10到20個百分點，原因就是翻譯誤差疊加在文字比對誤差之上。架構上的選擇（針對產品事實運作的GRI邏輯，相對於針對英文翻譯後文字做相似度比對），正是造成這個差距的關鍵。

我的客戶能不能用自己的語言輸入描述，再用自己的語言看到結果？

API的回應內容以英文呈現，因為HTS稅則本身就是英文寫成。如果平台需要用客戶的母語呈現結果，可以在平台自己的呈現層，把英文推理鏈翻譯回客戶使用的語言。結構化的JSON輸出（HS稅則號別、稅疊、推理鏈），讓這種再翻譯的呈現方式相對容易處理。

API能不能處理帶有特殊字元與Unicode的產品描述？

可以。API接受UTF-8編碼、任何字元集的描述輸入，包括中日韓文字、西里爾字母（俄文、烏克蘭文）、阿拉伯文、希伯來文等等，不需要另外指定編碼方式。

API怎麼處理非英文語言裡的技術用語？

不論用哪種語言表達，材質名稱、構造方式、元件規格這類技術用語，都會被擷取為產品事實。這套引擎能辨識出「Edelstahl」就是不鏽鋼，「牛仔布」就是丹寧布，並跟處理英文材質用語一樣，把這些材質事實套用到GRI邏輯裡。

開始為多語言商品目錄做歸類

如果你經營的是全球第三方物流業務、國際電商平台，或是有非英文供應商資料的進口業務，那種要求先翻譯成英文才能歸類的流程，正在增加你的成本，也在引入你其實不需要承擔的誤差。真正對的架構，是能直接處理非英文描述。

前往gingercontrol.com/products/openapi試用GingerControl的API。這套OpenAPI比市面上的替代方案更快、更便宜、也更準確，目前已經透過優化HS歸類與完整稅疊可視化，累計幫客戶省下400萬美元的關稅支出。你可以直接在頁面上實測API的速度，看到真實的回應時間。

GingerControl不只是一套工具。我們與全球第三方物流業者、國際電商平台、跨區域電商業者，以及擁有多語言供應商資料的進口業者合作，提供流程顧問、數位轉型策略規劃，以及端到端的客製系統開發。聯絡我們的團隊，把多語言HS歸類嵌入你的正式營運流程。

參考資料

[REF 1] 世界關務組織，HS多語言版本引用數據：HS是國際統一標準，並有官方多語言版本來源：WCO Harmonized System

[REF 2] USITC協調關稅稅則引用數據：美國HTS以法律英文寫成，並採用國際統一的六位碼架構來源：USITC HTS

[REF 3] 美國海關及邊境保護局，貿易統計數據引用數據：2025財政年度共徵收2,258億美元的關稅、稅捐與規費來源：CBP Trade Statistics 發布：2025年

[REF 4] CBP資訊性合規指引，合理注意義務引用數據：合理注意義務標準與文件留存要求來源：CBP Reasonable Care Publication 發布：2017年9月

[REF 5] ATLAS：針對全球貿易HTS歸類任務評測與調校大型語言模型，arXiv 引用數據：一般大型語言模型在歸類任務上的準確率基準，作為比較參考來源：arXiv 2509.18400 發布：2025年

Automated Global HS Classification: How Do You Classify Across 100+ Countries?