前言

工具選好了，在動手寫程式之前，還缺一件最重要的事：**明確定義這次要做的 RAG 系統，究竟要解決什麼問題。**這一步常被跳過，但它決定了後面每一個技術決策（Chunking 策略、Metadata 設計、評估標準）的方向。

定義問題：從「使用情境」出發

好的 RAG 專案規劃，建議從以下幾個問題出發：

1. 使用者是誰？ 內部工程師？一般使用者？特定領域的專家？
2. 他們會問什麼樣的問題？ 事實查詢型（「XX 規定是什麼」）還是需要推理整合型（「比較 A 方案和 B 方案的差異」）？
3. 知識庫的資料型態是什麼？ 純文字文件、表格、程式碼、多語言內容？
4. 回答的正確性有多重要？ 容錯率高的閒聊機器人，還是不能出錯的法規/醫療問答？

這些問題的答案會直接影響後續設計，例如：如果使用者常問「比較型」問題，單純的 Top-K 檢索可能不夠，需要考慮多步驟檢索或是把多份文件都撈出來再彙整。

資料從哪來？

盤點資料來源時，建議列出一張清單：

（依實際專案填入你們實驗室會用到的資料來源）

訂出成功標準

在動手做之前，先寫下這次系統「怎樣算做得好」，之後 Day 21-26 做評估時才有明確的對照標準。例如：

• 針對測試問題集，回答的正確率達到多少百分比
• 檢索到的 Top-3 結果中，至少有一筆包含正確答案的比例（Context Recall）
• 平均回應時間控制在多少秒內

這次系列的專案定案

（以下為範例，請依你們實驗室實際情況替換）

本次系列將以「[你們實際的應用場景，例如：實驗室內部技術文件問答系統]」為目標，知識庫來源為 [文件類型]，希望使用者能透過自然語言提問，快速找到過去累積的技術文件與經驗記錄，取代目前「在群組裡問人 / 翻資料夾找檔案」的低效率方式。

小結

明確定義問題、盤點資料來源、訂出成功標準，是動手寫程式之前最容易被忽略、卻最關鍵的一步。有了清楚的目標，接下來的資料前處理、Chunking 策略、評估設計才有方向可循。明天開始，我們就要正式進入資料前處理的實作階段。