企業知識庫 × AI:新人訓練與客服的共同解

每家公司都有同一個場景:新人問「這個流程怎麼跑?」,老鳥回「雲端硬碟裡有文件」,新人打開雲端硬碟,看到「SOP_final_v3(真正最終版)(0412更新).docx」躺在八層資料夾深處,旁邊還有三個內容互相矛盾的兄弟版本。於是新人放棄搜尋,直接再問一次老鳥——公司最貴的知識傳遞方式。

「知識庫 + AI 檢索」之所以是近年最務實的 AI 導入題目,因為它一次解掉兩個長期痛處:新人訓練(反覆回答一樣的問題)與客服支援(答案存在但找得慢)。這兩個場景吃的是同一套地基,做一次、兩邊受益。這篇講我們替自己與客戶走過的建置路徑。

先講殘酷的事實:AI 救不了爛文件

很多老闆期待 AI 像魔法一樣,把散落各處的混亂文件「自動整理好」。不會。AI 檢索(技術上就是 RAG,原理見RAG 是什麼)的品質上限,就是你文件的品質上限。三個版本互相矛盾的 SOP,AI 只會把矛盾更有效率地端到使用者面前。

所以建置的第一階段永遠是知識盤點與收斂,而且這步沒有捷徑:

指定唯一真相來源:每個主題只留一份現行文件,舊版歸檔不刪除但明確標示過期。
補上「部落知識」:最有價值的知識往往不在文件裡,在資深同事腦中。用訪談把「遇到 X 情況要先問誰、為什麼」這類判斷寫下來,這部分的價值常常超過既有文件總和。
建立文件的最低結構:每份文件標明適用對象、生效日期、負責人。不用完美,但要可維護。

我們的實務經驗:這一階段的工時常常佔整個專案一半以上,而且必須由懂業務的人主導,外部團隊只能陪跑。想省掉這步的專案,我們會直接勸退。

文件收斂後,才進入技術建置:文件切段、建立向量索引、串接 LLM 問答介面。這部分是成熟技術,真正需要判斷的是三個設計決策:

權限要跟著檢索走。薪資規章全員可問,客戶合約只有業務主管能問。檢索層必須尊重原本的文件權限,而不是把全公司文件煮成一鍋大雜燴。這是企業知識庫與玩具 demo 的最大差別。

答案必須附出處。每個回答連回原始文件段落。一來使用者可以查證,二來發現答錯時,你修的是文件而不是系統——這讓知識庫進入「越用越準」的正循環。

要有「答不出來」的出口。檢索不到依據時,系統要老實說找不到,並引導到負責人,而不是硬編。同時把這些「沒人寫過答案的問題」記錄下來——它就是你下一批該補的文件清單,比任何顧問的盤點都準。

知識庫專案的真正產出不是那個問答機器人,而是一套「知識有人負責、過期會被更新」的公司習慣。機器人只是讓這個習慣值得維持的理由。

新人側:與其丟一疊文件叫新人自己讀,不如給他一個可以隨時發問的入口。我們看到最有感的變化是提問品質改變了——新人把基礎問題丟給系統,留給導師的都是真正需要經驗判斷的問題。

客服側:先從「輔助客服人員」開始,值班同事查詢用,而不是直接面對客戶。等答案品質經過內部驗證、錯誤率有數據了,再評估開放部分場景直接對客。順序反過來,一次公開出錯就會賠掉整個專案的信任。

挑一個文件相對齊全、提問高度重複的部門(通常是客服或人資),用四到六週做第一輪:收斂文件、建檢索、內部試用、根據真實提問補洞。跑順了再橫向擴到其他部門。如果你想先評估自家的「文件體質」適不適合,歡迎聯絡我們,這個判斷不需要任何開發費用就能給你。