小編精選 - 技術文章翻譯 · 08月12日

如何避免 RAG 用過時資訊作答？從「Converged」資料庫思考 AI 時代的資料基礎架構

前言

生成式 AI 或 AI 代理的活用，往往也會連帶牽涉到資料庫端的議題：AI 要參照的資料要怎麼保存。
是把不同形態的資料——關聯式、文件、向量——分別放到各自擅長的專用資料庫裡，還是統一收納到一個資料庫中？
本文所談的融合式資料庫（converged database），就是指這種「統一保存」的做法。

本文以 Oracle Developers 部落格的 What Is a Converged Database? Definition, Five Tests, and AI Use Cases（Rick Houlihan，2026 年 6 月）為基礎，整理這個詞「融合式資料庫（converged database）」究竟指什麼，以及為什麼它常和 RAG、AI 代理一起被提起。

本文定位：本文是依據上述 Oracle 部落格內容，加入筆者自己的理解重新整理並補充而成。並非 Oracle 官方立場。

融合式資料庫是什麼

資料庫處理的資料，不只有表格那樣的結構，也有許多不同的「形態（資料型態／模型）」。
先從實例來看，為什麼在 AI 活用的脈絡下會出現這個詞。

假設有一個小型電商網站。
即使不是專門為 AI 設計的系統，當你開始思考業務資料與 AI 應用時，通常也會發現一般情境下就已經會出現各種不同形態的資料。

訂單／明細 — 以金額與庫存為主，需用嚴格結構與約束來處理的表格資料（關聯式）
客戶個人檔案 — 每個人欄位不一樣的巢狀 JSON（文件）
詐欺偵測 — 像是「多個帳號共用同一裝置」這類可追蹤關係的圖資料
客服工單相似搜尋 — 以語意相近程度找出「和這個工單相似的過往案件」的向量搜尋
附近門市 — 依緯度、經度計算的空間（Spatial）資料

這類資料的保存方式，通常會依模型分成對應的專用資料庫。
例如文件資料用 MongoDB、圖資料用 Neo4j、向量資料用 Pinecone，各自以專門的服務或儲存系統來分開處理。
相對地，把這些資料統一收納到一個資料庫引擎中，就是所謂的融合式（converged）。

將原文的定義翻成中文，大致如下：

由單一資料庫引擎原生支援多種資料模型，例如關聯式、文件（JSON）、圖、向量、空間、文字，並且它們共享同一個最佳化器、同一個交易邊界、同一個一致性模型、同一個安全與治理領域，且能透過開發者預期的存取方式來使用，例如 SQL、文件 API、REST。

這段定義很長，但原文本身也說，重點不是列出哪些模型，而是後面那一串特性。
不過只看這個定義還是不太直觀，所以接下來會從詞源與背景開始一步步說明。

詞彙的產生經緯

Oracle 大約在 2020 年前後開始使用 融合式資料庫（Converged Database） 這個詞。
最初的定義，是 Maria Colgan 所說的「單一引擎原生支援所有現代資料型態與開發典範」。（M. Colgan, “What is a Converged Database?,” 2020）
也就是說，把多個系統整併成比較少的系統（最好是一個），就能減少授權數量、備份數量，以及系統間串接的麻煩，這本質上是一種便利性上的說法。當時的「converged」主要是在講consolidation（整併）。

但在那之後，經過以下三個變化，這個詞的意義逐漸改變。
原本只是「整併起來比較方便」的說法，逐漸變成「是否融合在一起，會直接決定能做什麼、不能做什麼」的結構性特質。以下依序來看。

變化 1：SQL 標準的演進

首先是 SQL 標準本身的進化。

過去像「JSON 用 MongoDB、圖資料用 Neo4j」那樣，必須仰賴針對特定模型設計的專用資料庫。
改變這個局面的，是 SQL 標準的演進。原本只有專用 DB 才擅長的功能，逐漸變成一般 SQL 語法的一部分。

SQL:2016 — 語言中加入 JSON 運算子
SQL:2023 — 新增原生 JSON 型別，並以新章節（ISO/IEC 9075-16、SQL/PGQ）把圖的模式比對納入標準 SQL 1

此外，以圖來追蹤關係的處理（圖探索），也不再只是獨立資料庫類別的能力，而是可以寫在 FROM 子句中的一種語法。
當這些都能作為標準 SQL 的一部分來使用時，為了這些功能再把資料庫拆開的技術理由就變弱了。

變化 2：AI 工作負載的出現

第二個變化，是 AI 工作負載的出現，使得同步延遲與資料落差不再能被接受。

RAG 與 AI 代理會在每次回答時從資料庫取出資料，再交給 LLM。這些搜尋同時需要「新鮮度、權限、篩選條件」三種特性；若採用多個專用資料庫再以同步方式串接，這三件事往往都得由應用程式自己補齊，實作成本很高。
這一點後面會再詳細說明。

變化 3：獨立學術支撐的出現

如前所述，「converged」 這個詞原本是 Oracle 提出的。
但後來，這種整併方向本身，也開始出現在不依賴單一廠商的學術文獻中被討論。

關聯式資料庫領域的重要學者 Michael Stonebraker（PostgreSQL 前身 Postgres 的研究者）與 Andrew Pavlo（卡內基美隆大學的資料庫研究者），在 2024 年的 SIGMOD Record 論文 What Goes Around Comes Around… And Around… 中，檢視了 20 年來資料模型的演變，並得出以下結論：

文件資料庫與 RDBMS 正朝著「相互碰撞的軌道」前進，兩者差異會隨時間縮小，未來幾乎難以區分
向量資料庫本質上可視為「加上特殊索引（ANN）的文件導向 DBMS」；索引只是其中一項功能，而不是新資料庫架構的根基，因此不足以作為新產品類別的立論依據
全文檢索若能在 RDBMS 端持續改善，並整合進 SQL，就能避免另外再立一個獨立產品

也就是說，雖然這個詞一開始來自廠商，但它所對應的架構方向，也已經在獨立論文中被討論。

融合式資料庫與 AI 的關係

接下來看融合式資料庫與 AI 的關係。
如前一章所述，RAG 與 AI 代理在搜尋時同時需要「新鮮度、權限、篩選條件」。
如果用多個專用資料庫搭配同步管線來處理這三件事，就很容易產生同步落差；而融合式資料庫正是被拿來當作這種落差的解法。

先看落差是怎麼產生的。
延續前面的例子，假設訂單資料放在關聯式 DB 或 DynamoDB，搜尋放在像 OpenSearch 這樣的搜尋引擎，嵌入向量放在像 Pinecone 這樣的向量儲存，各自用最擅長的專用資料庫處理，再透過同步管線（CDC 或批次）將資料串起來。

在這種架構下，同一份資料會在多個地方存在副本，而在副本尚未同步完成前，搜尋端看到的仍然是舊資料。
這種落差不是設計瑕疵，而是複製式架構本身的固有特性，甚至在 AI 出現之前就已經被指出。

只是當使用者是人時，這個問題往往還算可以接受。
例如電商搜尋中的新品，晚幾分鐘才出現，通常還算可容忍；即使結果不夠理想，畫面前也還有人的判斷可以介入。

但 RAG 與 AI 代理不同，每次回答都會先從資料庫取資料再交給 LLM，因此搜尋品質會直接決定回答品質。
而這類搜尋同時需要以下三種特性：

新鮮度 — 剛更新的內容要能立刻反映在搜尋結果中。若是獨立的向量資料庫，在同步延遲期間，AI 看到的仍是舊資料
權限 — 「這個使用者能不能看這筆資料」要在搜尋過程中就生效。若資料庫只有一個，定義一次就好；但若資料存放在不同系統中，SQL、API、向量搜尋等不同存取路徑都得在應用層重新實作權限，這也可能形成資料外洩的缺口
篩選條件 — 能做像「這個客戶的、尚未解決的工單裡，與這個問題相似的案件」這類條件式搜尋。這通常需要把向量相似搜尋與關聯式條件篩選結合起來

在專用儲存系統的組合架構中，這三件事都得各自依賴同步管線或程式碼補強。

當索引與實際資料不同步時，LLM 不會因此「比較沒把握」。
它會在依據舊事實的情況下，非常自信地答錯。

原文把這種狀態命名為 State Vector Dissonance（帶著強烈自信產生幻覺的狀態）2。

如果只是聊天機器人，使用者還可能發現它講錯了；但若是會自動執行下單或退款的 AI 代理，這種延遲就會直接變成商業風險。

原文將這個轉變濃縮成以下一句話：

AI did not create the multi-store consistency problem. It removed the tolerance for it.
（AI 並沒有創造多儲存系統的一致性問題，而是讓我們不再能容忍它）
— What Is a Converged Database?

若要解決搜尋端殘留舊資料的問題，也可以朝縮短同步管線的方向努力。但只要是複製傳遞機制，就算再快，資料到達前還是會有時間差，不可能完全為零。
融合式資料庫採取的不是這條路，而是把資料統一放進單一引擎，直接消除同步管線。沒有複製，自然也就沒有等待資料送達的時間。

那麼，整合到什麼程度才算「沒有管線」？
下一章的 5 個測試，就是用來判定這件事的標準。

判定是否可稱為「融合式」的 5 個測試

「可以儲存多種模型」是產品儲存層的屬性。
而融合式，指的是其上層所提供的保證。
原文用 5 個可驗證的測試，來區分這兩者。

測試	通過時	不通過時
1. 單一交易邊界	關聯式插入、文件寫入、向量更新可以放在同一個 ACID 交易中執行，回滾也會整體一起回復	中途失敗時，會留下「只更新了一部分」的半完成狀態
2. 單一最佳化器	一個包含圖、JSON、向量與關聯式的查詢，只會產生一個已經做過成本評估的執行計畫	若資料庫分散，應用程式就得自己硬寫「先查圖資料庫，再逐筆查向量資料庫」的流程，沒有統一的查詢執行腦
3. 單一一致性模型	不論透過哪個 API，都能成立「寫完立刻可讀」	因為有模型間同步管線，資料可見性會延遲
4. 單一治理領域	同一套權限、列級政策、稽核記錄能套用到所有存取路徑	SQL、文件 API、向量搜尋、圖等不同路徑都得在應用層各自重做權限，稽核也會分散
5. 存取介面共享	SQL、MongoDB 相容 API、REST 都只是同一引擎的不同投影，操作的是同一份資料	即使入口只有一個，只要後面串的是多個引擎，交易、一致性、權限等保證還是各自分離

其中第 1 點與第 2 點，透過實際例子會更容易理解。

測試 1：4 種寫入放在同一個交易中

原文提供的驗證專案中，首先展示的是將以下 4 種寫入包進同一個交易的範例（節錄）：

INSERT INTO orders ...;        -- 關聯式訂單
INSERT INTO order_items ...;   -- 其明細
INSERT INTO events (data) VALUES (JSON('{"type":"order_placed"}'));  -- JSON 文件
UPDATE support_tickets SET embedding = TO_VECTOR('[...]', 8, FLOAT32) WHERE ticket_id = 1;  -- 向量更新

這 4 個動作，要嘛全部提交，要嘛全部作廢，沒有只成功一半的中間狀態。

若把同樣的 4 種寫入分散到多個專用儲存系統，則各系統的原子性只會停留在自己的邊界內，並沒有跨系統的交易 API。
（例如 Pinecone 的官方文件就明確提到，索引更新是最終一致性，剛寫入的資料不會立刻可見。）
這時候回滾就只能變成應用程式自己針對各種失敗情境去寫、去維護的補償流程。

測試 2：單一最佳化器與單一執行計畫

最佳化器是資料庫裡負責根據統計資訊判斷「這個查詢用什麼順序、什麼方法執行最快」的核心腦袋。

如果資料庫是分散的，這個腦袋就無法直接處理跨系統查詢，結果就變成「先查圖資料庫，再在結果上逐筆查向量資料庫」這類順序，必須被硬寫進應用程式。
原文把這種狀態形容成「連接順序被硬編碼到應用邏輯中的分散系統」。

在融合式的情境中，若對包含圖、JSON、向量與關聯式的語句執行 EXPLAIN PLAN，四種模型會一起出現在同一份執行計畫中。
原因在於，處理圖的 GRAPH_TABLE 運算子會先被轉換成一般 SQL，再由同一個最佳化器進行成本評估。

測試 3～5：一致性、治理與存取介面

單一一致性模型 — 因為模型之間沒有同步管線，所以不論從哪個 API 寫入，都能成立「寫完立刻可讀」
單一治理領域 — 權限、列級政策、稽核記錄只要定義一次，就能套用到所有入口（SQL、文件 API、向量搜尋、圖）；稽核也能集中成一條
存取介面共享 — SQL、MongoDB 相容 API、REST 都只是同一引擎的投影，操作的是同一份資料。若只是把多個引擎包在同一個 gateway 後面，入口看似統一，內部的交易、一致性、權限保證仍然各自為政

✓ 到目前為止的整理：可以儲存多種模型，只是前提。真正重要的是，這些模型之間的保證——交易、最佳化器、一致性、治理、存取介面——是否跨模型維持為一體。能否同時通過這 5 個測試，就是是否能稱為融合式的分水嶺。

（能儲存多種模型的資料庫通常稱為多模型資料庫。原文有討論它與融合式的比較，但本文因篇幅較大不深入展開。）

為什麼文件 DB 會從關聯式 DB 分出去

前面談的是統一保存／融合的方向（convergence），這裡也補充一下分化（divergence）的脈絡。

關於這個分化的原因，不同立場會有不同解釋。

從關聯式 DB 的角度，有人會說 NoSQL 的流行只是行銷先行的繞路。
前面提到的 Stonebraker 與 Pavlo 論文，則把這個分化主要解釋為對阻抗不匹配的不滿。
在程式裡，資料常以「客戶底下有訂單、訂單底下有明細」這種巢狀形式存在，但到了關聯式 DB 中，卻得拆成多個表保存，讀取時再透過 JOIN 組裝回來。
應用程式與資料庫之間這種形狀上的不一致，就是阻抗不匹配；而文件資料庫可以直接把物件存成 JSON，正好成為這種不滿的出口。

另一方面，本文作者 Rick Houlihan 曾在 AWS 建立並教授 DynamoDB 的單表設計，可說是「分出去的那一方」的親身參與者；他認為這個分化其實是基於工作負載實測後所做出的設計判斷。
他引用的根據，是 Amazon CTO Werner Vogels 公開過的、Amazon 從關聯式轉移時的工作負載分析：

約 70% 的關聯式操作，只是根據 key 取單筆資料
另外約 20% 的操作，只是從單一表回傳多筆資料

也就是說，約 9 成的操作，其實都不需要關聯式資料庫最擅長的 JOIN。
當存取模式已經如此明確時，比起每次請求都付出 JOIN 的成本，不如預先把資料整理成最終要讀取的樣子，也就是做非正規化，這樣會更快。
因此，分出去的理由不是反對理論，而是為了提升讀取效能的設計選擇。

但這種設計選擇帶來的非正規化，也就是「保留副本」與「同一筆資料重複存在」，其實正是關聯理論透過正規化想要移除的冗餘性。
如果是為了讀取效能，那麼理論原本想避免的東西，真的可以再加回設計裡嗎？

關聯式理論有禁止冗餘嗎

原文在這裡回溯到關聯式模型的提出者 E. F. Codd（柯德）本人的論文。
Codd 並不是把冗餘當成「絕對禁止」，而是把它視為要依工作負載權衡的選項。

1969 年研究報告 — 只有在查詢負載比其他操作重得多的環境下，強烈冗餘才是合理的
1970 年論文 — 冗餘是一種交易：用「更多儲存空間與更新時間」換取「查詢時間改善」

如果讀取多，就可以容許重複；如果寫入多，就偏向正規化。
冗餘從一開始就是理論中的一個調整旋鈕，會隨讀寫比例而改變。
原文認為，文件資料庫的設計者所調的，其實也是同一個旋鈕。

同一份 1969 年報告裡，Codd 還提出了另一個區分：
資料的「邏輯形態」 與 「物理儲存方式」 的分離。

將邏輯與物理解耦的機制重新做起來

依照 Codd 的區分，邏輯模型（已正規化的關係集合）應保持正規化，而儲存表示則可以依工作負載來選擇。
也就是說，邏輯設計不要動，只有資料放法可以隨讀寫需求調整。

但在文件資料庫中，這兩件事是綁在一起的。
因為保存的文件長相，本身就等於你想讀取的答案長相。
需要的資料集中在同一處，讀取自然會快；但當存取模式改變時，就得連資料形狀本身一起重做。

原文把「把這個分離重新用現代方式做回來」的機制，稱作 JSON Relational Duality View。
這不是 SQL 標準內建的功能，而是 Oracle 專有功能。它在 2023 年的 Oracle Database 23c 中登場，並延續到目前（2026 年 8 月）的最新版本 Oracle AI Database 26ai。

Duality View 的概念，是把 customers、orders、order_items 這些表，定義成一份像下面這樣的巢狀 JSON 文件，並用檢視表（CREATE JSON RELATIONAL DUALITY VIEW）的方式宣告出來。
之後，便可以透過相容 MongoDB 的文件 API 直接以文件方式讀寫，而底層實體其實仍然是正規化的表格列。
換句話說，並不是另外存一份 JSON 副本，而是同一份資料同時是「文件」，也是那些表列。

{
  "_id": 42,
  "_metadata": { "etag": "E9BA8572B721D85E653B49930B83D911" },
  "email": "[email protected]",
  "fullName": "Customer 42",
  "segment": "standard",
  "orders": [
    { "orderId": 90, "status": "delivered", "total": 273.96,
      "items": [ { "line": 1, "productId": 32, "qty": 3, "unitPrice": 273.96 } ] }
  ]
}

原文的驗證腳本中，也示範了透過文件 API 更新客戶屬性，並能用同一個引擎內的 SQL 讀回相同變更。

// 用文件 API 更新…
col.updateOne({ _id: 42 }, { $set: { segment: 'vip' } });

// …再用同一個引擎的 SQL 讀回（沒有同步管線）
db.aggregate([{ $sql: 'SELECT segment FROM customers WHERE customer_id = 42' }]);

當同時有更新衝突時，則透過文件上的 etag（用來偵測變更的標籤）來進行偵測與控制。
也就是說，文件世界保有文件 API 的使用體驗，關聯式世界則保有約束、統計與 JOIN，而且這些都是建立在同一份資料上。

原文將這個章節的思路總結為「建模領域，投影存取」（Model the domain. Project the access.）。
（意思是：資料本體以正規化表來設計，而從應用角度看到的樣子，則以投影，也就是檢視表的方式宣告。）
要不要把關聯資料嵌進文件中，或是拆開後再引用，這類文件設計沒有通用標準答案，得依讀寫比例與存取模式來決定。
融合式也不改變這點。真正改變的是，未來若要重新調整，成本會低很多。
如果文件只是正規化列的投影，那麼存取模式改變時，往往只需要修改「投影定義」，而不必遷移整份資料。

用單一引擎搭出小型電商的例子

回到一開始提到的小型電商範例。

接下來要確認，上述內容在 Oracle Database 中實際會怎麼實作。

原文已將這個範例實作到驗證儲存庫中（200 位客戶、1,000 筆訂單、300 筆含嵌入向量的客服工單、推薦與裝置圖、門市地點資訊），文中的程式碼範例也都在那裡被實際驗證過。

不是替 5 種資料形態各建一個資料庫，而是只儲存正規化的表。
同一份資料，不靠副本，也不靠同步管線，就能從 5 種模型來使用。
每個模型的實現方式，要嘛是在表上加一層「呈現定義」，要嘛是在表上加欄位；但無論哪一種，真正的儲存實體都還是表，不會新增其他儲存位置。

模型	實作方式
表（關聯式）	直接使用正規化表，這就是儲存實體
JSON（文件）	在表之上定義一個以巢狀 JSON 呈現的檢視表（`CREATE JSON RELATIONAL DUALITY VIEW`，也就是前述 Duality View）
圖	在表之上增加節點與邊的定義（`CREATE PROPERTY GRAPH`）
向量	在表中加入 `VECTOR` 型別欄位
空間	在表中加入空間型別欄位，用來保存位置資訊

在這個基礎上，跨模型查詢就能以單一語句完成。
例如，以某位客戶為起點，先沿著推薦圖走 1 到 4 跳，找到相關客戶，再把這些客戶的未解決工單依向量相似度排序，最後再做關聯式 join 的例子如下（節錄）：

WITH ring AS (
  SELECT DISTINCT cid FROM GRAPH_TABLE (customer_graph
    MATCH (a IS customers) -[IS referrals]->{1,4} (b IS customers)
    WHERE a.customer_id = 10
    COLUMNS (b.customer_id AS cid))
)
SELECT c.customer_id
FROM ring r
JOIN customers c        ON c.customer_id = r.cid
JOIN support_tickets st ON st.customer_id = c.customer_id
WHERE st.status IN ('open','pending')
ORDER BY VECTOR_DISTANCE(st.embedding, :query_vector, COSINE)
FETCH FIRST 10 ROWS ONLY;

另外，原文中的這些主張——例如「4 種寫入可放在同一個交易中」、「執行計畫只有一份」、「寫完立刻可讀」——都已經作為公開儲存庫 converged-database-lab 裡的腳本實際執行過。
其中有 5 份驗證腳本、20 個斷言，都是在實際驗證環境中自動執行，且執行狀況是公開的。

總結

「融合式資料庫」並不是指能儲存多種資料模型，而是指交易、最佳化器、一致性、治理、存取介面這些保證，能跨模型維持為一體。

本文整理的重點如下：

定義 — 融合式資料庫不是指多模型儲存能力（multi-model），而是指交易、最佳化器、一致性、治理、存取介面這些保證跨模型合而為一。判定標準就是那 5 個測試
與 AI 的關係 — RAG 與 AI 代理的搜尋同時需要「新鮮度、權限、篩選條件」，若用多個專用儲存系統再同步串接，這三件事都會變成應用程式要自己補的。融合式的答案不是「更快的同步」，而是沒有同步管線
分化背景與 Duality View — 文件資料庫分出去，原本是為了讓讀取更快。冗餘在關聯理論中也一直是讀寫取捨的一部分；Duality View 則是把「邏輯維持正規化、呈現方式作為投影宣告」這件事重新做回來
實作型態 — 真正儲存的只有正規化表；各模型則透過在表上加定義或加欄位來實現。寫入可以收斂到單一交易，跨模型查詢也能收斂成單一執行計畫

補充一點，原文討論的是結構與保證，不是效能比較。
「融合式是否比較快」不是本文或原文要回答的問題，閱讀時請把這兩者分開。

如果這篇文章能讓你在思考 AI 時代的資料基礎架構時多一點參考，那就太好了。