Guardrails 可以在回覆交付前，攔下部分缺乏來源支持的內容。但要說它「防止幻覺」，還得先問：這次檢查依據哪份資料，檢查了回答裡哪些主張？
前一篇談的是客服願意受理哪些問題。到了企業知識問答，問題即使落在服務範圍內，系統也未必有資料能回答。導入檢索增強生成（Retrieval-Augmented Generation，RAG）後，這個限制仍然存在：找到一段相關文字，模型還是可能補上文件沒說的條件，或把適用範圍不同的規定接在一起。
筆者在之前整理 RAG 評估指標時，就把使用者提問、檢索內容與回覆分開看。這篇延續這個區分，討論來源支持度（Groundedness）：回答中的主張，能不能從提供的來源得到支持？它能幫我們限制無根據的回答，但來源是否正確、是否適用，仍然需要另外處理。
以下以一個虛構的企業內規問答為例。使用者問：
我還在試用期，可以申請每週三天居家工作嗎？
假設系統這次取得的現行內規只有兩句：
居家工作每週至多兩天，申請須經直屬主管核准。
如果模型回答「可以，試用期員工每週可以居家三天，口頭告知主管即可」，問題很清楚。三天超過了文件的兩天；口頭告知也不能直接替代核准。至於試用期是否可以申請，這段來源根本沒有說。
回答裡有與來源衝突的主張，也有缺乏支持的主張。試用期資格即使碰巧答對，仍然不能由這份文件推出來。當服務承諾依內規回答，就需要交代這個判斷的依據。
TruLens 的 RAG Triad 文件用的也是這種檢查方式：把回答拆成個別主張，再從檢索內容找支持它們的證據。Groundedness 檢查的是回答與來源的關係。
檢查時，還要保留來源的條件。文件若寫「經主管核准後可以申請」，回答卻只剩「可以申請」，少掉的條件可能正是業務上最在意的部分。來源沒有逐字寫出答案，也不代表不能回答；合理改寫與推論仍然可以成立，但必須保留原本的限制，並說明推論所需的前提。
文末附上一個文件連結，也還不能證明整段回覆都有依據。那個連結可能只支持「每週至多兩天」，沒有支持試用期資格。引用品質要看它實際支持哪一句，而不是回答裡總共出現幾個連結。
現在換一個條件。假設知識庫裡留著舊版內規，寫的是「每週至多三天」，模型忠實地把這句話回給使用者。
回答與舊文件可以完全一致，卻仍然不適用於目前的申請。若來源支持度的檢查只拿這份舊文件比對，就不會因此發現新版已改成兩天。這是從檢查範圍推得出的限制：對來源忠實，不能替代對來源適用性的確認。
企業文件常有這類差異。不同公司、部門、員工身分或生效期間，可能使用不同規定；產品文件也可能只適用某個型號與版本。內容與「居家工作」高度相關，仍不足以回答這位使用者的資格。
因此，檢索之前與檢索之後，都需要處理文件身分：哪份是有效版本，適用哪些對象，是否已被取代。若兩份文件互相衝突，又沒有可信的版本或優先規則，讓模型挑一份看起來合理的答案，等於把內規的解釋責任交給生成器。
同樣地，「這次沒找到」只能說明目前的檢索結果不足。資料可能不在知識庫，也可能被切到別的片段，或根本沒有被檢索到。這時直接回答「公司沒有試用期限制」，就把查不到的資訊變成了不存在的規定。
再回到原本那兩句內規。如果模型回覆一大段居家工作的設備申請辦法，每句都能在文件中找到，使用者仍然不知道試用期可不可以申請。
TruLens 的 RAG Triad因此把三種關係分開檢查：
這三個角度可以幫我們定位問題，但不宜把分數加總後，就宣布答案可靠。本例即使找回了相關內規，仍缺少試用期資格；回覆講得再切題，也無法填補這個缺口。
Amazon Bedrock 的 contextual grounding checks也分別檢查來源支持與回答相關性，並讓應用設定各自的門檻。文件列出的用途包含摘要、改寫與問答，另明示不支援對話式問答／Chatbot；選用時不能只因功能名稱相近，就推定它能直接處理多輪客服。
檢查結果要接回本例，服務仍需決定試用期資格是否有足夠資料，以及缺資料時怎麼回應。
對這個內規問題，比較有用的回覆可以是：
目前找到的規定是每週至多兩天，且須經直屬主管核准。我尚未找到試用期員工是否適用的條文，因此無法確認你的申請資格；需要再查適用內規或向人資確認。
它保留了來源可以支持的部分，也說清楚缺少哪個條件。沒有為了交出完整答案，替公司補一條試用期政策。
這就是拒答或暫不作答（Abstention）需要細分的原因。缺少使用者身分，可以先澄清；資料只支持一部分，可以在政策允許時回答那一部分；來源不足以確認資格，就停在那個問題，並提供查詢管道。整段回覆不必只剩「無法回答」。
不過，拒答也可能發生在資料明明足夠的時候。如果有效內規已明確說明試用期資格，系統還是拒絕，就讓原本能完成的查詢失去功能。TruLens 的評估介面就有把「依來源能否回答」納入拒答評估的方式，區分合理保留與本來應該回答卻沒有回答。
從服務設計看，值得同時關注的，是無資料支持卻給了確定答案，以及有足夠資料卻過度拒答。門檻放得更嚴，可能攔住更多無根據的內容，也可能增加後者；這個取捨要放回實際問答與適用規定來看。
來源支持度可以用來做離線評估，找出哪些回答需要改善。要把它用成線上的 Guardrail，流程還必須在交付之前等待結果，並依結果處理回覆。
在本例中，若系統已判定「試用期可以每週居家三天」缺乏支持，畫面卻仍然顯示這句話，使用者依舊會拿它作為申請依據。記錄到問題和攔下問題，是不同的結果。
處理也未必都是整段封鎖。可以重新生成、移除缺乏支持的主張，或改用部分回答；修改之後，仍要確認保留下來的內容與原問題相符。若移除了否定詞或必要條件，剩下的句子反而可能改變意思。檢查逾時或沒有完成時，也不能視為已確認有來源支持。
回到這位試用期員工，服務能提供的協助，是說明目前找到的有效規定，指出資格資訊的缺口，讓他知道接下來查什麼。Groundedness Guardrails 能攔下部分越過來源的回答；要讓答案適用於這位使用者，還需要可靠的資料、正確的檢索與清楚的業務條件。
當企業要求「不要有幻覺」時，可以從具體承諾開始：哪些答案必須有來源支持，哪些條件缺少時應暫停判斷，以及使用者最後會收到什麼。這樣才有辦法討論防護是否達到目的，也能看見仍由知識庫與服務流程承擔的責任。
iThome鐵人賽
看影片追技術