---
slug: gemini-synthid-multilingual-token-watermark
status: published
title: "Gemini 文字浮水印怎麼跨語系運作？從 SynthID 詞元、檢測到可取得性"
excerpt: "Gemini 的文字浮水印不是藏在特殊字串裡，而是和 token、模型機率與生成策略有關。這篇從 SynthID-Text、跨語系差異、翻譯與改寫限制，整理到 Google Search 與改稿後流量下降該怎麼診斷。"
category: AI
tags: [Gemini, SynthID, AI, watermark, tokenization, Google Search, SEO]
author: Seer
author_role: Author
read_time: 16 min
cover: "/static/synthid-multilingual-text-watermark-cover.png"
closing_note: "真正值得留下的，不是看不見的來源訊號，而是文章裡那些只有作者做過研究、測試與判斷後才寫得出來的內容。"
published_at: "2026-08-12T08:43:08Z"
updated_at: "2026-08-12T08:43:08Z"
---

最近在整理 Gemini 文字浮水印的資料時，想到一個常被忽略的問題：當英文、繁體中文、日文、阿拉伯文等不同語系的斷詞方式（Tokenization）天差地別時，SynthID-Text 到底是如何在不同語言中寫入浮水印訊號的？我們能自己拿到這些 token 嗎？到底有沒有一份所謂的「浮水印詞元清單」？

在深入技術細節之前，許多創作者與開發者更關心的是：使用 Gemini 或 AI 生成的文章，是否會被 Google Search 排除收錄？如果改稿後網站流量下滑，是不是因為被偵測到了浮水印？

這不是完全抽象的假設。我自己前陣子確實做過一次改稿，改完之後自然搜尋流量明顯降低。這個時間上的先後關係，讓「改稿後內容被重新評估」成為值得認真追查的訊號；但它本身還不能分辨，真正原因是內容被改弱、標題與搜尋意圖改變、技術 SEO 狀態變動、搜尋需求與競爭改變，還是搜尋系統使用了我們看不到的生成來源或品質訊號。

## Google Search 會排除 Gemini 產生的 AI 文章嗎？

目前 Google 官方資料並不支持「只要內容是 Gemini 或 AI 生成，就一律不予收錄」的說法。Google Search 的公開說法是評估內容的品質、原創性、實用性與相關性，而非只看產出方式。[10][16] 只要內容符合 helpful、reliable 且以使用者為優先的原則，AI 生成本身並不是自動排除的條件。[13]

然而，如果大量使用生成式 AI 產生低價值、非原創的頁面，企圖以此操縱搜尋排名，則可能落入 Google Spam policies 所說的「規模化內容濫用（scaled content abuse）」範圍。[10][12]

在診斷流量或可見度問題時，應先釐清 Google Search 的三個階段：
- **抓取（Crawling）**：搜尋引擎爬蟲是否成功下載並讀取網頁。
- **索引（Indexing）**：網頁是否被成功納入搜尋引擎的資料庫。
- **排名與呈現（Ranking/Serving）**：已被索引的網頁，在面對使用者的搜尋意圖時，是否因為內容品質、競爭訊號等因素獲得曝光。

因此，當網站流量或曝光度下降時，不能只憑「改稿後就下降」這個時間關係，直接斷定「因為文章是 Gemini 寫的，所以被 Google 偵測到並排除」。但在有實際改稿與流量變化的個案下，這個說法也不該被一句「沒有官方證據」草草帶過：Google 不會公開完整的收錄、排名與內部分類器規則，理論上可能存在未公開的來源或生成訊號，並與內容品質、原創性、重複程度等因素一起影響頁面的可見度。

本文因此把「Google 可能辨識某些 Gemini 生成來源訊號，並將它與其他品質訊號一起納入評估」視為一個合理但尚未被公開證實的工作假說。它不等同於「SynthID 已被證明是 Google Search 的直接懲罰條件」。要判斷個別文章發生了什麼，仍然要先檢查 Search Console、URL Inspection、manual actions、robots、canonical 與索引狀態，再比對改稿前後的曝光、排名與內容差異。Google 也明確區分頁面是否被抓取、是否進入索引，以及是否在查詢中獲得曝光。[14]

## Gemini 生成的文章都帶有 SynthID 嗎？

根據 Google DeepMind 官方說明，目前文字版的 SynthID 浮水印已應用於 **Gemini App 與 Web 網頁版體驗** 中。[1] 這是官方目前明確承諾的適用範圍。

不過，我們不能將這個範圍無限延伸。以下結論在技術上是不成立的：
- 所有透過 Gemini API 輸出的內容都一定帶有 SynthID-Text。
- 經由第三方 API 封裝、代理服務或工作流產生的文字會保留同樣的浮水印。
- 即便是極短的回覆，偵測器也能判定。
- 只要文字風格像 Gemini，就能直接證實是 Gemini 寫的。
- 其他非 Gemini 的模型會自動套用這套 SynthID 機制。

浮水印本質上是模型生成演算法的一環。文字最終能否留下或被偵測出訊號，取決於實際運行的模型、產品入口、是否啟用了相容的浮水印配置，以及產出後是否經過修改。Google 開發者文件所介紹的，是一套可供開發者接入模型生成管線的技術方案，而非所有文字模型通用的後處理格式。[2]

最關鍵的是，目前公開資料還不能證明「偵測到 SynthID 就排除網頁」這條直接因果鏈。但因為 Google Search 的完整機制與內部分類器不公開，也不能把「官方沒有承認」推論成「這類來源訊號絕對不會被使用」。比較精確的分界是：SynthID 公開定位屬於內容來源識別與檢測技術；它是否、以及如何被 Google Search 的抓取、索引或排名系統使用，仍是未公開、待驗證的部分。[10][11][14]

## SynthID-Text 不是藏在文章裡的特殊字串

大型語言模型在處理文字時，會先將輸入與生成的內容拆解為 token（可能是字元、部分字根、單字或片段）。這個切分過程稱為 tokenization，而模型支援的所有 token 集合就是詞彙表（vocabulary）。[5][6]

一般的文本生成流程大致如下：

```text
前文
  ↓
tokenizer
  ↓
token IDs x₁, x₂, ...
  ↓
模型計算下一 token 的機率分布 p(xₜ | x₍<ₜ₎)
  ↓
抽樣或選擇下一個 token
  ↓
decode 回文字
```

而 SynthID-Text 則是將浮水印機制嵌入「抽樣下一個 token」的步驟中：

```mermaid
flowchart TB
  C["前文 + token IDs"] --> L["模型 logits / 機率分布"]
  L --> K["top-k / top-p 篩選"]
  K --> G["私有 key + 前文產生 seed 與 g-values"]
  G --> T["Tournament sampling"]
  T --> N["選出下一個 token"]
  N --> D{"生成完成？"}
  D -->|no| C
  D -->|yes| O["decode 回一般文字"]
```

Nature 論文指出，SynthID-Text 主要由隨機種子產生器（random seed generator）、抽樣演算法（sampling algorithm）與評分函數（scoring function）這三個核心元件構成。研究中的 seed 產生方式會將最近生成的 token 序列與浮水印金鑰（watermark key）放進雜湊流程，產生每一步的隨機種子。接著，g-function 會對詞彙表中的候選 token 計算出一個偽隨機分數，最後透過 Tournament sampling 讓候選 token 依據這些分數進行多層篩選與抽樣。[3]

而在 Google 開發者文件中，這套機制被描述為一個作用於生成管線中的 logits processor。它會在 top-k 或 top-p 等參數篩選後，利用偽隨機的 g-function 寫入浮水印資訊。其中 `keys` 與 `ngram_len` 是必要參數，完整設定還會包含 sampling table 與 context history 等欄位。[2]

因此，最終產出的 Markdown 文本通常不會以一般讀者可直接看見的形式包含：
- `SynthID` 這類識別字串。
- 任何肉眼可見的特殊符號。
- 隱藏的 HTML 屬性或欄位。
- 隨附在檔案裡的 metadata。
- 一組可以用肉眼對照的「綠色詞彙清單」。

它留下的是 token 的選擇傾向與上下文之間的統計關聯。若要進行檢測，偵測器必須使用完全相同的 tokenizer、浮水印設定與對應的訓練數據，才能將這些隱性關聯轉化為可供評估的分數或結論。[2][7][8]

## 不同語系的差異，發生在哪裡？

### 1. tokenizer 切法不同

在 LLM 的世界裡，「一個字」不等同於「一個 token」。中文可能以單字或常見詞彙片段來切分；英文會把空格、字根、字尾拆開處理；日文、韓文、阿拉伯文，乃至於混雜了數字與標點符號的文本，都會根據模型專屬的詞彙表而有不同的切法。

我們無法用單一規則套用在所有模型上。以 Gemini 而言，官方文件僅提供粗略估算：1 個 token 大約等於 4 個字元，但實際的斷詞方式仍完全由模型的 tokenizer 決定。[6]

以一句簡單的中文為例，在不同模型的 tokenizer 下切出來的結果可能長這樣：

```text
原始文字：今天適合部署嗎？

模型 A： [今天] [適合] [部署] [嗎] [?]
模型 B： [今] [天適] [合部] [署] [嗎] [?]
模型 C： [今天適合] [部署] [嗎] [?]
```

（註：這只是示意斷詞邊界的差異，並非 Gemini 實際的斷詞結果。請勿直接將某個開源模型的 token ID 套用到其他模型上。）

### 2. 浮水印並非挑選固定的語系詞表

SynthID-Text 的 g-function 是針對模型 vocabulary 中的候選 token 進行評分。它不會預先準備好「中文專用字表」或「英文專用詞表」來限制模型。

比較精確的運作邏輯是：

```text
每一步的前文 + 私有 watermark key
              ↓
        產生偽隨機 seed
              ↓
對目前 vocabulary 的候選 token 計算 g-values
              ↓
讓某些候選在抽樣競賽中暫時取得優勢
```

每一步生成的上下文改變，產生的 seed 就會改變；當模型的機率分佈不同，候選 token 也會隨之調整。因此，實務上根本不存在一張與上下文無關、恆定不變的「SynthID 詞元清單」。[2][3]

### 3. 不同語系提供的統計空間不同

如果某個語言在模型的 vocabulary 中有較豐富的 token 選擇，生成時擁有較高的 entropy（熵），浮水印演算法就有更多的餘裕去調整抽樣機率。

相反地，如果生成內容高度受限，例如：
- 數學公式
- 格式固定的 JSON 欄位
- 程式碼語法
- 法律條文原文
- 極短的字句
- 低 temperature 生成（候選 token 幾乎只有單一最優解）

此時模型能調整抽樣的空間微乎其微，浮水印訊號自然會變弱。SynthID-Text 論文的補充資料也證實，在短文本或模型預測機率分佈 entropy 較低時，偵測效果會打折扣，此時偵測器可能會選擇「不予判定」（abstain），避免給出錯誤的判讀。[4]

### 4. Google 的多語系實驗代表什麼？

在 SynthID-Text 論文中，研究團隊使用 XLSum 資料集測試了 8 種語言，以 Gemma 7B-IT 生成帶有浮水印新聞文章並與人工撰寫的文本對比。結果顯示，SynthID-Text 在這 8 種語言的實驗中都維持了不錯的偵測率。相較之下，像 Binoculars 這類直接在生成後進行 AI 文本判定（後置式）的工具，在印地語（Hindi）、阿拉伯語（Arabic）與俄語（Russian）等語言上的表現就明顯較差。[4]

這項實驗支持了一個關鍵論點：**在生成階段直接寫入浮水印，能有效擺脫後置分類器高度依賴英文寫作風格的限制。**

不過，這項研究的技術邊界依然存在：
- 實驗採用的是特定的模型、tokenizer、key、資料集與文本長度。
- 「8 種語言」取得成效，不代表能直接套用到世界上所有語言。
- Gemma 的實驗數據，並不等同於所有 Gemini 產品入口都開放了同等強度的設定。
- 面對繁體中文、日文或多國語言混雜的文本，仍需視實際模型與偵測器的校準結果而定。

## 為什麼文字翻譯後，浮水印訊號會變弱？

假設一段英文原文在生成時寫入了 SynthID-Text：

```text
英文前文 → 英文 tokenizer → 英文 token 選擇與 watermark 訊號
```

當這段文字被翻譯成中文時，背後通常會經過全新的生成管線：

```text
英文文字 → 翻譯模型理解
          ↓
       中文 tokenizer
          ↓
       中文候選 token
          ↓
       重新生成中文文字
```

這個過程徹底改變了：
- token 的邊界劃分
- token ID 的編碼序列
- 前文脈絡（context）
- 每一步預測的候選 token 集合
- 句意結構與詞彙選擇
- 生成模型與對應的浮水印配置

因此，原本在英文 token 序列中留下的統計關聯，在翻譯後可能大幅衰減。Google 開發者文件也明確指出，對文本進行大幅改寫或翻譯成其他語言，會導致偵測器的置信度（confidence）顯著下降。[2] 論文補充資料亦提到，刪改文字會削弱偵測效果，若經過能力強大的模型進行重寫，訊號衰減會更加明顯，但如果文本長度足夠，仍有可能保有一部分的偵測性。[4]

需要釐清的是，如果翻譯是由另一個「同樣啟用了自有浮水印」的模型來執行，那麼產出的中文會帶有該翻譯模型所產生的新浮水印。這並非「把舊浮水印翻譯過去」，而是新模型在新的語言與設定下重新留下的訊號痕跡。

## Agy 順稿後流量下降，該如何診斷？

如果在使用 Agy 或其他 AI 工具優化、潤飾文章後，發現網站搜尋流量產生變動，可以參考以下診斷框架來排查問題：

| 觀察到的現象 | 先查什麼 | 可能解釋 |
|---|---|---|
| 曝光數（impressions）與點擊數（clicks）一起下降 | Search Console、索引狀態、canonical、robots.txt、sitemap | 網頁可能面臨索引、技術設定錯誤，或整體搜尋需求的變化 |
| 曝光數維持，但點擊率（CTR）下降 | title、snippet、搜尋意圖、搜尋結果頁上的競爭頁面 | 搜尋結果的標題或摘要不夠吸引人，或者與搜尋意圖有落差 |
| 曝光數下降，平均排名變差 | 關鍵字查詢、內容主題、競爭對手動態、修改前後的內容差異 | 相關性判斷改變、內容差異或搜尋引擎排名訊號的波動 |
| Google 已索引網頁，但幾乎沒有獲得曝光 | 查詢該主題的搜尋需求、網頁內容是否過於平庸（commodity content） | 內容缺乏獨特性，或者市場上對於該主題的需求本就不足 |
| 內容修改（改稿）後流量才下降 | 比對原稿與 Agy 順稿後的差異（diff），也觀察同時期其他文章 | 順稿可能刪除了作者的個人經驗、實際案例、關鍵技術細節、明確的解答或內部連結；也不能排除搜尋系統對內容來源、重複性或品質訊號的評估發生變化 |

> [!NOTE]
> 此表格提供的是分析問題的診斷框架，並非對特定網站流量下降原因的唯一結論。在缺乏原稿、改稿日期、Search Console 與 GA4 完整數據的情況下，無法直接斷定流量變化與順稿工具、內容品質訊號或可能的生成來源訊號之間存在直接因果關係。

## 如何進行內容的第二次編修（Second Editorial Pass）？

當使用 AI 工具進行初步整理後，建議進行「第二次編修（Second Editorial Pass / Quality Pass）」，而非盲目相信可以用某些技術方式「洗掉」浮水印或保證通過 AI 檢測。

編修的核心目的在於提升內容的「原創價值」與「使用者體驗」，建議採取以下步驟：
- **補充作者的獨特價值**：補回原作者的實測條件、主觀觀察、專業判斷、案例細節以及技術限制。
- **清除空泛的 AI 語句**：刪除 AI 常產生的泛化陳述、無意義的轉折詞與缺乏事實根據的確定語氣。
- **優化結構與解答**：將讀者關心的核心問題直接置於 H2 標題與段落開頭，使資訊一目了然。
- **補回官方來源連結**：插入原始且具公信力的官方說明連結，確保資訊正確性。
- **校對與調整細節**：修正標題、摘要、網頁標題（heading）、段落順序與內部連結，最後做受限語氣的順稿。

不建議將此流程當作：
- 清除 SynthID 的方法。
- 永久移除文字浮水印的保證。
- 通過 AI 檢測器的工具。
- 恢復 Google 搜尋排名的保證。
- 利用多重翻譯、同義詞替換、刻意錯字或混合來源來規避檢測的手段。

從技術上看，刻意同義詞替換、翻譯或混合低價值內容來規避檢測，無法保證移除浮水印，也可能降低閱讀體驗與原創價值。Google 的 spam policy 將「以自動轉換大量產生、但沒有新增價值的頁面」列為 scaled content abuse 的例子。[12]

## 我們可以在哪裡取得詞元（Tokens）？

答案是可以，但必須釐清你取得的是哪一個層級的資料：

| 取得管道 | 能拿到什麼 | 無法直接證明什麼 |
|---|---|---|
| Google Cloud Gemini Enterprise Agent Platform 的 `compute_tokens` | 部分支援模型的 token、token ID 與 token bytes | 無法直接取得 SynthID key、g-values 或進行浮水印判讀 |
| Gemini API 的 `count_tokens` 與回應中的 `usage` | 輸入與輸出的 token 數量及用量資訊 | 無法單憑 token 數量推斷文本是否含有浮水印 |
| 開源模型的 Hugging Face tokenizer | token ID、token piece、encode／decode 結果 | 不代表 Gemini 也是使用同一套詞彙表 |
| Google DeepMind 的 SynthID-Text 參考實作 | Gemma、GPT-2 等開源模型的生成與檢測範例程式 | 無法直接拿來檢測任意 Gemini API 的輸出文字 |
| 一般第三方 tokenizer 網站 | 特定公開模型的估算斷詞結果 | 不保證與目標產品的 tokenizer 版本或 special token 一致 |

目前 Google Cloud 文件提供了 `compute_tokens` 的呼叫範例，可列出特定模型將文字切分後的 token 與對應的 token ID。該頁面也列出了支援的 Gemini 模型清單，並提醒此功能目前僅支援文字 prompt，多模態（multimodal）的 prompt 則不在該範例的支援範圍內。[5]

而 Gemini API 的 token 文件主要在解釋 token 的定義、`count_tokens` 的計算方式、API 回應中的 usage，以及 context window 與多模態 token 的計算規則。[6] 這與「取得模型完整的詞彙表」是兩回事。獲取某一段 prompt 的 token ID，並不等同於公開了整套模型詞彙表，也無法據此推算出生成時的 logits。

## 如何透過官方 API 取得 Gemini 的 token ID？

在 Google Cloud 文件的 Python SDK 中，可以透過以下方式呼叫：

```python
from google import genai
from google.genai.types import HttpOptions

# 實際執行時，請依 Google Cloud 文件設定自己的認證環境。
# 確保不要將 API key、服務帳戶金鑰或任何憑證寫死在程式碼中。
client = genai.Client(
    http_options=HttpOptions(api_version="v1")
)

response = client.models.compute_tokens(
    model="gemini-2.5-flash",
    contents="今天適合部署嗎？",
)

for info in response.tokens_info:
    print("role:", info.role)
    print("token_ids:", info.token_ids)
    print("tokens:", info.tokens)
```

實際調用是否成功，取決於你所使用的 Google Cloud 入口、模型支援度、SDK 版本以及權限驗證設定。此處程式碼已剔除所有敏感的金鑰與連線資訊。[5]

另外，回傳的 token 可能是原始 bytes 或模型內部的切分片段，不一定符合人類認知的「單字」。這些 token ID 僅在該特定模型與 tokenizer 的 vocabulary 下才有意義，一旦更換模型、版本或斷詞器，同一個 ID 所代表的文字內容就可能完全不同。

## 開源模型的 Token 檢視方式

如果你的目的是研究 tokenizer 與 SynthID-Text 的生成機制，直接使用開源模型會更方便觀察。Hugging Face 的 tokenizer API 可以直接將文字編碼為 token ID，或將 ID 解碼回 token piece。[7]

```python
from transformers import AutoTokenizer

model_name = "google/gemma-2-2b"
tokenizer = AutoTokenizer.from_pretrained(model_name)

text = "今天適合部署嗎？"

ids = tokenizer.encode(text, add_special_tokens=True)
pieces = tokenizer.convert_ids_to_tokens(ids)

for token_id, piece in zip(ids, pieces):
    print(token_id, repr(piece))
```

Google DeepMind 的 `synthid-text` GitHub 儲存庫提供了研究用的參考實作，其 Notebook 以 Gemma 與 GPT-2 為例，並強調該參考實作並非為了生產環境所設計。而 Hugging Face Transformers 庫中，則提供了可以直接嵌入 `model.generate()` 的 SynthID Text 生成元件與相關的偵測器介面。[7][8]

最基礎的呼叫流程如下：

```python
from transformers import (
    AutoModelForCausalLM,
    AutoTokenizer,
    SynthIDTextWatermarkingConfig,
)

model_name = "google/gemma-2-2b"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

# 此處僅示意配置結構，並未包含任何真實的私有金鑰。
# 生產環境中應由安全受控的 Secrets Manager 載入，切勿將金鑰寫入程式碼。
# 下方函式只是示意，本文不提供秘密管理器的實作或任何金鑰。
watermarking_config = SynthIDTextWatermarkingConfig(
    keys=load_private_watermark_keys(),
    ngram_len=5,
)

inputs = tokenizer("請用繁體中文說明部署流程", return_tensors="pt")
outputs = model.generate(
    **inputs,
    watermarking_config=watermarking_config,
    do_sample=True,
    max_new_tokens=128,
)

text = tokenizer.decode(outputs[0], skip_special_tokens=True)
print(text)
```

要成功執行上述程式碼，必須配置正確的 Python 環境並提供有效的私有金鑰，且 `keys` 必須嚴格保密。Google 官方也特別提醒，浮水印的設定檔應妥善保管，否則第三方將能輕易複製並偽造相同的浮水印。[2]

最核心的技術邊界在於：**拿到 token 不等於拿到浮水印。**

要還原或分析浮水印，你至少需要同時掌握：
1. 生成時所使用的 tokenizer 及其具體版本。
2. 模型的 vocabulary 與 logits 分佈。
3. 浮水印的私有金鑰（watermark key）。
4. `ngram_len` 等相關參數設定。
5. 生成當下的抽樣參數（Sampling parameters）。
6. 偵測器使用的訓練資料與判定門檻（threshold）。
7. 目標文字是模型直接輸出，還是已經過後處理。

缺乏上述任一要素，你頂多只能進行一般的斷詞分析，而無法重構出相容的 SynthID-Text 判定流程。

## 「拿到詞元」與「帶有浮水印」是兩碼子事

我們可以將整個機制拆解為三個獨立的層次：

### 第一層：Tokenization（斷詞）

文字被切分為 token 並轉換為 token ID。這是模型處理輸入輸出的基礎結構，大部分的 API 與 tokenizer 工具都能提供這部分的資訊。[5][6][7]

### 第二層：Watermark Generation（浮水印寫入）

模型在生成文本的每一步中，利用私有的浮水印配置來微調候選 token 的抽樣機率，從而在輸出中植入統計特徵。[2][3]

### 第三層：Watermark Detection（浮水印偵測）

偵測器使用相同或相容的斷詞器、參數配置與模型機率分佈來計算分數，並根據設定的判定門檻（threshold）輸出 `watermarked`、`not watermarked` 或 `uncertain` 等結果。[2][7][8]

只取得第一層的 token ID，不可能逆向推導出第二層的金鑰，也無法繞過第三層的演算法直接驗證來源。

## 偵測結果該如何解讀？

SynthID-Text 的判定本質上是統計機率。Google 文件列出的偵測狀態如下：[2]

| 偵測狀態 | 較為精確的解讀 |
|---|---|
| `watermarked` | 在指定的參數與門檻下，該文本呈現出足夠強烈的浮水印統計特徵 |
| `not watermarked` | 在指定的參數與門檻下，未偵測到足夠的統計特徵證據 |
| `uncertain` | 數據落在模糊地帶，無法以現有條件給出可靠的判定 |

這些狀態並不能直接回答「這段文字是誰寫的」：
- `watermarked` 不代表能追溯到特定使用者或特定帳號。
- `not watermarked` 不等於證實該文字為人類親自手寫。
- `uncertain` 並非系統出錯，通常是因為文本過短、格式過於受限，或是文字經過大幅度轉換。
- 市面上的通用 AI 文字分類器，與 SynthID 偵測器的運作原理截然不同。

論文補充資料中也提到了「選擇性預測」（selective prediction）機制：當分數落在判定區間的灰色地帶時，系統會選擇不給出明確結論，藉此控制誤判率（false positive / false negative）。[4]

## 修改、翻譯與重新生成對訊號有何影響？

我們可以從「浮水印訊號是否仍沿著原 token 序列保存」的角度來理解：

| 後續處理方式 | 對訊號的影響 |
|---|---|
| 刪除部分段落 | 雖然可用證據減少，但如果整體篇幅仍長，可能還保留部分訊號 |
| 修改微調措辭 | 訊號會被削弱，但可能不會完全消失 |
| 大幅度改寫 | token 序列與前文脈絡產生劇烈變化，偵測置信度會顯著下降 |
| 翻譯為其他語言 | 因斷詞器、候選分佈與生成路徑被抽換，原始浮水印訊號通常會大幅衰減 |
| 交付另一模型重新生成 | 舊有的浮水印訊號不會轉移；若新模型開啟了自身的浮水印，則會留下新訊號 |
| 混雜人工、模型與多個來源 | 偵測結果可能僅反映部分片段的特徵，使整體判定變得極難解讀 |

這些是技術層面的訊號衰減規律，並非百分之百的規避手段。目前並不存在一個能針對所有模型、所有語言與偵測器，且永遠有效的「去浮水印」方法；而且過度的改寫，也容易損害原文的本意、程式碼的正確性與事實的精準度。[2][4]

## Anthropic 的文字浮水印進展到哪裡了？

Anthropic 在其公開承諾中，確實將「AI 生成內容的技術浮水印」（Technical watermarking of AI-generated content）列為承諾項目之一。[9]

但根據目前公開的資訊，我們還無法證實以下說法：
- Anthropic 已經在所有 Claude 文字輸出中啟用了浮水印。
- Anthropic 採用了 Google 的 SynthID-Text 技術。
- Anthropic 已經公開了完整的文字浮水印演算法或偵測器。
- Anthropic 已經宣布了這項功能在各產品線的正式上線時間。

較為嚴謹的陳述方式是：Anthropic 官方已公開承諾會發展 AI 內容的技術浮水印，但其文字浮水印的具體產品部署進度、演算法細節與偵測工具，仍有待官方後續發布的文件證實。

## 若要進行相關研究，建議記錄哪些資料？

如果想要進行可重複驗證的模型輸出研究，建議完整記錄以下欄位：

```text
模型名稱與版本
產品入口：Gemini App、Gemini Web、Gemini API、Vertex AI 或第三方服務
生成日期
使用的語言與 Prompt
生成參數（如 Temperature、top-k、top-p 等，若產品入口有提供）
斷詞器（Tokenizer）及其版本（若能取得）
是否啟用了浮水印機制
浮水印設定檔的內部識別資訊（請避免直接記錄公開金鑰本身）
原始生成的文字輸出
後續的翻譯、改寫、刪剪或混合外部來源的歷程記錄
偵測器版本、判定門檻（threshold）與最終的偵測輸出狀態
```

請特別注意，`watermark key` 本身絕不應該被記錄在公開筆記、GitHub 儲存庫、部落格文章或對話紀錄中。若有團隊協作需求，可以使用版本代號、雜湊值或權限控管後的引用標記來識別，切勿直接洩漏可還原浮水印的敏感數值。

## 結論與判斷

不同語系並不會各自擁有一張固定的 SynthID 詞元表。其實際的運作機制是：各個模型使用各自的 tokenizer 將文本切分為 token，並在生成每一步的過程中，結合上下文、候選詞彙與私有金鑰設定來微調抽樣概率。中文、英文、日文或阿拉伯文在字面與結構上的差異，底層對應的是截然不同的 token 序列與生成概率分佈，這些特徵最終都會反映在浮水印的訊號強度與偵測的置信度上。[2][3][4]

現階段開發者能取得的相關資料主要分為兩類：
1. **Gemini 相關的 token 資訊**：可透過 Google Cloud 對部分模型查詢其斷詞與 token ID；或是透過 Gemini API 文件取得 token 數量與使用量估算。[5][6]
2. **開源模型的斷詞與生成管線**：可利用 Hugging Face 的 tokenizer，結合 SynthID-Text 參考實作或 Transformers 套件，對 Gemma、GPT-2 等模型進行流程研究。[7][8]

但必須重申，token ID 並非浮水印金鑰，token 列表也無法取代偵測器。要驗證一段文字是否帶有 SynthID，依舊得依賴實際生成時的入口、對應的參數配置、相容的偵測器與統計門檻。對於一般使用者而言，最務實的結論依然是：**Gemini App 與 Web 端是目前 Google 官方明確指出套用文字 SynthID 的範圍，但這並不代表所有 Gemini API、第三方代理服務或任意輸出結果都必然能被驗證。**

與其設法規避浮水印，內容創作者更應先提高文章本身的原創價值。Google 的公開指引要求內容聚焦使用者價值，並鼓勵原創研究、獨特觀點與第一手經驗；這些方向值得拿來做內容 QA，但不能被寫成保證排名的公式。[13][15]

如果「生成來源訊號會被搜尋系統納入評估」這個工作假說最後成立，這種做法也比單純改掉幾個詞更有意義：文章即使被辨識為曾經使用 Gemini 或其他 AI 工具，仍然包含作者實際研究、測試、判斷與可核對來源，而不是只有一層可被替換的生成文字。

## Sources

[1] https://deepmind.google/models/synthid — Google DeepMind SynthID
[2] https://ai.google.dev/responsible/docs/safeguards/synthid — Google AI Developers SynthID Text
[3] https://www.nature.com/articles/s41586-024-08025-4 — Nature SynthID-Text paper
[4] https://media.springernature.com/original/springer-static/esm/art%3A10.1038%2Fs41586-024-08025-4/MediaObjects/41586_2024_8025_MOESM1_ESM.pdf — SynthID-Text supplementary information
[5] https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/capabilities/list-token — Google Cloud list and count tokens
[6] https://ai.google.dev/gemini-api/docs/tokens — Gemini API token counting
[7] https://github.com/google-deepmind/synthid-text — Google DeepMind SynthID Text repository
[8] https://huggingface.co/blog/synthid-text — Hugging Face SynthID Text
[9] https://www.anthropic.com/transparency/voluntary-commitments — Anthropic voluntary commitments
[10] https://developers.google.com/search/docs/fundamentals/using-gen-ai-content — Google Search guidance on generative AI content
[11] https://developers.google.com/search/docs/essentials — Google Search Essentials
[12] https://developers.google.com/search/docs/essentials/spam-policies — Google Search spam policies
[13] https://developers.google.com/search/docs/fundamentals/creating-helpful-content — Creating helpful, reliable, people-first content
[14] https://developers.google.com/search/docs/fundamentals/how-search-works — How Google Search works
[15] https://developers.google.com/search/docs/fundamentals/ai-optimization-guide — Google guide to generative AI features in Search
[16] https://developers.google.com/search/blog/2023/02/google-search-and-ai-content — Google Search guidance about AI-generated content