Data → Knowledge → AI/RAG
從「水井三寶智慧互動展覽系統」第五層看懂資料如何成為文化知識
Event Data × Database × Cultural Knowledge × Retrieval × LLM × RAG
前面的水井三寶教材已經讓一筆「烏龜故事被播放」的事件，從ESP32經過HTTP、JSON與REST API送到Django。但資料送到Database並不是終點。真正值得思考的是：「烏龜今天播放37次」和「烏龜為什麼代表守水？」是同一種資料嗎？答案是否定的。這正是水井三寶五層架構從Layer 4走向Layer 5，以及未來導入AI/RAG最重要的分界。
一、先分清楚：Data不等於Knowledge
假設Django儀表板顯示：
白馬故事：52次
烏龜故事：37次
姻緣花故事：46次
總故事：21次
今日互動人次：156這些是非常有價值的Data（資料），它告訴我們系統發生了什麼。
但如果觀眾問：
「姻緣花和地方記憶有什麼關係？」
「水井三寶是哪三件作品？」
「這些作品和生產、生態、生活三生一體有什麼關係？」
這些問題就不能只靠播放次數回答。它需要地方故事、創作者資料、作品說明、影音、教材與USR實踐內容，這些才逐步形成Knowledge（知識）。
二、Layer 4和Layer 5到底差在哪裡？
| 比較 | Layer 4：Digital Twin / Data | Layer 5：文化知識 |
|---|---|---|
| 核心 | 事件、狀態、統計 | 故事、脈絡、意義、教材 |
| 典型內容 | 故事播放次數、時間、來源、完成率 | 白馬、烏龜、姻緣花的文化故事 |
| 資料型態 | 結構化資料 | 文字、圖片、影音、文件等多元內容 |
| 主要工具 | Django Model、Database、Dashboard | 文化網站、知識庫、未來RAG |
| 回答問題 | 今天有多少互動？ | 這個故事的文化意義是什麼？ |
三、從Data到Information，再到Knowledge
可以把轉換過程理解成：
從原始事件到統計，是「整理資料」；從統計到文化脈絡，則需要另外建立知識內容，不能只靠數字自動產生。
四、水井三寶的Knowledge從哪裡來？
第五層可以逐步整理以下知識來源：
| 知識類型 | 內容例子 |
|---|---|
| 地方故事 | 白馬、烏龜、姻緣花、水井村與地方記憶 |
| 作品資料 | 作品名稱、創作者、材料、設計理念、創作歷程 |
| 工藝知識 | 玉米籜、蓪草、姻緣花燈、地方工藝製作 |
| 教育教材 | 繪本、教案、親子活動、科技教育教材 |
| 影音內容 | 故事語音、影片、訪談、活動紀錄 |
| USR實踐 | 生產、生態、生活三生一體與大學社會責任歷程 |
| 互動資料 | Layer 4匿名事件與展覽統計 |
五、傳統搜尋和AI問答有什麼不同？
傳統網站通常要求使用者先知道要點哪一頁：
AI問答則可以讓使用者直接問：
「請用小學生聽得懂的方式介紹水井三寶。」
「姻緣花和地方工藝有什麼關係？」
但這裡出現一個新問題：大型語言模型不一定知道水井村的地方知識，即使回答得很流暢，也可能產生錯誤內容。
六、這就是為什麼需要RAG
RAG是 Retrieval-Augmented Generation，中文常譯為「檢索增強生成」。
核心概念不是讓AI憑記憶回答，而是：
七、為什麼不直接問Chatbot就好？
一般LLM可能具備廣泛知識，但「水井三寶」屬於高度地方化、專案化的內容。這類知識可能不在模型訓練資料中，也可能在作品持續發展後改變。
| 直接LLM | RAG |
|---|---|
| 主要依賴模型既有知識 | 先查水井三寶自己的知識庫 |
| 地方內容可能不足 | 可以納入地方採集與USR資料 |
| 更新通常不容易立即反映 | 更新知識庫即可提供新內容 |
| 回答來源較難控制 | 可要求依檢索內容回答並提供來源 |
八、RAG不是把整個網站一次丟給AI
真正的RAG通常會先對文化內容做前處理：
例如一篇長文章可以切成：
Chunk 001：白馬的故事
Chunk 002：烏龜與水文化
Chunk 003：姻緣花的文化意義
Chunk 004：創作者與作品歷程
Chunk 005：水井三寶與三生一體九、Embedding是在做什麼？
Embedding可以簡化理解成：把文字轉換成一組數值向量，讓系統可以比較「語意上像不像」。
例如使用者問：
「哪一個角色和珍惜水資源有關？」即使文章中沒有完全相同的句子，向量檢索仍可能找到：
「烏龜慢慢觀察土地與水，
提醒我們珍惜自然。」這和傳統只比對關鍵字的搜尋方式不同。
十、Metadata為什麼很重要？
每個知識Chunk除了文字，也應保存來源資訊：
{
"title":"水井三寶作品介紹",
"category":"地方文化",
"character":"turtle",
"source":"official",
"language":"zh-Hant",
"updated_at":"2026-08"
}這讓未來RAG可以限制：
只找「烏龜」相關內容
只找「教育教材」
只找最新版本內容
十一、一個完整RAG問答會怎麼走？
十二、Django在第五層還可以扮演什麼角色？
Django在Layer 4主要接收事件；到了Layer 5，可以進一步成為文化知識與AI服務的入口：
/api/exhibition/events/ → Layer 4事件
/api/knowledge/search/ → 搜尋文化知識
/api/ai/ask/ → AI/RAG問答
/api/treasures/white-horse/ → 白馬知識
/api/treasures/turtle/ → 烏龜知識
/api/treasures/flower/ → 姻緣花知識這樣就形成：
十三、Layer 4資料能不能直接拿來做RAG？
可以使用，但用途不同。
例如Layer 4告訴我們：
今天：
白馬 52次
烏龜 37次
姻緣花 46次AI可以根據這些結構化資料回答：
「三個故事的播放比例是多少？」
文化知識庫則回答：
「誰參與水井三寶作品創作？」
「水井三寶如何連結三生一體？」
十四、未來可以形成兩種AI工具
| AI角色 | 資料來源 | 問題例子 |
|---|---|---|
| 展覽數據助理 | Django事件資料庫 | 今天哪個故事最熱門？ |
| 文化導覽助理 | RAG文化知識庫 | 請介紹姻緣花的故事 |
再進一步，也可以讓兩者合作：
十五、AI回答文化故事時，最重要的是「有根據」
文化AI不能只追求回答流暢，還必須重視：
| 原則 | 說明 |
|---|---|
| Grounding | 回答必須根據知識庫資料 |
| Source | 能指出資料來源 |
| Version | 知道資料更新時間 |
| Authority | 區分官方、訪談、學生整理等來源 |
| Uncertainty | 資料不足時應說不知道，而不是自行編故事 |
十六、五層架構到這裡終於完整串起來
白馬、烏龜、姻緣花實體作品，是文化的起點。
ESP32、ToF、按鈕、JQ6500、WS2812B讓作品能感測、發聲與發光。
手機透過ESP32內嵌網站控制作品、查看設備狀態。
匿名事件經HTTP＋JSON＋REST API進入Django，形成Database與Dashboard。
地方故事、作品、工藝、影音、教育與USR內容形成Knowledge Base，未來再透過AI/RAG提供智慧文化導覽。
十七、從五層架構看資料價值如何增加
這條路徑也說明了為什麼水井三寶不是單純的ESP32作品：硬體只是入口，真正長期累積的資產是資料、文化內容與知識。
十八、課堂實作可以怎麼做？
可以把學生分成四個階段：
| 階段 | 任務 |
|---|---|
| 1. Data | 讀取Django事件資料，統計三個故事播放次數 |
| 2. Knowledge | 把白馬、烏龜、姻緣花文章整理成知識文件 |
| 3. Retrieval | 把文件切Chunk、加入Metadata並進行檢索 |
| 4. AI/RAG | 讓LLM只根據檢索內容回答文化問題 |
十九、課堂思考題
二十、結語：真正的第五層，是把地方記憶變成可以延續的知識
從ESP32送出一筆事件，到Django形成Dashboard，我們完成的是Data；把作品故事、創作者、工藝、教育與USR歷程整理起來，我們開始建立Knowledge；當這些知識能被檢索、被引用，再交給LLM產生符合不同觀眾需求的回答，就進一步形成AI/RAG服務。
因此，水井三寶五層架構的最後一層並不是為了「加上AI」而加AI。真正的目標是先把地方知識整理好，再讓AI成為連結人與知識的新介面。
Data Knowledge AI RAG Embedding Vector Search Django LLM 文化數位化 USR
沒有留言:
張貼留言