AO2 FIELD GUIDE · N042 · 企業知識庫與治理
知識庫品質驗收從代表任務、預期來源與失敗條件開始，分開檢查資料、查找及應用。附驗收矩陣與缺陷分流表，避免以檔案數量代替可用性。
匯入多少文件、搜尋有沒有結果，只是交付的一部分。真正的驗收要讓使用者在自己的權限與產品情境下，找到可採用的版本、辨認限制，並知道資料不足時下一步找誰確認。
知識庫品質驗收：先寫成功與失敗的任務
用日常工作定義測試，而非要求驗收者隨意搜尋。每一題記錄角色、產品條件、預期來源、應保留的限制與完成標準。例如新業務需要找到核准的產品說明，維護人員需要辨認舊設備版本，編輯需要確認哪份資料可以公開。不同角色看見不同範圍，不能由管理員帳號一測就代表所有人通過。
同時寫出應該失敗的情況：無權限資料不應被找到，缺少型號時不應直接選定版本，已撤回文件不應繼續當成最新依據。這些負向題目能揭露「結果看似完整」背後的風險。驗收目標不是每次都回答，而是在不確定時保留正確邊界與接手路徑。
| 測試類別 | 預期行為 | 需保存證據 |
|---|---|---|
| 正確查找 | 找到核准且適用的資料 | 問題、來源與版本 |
| 條件不足 | 詢問必要條件或保留未知 | 缺少欄位與提示 |
| 限制資料 | 未授權角色無法取得 | 角色與實際結果 |
| 歷史版本 | 辨認舊版適用範圍 | 版本及選擇理由 |
| 變更後重測 | 舊缺陷修復且未破壞其他任務 | 修訂及回歸測試 |
把資料、查找與工作採用分開檢查
資料層先看內容是否完整、版本是否核准、單位與註腳是否保留。查找層再看客戶用語、型號與條件能否找到預期來源。工作層則讓使用者依資料完成一次比較、回覆或文件準備。若這三層混在一起，查不到資料可能被誤認為模型不好，規格錯誤也可能被漂亮的回答遮住。
假想電子模組知識庫中，文件名稱相同但版本不同。測試者找到最新檔案，仍可能不適用客戶的舊韌體。驗收應要求指出「這份資料適用什麼版本」和「哪些情況不能採用」，不只勾選找到文件。若原始主檔未標版本，先修資料，再調整搜尋與回答方式。
抽樣要涵蓋風險，不只選最乾淨的文件
將文件依來源、格式、重要性與更新頻率分組，刻意加入掃描 PDF、跨頁表格、同名產品、歷史文件和限制資料。抽樣數量應由資料差異與風險決定，本文不提供適用所有企業的固定比例。未測到的範圍要列在驗收報告，避免少量通過被解讀為全部內容都正確。
| 失敗現象 | 先查位置 | 可能負責人 |
|---|---|---|
| 找到錯型號 | 別名、產品 ID 與標記 | 產品／資料維護 |
| 表格數字失真 | 原頁、抽取與轉換 | 文件處理人員 |
| 權限外洩 | 登入、授權與查詢限制 | 系統管理者 |
| 答案沒有來源 | 檢索及引用呈現 | AI 應用維護者 |
| 工作無法接續 | 入口、窗口與交接欄位 | 業務／流程負責人 |
對生技製藥合作資料，測試清單可納入對外使用範圍、審核狀態與到期條件。此處驗收的是知識使用與文件流程，不等同專業、法規或產品資格認證。需要專門判斷的部分，明確列出合適角色與所需文件，不能因知識庫能回答，就當成企業已完成正式審核。
讓缺陷能回到正確負責人
每個失敗案例保留輸入條件、帳號角色、實際結果、預期結果與來源位置。缺陷分流到資料、權限、索引、介面或流程，並記錄影響範圍。不要只寫「答案不準」或「搜尋不好用」，否則修正者很難重現，下一輪驗收也無法確認是否真的解決。
Microsoft 的 可靠性測試策略強調以故障情境驗證系統行為。本文借用測試失敗與復原的思路整理知識庫驗收表；這不是官方知識品質分數，也不是只做壓力測試就能確認內容正確。資料審核與系統測試仍需各自留下證據。
重測與放行要保留版本
修正後先重跑原失敗案例，再測受影響的相鄰任務。例如修改產品別名映射，除了原來查不到的詞，也要確認沒有把另一款產品導向錯誤來源。記錄資料版本、系統設定與測試日期，讓驗收結果能被重現。結果只有「通過」而沒有條件，對下一次更新幾乎沒有幫助。
上線可依範圍分階段：先開放已確認的資料與角色，尚未完成的部分列為限制，不為了趕進度隱藏重大缺陷。放行文件應記錄已測範圍、未解問題、接手責任與回退方式。若後續加入 AI 問答，另做檢索、生成與引用測試，不能把文件庫驗收直接當作 RAG 驗收。
常見問題
搜尋有結果就算通過嗎？
不算。可把驗收拆成四類任務：已知問題能找到核准資料、版本限定問題不會混用文件、無資料問題會保留未知，以及不同權限不會取得不該提供的內容。每題先指定適用來源、必要條件與預期行為，再保存實際結果。例如問題限定舊型號，系統雖找到同系列新品資料仍應判失敗；來源正確但漏掉會影響選型的限制，也不能視為通過。不同缺陷應分開記錄，優先修正錯用版本、錯誤主張與越權，再處理排序或用語問題；單一成功率會掩蓋這些差異。
所有文件都要人工逐字驗收嗎？
可按影響程度安排，但不能把抽樣結果說成全部通過。先列出產品規格、版本與權限等關鍵欄位，提高這些資料的核對程度；一般背景說明可依文件類型與處理流程抽樣。記錄抽樣範圍、發現缺陷與未測部分。若同一辨識流程造成重複錯誤，應擴查受影響批次，而非只修抽中的一筆；高影響主張未確認前，保留待核准狀態。
知識庫驗收可以沿用到 AI 問答嗎？
來源、分類與版本驗收可以作為基礎，但 AI 問答需另驗證檢索、生成與引用。沿用同一組任務，分開記錄是否找到正確來源、是否保留適用條件，以及答案是否超出證據。再加入無資料、衝突資料與無權限的題目，確認會補問、拒答或交接。文件本身正確，仍可能在切段後漏掉表頭或在回答時省略限制，因此不能直接沿用文件驗收的通過結論。
來源與方法範圍
查核日期：2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明；工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例，不作客戶實績、產品資格或效果背書。
