大型語言模型讀過海量的公開資料，可以流暢地解釋量子力學、翻譯多國語言，也能撰寫商業計畫書。但當你問它：

「我們 Q3 的需求工單有幾張來自美國市場？」

或是：

「內部 Request Worksheet 的 Priority 欄位是怎麼定義的？」

它很可能給出一個錯誤、空洞，或無法驗證的回答，而且說得非常有自信。理解這個落差的成因，是設計可信賴企業 AI 系統的第一步。

三種知識落差

1. 資料不可見（Invisibility）

你的 Google Sheets、Confluence 文件、Trello 看板與內部 PDF，通常不會出現在公開的模型訓練資料中。對語言模型而言，這些企業內部資料根本不存在。

模型只能根據公開資料建立通用知識，因此無法天然知道公司今年收到多少張需求工單、哪一個市場的需求最多、某個專案目前由誰負責、昨天的會議做了哪些決定，或內部欄位與縮寫如何定義。

這不是模型拒絕回答，也不是它不夠聰明，而是它從一開始就沒有接觸過這些資料。

2. 資料會更新（Staleness）

即使模型曾經在訓練階段看過某個組織的公開資料，今天的數字、進度、負責人與決策也可能已經完全不同。大型語言模型的知識通常有訓練截止時間，但企業的實際狀況每天都在改變。

例如，昨天可能新增了十張工單，專案負責人今天已經更換，某項政策本週才更新，最新的營運數字尚未公開，或專案狀態已經從「進行中」改為「延遲」。

因此，模型曾經知道某件事，不代表它現在仍然知道正確答案。企業需要的是即時事實，而不是模型對過去資料的記憶。

3. 企業語言高度在地化（Localization）

每間公司都有自己的縮寫、欄位名稱與內部術語。例如，「RW」在某間公司可能代表 Request Worksheet，在另一間公司卻可能代表 Remote Work、Risk Weight、Rework 或 Regional Warehouse。

同一個詞語，在不同企業、團隊與系統中，可能代表完全不同的業務概念。這種高度情境化的語言，模型幾乎不可能只靠一般語言知識正確判斷。

即使模型成功找到一份文件，如果它不了解文件中的內部術語，也可能錯誤解讀內容。

這三個問題通常會同時發生：

1. 資料沒有出現在模型的訓練資料中
2. 即使曾經出現，內容也可能已經過期
3. 即使內容仍然有效，模型也可能誤解企業內部術語

這不是單純的模型能力問題，而是知識邊界的本質限制。

模型不是企業資料庫

很多人的第一反應是：

「把資料貼到 Prompt 裡不就好了？」

這個方法在特定情境下確實有效。例如，當資料量只有幾百字、內容相對固定、只有單一資訊來源，而且問題不需要跨文件推理時，直接將內容放進 Prompt 是一種快速且實用的做法。將一段會議紀錄貼給模型，再請它整理重點，就是典型的適用情境。

Prompt 補充法適合的情境

• 資料量很小，例如只有幾百字
• 內容相對固定，不常更新
• 只有一個資訊來源
• 問題簡單，不需要跨文件推理
• 只需要處理一次性的任務
• 使用者已經知道哪些資料需要放入 Prompt

然而，當資料量擴大到數千筆工單或數十份文件，內容每天持續更新，答案分散在不同系統，或需要即時查詢、統計與比對時，單純將資料貼進 Prompt 就很難維持。

Prompt 補充法容易失敗的情境

• 資料量龐大，例如數千筆工單或數十份文件
• 資料持續更新，每天都有新內容
• 答案分散在多個系統中
• 需要即時查詢、統計或比對結果
• 使用者不知道答案藏在哪一份文件裡
• 每次提問都需要重新整理資料
• 資料涉及權限或敏感資訊

企業的實際情況通常更接近第二種。這時候，正確的解法不是把 Prompt 寫得更長，而是讓 AI 在回答前主動查詢真實的資料來源。

Data Machi 的應對方式

Data Machi 針對上述三種知識落差，採取三項明確的設計原則。

原則一：限制明確的業務範圍

系統應被限制在事先定義的業務範圍內。當問題涉及數字、日期、專案進度、負責人、工單狀態或企業內部定義時，回答必須來自工具查詢或知識來源，不允許模型只依靠語言直覺生成答案。

這個原則的重點不是限制模型能力，而是避免模型在缺乏資料時自行填補空白。

原則二：即時查詢，不依賴舊記憶

每次使用者提出問題時，系統都應重新查詢最新資料，而不是依賴對話歷史中的舊數字。

例如，使用者昨天問過：

「目前有多少張日本市場的需求工單？」

今天再次提問時，系統不能直接重複昨天的答案，而是應重新讀取資料來源。只有這樣，回答才會隨著企業資料更新而同步更新。

原則三：查不到就誠實說明

當系統無法從工具結果中找到答案時，必須明確說明找不到對應資料、哪些來源沒有查到結果、目前可能缺少哪些資訊，以及使用者接下來可以怎麼處理。

例如：

目前在已連接的 Google Sheets 與 Confluence 文件中，找不到 Priority 欄位的正式定義。建議確認是否存在其他版本的 Request Worksheet 說明文件。

這樣的回答看起來不如直接給答案流暢，卻更值得信任。

最危險的 AI 行為：流暢地說錯

企業場景中，最危險的 AI 行為不是「說不知道」，而是：

用流暢、自信的語氣說出錯誤資訊。

當模型不知道答案，卻仍然產生一個看似合理的回應時，通常稱為「幻覺（Hallucination）」。在一般對話中，幻覺可能只會造成困惑；但在企業決策情境中，一個錯誤的數字可能導致錯估市場需求、錯誤分配資源、誤判專案進度、對錯誤的團隊追責，甚至將不存在的規則當成正式政策。

幻覺之所以危險，是因為它看起來和正確答案沒有明顯差別。模型通常不會在錯誤答案旁邊附上警告，也不會主動告訴你：

「我剛才其實是在猜。」

它在正確與錯誤時，可能使用完全相同的語氣。

如何測試企業 AI 是否值得信任？

你可以刻意問一個系統理論上不應該知道答案的問題，例如：

「上週三的內部會議紀錄摘要是什麼？」

接著觀察系統如何回應。如果它回答：

我目前沒有找到上週三的會議紀錄，因此無法產生可靠摘要。

這是一個好兆頭。相反地，如果它開始自行描述會議內容，或產生看似合理的決策摘要，就代表這套系統缺乏必要的知識邊界與查核機制。

初學者版比喻

想像你剛雇用了一位學歷非常優秀、知識淵博的新員工。他第一天報到，對世界上的通用知識瞭若指掌，也能流暢地討論不同產業的發展趨勢。

但他不知道公司的共用硬碟在哪裡，不知道內部縮寫「RW」代表什麼，也不知道昨天的產品會議做了哪些決定。他不了解客戶 A 和業務 B 之間的合作歷史，不知道最新一版的工單分類規則，更不知道目前哪個專案已經延遲。

這位新員工不是不聰明，而是還沒有企業脈絡。

模型能力很強，不代表它天然擁有企業知識。

你需要提供它公司文件的存取方式、查詢內部系統的工具、業務術語的定義、資料使用規則，以及回答前的查核流程。有了這些能力，它才可能真正開始工作。

技術補充：為什麼需要 RAG？

前面提到的問題，正是 RAG 想要解決的核心問題。

RAG 的全名是 Retrieval-Augmented Generation，中文通常翻譯為「檢索增強生成」。它的核心邏輯可以簡化成：

不要把所有知識塞進模型
→ 在需要時查詢相關資料
→ 將查詢結果提供給模型
→ 根據真實資料產生回答

這就像要求員工在回答問題前先查閱公司手冊，而不是只靠自己的記憶作答。

一個基本的 RAG 流程通常包含以下步驟：

1. 將企業文件整理成可查詢的知識庫
2. 根據使用者問題搜尋相關內容
3. 取回最可能有幫助的文件片段
4. 將文件片段與問題一起交給語言模型
5. 要求模型根據取回的內容產生回答

Data Machi 的設計也是基於這個原則，讓涉及企業資料的回答能有真實來源支撐。

RAG 不是萬能解法

RAG 可以協助解決資料不可見、模型知識過時、文件數量過多，以及使用者不知道答案在哪裡等問題，但它本身並不能自動解決所有知識理解上的困難。

特別是「企業語言在地化」仍然需要額外處理。

假設 Confluence 文件中寫著：

所有 P1 RW 必須於 SLA 前完成 BA review。

即使 RAG 成功取回這段內容，模型仍然需要知道 P1 是哪一種優先級、RW 代表什麼、SLA 的期限如何計算、BA 指的是 Business Analyst 還是其他角色，以及 Review 完成的判定標準是什麼。

如果知識庫中沒有這些術語的定義，模型仍然可能錯誤理解內容。因此，企業知識系統除了要能找回資料，還需要建立企業詞彙表、補充欄位與縮寫定義、保存文件版本與有效日期、設定不同來源的優先級、說明資料之間的關聯，並定義模型應如何解讀取回的內容。

這也是為什麼 Day 02 提到的 Understand 步驟非常重要：系統不能只是取回資料，還必須知道如何正確解讀資料。

本日重點

今天只需要記住一件事：

模型的通用知識，不能取代企業的即時事實來源。

大型語言模型可以知道許多公開世界的知識，但它不會天然知道公司的最新數字、內部文件內容、專案目前進度、特定欄位定義、企業內部術語，以及尚未公開的決策。

因此，一套可信賴的企業 AI 系統必須具備真實資料來源、即時查詢能力、清楚的知識邊界、企業術語定義，以及查不到時誠實說明的機制。

下一篇，我們會說明為什麼 Prompt 寫得再完整，也不等於建立了一套可靠的工作流程，以及「告訴 AI 怎麼做」和「讓系統保證它真的這樣做」之間的本質差異。