昨天我們完成了資料契約，統一了欄位名稱、資料型態、單位、來源與版本。

今天遇到的新問題是：

資料已經整理好了，AI 真的會正確使用嗎？

假設我們有一份校園餐點資料，使用者詢問：

「彰化市區晚上還有 100 元以下、適合素食者的餐點嗎？」

如果直接把問題交給一般聊天機器人，AI 可能會：

• 根據過時資訊回答
• 混用不同版本資料
• 把模擬資料當成真實資料
• 找不到答案時自行補完
• 提供沒有來源的推薦

今天要學的 RAG，就是讓 AI 先搜尋指定資料，再根據找到的內容回答。

RAG 是什麼？

RAG 是 Retrieval-Augmented Generation 的縮寫，中文可以翻成「檢索增強生成」。

它不是重新訓練一個 AI，而是把外部資料加入回答流程：

1. 使用者提出問題。
2. 系統從專題資料中找出相關片段。
3. AI 閱讀這些片段。
4. AI 根據片段產生回答。
5. 系統保留來源，讓人可以回頭查證。

一般聊天流程：

使用者問題
→ AI 直接回答

RAG 流程：

使用者問題
→ 搜尋專題資料
→ 找到相關證據
→ AI 根據證據回答
→ 顯示來源

RAG 不能保證答案永遠正確。

如果原始資料錯誤、過期或沒有涵蓋問題，RAG 仍然可能產生不完整的回答。因此，RAG 的重點不是「讓 AI 自動知道一切」，而是讓回答有明確的資料依據。

RAG 在 AI 專題中解決什麼問題？

以我們的餐點推薦專題為例：

RAG 特別適合：

• 校園規章問答
• 專題資料查詢
• 研究論文整理
• 課程教材問答
• 商品或餐點推薦
• 公司內部文件搜尋
• 競賽 Demo 的知識問答

RAG 的六個主要階段

第一階段：資料匯入

將昨天整理好的資料放入系統，例如：

• PDF
• 網頁
• CSV
• JSON
• Google 文件
• 訪談紀錄
• 決策紀錄

資料匯入前，必須先確認：

• 是否為最新版本
• 是否有來源
• 是否包含不必要的個資
• 是否能合法使用
• 是否標示真實資料或模擬資料

第二階段：資料切分

一份很長的文件不能直接當成一個搜尋單位。

系統通常會把文件切成許多較小的文字片段，讓搜尋時可以找到更相關的內容。

例如：

原始文件
→ 問題背景
→ 使用者需求
→ 餐點資料
→ 資料限制
→ 團隊決策

切分時不要只按照固定字數處理，也要考慮內容結構。

比較好的片段通常包含：

• 一個完整段落
• 一個表格列
• 一個完整規則
• 一個完整訪談主題
• 一筆具有來源的資料

如果切得太大，搜尋結果可能包含很多無關內容。

如果切得太小，重要的前後文可能被分開。

第三階段：建立索引

索引可以想成一本大型資料的目錄。

系統會替每個資料片段建立可搜尋的表示方式，讓「便宜的素食餐點」和「低預算蔬食選項」有機會被視為相關內容。

這種搜尋不只依靠完全相同的關鍵字，也可能使用語意相似度。

但是語意搜尋不是萬能的。

以下內容仍然需要額外處理：

• 店家名稱
• 編號
• 日期
• 價格
• 精確地址
• 特殊分類
• 營業時間

因此，實際專題通常會混合：

• 關鍵字搜尋
• 欄位篩選
• 語意搜尋
• 來源與版本條件

第四階段：檢索

當使用者提出問題時，系統會從資料中找出最相關的片段。

例如：

使用者問題：
彰化市區晚上還有 100 元以下的素食餐點嗎？

檢索條件：
- 類別：餐點
- 預算：100 元以下
- 飲食標籤：素食
- 查詢時間：晚上
- 資料版本：places_v1.0

這時候不要把所有資料都交給 AI。

比較好的做法是：

1. 先使用固定欄位篩選。
2. 再讓 AI 比較篩選後的候選項目。
3. 最後要求 AI 提供推薦理由與來源。

這樣可以減少 AI 讀取無關資料，也能降低成本。

第五階段：生成回答

檢索到的內容會和使用者問題一起交給 AI。

可以使用以下提示詞：

你是 AI 專題中的資料型推薦助手。

請只根據我提供的候選資料回答，不要使用未提供的外部資訊。

回答規則：

1. 先列出符合條件的候選項目。
2. 說明每個候選項目符合哪些條件。
3. 每個重要主張都要附上 source_url。
4. 如果資料沒有提供營業狀態，不要自行推測目前是否營業。
5. 如果沒有完全符合的項目，請明確說明「目前資料不足」。
6. 不要把 estimated、unknown 或 simulated 改寫成 confirmed。
7. 最後列出仍需要人工確認的事項。

使用者條件：

- 預算：100 元以下
- 飲食限制：素食
- 時段：晚上
- 地點：彰化市區

候選資料：

請貼上經過篩選的 JSON 或表格資料。

這份提示詞的重點不是要求 AI「推薦最好的答案」，而是限制它：

• 只能使用指定資料
• 必須保留狀態
• 必須提供來源
• 不可以把未知內容猜成事實

第六階段：人工驗收

RAG 產生回答後，不能直接放到網站或簡報。

至少檢查：

初學者免費路線

對沒有程式背景的大一生，可以先使用以下流程：

Google Drive
→ Google Sheets 整理資料
→ NotebookLM 或其他可上傳資料的 AI 工具
→ 以來源為範圍提問
→ 人工檢查引用
→ 將確認結果放入簡報或網站

這條路線適合：

• 先理解 RAG 概念
• 快速製作研究型 Demo
• 不想先處理伺服器
• 需要展示資料引用

若要做成真正的網站功能，可以再進階使用：

• Python
• 向量資料庫
• OpenAI File Search
• Google Cloud RAG Engine
• 其他支援檢索的 API

OpenAI 官方文件提供 File Search 與 Retrieval 的 API 說明；Google Cloud 也提供 RAG Engine 與相關架構文件。API、雲端儲存及模型使用量可能產生成本，實際價格與免費額度應以官方最新頁面為準。:chatgpt-content-reference{index="1"}

不要把所有資料直接交給 AI

以下做法看起來快速，實際上容易出錯：

把整份資料貼給 AI
→ 要求 AI 自由整理
→ 直接把結果放進網站

問題包括：

• AI 不知道哪些資料已過期
• AI 不知道哪一筆資料比較可信
• AI 可能忽略欄位狀態
• AI 可能把多筆資料混在一起
• 團隊難以重現相同結果

比較可靠的流程是：

原始資料
→ 清理與版本確認
→ 固定欄位篩選
→ 檢索相關片段
→ AI 產生草稿
→ 人工查證
→ 發布

用來源卡控制 RAG 品質

每個資料片段都建議保留以下欄位：

source_id
source_name
source_type
source_url
dataset_version
collected_at
verified_at
verification_status

例如：

{
  "source_id": "SRC001",
  "source_name": "校園餐廳公告",
  "source_type": "official_website",
  "source_url": "https://example.edu.tw/dining",
  "dataset_version": "places_v1.0",
  "collected_at": "2026-09-21T16:00:00+08:00",
  "verified_at": "2026-09-22T09:00:00+08:00",
  "verification_status": "verified"
}

如果資料是團隊模擬的，應標示：

verification_status: simulated

如果目前還沒有查證，應標示：

verification_status: unknown

狀態欄位很重要，因為評審可能會問：

你們的推薦資料是真實資料，還是示範資料？

建立 RAG 測試問題集

不要只測試一個問題。

建議建立至少十題測試問題，包含不同類型：

每一題先寫出預期結果，再測試 AI。

RAG 驗收表

常見錯誤一：以為使用 RAG 就不會幻覺

RAG 只能提供資料，不代表 AI 一定正確。

如果檢索結果不相關，AI 仍然可能產生錯誤答案。

因此要分開檢查：

1. 找到的片段是否正確。
2. AI 是否忠實使用片段。
3. 回答是否超出資料範圍。

常見錯誤二：只依賴語意搜尋

如果要找「價格剛好 100 元」或「資料版本 1.0」，不能只依賴語意相似度。

價格、日期、版本與分類應該使用固定欄位篩選，再交給 AI 做比較與說明。

常見錯誤三：資料切得太碎

如果一段資料只有：

價格：80 元

卻沒有店名、日期與來源，AI 找到這段資料也不知道它代表什麼。

每個片段都應保留必要上下文。

常見錯誤四：把 AI 摘要再次當成原始資料

AI 摘要是衍生資料，不是原始證據。

建議使用以下標記：

SOURCE：原始來源
RETRIEVED：檢索到的資料片段
AI_DRAFT：AI 產生的草稿
VERIFIED：人工確認完成
DECISION：團隊正式採用

今天的實作練習

任務一：準備五份資料

至少包含：

• 一份官方資料
• 一份團隊訪談紀錄
• 一份餐點或地點資料
• 一份資料字典
• 一份團隊決策紀錄

任務二：建立十題測試問題

包含正常查詢、無結果查詢、資料不足查詢與來源查詢。

任務三：執行三種回答方式

比較：

1. 不提供專題資料，直接詢問 AI。
2. 提供全部資料，要求 AI 整理。
3. 先篩選資料，再以 RAG 或來源限定方式詢問。

記錄三種方式的：

• 正確性
• 引用完整度
• 回答時間
• 是否自行猜測
• 是否容易人工驗收

任務四：建立錯誤紀錄

每次回答出錯時，記錄：

測試問題：
使用的資料版本：
找到的資料：
AI 回答：
錯誤類型：
應該如何修正：

今天的完成條件是：

團隊能展示一個問題，說明 AI 找到了哪些資料、如何產生回答，以及如何確認回答沒有超出證據。

今日重點

RAG 不是把資料上傳後就完成，而是一條完整的專題流程：

資料匯入
→ 資料切分
→ 建立索引
→ 檢索相關片段
→ 根據證據生成
→ 人工查證
→ 發布具有來源的結果

AI 可以協助搜尋、比較與說明，但團隊仍然要負責：

• 資料是否可靠
• 來源是否合法
• 版本是否一致
• 引用是否支持主張
• 結果是否適合真正使用者

能得獎的專題，通常不只是展示「AI 很會回答」，而是能清楚說明：

這個答案使用了哪些資料，為什麼可信，失敗時如何被發現。

下一篇預告

Day 9，我們將把 RAG 的回答接到專題網站，學習如何設計 AI 功能介面、錯誤狀態、來源顯示與使用者操作流程。

官方參考資料

1. OpenAI｜File Search
   https://developers.openai.com/api/docs/guides/tools-file-search

2. OpenAI｜Retrieval
   https://developers.openai.com/api/docs/guides/retrieval

3. Google Cloud｜What is Retrieval-Augmented Generation
   https://cloud.google.com/use-cases/retrieval-augmented-generation

4. Google Cloud｜RAG Engine overview
   https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/rag-overview

以上資料於 2026 年 9 月 22 日查閱。工具功能、API 方案、免費額度與價格可能變動，使用前請查看官方最新文件。