這兩台機器是元培醫事科技大學的研究設備，不是我自己的。我獲得使用權，並用它們來回答一個整年都在腦中打轉的問題：那些只能透過付費 API 取得的東西，我能不能在一台就放在房間裡的機器上重建出來？
大致上可以。但真正的收穫不在於模型跑不跑得動，而在於「在終端機裡跑成功一次」與「連續好幾週不需要任何人碰它」之間的距離。我幾乎所有的力氣都花在這段距離上。
學校的問答助理是我訂下最嚴格規則的專案：寧可不回答，也不要答錯。一個會編造報名截止日期的校園機器人，比沒有機器人更糟。所以當檢索分數不足時，它會保持沉默而不是猜測。每則答案都附上它讀過的那一頁連結，以及該版本匯入的日期。
翻譯 API 上，我做了一件人人都該做卻很少人願意做的事：先量測，再選擇。三個模型同一份考題，每個模型 52 個樣本，溫度為零，題目與參數在執行前就鎖定，以免有人照著結果調整。
最令我意外的是表格的最後一列。名稱裡帶有 Taiwan 的那個模型，照理說是理所當然的選擇，卻把日期搞錯、句子中途換語言、漏掉整句。它是表中最快的，卻幾乎無法用於這件事。如果我依名字而不依數據來選，我就會把整個 API 建在三者中最差的模型上。
困難的不是模型，而是它外面那層殼。中途被截斷的翻譯是最危險的失敗，因為它看起來和成功的翻譯一模一樣。所以 API 會為未完成的翻譯回傳錯誤碼，而不是高高興興地交回半句話。
煙霧偵測器花掉最多時間，也是最多人不相信是我自己做的。我從零寫起，沒有建立在現成框架上。原因是：煙霧沒有清楚的邊界，合併重疊框的步驟容易吞掉稀薄的煙；而在火災警報這件事上，一次誤報的代價高於一次漏報 — 誤報幾次，人們就會把系統關掉。
所以我的架構沒有合併框的步驟。它直接預測，一個物件一個框。這拿掉了一道容易出錯的後處理，也讓執行時間穩定，而不隨畫面中物件數量而變。
把模型變成系統，關鍵在一條很土的規則：數到三再喊。系統只有在連續多個畫面都看到煙霧時才警報，而不是第一個畫面就喊。一隻飛過鏡頭的鳥或一道閃過的陽光，過不了這道濾網。
只講勝績的作品集不值得信任。以下是還沒完成的部分：學校的助理運行穩定、引用正確，但我還沒寫完標準題組，所以拿不出回答品質的數字。煙霧偵測器只見過測試集，從未面對過整夜運轉的真實攝影機。翻譯評分是我自己組織的，不是由獨立譯者盲測。而且我沒有外部監控系統，所以沒有資格引用任何運行時間的數字。
這一年下來我的心得聽起來很無趣：應用 AI 的難處很少在模型本身。它在於決定系統何時該保持沉默、在於先量測再選擇，以及在於願意寫下一行字說：這個我還沒做完。