情境不會躲在資料庫裏

情境不會躲在你的資料庫裏。

資料庫可能包含檔案、電郵、筆記、試算表、合約、發票、圖紙或決策紀錄。它甚至可能全部都有。

但這不代表它擁有情境。

一條紀錄告訴你寫下了甚麼。它往往不會告訴你為甚麼那件事重要、誰把建議的語氣放軟、大家心照的例外是甚麼、客戶真正想表達甚麼、哪項假設帶有政治性，或團隊為甚麼沒有採用那個看似顯而易見的先例。

這就是把 AI 情境當成儲存問題的盲點。

搜尋有用。檢索有用。更好的索引亦有用。但專業情境不是藏在資料夾內等待被抽取的物質。它是紀錄周圍的意義。

完整的檔案庫仍然可以出錯

想像一間公司有一個完整無缺的檔案庫。

每份文件都可搜尋。每個案件檔案都已建立索引。每封電郵都可取得。每段筆記都已轉錄。每次客戶通話都有摘要。每張圖紙、發票、簡報、協議、政策和試算表都可檢索。

這聽起來很強。

它仍然可以給出錯答案。

不是因為檔案庫空無一物，而是因為系統對紀錄的含意太有信心。

舊條款可能仍然存在，但合夥人可能知道它不適用於這個客戶。試算表可能顯示某個數字，但財務負責人可能知道背後的假設只在去年預算中被接受。設計簡報可能寫着「大膽」，但工作室可能知道這個客戶用這個字，是指「不要那麼千篇一律」，而不是要把設計做得更張揚。

這些不是罕見的邊緣情況，而是工作本身。

隱性知識不是缺陷

Michael Polanyi 有一句著名說法，大意是「我們知道的，比我們能說出的更多」（Polanyi^{1Michael Polanyi, The Tacit Dimension}）。這常常被當成知識管理問題，好像只是組織沒有留下足夠文件。

有時這是真的。有些東西本來應該寫下來。

但隱性知識不只是懶惰或文件不齊。它是專業工作的一部分。人會學到重複出現的模式、過往歷史、客戶偏好、專業標準和本地意義，這些都很難整齊地壓進系統的一個欄位。

Nonaka 關於組織知識的研究也有類似觀點：組織透過隱性和顯性知識之間的流動創造知識，而不是假設所有重要東西都已經寫清楚（Nonaka）。

這對 AI 很重要，因為檢索到的文件是明確紀錄，圍繞文件形成的判斷卻未必如此。

紀錄是工作的痕跡

文件不是工作本身，而是工作留下的痕跡。

電郵可能記錄了決定，但沒有記錄決定周圍的壓力。合約可能記錄了最終立場，但沒有記錄內部辯論。項目筆記可能捕捉了行動，但沒有捕捉它為甚麼重要。圖紙可能顯示當前設計，但沒有顯示形成它的被否決路線。

Brown 和 Duguid 對實踐社群的研究在這裏很有幫助。他們指出，學習和知識存在於實際工作中，不只存在於對工作的正式描述內（Brown and Duguid^{4Brown and Duguid, "Organizational Learning and Communities-of-Practice"}）。人是透過參與慣常做法、使用共同語言、了解捷徑、處理例外和掌握標準，才真正理解工作。

所以新人可以讀完整個檔案，仍然未真正明白那宗案件。

這亦解釋了為甚麼 AI 系統即使檢索到正確文件，仍然可能理解錯重點。

檢索可以做到甚麼

檢索增強生成仍然重要。

基本想法是合理的：不要要求模型只靠一般訓練資料回答，而是先找出相關來源，再根據這些來源產生答案。Lewis 和同事最初對 RAG 的研究，令這種做法成為知識密集型 AI 系統的重要基礎（Lewis et al.^{5Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"}）。

對專業工作來說，來源依據不是可有可無。人需要知道答案從哪裏來，並能夠檢視證據、質疑它、更新它，以及決定它是否足夠支持判斷。

檢索可以幫助：

• 找出相關紀錄；
• 減少對記憶的依賴；
• 展示說法背後的來源；
• 比較不同版本；
• 揭示欠缺的材料；
• 準備初步結果，交由人審閱。

這是真正收益。

但檢索不會自動解決情境問題。

檢索會漏掉甚麼

檢索至少可以在五方面遺漏情境。

第一，它可能因為語言相似但情況不同，而找出錯誤來源。

第二，它可能找出一個舊來源，卻不知道實際做法已經改變。

第三，它可能找出正式紀錄，卻漏掉非正式例外。

第四，它可能找到幾份互相矛盾的紀錄，然後把衝突抹平。

第五，它可能把未有紀錄當成不存在證據。如果檔案沒有記下原因，系統可能會當作根本沒有原因。

近期關於企業 RAG 基準的研究也指向這一點。企業內部知識往往需要跨文件推理、處理衝突，以及辨認欠缺的資料，而不只是檢索一段相關文字（EnterpriseRAG-Bench^{6EnterpriseRAG-Bench}）。

更難的問題不是「我們能否找到文件？」，而是「我們對這份文件應該有多大信心？」

更好的問題

不要問「我們有沒有資料？」，而應該問：

• 這個來源是否最新？
• 它是否具權威性？
• 它是否完整？
• 是否有已知例外？
• 誰了解事情的來龍去脈？
• 這份東西寫成之後，有甚麼改變？
• 甚麼會令它造成誤導？
• 審閱者應該檢查甚麼？

這些問題沒有「連接所有資料」那麼令人興奮，但它們更接近專業判斷的實際運作方式。

目標不是令 AI 無所不知，而是讓人能夠檢視知識的狀態。

情境由人際關係塑造

專業情境往往存在於人與人之間。

合夥人知道客戶為甚麼對時機敏感。經理知道哪個數字大家都不相信。建築師知道哪個設計動作，因為某些從未寫進簡報的原因而被否決。高級律師知道哪項條款看似標準，卻會改變商業立場。

這不代表情境應該困在私人記憶內。私人記憶很脆弱。人會離開、忘記、忙起來，或假設其他人都知道自己所知的事。

但答案不是假裝情境已經存在資料庫內。

答案是建立一套系統，讓人可以把意義連回紀錄：

• 這個來源已經過時；
• 這是目前適用的先例；
• 這個客戶偏好這條路線；
• 這項假設需要檢查；
• 這段筆記解釋了為甚麼沒有採用看似顯而易見的做法；
• 沒有先向這個人了解，答案就不完整。

資料庫正是這樣變得更有用。不是因為它聲稱包含所有情境，而是因為它讓缺口變得可見。

簡單測試

一個使用內部知識的 AI 系統，可以用一個簡單方法測試：

它能否說出自己不知道甚麼？

它能否展示哪些來源支持答案？

它能否分開紀錄和詮釋？

它能否提醒使用者來源可能已經過時？

它能否展示互相衝突的證據，而不是把衝突藏起來？

它能否指出行動前需要找哪個人，或完成哪個審閱步驟？

如果不能，系統對搜尋和草擬仍可能有用。但不應被誤認為已經理解情境。

檔案可能告訴你發生了甚麼。

但通常只有身處其中的團隊，才知道它為甚麼重要。

紀錄不會自動提供的四樣東西

「數據」一詞常把四個層次混在一起。

紀錄是被寫下的內容：電郵、欄位、文件、筆記或交易。它只證明某些事情曾被捕捉。

目前狀態是現在甚麼為真的描述，可能需要調和多份紀錄、檢查時效，並辨認哪個事件取代另一個。

脈絡解釋目前狀態為何在這裏重要，包括關係、意圖、義務、時機、優先次序和依賴。

判斷則是下一步應做甚麼的決定。它使用紀錄和脈絡，並承擔後果。

資料庫可以支援四者，卻不會自動把第一層變成其餘三層。

時效是一種關係，不只是一個時間戳

最新紀錄不一定最具權威。近期非正式訊息未必能推翻已簽署指示；欄位可能在決定後更新，但更新者沒有決定權；政策發布日期最新，卻未必適用於獲豁免的舊個案。

所以，時效需要把時間、來源、權威和目的連起來。系統不只要知道何時改變，還要知道該改變可以代表甚麼。

意圖與缺席的理由

紀錄偏向保存發生了甚麼，而不是另一條路徑為何被拒絕。團隊可能因對話、敏感因素或預期依賴而不用最明顯的方法。如果理由沒有保存，檢索會反覆找回已被拒絕的選項，並把它當成新見解。

答案不是記錄所有對話，而是辨認日後仍重要的決定理由，簡潔保存曾考慮甚麼、選擇甚麼、哪項假設主導，以及何時應重新檢視。

檢索必須承認衝突和缺漏

企業檢索之所以困難，正因來源會衝突、資料會缺漏，答案亦依賴跨文件一致性。EnterpriseRAG-Bench 就以這些條件評估系統，而非假設資料集乾淨（EnterpriseRAG-Bench^{6EnterpriseRAG-Bench}）。

有用的系統應能指出：來源互相矛盾、較舊紀錄反而更具權威、決定理由缺席、必須諮詢哪個角色，或現有證據不足以支持行動。這不是智能失敗，而是系統理解檢索與機構判斷之間的邊界。

由儲存走向營運智能

目標不是完美檔案庫，而是一種在工作發生時，令適當證據、關係、權限和不確定性可見的營運安排。這把脈絡連接到營運智能。

當機構保存重要選擇的理由，或把承諾連接負責人和條件，未來工作便可從更好的狀態開始。這與累積更多文件不同，而是在建立一個能記住自身承諾的系統。

資料來源

1. Michael Polanyi, The Tacit Dimension
2. Ikujiro Nonaka, "The Knowledge-Creating Company"
3. Nonaka, Toyama, and Konno, "SECI, Ba and Leadership"
4. Brown and Duguid, "Organizational Learning and Communities-of-Practice"
5. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"
6. EnterpriseRAG-Bench