Skip to main content
前四天我們已經拆解檢索增強生成（RAG）的原理：文件需要先解析、切割、向量化，再透過搜尋把真正相關的內容交給模型。今天不再停留在概念，而是把這條流程真正接起來。 這一天的目標不是做出「完整企業知識庫」，而是先完成一條最小、可驗證的路徑：前端提出問題 → 後端收到問題 → 文件工具找出相關段落 → Gemini 根據段落回答 → 回傳來源。 只要這條路徑成立，後續才有資格談更進階的搜尋策略與代理（Agent）。

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

Data Machi 使用模型來理解問題與組織回答，因此需要先準備 Gemini API。取得 API 金鑰（API Key）之後，不要直接寫進程式碼，而是放進本機環境變數，例如 .env。程式啟動時再從環境讀取。
這個習慣看起來只是安全問題，其實也和部署有關。本機用 .env，未來部署到 Render 時則改放在平台的環境變數（Environment Variables）。程式碼本身不需要跟著環境改來改去。 實際申請時，先登入 Google AI Studio 找到 API Key 管理入口，選擇或建立一個 Google Cloud Project，再於該 Project 底下建立 Gemini API Key。Key 建立完成後通常只會完整顯示一次，記得立即複製到密碼管理工具，不要貼進聊天視窗、文件或 GitHub。接著在 backend/.env 填入：
Data Machi 採用雙模型思路：主要模型負責使用者看得到的最終回答，快速模型負責分類、釐清與查核等內部步驟。第一版可以先只設定一個模型，等主流程成功後再拆分工。這裡也要特別記住：Gemini Key 屬於 Secret，只能放在後端（本機 .env 或 Render Environment），不能放進 Vercel 前端——瀏覽器使用者有機會從網路請求或 JavaScript Bundle 中把它挖出來。正確流程永遠是前端呼叫 Render，Render 再用 Key 呼叫 Gemini。 取得金鑰後，第一個測試先不要碰 RAG，而是完成一個最小可行流程：前端送出訊息 → 後端呼叫 /chat → Gemini 回答 → 顯示在畫面上。 這一步只驗證主幹是否打通，先不加入 Sheets、RAG、Trello 或對話記憶，因為如果一次串接五個工具才發生錯誤，會很難判斷問題出在前端、後端、模型、資料權限還是路由。可以先送出一句不需要外部資料的問題，例如「請用三句話說明你能協助處理哪些工作」，確認：
  1. 前端顯示送出中或處理中。
  2. 後端 Terminal 收到 /chat 請求。
  3. Gemini 回傳內容。
  4. 前端顯示完整回答，而且錯誤時不會永遠停在 Loading。
常見的卡關點可以先對照這張表快速定位： 主幹確認穩定之後，才進入下面的文件檢索流程。

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

實作初期不要直接丟幾百份公司 PDF。先選一份內容你自己很熟、答案容易驗證，而且不包含敏感資訊的文件。最好包含幾個明確的規則、定義或段落，方便測試檢索器（Retriever）是否真的找到正確內容。 如果文件是文字型 PDF，可以直接進入解析流程；如果是掃描件，則要先經過 Day 09 提到的光學字元辨識（OCR）或視覺處理。這也是為什麼實作時最好先從乾淨文件開始，先確認 RAG 主幹沒有問題，再逐步處理複雜格式。 不要直接拿內部文件測試。比較好的做法是自己寫一份 3–5 頁的匿名測試 PDF，內含清楚的標題、幾個小節、一張簡單表格、明確的日期與定義，並刻意留一段文件完全沒有提到的資訊，用來測試系統會不會誠實拒答。

​
第三步：建立索引，而不是把整份 PDF 塞進提示詞

文件進入系統後，會經歷幾個步驟：解析出文字、依合理大小切成文件片段（Chunk）、產生向量表示（Embedding），再存進可搜尋的索引（Index）。這一層的目的不是讓模型「記住文件」，而是讓系統未來收到問題時，可以快速找到最相關的片段。 文件片段不宜過大，也不宜切得太碎。太大會把很多無關內容一起送給模型；太碎則可能把定義與上下文拆開。實作時最重要的不是追求一開始就找到「最佳參數」，而是保留可調整的空間，並用實際問題驗證搜尋結果。

​
第四步：先看檢索結果，再看模型回答

RAG 最容易踩的坑，是只看最後的生成答案。模型很會說話，即使檢索器找錯段落，也可能產生看似合理的回答。因此測試時應該拆成兩層。 第一層先輸入問題，只看系統找回了哪些文件片段。確認真正相關的段落是否出現在前幾名。第二層才把這些片段交給 Gemini，要求模型只能根據提供的上下文（Context）回答。 例如文件中明確寫著某項規則，你可以分別測試「直接問規則」、「換一種說法問同一件事」、「問一個文件沒有答案的問題」。第三種尤其重要：當文件找不到答案時，系統應該說明資料不足，而不是自行補完。

​
第五步：讓答案保留來源

企業情境中的 RAG，如果只有漂亮答案但不知道出自哪裡，可信度仍然有限。因此文件工具（Document Tool）的輸出最好同時包含答案所使用的文件名稱、頁面與片段來源資訊（Metadata）。
每個文件片段（Chunk）至少應保留檔名、頁碼、章節標題、Chunk ID 與相似度排序，這樣使用者才有辦法把回答對回原始頁面，而不是只能選擇相信模型。如果索引資料量比較大，也不一定要在後端一啟動時就全部載入——可以採用 Lazy Initialization，第一次真的有人查文件時才建立或載入索引快取，降低啟動時間；只是第一次查詢會比較慢，前端最好顯示「正在準備文件索引」而不是無限轉圈。 到這裡，我們才真正完成第一個可驗證的 RAG，而不只是「把 PDF 丟給 AI」。

​
把它放回 Data Machi

目前 Data Machi 已經有兩條能力：一般模型對話，以及文件 RAG。使用者問通用問題時可以直接交給模型；問企業文件時則走文件工具。現階段這個選擇還可以是固定流程，等到後面加入更多工具後，再交給協調者（Coordinator）自己決定。
不要在這個階段一次加入所有公司文件、Confluence、Google Sheets 與 Trello。先證明單一文件工具能穩定取得正確來源，才有辦法知道後面跨來源出錯時是哪一層的問題。

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

回到 Day 05 定義的企業問題，先挑出其中一份最重要、內容可去識別化的文件。這一階段不要求你建立完整知識庫；你可以手動檢查、使用現成文件工具，或自行實作 RAG。真正要完成的是一份之後能反覆使用的驗證集。 不要只確認「AI 有回答」。真正要驗證的是兩件事：系統有沒有先找到正確證據，以及模型有沒有只根據證據回答。 可以先用一份你熟悉、答案容易人工確認的文件，建立 10–20 題固定測試。第一版不需要很多，先涵蓋下面幾種情境即可。 每一題至少記錄兩層結果：第一層是正確段落是否出現在前幾筆檢索結果中；第二層是最後回答是否正確引用來源，而且沒有超出證據範圍。這樣當答案錯誤時，才能分辨問題出在「沒找到資料」，還是「找到資料後回答錯」。 可以用下面這張小表持續累積： 之後調整文件切割、向量化、取回筆數或提示詞時，都用同一批題目重跑一次。這樣才知道修改後是真的變好，而不是剛好某一題成功。
保存四項成果：文件用途、固定測試題目、每題預期證據，以及文件沒有答案時的拒答條件。Day 15 會把這份知識來源和另一個結構化或即時資料來源串成跨來源流程。
今天完成的里程碑是：Data Machi 第一次能根據「外部企業資料」回答，而不是只依賴模型原本知道的內容。
下一篇我們會碰到 RAG 的第一個能力邊界：如果主管問的是「昨天的實際數字」或「目前專案進度」，文件搜尋就不夠了。