先定義「可檢索」，不要從選向量資料庫開始
企業文件通常散落在共用磁碟、Google Drive、SharePoint、電子郵件、工單系統與部門電腦中，格式則包含 PDF、Word、簡報、試算表、掃描影像與網頁。把這些檔案集中存放，只解決了保管問題；使用者真正需要的是依問題找到正確段落、確認答案出處，並知道內容是否仍然有效。
工程團隊應先蒐集實際查詢情境，例如查找設備維修步驟、比較不同版本的合約條款，或確認某項內部流程的負責人。每種情境對檢索的要求不同：技術手冊重視章節與零件名稱，合約需要精準文字及版本，會議紀錄則常依日期、專案和參與者篩選。若沒有先定義這些需求，後續即使搜尋速度很快，也可能只是在更有效率地回傳不相關內容。
建立可重跑、可追溯的文件處理管線
穩定的知識庫需要一條可重跑的擷取管線。每份文件都應保留來源位置、原始檔案識別碼、版本或修改時間、擷取時間、擁有部門、可見權限與處理狀態。這些欄位不是附加資訊，而是去除重複文件、同步更新、執行權限過濾及追查錯誤的基礎。若系統只儲存切分後的文字與向量，日後很難回答某段內容來自哪個版本，也無法可靠地刪除已撤回的文件。
文字擷取必須依格式採用不同策略。原生 PDF 可直接讀取文字，但多欄排版可能打亂閱讀順序；掃描檔需要 OCR，且表格、頁首與印章容易造成誤判；簡報應保留投影片標題與備註；試算表則通常要把工作表、欄名和資料範圍轉成有語意的紀錄。遇到擷取品質不足的文件，應標記為待檢查，而不是讓不完整內容悄悄進入索引。
- 正規化：統一編碼、空白與常見標點，但保留標題、清單、表格關係及頁碼等結構。
- 去重：同時比較檔案識別、內容雜湊與版本資訊，避免同一文件的副本互相競爭。
- 切分：優先依章節、段落或表格邊界切分；固定長度只適合作為安全上限。
- 中繼資料：保存文件類型、語言、日期、產品、部門與保密等級，支援查詢前過濾。
- 索引生命週期：對新增、修改、刪除和權限變更建立明確同步流程，並記錄失敗項目。
檢索品質取決於切分、排序與查詢理解
切分太小，結果會缺少前後文；切分太大，無關內容會稀釋關鍵訊息並增加模型輸入成本。實務上可先以完整的小節、條款或問答單位作為區塊，必要時附帶上層標題與少量相鄰內容。表格不宜逐列盲目切開，因為欄名、單位和註解往往決定資料含義。對需要逐字核對的政策或法務文件，還要保留頁碼和原文定位。
向量搜尋適合處理同義詞與自然語言問題，但對產品代碼、錯誤訊息、料號和專有名詞，關鍵字搜尋通常更可靠。因此企業知識庫常需要混合搜尋：先套用權限與中繼資料條件，再結合關鍵字和語意候選，最後以重新排序模型或明確規則排列結果。若使用生成式 AI 回答，系統應只根據取回內容作答、顯示可點選來源，並在證據不足時明確表示無法確認。
評估不能只看幾個示範問題。應從不同部門蒐集真實查詢，建立包含預期文件、可接受段落與無答案問題的測試集。每次調整 OCR、切分、嵌入模型、搜尋權重或排序方式後，都用同一批問題比較結果。人工檢查時，除了相關性，也要確認版本、權限、引用位置與答案是否超出證據。這種回歸測試比單純更換模型更能穩定提升品質。
把權限、更新與營運納入第一版設計
知識庫的存取權限至少要與來源系統一致。查詢時應依使用者身分過濾候選內容，而不是先搜尋全部資料，再要求語言模型忽略無權查看的片段。權限變更也必須快速同步；否則離職、調職或文件撤權後，舊索引仍可能暴露內容。若跨系統身分無法直接對應，應先建立清楚的群組映射與例外處理規則。
文件更新同樣是產品功能。系統需要監測來源同步延遲、解析失敗、無法辨識的掃描檔、重複內容、索引落差及無結果查詢。保留處理日誌與文件血緣，才能在使用者回報錯誤答案時，追查是來源過期、擷取失敗、搜尋漏接，還是生成階段誤解證據。
較穩健的導入方式，是先選擇邊界清楚、文件擁有者明確且查詢需求頻繁的資料域，跑通同步、權限、引用與評估流程，再擴展到其他系統。技術選型固然重要，但真正讓知識庫可長期使用的，是可追溯的資料管線、持續測試，以及有人負責處理內容生命週期。