Astute RAG：RAG 失效時，該信誰？

先給判斷：真正的問題在後檢索

傳統 RAG 的直覺是「模型不知道，就去找資料」。問題在於，檢索器回傳的資料不保證相關、正確、最新，甚至可能含有惡意內容；模型一旦把噪聲當成上下文，新增的外部資訊反而會把原本答對的問題帶偏。論文把焦點從「如何再改進 retriever」移到「拿到結果後，模型該如何處理不確定性與衝突」。[2]

衝突案例中，內部知識正確的比例是 47.4%，外部資訊正確的比例是 52.6%。這個分布直接否定「永遠信模型記憶」與「永遠信檢索內容」兩種簡單規則；需要比較兩邊，而不是預先選邊。[2]

方法拆解：三個角色，不是單純多塞一段 context

實驗設計與結果：增益存在，但成本也是真的

v1 使用 NQ、TriviaQA、BioASQ、PopQA 共 1,042 組短答案 QA，每題以 Google Search 取前 30 筆結果，再選前 10 個可存取網站，擷取對應 snippet 的段落；研究沒有依檢索結果反過來挑題或標註答案。模型是 Gemini 1.5 Pro (002) 與 Claude 3.5 Sonnet (20240620)，temperature 0、zero-shot。[2]

換成較容易解讀的絕對差距：Claude 的最佳既有 baseline 到 Astute RAG 是 +4.03 個百分點；Gemini 是 +2.11 個百分點。同時，Gemini 在 t=3 反而從 59.69 降回 59.21，說明「多一次整理」不是保證增益，輪數應由模型、資料與 context 長度共同決定。[2]

最有價值的不是 Overall 排名，而是極端情境：在 RGB 的 worst-case 設定中，所有檢索文件都是 negative passages；一般 RAG 與無 RAG 的性能差距超過 50 個百分點，Astute RAG 是唯一接近無 RAG 表現的方法。這表示它至少具備「外部證據失效時不要跟著一起崩」的保底能力。[2]

為什麼有效：它把「衝突」保留下來

一般做法常把多個 passages 直接串接，或以答案投票做聚合；這兩者都可能把錯誤資訊的數量誤當成可信度。Astute RAG 的差異在於先建立資訊群組，再讓每個群組各自產生答案，最後才比較群組。這讓「外部資料多數勝出」不再是唯一規則，也讓「模型記憶答對」有機會抵抗一批錯誤檢索內容。[2]

最值得學的五件事

1. RAG 必須有 no-RAG 退路。「加資料」不是單調增益；在低 precision 情境，沒有檢索反而可能比較好。生產系統要能記錄「有 RAG」與「無 RAG」兩條候選路徑，而不是只保留一條。
2. 來源標籤要跟著摘要走。只保存整理後的結論，等於丟掉日後查錯的證據。壓縮、重排、摘要都不應抹去 URL、文件編號、時間與來源類型。
3. 衝突不是噪聲，衝突是決策資料。不同說法被合併成一個「看似合理」句子後，錯誤很難追。應保留競爭假設，等最後一層判斷。
4. 模型自評的 confidence 不能單獨當可靠度。v1 用 prompt 要模型依可信度與一致性評分，但沒有提供可校準的機率模型或固定權重；工程上仍需要獨立來源、時間、新鮮度與人工覆核規則。[2]
5. 額外推理要有觸發條件。v1 的預設是最多一段內部候選、t=1 的 2 calls；只有 context 長、來源互斥或任務風險高時才增加迭代，不能把 3–4 calls 當成免費的預設。

對 Hermes／DKY 的最小落地版本

不必先複製完整論文框架，也不必立刻新增一個大型服務。先把它做成「後檢索可靠性閘門」：只在檢索稀疏、來源矛盾、或醫療／金融／法規／正式金額等高風險場景啟用。

raw = retrieve(query)
internal = generate_at_most_one_candidate(query)  # 不確定就回不知道
context = consolidate(
    raw + internal,
    keep_source_ids=True,
    keep_conflict_groups=True,
    drop_irrelevant=True,
)
if high_risk_conflict(context):
    require_independent_primary_source(context)
answer = finalize_with_citations(context)
write_memory_only_after_evidence_check(answer)

論文的「20%」是它在特定 Google Search、短答案資料集上的 retrieval precision 觀察，不應直接硬編碼成所有系統的門檻。比較穩妥的做法是先收集自己的事件記錄：query_id、source_id、來源時間、衝突群組、最後採納理由、是否人工覆核，之後再用實測錯誤率調整。

限制與反方檢查

• 評測範圍窄：主要是短答案 QA，正確性以模型回覆是否包含 ground-truth answer 判定；長文摘要、複合推理與引用完整性不在同一個評測內。[2]
• 檢索環境特定：使用 Google Search 的前 30 筆與前 10 個可存取網站，不能直接推論到所有私有向量資料庫、企業文件或中文網路內容。[2]
• 內部知識仍可能錯：它只是另一個證據候選，不是可靠的 ground truth；如果模型本身能力不足，內部候選會把錯誤帶進整理流程。
• 可靠度沒有外部校準：v1 的裁決由同一個黑箱 LLM 依 prompt 完成，沒有獨立 verifier、可重現的權重或校準曲線，因此高風險系統仍要接上外部來源與人工控制。
• 成本與延遲：預設至少多一次內部候選產生 call；迭代整理雖然提升部分結果，但 Gemini 的 t=3 已顯示額外一輪不一定帶來增益。[2]

最終判斷

值得搬走的不是三段 prompt，而是設計原則：把 RAG 當成「外部證據候選」，把內部知識當成「另一個候選」，在答案輸出前設一層能保留來源與衝突的決策閘門。對 Agent 系統而言，這比單純增加 top-k、把 context 塞得更長，或再加一個沒有驗證的 reranker 更有長期價值。

最小可行採用順序是：先記錄 raw evidence 與 provenance，再加入衝突分組，最後只對高風險／低信心案例開啟內部候選與獨立覆核。這樣能取得 Astute RAG 的保底思想，又不會把每個問題都變成 3–4 次昂貴推理。

來源與版本