昨天寫完 verifier_protocol.py，我在終端機前面坐了很久。

介面訂好了，gpt-oss:20b 還是跑不起來。本機 4GB 顯卡差一個數量級，GB10 不是我能動的機器。照理說下一步應該是去想辦法生出硬體。

但我卡在另一個念頭上：就算明天真的有一台 32GB 的機器送到我桌上，我憑什麼把這顆模型放進一個要讀年報、讀重大契約的系統裡？

規劃書上寫的理由只有一句「不用中國 origin 的模型與工具」。我重讀了一遍，有點心虛。這句話我講過很多次，但從來沒有真的查過。它比較像是我從別人的簡報上抄來的立場，然後一直沿用。

所以今天不寫程式，改做一件比較像稽核員的事：把「信不信任這個模型」拆成可以查的項目，一項一項去翻官方文件，查不到的就老實寫查不到。

本地部署，不等於隱私就沒問題

先講一個我自己以前也搞錯的觀念。

很多人（包括幾個月前的我）會覺得：模型權重下載到自己機器上跑，資料不出內網，隱私就搞定了。權重本身是一堆浮點數，它不會自己連網。

這句話只對一半。

真正會出事的地方通常不在權重，在權重旁邊那一圈東西：載入模型時要不要 trust_remote_code=True、tokenizer 是不是附帶一段自訂 Python、推論框架有沒有預設開啟的遙測、某個「方便」的前處理套件會不會在背景去抓更新。這些都是程式碼，程式碼就可以做任何事。

再往上一層，是授權跟法律。一份年報 OCR 系統，處理的東西可能包含還沒公告的契約條件、關係人名單、員工個資。如果哪天模型的授權方可以片面終止授權，或者你用的模型被主管機關點名，你的系統就得整個重來。這種事跟技術好不好沒關係，但它一樣會讓專案停擺。

所以我對「供應鏈審查」的定義是：這個模型從誰手上來、帶著什麼條件來、出事時誰有權管。不是「感覺這家公司可不可靠」。

四個能查的維度

查了一輪之後，我把審查收斂成四個維度。刻意選的是「能拿官方文件回答」的問題，因為感覺類的問題吵不出結果。

這張表有一個缺點：它沒有「模型好不好用」這一欄。那是故意的。效能是明天要合併進來的另一張表，今天只管「能不能進門」。

我把它寫成一份可以重複使用的檢查清單。每次有新候選進來，就複製一份填。

# supply_chain_checklist.yaml（範例格式，每個候選模型各一份）
candidate: "模型名稱 / 版本 / 下載來源 URL"
checked_at: "YYYY-MM-DD"
checked_by: "誰查的"

training_data:
  disclosure_level: null   # dataset_list / category_only / none
  evidence_url: null
  note: ""

license:
  name: null               # 例如 Apache-2.0、自訂授權
  modified_from_standard: null   # true / false / unknown
  forced_sublicense_terms: null  # 下游是否必須沿用同一套限制
  patent_retaliation: null       # 對授權方提告是否終止授權
  unilateral_termination: null   # 授權方可否片面終止
  export_control_clause: null
  evidence_url: null

jurisdiction:
  legal_entity: null
  headquarters: null
  source_quality: null     # primary（官方登記） / secondary（媒體、百科）

third_party_evidence:
  government_tests: []     # 每筆要有機關、日期、URL
  bans: []                 # 同上

runtime_surface:           # 權重以外、會跟著進系統的程式碼
  requires_trust_remote_code: null
  bundled_custom_code: null
  default_telemetry: null

verdict: null              # pass / pass_with_notes / reject / unknown
unverified_items: []       # 查不到的全部列在這，不准省略

最後那個 unverified_items 是我最在意的欄位。清單最容易騙人的地方，是把「沒查」跟「查了沒問題」都寫成空白。強迫自己把查不到的東西列出來，這份清單才有意義。

Tip：授權條款一定要看全文。我這次就是因為只看了 Day 9 查資料時留下的摘要，差點把一份已經換掉的授權當成現行版本。細節下面講。

runtime_surface 那一段是我後來補的。今天查的三個候選都沒有逐項填這一段，所以它在下面的結果表裡不會出現。放在清單裡，是提醒以後真的要部署時得回來填。

三個候選，實際查出來長這樣

候選是 Gemma-4（目前 OCR 主力）、gpt-oss-20b（規劃中的 Verifier）、Nemotron（備選 Verifier）。

有兩件事跟我原本的預設不一樣，分開講。

Nemotron 的資料透明度，反而是最高的

我原本以為大廠都藏得差不多。Google 只給類別，OpenAI 什麼都不給，那 NVIDIA 大概也是一句「公開網路資料與授權資料」帶過。

結果打開 Nemotron-3-Nano-30B 的 model card，資料集清單一路往下捲，約 141 個。

這讓我有點尷尬，因為我原本在心裡已經幫三家排好順序了，排序依據是「公司名氣」。現在看來那個排序一點根據都沒有。以後要判斷透明度，就是去翻 model card，別用公司大小去猜。

但 Nemotron 也不是沒有坑。

專利報復條款

Nemotron Open Model License 裡有一條：被授權人如果對 NVIDIA 提起專利或著作權訴訟，授權就自動終止。另外還有一條補償條款，第三方如果因為你的使用去告 NVIDIA，你要負責補償。

寫程式的時候誰會去注意這種東西？我平常絕對不會。

可是換個場景想：假設這套 OCR 系統之後是某家公司內部在用，而那家公司剛好跟 NVIDIA 有專利糾紛（半導體產業這不算罕見）。那一天法務一打官司，Verifier 的授權就沒了。系統不會壞，但你在法律上不能再用它。

所以這條我會寫進選型報告，標成「技術上不影響使用，部署前必須先給法務看」。它不是淘汰理由，但它是一個會在很奇怪的時間點爆炸的東西。

順便更正 Day 9：Gemma 的授權已經換了

這是今天最意外的發現。

Day 9 選型時我只盯著 MoE 跟 Dense 的效能差異，授權那部分是用舊印象寫的。舊版的 Gemma（1 到 3n）用的是 Gemma Terms of Use，裡面有強制下游轉授的要求、一份 Prohibited Use Policy，而且 Google 保留片面終止的權利。這在企業法務眼裡是很麻煩的條款。

Gemma 4 已經不是這份了。官方頁面（ai.google.dev/gemma/apache_2）寫得很清楚：改用未修改的標準 Apache 2.0。

這件事不影響 Day 9 的技術結論，但如果有人拿著 Day 9 那篇去跟法務討論授權，看到的是過時的描述。這裡正式更正。

老實說我有點懊惱。我一直在講「查證」，結果自己在授權這種最容易查的地方用了舊資料。清單裡強制要求 evidence_url 就是為了這種情況：沒有網址的欄位，就等於還沒查。

「不用中國 origin 模型」站不站得住

這是我今天最想搞清楚的一條。

我擔心的是：這句話會不會只是業界的政治正確？大家都這樣講，所以我也這樣講。如果它背後沒有具體事件，那放進審查清單就只是偏見。

查完之後，我的結論是它站得住。理由是有日期、有機關名稱、可以追回去的事件：

• 台灣國安局 2025 年實測 5 款中國 AI 模型，用 15 項指標檢查。Qwen（通義千問）違規 11 項，是受測模型中最高的；DeepSeek 違規 8 項。測出的問題包含個資回傳中國企業伺服器。
• 美國商務部 2025-03-17 發全員信，禁止在政府設備上使用 DeepSeek。
• 南韓情報機構指出 DeepSeek 會蒐集鍵盤敲擊的動態模式，並傳回中國伺服器。
• 美國海軍（2025-01-24）、NASA（2025-01-31）、台灣數位發展部（2025-01-31）都發過正式禁令。

Qwen 那一條讓我愣了一下。一般討論比較常點名 DeepSeek，Qwen 在開源圈的名聲其實很好，很多人拿它來做中文任務的 baseline。結果在國安局的測試裡，它的違規項目數比 DeepSeek 還高。

這也是我想講的一個跟主流不太一樣的看法：開源社群評一個模型，看的是 benchmark 分數、授權寬不寬、社群活不活躍。這三件事 Qwen 都表現很好。但這三件事沒有一件回答「資料會不會被送去哪裡」。好用跟可信任，是兩張不同的成績單。

還有一條線我沒追完。有一份叫「No Adversarial AI Act」的美國法案，我只查到二手摘要，原文抓不到，所以不放進結論，只列在未查證。光是上面已經查到的幾件，已經夠支撐這條原則了，不需要靠一份我沒讀過原文的法案來加強。

工具也要一起審

規劃書那句話寫的是「模型與工具」，後面兩個字很容易被忽略。

OCR 這條路上會用到的東西不只 LLM：版面偵測、表格辨識、PDF 解析，每一塊都有現成的開源工具，其中有些是中國團隊開發的。它們不是 LLM，但它們一樣直接讀你的文件。

我的做法是讓工具走同一份清單，只是 training_data 那段可能填「不適用」，重點改看 runtime_surface：會不會連網、有沒有自動下載模型權重、權重從哪個伺服器下載。這部分我今天沒有逐一去審具體的工具，Day 18 組 Pipeline 的時候，每用到一個工具會回來填表。

備選評測：Nemotron 放在哪

規劃書要求做備選模型評測。我得先承認一件事：今天這份「評測」是規格跟授權層面的比較，我沒有下載、也沒有跑過 Nemotron。原因跟昨天一樣，沒有能跑的機器。

在這個前提下，把 gpt-oss-20b 跟 Nemotron 放在一起看，從 Verifier 這個角色的需求出發：

看完這張表，我的判斷是：gpt-oss-20b 繼續當 Verifier 首選，Nemotron 當備選。理由主要是授權。專利報復條款對個人專案無關痛癢，但這系列的目標是做一個能拿進企業用的東西，法務風險低的那一邊比較好推。

但如果哪天要回頭追查「Verifier 為什麼老是放過某一類錯字」，Nemotron 那份資料集清單會比 gpt-oss 的空白有用得多。這個取捨我沒有標準答案，只能先記下來。

查證表

最後兩件要誠實補充。Nemotron 我沒跑過，上面所有比較都來自公開規格跟授權文件。中國 origin 模型的禁令，我用的是媒體轉述，沒有找到每一份禁令的官方原文逐字核對。

兩張表現在各自獨立：Day 11 那張說「跑不跑得動」，今天這張說「能不能進門」。分開看都很清楚，合在一起會不會打架，我還不知道。明天就來疊疊看。