OceanBase 向量檢索在貨拉拉的探索和實踐

作者：陳銓，貨拉拉大數據技術與產品部高級大數據工程師

貨拉拉成立於 2013 年，成長於粵港澳大灣區，是從事同城 / 跨城貨運、企業版物流服務、搬家、零擔、跑腿、冷運、汽車租售及車後市場服務的互聯網物流商城。截至 2024 年，貨拉拉在全球擁有 1670 萬月活用戶和 168 萬月活司機，業務覆蓋全球 11 個市場、400 + 城市，並在全球設有 6 個數據中心。

一、大模型應用場景的挑戰

貨拉拉基於自身在物流領域 AI 落地的深厚積累，已在 14+ 個業務或部門，50+ 個真實業務場景探索和落地大模型應用。在引入大模型的過程中，面臨着其在垂直領域知識的缺乏、時效性不足以及數據安全隱患等挑戰。爲應對這些問題，採用了業界較爲通用的解決方案的解決方案——檢索增強生成技術（Retrieval-Augmented Generation, RAG），通過引入外部數據，讓大模型的回答從原來的 “閉卷” 變爲“開卷”。RAG 通過整合領域專有知識、私有數據以及實時數據，顯著降低了答案生成的不確定性，增強了數據安全性，從而有效解決了大模型的固有問題，提升了回答的準確性和實用性。

RAG 的核心在於將強大的語言模型能力與向量數據庫的能力相結合，企業在實施 RAG 方案的過程中，通常需要結合一個向量數據庫。向量數據庫在處理多模數據和語義檢索方面具有獨特的優勢，具體體現在以下幾個方面：

• 存儲非結構化數據：向量數據庫能夠有效存儲和管理多模態數據，如音頻、視頻、圖片和文本等。這些數據通常具有規模龐大、信息密度高、處理成本高的特點。

• 向量化表示：通過神經網絡提取數據特徵，將其轉換爲高維空間中的座標點。向量化表示賦予數據語義表達能力，使其適用於相似性檢索。

• 檢索非結構化數據：通過計算向量間的距離（如內積或歐氏距離），識別出最相似的向量。檢索過程涉及近鄰圖的遍歷，需要進行大量的浮點運算，以實現高效的相似性匹配。

二、向量數據庫選型思考

（一）原有架構與痛點

現有的架構包含基礎設施層（CPU 和 GPU 兩種機型）、存儲層（向量數據庫、ES 等）、檢索層（以圖索引爲主，多種檢索類型）、接入層與入口層。並且在國內外共有 5 個集羣，單集羣內存配置在 380 +GB，單表數據量最大爲 2000 萬。

痛點 1：動態 schema

隨着業務的快速發展，頻繁的字段增刪操作成爲常態。目前的解決方案是通過新建表、導入現有數據並最終重建索引來實現，這一流程相對繁瑣。對於某些數據量較大的表，索引重建的耗時可能長達十幾個小時。此外，索引重建過程對 CPU 和內存資源消耗極大，容易引發線上業務抖動。

痛點 2：混合檢索

向量檢索在相似語義檢索和多模態數據理解方面具有顯著優勢，而全文檢索則在精準匹配、短文本及低頻詞彙檢索上表現優異。在企業應用中，僅依賴單一檢索方式難以滿足業務對檢索精度的高要求。爲了彌補全文檢索的缺陷，引入了 Elasticsearch 來作爲全文檢索引擎，這也導致了整體架構的複雜性增加，同時提升了系統的維護難度。對於用戶而言，需要在應用層實現複雜的 reranking 邏輯，並且得到的相似度得分難以統一，從而增加了使用成本。因此，業務希望引入一站式混合索引能力。

痛點 3：運維難度大

• 穩定性能力弱：向量數據庫本身存在不穩定性，BUG 較多；缺乏專家經驗使得問題排查變得困難；監控指標有限，問題定位困難。

• 擴展性不足：節點的橫向擴展能力較差，數據遷移依賴人工；數據分片的管理和運維過程複雜。

• 權限認證能力弱：現有的權限認證機制不夠完善，容易引發數據泄漏和安全問題，需要自行實現權限管理，增加了開發和運維的複雜性。

• 社區活躍度差：雖然項目仍在維護，但更新頻率較低，社區貢獻和開發者參與度有限，且社區功能和生態發展緩慢，無法滿足業務未來的需求。

（二）選型標準與過程

基於上述痛點，我們在 2024 年底重新進行了一次向量數據庫選型。選型的標準主要從業務訴求和運維訴求兩方面來考慮，如下圖所示。

在選型過程中，將 10 款向量數據庫列入候選集，並通過多維度的詳細對比，基於業務和運維痛點進行了第一輪篩選，首先，由於我司採用多雲架構，因此希望數據庫可以跨雲部署，排除了雲商數據庫。其次，基於業務對於向量維度有更高的需求，排除 PostgreSQL。另外從穩定性和權限管理方面考慮，排除了 Weaviate。

經過初步篩選，Milvus、Elasticsearch 和 OceanBase 成爲入圍的候選產品。在第二輪篩選中，重點關注穩定性和運維成本：

• Milvus：實時風控場景對向量數據庫的穩定性要求極高。由於 Milvus 的整體架構較爲複雜，確保其穩定性需要投入更多的運維成本。此外，Zilliz 的雲版本和貨拉拉的線上服務是跨地區部署，存在一定的穩定性隱患，因此暫時排除 Milvus。

• OceanBase：在搭建 OceanBase 社區版環境後，進行了全面的向量能力測試，並與業務部門聯合對線上真實場景進行了壓力測試和對比。結果表明，OceanBase 在功能和性能方面均能滿足業務需求。此外，OceanBase 經過各大廠多年的打磨，穩定性方已經得到驗證。同時，OceanBase 社區活躍度高，定期更新向量能力和性能，並提供技術支持。

• Elasticsearch：Elasticsearch 在全文檢索和混合檢索能力上表現比較優秀，但基於公司內部團隊的實際情況，最終在 Elasticsearch 和 OceanBase 之間選擇了後者。

在完成選型後，面臨的關鍵決策是選擇自建還是上雲。首先對這兩種方案進行了詳細對比，其次考慮到公司內部大量 DB 都存在上雲趨勢，上雲後能夠實現很好的彈性擴縮容，同時有更可靠的 SLA 保障 ，且現階段我們更關注的是業務接入，在運維上不希望投入過多的人力，最終選擇在雲上構建向量數據庫底座。

三、向量數據庫落地場景

（一）資損代碼識別

資損代碼識別是 OceanBase 向量檢索在貨拉拉的重要應用場景。由於研發質量問題或代碼中的潛在漏洞，可能導致公司面臨嚴重的財務損失。過去主要依靠人工審覈來識別資損代碼，效率低下且難以全面覆蓋線上服務，導致資損風險無法完全規避。爲解決這一問題，結合大模型能力與 OceanBase 向量檢索，開發了自動化代碼風險識別系統。該系統通過向量化歷史案例數據並檢索相似代碼，利用大模型進行分析和判斷資損風險，從而提高代碼審查的效率和準確性，控制開發過程中的風險。

具體流程如下：首先，基於歷史真實發生的資損代碼場景和案例數據，通過大模型進行分類打標處理，得到數據集並經人工二次確認後，將數據灌入向量數據庫。在開發者提交代碼構建時，觸發代碼檢測流程，將用戶提交的代碼與向量數據庫中保存的資損代碼進行向量相似度檢索，將檢索結果及相關數據提供給大模型進行資損風險判斷。若判斷代碼存在風險，則熔斷代碼構建流程，防止其發佈到線上平臺。這一項目的實施，提高了資損代碼識別的效率和準確性，爲公司有效的規避潛在的資損風險。

（二）數倉 AI 答疑助手

數倉 AI 答疑項目是 OceanBase 向量檢索在貨拉拉的另一個重要落地場景，同時也是一個非常典型的應用場景。貨拉拉的大數據數倉體量龐大，擁有幾十萬張 Hive 表，每天都有大量用戶需要查詢數據。然而，用戶通常缺乏足夠的業務背景知識，難以快速找到所需數據，只能通過數倉開發人員的幫助，這給數倉開發同學帶來了巨大的工作負擔。爲了解決這一問題，我們將向量檢索的能力應用於數倉 AI 答疑助手，提高數據查詢效率，減輕了數倉開發人員的工作壓力。

具體流程如下：首先，將庫表的 Schema 信息、聊天答疑記錄以及內部維護的文檔進行處理，例如將庫表信息處理成字段映射關係、將聊天答疑記錄轉化爲 QA 對形式等。然後，通過 Embedding 模型將這些數據轉化爲向量並存儲到 OceanBase 向量數據庫中。當用戶提問時，系統首先進行意圖識別，判斷用戶是找數場景、問口徑場景還是普通知識答疑場景。接着，對用戶的問題進行理解，將其複雜問題拆分成多個子問題，並進行實體識別，必要時採用多輪對話方式確定用戶意圖。之後進行知識召回，由於該場景對查詢精度要求高，因此採用了多種檢索方案，如向量檢索、標量檢索以及全文關鍵字檢索。將召回的知識數據提供給重排序模型進行重排，將最相關答案提供給大模型進行總結生成，最終爲用戶提供準確的數據查詢結果。這一項目的實施，降低用戶找數門檻，減輕隱性的溝通負擔，顯著提高了數倉數據查詢效率，降低了人力成本，提升了用戶體驗。

四、未來規劃

隨着 OceanBase 在貨拉拉線上業務的穩定運行，未來將有更深入、更豐富的應用規劃。

• 業務遷移：這一過程涉及支持一站式融合檢索能力，業務改造適配，數據遷移等。

• 性能成本：隨着用戶數量的增加，性能和成本成爲關注的焦點，將考慮引入標量量化索引 HNSW_SQ 或磁盤索引 IVF 等技術，同時支持表級別的 TTL 和冷熱數據分層能力。

• 內部系統集成：將 OceanBase 集成到內部系統中，如大數據平臺、監控告警系統和 DMS 數據庫管理系統，以提供更絲滑的用戶體驗。

• 更多場景探索：正在在探索更多 OceanBase 的應用場景，如 OLAP、OBKV 等，希望解決在線存儲的痛點。

「老紀的技術嘮嗑局」不僅希望能持續給大家帶來有價值的技術分享，也希望能和大家一起爲開源社區貢獻一份力量。如果你對 OceanBase 開源社區認可，點亮一顆小星星 ✨ 吧！你的每一個 Star，都是我們努力的動力。

https://github.com/oceanbase/oceanbase

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Ou4zIzjIaMkrma6Cxb3Tkw