RAG 的搜尋做好了，context 準確了，但 LLM 的回答還是差強人意。這時候問題通常在 Prompt 設計——怎麼把 context 和指令組合在一起，讓 LLM 知道怎麼回答。
System Prompt 的基本結構
一個 RAG 的 system prompt 通常有三個部分：
1. 角色定義：你是誰、你能做什麼
2. 行為準則：怎麼使用 context、怎麼處理不確定性
3. 輸出格式：回答的結構和語氣你是 NobodyClimb 的攀岩知識助理，熟悉台灣和全球各地的岩場、路線和攀岩技術。
[行為準則]
- 只根據提供的知識庫資料回答，不要添加知識庫以外的資訊
- 如果知識庫沒有相關資料，直接說「目前沒有這方面的資料」，不要猜測
- 難度資訊要精確，不要模糊表達（用「5.11a」而不是「中等難度」）
- 安全相關的建議要保守，不確定時建議諮詢有經驗的教練
[輸出格式]
- 回答用繁體中文
- 路線推薦時列出名稱、難度、類型
- 適當使用條列式，但不要過度結構化
- 回答長度適中，不要冗長角色定義讓 LLM 明白自己的定位；行為準則防止幻覺和跑題；輸出格式確保一致性。
Context 的排版
Context 的排版方式影響 LLM 對資訊的理解和引用：
不好的排版：
Context: 龍洞北壁5.11a保護點密集落點清晰龍洞南壁5.9入門路線適合初學者龍洞高峰5.12a技術路線需要良好腳法...把所有文件拼在一起，沒有邊界。LLM 難以區分不同文件的內容。
好的排版：
[知識庫資料]
文件 1：
路線名稱：某某路線（龍洞北壁）
難度：5.11a，運動攀登
描述：保護點密集，落點清晰，關鍵動作在第三個保護點後...
---
文件 2：
路線名稱：另一路線（龍洞南壁）
難度：5.9，運動攀登
描述：入門路線，適合初學者，保護點間距均勻...
---清晰的文件邊界（---）、結構化的欄位（名稱、難度、描述），讓 LLM 能準確引用特定文件的資訊。
文件相關性提示
在 context 裡加入相關性分數，讓 LLM 知道哪些文件更可信：
[知識庫資料]（按相關度排序）
文件 1（相關度：高）：
...
文件 2（相關度：中）：
...
文件 3（相關度：低，供參考）：
...LLM 會傾向更多引用「相關度：高」的文件，降低低品質 context 的影響。
指令的位置
研究顯示，LLM 對 prompt 開頭和結尾的指令關注度更高（Lost in the Middle 問題）。重要的指令放在 system prompt 的開頭，或在 user message 的結尾重複強調：
[System Prompt 開頭]
你是攀岩助理，只根據提供的知識庫回答。
[知識庫資料]
...（大量文件）...
[User Message 結尾]
請根據上面的知識庫資料回答：{query}
如果知識庫沒有相關資料，請說「目前沒有這方面的資料」。重要的「不要幻覺」指令在開頭和結尾都有，不容易被中間的長 context 稀釋。
思維鏈（Chain-of-Thought）
對複雜查詢加入 CoT 指令，讓 LLM 展示推理過程：
回答前，請先：
1. 識別問題的核心需求
2. 確認知識庫中有哪些相關資料
3. 根據相關資料組織回答
然後給出最終回答。CoT 讓 LLM 的推理更有條理，特別是需要比較多個選項或做出推薦時。對 8B 以下的小模型效果更明顯。
常見問題和修法
問題：回答加入了太多 context 之外的內容
修法：
嚴格限制：你的回答必須 100% 基於提供的知識庫資料。
如果知識庫沒有某項資訊，明確說明缺乏資料，不要補充。問題：回答格式不一致
修法：提供一個 few-shot 範例：
回答格式範例：
問：龍洞有哪些適合初學者的路線？
答：龍洞有以下幾條適合初學者的路線：
1. **某路線** - 5.9，運動攀登，保護點密集，適合第一次戶外攀岩
2. **某路線** - 5.8，運動攀登，路線清晰，難度均勻
請按照此格式回答。問題：難度資訊不精確（說「中等難度」而不是 5.10b）
修法：
難度必須使用精確的攀岩難度標準表示（如：5.10b、V4），
不要使用「中等」、「較難」等模糊表達。問題：回答太長
修法：
回答長度限制：
- 簡單問題（定義、單一事實）：1-2 句
- 推薦問題：列出 3-5 個選項，每個 1-2 句描述
- 複雜分析：最多 200 字
避免冗長的前言和總結。Prompt 的版本管理
Prompt 是程式碼，要版本管理：
const PROMPTS = {
"v1.0": {
system: "你是攀岩助理...",
contextTemplate: "文件 {n}：\n{content}\n---",
},
"v1.1": {
system: "你是攀岩助理...（改進版）",
contextTemplate: "文件 {n}（相關度：{relevance}）：\n{content}\n---",
},
};
// 從 ai_config 讀取當前使用的版本
const currentVersion = config.prompt_version ?? "v1.1";
const prompt = PROMPTS[currentVersion];版本化讓 A/B 測試不同 prompt 成為可能，也讓回退到舊版本很方便。
整體來說
Prompt Engineering 在 RAG 系統裡的地位被低估了。搜尋做得再好，如果 LLM 不知道怎麼用 context，或者被糟糕的 prompt 結構迷惑，回答品質還是差。
最有效的 prompt 改進：
- 明確的角色定義（讓 LLM 知道自己的邊界）
- 清晰的 context 排版（文件邊界、欄位結構）
- 「不確定時說不確定」的明確指令（防幻覺）
- 輸出格式範例（few-shot 效果最直接）
這四點做好，不需要複雜的技術，回答品質就能明顯提升。