*圖 1 通用模型與企業私有知識之間的資訊邊界*
第一次使用大型語言模型時，很容易產生一種錯覺：它既然可以回答程式、歷史、行銷甚至商業策略，是不是也應該能回答公司內部的問題？真正開始拿它處理工作後，落差就會出現。它知道什麼是 conversion rate，卻不知道你公司這個指標的正式定義；它知道怎麼分析專案風險，卻不知道昨天 Trello 上剛更新的狀態。 這不是模型「不夠聰明」，而是知識來源本來就不同。 ## 通用知識與企業知識之間有一道牆 大型語言模型主要依靠訓練資料與當下提供的上下文回答問題，但企業內部有大量資訊從未出現在公開訓練資料中，例如內部 SOP、專案文件、銷售明細、會議記錄與權限受控的知識庫。即使某些資訊曾經存在於模型可接觸的世界裡，也不代表它掌握的是最新版本。 因此企業常見的知識落差至少有三種。第一種是**私有資料**，模型根本沒有看過；第二種是**即時資料**，例如今天庫存、昨天銷售或最新專案狀態；第三種是**公司自己的定義與脈絡**，同一個詞在不同組織可能代表完全不同的事情。 ## 最危險的不是「不知道」，而是「看起來像知道」 如果模型直接說「我不知道」，問題反而容易處理。真正麻煩的是語言模型擅長生成流暢內容，所以在缺乏企業資料時，仍可能根據通用知識補出一個合理答案。對一般聊天來說這可能只是誤差，但如果內容涉及營收、政策、客戶或決策依據，流暢卻錯誤的回答會比沒有回答更危險。 企業 AI 因此需要把「答案是否有根據」放在「答案是否好讀」之前。這也是為什麼後面會反覆出現來源、驗證與重新查詢等設計。 ## 外部知識取得有兩條主要路徑 如果答案存在於文件中，我們可以先檢索相關內容，再交給模型整理，這就是後面會介紹的檢索增強生成（RAG）。如果答案存在於即時系統或結構化資料裡，就應該透過工具使用（Tool Use）直接查詢 API、試算表或資料庫。 這兩條路徑的共同點是：**不要期待模型記得企業事實，而是在需要時把可信資料帶進來。** 模型的角色更像理解問題與組織答案，而不是企業資料庫本身。 ## Data Machi 的選擇 Data Machi 不把所有內容都硬塞進 Prompt，而是依照資料性質分工。PDF 與規範文件交給 RAG，Google Sheets 的數字交給資料工具，專案進度交給對應 API。當問題跨越多種資料，Coordinator 再決定要查哪些來源。 這個設計看起來比單一 Prompt 麻煩，但它換來的是可更新、可追溯與可驗證。當原始資料更新時，系統重新查詢即可取得新結果，而不是重新修改一大段 Prompt。