RAG 管線有三個階段：索引、檢索和生成。在索引階段，你將文件 —— PDF、網頁、資料庫記錄等 —— 分割成片段，將每個片段通過 embedding 模型得到一個向量，然後將這些向量儲存在 Qdrant、Pinecone 或 Weaviate 等向量資料庫中。在檢索階段，用戶的查詢用同一個模型進行 embedding，向量資料庫返回前 k 個最相似的片段（通常 3 到 10 個）。在生成階段，這些片段作為上下文塞入模型的提示中，模型基於這些材料生成回應。整個流程 —— 對查詢進行 embedding、搜尋、組裝提示、生成 —— 通常需要 1 到 3 秒。
分片是大多數 RAG 系統成敗的關鍵，而且比看起來更加微妙。片段切得太小會丟失上下文；太大則會在寶貴的上下文視窗中浪費空間在不相關的文字上。一個常見的起點是每片 500 到 1000 個 token，相鄰片段之間有 10-20% 的重疊（避免跨越邊界的資訊丟失）。但簡單的固定大小分片常常把句子切成兩半或把標題與其內容分開。更精密的方法利用文件結構 —— 按標題、段落分隔或語意轉換來分片 —— 以創建自成一體且有意義的片段。LangChain 的 RecursiveCharacterTextSplitter 和 LlamaIndex 的 SentenceSplitter 都試圖處理這個問題，但最佳結果通常來自理解你的特定文件並編寫自訂的分片邏輯。
檢索步驟的選項比人們認知的多。純向量相似度搜尋（在 embedding 空間中的最近鄰查找）是預設選項，但在精確的關鍵字匹配、專有名詞和程式碼標識符上表現不佳。這就是為什麼混合搜尋已成為生產系統的標準：你同時運行向量搜尋和傳統的關鍵字搜尋（BM25），然後用倒數排名融合或學習型重排器合併結果。Qdrant、Weaviate 和 Elasticsearch 都原生支援混合搜尋。重排 —— 從檢索結果中取前 20 到 50 個，用交叉編碼器模型重新評分 —— 會增加延遲但顯著提升相關性。Cohere Rerank 和 Hugging Face 的交叉編碼器模型是常見選擇。
一個常見的誤解是 RAG 可以消除幻覺。它能顯著減少幻覺，但模型仍然可以編造不在檢索到的片段中的細節，特別是當片段只是與查詢沾邊相關而非直接回答時。好的 RAG 系統透過以下方式緩解這個問題：在提示指令中加入來源引用（「只根據提供的上下文回答，引用你的來源」）；過濾掉低相關性的片段（設定最低相似度門檻而非總是返回 top-k）；以及讓模型在檢索到的上下文真的無法回答問題時說「我沒有足夠的資訊」。一些團隊會加入驗證步驟，用第二次模型呼叫檢查回應是否真的有來源支撐。
RAG 最初在 2020 年由 Facebook AI Research（現 Meta AI）的論文中提出，但直到 2023 年向量資料庫和 embedding API 成熟到足以使其實用時，它才成為主流生產模式。此後這個模式朝幾個方向演進：GraphRAG 使用知識圖譜替代（或搭配）向量搜尋，更好地處理關係型問題。代理型 RAG 賦予模型重新組織查詢、搜尋多個來源並迭代檢索的能力，而非只做單次搜尋。而上下文視窗的擴展 —— 模型現在可以處理超過 10 萬 token —— 已使一些團隊對較小的知識庫完全跳過 RAG，直接把所有內容塞進提示。這種方法對幾百頁的文件有效，但在更大規模時就會失效 —— 這正是 RAG 仍然不可或缺的地方。