昨天我們把 Retrieved Evidence 整理成 Evidence Packet：去除重複內容、確認版本與時效、標示來源權威，再依 Attention 與 Cache 的限制組裝 Context。照理來說，模型已經拿到正確資料，今天應該可以安心產生答案了吧？
回到前幾天的例子。使用者問：「升級到 3.2.1 後出現 ORA-12541，要怎麼恢復？」系統回答：
3.2.1 已於 8 月 12 日發布，並移除了參數 X，因此所有 Windows 使用者都不需要再修改 Listener 設定。[1]
引用 [1] 確實存在，也真的提到 3.2.1 與 8 月 12 日。但文件沒有說參數 X 被移除，更沒有說所有 Windows 使用者都不用修改設定。
這句話包含版本、日期、參數變更與適用範圍四個主張。證據只支持前兩個，模型卻讓同一個引用替整句話背書。
Day 8 把可信證據送進模型，只解決了前半段。接下來還要限制模型不能超出證據，並在資料不足時停止。
Grounded Generation 不是讓答案看起來有根據，而是讓每一句可驗證的話都有證據、每一份證據真的支持那句話；證據不夠時，系統也知道要停下來。
討論 Grounding 時，最容易犯的錯是把所有品質問題都叫做「幻覺」。一旦定義不清楚，就不知道該修 Retrieval、Context、Generation，還是資料來源本身。
至少需要拆開以下六個概念：
| 概念 | 真正檢查的問題 | 常見誤判 |
|---|---|---|
| Citation Presence | 回答旁邊有沒有引用標記？ | 出現 [1] 就算可信 |
| Citation Validity | [1] 是否真的指向存在且可存取的來源？ |
編號存在，但 URL、文件或段落不存在 |
| Citation Correctness | 被引用的證據是否真的支持相鄰 Claim？ | 文件談到同一主題，就被當成支持結論 |
| Citation Completeness | 所有需要證據的 Claim 是否都有引用？ | 只替最安全的一句加引用，其餘沒有來源 |
| Groundedness／Faithfulness | 回答是否忠於實際提供給模型的 Evidence？ | 模型靠記憶答對，也被算成 Grounded |
| Factual Correctness | 這個說法在現實世界中是否正確？ | 忠實轉述過期文件，就被當成正確答案 |
答案可能「正確但沒有 Grounded」：模型靠參數記憶碰巧答對，提供的 Evidence 根本沒有這項資訊。在需要追溯來源的企業場景中，仍然是失敗。
答案也可能「Grounded 但不正確」：模型忠實摘要了一份過期手冊。這是 Reference Quality 問題，必須回到 Day 8 的來源權威、版本與 Effective Time。
ALCE 將 Citation Quality 拆成 Correctness 與 Completeness，正好說明「引用對不對」與「該引用的地方是否都有引用」也不能只用一個分數概括。
因此，真正要建立的不是「自動加引用」功能，而是一條能回答以下問題的責任鏈：
這個 Claim 從哪裡來？這段 Evidence 支持到什麼範圍？如果支持不足，系統為什麼仍讓它出現在答案中？
一套比較完整的流程，可以拆成生成前、生成中與生成後三道閘門：
Evidence Packet
↓
1. Answerability Gate：現在的證據足以回答嗎？
↓
2. Claim–Evidence Binding：先選證據，再產生可支持的 Claim
↓
3. Claim-level Verification：逐項驗證、修正或拒答
↓
Verified Answer + Citations + Audit Trail
只在最後請模型「檢查自己有沒有亂講」，等於讓生成器同時當作者與審稿人；只檢查 Context 相關，也阻止不了模型多加沒有來源的推論。
三道閘門分別處理不同錯誤：
| 閘門 | 核心問題 | 失敗後的處理 |
|---|---|---|
| 生成前 | Evidence 是否充分、適用且沒有未解衝突？ | 追問、補 Retrieval、縮小回答或拒答 |
| 生成中 | 每個 Claim 是否綁定允許使用的 Evidence？ | 不生成、拆小 Claim 或標示限制 |
| 生成後 | Evidence 是否真的支持 Claim 的完整語意？ | 刪除、局部修正、重新 Retrieval、轉人工 |
Retrieval 找回的文件和問題相關，只代表它們值得被看見，不代表已經包含完整答案。
例如文件提到 ORA-12541、3.2.1 與 Listener，卻沒有說明作業系統與安裝模式。若回答「所有 Windows 使用者都不需要修改」，就是擅自補上缺失條件。
Answerability Gate 應先把目前狀態分成：
UAEval4RAG 特別研究 Knowledge Base 中不可回答的問題；Abstain-QA 則同時觀察問題是否可回答，以及模型選擇回答或拒答。它們帶來一個很實用的觀念：回答正確與知道何時不回答，是兩條不同的能力軸。
如果只計算已回答題目的正確率，系統可以靠大量拒答取得漂亮分數；只追求覆蓋率，又會逼模型猜測。因此需要同時觀察：
模型說「我有 95% 的信心」不能取代這道閘門。Confidence 是風險訊號，不是證據。Semantic Entropy 能估計部分不確定性，但不是所有事實錯誤的偵測器；RAG 仍要檢查 Evidence Sufficiency、來源衝突與 Claim Support。
拒答不是模型語氣變得保守，而是系統對「目前有哪些證據、還缺哪些證據」做出的決策。
常見的 Citation Prompt 是：「請根據以下資料回答，並附上來源。」它能改善格式，卻不保證 Claim–Evidence 關係正確。
更可靠的方向是 Evidence-first：
內部資料可以長得像這樣：
{
"claim_id": "C1",
"text": "3.2.1 版本於 8 月 12 日發布",
"type": "version_date",
"evidence_ids": ["E2"],
"status": "pending_verification"
}
evidence_ids 必須來自 Application 提供的 Allowlist，不能讓模型自己生成 URL 或不存在的編號。Evidence 也要保留原始文件與 Offset，才能回到真正支持內容的 Span。
ReClaim 探索交替產生 Reference 與 Claim；其核心洞見是：Attribution 應發生在生成過程中，而不是答案完成後的裝飾。
Structured Output 很適合承載 Generation Contract。Outlines 或 XGrammar 一類的 Constrained Decoding，可以確保每個物件都有必要欄位，並避免壞掉的 JSON。
但格式正確不代表事實正確。模型仍可能把 C1 綁到不支持它的 E2，或正確填滿所有欄位後產生錯誤內容。
Constrained Decoding 能保證答案裝得進我們設計的骨架，不能保證骨架裡裝的是真的。
如果 Verifier 一次判斷整段話是否「看起來有根據」，細小但重要的錯誤很容易被其他正確內容掩蓋。
以前面的回答為例：
3.2.1 已於 8 月 12 日發布，並移除了參數 X，因此所有 Windows 使用者都不需要再修改 Listener 設定。
至少可以拆成：
C6 是因果 Claim，不會因為 C3 與 C5 各自成立就自動成立。否定、條件與「必須／可以／不得」也不能在拆解時消失。
FActScore 將長文拆成 Atomic Facts，再檢查多少事實受到知識來源支持；RefChecker 則抽取細粒度 Claim，判斷 Reference 對它是 Entailment、Contradiction 或 Neutral。兩者都指出同一件事：Sentence 甚至可能還太大，Paragraph 更不是適合的最小驗證單位。
Claim Decomposition 本身也會錯，例如漏掉否定、拆壞條件句或混淆同名實體。因此系統需要保存：
否則即使 Verifier 判斷失敗，也無法知道錯在答案、拆解，還是證據對齊。
Claim 與 Evidence 對齊後，Verifier 至少要能區分三種結果：
| 結果 | 意義 | 例子 |
|---|---|---|
| Entailed | Evidence 足以支持 Claim | 文件明確寫出 3.2.1 的發布日期 |
| Contradicted | Evidence 與 Claim 明確衝突 | 文件寫參數 X 仍為必要設定 |
| Insufficient | Evidence 沒有足夠資訊判定 | 文件完全沒談 Windows 適用範圍 |
Insufficient 不能被當成 Supported，也不一定等於 Contradicted。「文件沒有說」不代表事情一定沒有發生，但代表目前這份答案不能把它當成已被證明的事實。
NLI Model 或 LLM Verifier 可以判斷語意支持關係，但容易受到以下內容影響：
must、may、must not 等規範強度因此，語意 Judge 不應成為唯一防線，檢查至少要拆成兩類。
第一類是 Deterministic／Typed Validation：實體 ID、版本、日期、數值、單位、幣別、百分比與 Evidence Allowlist，可以用規則與 Schema 精確比對。
第二類才是 Semantic Verification：語意是否支持、條件是否一致、跨句推論是否成立，以及 Claim 是否超出原文範圍。
例如「故障率從 5% 降到 4%，下降 20%」在相對變化上成立，但若產品要求顯示 Percentage Point，正確說法應是下降 1 個百分點。一般語意 Judge 可能放行，Typed Validator 卻可以檢查公式、分母與顯示口徑。
同樣地，文件發布日不等於規則生效日；「3.10」也不能用字串排序誤判為小於「3.2」。
Verifier 不是另一個負責說『看起來沒問題』的 LLM，而是一組依 Claim 類型選擇證據、規則與判斷器的驗證流程。
當 C3 驗證失敗，若把整段丟回模型重寫，可能修好 C3 卻改壞原本正確的 C1。
更安全的 Repair Loop 應該保留已通過的 Claim，只處理失敗部分：
Verifier Fail
├─ 非必要 Claim → Delete
├─ 說法超出證據 → Local Repair
├─ 缺少關鍵證據 → Retrieve More
├─ 來源互相衝突 → Disclose／Clarify
└─ 高風險或無法判定 → Abstain／Human Review
Final Renderer 只能把通過的 Claim 轉成答案，不能在潤飾時新增事實、因果關係或建議。
若答案完成後才驗證，使用者必須多等；若直接 Streaming，錯誤 Claim 可能在驗證前就送到畫面上。
系統可以整份驗證後再輸出、以 Claim 為單位緩衝，或只延遲高風險欄位。但 Verification Latency、Timeout，以及逾時後要 Fail-open 或 Fail-closed，都必須有明確政策。
雲端服務與開源框架已提供 Citation、Structured Output、Grounding Check 與 Guardrails，但它們位於不同責任層。
| 層次 | 可以處理什麼 | 不能單獨保證什麼 |
|---|---|---|
| Model Generation | 依 Prompt 與 Evidence 生成答案 | 不保證每個 Claim 都有支持 |
| Citation／Grounding Feature | 傳遞來源、產生引用、判斷部分支持關係 | 不保證來源本身正確、最新且完整 |
| Structured Output | 讓 Claim、Evidence ID 與狀態可被程式解析 | 不保證欄位內容為真 |
| Application Validation | Allowlist、型別檢查、門檻、修正與拒答 | 仍需資料、政策與人工標註校準 |
| Offline／Online Evaluation | 比較版本、監控退化與診斷錯誤 | 不會自動阻擋單次高風險回答 |
Anthropic 的 Citations 能引用 Source Block 與對應 Span；AWS、Google 與 Azure 也提供來源歸因、Grounding 或評估能力。它們能降低整合成本，卻不會替 Application 決定哪份文件是 Source of Truth、過期資料能否使用，以及何時必須轉人工。
NVIDIA NeMo Guardrails 的 Fact Checking 可在輸出階段檢查 Evidence Support，也能在無法判定時 Fail-closed；但 Self-check 品質仍依賴使用的 LLM。
RAGFlow、Dify 與 FastGPT 已能傳遞 Retrieval Metadata 或顯示引用，但 UI 能點開來源，不代表已完成 Claim-level Entailment 與 Citation Completeness 驗證。
Provider Feature 可以提供積木；最後是否放行答案，仍然是 Application 必須承擔的責任。
十個 Claim 即使通過九個，唯一錯誤若是金額、日期或版本，平均 90 分仍可能造成事故。
因此 Evaluation 應同時觀察：
| 指標 | 想回答的問題 |
|---|---|
| Claim Support Precision | 系統寫出的 Claim 有多少真的受到支持？ |
| Citation Correctness | 每個引用是否真的支持相鄰 Claim？ |
| Citation Completeness | 需要引用的 Claim 是否全部被涵蓋？ |
| Contradiction Rate | 有多少 Claim 與提供的 Evidence 衝突？ |
| Critical Claim Pass Rate | 金額、日期、版本、權限等高風險 Claim 是否通過？ |
| Answer Coverage／Usefulness | 系統是否真正完成任務，而不是靠刪除內容拿高分？ |
| Abstention Accuracy | 該停時是否停止，能回答時是否過度拒答？ |
| Human Overturn Rate | 人工覆核推翻多少自動放行或阻擋？ |
RAGChecker 的重要觀念，是把 Retriever 與 Generator 的失敗分開診斷。答案沒有根據，可能是：
這五種 Failure 需要不同修法，不能全部壓成一個 Hallucination Score。
Golden Set 至少要包含資料不存在、部分答案、版本衝突、否定句、數字與單位、同名實體、過期文件、惡意 Evidence，以及模型靠既有知識可能答對的題目。
自動 Judge 必須用自己的繁中領域資料與人工標註校準，追蹤 False Pass 與 False Block。多個 Judge 也可能共享盲點；Disagreement 應成為風險訊號，而不是被平均掉。
把今天的內容整理成一條完整流程：
1. 定義 Evidence Contract
每個 Evidence Block 保存 Source、版本、有效時間、Authority、原文 Span、ACL 與允許引用的 ID。過期、越權或無法追溯的資料不能因為語意相似就取得引用資格。
2. 執行 Answerability Gate
依 Evidence Sufficiency、必要條件、適用範圍與衝突狀態，決定 Supported、Partial、Ambiguous、Conflict 或 Unsupported。
3. 規劃 Atomic Claims
先決定回答需要哪些 Claim，再為每個 Claim 選擇 Evidence。保留否定、條件、數字、時間、版本、適用範圍與因果關係。
4. 產生結構化草稿
要求每個 Claim 帶有 claim_id、type、evidence_ids 與驗證狀態；Evidence ID 只能從 Allowlist 選取。
5. 分層驗證
先做 Citation Validity、Schema 與 Typed Validation，再做 Entailment、Contradiction 與 Sufficiency 判定。高風險 Claim 採更嚴格門檻。
6. 修正或停止
刪除非必要內容、局部修正、補 Retrieval、揭露衝突、拒答或轉人工。修正後重新驗證，不讓 Final Renderer 新增事實。
7. 保存 Audit Trail
記錄 Generator、Verifier、Schema、Threshold、Policy Version、Claim–Evidence Mapping、Repair 與 Abstention Reason。敏感 Evidence 仍需遮罩。
8. 同時衡量風險與覆蓋率
不能用「全部拒答」換取零 Unsupported Claim。產品要依 Claim 風險，取捨 False Pass、False Block、Latency 與人工成本。
Selective 的含義，是決定哪些 Claim 有資格生成，哪些必須縮小、補查或停止。
回顧 Day 6 到 Day 9：
Grounded Generation 不是在 System Prompt 加一句「只能依照資料回答」。Prompt 只能表達意圖；系統還需要 Answerability、Claim–Evidence Binding、Validation、Repair、Abstention、Human Review 與可觀測性。
Citation 不是答案正確的徽章。它必須存在、放在正確位置、支持完整 Claim，並涵蓋所有需要證據的內容。
最重要的是，Groundedness 仍不是世界真相。模型可以忠於錯誤文件，所以 Source Authority、版本與有效時間必須從 Day 8 一路保留到 Verifier；Verifier 也可能犯錯，所以門檻必須用真實資料校準，高風險案例仍要保留人工控制。
成熟的 RAG 不只是找得到資料、塞得進 Context，也不是回答旁邊出現幾個引用編號；而是系統能對每個被放行的 Claim 說明：它由哪一段證據支持、支持到什麼範圍，以及證據不足時為什麼選擇停止。
下一步，當 Retrieval、Context 與 Grounded Generation 都有了清楚責任，問題就會來到：我們如何用一套端到端 Evaluation，證明每一層真的有改善，而不是只挑幾個看起來不錯的 Demo？
iThome鐵人賽
看影片追技術