提示工程有其上限。以下是超越之後的道路。

提示工程是真實且有價值的。精心製作的系統提示可以顯著改善 LLM 的輸出品質。少量示例（few-shot）解鎖了零樣本提示無法實現的行為。思維鏈技術改善了複雜任務的推理能力。

但存在上限。每個從業者最終都會碰到它，而能夠突破它的代理商和開發者，構建的產品從根本上優於那些持續最佳化提示的人。

本文講述如何識別上限，以及超越之後是什麼。

提示工程實際上做了什麼

要理解上限，您需要了解提示的作用。提示是引導模型走向其輸出空間特定區域的輸入。模型「知道」的一切已經固定——權重是凍結的。提示只能激活和引導已經存在的東西。

這意味著提示從根本上受到基礎模型在訓練期間學到的內容的限制。它們無法：

• 教模型它從未接觸過的新詞彙或特定領域術語
• 注入未在訓練資料中體現的行為模式
• 改變模型在任務上的底層精確度，只能改變其表達風格
• 消除由訓練資料缺口引起的幻覺

提示是給已經擁有固定知識和技能的員工的指令。您可以更好地引導他們，但無法改變他們所知道的。

您已達到上限的跡象

儘管有大量指令，輸出在風格上仍然是錯的。 您有 2,000 個 token 的系統提示，描述了您需要的確切語氣、格式和風格。模型「幾乎」遵循它，但會漂移——它使用您的客戶從不使用的詞彙，以錯誤的方式組織響應，錯過品牌語氣。再多的指令也無法解決它。

模型不了解您客戶的術語。 您與一家法律科技公司合作。模型不斷使用通用的法律語言，而不是律師事務所特定的文件命名慣例、事項編號系統和內部行話。您添加更多示例。有一定幫助，然後又退回原樣。

特定領域任務的精確度停滯不前。 您正在構建一個醫療編碼助手。您已廣泛最佳化您的提示。您在測試集上的精確度為 78%。您再花兩週時間進行提示迭代，達到 81%。進一步工作的回報遞減。模型對這個特定編碼分類法的接觸不夠深入。

延遲和成本難以為繼。 為了達到可接受的品質，您每個請求需要 6,000 個 token 的上下文——2,000 個系統提示加上 4,000 個少量示例。在規模上，這使每個請求都既昂貴又緩慢。您的提示解決方案所花費的成本超過了它要解決的問題。

上下文視窗限制是結構性約束。 您的 RAG 管道需要向上下文中塞入太多文件才能可靠地找到正確答案。模型在關注開頭和結尾，但在上下文邊界丟失中間部分。沒有提示技巧能修復上下文邊界的注意力模式。

為什麼上限存在於那個位置

上限對每個任務來說都不在同一個位置。提示工程對以下情況效果更好：

• 模型有大量訓練資料的任務（通用寫作、流行語言的代碼、常見問題類型）
• 風格和格式比事實準確性更重要的任務
• 具有可以用文字表達的清晰、可描述規則的任務

對以下情況更快達到上限：

• 具有專業術語的窄領域任務
• 需要在許多邊緣案例中保持一致行為的任務
• 需要持久行為模式的長程任務
• 「正確答案」依賴於模型從未被訓練過的私有資料的任務

超越之後：技術棧

1. 微調

微調直接修改模型的權重，從示例中學習新行為、術語和模式。它解決了提示無法解決的結構性問題：

• 模型在參數層面學習您客戶的特定語言和語氣
• 特定領域精確度大幅提升（窄任務上通常提升 15–30 個百分點）
• 您可以從提示中消除大量的少量示例塊，減少每個請求的 token
• 行為一致性顯著改善——模型不會漂移，因為行為已被烘焙進去

何時使用： 當您至少有 200–500 個期望輸入-輸出行為的示例，且任務足夠窄且特定領域，以至於通用模型持續表現不佳。

實際入口： 使用 Ertas 等工具對 7B 模型進行 LoRA 微調，在消費級 GPU 上需要 1–3 小時。輸出是可以立即部署的適配器文件。這不再是學術練習——它是一種可訪問的生產技術。

2. 檢索增強生成（RAG）

RAG 在推理時從知識庫中動態注入相關上下文到提示中。它為事實信息解決了「模型不了解這個」的問題：

• 產品目錄、文檔、政策文件、案例文件——在推理時都可搜索
• 模型不需要記憶靜態事實；它可以檢索它們
• 知識可以在不重新訓練的情況下更新

何時使用： 當知識缺口是關於隨時間變化的事實，或者體量太大無法包含在靜態提示中。具有大型且頻繁更新產品目錄的客戶服務是典型的 RAG 用例。

RAG 的上限： RAG 仍然使用基礎模型的行為模式和語言。如果模型的輸出風格、語氣或領域行為是錯的，RAG 不能修復它。微調和 RAG 解決不同的問題，且常常一起使用。

3. 微調 + RAG 結合

許多生產系統同時使用兩者。微調模型帶來正確的行為模式、術語和基礎精確度。RAG 帶來模型不需要記憶的當前、事實性上下文。

醫療文檔助手可能在診所的筆記寫作風格和術語上進行微調，然後使用 RAG 為每個查詢檢索特定患者記錄和相關臨床指南。單獨使用任何一種方法都無法達到生產品質；結合在一起則可以。

4. 結構化輸出與工具使用

對於需要確定性格式或外部資料存取的任務，用於格式化的提示工程是脆弱的。結構化輸出（在推理時強制執行的 JSON schema、TypeScript 類型）在不需要提示技巧的情況下給您可靠的解析。工具使用讓模型調用外部 API 或資料庫來獲取它需要的資料，而不是幻覺出答案。

這些不是微調的替代品——它們解決不同的問題——但它們消除了整個類別的「提示工程以獲得一致 JSON 輸出」，工程師在這上面浪費時間。

實用決策框架

商業影響

達到提示上限並突破它有直接的商業後果。

進行微調的代理商與客戶的對話從根本上不同。「我們的模型在您的任務上達到 X% 的精確度，在您的資料上已驗證」與「我們有一個非常好的系統提示」是完全不同的提案。前者是技術資產。後者只是配置。

進行微調的開發者交付更好的產品，支援工單更少。當微調模型崩潰時，它以一致的方式崩潰——您可以識別訓練資料中的缺口並修復它。當基於提示工程的模型崩潰時，它以不可預測的方式崩潰，修復是更多的提示迭代。

上限不是死胡同。它是從一種技術到下一種技術的過渡點。認識到它並在其之外導航的從業者構建的東西，是停留在上限以下的從業者無法構建的。

---

延伸閱讀

• 微調 vs RAG：為客戶實際構建什麼 — 兩種主要技術的決策框架
• 面向 AI 代理商老闆的 LoRA 適配器（無需機器學習學位） — LoRA 微調的工作原理，沒有學術術語
• 微調一次，按月收費：產品化 AI 服務模型 — 如何將微調技能轉化為定期收入