NSFW 偵測 API vs LLM Vision：我測試了其中的陷阱

每個 NSFW 偵測 API 都能抓到明顯的色情內容。它們真正的分野在於誤判率，也就是會不會把泳裝、藝術作品或醫療照片錯誤標成露骨內容，而這才應該決定你的選擇。因此，我拿一個專用偵測器與三個 LLM 視覺模型在同一批模稜兩可的圖片上做了測試：廉價的偵測器在 26ms 內把一尊大理石雕像判成裸露，而較強的 LLM 則讀懂了上下文並通過了。大多數團隊應該複製的架構是：每次上傳先用便宜的偵測器，然後只把模糊案例送到 LLM 做第二次判讀，這樣既能維持約每 1,000 次 $1 的成本，又能減少那些惹怒真實使用者的誤報。

NSFW 偵測 API 實際回傳什麼

在比較工具之前，先了解回傳結果。你送出一張圖片（作為 URL 或直接上傳），並取得 0.0 到 1.0 之間的機率分數，以及每個類別的標籤：通常包括裸體、暗示性內容和暴力，有些服務還會加上 hentai、血腥、毒品或武器。你自行選擇門檻。高於門檻的分數會被封鎖，中間區間會排給人工審核，其餘則通過。

那個 0–1 分數就是整個遊戲。閾值設得太低，版主就會被大量誤報淹沒；設得太高，危險內容就會送達使用者。大多數服務會對靜態圖片進行評分；較少有服務處理影片（方法是依你設定的間隔抽取畫面）或文字。請記住這些術語。這就是下面選項之間的差異。

各種選項，以及它們各自擅長的內容

市場分成四個群組，而它們解決不同的問題。

專用審核 API

來自 Sightengine、Hive Moderation、AWS Rekognition、Google Cloud Vision，以及 Azure AI Content Safety 的專用分類器。它們速度快（低於 1 秒到約 1 秒）、單張圖片成本低，並在較高方案中提供更細的類別粒度以及影片支援。Hive 宣稱支援 50+ 類別；Sightengine 標稱回應時間低於 100ms。

免費內建選項：OpenAI Moderation

OpenAI 的 Moderation 端點 (omni-moderation-latest) 可免費使用，並可接受文字與圖片，大小上限為 20 MB。它會回傳 13 個類別，包括專門的 sexual/minors 標記，每個類別都附有布林值和 0–1 的信心分數。由於它是免費的，因此是先進行基準測試的最快選項：

curl https://api.openai.com/v1/moderations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"omni-moderation-latest",
       "input":[{"type":"image_url","image_url":{"url":"https://example.com/upload.jpg"}}]}'

自架設的開源

NudeNet 和 Falconsai/nsfw_image_detection 模型都可在 Python 中本地執行，沒有每次呼叫費用，且影像資料絕不會離開你的基礎架構。NudeNet 只需兩行即可試用：

from nudenet import NudeDetector
NudeDetector().detect("upload.jpg")
# -> [{'class': 'FEMALE_BREAST_EXPOSED', 'score': 0.91, 'box': [...]}, ...]

開源的 safe-content-ai 專案將 Falconsai 封裝成一個 Docker FastAPI 服務，您可以用一條指令部署。其取捨在於範圍（這些方案專注於裸體或簡單的二元判定）以及營運維護：您需要自行負責可用性、GPU 和更新。

透過中繼實現多模態 LLM 視覺

Vision models (GPT, Claude, GLM, doubao) 可以根據簡單的 prompt 對圖片進行分類。這是最靈活的選項：你只要編輯 prompt 就能修改政策，還能為每個判定取得書面理由，並且可以即時建立自訂類別。你需要按 token 付費，並等待幾秒鐘。這個選項很少與專用工具進行基準測試，所以我把重點放在這裡進行測試。

價格與各自最適合的用途

已根據各供應商於 2026 年 7 月的官方定價頁面進行核對：

我測試了誤判：專用偵測器 vs LLM 視覺

供應商會公布準確率數字。JigsawStack 宣稱超過 98%，而「95%+」也很常見。但原始準確率掩蓋了會產生客服工單的失敗：對安全內容誤判為陽性。因此，我建立了一個三張圖片的測試集，全部都是適合辦公室觀看的內容，並將相同圖片同時送入一個專門的開源偵測器（NudeNet）以及三個多模態視覺模型。控制組是一張辦公室照片、一位穿著端莊連身泳裝的女性，以及一尊古典裸身大理石雕像；其中這兩個「陷阱」正是那種粗暴的裸體偵測器會過度標記的圖像。

對於 LLM 模型，我使用了一個提示詞：*"You are an image content-moderation classifier. Return strict JSON: verdict (safe/flag/block), nsfw_score 0–1, categories {nudity, suggestive, violence}, reason. Use block only for explicit sexual content; flag means needs human review."* NudeNet 會回傳每個身體部位的框與信心分數，因此我將最高的外露部位分數作為其裸體分數。結果如下：

_{*在辦公室照片上，glm-5 回傳了 "safe"，但它自己的理由卻承認無法讀取這張圖片，所以我將那一格算作失敗呼叫，而不是有效結果。在生產環境中，這種無聲的 fail-open 是危險的情況。}

分界線不是「專用模型 vs LLM」，而是上下文理解。以下是它們對那張分開了它們的雕像圖片各自的回應：

NudeNet:  BELLY_EXPOSED 0.70, FEMALE_GENITALIA_COVERED 0.41, ARMPITS_EXPOSED 0.36  -> 標記
glm-5:    {"verdict":"flag","nsfw_score":0.75,"categories":{"nudity":1},"reason":"人體藝術裸露描繪需要人工審核。"}
claude:   {"verdict":"safe","nsfw_score":0.08,"categories":{"nudity":0.3},"reason":"博物館中的古典維納斯雕塑。屬於美術作品，不帶性暗示。"}

NudeNet 很快（18–26ms）且可免費自行部署，但它因為偵測的是身體部位而非意義，所以將這座雕像標記為 0.70；glm-5 也以 0.75 做出了相同判定。claude-opus-4-6 仍然設定了 nudity: 0.3——它看到了裸露——但根據上下文推翻了該判定，這是像素層級偵測器所不具備的能力。需要注意的失敗案例是 glm-5 的：它在無法讀取影像的情況下，仍對辦公室照片回傳了「safe」，這種靜默的 fail-open 在生產環境中你永遠不會察覺。

三個誠實的注意事項。LLM 的延遲每張圖片約為 4–14 秒，相較之下 NudeNet 約為 20ms。每張圖片大約消耗 730–1,900 個輸入 token，以前沿模型來看，成本約是你使用 Rekognition 會支付的 ~$0.001 的 10–30 倍，因此它不適合放在即時處理路徑上。再者，LLM 的輸出沒有標準化：你得把敘述文字解析成分數，而且不同模型之間的品質差異很大。這只是針對三張圖片的一個小型、非正式測試，並非基準測試。但它足以說明真正的取捨：情境理解 vs 成本、速度與一致性。

專用 API 還是 LLM 視覺能力？自建與採購的抉擇

當專用工具更勝一籌時

高流量、嚴格的每張圖片預算、次秒級延遲、影片，或合規認證（SOC 2、已簽署的 GDPR DPA）。如果你要審核數百萬次上傳，每 1,000 次僅需 $1、100ms 的方案在成本和速度上都很難超越，而 LLM 視覺在這方面並不在同一個級別。

LLM 視覺功能何時值得其成本

上下文敏感的類別中，誤判會造成傷害（藝術、教育、醫療、哺乳），以及你需要可供人類閱讀的申訴理由、需要自訂或新穎的類別，或已經針對其他特徵執行 vision model 的情況。它是聰明但昂貴的審核者，而不是大量篩選器。

大多數團隊應該使用的分層設定

在每次上傳時執行一個便宜的偵測器（或像 NudeNet 這樣的自架模型）。僅作為示意性的起點，在信任它之前先進行校準：高於約 0.85 自動封鎖，低於約 0.3 放行，並將中間區間交由一個 LLM-vision 呼叫，讓它在任何人類看到之前先根據上下文推理，然後用你自己流量中的已標記樣本來調整這些門檻。並且把分類失敗視為不安全，而不是安全：如果回應沒有確認它已讀取圖片，或無法解析為有效的 JSON，就重試或送交人工審核，而不是讓它通過，這正如上面的 glm-5 fail-open。你會以 dedicated-API 的費率處理大部分上傳，並把 LLM 成本保留給那些實際上會引發爭議的模糊案例，也就是藝術與裸露的邊界情況，那些便宜偵測器把博物館雕像誤判為裸露的例子。

那個 LLM 層需要存取一個或多個 vision models。像 AIReiter 這樣的 relay 會透過單一 OpenAI-compatible endpoint 連接到 GPT、Claude 和 GLM vision，因此審查層可以在不需要額外 SDK 或帳號的情況下切換模型；我就是這樣執行上面的四向測試。

你絕不應該親自建立的唯一一件事：CSAM

有一條底線。以上內容不適用於兒童性虐待素材。不要訓練、執行或「測試」你自己的 CSAM 偵測器，也不要把疑似 CSAM 透過一般的 NSFW 偵測 API 來處理，彷彿它只是一般的成人內容。既定的做法是與已知資料庫進行雜湊比對（Microsoft 的 PhotoDNA 以及 NCMEC 和 IWF 的雜湊清單），再向 NCMEC 通報。具體的通報義務會因司法管轄區以及你作為服務提供者的角色而異，因此應將此視為具有專屬系統的法律與執法事項，而不是一個可供你調校的分類器。

常見問題

有免費的 NSFW 偵測 API 嗎？

是的。OpenAI 的 Moderation 端點（omni-moderation-latest）是免費的，並且支援圖片。AWS Rekognition 和 Google Cloud Vision 每個每月都包含大約 1,000 張免費圖片。若要無限次免費使用，可以自行架設像 NudeNet 這類開源模型，我在測試中它每張圖片的執行時間約為 20ms。

圖片和影片最好的 NSFW 偵測 API 是什麼？

對於影片，Sightengine 和 Hive 都會取樣影格，而且就是為此而設計，AWS Rekognition 也提供影片審核。若是預算有限的圖片辨識，AWS Rekognition 每 1,000 張收費 $1，通常是常見的預設選擇。請依成本、分類深度或誤判率來衡量你的選擇；沒有絕對的贏家。

我可以在不使用付費 API 的情況下在 Python 中執行 NSFW 偵測嗎？

是的。NudeNet 和 Falconsai/nsfw_image_detection 模型都可在 Python 中本機執行（pip install nudenet），而開源的 safe-content-ai 專案則將後者封裝為一個 Docker FastAPI 服務。你是以自行託管與維護模型，來換取免去每次呼叫的費用。

NSFW 偵測 API 的準確度如何？

供應商在自己的基準測試中聲稱對明確內容達到 95–98%。真正會帶來麻煩的數字，是對邊界安全內容（藝術、泳裝、醫療影像）的誤判率；正如上面的測試所示，一個快速的專用偵測器和一個較弱的模型都過度標記了博物館雕像，而具備上下文感知的 LLM 視覺則通過了。

我可以使用 GPT-4o 或 Claude vision 進行內容審核嗎？

是，而且在需要上下文感知的情況下，它們能更好地避免誤判；在我的測試中，Claude vision 將一尊裸像判定為美術作品，而像素級偵測器卻把它標記了出來。代價是速度（幾秒，而不是毫秒）和價格（每張圖片大約是專用 API 的 10–30 倍），所以應該把它們用作審核層，而不是第一線的大量過濾器。

相關閱讀

• Claude API 定價指南