知識就是資料嗎？
系列：程式人的哲學思辨 #02/11 | 閱讀時間：25-30分鐘 | 概念：知識論（Epistemology）— 資料、資訊、知識與智慧
作者：Wina @ Code & Cogito
那天資料庫教我的事
某天下午，我接手了一個「簡單」的任務：從資料庫裡撈出上個月的銷售趨勢。
資料都在。幾百萬筆交易記錄，時間戳精確到毫秒，每一筆都有商品ID、金額、使用者標記。我寫了 query，跑了聚合，畫了圖表。折線上去了，看起來不錯。
我把報告丟給產品經理。她看了三秒，問了一個我回答不了的問題：「這是因為我們做了什麼對的事情，還是只是季節因素？」
我愣住了。
我有資料。我有數字。我甚至有趨勢圖。但我沒有理解。我知道「發生了什麼」，卻不知道「為什麼」。我可以告訴你每一筆交易的細節，卻說不出這些細節拼在一起意味著什麼。
那天我開始思考一個看似天真的問題：資料和知識之間，到底差了什麼？
後來我發現，這個問題困擾了哲學家兩千五百年。而且他們的回答，對我們做工程的人來說，驚人地實用。
背景：從位元到智慧的距離
DIKW 金字塔：一個被低估的架構
在資訊科學裡，有一個經典的層次模型——DIKW 金字塔：Data（資料）、Information（資訊）、Knowledge（知識）、Wisdom（智慧）。大多數人把它當口號看過就算了。但如果你用工程師的眼睛仔細看，它其實描述的是一條轉換 pipeline：
raw = b"01001000 01100101 01101100 01101100 01101111"
info = raw.decode("utf-8") # "Hello" — 有了格式
knowledge = "英語問候語，用於初次見面" # 有了語境和意義
wisdom = "此刻對這個人說 Hello 是否合適" # 有了判斷與行動
每一層轉換都不是自動發生的。從資料到資訊，你需要編碼與格式；從資訊到知識，你需要語境與連結；從知識到智慧，你需要經驗與判斷。
這裡有一個工程師特別能理解的重點：每一層的轉換都會引入不確定性。 資料本身是確定的（那些 bit 就是那些 bit），但一旦開始解讀，你就進入了哲學的領地。
哲學家的版本：JTB 與它的崩塌
哲學界對「知識」最經典的定義叫做 JTB——Justified True Belief（被證成的真信念）。要算作「知識」，你需要同時滿足三個條件：
- 你相信它（Belief）——你的系統裡有這筆記錄
- 它是真的（True）——它確實對應現實
- 你有充分的理由相信它（Justified）——你的信念不是碰巧猜對的
用工程師的語言翻譯：
def is_knowledge(claim, evidence, reality):
believed = claim in my_beliefs # 我相信嗎？
true = claim.matches(reality) # 它是真的嗎？
justified = evidence.supports(claim) # 我有好的理由嗎？
return believed and true and justified
這看起來很乾淨。但 1963 年，一個叫蓋提爾（Edmund Gettier）的哲學家用兩頁紙的論文炸掉了這個定義。他給出的反例本質上是：你可以有充分的理由相信一件恰好為真的事情，但你的理由和它為什麼為真之間毫無關係。 你猜對了答案，但你的推理過程是錯的。
工程師見過太多這種情況了。你的測試全綠，程式碼也確實在正確運行——但不是因為你的邏輯對了，而是因為兩個 bug 剛好互相抵消。你「知道」程式是對的嗎？
Schema 就是世界觀
你怎麼存，就怎麼想
這是整篇文章最重要的洞察之一，所以讓我慢慢展開。
當你設計一個資料庫 schema，你做了一個看似純技術的決定。但仔細想想，你其實在做一件非常哲學的事——你在決定世界由什麼組成。
你把「人」拆成欄位：姓名、年齡、性別、職稱、部門。這些欄位就是你認為「人」最重要的屬性。你沒有放「夢想」、「恐懼」、「童年記憶」——不是因為這些不存在，而是因為它們不在你的模型範圍內。
你把「關係」拆成外鍵和關聯表：朋友、同事、上司。但人際關係的微妙性——亦敵亦友、曾經親密但漸行漸遠、表面客氣但暗中較勁——這些在你的 schema 裡不存在。
Schema 是一種本體論宣言：它定義了你的系統「看得見」什麼。
而你看不見的東西，你永遠問不出關於它的問題。
# 你的 schema 決定了你能提出什麼問題
class Employee:
name: str
department: str
salary: float
# 你能問：誰的薪水最高？哪個部門人最多？
# 你問不出：誰最有創造力？誰在默默支撐團隊？
哲學裡，這叫做「本體論承諾」（ontological commitment）——你的語言和框架決定了你承認什麼東西存在。SQL schema 是一種本體論承諾。API 的 response format 是一種本體論承諾。你選擇追蹤的 metrics 也是。
知識的三個隱藏維度
在 DIKW 金字塔之外，知識還有三個工程師容易忽略的維度。
第一，知識有語境（Context）。 「水在 100 度沸騰」——這在海平面是對的，在高山上就不是。你的 feature flag 在測試環境表現完美，到了生產環境就出問題——因為語境變了。知識離開了它成立的語境，就從「知識」退化成「可能會誤導你的資訊」。
第二，知識有時效（Temporality）。 「這個 API endpoint 回傳 JSON 格式」——直到下一個版本改成了 Protocol Buffers。你對 framework 最佳實踐的理解——直到社群共識轉向了。知識是有保鮮期的，但我們很少給信念標上 TTL。
第三，知識有出處（Provenance）。 你從哪裡知道這件事的？是你親自驗證的、是同事告訴你的、是從文件讀到的、還是 AI 生成的？每一個來源都帶有不同程度的可信度。但在日常工作中，我們很少追蹤信念的出處鏈——直到某個「大家都知道」的假設被發現是錯的。
知識版本控制：信念也需要 Git
為什麼你的知識系統需要 retract
你的程式碼有 Git。你的文件有版本控制。但你的信念呢？
想想看——你在三年前讀了一篇文章，學到「微服務是正確的架構方向」。這個信念進入了你的知識系統。從此以後，你在每一個架構決策中都帶著它。但你從來沒有回去更新過這個信念——即使你已經經歷過微服務帶來的痛苦、讀過反對的聲音、看過不同的成功模式。
成熟的知識系統必須能做三件事：
class KnowledgeRepo:
def commit(self, claim, evidence, confidence):
"""新增一條知識，附帶證據和信心度"""
self.log.append({"claim": claim, "evidence": evidence,
"confidence": confidence, "status": "active"})
def retract(self, claim, reason):
"""撤回一條知識——不是刪除，是標記為已撤回"""
self.log.append({"retract": claim, "reason": reason})
def trace(self, claim):
"""追溯一條知識的完整歷史"""
return [entry for entry in self.log if entry.get("claim") == claim]
更新：新證據來了，要能合併進來。撤回：舊主張錯了，要能明確標記——不是悄悄刪除，而是留下記錄，說明為什麼改了。追溯：每一個結論都要能追回到它的來源和推理過程。
這和你做 incident postmortem 的邏輯一模一樣。你不會在系統出問題後把 log 刪掉假裝沒發生過——你會追溯、記錄、更新預防措施。你的信念系統也值得同樣的嚴謹對待。
知識圖譜：不是大，而是可查詢
知識圖譜在工程界很熱門，但大多數人關注的是「大」。哲學給我們一個不同的視角：知識圖譜的價值不在於節點多寡，而在於可推導性。
一個好的知識結構，要能讓你從已知推出未知：
# 最小可用的知識推導
facts = {
("海水密度", "受影響於", "鹽度"),
("海水密度", "受影響於", "溫度"),
("鹽度", "可由", "導電度估算"),
}
def what_affects(subject):
return {obj for (s, p, obj) in facts if s == subject and p == "受影響於"}
# what_affects("海水密度") → {"鹽度", "溫度"}
重點不在程式碼的複雜度，而在於你把知識結構化到了可以被機器查詢和推導的程度。這是從「我腦子裡知道」到「系統可以用」的關鍵躍遷。
現代連結：LLM 有知識嗎？
流利不等於知道
這是 AI 時代最緊迫的認識論問題。
你問 ChatGPT 一個問題，它給你一個流暢、有組織、看起來很有道理的回答。它「知道」這些事情嗎？
用 JTB 框架來檢查：
- Belief：嚴格來說，LLM 不「相信」任何東西。它計算下一個 token 的機率分佈。但從行為上看，它表現得像是有信念。
- Truth：它的回答有時候是對的，有時候是精心包裝的錯誤。它不區分這兩者。
- Justification：這是最致命的弱點。LLM 通常無法指出一個可驗證的來源鏈。它的「理由」是統計模式，不是推理過程。
所以 LLM 的輸出更像是——它通過了融貫論的測試（看起來前後一致），但不一定通過符應論的測試（不一定對應事實）。它「像」知識，但缺少知識最核心的要素：可追溯的證成。
RAG 的認識論意義
這就是為什麼 RAG（Retrieval-Augmented Generation）在工程實務上如此重要——它不只是一個技術優化，它是一個認識論補丁。
RAG 做的事情是：在生成回答之前，先去查一個可靠的知識庫，把檢索到的來源附在回答旁邊。翻譯成哲學語言——它把「沒有 justification 的 belief」升級成了「有來源追溯的 justified belief」。
不完美，但方向是對的。工程師在這裡做的事情，本質上就是在修補一個認識論的漏洞。
知識供應鏈管理
在 AI 時代，知識不再是一次性的判定。它需要像供應鏈一樣管理：
- 來源追溯（provenance）——這個說法從哪來的？
- 信心標記（confidence scoring）——我有多確定？
- 交叉驗證（multi-source validation）——有獨立的第二來源嗎？
- 時效管理（TTL）——什麼時候需要重新驗證？
你每天在做的 CI/CD pipeline，本質上就是一套知識維護系統——它持續驗證你的程式碼（信念）在新的環境（現實）中是否還成立。
反思與啟示：你是在收集資料，還是在累積理解？
資料焦慮症的解藥
很多人做資料累積，是在累積一種安全感：「只要資料夠多，我就不會判斷錯。」
但真實的情況是：資料越多，你反而越能看見自己不知道的東西。更多的資料帶來更多的維度，更多的維度帶來更多的矛盾，更多的矛盾帶來更多的不確定性。
成熟的知識觀不是「我知道」，而是「我知道我在哪裡不確定」。
四個帶走的心智模型
-
區分層次——下次當你說「我知道」的時候，問自己：你是有資料、有資訊、有知識、還是有理解？層次不同，你能做的決策品質就不同。
-
檢查 schema——你的思考框架（你追蹤的 metrics、你問的問題、你建的模型）決定了你能看見什麼。定期問：有什麼重要的東西不在我的 schema 裡？
-
標記出處——每一個重要的信念，嘗試追溯它的來源。是你親自驗證的？還是「大家都這麼說」？來源的可信度直接決定信念的可信度。
-
設定 TTL——給你的核心信念設保鮮期。每隔一段時間主動問：這個信念還成立嗎？世界變了嗎？有新的證據嗎？
結語
回到那天下午的資料庫前面。
我有幾百萬筆資料。但我學到了一件重要的事：資料不會自動變成知識，就像食材不會自動變成料理。 中間需要結構、語境、判斷、經驗——以及一個願意承認「我還不夠理解」的人。
下次當你從資料庫撈出一堆數字，準備寫進報告的時候，也許會多想一秒：
這是資料，還是知識？你真的「知道」了什麼？
下一篇預告
我思故我在.py
你的程式會反射（reflection）、會監控自己、會根據狀態自動調整策略。它有「自我意識」嗎？
- 笛卡兒懷疑一切之後剩下什麼？為什麼它像一個 fallback 機制？
- 反射（reflection）和遞迴（recursion）——自我指涉的工程結構能解釋意識嗎？
- AI agent 會規劃、會修正、會說「我覺得」——我們該怎麼面對這種人格投射？
- 意識的「硬問題」到底難在哪裡？為什麼工程方法可能永遠解不了它？
下一篇，我們從笛卡兒的方法論懷疑出發，用 inspect、self、和監控系統來拆解意識之謎。
參考資料
- Plato. Theaetetus. (知識的經典定義：被證成的真信念)
- Gettier, Edmund. “Is Justified True Belief Knowledge?” Analysis, 1963. (JTB 反例)
- Ackoff, Russell. “From Data to Wisdom.” Journal of Applied Systems Analysis, 1989. (DIKW 金字塔)
- Quine, W.V.O. “On What There Is.” Review of Metaphysics, 1948. (本體論承諾)
- Floridi, Luciano. The Philosophy of Information. Oxford University Press, 2011. (資訊哲學)
- Lewis, Patrick et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS, 2020. (RAG)
