檢索增強生成（RAG）常以簡潔的示意圖介紹：
documents -> embeddings -> vector database -> LLM
Enter fullscreen mode Exit fullscreen mode
這是個有用的起點，但也可能讓其中一個元件看起來像整個系統。
良好的 RAG 資料庫設計必須涵蓋遠多於向量儲存的範疇。
一個正式上線的 RAG 應用可能還需要儲存原始文件、強制租戶邊界、精確比對產品名稱、依日期篩選、記錄對話、使過期內容失效、整合多個資料來源，並把最終提示詞控制在 token 預算內。
沒有任何資料庫僅靠儲存 embedding 就能成為「RAG 資料庫」。不同的資料庫模型各自解決檢索的不同面向。
本文探討關聯式資料庫、文件資料庫、快取、全文檢索引擎與向量資料庫在 RAG 中的角色，並討論一個單靠相似度難以表述的檢索問題：當應用程式知道中心點，卻不知道答案確切邊界時，如何找出有用的情境鄰域。
在實務 AI 應用案例中，此模式常見於客服、銷售效率 AI 工具、內部知識助理、AI 程式自動化，以及 AI Agent 開發。同樣的檢索問題也適用於使用內部資料開發 AI 助理，此時存取控制與來源新鮮度與生成答案同等重要。
RAG 的運作方式，以及與微調的差異
RAG 會在收到請求時即時檢索外部資訊，再把選定的證據放入模型的 context。微調則改變模型權重。因此，RAG 與微調的實務差異在於知識被引入的時機與位置。
RAG 通常更容易更新、引用、篩選或移除，因為知識留在模型之外。微調可改變行為、風格或學習到的模式，但無法方便地取代經常變動的文件儲存。
RAG 的主要優缺點源於此分離：RAG 可使用最新與私有來源而無需重新訓練模型，但也帶來資料擷取、檢索、權限、評估、延遲與運維工作。僅了解 AI 生成機制是不夠的：流暢的模型仍可能根據薄弱、過期或未經授權的證據作答。
資料庫類型與 RAG 的建置方式
更完整的 RAG 管線如下：
source data
-> ingestion and normalization
-> document and metadata storage
-> candidate selection
-> lexical or vector ranking
-> reranking and context assembly
-> LLM
-> answer and citations
Enter fullscreen mode Exit fullscreen mode
資料庫可參與多個階段。
| Responsibility | Typical data |
|---|---|
| Source of truth | Documents, records, revisions, users, permissions |
| Ingestion state | Jobs, checksums, parser versions, failures |
| Exact filtering | Tenant, category, status, language, date |
| Lexical retrieval | Keywords, names, identifiers, error codes |
| Semantic retrieval | Embeddings and similarity scores |
| Session state | Recent messages, selected sources, cached results |
| Context assembly | Related records, projections, token-bounded payloads |
單一資料庫可同時負責多項工作。小型應用程式不必因為表格有六列就建立六個資料庫。重點是在選擇儲存引擎前，先確認檢索工作。實用的資料庫比較應從這些工作出發，而非僅看功能清單。
團隊在研究如何建置 RAG 時，常從 embedding 模型或 RAG 向量資料庫開始。更安全的順序是先確認來源、存取規則、更新流程、精確篩選條件、候選檢索方法與評估計畫，再來才是向量索引。
為了讓差異更具體，我們以京都旅遊助理為例。它儲存地標、餐廳、文化設施、活動、交通、營業時間、預約與使用者行程等資訊。
PostgreSQL 與 MySQL：結構化真實來源與精確關聯
關聯式資料庫通常是存放 RAG 系統中權威應用狀態最直觀的地方。
對於旅遊助理，關聯式資料庫可儲存：
- 使用者與帳戶；
- 訂單與預約；
- 已儲存地點與行程；
- 租戶或組織邊界；
- 文件版本與擷取狀態；
- 權限與可見性規則；
- 結構化的營業時間與無障礙欄位。
當正確性取決於精確關聯時，SQL 特別有用。若私人行程屬於單一使用者，或文件不得跨越租戶邊界，此規則不應依賴 embedding 分數。
關聯式查詢可先選出允許的文件 ID，RAG 管線再對這些文件進行排序。
SELECT document_id
FROM travel_documents
WHERE city = 'Kyoto'
AND language = 'en'
AND published = true
AND valid_from <= CURRENT_TIMESTAMP
AND valid_until > CURRENT_TIMESTAMP;
Enter fullscreen mode Exit fullscreen mode
PostgreSQL 也支援 JSON、全文檢索與擴充功能。延伸模組 pgvector 可將向量與關聯式資料並存，對早期或中型 RAG 應用通常已足夠。
重點在於：新增向量欄位並不會消除設計權限、文件生命週期、中繼資料、候選選取與提示詞建構的需求。
MongoDB 與文件資料庫：彈性的內容記錄
當擷取的項目本身即為 JSON 物件，且不同項目類型有不同欄位時，文件資料庫是自然的選擇。
地標記錄可能包含歷史、圖片、座標與營業時間；餐廳可能有料理類型、價格範圍、預約規則與飲食選項；活動可能有開始時間、場地、票券網址與天氣政策。
{
"kind": "restaurant",
"name": "Example Cafe",
"area": "Higashiyama",
"cuisine": ["Japanese", "Cafe"],
"features": {
"indoor": true,
"vegetarianOptions": true
}
}
Enter fullscreen mode Exit fullscreen mode
MongoDB 文件 可 呈現此結構，而無需將所有項目類型強制放入相同欄位。中繼資料與來源文字可共存，巢狀欄位在已知存取模式時亦可建立索引。
然而，彈性並不消除檢索設計。應用程式仍需決定哪些集合、欄位、篩選條件與記錄應成為模型的候選項目。
傳統 RDB 與 NoSQL 的差異在此依然重要。關聯式系統以精確關聯與約束為核心；文件資料庫則以彈性記錄形狀與聚合導向存取為核心。針對商業系統，NoSQL 資料庫選型應考量一致性、授權、運維技能、備份與遷移，而非僅看輸入資料是否為 JSON。
Redis：短生命週期狀態與重複工作
即使 Redis 不是主要文件儲存，仍可在 RAG 架構中發揮作用。
常見用途包括：
- 對話工作階段狀態；
- 檢索結果快取；
- 速率限制；
- 短生命週期 Agent 狀態；
- 工作佇列；
- 去重鍵；
- 經常重複使用的 context 片段。
若多位使用者詢問相同景點的類似問題，快取已驗證的檢索結果可能比重新執行完整管線更省成本。
Redis 也支援持久化與多種資料結構，但快取仍需失效策略。旅遊資訊使此需求明顯：關於活動、臨時關閉或營業時間的答案可能變得錯誤，即使快取文字內部一致。
Redis 文件
將其描述為不只是簡單的鍵值快取，但在 RAG 架構中的角色仍應明確指定。
OpenSearch：文字、欄位與篩選仍很重要
Embedding 搜尋並非全文檢索的替代品。
使用者會搜尋精確地名、車次、產品代碼、法條、錯誤訊息與引號片語。模型可能為相關文字產生相似 embedding，但精確識別碼通常仍需精確比對。
OpenSearch 可結合：
- 全文查詢；
- BM25 式詞彙相關性；
- 欄位篩選；
- 聚合；
- 地理查詢；
- 向量搜尋；
- 搜尋導向的儀表板與運維工具。
對旅遊助理而言，它可回答如下問題：
Find pages containing "Kiyomizu-dera" in English,
published in the Kyoto corpus, with an opening-hours field updated this month.
Enter fullscreen mode Exit fullscreen mode
此查詢包含精確文字、中繼資料與新鮮度需求，這些訊號不應簡化為單一向量距離。
OpenSearch 文件
涵蓋詞彙與向量導向搜尋，當需要同時使用這兩種檢索模式時，可作為單一引擎選擇。
Qdrant 與向量資料庫：語義相似度
向量資料庫設計用來回答不同問題：
哪些已儲存項目在 embedding 空間中最接近此查詢？
當使用者與文件不使用相同詞彙時，這項功能很有價值。
例如，訪客可能問：
Where can I spend a quiet indoor afternoon learning about local history?
Enter fullscreen mode Exit fullscreen mode
有用的博物館描述可能不包含此確切句子，但語義檢索仍可將其納入候選集。
Qdrant 儲存向量與 payload 中繼資料，並支援帶篩選的相似度搜尋。典型請求會先限制合格項目，再依向量距離排序剩餘項目。
metadata filter
-> approximate nearest-neighbor search
-> top candidates
-> optional reranker
-> LLM context
Enter fullscreen mode Exit fullscreen mode
這是有效模式，但仍留下架構問題：應用程式如何在相似度排序前決定適當篩選條件與搜尋命名空間？
向量資料庫的相似度演算法、索引類型、篩選行為、記憶體使用與更新模式皆會影響結果。RAG 向量資料庫比較（Pinecone、Qdrant、pgvector 或 OpenSearch）應使用應用程式自身的語料與篩選條件。推薦向量資料庫清單無法取代工作負載專屬評估。
RAG 混合搜尋：BM25、向量與重排序
關鍵字與語義檢索互補。RAG 混合搜尋管線可結合 BM25 與向量分數，讓精確名稱與識別碼保持可見，同時仍能發現語義相關文件。
metadata and permission filters
-> BM25 lexical candidates
+ vector similarity candidates
-> merge and deduplicate
-> reranker
-> token-bounded context
Enter fullscreen mode Exit fullscreen mode
對 RAG 準確度提升而言，整合重排序器通常比單純增加第一階段結果數量更有用。重排序器可更仔細檢視小型候選集，而第一階段則維持高召回率最佳化。
RAG chunk size 最佳化技巧也很重要。小型區塊可提升比對精確度，但會失去周圍意義；大型區塊保留 context，但消耗更多 token 且可能稀釋相關性。正確的區塊大小取決於文件結構、檢索方法與必須引用的單位。
LangChain、LlamaIndex 等 RAG 框架可串接 loader、embedding、retriever 與模型。LangChain RAG 設定範例可展示接線方式，但框架無法為應用程式決定正確的授權邊界、新鮮度規則或候選範圍。
內部搜尋的開源 RAG 設定可結合 PostgreSQL、OpenSearch 或 Qdrant、本機模型與 orchestration 框架。自行託管會改變運維與隱私邊界，但無法免除相同的檢索與評估決策。
RAG 準確度提升與評估指標
檢索品質與答案品質應分開衡量。實用的 RAG 評估指標包括：
- recall 與 precision at
k； - mean reciprocal rank 或 nDCG；
- context relevance 與 context precision；
- groundedness 或 faithfulness；
- citation correctness；
- answer completeness；
- retrieved tokens、latency 與 cost per request。
Ragas 等工具可自動化部分評估，但沒有任何 RAG 評估工具或教學能為每項業務流程定義正確的預期答案。來自真實問題且經過審核的小型測試集仍然有價值。
RAG 幻覺防範措施應不只新增文件。更強的措施包括最新來源、明確引用、權限檢查、衝突偵測、拒絕作答選項，以及對知識庫中不存在答案的問題進行測試。
RAG 知識庫自動更新也需要版本控制與失效機制。管線應知道哪個來源修訂產生了區塊、何時必須重建 embedding，以及已刪除或過期的資訊如何離開快取與索引。
RAG 安全措施與實作成本
RAG 安全措施始於檢索之前。租戶隔離、來源授權、機密移除、加密、稽核軌跡，以及防範從檢索文件注入提示詞等，都應納入設計。即使資料庫被描述為 AI 元件，通用資料庫安全措施仍適用。
組織也可能需要使資料收集與使用符合隱私法規、產業義務、AI 法律規範，以及自身的 AI 倫理指南。檢索使資料可供模型使用，但不代表有權使用該資料。
完整的 RAG 成本比較應包含擷取、embedding 生成、資料庫儲存、快取、網路傳輸、重排序、LLM 輸入 token、監控、備份與工程時間。對小型企業而言，平均 AI 實作成本不能僅從模型 API 價格推斷。
RAG 成本降低與 token 節省與候選範圍密切相關。
減少不相關記錄通過檢索與重排序，可同時降低資料庫工作與 LLM 輸入。對於本機部署，本機 LLM 設定與 PC 需求是另一項容量決策，但較小的檢索 context 仍可降低下游記憶體與運算壓力。
許多 AI 實作失敗的原因是僅在少數成功問題上評估示範。實務 AI 實作效益會在系統也能處理過期資料、缺少答案、存取邊界、成本限制與失敗恢復時顯現。
困難的部分往往是候選範圍
考慮此問題：
我在清水寺。天在下雨，我有兩個小時。接下來該做什麼？
多種檢索方法皆可協助：
- 詞彙搜尋可找到提及清水寺的頁面；
- 地理搜尋可找到半徑範圍內的座標；
- 向量搜尋可找到語義相似的旅遊建議；
- SQL 可強制執行營業時間、權限與預約限制；
- 重排序器可重新排序結果候選集。
挑戰不在於任何一種方法不好，而在於決定哪些項目應進入候選集。
有用的答案可能需要：
- 附近地標；
- 室內博物館或藝廊；
- 目前營業中的餐廳；
- 今日舉辦的臨時活動；
- 交通資訊；
- 無障礙資訊；
- 使用者行程中已存在的地點。
應用程式知道中心：訪客、清水寺、當日與當前情境，但尚不知道有用答案的確切邊界。
語義相似度不等於運作相關性
語義最相似的文件不一定是目前請求最有用的文件。
一篇關於另一座日本寺廟的精美文章可能在 embedding 空間中接近，但無法在兩小時內使用。一則簡短的交通通知可能與旅遊問題在語義上相距甚遠，卻是答案的關鍵。餐廳記錄可能幾乎不含使用者請求中的任何詞彙，但因鄰近、營業中且符合行程而相關。
RAG 系統通常以中繼資料篩選來處理此問題：
{
"city": "Kyoto",
"area": "Higashiyama",
"openNow": true,
"weather": "rain",
"categories": ["restaurant", "museum", "landmark"]
}
Enter fullscreen mode Exit fullscreen mode
這是合理的。但隨著產品成長，篩選條件會成為應用層級的檢索計畫。必須有人維護規則、命名空間、join 與 fan-out 讀取，以便為每次請求重建 context。
地理距離也不是完整的邊界
若問題只是「一公里內有什麼？」，PostGIS 或 OpenSearch 地理搜尋等地理索引是直接解法。
然而，有用的旅遊 context 並非總是圓形。
- 河流、山丘或鐵路可能使兩個近點實際不便到達；
- 下雨會改變哪些設施有用；
- 家庭與單獨旅行者可能需要不同的鄰域；
- 營業時間與活動日期會改變可用 context；
- 「雨天京都」等編輯分組並非地理區域；
- 同一個地點可同時屬於區域指南、車站指南與個人行程。
距離仍是重要訊號，但它不是定義視野的唯一關係。
應用程式不斷重建 context
傳統堆疊可解決此問題。它可能使用 SQL join、地理索引、搜尋篩選、圖形、應用程式維護的 ID 清單與向量排序。
重複的工作是重建相同的 locality：
start from the current place
-> identify the area
-> find allowed categories
-> join today's events
-> add relevant transit
-> add itinerary items
-> build candidates
-> rank candidates
Enter fullscreen mode Exit fullscreen mode
這裡缺少的運算不是另一個評分演算法，而是可重複回答此先前問題的方式：
對於此類請求，哪些項目應屬於此已知中心的鄰域？
將可重複使用的鄰域視為資料
一種設計選項是儲存該鄰域，而非每次請求都從頭重建。
這不一定需要新資料庫。應用程式可用 SQL 關聯表、圖形邊、實體化檢視、搜尋文件或維護的 ID 清單來建模此關係。重要的概念改變是：候選範圍成為有自己生命週期的資料，而非在排序前臨時組裝的查詢邏輯。
對旅遊範例而言，可重複使用的鄰域需要幾項屬性：
- 每個地點應保留一條標準記錄；
- 同一個地點可出現在多個 context 中；
- 將地點加入指南時不應複製其 payload；
- 讀取應受類別、深度、篩選、限制與 token 成本約束；
- 在選定鄰域後，仍可使用詞彙或向量排序。
若此關係偶爾出現，應用程式程式碼可能已足夠。若相同模式跨越使用者、地點、專案、產品或時間視窗出現，則將 locality 做為一級檢索原語可能有用。
KoutenDB 如何表述此檢索模式
KoutenDB 是專為此模式設計的資料庫之一。它使用類座標的 ring 放置標準記錄，並使用 stellar 可見性透鏡在這些座標上建立可重複使用的視圖。
匯入程式或應用程式可將旅遊資料保留在標準 ring 中：
landmarks/kyoto/kiyomizudera
landmarks/kyoto/yasaka-pagoda
restaurants/kyoto/gion
culture/kyoto/national-museum
events/kyoto/2026-07-23
transit/kyoto/higashiyama
Enter fullscreen mode Exit fullscreen mode
接著可將有用的座標附加到以區域為中心的視圖：
kouten stellar attach \
--stellar=travel/kyoto/higashiyama \
--ring=landmarks/kyoto/kiyomizudera
kouten stellar attach \
--stellar=travel/kyoto/higashiyama \
--ring=restaurants/kyoto/gion
kouten stellar attach \
--stellar=travel/kyoto/higashiyama \
--ring=culture/kyoto/national-museum
kouten stellar attach \
--stellar=travel/kyoto/higashiyama \
--ring=events/kyoto/2026-07-23
Enter fullscreen mode Exit fullscreen mode
應用程式可從已知中心讀取周邊 context：
kouten get --stellar=travel/kyoto/higashiyama
Enter fullscreen mode Exit fullscreen mode
或將相同視野限縮至單一類別：
kouten get --stellar=travel/kyoto/higashiyama --subring=restaurants
kouten get --stellar=travel/kyoto/higashiyama --subring=culture
Enter fullscreen mode Exit fullscreen mode
同一家餐廳也可從雨天指南、車站中心指南或使用者行程中可見，而無需複製其標準 payload。
KoutenDB 不會從路徑名稱推斷地理或編輯相關性。
應用程式、匯入程式或策展流程仍需決定哪些座標屬於每個鄰域。資料庫保留此決策，讓後續讀取無需從頭重建。
這不只是路徑前綴
ring 名稱刻意設計成可讀路徑。當父子資料自然屬於一起時，階層結構很有用。
然而，單一路徑前綴只代表一棵樹。真實記錄會同時參與多個視圖：
canonical catalog: restaurants/kyoto/gion/example-cafe
area guide: travel/kyoto/higashiyama
weather guide: travel/kyoto/rainy-day
personal plan: travel/users/123/today
Enter fullscreen mode Exit fullscreen mode
在每個路徑下複製餐廳會產生同步工作。將其移至單一路徑會削弱其他視圖。stellar 透鏡則在現有座標間儲存可見性關係。
呼叫者提供中心與成本邊界。深度、分支預算、subring、篩選、投影、排序與限制控制回傳多少 context。呼叫者無需列舉答案中的每一筆記錄。
Locality 可先於向量排序
Locality-aware 檢索與向量搜尋並非互斥。
組合管線可如下：
known center: user + place + time
-> retrieve the configured local neighborhood
-> apply current constraints
-> vector-rank the smaller candidate set if needed
-> rerank and enforce a token budget
-> LLM
Enter fullscreen mode Exit fullscreen mode
向量資料庫詢問哪些候選在語義上接近；locality 層則詢問應先考慮資料的哪一部分。
這可減少載入的 payload 數量、比較的向量、重新排序的記錄、傳輸的位元組，以及下游考慮的 token。它不保證每次查詢都更快。只有當應用程式能表達有意義的 locality 時，此模型才有價值。
依檢索問題選擇資料庫
當從問題而非當前 RAG 趨勢出發時，資料庫決策會更清楚。
| Retrieval question | Natural starting point |
|---|---|
| Which exact record or relationship is valid? | Relational query and indexes |
| Which JSON documents match known fields? | Document database or SQL/JSON |
| Which result can be reused briefly? | Cache or session store |
| Which documents contain these words? | Full-text search engine |
| Which documents are semantically similar? | Vector search |
| Which places are inside a literal radius? | Geographic index |
| Which context is useful around this known user, place, project, or time? | Locality-aware neighborhood retrieval |
這些不是互斥選擇。PostgreSQL 可維持真實來源，而 OpenSearch 處理詞彙檢索。向量資料庫可對語義相似的區塊排序。KoutenDB 可作為 locality-aware 文件與檢索儲存，或作為較早的候選選取階段。
較小的系統可選擇涵蓋足夠角色的單一資料庫；較大的系統可將它們分開。只有在移除可衡量的檢索、正確性或運維問題時，才有理由增加額外基礎設施。
因此，RAG 的實務資料庫設計步驟如下：
- 確認權威來源與更新負責人；
- 定義租戶、使用者與文件存取邊界；
- 列出精確、詞彙、語義、地理與 locality-aware 查詢；
- 選擇涵蓋這些查詢的最小資料庫類型集合；
- 衡量檢索品質、token、延遲與失敗案例；
- 記錄無法重建之資料的資料庫備份方法與遷移步驟；
- 僅在候選與存取模型正確後，再進行資料庫效能調校。
最終問題是應用程式已經知道什麼
RAG 架構常從詢問要使用哪個 embedding 模型或向量資料庫開始。
另一個有用的問題應更早提出：
在檢索開始前，應用程式已經知道什麼？
它可能已經知道已驗證的使用者、租戶、訂單、專案、文件群組、當前地點、時間視窗或進行中的任務。這些資訊可定義比完整語料庫更小且更相關的起始區域。
若請求在沒有有意義中心的情況下開始，全域詞彙或向量搜尋可能正是正確選擇。若請求從已知中心開始，但 context 邊界不明確，保留 locality 可在排序與提示詞建構前將檢索問題保持在較小範圍。
重要的選擇不是 SQL 對向量，或某個資料庫產品對另一個產品，而是決定應用程式需要精確真實來源、詞彙比對、語義相似度、地理鄰近性，還是可重複使用的 context 鄰域，然後為每個檢索階段提供它真正需要的資料模型。
這才是能超越示範的 RAG 資料庫設計基礎。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.