前四天我們已經拆解檢索增強生成（RAG）的原理：文件需要先解析、切割、向量化，再透過搜尋把真正相關的內容交給模型。今天不再停留在概念，而是把這條流程真正接起來。

這一天的目標不是立刻做出一套「完整企業知識庫」，而是先完成一條最小、可以驗證的路徑：

前端提出問題
    ↓
後端收到問題
    ↓
文件工具找出相關段落
    ↓
Gemini 根據段落回答
    ↓
回傳答案與來源

只要這條路徑成立，我們就完成了第一個真正可以運作的 PDF RAG。後面不論要加入更進階的 Retrieval、Tool Use 或 Agent，都可以在這個基礎上繼續擴充。

第一步：先讓模型本身可以工作

Data Machi 使用大型語言模型來理解問題與組織回答，因此第一步需要先準備 Gemini API。取得 API Key 之後，不要直接把金鑰寫進程式碼，而是存放在本機環境變數，例如 .env，讓程式啟動時再從環境讀取。

GOOGLE_API_KEY=your_key_here
GEMINI_MODEL=your_primary_model
GEMINI_FAST_MODEL=your_fast_model

實際申請時，可以先登入 Google AI Studio，在 API Key 管理入口選擇或建立 Google Cloud Project，再於該 Project 建立 Gemini API Key。Key 建立完成後應妥善保存，不要貼進公開文件、GitHub Repository 或任何可能被其他人看到的位置。

把 API Key 放進環境變數看起來只是安全習慣，其實也和後面的部署方式有關。本機環境可以使用 .env，未來部署到 Render 時則改放到平台的 Environment Variables，程式碼本身不需要因為執行環境不同而修改。

Data Machi 可以採用雙模型的設計：主要模型負責使用者最後看見的回答，較快速的模型則負責分類、問題釐清、驗證或其他內部工作。不過第一版不需要一次把所有設計都完成，可以先設定一個模型，把主要流程成功跑通之後再拆分。

這裡還有一個非常重要的安全原則：Gemini API Key 只能存在後端，不能放進 Vercel 前端。 如果把 Secret 寫進前端 JavaScript 或環境變數 Bundle，使用者就可能透過瀏覽器工具或網路請求取得金鑰。

正確的呼叫流程應該是：

使用者瀏覽器
    ↓
React Frontend
    ↓
Render / FastAPI Backend
    ↓
Gemini API

也就是前端只知道後端 API 在哪裡，而真正的 Gemini Key 只有後端知道。

先完成最小模型測試

取得金鑰後，第一個測試先不要碰 RAG，而是確認最基本的模型呼叫可以工作：

前端送出訊息
    ↓
後端 /chat
    ↓
Gemini
    ↓
後端取得回答
    ↓
前端顯示結果

可以送出一句完全不需要企業資料的問題，例如：

「請用三句話說明你能協助處理哪些工作。」

這一步只需要確認四件事情：前端有顯示送出或處理中的狀態、後端 Terminal 收到 /chat 請求、Gemini 正常回傳內容，以及前端最後能顯示完整回答。發生錯誤時，也應該能結束 Loading 狀態並顯示錯誤訊息，而不是永遠停在等待畫面。

這時先不要加入 Google Sheets、PDF RAG、Trello 或對話記憶。因為如果一次串接五個功能才發生錯誤，就很難判斷問題到底出在前端、後端、模型、API 權限還是 Route。

常見的問題可以先從下表快速定位：

等這條最基本的模型主幹確認穩定之後，再開始加入文件檢索。

第二步：準備一份適合驗證的測試文件

實作初期不要直接匯入幾百份公司 PDF。比較好的方式，是先選一份內容自己很熟悉、答案容易人工驗證，而且不包含敏感資訊的文件。文件中最好包含幾項清楚的規則、定義或政策，這樣才容易判斷 Retriever 找到的內容究竟是不是正確答案。

如果文件是文字型 PDF，可以直接進入 Parse、Chunk、Embedding 與 Index 流程；如果是掃描 PDF，則要先經過 Day 09 提到的 OCR 或視覺處理。因此第一個 RAG 實作最好先從乾淨的文字型 PDF 開始，先確認整條流程沒有問題，再逐步處理表格、掃描頁或圖片。

實際測試時，也不建議直接使用公司內部文件。可以自己製作一份約 3–5 頁的匿名測試 PDF，其中包含清楚標題、幾個小節、一張簡單表格、明確日期與定義，並刻意留下一些「文件完全沒有提到」的問題。這些不存在於文件中的資訊，之後會用來測試系統是否能在證據不足時誠實拒答。

第三步：建立索引，而不是把整份 PDF 塞進 Prompt

文件進入系統後，會依序經過前面幾天介紹的處理流程：先解析文字，再切割成適合搜尋的文件片段（Chunk），接著產生向量表示（Embedding），最後保存到可搜尋的索引（Index）。

PDF
 ↓
Parse
解析文件
 ↓
Chunking
切割文件片段
 ↓
Embedding
產生向量
 ↓
Index
建立索引

這一層的目的不是讓 Gemini 把整份文件「背起來」，而是建立一個之後能快速搜尋的知識結構。當使用者提出問題時，系統才去 Index 中找出最相關的內容，再把真正需要的片段交給模型。

Chunk 不宜過大，也不宜切得過碎。太大的 Chunk 會夾帶很多不相關內容；太小則可能把一條完整規則的條件、說明與例外拆散。第一版不需要急著找到所謂的「最佳 Chunk Size」，更重要的是保留可以調整的空間，並用真實問題驗證搜尋結果。

第四步：先看 Retrieval，再看模型回答

RAG 最容易踩到的一個坑，就是只看最後的回答。

大型語言模型很擅長產生自然流暢的文字，即使 Retriever 找錯文件，它仍然可能生成一段「看起來很合理」的答案。因此 RAG 測試最好拆成兩層：先驗證 Retrieval，再驗證 Generation。

第一層輸入問題之後，不要急著看 Gemini 的回答，而是先檢查 Retriever 找回了哪些 Chunk。例如使用者詢問：

「員工出差需要提前幾天申請？」

系統可能回傳：

Top 1
員工出差需於出發日前 7 日完成申請。

Top 2
海外差旅需取得部門主管核准。

Top 3
交通費應檢附相關付款證明。

如果正確規則已經出現在前幾筆結果中，代表 Retrieval 至少成功找到了相關證據。第二層才把這些 Chunks 交給 Gemini，並要求模型只能根據提供的 Context 回答。

實際驗證時，可以設計三類問題：第一類直接用文件中的說法提問；第二類換一種說法問同一件事情；第三類則詢問文件根本沒有提供答案的內容。

例如：

直接詢問：
員工出差需要提前多久提出？

換句話說：
出差前幾天要送申請？

文件沒有答案：
員工出差可以攜帶寵物嗎？

第三種尤其重要。當文件沒有提供答案時，系統應該明確說明資料不足，而不是利用模型原本的常識自行補完。

這也是企業 RAG 和一般聊天體驗很重要的差別：

沒有證據時，不回答也是一種正確答案。

第五步：讓答案保留來源

企業情境中的 RAG，如果只有漂亮答案卻不知道資訊來自哪裡，可信度仍然有限。因此 Document Tool 的輸出不應該只有文字內容，也需要保存可以追溯回原始文件的 Metadata。

完整流程可以理解成：

使用者問題
    ↓
Retriever
    ↓
相關文件片段
+
Metadata
    ↓
Gemini
    ↓
答案
+
來源

每一個 Chunk 至少可以保存以下資訊：

例如最後的回答可以呈現為：

國內出差住宿費每日上限為 3,000 元。

來源：
travel_policy.pdf
Page 3
「國內住宿費每日上限為新台幣 3,000 元。」

這樣當答案有爭議時，使用者可以回到原始文件確認，而不是只能相信模型產生的文字。

索引不一定要在 Server 啟動時全部載入

如果索引資料量開始增加，也不一定要在 Backend 每次啟動時就把所有文件全部載入。可以考慮採用 Lazy Initialization，也就是第一次真的有人查詢文件時，才載入或初始化所需的 Index，之後再把結果留在記憶體或其他持久化儲存中。

流程可以理解成：

Backend 啟動
    ↓
暫時不載入大型 Index
    ↓
使用者第一次查文件
    ↓
初始化 / 載入 Index
    ↓
執行 Retrieval
    ↓
後續查詢重複使用

這樣可以降低 Server 的啟動時間，但代價是第一次查詢可能比較慢。如果採用這種設計，前端最好顯示「正在準備文件索引」之類的狀態，而不是只顯示無限轉圈的 Loading。

到這裡，我們才真正完成第一個可以驗證的 RAG，而不只是「把 PDF 丟給 AI」。

把它放回 Data Machi

目前 Data Machi 已經開始擁有兩種不同能力：一種是一般模型對話，另一種是文件 RAG。

使用者問題
    ↓
 ┌─────────────┬─────────────┐
 │ 一般問題    │ 文件問題    │
 │             │             │
 │ Gemini      │ PDF RAG     │
 └─────────────┴─────────────┘

目前這個選擇還可以透過固定流程或簡單規則處理。例如一般問題直接交給 Gemini，需要文件知識的問題則走 Document Tool。等後面加入 Sheets、Trello、Confluence 等更多工具之後，再讓 Coordinator 根據問題自主選擇應該使用哪一種工具。

注意：
不要在這個階段一次加入所有公司文件、Confluence、Google Sheets 與 Trello。先證明單一 Document Tool 能穩定找到正確資料與來源，後面進行跨來源整合時，才有辦法知道問題究竟發生在哪一層。

階段實作二｜建立第一份企業知識驗證集

Day 05 我們已經定義自己的企業 AI 問題，現在可以從那個情境中挑出一份最重要，而且能夠去識別化的文件。這一階段不要求你建立完整的企業知識庫，也不一定要從零實作所有 RAG 元件；真正要完成的是一份之後可以反覆使用的企業知識驗證集。

驗證 RAG 時，不要只確認「AI 有沒有回答」。真正需要驗證的是兩件事情：系統有沒有先找到正確證據，以及模型最後有沒有只根據這些證據回答。

可以先選一份自己熟悉、答案容易人工確認的文件，建立大約 10–20 題固定測試。第一版不需要追求題目數量，先涵蓋不同類型的查詢即可。

每一題至少需要記錄兩層結果。第一層是正確段落是否出現在前幾筆 Retrieval Results 中；第二層則是最後回答是否正確引用來源，而且沒有超出證據範圍。

可以使用下面這張表持續記錄：

之後不論調整 Chunking、Embedding、Top-k、Retriever 或 Prompt，都重新使用同一批測試題目跑一次。這樣才能比較修改前後的結果，而不是因為某一道題目剛好成功，就認為整套 RAG 已經變好了。

如果回答錯誤，也可以藉由這份驗證集快速區分：

答案錯誤
   ↓
正確 Chunk 有沒有被找到？
   ↓
 ┌──────────┬──────────┐
 │   沒有   │   有     │
 │          │          │
 │Retrieval │Generation│
 │ 問題     │ 問題     │
 └──────────┴──────────┘

這就是為什麼測試資料不只是開發階段的附屬品，而會逐漸成為企業 AI 持續改善的重要基礎。

階段成果：
保存四項內容：文件用途、固定測試題目、每題預期證據，以及文件沒有答案時的拒答條件。 Day 15 會把這份知識來源和另一個結構化或即時資料來源串成跨來源流程。

今天的重點：
Data Machi 第一次能根據「外部企業資料」回答，而不是只依賴模型原本知道的內容。真正完成 RAG 的標準，不是 AI 能回答，而是找得到正確證據、根據證據回答，而且能把來源交還給使用者。

下一篇，我們會碰到 RAG 的第一個能力邊界：如果主管問的是「昨天的實際數字」或「目前專案進度」，單靠文件搜尋就不夠了。

我們下集見囉！