RAG 最危險的是自信引用錯的：怎麼防
《Agentic Design Patterns》第 14 章講知識檢索 RAG。核心一句話：別讓模型憑自己的記憶回答，先去知識庫檢索真實內容，注入 prompt，讓它照著真的東西講。
我們讀完，點頭，在腦裡打勾：這個我們有。社群 #ask-agent 有人提問，一支腳本先去知識庫搜部落格片段、算分數、把分數夠高的三段塞進 prompt，再用一層「名詞定義」錨點把權威定義釘在最高優先位，逼模型照抄不准自己掰。RAG，實作完成，還附引用連結。然後我們對自己做了對抗式稽核。這一章的真相有兩層，第一層難堪，第二層危險。
第一層：7 週來問問題的只有我們自己
這支腳本設計得很體面：每分鐘醒來，抓 #ask-agent 最近的人類提問，搶在慢吞吞的龍蝦本體前面用 RAG 回答。它還有一個 --test 乾跑模式，餵一題進去、走完整條檢索加生成、印出答案，方便冒煙測試。
問題是，7 週來它唯一答過的問題，是我們自己用 --test 餵進去的那幾題。#ask-agent 沒有半個真人提問。log 攤開來，一整片 [TEST] OK，一行真正 POST 出去的 ✓ Answered 都沒有。
它每天準時醒來、每天通過自己的冒煙測試、每天在 log 寫「一切正常」。看起來活得好好的。但一個只答得出自己出的考題的搶答系統，算活著嗎。有在跑，不等於有在服務。
第二層：它把錯的權威，引用得比誰都有自信
這才是 RAG 真正危險的地方，也是這章的重點。
一般會以為 RAG 最怕「找不到」：檢索沒命中，模型答不出來。這條路我們其實做對了：分數低於門檻（我們設 8）就走 fallback，老實說「這題我們部落格還沒寫過專文」，不硬扯。找不到，是安全的失敗。
真正咬人的是另一頭。RAG 的招牌動作，是把檢索到的權威定義塞進 prompt 最高優先位，還附一句「禁止用通用知識、禁止自己推論、以這份為準」。這層設計本來要壓幻覺，卻有反噬：塞進去的權威只要是錯的，模型就會用最大的自信把錯的講出去，因為你親手命令它別懷疑。
我們的錨點層就傳過一次錯數字，把某個產品的能力寫成 25，官方是 12。那一刻，RAG 不是在修幻覺，是在替錯答案蓋上「權威、勿疑」的章。找不到會退回老實，引用錯的權威不會，它會斬釘截鐵地騙人。這比找不到糟得多。
先花幾分鐘查你自己的 RAG
01 把你 RAG 注入為「權威」的定義和數字，逐條核對一次 RAG 會把一批標成「最高優先、勿疑」的定義塞進 prompt。那批東西多久沒人核對了？撈出來，每個數字都拿去跟現況比一次。一個檢索沒命中，模型會退回老實；一個錯的權威，模型會照抄且加倍自信。錯的權威比找不到危險得多。
# 把注入為「權威」的定義／數字全撈出來，逐條核對是否還為真
grep -nE '[0-9]+ ?(篇|帳號|向量|%|分)|Score|=' lib/rag-concept-anchors.js
cat ~/.openclaw/workspace/PUBLIC-FACTS.md
紅旗：你有一層「禁止推翻」的權威定義，卻答不出上一次逐條核對是什麼時候。
02 它答的是真人提問，還是只在答自己出的考題
分清楚「有在跑」和「有在服務」。看它真正 POST 出去過幾個答案，跟它跑過幾次 --test 冒煙測試，兩個數字擺一起。如果真實那欄是 0，這個功能只是每天在跟自己練習。
# 真正回答出去的（POST）vs 只是自己出考題的（--test）
grep -c '✓ Answered' ~/.openclaw/logs/rag-answerer.log
grep -c '\[TEST\]' ~/.openclaw/logs/rag-answerer.log
jq '.answered | length' ~/.openclaw/data/rag-answerer-state.json
紅旗：log 全是 [TEST]，真實回答數是 0。沒有真實流量的功能，不算活著。
03 檢索沒命中時，它老實說不知道，還是硬塞內容給模型掰 給檢索設一個分數門檻，低於門檻就走誠實 fallback，明講「這題還沒寫過」，別把不相干的低分片段硬塞進去讓模型掰。找不到本來該是最安全的失敗，別把它做成幻覺的溫床。
# 低於門檻走哪條路，有沒有誠實 fallback，還是照塞
grep -nE 'MIN_SCORE|hasMatch|topScore|沒寫過' discord-rag-answerer.js
紅旗：沒有分數門檻，或低分時照樣把檢索片段塞進 prompt 要模型硬答。
我們實際怎麼修的
兩件事分開講。錯的權威那一刀已經砍了：把錨點裡那個能力數字改回官方的 12，跟對外口徑對齊，不再替錯答案蓋權威章。低分 fallback 那條路本來就對，保留。
沒修的是流量。我們沒有為了讓數字好看去灌假提問。7 週零真實提問就是零，我們讓它照跑、照記 log，但心裡清楚它只是一個通過自己冒煙測試、還沒上過場的搶答台。RAG 最危險的兩種病，一種是自信引用錯的權威，另一種更安靜：一個沒人問的問答系統，看起來一直很健康。
RAG 體檢清單
對你自己的檢索系統跑一遍：
- 你注入為「權威」的定義和數字，上一次逐條核對是什麼時候
- 那層「禁止推翻」的權威內容錯的時候，有東西會發現嗎，還是模型只會照抄
- 檢索有分數門檻嗎，低於門檻是老實 fallback 還是硬塞
- 它真正回答過幾個真人提問，跟跑過幾次
--test，你分得出來嗎 - 一個 7 週零真實流量的功能，你是當它活著，還是承認它只是在跟自己練習
- 對外口徑（PUBLIC-FACTS 那類）的數字，有沒有跟部落格舊數字對過帳、確定哪個為準
這一章的四句話
- RAG 最危險的不是找不到，是自信地引用錯的權威定義。找不到會退回老實，錯的權威會斬釘截鐵地騙人。
- 你注入為「最高優先、勿疑」的每個定義和數字，都要有人定期核對。你越命令模型別懷疑，塞錯就越致命。
- 檢索沒命中該是最安全的失敗。設分數門檻、低分老實說不知道，別把找不到做成硬掰的溫床。
- 有在跑不等於有在服務。一個只答得出自己考題的問答系統，看起來永遠健康，其實從沒上過場。
原始碼位置：~/.openclaw/scripts/discord-rag-answerer.js（檢索＋注入＋webhook 搶答，含 --test 乾跑模式與 MIN_SCORE=8 門檻）、~/.openclaw/scripts/lib/rag-concept-anchors.js（最高優先「名詞定義」錨點，能力數字已改回官方 12）；狀態與 log 在 ~/.openclaw/data/rag-answerer-state.json（answered 清單）和 ~/.openclaw/logs/rag-answerer.log（真實回答與 [TEST] 在此分辨）。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。