經過前九天的硬核基礎，我們成功從「如何跟 AI 說話 (Prompt)」一路走到了「如何讓 AI 看我們的專屬文件 (RAG)」。在進入下一階段的視覺化開發前，今天是我們沉澱觀念的里程碑。

回顧 RAG (檢索增強生成) 的本質，它其實是一個精密的資料處理管線 (Data Pipeline)：

切塊 (Chunking)： 將龐大文件切分為有邏輯的片段。

向量化 (Embedding)： 將文字片段轉換為數學座標。

檢索 (Retrieval)： 透過 Faiss 等向量庫找出距離問題最接近的段落。

生成 (Generation)： 將找出的段落作為 Context，限制模型只能根據這些線索回答。

在親手寫過這些底層邏輯後，為了避免未來在實作複雜系統時踩坑，這裡總結三個工程師在導入 RAG 時最常遇到的盲點：

1. Garbage In, Garbage Out (資料清理決定了 80% 的成敗)
很多人以為有了強大的 Embedding 模型，隨便丟入排版混亂的 PDF 也能精準問答。事實上，如果文本解析時包含了無意義的頁首頁尾、錯位的表格，或者 Chunking 策略把關鍵句切斷了，向量搜尋出來的結果就是一團亂。AI 永遠無法從錯誤的檢索結果中生成正確答案。

2. 相似度高，不代表包含「答案」
向量檢索計算的是「語意相似度」。當使用者問「系統無法登入怎麼辦？」，檢索出來的第一名可能是一段同樣在抱怨「系統無法登入」的使用者回饋紀錄，而不是藏在十名之外的「系統除錯手冊」。因此，實務上常需要搭配關鍵字搜尋 (Keyword Search) 進行混合檢索 (Hybrid Search)，來彌補純向量搜尋的缺陷。

3. 權限與資料隱私邊界
在企業級開發或處理具有機敏性（例如帶有個人識別特徵）的資料時，RAG 架構是將內部資料外送給大模型 API 的最後一關。必須在組裝 Prompt 之前，確保檢索出的 Chunk 沒有越權撈取使用者不該看到的機密，這是在架構設計初期就必須建立的資安防護網。

走到這裡，你已經具備了 AI Engineering 的底層心法。但如果每一個專案都要從頭手刻這些切塊、檢索與組裝 Prompt 的程式碼，開發效率實在太低了。

隨著架構越來越複雜，我們需要更現代化的武器。明天 [Day 11]，我們將正式跨入第三階段：解放生產力！Dify 與 n8n 的 Low-code Agent 開發宇宙，見證如何用拖曳節點的方式，把這十天的觀念化為視覺化的工作流！