三個旋鈕，不是階梯
讀到這裡你已經知道：大語言模型是一堆凍結的參數，在推理時把你的文字變成更多文字。問題在於，基礎模型懂很多關於世界的通識，卻對你的世界一無所知——你的文件、你的語氣、上週二的價目表。要補上這一課，你能下手的地方恰好只有三個，而把它們看成三個各自獨立的旋鈕、而不是一條越爬越高的品質階梯，會讓你受益無窮。
第一是提示（prompting）：改變你送進去的文字。第二是檢索（RAG）：在執行時取出相關事實，貼進同一段提示裡。第三是微調（fine-tuning）：真的用更多訓練去挪動權重。前兩條不碰模型本身，全都在上下文視窗裡發生；只有第三條改變了模型自己。這一條區分——模型的記憶變沒變，還是只是它當下看到的東西變了？——是下文一切的脊梁。
提示：最便宜、最快的旋鈕
提示利用的是你早先見過的一個特性——上下文學習。一個有能力的模型，能僅憑提示裡寫的指令和幾個示例就接住一項新任務，完全不改權重。好的提示工程——一段清晰的系統提示、一兩個做好的示例、對多步推理再加一點思維鏈的引導——能把「模型的預設表現」和「你想要的表現」之間的差距，關掉得出乎意料地多。
為什麼從這裡開始？因為迭代一圈以秒計，成本只是你發出去的 token，而且你可以隨時改主意。沒有訓練任務要等，沒有資料要標註，沒有單獨的模型要託管。等下個季度更強的基礎模型一發布，一個純提示的系統通常直接白撿這次升級。這份靈活性，值真金白銀。
但提示有它實打實的局限，而且不只是文風層面。它沒法教會模型在預訓練裡從沒見過的事實——問它你們的內部 API，它會信誓旦旦地幻覺出一個錯誤答案。長提示每次呼叫都要多花 token，最終把上下文視窗擠爆。而且單靠提示，很難在成千上萬個邊角情形裡產出深度一致的口吻或格式。撞上這些牆時，你就該去夠另外兩個旋鈕了。
RAG：在執行時把事實餵給它
當問題出在知識上——模型缺事實，或者事實變得太快沒法烤進權重——對的旋鈕幾乎總是檢索增強生成。它的形狀很簡單：把你的文件以嵌入形式存進向量資料庫，查詢時取出與使用者問題最相關的那幾段，貼進提示裡，讓模型依據這些段落來回答。推理和行文仍由模型完成；你只是遞給了它一本翻開的書。
user question
|-> embed -> search vector DB -> top-k relevant chunks
| |
+----------------> PROMPT <----------------+
|
LLM answer (grounded in the chunks, with citations)RAG 受歡迎是有硬道理的。事實留在模型之外，所以更新知識只需改一份文件，而不必重新訓練任何東西。答案能附上出處，因此可被稽核。又因為模型被要求倚靠檢索到的文本，構建良好的 RAG 在「能找到依據的問題」上可量化地壓低了幻覺。對大多數「和我們的文件對話／從知識庫裡回答」的產品來說，RAG 加上扎實的提示就是全部答案——根本不需要微調。
微調：當你非動權重不可時
微調是指：在一個現成模型上，用你自己的帶標註樣本繼續訓練，挪動權重，把新行為烤進去。它是遷移學習的一種：你保留模型來之不易的通用能力，再讓它專精化。判斷你是否需要它，有一條犀利的檢驗——當你必須改變模型行為的方式、而非它所知道的內容時，才微調。知識問題交給 RAG；行為問題交給微調。
微調的正當理由：把精確的輸出格式或品牌口吻鎖進每一次呼叫；教會一項狹窄技能——你有大量示例、卻很難用語言描述清楚；或者為了縮短提示——一旦指令住進了權重，你就不必每次請求都為它們付費。這些大多在精神上屬於指令微調：給模型看許許多多「(輸入, 期望輸出)」的配對，直到模式黏住。你很少需要動全部權重；輕量方法只調一小片，就能廉價地拿到大部分收益。
它的代價，正是你把它留到最後的原因。你需要一份乾淨的、帶標註的資料集——而打磨這份資料才是真正的工作，訓練本身倒不是。一次訓練要花時間和算力，你從此擁有並且必須託管一個單獨的模型，還冒著對自己樣本過擬合、或侵蝕模型通用能力的風險。最糟的是，微調後模型的知識凍結在訓練那一刻；事實一變，你要重新訓練，而不是改一份文件。這最後一點，恰恰說明了為什麼用微調去修 RAG 本能乾淨解決的知識問題，是個糟糕選擇。
蒸餾，與成本／品質的權衡
有個近親值得認識：蒸餾。做法是讓一個又大又貴的「教師」模型產出高品質輸出，你再微調一個又小又便宜的「學生」去模仿它（在大模型語境裡叫模型蒸餾）。賣點很誘人——一個在你那項狹窄任務上跑得又快又省的小模型，在那一小片範圍內往往接近教師的品質。代價是：學生只在你訓練過的地方保住教師的水準；一旦推到那範圍之外，品質就掉下去。
退一步看，整個決策就是一場跨越兩種截然不同預算的成本／品質權衡。一是前期成本：提示幾乎為零，RAG 需要搭建並維護一條檢索流水線，微調和蒸餾則要標註資料和一次訓練。二是推理時的單次呼叫成本——也就是你持續的推理成本。長提示和大段 RAG 上下文每次呼叫都更費 token；而一個微調或蒸餾出來的小模型，一旦存在，單次呼叫可能便宜得多。怎麼選取決於你的流量：一個一次性工具，和一個每天回答百萬次呼叫的服務，指向截然不同的答案。
- 從提示開始。寫一段清晰的系統提示，加上一兩個示例，對著一個小評測集量化品質。很多任務到這一步就夠了。
- 如果失敗的原因是缺事實或事實過時，就加上 RAG。把功夫下在檢索品質上——切塊、搜尋、排序——再去怪模型。
- 如果失敗的原因是頑固的行為問題——格式不對、風格不對、提示釘不住的某項技能——而你又有示例，那就微調。如果你同時還需要新鮮事實，就把它和 RAG 疊在一起用；這些旋鈕是可以疊加的。
- 如果一個微調過的大模型有效、但在規模上單次呼叫太貴，就為那項狹窄任務把它蒸餾成一個更小的學生模型。
這一切都不是一錘定音的決定，也沒有哪一項能取代「測量」。不管你最終上線什麼，都在它旁邊放一個小評測集，盯著數字看——下一級講的正是如何評估和守護你部署的東西。三個旋鈕不是對手；最強的系統會把提示寫好、把對的事實檢索出來，只去微調那些怎麼換法都死活不肯動的行為。