第一次使用大型語言模型時，很容易產生一種錯覺：它既然可以回答程式、歷史、行銷甚至商業策略，是不是也應該能回答公司內部的問題？真正開始拿它處理工作後，落差就會出現。它知道什麼是 conversion rate，卻不知道你公司這個指標的正式定義；它知道怎麼分析專案風險，卻不知道昨天 Trello 上剛更新的狀態。

這不是模型「不夠聰明」，而是知識來源本來就不同。

通用知識與企業知識之間有一道牆

大型語言模型主要依靠訓練資料與當下提供的上下文回答問題，但企業內部有大量資訊從未出現在公開訓練資料中，例如內部 SOP、專案文件、銷售明細、會議記錄與權限受控的知識庫。即使某些資訊曾經存在於模型可接觸的世界裡，也不代表它掌握的是最新版本。

因此企業常見的知識落差至少有三種。第一種是私有資料，模型根本沒有看過；第二種是即時資料，例如今天庫存、昨天銷售或最新專案狀態；第三種是公司自己的定義與脈絡，同一個詞在不同組織可能代表完全不同的事情。

最危險的不是「不知道」，而是「看起來像知道」

如果模型直接說「我不知道」，問題反而容易處理。真正麻煩的是語言模型擅長生成流暢內容，所以在缺乏企業資料時，仍可能根據通用知識補出一個合理答案。對一般聊天來說這可能只是誤差，但如果內容涉及營收、政策、客戶或決策依據，流暢卻錯誤的回答會比沒有回答更危險。

企業 AI 因此需要把「答案是否有根據」放在「答案是否好讀」之前。這也是為什麼後面會反覆出現來源、驗證與重新查詢等設計。

外部知識取得有兩條主要路徑

如果答案存在於文件中，我們可以先檢索相關內容，再交給模型整理，這就是後面會介紹的檢索增強生成（RAG）。如果答案存在於即時系統或結構化資料裡，就應該透過工具使用（Tool Use）直接查詢 API、試算表或資料庫。

這兩條路徑的共同點是：不要期待模型記得企業事實，而是在需要時把可信資料帶進來。 模型的角色更像理解問題與組織答案，而不是企業資料庫本身。

Data Machi 的選擇

Data Machi 不把所有內容都硬塞進 Prompt，而是依照資料性質分工。PDF 與規範文件交給 RAG，Google Sheets 的數字交給資料工具，專案進度交給對應 API。當問題跨越多種資料，Coordinator 再決定要查哪些來源。

這個設計看起來比單一 Prompt 麻煩，但它換來的是可更新、可追溯與可驗證。當原始資料更新時，系統重新查詢即可取得新結果，而不是重新修改一大段 Prompt。

不要問「模型知不知道公司的事情」，而要問「系統在回答前，能不能取得正確而且最新的公司資料」。

下一篇，我們會繼續處理另一個常見誤區：既然 AI 可以理解自然語言，是不是把所有規則寫進 System Prompt，就能得到一套可靠的工作流程？

我們下集見囉！