由於我們仍處於使用基礎模型建構應用程式的早期階段，犯錯是常態。這是一篇簡短的筆記，其中包含我從公開案例研究和個人經驗中觀察到的一些最常見陷阱範例。 由於這些陷阱很常見，如果你曾參與任何 AI 產品的開發，你可能都曾見過它們。 ## 1. 當你不需要生成式 AI 時卻使用它 每當有新技術出現時，我都能聽到資深工程師們集體嘆息：「並非所有問題都需要榔頭。」生成式 AI 也不例外——它看似無限的能力只會加劇將生成式 AI 用於所有事物的傾向。 一個團隊向我提出使用生成式 AI 優化能源消耗的想法。他們將家庭的耗能活動清單和每小時電價輸入大型語言模型 (LLM)，然後要求它建立一個排程以最大程度地降低能源成本。他們的實驗顯示，這可以幫助家庭減少 30% 的電費。這簡直是免費的錢。誰會不想使用他們的應用程式呢？ 我問：「這與在電費最便宜時簡單地安排耗能最高的活動相比如何？例如，晚上 10 點後洗衣服和為汽車充電？」 他們說他們會稍後嘗試並讓我知道。他們從未回覆，但不久後就放棄了這個應用程式。我懷疑這種貪婪排程可能相當有效。即使無效，也有其他更便宜、更可靠的優化解決方案，例如線性規劃，而非生成式 AI。 我一次又一次地看到這種情況。一家大公司想使用生成式 AI 偵測網路流量中的異常。另一家公司想預測即將到來的客戶來電量。一家醫院想偵測患者是否營養不良（這真的不建議）。 探索新方法以了解可能性通常是有益的，只要你意識到你的目標不是解決問題，而是測試解決方案。「我們解決了問題」和「我們使用了生成式 AI」是兩個截然不同的標題，不幸的是，許多人寧願選擇後者。 ## 2. 將「糟糕的產品」與「糟糕的 AI」混淆 另一方面，許多團隊因為嘗試後使用者不喜歡而將生成式 AI 視為解決問題的無效方案。然而，其他團隊卻成功地將生成式 AI 用於類似的使用案例。我只能調查其中兩個團隊。在這兩種情況下，問題都不在於 AI，而在於產品。 許多人告訴我，他們 AI 應用程式的技術層面很簡單。困難的部分是使用者體驗 (UX)。產品介面應該是什麼樣子？如何將產品無縫整合到使用者工作流程中？如何納入人機協作？ 使用者體驗一直都充滿挑戰，但對於生成式 AI 來說更是如此。雖然我們知道生成式 AI 正在改變我們閱讀、寫作、學習、教學、工作、娛樂等方式，但我們還不完全知道具體如何改變。未來的閱讀/學習/工作會是什麼樣子？ 以下是一些簡單的例子，說明使用者需求可能與直覺相反，需要嚴謹的使用者研究。 1. 我的朋友正在開發一個總結會議紀錄的應用程式。最初，她的團隊專注於取得正確的摘要長度。使用者會喜歡 3 句話的摘要還是 5 句話的摘要？ 然而，結果發現他們的使用者根本不在乎實際的摘要。他們只想要每次會議中與他們相關的待辦事項。 2. 當 LinkedIn 開發一個用於技能適配度評估的聊天機器人時，他們發現使用者不想要正確的回應。使用者想要有幫助的回應。 例如，如果使用者詢問機器人他們是否適合某份工作，而機器人回應：「你非常不適合。」這個回應可能是正確的，但對使用者來說卻沒有太大幫助。使用者想要了解差距在哪裡以及如何彌補這些差距的建議。 3. Intuit 建立了一個聊天機器人來幫助使用者回答稅務問題。最初，他們獲得的回饋平平——使用者認為機器人沒有用。經過調查，他們發現使用者其實討厭打字。面對一個空白的聊天機器人，使用者不知道機器人能做什麼以及該輸入什麼。 因此，對於每次互動，Intuit 都添加了一些建議問題供使用者點擊。這降低了使用者使用機器人的摩擦，並逐漸建立了使用者的信任。之後，使用者的回饋變得更加正面。 （由 Intuit AI 副總裁 Nhung Ho 在我們的 Grace Hopper 小組討論中分享。） 由於現在大家使用的模型都差不多，AI 產品的 AI 組件也大同小異，差異化在於產品。 ## 3. 一開始就過於複雜 這個陷阱的例子： 1. 當直接 API 呼叫有效時，卻使用代理框架。 2. 當簡單的基於詞彙的檢索方案（不需要向量資料庫）有效時，卻糾結於要使用哪種向量資料庫。 3. 當提示詞工程有效時，卻堅持微調。 4. 使用語義快取。 面對這麼多閃亮的新技術，很容易就想直接使用它們。然而，過早地整合外部工具可能會導致兩個問題： 1. 抽象化關鍵細節，使系統難以理解和除錯。 2. 引入不必要的錯誤。 工具開發者可能會犯錯。例如，我經常在審查框架的程式碼庫時發現預設提示詞中的錯字。如果你使用的框架在未告知的情況下更新了其提示詞，你的應用程式行為可能會改變，而你可能不知道原因。 最終，抽象化是好的。但抽象化需要納入最佳實踐並經過時間的考驗。由於我們仍處於 AI 工程的早期階段，最佳實踐仍在不斷演進，我們在採用任何抽象化時都應保持警惕。 ## 4. 過度看重初期成功 1. LinkedIn 花了 1 個月才達到他們想要的 80% 體驗，又花了額外 4 個月才超越 95%。最初的成功讓他們嚴重低估了改進產品的挑戰性，尤其是在幻覺問題上。他們發現，要達到後續每 1% 的提升是如此困難，令人沮喪。 2. 一家為電商開發 AI 銷售助理的新創公司告訴我，從 0 到 80% 所花的時間與從 80% 到 90% 所花的時間一樣長。他們面臨的挑戰包括： * 準確性/延遲權衡：更多的規劃/自我修正 = 更多的節點 = 更高的延遲 * 工具呼叫：代理難以區分相似的工具 * 系統提示詞中語氣要求（例如「像奢侈品牌禮賓員一樣說話」）難以被完美遵守 * 代理難以完全理解客戶意圖 * 難以建立一套特定的單元測試，因為查詢組合幾乎是無限的 （感謝 Jason Tjahjono 分享此資訊。） 3. 在 UltraChat 論文中，Ding 等人 (2023) 分享道：「從 0 到 60 的旅程很容易，而從 60 到 100 的進展則變得異常艱鉅。」 這或許是任何快速建立 AI 產品的人都會學到的第一個痛苦教訓。建立一個演示很容易，但建立一個產品卻很難。除了前面提到的幻覺、延遲、延遲/準確性權衡、工具使用、提示詞工程、測試等問題外，團隊還會遇到以下問題： 1. API 供應商的可靠性。一個團隊告訴我，他們 10% 的 API 呼叫超時。或者產品行為因底層模型改變而改變。 2. 合規性，例如關於 AI 輸出著作權、資料存取/共享、使用者隱私、檢索/快取系統的安全風險，以及訓練資料溯源的模糊性。 3. 安全性，例如惡意使用者濫用你的產品，你的產品產生不敏感或冒犯性回應。 在規劃產品的里程碑和資源時，請務必將這些潛在的障礙納入考量。一位朋友稱之為「謹慎樂觀」。然而，請記住，許多很酷的演示不一定會帶來出色的產品。 ## 5. 捨棄人工評估 為了自動評估 AI 應用程式，許多團隊選擇了 AI 評審（也稱為 LLM 評審）的方法——使用 AI 模型來評估 AI 輸出。一個常見的陷阱是捨棄人工評估，完全依賴 AI 評審。 雖然 AI 評審可能非常有用，但它們並非確定性的。評審的品質取決於底層評審模型、評審的提示詞以及使用案例。如果 AI 評審未正確開發，它可能會對你的應用程式效能給出誤導性評估。AI 評審必須像所有其他 AI 應用程式一樣，隨著時間進行評估和迭代。 我見過擁有最佳產品的團隊都採用人工評估來輔助其自動評估。每天，他們都會讓人工專家評估應用程式輸出的一小部分，數量從 30 到 1000 個範例不等。 每日人工評估有三個目的： 1. 將人工判斷與 AI 判斷進行關聯。如果人工評估者的分數正在下降，但 AI 評審的分數正在上升，你可能需要調查你的 AI 評審。 2. 更好地理解使用者如何使用你的應用程式，這可以為你改進應用程式提供想法。 3. 利用你對時事的了解，偵測使用者行為的模式和變化，這些是自動化資料探索可能遺漏的。 人工評估的可靠性也取決於精心設計的註釋指南。這些註釋指南可以幫助改進模型的指令（如果人類難以遵循指令，模型也會如此）。如果以後你選擇微調，它也可以重複用於建立微調資料。 在我參與的每個專案中，僅僅審視資料 15 分鐘通常就能給我一些見解，可以省去我數小時的麻煩。Greg Brockman 曾發推文：「在機器學習中，人工檢查資料的價值與聲望比可能是最高的。」 ## 6. 眾包使用案例 這是我在企業瘋狂採用生成式 AI 的早期階段看到的一個錯誤。許多科技主管無法制定專注於哪些使用案例的策略，於是向全公司眾包想法。「我們僱用聰明人。讓他們告訴我們該怎麼做。」然後他們試圖一個接一個地實施這些想法。 這就是我們最終擁有一百萬個文字轉 SQL 模型、一百萬個 Slack 機器人，以及十億個程式碼外掛程式的原因。 雖然傾聽你僱用的聰明人確實是個好主意，但個人可能偏向於立即影響他們日常工作的問題，而不是可能帶來最高投資報酬率的問題。如果沒有考慮大局的整體策略，很容易就會跑題，陷入一系列小型、低影響的應用程式，並得出生成式 AI 沒有投資報酬率的錯誤結論。 ## 總結 簡而言之，以下是常見的 AI 工程陷阱： 1. **當你不需要生成式 AI 時卻使用它** 生成式 AI 並非解決所有問題的萬靈丹。許多問題甚至不需要 AI。 2. **將「糟糕的產品」與「糟糕的 AI」混淆** 對於許多 AI 產品來說，AI 是簡單的部分，產品才是困難的部分。 3. **一開始就過於複雜** 雖然花俏的新框架和