AI 不是炒作：實戰工程師指南

網路上大多數 AI 相關內容分為兩種：關於超級智能的末日論，或是誇大其詞宣稱聊天機器人下週就會搶走你的工作。兩種都幫不上忙。本指南跳過這兩種極端，直接講解如何在實際專案中使用現有一代的 AI 工具，並明確說明其限制。

LLM 實際上做什麼

大語言模型如 GPT-4 或 Llama 3 預測序列中的下一個 token，訓練資料是大量文本。就這樣。模型內部沒有事實查核機制，在會話之間沒有持久記憶（除非你自己建構），也沒有人類那種理解方式。當你問它問題時，它在生成統計上合理的提示詞延續。

這在實務上很重要：模型會自信地生成呼叫不存在的函式庫方法的 Python 函式，因為這個方法聽起來就像函式庫會有的東西。一定要執行程式碼。一定要檢查 API 參考。把模型輸出當作來自一位聰慧但有時會無意識說謊的高效實習生的初稿。

實際工作流程：使用 LLM 寫程式碼

這種方法可行，而不是只是問 ChatGPT「幫我做個 app」：

1. 自己寫函式簽名和文件字串，指定類型和邊界情況。
2. 要求模型根據確切規格實現它。
3. 分別寫你自己的測試——別要求模型為它剛寫的程式碼寫測試，它會傾向於寫通過的平凡測試。
4. 執行測試。將失敗反饋作為新提示，而不是模糊的「它不工作」陳述。

def parse_duration(text: str) -> int:
    """
    Parse strings like '1h30m', '45s', '2d' into total seconds.
    Raise ValueError on invalid input.
    """

給模型這個確切的合約會產生遠優於籠統描述的輸出，並且給你具體的東西來測試。

檢索增強生成，簡單說法

RAG 被當成流行用語拋來拋去，但機制很簡單：不依賴模型在訓練期間記住的內容，而是在查詢時取得相關文件並塞進提示。

基本設定：

1. 將文件分塊（500-1000 tokens 是常見的起點）。
2. 用 text-embedding-3-small 這樣的模型或 bge-small-en 這樣的開源模型嵌入每個塊。
3. 在 Postgres 搭配 pgvector 或像 Qdrant 這樣的專用儲存中儲存向量。
4. 查詢時，嵌入使用者的問題，執行相似度搜尋（餘弦距離是標準做法），將前 k 個塊拉進提示中與問題一起。

SELECT content FROM docs
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;

這就是為什麼在截止日期之前訓練的聊天機器人仍可回答上週你內部 wiki 的問題。它不是在推理你的公司——它在讀你的文件並總結它們。

經典 ML 仍然勝出的地方

不是每個問題都需要 transformer。如果你從結構化表格資料預測流失——帳戶年齡、使用頻率、支援工單——梯度提升樹模型如 XGBoost 或 LightGBM 通常會勝過基於 LLM 的方法，訓練耗時分鐘而非小時，運行成本只是零頭。在聯絡 API 之前先用 scikit-learn 的 RandomForestClassifier 或 XGBoost，特別是當你的資料放得進試算表且目標變數是乾淨的數字或類別時。

成本和延遲是設計限制，不是事後考量

GPT-4 級的呼叫每個 token 花真金白銀，回傳需要真實的秒數。如果你在為每個使用者的每次頁面載入執行的功能，成本會迅速累積，延遲會很明顯。積極快取，對不需要頂級推理的東西使用較小的模型如 GPT-4o-mini 或本機 Llama 3 8B，將昂貴的模型呼叫保留給管道中品質真正重要的部分。

沒人警告你的失敗模式

當你要求模型回答訓練分佈略微之外的內容時——晦澀的函式庫版本、內部公司行話、最近的 CVE 編號——模型幻覺更多，不是更少。如果答案需要完全正確（安全公告、法律引用、醫學劑量），別只信任生成。每次都要對比主要來源驗證，將驗證步驟內建到管道中，而不是信任事後的人工審查。

AI 工具一旦你停止期望它思考並開始將它視為你必須檢查的快速模式匹配器，就真正有用。從第一天開始將驗證步驟內建在內，你就能從中獲得真實價值，而不是一連串自信的廢話。

若要深入瞭解，請查看 Korra Studio 的 Python 和資料科學課程，獲得使用這些工具真正有生產力所需的基礎知識。