引用看起來正確，不等於答案有根據
許多 RAG 系統會在答案後面附上文件名稱、頁碼或連結，但這只能證明系統曾經檢索到某份資料，不能證明每一句答案都由該資料支持。語言模型可能混合多個片段、補入既有知識，或把文件中相近但不同的規則拼在一起。最常見的錯誤不是完全虛構，而是引用真實、結論卻超出原文。
工程上應把問題拆成三層。第一層是檢索溯源：送進模型的片段究竟來自哪個檔案與版本。第二層是主張支持：來源文字是否直接支持答案中的具體陳述。第三層是引用呈現：使用者能否快速回到原始位置核對上下文。三層缺一，引用就可能只是介面上的裝飾。
先建立不可混淆的文件身分
驗證必須從資料匯入階段開始。每個片段至少要保存文件識別碼、版本、章節、頁碼或段落位置、擷取時間與原始檔案位置。若文件可能被更新，不能只保存檔名；同名檔案可能已有不同內容。實務上可加入內容雜湊值，讓系統知道答案依據的是哪一版，而不是目前碰巧出現在資料夾裡的版本。
切塊也會影響引用品質。片段過短時，模型可能看到一句規則卻缺少適用條件；片段過長時，引用雖然命中，使用者卻難以判斷支持答案的是哪一句。合約、作業規範與產品手冊通常應沿用標題、條款或表格邊界切分，並保留父章節。掃描 PDF 還要特別檢查 OCR、頁碼錯位、表格欄位順序與頁首頁尾污染。
- 來源識別：保存穩定的文件 ID、版本與內容雜湊值。
- 位置資訊：記錄章節、頁碼、段落或字元範圍，而不只是一個下載連結。
- 存取範圍：把部門、角色與文件權限帶入檢索，避免引用到使用者不應看到的內容。
- 原文快照：保留實際送入模型的片段，方便重現當時的回答。
- 解析品質：針對表格、圖片、掃描檔與多欄排版建立人工抽查流程。
以主張為單位驗證，而不是只檢查整段答案
可靠的流程會先把答案拆成可驗證的主張，例如資格條件、操作步驟、金額限制、責任歸屬或例外情況，再要求每項主張對應到一個或多個來源片段。驗證器要判斷的是來源是否蘊含該主張，而非兩段文字是否出現相似關鍵字。若答案說「所有供應商都必須通過審查」，原文只寫「高風險供應商需要審查」，即使關鍵字高度重疊，也不應通過。
驗證可採規則、第二個模型，或兩者組合。規則適合檢查文件 ID、頁碼、連結、數字與日期是否存在；模型較適合判斷改寫後的語意是否受到原文支持。對高風險內容，驗證器應能回傳支持、矛盾、資訊不足等狀態，並在矛盾或不足時刪除主張、重新檢索或明確拒答。不要讓生成模型自行宣告引用正確，因為它可能重複同一個推論錯誤。
多文件回答還要處理衝突。當新版政策與舊版手冊內容不同，系統需要明確的版本優先順序、生效日期與文件權威等級。若無法判斷哪份文件有效，合理的結果不是挑一份較像答案的資料，而是指出衝突並請使用者確認適用版本。
用可重現測試維持正式環境的可信度
上線前應建立一組來自真實文件結構的測試題，涵蓋可直接回答、需要跨段落整合、文件互相矛盾、資料不存在，以及使用者無權存取等情境。每題不只保存預期答案，也要保存允許引用的文件、必要證據與不可接受的推論。如此才能分辨錯誤發生在解析、檢索、排序、生成還是驗證階段。
營運時應記錄查詢、檢索候選、實際提供給模型的片段、答案、引用與驗證結果，但必須依資料敏感度設定遮罩、保存期限與存取控制。評估時可分別觀察來源命中、主張支持、引用位置正確性、衝突處理與拒答品質；只看答案是否流暢，通常會掩蓋最重要的風險。
最實用的設計原則是：任何重要主張都應能從答案一路追到固定版本的原文，而且第三方可以重現判斷過程。若做不到，應把答案標示為未驗證，而不是用漂亮的引用格式製造確定感。當資料來源橫跨檔案庫、ERP、CRM 與權限系統時，整合團隊的重點也應放在這條證據鏈，而不只是把模型接上搜尋介面。