Posts

哈囉，這裡是 DataFox。 如果你最近有來逛 datafox.tw，可能會發現一件事情——我已經從 6 月 12 日開始，就沒有更新任何新的文章了。 很多人也陸續問我：「不是說要寫課程評價嗎？」「AI 新知呢？」「最近怎麼都沒有新文章？」 老實說，不是沒有想法，而是真的太忙了。 這段時間，我除了 Google 實習之外，還同時卡著 AAAI、ICAIF 等三篇論文、產學合作專案，以及研究所的各種研究工作。我也不知道為什麼，原本分散在不同時間的事情，最後全部擠在同一個多月裡。除此之外，我還是希望能維持正常生活：跟朋友見面、運動、睡覺，不要把自己完全燃燒殆盡。於是，經營自媒體自然就被我往後放了。 其實我也不是完全沒有更新。LinkedIn 原本還有持續分享一些 Google 實習和研究上的近況，但最近也因為論文衝刺，不小心斷更了。qq 這陣子，我也一直在思考 DataFox 下一步該往哪裡走。 我曾經想過建立一個 AI 社群，但現在 AI 社群真的很多。我一直在想，我到底能提供什麼別人沒有的價值？ 也許等論文告一段落之後，我會開始分享更多自己真正累積下來的東西，例如研究過程中的觀察、Google 實習的見聞，以及一些 AI 系統設計與研究方法上的心得，而不只是整理新聞或追最新模型。我希望 DataFox 能慢慢長成一個有自己特色的地方。 有趣的是，雖然我已經兩個多月沒有發文，網站每天還是大概有二十位左右的自然訪客。 每次看到 Analytics，我都會提醒自己：原來，還是有人會來。這也讓我更不希望為了更新而更新。 我不希望經營 datafox.tw 變成另一種壓力，或變成必須追著演算法跑的工作。我更希望它是一個能夠長期記錄自己思考、研究與生活的地方。 只是現在的我，還沒有足夠的力氣。 最近每天都被實習、論文、研究和各種 deadline 推著走，甚至連 Podcast 都還躺在待剪清單裡。 不過，這只是暫時的。如果一切順利，這波最忙的時間大概會在 8 月初告一段落。等我把這些事情完成，也把自己整理好，我會慢慢回來。 到時候，再和大家分享這段時間發生的故事，以及下一個階段的 DataFox。 謝謝還願意偶爾來這裡看看。

最近的生活真的是忙到焦頭爛額，一邊在水深火熱地幫論文補數據，另一邊的實務合作專案也遇到了一個非常真實、且極度折磨人的工程挑戰。 這篇文章不談太具體的商業邏輯，單純來聊聊我們在系統架構上踩到的一個巨大效能坑，以及一個工程師在 Debug 卡關時，到底會做出什麼荒謬的紓壓行為。 平行運算的魔法失效了？ 這個專案的底層架構，是一套由 Python 負責前端策略處理、交給 Java 核心引擎進行高速運算的系統。 原本的運作模式是非常安分守己的「序列化」。也就是說，系統必須等第一天的巨量資料跑完好幾分鐘，才能接著跑下一天。看著伺服器那精美的多核心 CPU 閒置在那邊，身為一個對效能有追求的工程師，我當然不能忍，於是決定發揮平行化程式設計的技巧來榨乾硬體效能。 結果，意外發生了。我原以為加上 Parallel 就像施了魔法一樣會自動起飛，但我剛查了 Log 卻發現，即使我非常保守地只開了 2 個 Worker，平行運算依然華麗地失敗、整個系統直接崩潰斷線。(我先嘗試6然後4然後2 都失敗) 傲嬌的 Java 引擎與慢郎中 Python 看著滿螢幕的錯誤訊息，我一開始的判斷是：「這 Java 核心引擎也太傲嬌了吧！」 錯誤代碼顯示的是 SocketTimeoutException。我當下的推論是：這套 Java 引擎對於「通訊延遲」有著極其嚴格的限制。當伺服器同時跑兩套 Java 引擎和 Python 腳本處理全日版的龐大資料時，瞬間的 CPU 爭奪造成了延遲。Python 無法在規定的「微秒級」時限內把成千上萬筆的資料傳過去，所以 Java 引擎就直接無情地把連線切斷了。 聽起來很合理對吧？但身為一個對技術抱持懷疑態度的人，我總覺得哪裡怪怪的。底層的資源競爭真的會讓通訊慢到觸發 Timeout 嗎？ 於是我繼續往下深挖，把平行版斷線的 task.log 徹底翻了一遍。結果迎來了史詩級的劇情反轉： Java 引擎是無辜的，真正的戰犯，其實是 Python！ 史詩級的 JSON 效能慘案與修復 真相大白。SocketTimeoutException 雖然是 Java 拋出的，但根本原因在於：Python 內建的 json.loads() 處理速度實在太慢了。 在資料的巔峰時段（例如某些流量爆衝的極端日子），每 5 分鐘就會有一波極其龐大的狀態 JSON 湧入系統。當 6 顆 Java 引擎同時把海量 JSON 砸向 Python 時，Python 原生的解析器根本來不及消化。這導致 Socket 直接塞車堵死，最終 Java 引擎在對面苦苦等不到回應，只好無奈地強制切斷連線。 ...

在建立這個個人網站的過程中，我一直有一個兩難：我希望能用自己最熟悉、最有溫度的母語（繁體中文）來記錄與創作，但同時，我也渴望與世界接軌，讓更多英文母語者或是對我的技術文章感興趣的國際讀者，有機會看到這些內容的潛力。 此外，從技術部落格的經營角度來看，雙語內容對於搜尋引擎優化（SEO）也有著顯著的幫助，能夠為網站帶來更廣泛的自然流量。 為了解決這個問題，我沒有選擇花費大量時間手動翻譯，也沒有強迫自己改變寫作語言，而是決定利用 AI 的力量來自動化這個流程。 專注於創作，把翻譯交給 AI 我最近在網站上實作了一套基於 GitHub Actions 與 Gemini API 的自動化翻譯工作流： 維持原本的寫作習慣：我只需要專注於用中文撰寫 Markdown 文章。 自動觸發翻譯：每當我把新文章 push 到 GitHub 上，GitHub Action 就會在背景自動執行 Python 腳本。 Gemini 接手處理：腳本會掃描尚未有英文版本的文章，呼叫 gemini-2.5-flash 模型，自動將內文精準翻譯成流暢的英文。 自動更新網站：翻譯完成後，腳本會自動把內容包裝成中英文切換的 HTML 區塊，並將修改直接 commit 回 repository。 現在，你在這篇文章（以及網站上的其他文章）上方，應該能看到一個「🌐 切換為英文 (Switch to English)」的按鈕。這一切都是自動發生的，我完全不需要介入。 這樣一來，我不僅保留了寫作的純粹與樂趣，也同時賦予了這個網站觸及全球讀者的能力。 未來的計畫：走向更現代化的架構 雖然目前的做法已經能很好地滿足「專注創作＋自動翻譯」的需求，但我知道這個網站還有進步的空間。 為了提供更好的閱讀體驗與效能，我之後會繼續嘗試將網站架構遷移到更輕量化、載入速度更快的 Astro.js，並結合 Astro 原生的地區適應（i18n / Localization）功能，讓雙語切換不僅僅是內文的隱藏與顯示，而是從網址結構、Metadata 到介面語系都能完美適配的現代化架構。 世界很大，語言不該是我們分享知識的障礙。接下來，就讓 AI 繼續幫我把這些文字，翻譯給更多需要的人吧！

如果剛才有在關注這個網站的讀者，可能會發現網站在幾個小時內經歷了一次劇烈的「陣痛期」——也就是切換語言時畫面直接一片空白死機。 但經過一番搶修與大改版，我很高興地宣布：這個網站已經正式升級為「原生雙語架構 (Bilingual Native)」了！ 拋棄 Hacky 的 CSS 隱藏法 在上一篇文章中，我提到使用 AI 來自動翻譯文章。當時的做法其實非常「Hack」：我讓 Python 腳本把翻譯出來的英文，跟原本的中文一起塞在同一個 Markdown 檔案裡，然後利用自訂的按鈕和 CSS 的 display: none 來強制隱藏或顯示對應的語言區塊。 這種做法雖然快速，但遇到了不少致命缺點： 排版容易崩潰：如果文章裡面有複雜的 HTML 標籤（比如置中圖片的 <div>），腳本的 Regular Expression 一個不小心就會把文章直接從中間「截斷」，導致整個網頁 HTML 結構壞死（這也是剛才網站全白死機的元兇）。 對 SEO 極度不友善：搜尋引擎爬蟲一次會把中英文全都爬進去，它根本不知道這個網頁到底是什麼語言。 遷移困難：未來如果我要把網站搬家到效能更好的 Astro.js，這種充滿自訂標籤的單一檔案絕對是一場災難。 擁抱 Hugo 原生多語系 (i18n) 痛定思痛後，我決定花點時間，把架構徹底重構成最標準、最正規的做法——使用 Hugo 內建的 i18n (Internationalization) 機制。 1. 檔案物理分離，保持純淨 現在，我依然只需要專心寫純中文的 Markdown 文章（例如 article.md）。 當我把文章 Push 到 GitHub 時，背景運行的 GitHub Actions 與 Gemini API 會自動偵測這篇新文章，並把它的標題、摘要、內文全部翻譯成流暢的英文。 最關鍵的差異在於，腳本不再把英文塞回原本的檔案，而是自動產生一個獨立的 article.en.md 檔案。這讓我的中文原始檔保持絕對的乾淨，沒有任何多餘的程式碼干擾閱讀或後續編輯。 2. 全站雙語化與 SEO 提升 受惠於原生架構，現在不只是「單篇文章」有英文版，而是**「整個網站」都有了專屬的英文空間**！ ...

從 Geoguessr 的「找膠帶」玄學，看深度學習的捷徑學習（Shortcut Learning）迷思，我們如果太依賴某特徵會發生什麼事情？ 1. 那些被丟在荒郊野外的日子：Vibe Guessing 的浪漫 自從結束交換學生的日子後，我意外迷上了 Geoguessr 這款遊戲。它的魅力在於不用下載任何 App，打開瀏覽器就能隨時隨地被「隨機空投」到世界某個角落。在玩這款遊戲時，我不僅能複習曾經走過的街景，還發現自己漸漸長出了一種超能力——「Vibe guessing（直覺流）」。 多虧了在歐洲遊走的經驗，我開始能用直覺去感受一個地方的「氣味」：不依賴那些主流的meta側面破解技巧，而是靠著建築的冷暖色調、路邊植物的生長姿態，甚至是一種難以言喻的「破敗感」或「秩序感」來定位。雖然這種黑盒子演算法偶爾會讓我大落漆（把南美洲猜成東歐之類的），但這種真正用雙眼去感受地理的過程，才是遊戲靈魂。 2. Meta 玩家的玄學：現實世界沒有長著涉水管的 Google 車 但與此同時，我對 Geoguessr 圈內極度推崇的「Meta 策略」抱持著高度懷疑。 什麼是 Meta？高階玩家被丟到荒郊野外時，他們第一時間不是看風景，而是低頭看 Google 街景車。他們透過記憶 Google 街景車在各國的收錄瑕疵來上分： 「車頂有黑膠帶？這絕對是迦納。」 「車頭右邊有一根涉水管？不用看了，肯亞。」 「天空有明顯的第三代鏡頭接縫光暈？定位塞內加爾。」 這確實很聰明，也是遊戲規則內的完美必勝法。他們繞過了真正需要龐大知識量的地理分析，直接破解了題庫。但荒謬的是，如果今天把這些 Meta 玩家丟到真實世界的肯亞，他們會迷路—— 因為現實中的肯亞街頭，並沒有那台長著涉水管的 Google 街景車跟著他們。 3. 演算法也是個功利的玩家：什麼是 Shortcut Learning？ 把場景換到 AI 領域，深度學習模型其實就是個死命想上分的 Geoguessr 玩家。 不管是在電腦視覺還是對抗性攻擊與防禦（Adversarial Attack/Defense，我最近跟者羅紹元老師的腳步在研究）中，模型唯一的目標就是把 Loss 降到最低。它才不管什麼大局觀，只要能最快達到目的，它就會毫不猶豫地走捷徑。 這在機器學習裡被稱為 捷徑學習（Shortcut Learning） 。 模型並沒有學會我們期望它學會的「真正特徵」，而是學到了「資料集裡的統計相關性（或是瑕疵）」。只要這個帶有強烈訊號的捷徑特徵一消失，模型的預測能力就會瞬間崩盤，毫無泛化性（Generalization）可言。 4. 殺傷力極強的隱形炸彈：相關性不等於因果關係 Shortcut Learning 在機器學習各個領域都是個災難，而且它比我們常說的Overfitting更難被發現、殺傷力更高。 Overfitting 是模型死背了訓練集，但在驗證集就會露餡。但 Shortcut Learning 可怕的地方在於，如果你的驗證集也包含了同樣的瑕疵，模型的表現會堪稱完美。 這就像經濟學和統計學裡常被拿出來鞭的鐵則：「相關性不代表因果」。模型只看到了高度相關，卻搞錯了因果。 套用回 Geoguessr 的比喻：如果哪天 Google 官方來個大更新，用 AI 把所有街景車的特徵、天線、膠帶全部 P 掉，那些高度依賴 Meta 的玩家積分絕對會迎來史詩級的雪崩。 ...

最近在盤點 datafox.tw 的後台數據時，我發現了一個非常殘酷的現實：我花了大把時間寫的某些硬核技術文章，在搜尋引擎和 AI 爬蟲的眼裡，幾乎是隱形的。在 2026 這個 AI SEO 與 GEO（Generative Engine Optimization，生成式引擎最佳化）主導注意力的時代，我忘記以EEAT為核心，這是一個非常致命的戰略失誤。 🔍 根本問題：我正在嘗試跟全世界最強的巨頭搶同一個關鍵字 我之前寫過一篇探討 flash vs thinking kv cache test time compute 的文章。我以為這篇技術含量很高，應該能獲得不錯的自然流量。結果呢？數據一片死寂。 原因很簡單：這是一個純粹的「主題型」關鍵字。當使用者或 AI 去搜尋這個詞時，我這個剛建立不久的 datafox.tw 新網域，要面對的競爭對手是誰？是 arXiv 上的頂級論文、是 Pure Storage 的官方技術部落格、是 Substack 上累積了大量反向連結的資深 AI 研究者。在這些權重極高的巨頭面前，我的文章就算寫得再好，也只會被淹沒。 對比之下，那些帶有我個人標籤的搜尋，例如 datafox llm 或 datafox ntu，我卻能穩穩佔據第一。這揭示了一個殘酷的事實：如果文章沒有綁定「你是誰」，那它就只是一篇隨時可以被取代的普通科普文。 🦊 資訊是可取代的，但「實體」不行 AI 時代，知識的獲取成本已經趨近於零。如果我只寫一篇「如何用 GitHub Actions 自動化更新網站」，這件事 AI 隨便都能幫你生成出十幾種完美版本。 但什麼東西是 AI 暴力破解也學不來的？是脈絡性與個人經驗。 同樣是自動化更新，如果我寫的是：「這隻叫 Datafox 的狐狸，他是怎麼一邊在台大讀資料科學，一邊在 Google 實習，並用這套自動化系統搞定他的周報？」 這種帶著真實血肉的經驗，AI 搬不走。 在未來的 AI 知識圖譜裡，我不需要成為全網最懂 GitHub Actions 的人，但我可以精準搶奪到「自動化 + 資料科學碩士」這組獨一無二的標籤交集。 ...

在深入研究 LLM 應用與 Agent 系統的過程中，我實在對業界那種「AI 馬屁精」式的玄學行銷感到反胃。現在廠商動不動就愛吹自家的新模型「會思考」、「有邏輯」，彷彿加了一個 “Pro” 或 “Thinking” 的後綴，神經網路就突然長出了人類的大腦。我們如果不採取懷疑與質問的態度，很容易就會被這些漂亮話牽著鼻子走。今天我們就冷酷地從底層運作機制與物理限制出發，拆解 Flash 模型與 Thinking 模型真正的差異，以及那些所謂的「思考過程」到底是什麼。 1. 根本不是「想久一點」：訓練目標與機率分佈的差異 很多人以為 Thinking 模型只是 Flash 模型跑得比較久，或者我們透過 Prompt 叫它「你想仔細一點喔」。這完全是個誤解。 Flash 模型的訓練目標是追求極致的推理速度與低延遲，它依賴強大的壓縮記憶和直覺式的 Pattern Matching。而標榜推理的 Thinking 模型，是在訓練階段引入了大量的RL，被「刻意訓練」成在給出最終答案前，必須先產生一長串的內部推理軌跡（Chain of Thought）。 無論是哪一種，它們本質上依然是在做 Next-Token Prediction。我們來看自迴歸生成最核心的機率公式：P(Y | X) = 根據過往生成的X個token 預測目前要接龍的下一個token Y的sampling長什麼樣子。 給定輸入 X，模型每一步都是在計算下一個 Token y_t 的最大條件機率。Thinking 模型並沒有跳脫這個框架，它只是被訓練成在生成最終答案的 y 之前，先利用這個公式接龍出一大堆中間步驟。 2. KV Cache 的暴力美學：破除「重新計算」的直觀迷思 既然是接龍出思考過程，這就帶出了第二個嚴重的迷思。很多人直觀地以為，Thinking 模型的運作方式是： 原始問題 -> 產出思考步驟 1。 接著把「原始問題＋思考步驟 1」整包重新餵給 Transformer -> 產出思考步驟 2… 就這樣像俄羅斯娃娃一樣越疊越大。 如果真的是這樣運作，GPU 的算力早就原地爆炸了。真正的底層魔法，在於 KV Cache（Key-Value Cache）。 ...

當時的我會覺得，Decoder 說穿了根本只是看著輸入做「文字接龍」，沒辦法預先知道整體要生成什麼。但現在回頭看，如果我們不跟著那些 AI 馬屁精瞎起鬨、講一些「因為 GPT 比較有靈性」的漂亮話，而是冷酷地從Information Theory與工程現實的底層來拆解，你會發現 Decoder-only 的勝出，根本是一場數學與物理限制下的必然。 1. 統一架構的暴力美學：交叉熵與自作聰明的代價 Seq2Seq 雖然邏輯清晰，但它把「理解」與「生成」拆成兩個模組，其實在數學目標函數上「自我閹割」了資訊壓縮的純粹性。 我們回到機率與資訊理論最純粹的定義——熵的鏈律（Chain Rule for Entropy）： $$H(X_1, X_2, \dots, X_n) = \sum_{i=1}^{n} H(X_i | X_{i-1}, \dots, X_1)$$ 這條公式告訴我們，要量化一段人類語言的總體不確定性，最完美、最無損的拆解方式，就是去計算「在給定所有歷史資訊的情況下，下一個字的條件熵」並全部加總。 而 LLM 每天在跑的 Next-Token Prediction，其損失函數本質上就是最小化真實世界人類語言分佈 $p$ 與模型預測分佈 $q$ 之間的交叉熵（Cross-Entropy）： $$H(p, q) = H(p) + D_{\text{KL}}(p \parallel q)$$ 這裡面的物理意義非常優雅：$H(p)$ 是「上帝的熵」，人類語言本身自帶的終極亂度；而 KL 散度 $D_{\text{KL}}(p \parallel q)$ 則是模型因為不夠聰明，導致我們在進行接龍時，平均每一步要多付出的資訊代價（雜訊）。優化模型的終極目標，就是要把這個代價逼近到 0。反觀 Seq2Seq，它偏要把這個統一的優化任務拆開，用雙向 Attention 去搞 Span Corruption（挖空填空），再用 Cross-Attention 去撈 Embedding。這打碎了能量化一切的條件熵鏈律，讓參數空間的優化目標變得極度不純粹。 2. 質問：我們真的希望 KL 散度歸零嗎？ 好，這時候如果有人舉手質問：「照你這樣說，我們希望 $D_{\text{KL}}$ 越低越好，那終極目標不就是讓它等於 0？如果模型分佈跟人類真實資料採樣完全一模一樣，那它不就只是個死記硬背的隨機鸚鵡？你們天天掛在嘴邊的『湧現能力』到底從哪裡蹦出來的？」這個質問，就是解開 Decoder-only 勝出謎題的終極鑰匙。 ...

「如果要通往圖靈機的路上，Seq2Seq 本身比 Decoder 還要合理。」這是我在 2022 年的筆記裡寫下的一句話。 當時我試玩了早期的 GPT-2，心裡總覺得：這到底是個什麼東西？相比之下，基於 Seq2Seq 概念的 BART 或是 T5 看起來合理太多了。沒想到幾年後的現在，在這場 AI 軍備競賽中，竟然是 Decoder-only 架構拿下了 MVP。 當時的我會覺得，Decoder 說穿了根本只是看著輸入做「文字接龍」。它沒辦法預先知道自己整體要生成什麼，只能不斷在 Sample Space (樣本空間) 中選擇「現在這個情況下，下一個字機率最大的是誰」。 相較之下，Seq2Seq 才是完整使用 Transformer 架構的「好學生」： Encoder 負責看懂整個句子架構，並生成富含語意細節的 Embedding。 Decoder 應用 Encoder 給的全局上下文 (Context) 來輸出序列。 這樣的分工聽起來超合理，對吧？但為什麼現在的發展卻完全偏向了 Decoder-only？以下是我後來自己的反思，以及結合近期與 AI 討論後整理出的幾個關鍵原因。 1. 統一架構的暴力美學：Scaling Law 與目標函數 Seq2Seq 雖然邏輯清晰，但它把「理解」與「生成」拆成了兩個模組。Encoder 負責理解並產生針對細部觀念的 Embedding。這其實帶來了一個隱形的代價：訓練目標的不一致。 Seq2Seq 常常使用 Span Corruption（例如把一段話挖空，讓 AI 填空，類似 BERT/T5 的作法）來預訓練；而 GPT 則是貫徹到底的 Next Token Prediction (預測下一個詞)。 後來的事實證明，當模型參數規模放大到百億、千億等級時，遵守 Scaling Law (規模法則) 的 Next Token Prediction 是最能榨取資料價值的「目標函數」。當我們要壓低 Loss Function，讓 Decoder-only 的模型表現越來越好時，因為要預測下一個字足夠準確，模型被迫要在內部「模擬」出整個世界的邏輯、常識甚至物理規律。 ...

在〈datafox 竣工後記〉裡，我很自豪地介紹了我怎麼用 JSON-LD 做 AI-SEO、怎麼把 Person Schema 埋進 extend_head.html 裡讓 Perplexity 認識我、怎麼讓 AI 搜尋引擎理解我的技術邊界。我當時覺得我在做很厲害的事情。 在大概兩個月後我打開 Google Analytics，發現一個問題。 我的流量，幾乎全部來自我自己推。每次發文 → 丟 LinkedIn → 丟群組 → 流量來一下 → 消失。 自然搜尋？幾乎零。幹我超難過的，之前在medium發文都可以吸引到自然流量，但是我這裡幾乎沒有，可憐。 一、我到底漏掉了什麼？ 這件事讓我有點汗顏，因為我之前寫過的那篇 SEO 文章，某種程度上也在教別人怎麼做 SEO。但是我忽略了一個超大的問題，也就是，我做了「AI 時代的進階 SEO」，但跳過了最基本的那幾件事。 譬如說，我的文章 URL 長這樣： https://datafox.tw/posts/260303_2222/ 這串數字對 Google 來說毫無意義。Google 不知道這篇文章在講什麼，所以也沒辦法在有人搜尋相關關鍵字時把它推出來。Medium 之所以能搜尋到，原因之一就是 Medium 的 URL 長這樣： https://datafox-tw.medium.com/datafox-竣工後記-2026-個人網站實戰指南-從-想要一個網站-到真正上線-3ae9d5a615b7 一眼就知道在講什麼。 然後是文章的 description。我翻了一下，25 篇文章裡有 17 篇是空白的。 description: "" 這代表 Google 抓到我的文章時，不知道要在搜尋結果裡顯示什麼摘要。只能自己猜。猜出來的東西通常不太好看，點擊率自然也不高。 再來是，我根本沒有主動告訴 Google 我的網站存在。robots.txt 有、sitemap 有，但我從來沒去 Google Search Console 提交過。我之前都只知道ga4，但是我沒有去gsc，讓我的自然流量門可羅雀，尤其這件事情根本只要三分鐘就搞定了 二、今天做的四件事 2.1 讓 URL 說人話 在每篇文章的 front matter 加上 slug，讓新的 canonical URL 帶有關鍵字： ...