大模型和 ai 數(shù)據(jù)庫雙劍合璧，成為大模型降本增效，大數(shù)據(jù)真正智能的制勝法寶。
???AI 智能聊天, 問答助手, AI 智能搜索, 免費無限量使用 DeepSeek R1 模型???
大模型（LLM）的浪潮已經(jīng)涌動一年多了，尤其是以 GPT-4、Gemini-1.5、Claude-3 等為代表的模型你方唱罷我登場，成為當之無愧的風(fēng)口。在 LLM 這條賽道上，有的研究專注于增加模型參數(shù)，有的瘋狂卷多模態(tài)…… 這當中，LLM 處理上下文長度的能力成為了評估模型的一個重要指標，更強的上下文意味著模型擁有更強的檢索性能。例如有些模型一口氣可以處理高達 100 萬 token 的能力讓不少研究者開始思考，RAG （Retrieval-Augmented Generation，檢索增強生成）方法還有存在的必要嗎？有人認為 RAG 要被長上下文模型殺死了，但這種觀點遭到了很多研究者和架構(gòu)師的反駁。他們認為一方面數(shù)據(jù)結(jié)構(gòu)復(fù)雜、定期變化，并且很多數(shù)據(jù)具有重要的時間維度，這些數(shù)據(jù)對于 LLM 來說可能太復(fù)雜。另一方面，企業(yè)、行業(yè)的海量異構(gòu)數(shù)據(jù)，都放到上下文窗口中也不現(xiàn)實。而大模型和 AI 數(shù)據(jù)庫結(jié)合，給生成式 AI 系統(tǒng)注入專業(yè)、精準和實時的信息，大幅降低了幻覺，并提高了系統(tǒng)的實用性。同時，Data-centric LLM 的方法也可以利用 AI 數(shù)據(jù)庫海量數(shù)據(jù)管理、查詢的能力，大幅降低大模型訓(xùn)練、微調(diào)的開銷，并支持在系統(tǒng)不同場景的小樣本調(diào)優(yōu)?？偨Y(jié)來說，大模型和 AI 數(shù)據(jù)庫雙劍合璧，既給大模型降本增效，又讓大數(shù)據(jù)真正實現(xiàn)智能。歷經(jīng)數(shù)年開發(fā)和迭代，MyScaleDB 終于開源RAG 的出現(xiàn)使得 LLM 能從大規(guī)模的知識庫中精確地抽取信息，并生成實時、專業(yè)、富有洞察力的答案。伴隨而來的是 RAG 系統(tǒng)的核心功能向量數(shù)據(jù)庫也得到了迅速發(fā)展，按照向量數(shù)據(jù)庫的設(shè)計理念我們可以將其大致分為三類：專用向量數(shù)據(jù)庫，關(guān)鍵字和向量結(jié)合的檢索系統(tǒng)，以及 SQL 向量數(shù)據(jù)庫。
- 以 Pinecone/Weaviate/Milvus 為代表的專用向量數(shù)據(jù)庫，一開始即為向量檢索設(shè)計打造，向量檢索性能出色，不過通用的數(shù)據(jù)管理功能較弱。
- 以 Elasticsearch/OpenSearch 為代表的關(guān)鍵字和向量檢索系統(tǒng)，因其完善的關(guān)鍵字檢索功能得到廣泛生產(chǎn)應(yīng)用，不過系統(tǒng)資源占用較多，關(guān)鍵字與向量的聯(lián)合查詢精度和性能不盡人如意。
- 以 pgvector（PostgreSQL 的向量搜索插件）和 MyScale AI 數(shù)據(jù)庫為代表的 SQL 向量數(shù)據(jù)庫，基于 SQL 并且數(shù)據(jù)管理功能強大。不過因為 PostgreSQL 行存的劣勢和向量算法的局限性，pgvector 在復(fù)雜向量查詢中精度較低。
MyScale AI 數(shù)據(jù)庫（MyScaleDB）基于高性能的 SQL 列式存儲數(shù)據(jù)庫打造，自研高性能和高數(shù)據(jù)密度的向量索引算法，并針對 SQL 和向量的聯(lián)合查詢對檢索和存儲引擎進行了深度的研發(fā)和優(yōu)化，是全球第一個綜合性能和性價比大幅超越了專用向量數(shù)據(jù)庫的 SQL 向量數(shù)據(jù)庫產(chǎn)品。得益于 SQL 數(shù)據(jù)庫在海量結(jié)構(gòu)化數(shù)據(jù)場景長期的打磨，MyScaleDB 同時支持海量向量和結(jié)構(gòu)化數(shù)據(jù)，包括字符串、JSON、空間、時序等多種數(shù)據(jù)類型的高效存儲和查詢，并將在近期推出功能強大的倒排表和關(guān)鍵字檢索功能，進一步提高 RAG 系統(tǒng)的精度并替代 Elasticsearch 等系統(tǒng)。
經(jīng)過近 6 年的開發(fā)和數(shù)次版本迭代，MyScaleDB 已于近期開源，歡迎所有開發(fā)者和企業(yè)用戶在 GitHub 上 Star，并開啟使用 SQL 構(gòu)建生產(chǎn)級 AI 應(yīng)用的新玩法！項目地址：https://github.com/myscale/myscaledb借助完善的 SQL 數(shù)據(jù)管理能力，強大高效的結(jié)構(gòu)化、向量和異構(gòu)數(shù)據(jù)存儲和查詢能力，MyScaleDB 有望成為第一款真正面向大模型和大數(shù)據(jù)的 AI 數(shù)據(jù)庫。自從 SQL 誕生半個世紀以來，盡管其中經(jīng)歷了 NoSQL、大數(shù)據(jù)等浪潮，不斷進化的 SQL 數(shù)據(jù)庫還是占據(jù)了數(shù)據(jù)管理市場主要份額，甚至 Elasticsearch、Spark 等檢索和大數(shù)據(jù)系統(tǒng)也陸續(xù)支持了 SQL 接口。而專用的向量數(shù)據(jù)庫盡管為向量做了優(yōu)化和系統(tǒng)設(shè)計，但其查詢接口通常缺乏規(guī)范性，沒有高級的查詢語言。這導(dǎo)致了接口的泛化能力較弱，例如 Pinecone 的查詢接口甚至不包括指定要檢索的字段，更不用說分頁、聚合等數(shù)據(jù)庫常見的功能。接口的泛化能力弱意味著其變化頻繁，增加了學(xué)習(xí)成本。MyScale 團隊則認為，經(jīng)過系統(tǒng)性優(yōu)化的 SQL 和向量系統(tǒng)是可以既保持完整的 SQL 支持，又保證向量檢索高性能的，而他們的開源評測的結(jié)果已經(jīng)充分論證了這一點。在實際復(fù)雜 AI 應(yīng)用場景中，SQL 和向量結(jié)合可以極大增加數(shù)據(jù)建模的靈活性，并簡化開發(fā)流程。例如 MyScale 團隊與北京科學(xué)智能研究院合作的 Science Navigator 項目中，利用 MyScaleDB 對于海量的科學(xué)文獻數(shù)據(jù)做檢索和智能問答，其主要的 SQL 表結(jié)構(gòu)就有 10 多個，其中多張表結(jié)構(gòu)建立了向量和倒排表索引，并利用主鍵和外鍵做了關(guān)聯(lián)。系統(tǒng)在實際查詢中，也會涉及結(jié)構(gòu)化、向量和關(guān)鍵字數(shù)據(jù)的聯(lián)合查詢，以及幾張表的關(guān)聯(lián)查詢。在專用的向量數(shù)據(jù)庫中這些建模和關(guān)聯(lián)是難以實現(xiàn)的，也會導(dǎo)致最終的系統(tǒng)迭代緩慢、查詢低效和維護困難。
? ? ? ? ? ? ? ? ? ? ? ? ? ?Science Navigator 主要表結(jié)構(gòu)示意圖（加粗體的列建立了向量索引或倒排索引）支持結(jié)構(gòu)化、向量和關(guān)鍵字等數(shù)據(jù)聯(lián)合查詢在實際 RAG 系統(tǒng)中，檢索的精度和效果是制約其落地的主要瓶頸。這需要 AI 數(shù)據(jù)庫高效支持結(jié)構(gòu)化、向量和關(guān)鍵字等數(shù)據(jù)聯(lián)合查詢，綜合提高檢索精度。例如在金融場景中，用戶需要針對文檔庫查詢 “某公司 2023 年全球各項業(yè)務(wù)的收入情況如何？”，“某公司”，“2023 年” 等結(jié)構(gòu)化元信息并不能被向量很好的抓取，甚至不一定在對應(yīng)的段落中有直接的體現(xiàn)。直接在全庫上執(zhí)行向量檢索會得到大量的干擾信息，并降低系統(tǒng)最終的準確性。另一方面，公司名稱，年份等通常是可以作為文檔的元信息被獲取的，我們可以將 WHERE year=2023 AND company ILIKE "%<company_name>%" 作為向量查詢的過濾條件，從而精準的定位到相關(guān)信息，大幅提升了系統(tǒng)的可靠性。在金融、制造業(yè)、科研等場景中，MyScale 團隊都觀察到異構(gòu)數(shù)據(jù)建模和關(guān)聯(lián)查詢的威力，很多場景下甚至有?60% 精度到?90% 的提升。盡管傳統(tǒng)的數(shù)據(jù)庫產(chǎn)品都已經(jīng)陸續(xù)意識到了向量查詢在 AI 時代的重要性，并開始在數(shù)據(jù)庫中增加向量能力，其聯(lián)合查詢的精度仍然存在顯著的問題。例如，在過濾查詢的場景下，Elasticsearch 在過濾比例為 0.1 時，QPS 會降到只有 5 左右，而 PostgresSQL（使用 pgvector 插件）在過濾比例是 0.01 時，檢索精度只有 50% 左右，不穩(wěn)定的查詢精度 / 性能極大制約了其應(yīng)用的場景。而 MyScale 僅使用了 pgvector 36% 的成本和 ElasticSearch 12% 的成本，就能夠在各種不同過濾比例的場景下都實現(xiàn)高性能和高精度的查詢。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?在不同過濾比例場景下，MyScale 都用低成本實現(xiàn)了高精度和高性能查詢正因為向量檢索在大模型應(yīng)用中的重要性和高關(guān)注度，越來越多的團隊投入了向量數(shù)據(jù)庫這個賽道。大家一開始的關(guān)注點都是努力提升純向量搜索場景下的 QPS，不過純向量搜索是遠遠不夠的！在實戰(zhàn)的場景中，數(shù)據(jù)建模、查詢的靈活性和精準度以及平衡數(shù)據(jù)密度、查詢性能和成本是更為重要的議題。在 RAG 場景中，純向量查詢性能有 10x 的過剩，向量占用資源龐大，聯(lián)合查詢功能缺乏、性能和精度不佳往往是當下專有向量數(shù)據(jù)庫的常態(tài)。MyScaleDB 致力于在真實海量數(shù)據(jù)場景下 AI 數(shù)據(jù)庫的綜合性能提升，其推出的 MyScale Vector Database Benchmark 也是業(yè)內(nèi)首個在五百萬向量規(guī)模，不同查詢場景下比較主流向量數(shù)據(jù)庫系統(tǒng)綜合性能、性價比的開源評測系統(tǒng)，歡迎大家關(guān)注和提 issue。MyScale 團隊表示，AI 數(shù)據(jù)庫在真實應(yīng)用場景下還存在很大的優(yōu)化空間，他們也希望在實踐中不斷打磨產(chǎn)品并完善評測系統(tǒng)。MyScale Vector Database Benchmark 項目地址：https://github.com/myscale/vector-db-benchmark展望：AI 數(shù)據(jù)庫支撐的大模型 + 大數(shù)據(jù) Agent 平臺機器學(xué)習(xí) + 大數(shù)據(jù)驅(qū)動了互聯(lián)網(wǎng)和上一代信息系統(tǒng)的成功，而在大模型的時代背景下，MyScale 團隊也致力于提出新一代的大模型 + 大數(shù)據(jù)方案。以高性能的 SQL + 向量數(shù)據(jù)庫為堅實的支撐，MyScaleDB 提供了大規(guī)模數(shù)據(jù)處理、知識查詢、可觀測性、數(shù)據(jù)分析和小樣本學(xué)習(xí)的關(guān)鍵能力，構(gòu)建了 AI 和數(shù)據(jù)閉環(huán)，成為下一代大模型 + 大數(shù)據(jù) Agent 平臺的關(guān)鍵基座。MyScale 團隊已經(jīng)在科研、金融、工業(yè)、醫(yī)療等領(lǐng)域探索這套方案的落地。
隨著技術(shù)的快速發(fā)展，某種意義上的通用人工智能 (AGI) 有望在未來 5-10 年內(nèi)出現(xiàn)。關(guān)于這個問題，我們不禁要思考：是需要一個靜態(tài)、虛擬且與人類競爭的大模型，還是其他更加全面的解決方案？數(shù)據(jù)無疑是連接大模型、世界與用戶的重要紐帶，MyScale 團隊的愿景是將大模型和大數(shù)據(jù)有機結(jié)合，打造更加專業(yè)、實時、高效協(xié)作，同時亦充滿人性溫度和價值的 AI 系統(tǒng)。以上就是長文本殺不死RAG：SQL+向量驅(qū)動大模型和大數(shù)據(jù)新范式，MyScale AI數(shù)據(jù)庫正式開源的詳細內(nèi)容，更多請關(guān)注php中文網(wǎng)其它相關(guān)文章！
廣告
收藏
技術(shù)交流群
261
