在(zai)圈內朋(peng)友看來，Oracle 數據(ju)(ju)(ju)庫的(de) 多模能力 已經不是什么(me)新鮮(xian)話題。它不僅在(zai)關系型(xing)數據(ju)(ju)(ju)管理方面(mian)獨樹一幟，還能夠在(zai)同一個數據(ju)(ju)(ju)庫引(yin)擎中，支持幾乎所有主流(liu)的(de)數據(ju)(ju)(ju)模型(xing) —— 從 JSON、XML、時序(xu)、空間(jian)，到(dao)圖(tu)數據(ju)(ju)(ju)、區塊鏈，再(zai)到(dao)如今(jin)最火的(de)向量數據(ju)(ju)(ju)與 AI。

利用 Oracle APEX，可以(yi)更簡單(dan)、高效地(di)展示(shi)數據庫的多模(mo)能(neng)(neng)力(li)。本文將通(tong)過一個 簡明示(shi)例，演示(shi)如何使(shi)用 APEX 程序 直觀地(di)體驗(yan)向量近似(si)檢索（Approximate Nearest Neighbor, ANN） 的能(neng)(neng)力(li)，從而(er)讓多模(mo)數據的操作與查詢可視化(hua)、易上手。

APEX實現(xian)功(gong)能：文本(ben)內容的近似最近鄰檢(jian)索（ANN） 功(gong)能。

• 1.庫內Embedding模型準備
• 2.APEX簡明示例
• 3.其他細節信息參考

1.庫內Embedding模型準備

我們知道，Oracle 23ai數(shu)(shu)據(ju)庫原生支(zhi)持(chi)向量數(shu)(shu)據(ju)類型(xing)的存儲(chu)，可以支(zhi)持(chi)直接在(zai)任意(yi)數(shu)(shu)據(ju)庫表對象上增加一個或(huo)多個vector數(shu)(shu)據(ju)類型(xing)的列，專門用(yong)于(yu)存儲(chu)向量數(shu)(shu)據(ju)格式。

具體如何存儲向量化的數據呢？

• 首先我們需要一個Embedding模型，可以對指定的內容向量化，然后將向量化后的結果直接存儲到vector數據類型的字段中；

如果還沒有Embedding模型可用，不必折騰，Oracle本身支持庫內加載onnx模型，具體可以參考之前文章《》中提到過的方法，唯一需要注意，當時是直接使用了官方文檔介紹的all_MiniLM_L12_v2.onnx模型，這里筆者實際測試發現其對中文的匹配效果并不理想，所以換用另一個Embedding模型bge-base-zh-v1.5.onnx，為(wei)了方便大家動(dong)手(shou)操(cao)作，這里(li)貼出導入此(ci)模型的關鍵步驟：

--刪除模型（可選）
exec DBMS_VECTOR.DROP_ONNX_MODEL(model_name => 'BGE_BASE', force => true);

--加載導入模型：
BEGIN
   DBMS_VECTOR.LOAD_ONNX_MODEL(
        directory => 'DM_DUMP',
                file_name => 'bge-base-zh-v1.5.onnx',
        model_name => 'BGE_BASE',
        metadata => JSON('{"function" : "embedding", "embeddingOutput" : "embedding", "input": {"input": ["DATA"]}}'));
END;
/

--查詢導入的EMBEDDING模型：
select model_name, algorithm, mining_function from user_mining_models where model_name='BGE_BASE';

--測試EMBEDDING模型可用，可以正常返回向量化結果
SELECT VECTOR_EMBEDDING(BGE_BASE USING 'Hi, Alfred' as DATA) AS embedding;

2.APEX簡明示例

隨便找一(yi)張(zhang)表(biao)，對其中(zhong)任意一(yi)個(ge)想做近似檢索的(de)文本列字(zi)段，針對該表(biao)增加一(yi)個(ge)向(xiang)量列。然后使用(yong)上一(yi)步配置好的(de)庫內Embedding模(mo)型進(jin)行(xing)向(xiang)量化處理。

我這里就以之前的Demo為基礎，針對t_history表中 content列的內容進行向量化，結果存儲到表中列v中，數據類型是vector。

關鍵步驟：

--1.向量字段存儲向量化后的內容，只是測試下模型可用
UPDATE t_history
SET v = VECTOR_EMBEDDING(BGE_BASE USING content AS DATA)
where username = 'test';

--2.分批處理更新，向量字段存儲向量化后的內容，可配置到APEX頁面中前臺調用
DECLARE
  CURSOR c_history IS
    SELECT rowid AS rid, content
    FROM t_history
    WHERE content is not null 
    and (v IS NULL or v_needs_update=1);  -- 只處理未向量化和需要更新向量化的行
BEGIN
  FOR r IN c_history LOOP
    UPDATE t_history
    SET v = VECTOR_EMBEDDING(BGE_BASE USING r.content AS DATA)
    WHERE rowid = r.rid;
  END LOOP;
  COMMIT;
END;
/

--3.APEX可以通過報表直觀展現近似檢索功能
SELECT type, week, day, history_date, content
FROM t_history
where username = :APP_USER
ORDER BY VECTOR_DISTANCE(v, VECTOR_EMBEDDING(BGE_BASE USING :P7_SEARCH_TEXT AS DATA))
FETCH APPROX FIRST 5 ROWS ONLY;

APEX近似檢索效果：
這里首先我在(zai)表(biao)中的content列中，初(chu)始(shi)化了(le)一些(xie)(xie)測試數據，比(bi)如針(zhen)對愛情(qing)、開發等主題，模擬用(yong)戶日常操作，錄入一些(xie)(xie)與主題相關的內容，不(bu)知(zhi)道該具(ju)體輸入啥內容的同學，可(ke)以直接讓LLM幫你(ni)生成(cheng)哈。

然后，我們到(dao)APEX頁(ye)面(mian)上進行檢索測試。

輸入愛情，點擊搜索，就可以從該用戶歷史記錄過的所有內容中，檢索到它認為向量近似的前5個結果列出來，可以看到結果都與愛情相關，但未必都包含愛情關鍵字，比如第5條結果描述的單戀場景：

同樣，如果輸入開發，點擊搜索，結果就是這樣，很多結果并沒有開發關鍵字，但表(biao)述其實都(dou)跟軟(ruan)件(jian)開發這個主題密不可分：

這也是向量近似檢索的魅力所在，歷史傳統數據庫無論是進行精確或模糊搜索，都只能基于關鍵字匹配，但如今，向量的近似檢索使其可以直接依據語義進行搜索。

3.其他細節信息參考

前面已經(jing)展示(shi)了(le)實際效果，達(da)成了(le)目(mu)標，本節主要補充一些信(xin)息，方便讀者更(geng)好地理解實現細(xi)節。

我這里在對t_history表處理的過程中，針對向量列的判斷里，有寫到 (v IS NULL or v_needs_update=1); -- 只處理未向量化和需要更新向量化的行，還特別注釋說明了下，這(zhe)是(shi)因(yin)為(wei)最初我只處理(li)了未向(xiang)量(liang)化的(de)(de)內(nei)容(rong)，但是(shi)我實際在錄入(ru)文本內(nei)容(rong)時，存在更(geng)新(xin)原內(nei)容(rong)的(de)(de)需求。而(er)原內(nei)容(rong)因(yin)為(wei)已經做(zuo)過(guo)向(xiang)量(liang)化，向(xiang)量(liang)部分不會(hui)更(geng)新(xin)，所(suo)以搜索(suo)會(hui)遇到問題，因(yin)此需要fix這(zhe)個更(geng)新(xin)場(chang)景的(de)(de)bug，增加一列，并加入(ru)到對應的(de)(de)邏輯判斷中(zhong)：

--fix更新bug
ALTER TABLE t_history ADD v_needs_update NUMBER(1) DEFAULT 0;

這樣(yang)，當發現有(you)錄入(ru)或更新(xin)內(nei)容，都(dou)可以(yi)做到能提示最終用戶(hu)，需要處理新(xin)內(nei)容。

比如用戶想近似檢索人工智能相關的內容，下面紅色數字就表示，表中數據存在更新內容，但還未向量化的情況，檢索結果可能存在不準確的情況，這個例子就是如此，除了第一條記錄，其他和人工智能其實關系并不大：

此時，用戶可以手工點擊向量化，將最新更新的一些內容向量化，再次檢索，發現除了第一條結果，其他已經不一樣了，說明新的內容（這里可以通過History Date列快速識別）確實存在一些比歷史數據更匹配人工智能主題的結果：

也許看到這里，有讀者會有疑問(wen)，為(wei)何不(bu)直(zhi)(zhi)接設計，在更新(xin)內容(rong)時直(zhi)(zhi)接就向量(liang)化呢？

嗯，其實(shi)也不是不可(ke)以，看應(ying)用(yong)要求，只是我(wo)這(zhe)(zhe)里這(zhe)(zhe)樣設(she)計更符合演示(shi)要求而已(yi)。同時也為了(le)能讓大家直觀看到(dao)，近(jin)似(si)檢索(suo)(suo)，實(shi)際(ji)上檢索(suo)(suo)結果(guo)就是distance的(de)排名，如果(guo)要求展示(shi)的(de)記(ji)錄數，本身(shen)數據集中就沒(mei)有足夠數量匹(pi)配的(de)，也會檢索(suo)(suo)出來一些不太相干(gan)的(de)內(nei)容。

此(ci)外，如果數據量(liang)(liang)較(jiao)大(da)，基于性能考量(liang)(liang)，建議創建HNSW（Hierarchical Navigable Small World）類型的向(xiang)量(liang)(liang)索引，同時(shi)注(zhu)意(yi)Top-K兩種寫(xie)法差異：

--4.創建HNSW索引
create vector index t_history_hnsw_idx on t_history(v)
organization inmemory neighbor graph
distance COSINE
with target accuracy 95;

--精確 Top-K
SELECT type, week, day, history_date, content
FROM t_history
ORDER BY VECTOR_DISTANCE(v, VECTOR_EMBEDDING(BGE_BASE USING '愛情' AS DATA))
FETCH FIRST 5 ROWS ONLY;

--近似 Top-K，增加了APPROX關鍵字：
SELECT type, week, day, history_date, content
FROM t_history
ORDER BY VECTOR_DISTANCE(v, VECTOR_EMBEDDING(BGE_BASE USING '愛情' AS DATA))
FETCH APPROX FIRST 5 ROWS ONLY;

至(zhi)此，我們就(jiu)利用(yong)APEX程序(xu)直觀體驗了向量(liang)近似檢索能(neng)力。