客服問：「客製配件到貨第 7 日，可以直接核准換貨嗎？」公司的 AI 助手回答：「十四日內可以直接換貨。[1]」底下還附了一個文件連結。客服拿著答案問主管，才發現現行規範要求主管審核。
文件明明就在知識庫裡，怎麼還會答錯？
RAG 是先找出相關資料，再交給模型回答。切塊後可以建立字面索引，也能用 embedding 把文字轉成向量；查詢也轉成向量，找語意相關的片段，取回原文供回答使用。這套流程不需要把整個知識庫訓練進模型。
原檔有資料、搜尋找得到、模型真的讀到、回答用對條款，是幾件需要分開確認的事。接手的前線部署工程師（FDE）得把這次問答重放，找到錯誤第一次出現在哪裡，才知道要跟誰修哪一層。
這裡用一份本刊虛構的內部售後換貨 SOP 來說明，編號是 RMA-A17。它規定客製配件在到貨 7 日內可受理，包含第 7 日，但須主管審核，客服不能直接核准。下面的表格、JSON 和 trace 都是本刊為教學設計的虛構示意，不是消保法規、真實文件或實測 log；各段示範不同故障分叉，不表示同一系統發生過所有問題。
圖解：KeepInAI。文件入庫與查詢路徑的示意架構。
打開原頁，看看那一列還在不在
先請資料負責人確認正確條款，再把 SOP 第 3 頁和解析輸出並排打開。這是示意原頁的兩列資料，屬於 RMA-A17/v2：
| 品項 | 到貨後受理期限 | 核准方式 |
|---|---|---|
| 一般品 | 7 日內，含第 7 日 | 客服可核准 |
| 客製配件 | 7 日內，含第 7 日 | 須主管審核 |
「可受理」只表示案件能進入處理流程。第三欄才決定誰能核准，解析結果必須保住客製配件和「須主管審核」的對應。
如果抽出的文字變成一串「一般品、客製配件、7 日內、客服可核准、須主管審核」，字都在，列與欄的關係卻沒了。後面的模型可能把一般品的權限接到客製配件上。
Microsoft 的文件版面解析說明把文字、表格、段落角色與章節結構分開呈現。對這個問題，FDE 要看的就是解析文字和表格資料：品項有沒有對到正確欄位，表頭、頁碼、例外或否定詞有沒有留下來。掃描頁還得核對 OCR 辨識文字的結果；PDF 有文字層，也不能直接認定表格已經讀對。
原檔有、解析後沒有，就先跟資料工程或文件處理的負責人修解析，抽幾頁有表格、雙欄或小字的內容回查。原檔本身寫不清楚，則請資料負責人補定義。這時靠 prompt 要模型「仔細一點」，補不回消失的那一列。
追到切塊後，別讓例外跟表頭分家
解析沒問題，再打開切塊檔，例如 chunks.jsonl。chunk 是給搜尋和模型使用的一小段文件。單獨拿出客製配件那一塊，讀者還能知道「7 日內」指什麼，以及誰能核准嗎？
若表頭在前一塊，「須主管審核」又被切到下一塊，搜尋只取回中間那段，就容易漏掉限制。FDE 可以跟索引管線的負責人調整切法，讓條件和例外一起讀得懂；大表分段時重帶表頭，必要時取相鄰段落。Google 的解析與切塊文件也提供按版面結構切塊、來源頁範圍和相鄰 chunk 的做法。相鄰段同樣要符合權限與版本範圍。
每一塊還要能追回版號、第 3 頁、章節與授權範圍。把這些 metadata，也就是跟著內容保存的資料欄位，和 chunk 一起核對。
可以先用這樣一筆 JSON 核對輸出。欄位是本刊自訂的示意 schema，不是任何廠商 SDK 格式，也不是可直接上線的權限設定：
{
"chunk_id": "RMA-A17-v2-p3-custom",
"document_id": "RMA-A17",
"version": "v2",
"section": "換貨受理條件",
"page": 3,
"effective_from": "2026-10-01",
"effective_to": null,
"allowed_roles": [
"support",
"manager"
],
"text": "客製配件：到貨7日內（含第7日）可受理，須主管審核；客服不能直接核准。"
}text 要同時保留期限與主管審核，page 要點得回原頁；document_id 和 version 用來排除相似編號與錯版。allowed_roles 只是這個例子的角色範圍，真實系統仍由服務端按既有身分與授權規則判定。若內容正確、搜尋卻沒按這些欄位限制，故障就出在資料欄位沒有落到實際查詢。
版本在這個案例尤其重要。假設 v2 從 10 月 1 日起生效，舊 v1 才是「十四日內可直接核准」。資料負責人已定義以受理日選版，那 10 月 5 日受理的案件就要用 v2。歷史案件仍可能需要 v1，不能把舊版全部刪掉，也不能拿今天最新條款回答所有過去的問題。用購買日、到貨日還是受理日選版，得先由業務定義，不能留給模型猜。
搜尋找到了，還要看模型收到什麼
下一份要打開的是檢索候選紀錄。保留這次問句、品項編號、適用日期，以及由服務端確認的登入身分；分開看字面搜尋和向量搜尋各找到了什麼。
向量搜尋用語意相近程度找資料，適合處理不同問法；遇到 RMA-A17 這類編號，還需要字面核對。另一份 RMA-A71 文字很像，卻是不同品項。Anthropic 的 Contextual Retrieval 說明用特定代碼的例子解釋，BM25 字面搜尋可以補語意搜尋的不足，也介紹合併結果與重新排序。但 BM25 仍是排名方法；編號必須完全一致時，要用結構欄位或明確的字面規則核對，不能把高分當成主鍵匹配成功。
如果 v2 第 3 頁根本沒出現在候選裡，查的是切塊、索引是否完整，以及搜尋條件。如果它已經在候選裡，就再打開排序結果和實際送給模型的 context。context 是這次回答所讀到的上下文，不能拿資料庫裡「理論上可取得」的內容代替。
正確段落可能被重新排序擠掉，也可能在去重、取前幾筆或長度裁切時消失。FDE 要留下選入的 chunk ID 和移除理由，跟負責搜尋或模型輸入的人確認：客製配件那一列，到底有沒有完整送進去？2023 年的 Lost in the Middle 研究也在特定問答實驗中區分了檢索到資料和模型答對的結果；當年的模型結果不能直接套到所有新模型，但提醒我們兩層要分開測。
把候選紀錄和模型輸入串起來，可能看到下面這個示意故障 trace，同樣用本刊自訂欄位。身分與適用版本已在搜尋前由服務端決定，清單裡的內容也都在授權範圍內。sent_to_model_text 是模型輸入的精簡示意；這裡刻意示範組裝 context 時，必要條款被長度預算裁掉的錯誤：
{
"verified_role": "support",
"case_date": "2026-10-05",
"scope_resolved_before_search": {
"document_id": "RMA-A17",
"version": "v2",
"permission_filter_applied": true
},
"ranked_candidate_ids": [
"RMA-A17-v2-p3-custom",
"RMA-A17-v2-p1-intro"
],
"context_builder": {
"selected_ids": [
"RMA-A17-v2-p3-custom",
"RMA-A17-v2-p1-intro"
],
"removed": [
{
"chunk_id": "RMA-A17-v2-p3-custom",
"reason": "budget_trim"
}
],
"sent_to_model_ids": [
"RMA-A17-v2-p1-intro"
],
"required_evidence_present": false,
"sent_to_model_text": "RMA-A17 售後作業介紹：客服先確認案件資料。"
}
}RMA-A17-v2-p3-custom 出現在候選和初選清單，卻不在 sent_to_model_ids；移除理由是 budget_trim，sent_to_model_text 也只剩第 1 頁的介紹。required_evidence_present 是本例按必要條款人工核對的結果，沒有宣稱系統能自動辨識所有缺漏。這份紀錄把故障指向 context 組裝：FDE 要跟負責人修必要證據的保留方式，證據不齊時轉交或要求補查，不能讓模型照常給核准結論。它還不能證明錯答裡的「十四日」從哪裡來，得再對照實際輸入和引用映射，不能直接猜是模型讀到舊版。
條款和例外都已完整送入，回答仍然用錯，才往回答指令和模型查：問句的品項、日期是否綁對，模型有沒有忽略限制，引用又是否接到了別段。讓每次輸入和輸出對得起來，修復才有依據。
權限要沿途檢查，引用要真的支持答案
假設主管另有一份審核附件，客服無權讀。客服仍可以從已授權的主 SOP 得到「須主管審核」這個答案，但不該看到附件內容，也不該由回答得知未授權文件的存在或標題。
FDE 得跟系統負責人取得可信的身分和授權規則，跟資料負責人確認每份文件的權限與更新方式，再把規則落到搜尋和讀取流程。模型不能憑使用者寫在問句裡的角色，決定誰能看什麼。Microsoft 的文件存取控制說明也區分了文件權限資料、查詢時的限制和來源權限同步；其中部分原生能力仍標示 preview，接入前要核對所用功能的狀態。
驗收時，用客服和主管兩種身分重問同一題，檢查字面與向量搜尋、直接取 chunk、相鄰段落擴展，以及送往重新排序服務和模型的內容。不能先把受限全文送給第三方，再等答案產生後遮掉。快取要隔離授權範圍，文件或權限改變後也要能失效；引用原檔的下載和診斷日誌，都要有相應的存取控制。日誌只留排錯必要的資料，受限全文不能因為是 log 就放行。
接著才是回答的引用。[1] 存在、連結打得開，能證明有這份文件；還得看段落是否支持「可直接核准」，以及版號、品項和日期是否適用。
ALCE 論文把引用支持與覆蓋放到逐項主張來看，也指出引用表現好仍可能答不完整。放回這個例子，就把「第 7 日可受理」「須主管審核」「客服不能直接核准」分別核對。業務是否正確、版本是否適用，也要另外驗。
下面把同一案件的主張核對寫成兩欄。這也是人工判讀的示意，supported 看引用是否支持句子，applicable 看來源是否適用這次的身分、品項和日期；兩者不能混成一個分數。
| 主張與引用 | 核對結果 |
|---|---|
| 「第 7 日可受理，但須主管審核」；引 v2 第 3 頁客製配件列 | supported：是。applicable：是。條件與例外都對得上。 |
| 「十四日內可直接核准」；引 v1 舊條款 | supported：是。applicable：否。文字有根據，但不適用 10 月 5 日受理的案件。 |
| 「客服可直接核准客製配件」；引 v2 第 3 頁客製配件列 | supported：否。applicable：是。引用指對條款，結論卻跟條款相反。 |
第一列仍要看回答有沒有漏掉使用者問的事項；兩欄都通過，不等於整個答案已經完整。需要一組來源共同支持的主張，按整組證據核對，而不是拆成每份來源都必須獨立證明全部。
資料只支持受理條件，卻沒有核准權限，就回答能證明的部分，再請指定人員確認。缺品項或受理日，先問清楚；兩份適用規範互相衝突，交回資料負責人處理，別讓模型挑一句順口的。
修完後，把同一組問題重跑給負責人看
一題答對了，可以確認這個例子有改善。要交付，還得找一小組已確認答案的題目，也就是金標題，看看同類問題會不會再出現。
請資料負責人確認每題適用品項、日期、原頁和必要答案要點。題目要包含表格例外、A17 和 A71、現行與歷史版本、兩種權限，以及缺資料時應該澄清或交接的情況；留一些沒用來調整系統的題目。需要兩段證據一起回答時，記下整組條款，不只找答案裡有沒有某個關鍵字。
Microsoft 的 RAG 評測說明分開看回答有沒有根據、是否正確、是否完整。這裡也分層記：解析保住了關鍵列嗎，候選找齊了必要證據嗎，實際 context 留下了條件與例外嗎，回答是否用對條款、引用是否支持？改切塊後要重新對回原頁，不能把同一句拆成更多塊，就當成召回改善。
比較修前修後，固定同一組題目、資料快照及其餘設定，記下 parser、切塊、搜尋、排序、模型和 prompt 的版本，先改一層來判斷原因，再把整段流程重跑，同時看延遲與成本。模型評分可以協助初篩，關鍵條款和反例仍由人核對，也要用人工確認的反例檢查評分模型會不會判錯。
權限越界單獨列出，發現一件已知越界就停止該版交付、修好再驗；小樣本零錯不能證明生產環境一定安全。可回答卻拒答、不可回答卻亂答，也要分開記，不能靠多拒答讓分數好看。
FDE 最後交給團隊的，可以是一份能重放錯答的診斷包：原頁與解析對照、可追溯的 chunk、候選與實際 context、逐項引用核對，以及資料負責人確認的回歸結果。每個修復項寫清楚誰接手。下一次客服問到第 7 日的客製配件，團隊就能查到，系統為什麼回答「可受理，但須主管審核」，以及這個答案用的是哪一版、哪一列規範。
