前言

30 天的旅程走到了最後一天。從第一天談「為什麼需要 RAG」開始，到今天，我們一起走過了一套 RAG 系統從零到落地的完整過程。今天做一次系統性的回顧，也談談接下來還可以往哪些方向繼續深入。

完整旅程回顧

第一階段：基礎與規劃（Day 1-4）

從 LLM 幻覺問題出發，理解 RAG 為什麼是比微調、硬塞 Prompt 更好的解法，並確立了這次系列的技術選型與專案目標。

第二階段：資料前處理（Day 5-9）

處理各種格式的原始文件，比較不同 Chunking 策略、探討 Chunk Size 與 Overlap 的取捨、設計 Metadata，最後整合成自動化 Pipeline。

第三階段：Embedding 與向量資料庫（Day 10-14）

介紹 Embedding 模型選型、向量資料庫比較、相似度搜尋的數學原理，並實作出第一個能查詢的向量資料庫。

第四階段：檢索優化（Day 15-20）

從 Top-K 檢索的侷限出發，逐一補上 Hybrid Search、Rerank、Query Rewriting/HyDE、多輪對話處理、長文件與多文件交叉引用等進階技巧。

第五階段：生成與評估（Day 21-26）

探討 Prompt 設計原則、常見的生成問題（幻覺、答非所問、引用錯誤），並建立起 RAGAS 自動化評估流程與錯誤案例分析機制。

第六階段：落地部署（Day 27-30）

把系統整合成 API 服務、串接前端，處理效能與成本優化，建立監控與維運機制，最後完成今天的總結。

這 30 天最大的收穫

如果要用一句話總結這趟旅程，會是：RAG 系統的品質，不是取決於單一個「最強的技巧」，而是取決於每個環節（Chunking、Embedding、檢索、生成、評估）是否都被認真對待，並且透過持續的評估與迭代不斷改進。

沒有一種 Chunking 策略、Embedding 模型或 Prompt 設計是萬用的最佳解，真正重要的是：

1. 建立量化評估的能力，讓每次優化都有明確依據
2. 建立分析錯誤案例的習慣，找出真正的問題根因
3. 持續迭代，而不是期待一次到位

還可以繼續深入的方向

這個系列涵蓋了 RAG 的核心環節，但這個領域還有許多值得繼續探索的方向：

• Agentic RAG：讓系統能自主決定要不要檢索、要檢索幾次、要不要用其他工具輔助（如搜尋引擎、計算機）
• 多模態 RAG：處理圖片、表格、圖表等非純文字內容的檢索與理解
• GraphRAG：利用知識圖譜結構，處理需要多步推理、實體關聯的複雜問題
• 細粒度的權限控管：企業應用中，不同使用者可能只能查詢特定範圍的知識庫內容
• 持續學習機制：如何讓系統從使用者回饋中自動學習、優化檢索與生成品質

給同樣想踏入 RAG 領域的你

如果你也對 RAG 有興趣，建議從一個小而明確的專案開始，親自走過從 Chunking 到評估的完整流程——理論看再多次，都不如實際跑一次、看到真實的檢索結果與生成品質，來得有體感。

感謝這 30 天願意跟著閱讀這個系列的每一位讀者，我們下次再見！

系列文章索引：

• Day 1-4：RAG 基礎與環境準備
• Day 5-9：資料前處理
• Day 10-14：Embedding 與向量資料庫
• Day 15-20：檢索優化
• Day 21-26：生成與評估
• Day 27-30：落地部署與總結