Gemini 文字浮水印怎麼跨語系運作？從 SynthID 詞元、檢測到可取得性

最近在整理 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]

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

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

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

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 下切出來的結果可能長這樣：

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

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

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

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

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

比較精確的運作邏輯是：

每一步的前文 + 私有 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：

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

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

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

這個過程徹底改變了：

• token 的邊界劃分
• token ID 的編碼序列
• 前文脈絡（context）
• 每一步預測的候選 token 集合
• 句意結構與詞彙選擇
• 生成模型與對應的浮水印配置

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

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

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

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

[!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 文件提供了 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 中，可以透過以下方式呼叫：

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]

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]

最基礎的呼叫流程如下：

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 並非系統出錯，通常是因為文本過短、格式過於受限，或是文字經過大幅度轉換。
• 市面上的通用 AI 文字分類器，與 SynthID 偵測器的運作原理截然不同。

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

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

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

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

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

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

但根據目前公開的資訊，我們還無法證實以下說法：

• Anthropic 已經在所有 Claude 文字輸出中啟用了浮水印。
• Anthropic 採用了 Google 的 SynthID-Text 技術。
• Anthropic 已經公開了完整的文字浮水印演算法或偵測器。
• Anthropic 已經宣布了這項功能在各產品線的正式上線時間。

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

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

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

模型名稱與版本
產品入口：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