長文本殺不死RAG:SQL+向量驅動大模型和大數據新範式,MyScale開源

機器之心發佈

機器之心編輯部

大模型（LLM）的浪潮已經涌動一年多了，尤其是以 GPT-4、Gemini-1.5、Claude-3 等爲代表的模型你方唱罷我登場，成爲當之無愧的風口。在 LLM 這條賽道上，有的研究專注於增加模型參數，有的瘋狂卷多模態…… 這當中，LLM 處理上下文長度的能力成爲了評估模型的一個重要指標，更強的上下文意味着模型擁有更強的檢索性能。例如有些模型一口氣可以處理高達 100 萬 token 的能力讓不少研究者開始思考，RAG （Retrieval-Augmented Generation，檢索增強生成）方法還有存在的必要嗎？

有人認爲 RAG 要被長上下文模型殺死了，但這種觀點遭到了很多研究者和架構師的反駁。他們認爲一方面數據結構複雜、定期變化，並且很多數據具有重要的時間維度，這些數據對於 LLM 來說可能太複雜。另一方面，企業、行業的海量異構數據，都放到上下文窗口中也不現實。而大模型和 AI 數據庫結合，給生成式 AI 系統注入專業、精準和實時的信息，大幅降低了幻覺，並提高了系統的實用性。同時，Data-centric LLM 的方法也可以利用 AI 數據庫海量數據管理、查詢的能力，大幅降低大模型訓練、微調的開銷，並支持在系統不同場景的小樣本調優。總結來說，大模型和 AI 數據庫雙劍合璧，既給大模型降本增效，又讓大數據真正實現智能。

歷經數年開發和迭代，MyScaleDB 終於開源

RAG 的出現使得 LLM 能從大規模的知識庫中精確地抽取信息，並生成實時、專業、富有洞察力的答案。伴隨而來的是 RAG 系統的核心功能向量數據庫也得到了迅速發展，按照向量數據庫的設計理念我們可以將其大致分爲三類：專用向量數據庫，關鍵字和向量結合的檢索系統，以及 SQL 向量數據庫。

MyScale AI 數據庫（MyScaleDB）基於高性能的 SQL 列式存儲數據庫打造，自研高性能和高數據密度的向量索引算法，並針對 SQL 和向量的聯合查詢對檢索和存儲引擎進行了深度的研發和優化，是全球第一個綜合性能和性價比大幅超越了專用向量數據庫的 SQL 向量數據庫產品。

得益於 SQL 數據庫在海量結構化數據場景長期的打磨，MyScaleDB同時支持海量向量和結構化數據，包括字符串、JSON、空間、時序等多種數據類型的高效存儲和查詢，並將在近期推出功能強大的倒排表和關鍵字檢索功能，進一步提高 RAG 系統的精度並替代 Elasticsearch 等系統。

經過近 6 年的開發和數次版本迭代，MyScaleDB 已於近期開源，歡迎所有開發者和企業用戶在 GitHub 上 Star，並開啓使用 SQL 構建生產級 AI 應用的新玩法！

項目地址：https://github.com/myscale/myscaledb

完全兼容 SQL，精度提升、成本降低

藉助完善的 SQL 數據管理能力，強大高效的結構化、向量和異構數據存儲和查詢能力，MyScaleDB 有望成爲第一款真正面向大模型和大數據的 AI 數據庫。

SQL 和向量的原生兼容性

自從 SQL 誕生半個世紀以來，儘管其中經歷了 NoSQL、大數據等浪潮，不斷進化的 SQL 數據庫還是佔據了數據管理市場主要份額，甚至 Elasticsearch、Spark 等檢索和大數據系統也陸續支持了 SQL 接口。而專用的向量數據庫儘管爲向量做了優化和系統設計，但其查詢接口通常缺乏規範性，沒有高級的查詢語言。這導致了接口的泛化能力較弱，例如 Pinecone 的查詢接口甚至不包括指定要檢索的字段，更不用說分頁、聚合等數據庫常見的功能。

接口的泛化能力弱意味着其變化頻繁，增加了學習成本。MyScale 團隊則認爲，經過系統性優化的 SQL 和向量系統是可以既保持完整的 SQL 支持，又保證向量檢索高性能的，而他們的開源評測的結果已經充分論證了這一點。

在實際複雜 AI 應用場景中，SQL 和向量結合可以極大增加數據建模的靈活性，並簡化開發流程。例如 MyScale 團隊與北京科學智能研究院合作的 Science Navigator 項目中，利用 MyScaleDB 對於海量的科學文獻數據做檢索和智能問答，其主要的 SQL 表結構就有 10 多個，其中多張表結構建立了向量和倒排表索引，並利用主鍵和外鍵做了關聯。系統在實際查詢中，也會涉及結構化、向量和關鍵字數據的聯合查詢，以及幾張表的關聯查詢。在專用的向量數據庫中這些建模和關聯是難以實現的，也會導致最終的系統迭代緩慢、查詢低效和維護困難。

Science Navigator 主要表結構示意圖（加粗體的列建立了向量索引或倒排索引）

支持結構化、向量和關鍵字等數據聯合查詢

在實際 RAG 系統中，檢索的精度和效果是制約其落地的主要瓶頸。這需要 AI 數據庫高效支持結構化、向量和關鍵字等數據聯合查詢，綜合提高檢索精度。

例如在金融場景中，用戶需要針對文檔庫查詢 “某公司 2023 年全球各項業務的收入情況如何？”，“某公司”，“2023 年” 等結構化元信息並不能被向量很好的抓取，甚至不一定在對應的段落中有直接的體現。直接在全庫上執行向量檢索會得到大量的干擾信息，並降低系統最終的準確性。另一方面，公司名稱，年份等通常是可以作爲文檔的元信息被獲取的，我們可以將 WHERE year=2023 AND company ILIKE "%

%" 作爲向量查詢的過濾條件，從而精準的定位到相關信息，大幅提升了系統的可靠性。在金融、製造業、科研等場景中，MyScale 團隊都觀察到異構數據建模和關聯查詢的威力，很多場景下甚至有60%精度到90%的提升。

儘管傳統的數據庫產品都已經陸續意識到了向量查詢在 AI 時代的重要性，並開始在數據庫中增加向量能力，其聯合查詢的精度仍然存在顯著的問題。例如，在過濾查詢的場景下，Elasticsearch 在過濾比例爲 0.1 時，QPS 會降到只有 5 左右，而 PostgresSQL（使用 pgvector 插件）在過濾比例是 0.01 時，檢索精度只有 50% 左右，不穩定的查詢精度 / 性能極大制約了其應用的場景。而MyScale 僅使用了 pgvector 36% 的成本和 ElasticSearch 12% 的成本，就能夠在各種不同過濾比例的場景下都實現高性能和高精度的查詢。

在不同過濾比例場景下，MyScale 都用低成本實現了高精度和高性能查詢

真實場景下性能和成本的平衡

正因爲向量檢索在大模型應用中的重要性和高關注度，越來越多的團隊投入了向量數據庫這個賽道。大家一開始的關注點都是努力提升純向量搜索場景下的 QPS，不過純向量搜索是遠遠不夠的！在實戰的場景中，數據建模、查詢的靈活性和精準度以及平衡數據密度、查詢性能和成本是更爲重要的議題。

在 RAG 場景中，純向量查詢性能有 10x 的過剩，向量佔用資源龐大，聯合查詢功能缺乏、性能和精度不佳往往是當下專有向量數據庫的常態。MyScaleDB 致力於在真實海量數據場景下 AI 數據庫的綜合性能提升，其推出的 MyScale Vector Database Benchmark 也是業內首個在五百萬向量規模，不同查詢場景下比較主流向量數據庫系統綜合性能、性價比的開源評測系統，歡迎大家關注和提 issue。MyScale 團隊表示，AI 數據庫在真實應用場景下還存在很大的優化空間，他們也希望在實踐中不斷打磨產品並完善評測系統。

MyScale Vector Database Benchmark 項目地址：

https://github.com/myscale/vector-db-benchmark

展望：AI 數據庫支撐的大模型 + 大數據 Agent 平臺

機器學習 + 大數據驅動了互聯網和上一代信息系統的成功，而在大模型的時代背景下，MyScale 團隊也致力於提出新一代的大模型 + 大數據方案。以高性能的 SQL + 向量數據庫爲堅實的支撐，MyScaleDB 提供了大規模數據處理、知識查詢、可觀測性、數據分析和小樣本學習的關鍵能力，構建了 AI 和數據閉環，成爲下一代大模型 + 大數據 Agent 平臺的關鍵基座。MyScale 團隊已經在科研、金融、工業、醫療等領域探索這套方案的落地。

隨着技術的快速發展，某種意義上的通用人工智能 (AGI) 有望在未來 5-10 年內出現。關於這個問題，我們不禁要思考：是需要一個靜態、虛擬且與人類競爭的大模型，還是其他更加全面的解決方案？數據無疑是連接大模型、世界與用戶的重要紐帶，MyScale 團隊的願景是將大模型和大數據有機結合，打造更加專業、實時、高效協作，同時亦充滿人性溫度和價值的 AI 系統。