新人一直問、老員工反覆教：企業該先整理 SOP，還是建立 AI 知識庫？

一家持續招募新人的公司常有熟悉的畫面：新人問「這張表要交給誰」，資深同事回答「我上次不是說過」；新人問「客戶要求改交期能不能答應」，另一位主管說「你先問業務」；隔天碰到不同客戶，同一套問題又重新演一次。有人主張把 SOP 做完整，有人提議直接建立 AI 知識庫，讓新人自己問。兩種看法都抓到部分問題，卻可能漏掉最關鍵的一步：先查明為何大家找不到可信答案。

文件的數量與組織知識的可使用性不是同一回事。若企業有 300 份檔案卻沒有版本、分類和負責人，新人可能比只有 20 份清楚 SOP 時更難完成工作。AI 搜尋可以降低查找門檻，卻不會自然把過時的制度改成正確制度；當來源互相矛盾，它甚至可能把兩個不同版本整理成一個看起來合理的新答案。

先辨識三種問題，才知道該用哪種工具

第一種是固定規則。像是請款要附哪些單據、資料存放在哪個資料夾、報修需要填哪些欄位，只要制度明確且變化不頻繁，最適合先整理成簡潔 SOP 或檢核清單。這類問題真正需要的是「照著做就不會漏步驟」，未必需要新模型或複雜檢索系統。

第二種是情境判斷。客戶臨時調整交付內容、供應商提出特殊條件、新人接到跨部門請求，需要知道過往類似情況如何處理。這些答案可能散落在會議紀錄、合約摘要、案例回顧及團隊 FAQ。單一 SOP 很難涵蓋全部變化，這時具來源索引、可追溯引用的知識查找系統才可能有幫助。

第三種是授權決策。折扣能否核准、特殊個資是否能外傳、某個合約條款能否修改，不是查到舊案例就可以自行決定。這些問題需要當下授權者負責。AI 可指出適用規則與過去案例，卻不能因為能給出流暢答案，就直接獲得公司治理上的批准權。企業若把三種問題混在一起，容易把「查詢變容易」誤認成「決策已自動化」。

SOP 的價值是穩定執行，而不是把經驗寫成一大本手冊

好的 SOP 應讓新同仁在工作發生時立即看懂下一步。內容需要清楚描述觸發條件、負責角色、必填資料、操作步驟、例外情況、完成標準及更新人。若一本手冊需要從第一頁讀到第六十頁才找得到答案，即使內容完整，也不一定符合現場使用方式。

以「客戶要求更改交付日」為例，SOP 不必長篇解釋什麼是專案管理。它應回答：誰先確認新日期、哪個部門計算可行性、什麼程度的延誤要主管核准、正式回覆前需要留下哪些紀錄。新人遇到問題時，能按表判斷工作要移交給誰，而不是記住每位資深同事的個人習慣。

企業常見的另一個問題是 SOP 寫好就放著。制度更新後，檔案仍留著舊版本；負責人轉職，沒有人接手更新；某個例外處理方式變成不成文慣例，文件卻沒有補上。這時增加 AI 搜尋，不會自動解決治理問題。先建立版本、所有者、生效日期和定期檢視，才是讓 SOP 能長期使用的基本功。

AI 知識庫到底是什麼？先把期待調整到正確位置

「AI 知識庫」不是單一產品名稱。有些產品只是讓使用者搜尋現有檔案，有些能把找到的資料摘要成答案，有些則能串接權限與業務系統。企業最常談到的 RAG，中文稱「檢索增強生成」，基本概念是先從指定資料找出相關內容，再讓模型依據這些內容回答。Google Cloud 的 RAG 文件將流程拆為檢索與生成兩個階段。^[1]

這個架構的好處，是讓回答不只依靠模型既有訓練知識，而能使用企業自己提供的文件。但它不是萬無一失。檢索可能找錯、找漏或找出已過期文件；即使找到正確內容，模型也可能忽略限制條件，或把不同來源合成一段不準確結論。資料進入知識庫之前，仍需要權限、版本和品質管理。回答之後，也應讓使用者看到來源與時間，才知道何時需要改向人詢問。

Google Cloud 的評估教學指出，RAG 品質涉及檢索是否正確、模型是否適當使用檢索結果，以及回答本身是否有用且準確。^[2] 換句話說，「AI 有回答」不是驗收。真正要測的是「它有沒有找到可用的規範、是否遵守規範，遇到沒有答案時會不會拒絕亂猜」。

有文件不代表有知識：整理之前先做知識資產盤點

建議企業從新人最近兩週反覆提出的 30 個問題開始，這是便於試行的建議值，不是研究證實的標準樣本量。將每個問題記錄問題原句、當下答案、引用來源、答案擁有者、最後更新日及是否需要主管核准。完成後往往會發現，同樣是「問問題」，有些是找不到文件，有些是文件有矛盾，有些則是根本沒有明確政策。

把問題分成四類即可：有可信答案且固定、答案散落但可整理、來源衝突需決策、完全沒有正式規則。前兩類有機會透過 SOP 或搜尋改善；第三類應由制度所有者確認版本；第四類需要主管先制定規則。沒有規則的問題，任何 AI 工具都只能生成建議，不能替企業創造正式政策。

這項盤點有一個額外好處：能看出哪些知識其實不該全部公開。人資薪酬、客戶合約、採購底價和內部安全事件，都可能需要不同存取權限。建置知識庫時不能只用「公司員工」一個權限群組處理所有文件，應讓模型可引用的內容跟隨原本資料的使用權限。若原系統做不到，應縮小試點範圍，不要先大量上傳後再想辦法限制。

一份可以拿來交接的知識條目，至少有六個欄位

每則知識不妨採用「標題、適用情境、正式答案、引用來源、限制與例外、負責與更新資訊」六欄。標題用新人平常會說的問題，不使用只有資深同仁才知道的縮寫。正式答案盡量先給下一步動作，再提供原因；長篇背景可以放在延伸閱讀，避免每次查詢都被大量文字淹沒。

例如問題是「客戶要求加快交付怎麼辦」，不要只寫「依公司交期規定辦理」。應寫：「先在案件表標記原約定日與新希望日；由專案窗口確認排程與人力；變更可能影響價格時交業務主管核准；取得核准後才能對客確認。」同時附上對應表單、版本與負責部門。若這份規定只適用特定產品，應在條目顯示限制，避免 AI 把它用在所有案件。

如果兩份文件給出不同答案，不要要求 AI 自動挑選「比較新的內容」就算解決。日期較新可能是草案，較舊文件反而仍具正式效力；應比對簽核狀態、生效日期及政策擁有者。最穩妥的方式是在資料庫清楚標示草稿、現行、停用與歷史版本，並避免搜尋系統把非現行文件當成預設權威來源。

什麼時候應該直接先做 SOP？

若團隊反覆問的是十個步驟固定、錯一步就要重做的工作，且公司仍沒有正式標準，先做 SOP 幾乎一定比先建 RAG 更容易驗收。原因不在於 AI 不夠強，而是「正確步驟」尚不存在，無論多強的模型都無法代替組織拍板。這時可使用 AI 協助把資深同仁的說明整理成初稿，再由真正的流程負責人逐項核准。

另一種優先做 SOP 的情境，是工作會直接改動財務、客戶或安全資料。例如付款設定、資料刪除、系統權限核發、對客價格承諾等。即使日後提供 AI 檢索，也需要明確的人工責任與稽核記錄。把程序標準化與讓 AI 容易回答，應是前後相接的兩步，而不是要求系統直接跨越治理缺口。

什麼時候可以開始考慮 RAG？

當可靠文件已存在、問題經常需要跨多份資料才能回答、使用者不容易用傳統搜尋找到答案，且組織能控制文件存取權限時，才值得評估 RAG。尤其是規格查找、維修紀錄、客服 FAQ、長期專案知識與跨版本文件比對，若每次人工搜尋都要花很多時間，檢索輔助可能產生較高價值。

但不必先購買一套大型平台才能驗證。可以選 50 至 100 則授權明確、已核准且非敏感的文件，建立一組真實問題和預期答案，先測現有企業搜尋功能能否解決，再測 AI 檢索是否確實增加價值。若原本使用者只是不知道該去哪個資料夾，改善導覽結構有時比導入新模型更直接，也更容易維護。

評估時要把「回答品質」拆解成三部分：有沒有找到正確文件、有沒有引用正確段落、回答是否遵守原始條件。可以讓不同角色共同設計測試題，包括新人會問的基本題、資深同仁才知道的例外題、故意包含錯誤前提的題目，以及公司沒有規定的題目。最後一種題尤其重要，因為知識庫應該能說「目前沒有已核准答案」，而不是用流暢文字掩蓋未知。

假設企業有 100 題，如何制定驗收方法？

以下是設計方法示例，不代表任何實測結果。假設公司選出 100 道問題，按日常查詢比例分配固定規則、跨文件查找、例外流程與無答案題。建立每題的標準來源和可接受回答要點，再由具有授權的流程負責人確認答案，避免僅用同一個 AI 模型替自己評分。

除了整體正確率，也要記錄「來源正確率」「應拒答時有沒有拒答」「是否越權揭露」「錯誤的嚴重程度」。一個模型在 90 道低風險題答得漂亮，卻在 10 道付款或個資問題中多次違反規則，不能只以 90% 的平均數字宣布上線。權限與高風險例外必須被獨立審核。

測試也應分群。新人可能只需要下一步操作指令，資深同仁則想查到歷史案例和例外原因；客服人員需要可對客說明的標準措辭，主管則需要制度依據和核准權限。若所有人都看到同樣長度與層次的答案，知識庫可能只是將原本厚重手冊換成另一種閱讀負擔。

別忽略「知識維護」這個長期成本

知識系統上線後，真正的成本才開始。制度更新、負責人異動、資料權限調整、商品停用、客戶政策變更，都需要同步到知識來源和索引。企業若只編列一次性建置費，卻沒有安排文件所有者與更新流程，系統往往逐步失去可信度。答案不準之後，同仁回頭問資深同事，雙軌維護又讓工作更複雜。

建議每一類內容指定資料所有者，而不是把所有文件維護丟給資訊部門。IT 可以管理搜尋、身分、權限與系統健康；但價格政策應由業務或財務負責，客戶服務規範由客服主管負責，人才制度由 HR 負責。誰有權決定內容正確，誰就應對更新節奏負責。知識庫只是讓現行制度更容易使用，不是讓制度失去主人。

當公司準備把 AI 知識庫接到其他工具並進行自動操作，更要把查詢與執行分開。讀到「應更新客戶資料」的文件，不表示 AI 已獲權限直接改 CRM。建議先保留唯讀查詢與人工確認；若未來增加寫入能力，再逐項設計可撤回、可追溯與失敗時可停止的機制。

一個月的順序：先盤點問題，再決定技術

第一週請新人與資深同仁各記錄反覆出現的問題，特別是會阻斷工作的問題。第二週確認現有文件的所有者、有效版本和來源，把衝突或無規則的部分交主管決定。第三週用簡潔 SOP、FAQ 與文件索引先解決固定問題；只有跨文件查找仍困難的部分，才選出 AI 知識庫試點。第四週用真實題庫驗收，並決定哪些問題要繼續由人處理。

最後的成果不應只是「我們上線了一個聊天機器人」，而應包含一份明確的問題地圖、一套有效知識來源、一組實際題庫、權限規則、文件更新責任及查詢失敗處理方式。新人可否較少打斷同仁、能否獨立完成合格工作，才是這個專案應繼續追蹤的價值。

讓資深同仁參與，不是把他們當成免費的資料輸入員

當公司宣布「要把老師傅的知識全部放進 AI」，資深同仁可能擔心工作被簡化、經驗被誤用，或日後每個答案都由自己背書。若知識整理只要求他們花大量時間寫文件，卻沒有說明改善目標和回饋方式，實際配合度往往不高。更好的做法是請他們協助辨識真正反覆發生、最容易出錯的情境，讓整理成果直接減少自己的重複答覆。

例如不是請一位資深客服寫出過去十年的全部經驗，而是從近一個月常見的退件紀錄選出十個問題，讓他用現有文件確認標準答案，再由新人試讀。新人看不懂的部分，才補上範例與操作截圖。資深同仁主要負責判斷內容對不對，新人主要負責測試是否看得懂，資訊人員則負責讓文件容易查找。分工清楚，才不會把知識管理變成少數人的額外負擔。

如何處理「制度變更當天」的知識更新？

知識庫最容易出現的重大錯誤之一，是新制度已生效，舊答案卻仍可搜尋。假設公司改變退款條件，主管已正式核准新規則，原本的 FAQ、舊合約範本及過往客服對話仍保存在不同地方。若系統不區分正式規定與歷史案例，就可能對同一天不同客戶給出互相矛盾的回覆。

因此制度變更應有一個明確順序：先核准生效版本、指定資料所有者、標記舊版停用、更新對外與內部索引，最後用測試題確認新規則能被正確找到。若涉及正在執行的案件，還要註明哪些案件適用舊制度、哪些適用新制度，避免用更新日期直接覆蓋契約上已成立的條件。這些治理工作無法單靠語意搜尋完成。

技術人員可在系統中加入文件狀態與權限過濾，培訓主管則應安排一個容易回報錯誤的入口。當新人發現兩份文件互相衝突，不要要求他自行判定，而應讓他將問題送回制度所有者。衡量知識庫的成功，除了回答速度，也要追蹤錯誤答案的通報時間、修復時間和相同錯誤是否重複發生。

管理者可能仍會有的疑問

已經有 ChatGPT 或其他模型，為什麼不能直接把所有文件上傳？ 因為文件是否可以上傳、誰能查到、內容是否仍有效、供應商如何處理資料，都需要先確認。不同產品、方案與組織設定有不同資料政策，不能用單一答案涵蓋。當文件包含個資、客戶資料或商業機密，應先完成政策及存取權限審查。

如果新人不願看 SOP，改成 AI 會改善嗎？ 互動式問答可能降低使用門檻，但如果真正的障礙是主管口頭規則不一致、答案太慢更新，或沒有明確授權人，換介面不會根治。應把查詢紀錄當成改進文件的回饋，不把每次提問都當成員工能力不足。

一定要做向量資料庫嗎？ 不一定。資料量小、分類清楚、搜尋需求簡單時，標題索引、文件搜尋或現有平台功能就可能足夠。只有當跨文檢索、語意查找與來源整合的效益足以支撐額外治理與維護成本時，才值得進一步評估較複雜架構。

知識庫要做跨部門嗎？先處理「不同答案都可能合理」的情境

例如同一個客戶詢問退款，客服需要回答對外政策，財務關心實際入帳和退款進度，法務則關注契約條款。三個部門引用不同資料，不一定代表其中一個錯了；有可能是問題所處的決策階段不同。若知識庫只把所有文件混合索引，就容易將前提不同的規則合成一段貌似完整、實際無法直接採行的答案。

因此跨部門的知識條目應標註適用角色、流程階段、正式政策來源，以及何時應移交另一部門。當答案涉及不同責任領域，系統不應假裝有一個萬用結論，而應提供必要的判斷順序。像是「先確認交易是否符合退款政策，再由財務核對款項狀態」，通常比直接給出「可退款」更符合管理需求。

若系統無法可靠判定問題是規則查詢還是授權申請，應在介面上提供明確選項與人工轉介。與其追求每題都能由 AI 回答，不如確保每題都能進入正確的處理路徑。這也讓企業能把知識庫的成果放在「減少錯誤轉介和反覆詢問」上，而不是只統計回答字數或提問次數。

對 HR 而言，知識改善也可以形成新的學習資料。新人在哪一種問題停留最久、哪一種答案看完仍需要資深同事協助，往往比單純統計課程完訓率更有實務意義。但這些紀錄應用來改善教材與流程，而不是不加脈絡地評量個人能力。不同工作年資與案件難度會影響提問次數，主管應先看內容是否足夠清楚、是否容易取得。

給企業的最後判斷：先修正知識的責任，再修正找知識的方式

一位資深同仁反覆被問問題，有時不是新人不努力，而是公司把制度藏在個人經驗裡。先把可標準化的步驟說清楚，把需要授權的判斷交還給主管，再用適合的工具讓大家取得可信答案，這才是有順序的知識管理。

SOP 讓工作有一致基準，AI 知識庫讓答案比較容易被找到；兩者的交集是可維護、可追溯、可授權的組織知識。若公司仍無法回答「這個答案是誰核准的」，應該先處理制度，而不是先擴大 AI 的回答範圍。

實務延伸

若企業正在規劃新人訓練或跨部門知識交接，可以用「高頻問題清單、SOP 版本表、來源檢核與問答驗收題庫」作為工作坊的實作成果。工具選型不應先行於資料治理；涉及特定架構時，建議由企業資訊與資安人員共同評估。

此外，知識系統的搜尋紀錄本身也需要審慎管理。使用者可能在問題中輸入尚未公開的客戶名稱或個人資料；即使只是為了改善問答品質，也不表示企業可以無限保存所有查詢。記錄目的、保存期間、查詢權限和刪除方式都應明確，並先遵循公司資料處理規範。好的知識服務應讓問題更容易被解決，同時避免為了追蹤問題而建立新的資料風險。

對同一問題如果已有明確正式答案，企業也應避免每個部門自行撰寫一套版本；由一位制度所有者管理來源，通常能減少後續協作的歧義。

參考資料

1. Google Cloud，〈Vertex AI APIs for Building Search and RAG Experiences〉：https://docs.cloud.google.com/generative-ai-app-builder/docs/builder-apis
2. Google Cloud Codelabs，〈Evaluate RAG Systems with Vertex AI〉：https://codelabs.developers.google.com/codelabs/production-ready-ai-with-gc/6-ai-evaluation/evaluate-rag-systems-with-vertex-ai
3. NIST，2024-07-26，〈Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile〉：https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

圖片資訊

封面為 AI 生成的文件管理與知識檢索概念圖，不是真實系統畫面。