上一篇文章談到，RAG 的價值不只是讓 LLM 產生一段看起來合理的文字，而是讓回答能夠回到指定的知識來源。既然這個系列最後要完成一個 RAG 知識助理，今天就不能急著選模型或安裝向量資料庫，而是要先回答一個更基本的問題：我們究竟要讓這個助理解決什麼問題？

RAG 可以應用在客服、法律文件、醫療衛教、公司內規、產品手冊與個人筆記等許多情境。如果一開始只說「我要做一個可以回答問題的 AI」，範圍很快就會失去控制。不同資料來源有不同格式，不同使用者有不同期待，不同問題也需要不同的搜尋與回答策略。沒有明確的使用情境，最後很可能只完成一個能夠展示的聊天介面，卻無法判斷它是否真的有用。

因此，本系列要打造的不是通用聊天機器人，而是一個「繁體中文技術知識助理」。它的主要資料來源是結構相對清楚的 Markdown 技術文件與筆記，使用者則是想查詢技術概念、設定方式與實作差異的開發者或學習者。這個設定不代表系統只能回答程式設計問題，而是先選擇一個可以在 30 天內準備資料、反覆實驗並且清楚評估的範圍。

先定義使用者會問什麼

一個知識助理的設計，應該從使用者問題開始，而不是從模型名稱開始。對技術知識助理來說，使用者可能會問某個名詞是什麼、某個功能如何設定、兩種做法有什麼差異，也可能貼上一段錯誤訊息，想知道應該從哪裡排查。這些問題看起來都和技術有關，但搜尋時依賴的線索並不相同。

詢問概念的問題，通常需要找到定義與背景說明；詢問操作方式的問題，則需要找到步驟、設定範例或前置條件；比較型問題可能分散在不同文件中，需要同時取得多個來源；問題排查則可能必須依靠錯誤訊息中的專有名詞、版本與上下文。如果我們沒有先想過這些問題類型，後面很難設計一組有代表性的測試資料，也無法知道搜尋結果究竟是對所有問題都有幫助，還是只對某一種問題有效。

所以，這個系列會把問題分成幾種主要情境來思考：概念理解、操作查詢、技術比較與問題排查。這不是要建立一套非常複雜的分類模型，而是先讓我們在準備資料與評測時，有一個可以依循的方向。未來測試搜尋品質時，也可以觀察不同問題類型是否出現不同的失敗模式。

再定義知識庫要回答什麼

接著要決定的，是知識助理可以使用哪些資料。這個系列會以繁體中文 Markdown 技術文件與筆記作為主要資料來源，原因是 Markdown 同時保留了標題、段落、清單與程式碼區塊等結構，方便後續進行文字清理與文件切分，也比較容易在文章中說明資料是如何從原始文件走到搜尋結果的。

資料來源可以包含自己整理的技術筆記，以及具有適當使用條件的公開技術文件。這裡有一個重要原則：知識庫中的內容必須能夠被追溯。每一份文件都應該知道自己的標題、來源、主題與版本；如果資料來自外部，也要保留原始連結或授權資訊。RAG 的回答要有根據，前提是我們自己先清楚知道根據來自哪裡。

在第一版系統中，我們不會試圖把整個網際網路都放進知識庫，也不會讓系統即時搜尋所有網站。資料範圍會先集中在一批可控的繁體中文技術文件，讓每次搜尋結果都能被人工檢查。這樣做看似限制了功能，實際上卻能讓實驗更可靠，因為當回答出錯時，我們才有機會判斷問題是出在資料、搜尋、Prompt，還是模型本身。

這個助理應該如何回答？

明確定義問題之後，還需要先想像理想的回答形式。這個知識助理不是只要回傳一段文字，而是應該提供一個有結構的結果：先回答使用者的問題，再說明回答所根據的內容，最後列出引用來源。如果問題超出知識庫範圍，或搜尋到的內容不足以支持結論，系統應該明確說明資料不足，而不是用模型自己的推測補滿答案。

這個回答契約會影響後續許多設計。來源引用需要在文件切分時保留識別資訊，拒答判斷需要搜尋結果的相關程度，回答格式則會影響 Prompt 的寫法與最後的評測方式。換句話說，回答長什麼樣子不是最後才加上的介面功能，而是從專案一開始就要決定的系統需求。

我們也要接受一個事實：知識助理不可能回答所有問題。使用者可能詢問知識庫沒有收錄的主題，也可能要求模型做出文件沒有支持的推論。這些情況不代表系統失敗，真正重要的是系統能否辨識自己的資料邊界，並且用清楚的方式告訴使用者目前能確認到哪裡。

系統邊界同樣重要

為了讓 30 天的主線能夠完成，本系列會先把範圍限制在單一知識庫、單輪與基本多輪問答、繁體中文文字資料，以及可以透過來源引用檢查的技術問題。第一版不會加入即時網路搜尋、圖片理解、PDF OCR、複雜 Agent 工作流或自動執行使用者指令。

這些功能並不是不能做，而是它們會引入新的資料來源、權限、安全性與評測問題。例如即時搜尋需要處理網頁品質與內容變動，圖片理解需要加入多模態模型，Agent 則會涉及工具呼叫與任務規劃。如果現在就把所有能力放進來，文章很容易變成工具清單，卻失去 RAG 主線。

對這個系列而言，「先不做什麼」和「決定要做什麼」同樣重要。只有把邊界畫清楚，後面的實驗結果才有意義；只有固定資料與問題範圍，我們才有辦法比較不同搜尋方法到底改善了多少。

今天的決定

經過今天的整理，這個專案的目標可以被描述成一句話：建立一個以繁體中文 Markdown 技術文件為知識來源，能夠回答技術問題、引用相關段落，並在資料不足時拒答的 RAG 知識助理。

這句話同時包含了使用者、資料來源、核心功能與限制條件。後續每加入一個技術，都應該回頭確認它是否服務於這個目標，而不是因為某個工具很熱門就把它加入專案。接下來，我們會進一步討論 LLM 本身到底知道什麼，以及 Token、Context 與訓練資料如何限制模型的回答。