AI Project Strategy：三四個小時的試算表，省掉幾週的錯方向

🌏 English version

上一篇講了強化學習與 RLHF。這一篇回到最實務的一端。

本篇對應 Lecture 6: AI Project Strategy（2025/10/28，Andrew Ng 主講，1 小時 15 分）。

先提醒一件事：官網 syllabus 的 Lecture 6 條目寫的是「職涯建議／論文閱讀／醫療 AI 客座」配 2024 年的投影片——那是過期的。實際錄下來的整堂課是 AI Project Strategy，開場第一句就是 "continue our discussion on AI project strategy"。職涯是 Lecture 9。

這一講用兩個例子：前半是語音控制檯燈的喚醒詞偵測（end-to-end 單一模型），後半是 AI deep researcher（多元件 pipeline）。後半那段是全系列最能直接搬到 LLM 應用的內容。

為什麼要教這個

「懂演算法很重要……但真正驅動效能的，是一個團隊擁有高效開發流程的能力。超參數怎麼調？資料怎麼收？試了第一次不成功——而它通常不會成功——**你下一步做什麼？**做這些決策的技能，往往造成字面意義上的 10 倍生產力差距。」

「我看過很多知名品牌公司的團隊，花一年做一個更有能力的團隊一個月就做完的專案。」

為什麼這件事特別難學：

「你在公司可能一兩年才換一個專案。所以你要花一兩年的人生才多累積一個專案的經驗，十年之後你終於看過十個專案。」

所以這堂課的目的是壓縮經驗累積——一堂課帶你走過幾個他親身經歷過的專案的簡化版。

前半：語音控制檯燈

產品想法：買一盞檯燈，它本身就有名字（叫 Robert），插上電就能說「Robert, turn on」，不用設定 Wi-Fi、不用連手機、不用雲端。做法是做一顆小 IC 賣給檯燈廠商。

這是他和朋友幾年前真的討論過的新創點子，因為手上有另外兩個更興奮的想法所以沒做。他自己辦公室裡就有一堆有名字的語音裝置，連升降桌都有名字。

（反諷的自白：「我做了那麼多智慧音箱，我家裡卻有很長一段時間只有一顆燈泡連上 Wi-Fi，因為設定實在太麻煩了。」）

他會先做什麼：文獻搜尋，不是寫程式

先給一個領域知識：通用語音辨識到今天對「幾美元的邊緣裝置」來說仍然太重，但只偵測一個固定詞組，用相當小的網路就能做到。

然後：

「如果我第一次做這個，我第一件事其實會是文獻搜尋。」

令人意外的事實：智慧音箱存在超過十年了，至今學界仍沒有一個公認最好的 wake word 架構，文獻上仍是各說各話。

怎麼做文獻搜尋（很具體，可直接抄）：

❌ 錯的做法：把論文一讀到 100% 讀完，再把論文二讀到 100%。

✅ 他的做法：幾次搜尋拉出一把資源 → 全部只略讀 → 略讀過程中發現引用，順藤摸瓜 → 找到那篇真正關鍵的（可能是第七篇）→ 才投入時間讀透。

「你真正讀完的資源數量非常少，但你花大量時間在跳來跳去、對更廣的一批論文建立粗略理解。」

去找專家（他說 Stanford 學生嚴重低估這招）：先做完自己的功課，然後寫一封有禮貌的信給論文作者。

「與其我再自己卡四個小時……很多人看到你已經做了功課、不是什麼都沒做就來煩他們，是會願意幫忙的。」

「寄一封信花你十分鐘，也許有 50% 的機會收到回覆。不是 100%，但這個 ROI 常常非常高。」

資料：網路上不存在「有人說 Robert turn on」的資料集

必須自己收。Ng 對隱私講得很直白：「隱私很重要，同意很重要。**不要做鬼祟或奇怪的事。**清楚說明你在做什麼，徵求同意，不給也沒關係。」

合成資料可以用，但不是第一步——理由講得很好：

1. 很難知道合成資料相對真實資料有多準
2. TTS 的聲音數量有限，要湊到足夠的人聲多樣性很麻煩
3. 太多超參數要調
4. 「你腦後永遠會有個聲音在想：這批合成資料是不是有什麼我沒想到的怪異之處？」

電玩車輛的故事（很好用的反例）：做自駕要偵測車輛，很多人會想「去電玩裡抓車的圖」。但一款擬真電玩可能整款只有 20 種車——對人類玩起來完全正常，因為擬真不需要一千種車；但真實道路上的車款豐富度差了好幾個量級。

資料設定：0 個測試集

他團隊真的這樣做：100 個訓練音檔、25 個 dev set、0 個 test set。

「如果我的目標只是做出一個能用的系統、而不是發論文，我常常不做 test set。只有 training set 和 dev set，然後我毫不愧疚地把系統調到 dev set 上。要發論文才需要乾淨無偏的 test set。」

「Robert turn on」大約一秒；用 3 秒窗口滑過 10 秒音檔，窗口結尾剛好是講完的瞬間 → 標 1。100 個音檔 × 每個切 30 個窗口 = 3,000 筆二元樣本。

撞牆一：97% 準確率，但它從來沒偵測到任何東西

「我們訓出了一個很大的神經網路，而我用那一行 Python 就能得到一模一樣的結果。」（print 0）

正負比是 1:30。他給的不平衡經驗法則很實用：

比例	他的反應
1:2	完全不擔心
到 1:10	開始有點擔心，可能會做點平衡
1:30（本例）	就爆掉了

學生提的解法：複製正例、給正例更高權重、懲罰 false negative、減少負例（Ng 補充這招的小缺點：會降低負例的多樣性）、加噪音。

他團隊實際用的 hack：不是複製正例，而是把正例的時間窗口拉長——從「過去 100 毫秒內講完」放寬到「過去半秒到一秒內講完」。這樣同一段音檔會產生好幾個位置不同的正例窗口，比單純複製多了一點多樣性。

他很誠實：「我告訴你這個不是因為它是什麼我引以為傲的高明技巧，而是因為我想讓你看到真實的商用機器學習團隊實際用的那種 hack。」

撞牆二：訓練集 95%、dev set 30%

overfitting → 先試 regularization，然後補資料。

這裡他岔出去講訓練/測試分佈，很重要：

「機器學習早期一直有個執著：訓練集、dev set、test set 要同分佈。我想那是因為同分佈比較好證明定理——從發論文的角度來說，人生會好過很多。

但從實務角度，你的訓練分佈常常就是和測試分佈不一樣，這就是人生。」

具體到這個案例：用 TTS 可以生出巨大的訓練集，但代價是——「使用者不會用合成語音說話，他們用真實語音說話。」 所以 test set 一定要放真實資料。

最後真的有效的合成資料，以及它的陷阱

聲音會相加——把兩段波形直接相加，聽起來就像那句話在那個背景噪音下被說出來。所以：背景噪音（線上大量存在，要看授權條款）+ 幾段乾淨的「Robert turn on」→ 相加 → 大量正例。

⚠️ 但這裡有個陷阱，是本講最漂亮的一個洞見：

「如果你完全照我剛講的做，你不會得到一個 Robert turn on 偵測器，你會得到一個語音活動偵測器。因為背景噪音很多，而唯一有人說話的時候說的都是 Robert turn on，那模型只要判斷『是不是有人在講話』就好了，那比真的辨識詞容易太多。」

解法：也要合成一堆人講別的詞的樣本。

（背景音樂那題他的答案是多樣性優於猜對：與其賭使用者聽古典還是 EDM 而選窄，不如全收——前提是網路夠大。）

「機器學習的工作流比較像除錯，不像開發」

「寫傳統軟體時你控制所有程式碼，所以寫個 spec 然後照做、大致就會動；當然還是要 debug，但那些 bug 是我自己的 bug。

相對地，建機器學習系統比較像是——我不知道接下來會發生什麼。所以機器學習的工作流感覺上比較像除錯，而不是開發。」

而且如果任務是人類做得到的，「bug」通常就是人類明顯做得到、但 AI 系統做不到的那些事。

每日節奏

時段	做什麼
早上	看昨晚訓練結果，做 error analysis
下午	寫程式修昨天發現的問題
傍晚（下班前）	啟動訓練任務
夜間	訓練跑約 4 小時

「如果你能一天修掉一個問題，那其實相當好。」

反面對照寫得很生動：

「有些團隊早上醒來想『嗯，我們接下來要做什麼？喔，下午開個會吧。等等，資料在哪？好吧，那明天開會看資料。』然後『喔，我們的 infra 掛了。』」

訓練時間決定整個流程的設計

訓練一次要多久	工作型態
10 分鐘	訓練→拿杯咖啡→回來分析。瓶頸變成你分析與拿資料的速度
4 小時	不想等，但跑一整夜剛好 → 每日迴圈
3 週	啟動然後「祈禱」。會監控、會非同步啟動好幾個任務，通常另外花 1–2 週分析才啟動下一輪

專案會遷移：一開始 10 分鐘，資料變多變 4 小時，再變 3 週，「後來變成一個半月」。

checkpoint 的用法：跑三週的任務，你會預期一兩天後應該到某個水準；差很多就在燒掉另外兩週之前先問「learning rate 是不是明顯錯了」。真的砍掉任務「非常少發生」。transfer learning 是縮短迴圈的工具。

為什麼他對速度這麼執著

橫軸月份、縱軸錯誤率。如果競爭對手做每件事都花你兩倍時間：

「顧客在某個時間點在意的是——你比他們好太多了。

你可能會想『我花兩天，他花一天，有什麼大不了？』大不了的不是你慢了幾天，是你慢了兩倍。」

後半：AI deep researcher 的 pipeline

從 end-to-end 單一模型換到多元件 pipeline。

早期的線性架構：

查詢 →（LLM 生成搜尋詞）→ 網路搜尋引擎 →（LLM 讀 snippet 挑要抓哪幾頁）→ 抓取網頁 → 寫作 → 輸出

他的觀察：「越來越多網路搜尋引擎是為 AI 設計的，而不是為人類設計的，我覺得這滿妙的。」挑網頁那步的類比是：「就像人類一樣，我做完搜尋不會每個連結都點，我會掃一眼再決定點哪些。」

他也明確標註這是早期架構：「更現代的 deep researcher 會讓系統自己決定何時要再搜尋、何時要再抓網頁，更自主、更 agentic。」

核心問題：該修哪一個元件

元件	失效樣態
生成搜尋詞	詞就不對
網路搜尋	不夠全面；或不夠新——「要抓真正新鮮的新聞時，各家差很多」
挑網頁	抓了 bobsbackyardastronomyblog.com 而跳過 nasa.gov
寫作	有好來源卻寫不出好文章

有經驗的人「變異數很小」

「找幾個有經驗的機器學習的人來看同一個系統，你會發現我們對下一步該做什麼的意見，變異數小得驚人。不是說我們百分之百同意彼此，但變異數比你以為的小得多。對我來說這代表——這件事是有方法論的。而經驗較淺的工程師之間，變異數就大得多。」

error analysis 電子表格

它是手動的，而且他強調沒人真的做：

「我知道我說了，你大概也同意這是個好主意，但真的到了那個時候會去做的人的比例，我發現遠低於 100%。」

「error analysis 往往是非常手動的過程。因為它本質上是在找出人類會做得比 AI 系統更好的地方，然後把人類的知識注入到 AI 系統裡。AI 還沒有這個知識，所以你就是需要人的時間。我知道有人在談自動化這件事，也許會有進展，但目前為止，就是得靠人去看。」

做法：

• 列 = pipeline 的每個步驟（搜尋詞 / 網路搜尋 / 抓頁 / 寫作）
• 行 = 查詢，數量10 到 100 之間。「我通常對看到 100 個例子還有耐心。」
• 只看表現不好的查詢——做得好的那些他基本不看
• 逐格檢查中間輸出，不 OK 就記一筆（「Bob 而不是 NASA」）

結果長這樣：

	搜尋詞	網路搜尋	挑網頁	寫作
失敗佔比	20%	5%	70%	20%

「這些不需要加起來等於 100%——有時候一個查詢在不只一欄出問題。」

結論一目了然：去修挑網頁那步。

• 成本效益：「這個過程有時要花我們三四個小時，但省下的是幾週走錯方向的時間。」
• 反面情境：如果真正的問題是挑網頁，但團隊因為有人在推銷新的搜尋服務，就花了六個月在換搜尋引擎——「完全有可能對整體效能根本不動如山」

---

延伸：把這張表換成 LLM 應用的版本

Ng 用的例子已經是 LLM pipeline 了，所以幾乎不用轉譯。真正值得補的是三件事：

一、這張表的列，就是你的 trace 分段。 你有 LLM traces 的話，每個 span 就是一列。差別在於——traces 告訴你哪一段慢、哪一段報錯，但不會告訴你哪一段「做得比人差」。後者只能靠人看。

二、「只看失敗案例」比想像中違反直覺。 大多數人做 eval 是算總分，然後看分數有沒有進步。Ng 的做法是完全不看成功案例，把注意力全部押在 10–100 個失敗上，然後統計失敗集中在哪一欄。這兩種做法會導向完全不同的行動。

三、「百分比不用加起來等於 100%」這個細節很重要。 它意味著一個查詢可以同時在三個地方壞掉，而你如果用「歸因到單一根因」的方式做分析，會系統性地低估上游元件的問題。

站上 RAG 常見失敗模式 那篇列了十種問題和對應解法，而這一講補上的是你怎麼知道自己中的是哪一種——那十種解法都很好，但如果你的問題其實在挑網頁那一步，換再多檢索策略都不會動。

至於前半的喚醒詞案例，有一個洞見今天一樣成立：「你會得到一個語音活動偵測器」。當你用合成資料建 eval 集，如果所有正例都有某個共同的表面特徵，模型（或你的 judge）會學會抓那個特徵，而不是你真正想測的東西。這和站上 上線才是工作的開始 講的落差是同一個機制的兩端。

參考資料

• Lecture 6: AI Project Strategy — 2025/10/28，Andrew Ng。喚醒詞案例、一天修一個問題的節奏、deep researcher pipeline 與 error analysis 電子表格的出處。這一講沒有專屬投影片
• CS230 syllabus — 注意 Lecture 6 條目已過期，寫的是職涯客座，實際影片是 AI Project Strategy
• Stanford CS230 Autumn 2025 playlist — 九講完整清單
• RAG 常見失敗模式：10 種問題和對應的解法 — 站上文章，這一講補上的是「你怎麼知道中的是哪一種」
• 上線才是工作的開始：企業 agent 案例橫向讀 — 站上文章