Retrieval Augmented Generation（檢索增強生成，RAG）
模型會產生一個答案，而這個答案會透過從文件集合中檢索到的資訊來加以增強。
即使大型語言模型（LLM）的上下文視窗（Context Window）足夠大，將海量資料一次全部塞進模型，依然容易讓模型產生混亂或注意力分散。此外，如果原始文件中包含寫作品質不佳或互相矛盾的觀點，也會直接影響最終輸出的品質。
因此，我們需要將龐大的文字拆分成較小的區塊（Chunk）。
拆分Chunk並沒有唯一的最佳解，常見的做法包含：
- 字數/Token 切割：固定每區塊的字元數或token數。
- 語意/結構切割： 按照單字、段落，甚至文件的章節結構來進行切分。
語意導航的關鍵：Embedding（嵌入）
文本切碎後，下一步是根據使用者的提問（Prompt）找出最相關的 Chunk。這正是 Embedding 發揮作用的地方。
Embedding 是文字的「語意數值化表示方式」。我們會將Chunk送入專門的 Embedding Model（通常容量較小、執行速度極快），讓模型分析語意，並將其轉化為高維度空間中的向量（由一連串浮點數組成的陣列）。
關於 Embedding 的核心特性：
- 固定維度： 不論輸入的是兩三個字的短語，還是 800 字的文章，經由同一個模型處理後，產生的向量長度都完全相同（例如 Nomic Embed Text 固定產生 768 維度的向量）。
- 向量比較： 只要向量長度相同，就能透過數學演算法（如餘弦相似度）輕鬆計算它們之間的語意距離，找出與使用者問題最接近的文本區塊。
- 模型不可混用： 不同模型產生的向量長度與空間定義不同，不同長度的向量無法直接比較。一旦更換 Embedding Model，系統內所有歷史資料都必須重新進行 Embedding。
資料的落腳處：Vector Database（向量資料庫）
當 Chunk 數量成長到數千甚至數百萬個時，單純儲存在本機 JSON 檔或獨立文字檔會遇到嚴重的擴充性與查詢效率問題。這時就需要使用 Vector Database（向量資料庫），例如 Chroma、Milvus，或支援向量擴充的關聯式資料庫（如 PostgreSQL的pgvector）。
對於每一個 Chunk，資料庫必須同時儲存兩樣東西：
- Embedding（向量）： 用於快速進行語意相似度檢索。
- 原始文字內容： 用於後續組合進 Prompt 提供給 LLM。
理論上某些技術可以嘗試從向量還原文字，但直接將原始文字與向量一起儲存，在實際應用上效率高出許多。
RAG 的完整運作流程
RAG（Retrieval-Augmented Generation，檢索增強生成）的核心目標非常純粹：找到與問題最相關的文字區塊，補充進 Prompt 中，讓模型擁有它原本不知道的背景資訊。
【前期準備（建立索引）】 原始文件 → 拆分為 Chunk → 計算向量 Embedding → 存入 Vector Database（包含向量與原始文字）
【即時查詢（使用者提問時）】
- 問題向量化：對使用者的Query建立 Embedding。
- 向量比對：將 Query 的向量與資料庫中的向量進行比對。
- 篩選 Top-K：找出相似度排名最高的前 5 或 10 個最相關向量。
- 提取原文：取得這些向量所對應的原始文字 Chunk。
- 組合 Prompt： 加入指示詞（例如：「請參考以下資訊回答問題：…」），並附上提取出的文字內容。
- 模型生成： 將這個包含豐富上下文的完整 Prompt 傳送給 LLM 產生最終回答。
RAG可以解決AI幻覺，建立企業私有知識庫和降本增效與資料權限控管。下篇會講解如何Ollama結合RAG應用(PageAssist和AnythingLLM)。