企業知識庫．系列講座 - 第06集跨部門失敗模式與系統能力邊界

企業知識庫．系列講座 - 第06集_跨部門失敗模式與系統能力邊界

這裡是智庫引擎，專為企業設計的知識庫。前面五集，我們一個部門一個部門走過來。這一集不談任何單一部門，改談一件更重要的事：什麼情況下，這套系統會做壞。畫面上的副標寫了兩件事：排障指南，還有期望值管理地圖。第二件事其實更關鍵。多數導入之所以失敗，不是系統壞了，是一開始就期待錯了東西。右下角那個標籤說明了這一集是給誰聽的：專案負責人，還有各部門的知識庫窗口。如果您是決策者，這一集會告訴您，該在什麼時候踩煞車。

失敗有兩種長相，畫面左右各一種。左邊叫無聲的失效。這是最麻煩的一種。一般的系統壞掉會跳警告，您馬上知道要修。但這套系統出錯的時候，多半什麼都不會跳。它會用一個很有自信的錯答，或者一句「查無資料」，把底層的問題蓋過去。所以它不是不會壞，是壞了不會叫。右邊叫全能的迷思。有人拿它去算即時的數字、做跨表統計、處理很細的權限。這些它都做不好。因為它的本質只是一層唯讀的知識，不是一台計算機，也不是一套流程系統。中間那句話是這一集的骨幹：導入成功的關鍵，不在於系統絕對不犯錯，而在於您看得懂無聲的錯誤，而且嚴守它的邊界。那錯誤是從哪裡來的？畫面上這條線有三段，每一段都埋著地雷。第一段，資料匯入。這裡的地雷是垃圾進；是資料倒進去了，但沒有整理成可以被查詢的樣子；還有明明沒核可、卻已經在裡面的內容。第二段，清洗與處理。這裡的地雷更隱蔽：內容被無聲地截斷、該設的鑰匙沒設、工程資料裡的關鍵數字不見了。這一段是黑箱，出事您看不到。第三段，查詢與應用。這裡的地雷是人跟系統的認知落差，還有拿過期資料回答的問題。請注意上面那句話：每一處斷點，最後都會變成同一種東西——一個很有自信的錯答。使用者只會看到最後那個錯答。您要修的，卻在前面兩段。接著是三張診斷單，每一張都是症狀、病因、處方。第一張。症狀是答案品質極差。病因是：一次匯入五百份，而且沒有人審查。信心門檻擋得住格式問題，擋不住內容本身就是錯的。處方很簡單，但很多人不肯做：第一批嚴格控制在二十到三十份，全部人工審過。確認品質沒問題，再放大。第二張。症狀是關聯抽取跑完了，卻一個結果都抽不到。病因是來源的知識頁還沒有被核可。處方是先去核可，再重跑一次。這一題很常見，而且完全不是故障。第三張。症狀是什麼都問不到，一律回「查無相關依據」。病因是底層根本沒有整理成可以被查詢的樣子。第一集就講過：這一步沒做，之後問什麼都是查無依據。處方是到系統健康檢查那一頁，看涵蓋率。再往下一層，這一頁是三種比較難發現的故障。第一種，嚴重錯誤：排在後面的內容全部查不到。原因是一個盒子塞太多，清洗的時候被截斷了。怎麼查？比對清洗前後的長度比例，正常大概是零點五到一之間。比例太低，就是尾巴被吃掉了。解法是上傳前先拆檔、分盒，重跑一次。第二種，降級模式：內容只是被接起來，沒有分類、也沒有摘要。原因是連到人工智慧的那把鑰匙沒設定。沒有鑰匙，它只能做最陽春的合併。補上鑰匙就好。第三種，資料遺失，這一種最貴：關鍵尺寸跟公差在清洗之後消失了。原因是遮罩的提示詞寫得太廣，沒有把型號跟尺寸排除掉。第一集跟第二集都警告過這件事。解法是提示詞裡明白寫上「不要遮型號、尺寸、公差」，然後拿真實的樣本試跑一次，親眼確認數字還在。這一頁我認為是整集最有價值的一頁。左邊是人以為的，中間是實際發生的，右邊是解法。第一列。人以為多選分類是「而且」，選越多範圍越小。實際上它是「或者」，選越多範圍反而越大。第一集講過這件事，這裡是它的後果。解法是改用「限定知識來源」去硬篩，分類只留一個維度。第二列。人以為系統分得出不同盒子裡的「設計規範」。實際上十個盒子都叫同樣的名字，它分不出來，還會很有自信地答錯型號——把三千的規範拿去回答五千。解法是嚴格遵守命名規範。第三列。人以為它會照著公司既有的分類去貼標籤。實際上它會自己發明一個不存在的分類，然後寫回紀錄裡。解法是在提示詞裡把可用的詞列出來，嚴格禁止自創。第四列，最容易中招。人以為規範改版之後系統會自動生效。實際上，過時是靜默的——在重新處理過之前，它會一直回答舊版。解法是把資料一致性監控起來。素材一改，下游一定要重跑。講完故障，講邊界。畫面上這三個同心圓，請您記住它們的顏色。最外面那圈綠色的，叫戰術繞道。這一圈的限制都可以繞過去，靠的是流程調整跟人工規劃，不用等任何人開發。下一頁就是這一圈的具體做法。中間那圈黃色的，叫開發地平線。這一圈要改底層的程式，所以一定要先評估划不划得來。它做得到，但要花錢跟時間。最裡面那圈紅色的，叫絕對禁區。這一圈是本質上就不該用這套系統做的事。往這裡硬闖，花再多錢也是白花。左邊那句話請您收下：認識邊界，是避免對系統失望的唯一途徑。越往核心走，硬解的代價越高。多數失望，都來自把紅圈當成綠圈。這一頁是綠圈，五個限制，五條繞行的路。都不用等開發。第一，它讀不懂設計圖檔。繞法是人工把關鍵尺寸做成標註截圖，改走圖片那條路。第四集用過這一招。第二，它不會自動鎖定型號或客戶。繞法是放棄自動判定，直接用「限定知識來源」硬篩。第三，它做不到多維度交叉篩選。繞法是把主要的那個維度寫進盒子標題，分類只留一個維度。第一集的命名公式，就是為了這件事存在的。第四，外文文件它不一定讀得準。繞法是先萃取出來，讓人確認讀不讀得通，整理成中文版再匯入。第五，按批號或工單號查詢。繞法很土但很有效：把編號直接寫進素材的標題跟內文裡。您看，這五條沒有一條需要工程師。全部都是流程的事。這一頁是黃圈，也就是要花錢開發的那一圈。畫面上六個項目，已經排好順序了。第一順位，讓分類可以取交集。第二，讓文字段落自動帶上章節標題。第三跟第四是中文斷詞相關的優化。第五，把找到的結果重新排一次順序。第六，多維標籤的資料模型。下面那個框，是給老闆的：建議照順序做。先完成第一項，然後實際量測第二項帶來多少增益，再決定要不要往下。最後那句話是紅字級的提醒：絕對不要一開始就跳到第六項。多維標籤聽起來最完整、最漂亮，簡報上也最好看。但它會讓整個系統過度複雜，而且效益完全未知。先做第一項。它便宜，而且立刻有感。這一頁是紅圈，六件事，一件都不要嘗試。第一，即時數據查詢，庫存、當期報價、稼動率。原因是知識庫只是一張清洗整理過的照片，照片本質上就會過期。第二，跨表統計跟排名。它專心做的是文字語意的搜尋，它沒有算數的能力。第三，交易型的操作，下單、派工、簽核。它是唯讀的一層，沒有留下誰在什麼時候做了什麼的完整紀錄。這種事一定要交給有稽核能力的系統。第四，具法律效力的逐字引用。它的產出是重組過的知識，不是原文。它只能幫您導航到原始檔在哪裡。第五，單筆或單一欄位的權限限制。它控管的最小單位是團隊標籤。後半句才是重點：需要單獨控管的機密，根本就不該匯進來。第六，數學計算跟公差疊加。語言模型的算術不可靠。它會給您一個看起來很像的數字——這比算不出來更危險。上一頁講了六個不能做。那那些需求該去哪裡？這一頁給答案。中間是知識庫。它的核心能力只有三項：模糊語意的搜尋、把零散知識重組起來、還有工程規範的指引。如果需求是即時數據跟交易，往上，交給交易系統、現場監控系統或工作流系統。如果需求是跨表統計跟數值分析，往右，交給報表工具。如果需求是精準的影像量測與檢測，往下，交給光學檢測系統。如果需求是對外承諾跟規格保證，往左，交給正式的簽核流程。這一條特別重要——承諾要有人簽名負責，不是系統說了算。這張圖建議印出來貼在牆上。以後有人抱怨「這個它為什麼做不到」，先看一眼這張圖：多數時候不是它做不到，是需求走錯了門。最後給您一張自評表，四題。第一題，資料品質：有沒有訂出一份寫得出來的作業辦法，規定第一批只做二十到三十份，而且全部人工檢驗？第二題，查詢邏輯：盒子的命名規範統一了嗎？使用者知不知道怎麼用「限定知識來源」去硬篩？第三題，系統邊界：那些即時的、要算數的需求，您清楚知道該轉給哪一套系統嗎？第四題，認知對齊：整個團隊是不是都清楚——它產出的是重組後的參考指引，不是有法律效力的逐字稿？這四題如果有任何一題答不出來，先不要擴大導入範圍。先把那一題補起來。這一集只有一句話要留給您，就在畫面正中間。系統的強大，源自於我們對其邊界的敬畏。底下那行講得更白：停止追求全能的迷思，用正確的工具，解決正確的問題。一套什麼都說可以的系統，其實什麼都不能信。願意講清楚自己做不到什麼的系統，您才敢把公司的決策交給它。下一集是最後一集。我們把七集的東西收攏成一張時間表，講導入的順序，還有第一個月該達成的里程碑。

C# .NET Blazor MAUI Xamarin Research

2026年8月1日星期六