随着生成式AI的飞速发展,很大一部分的查询会以“密集向量搜索”的方式执行。
原文链接:https://nextword.substack.com/p/vector-database-is-not-a-separate
作者 | JOHN HWANG译者| 弯月
责编 | 夏萌
出品 | CSDN(ID:CSDNnews)
在不久的将来,我们会看到:
其结果是,我们有必要考虑“向量数据库”是否有必要作为单独的数据库分类存在,还是仅仅是一个任何数据库都能提供的特性。
随着生成式AI的飞速发展,很大一部分的查询会以“密集向量搜索”的方式执行。相信任何数据库公司都不会无视这种负载。因此,相信绝大多数能够存储文本的数据库都会提供向量搜索。
实际上,这种“数据库的向量数据库化”正在进行中。
直到2023年第二季度之前,“向量搜索”还主要存在于数据库初创公司,如Pinecone、Milvus、Weaviate等。但现有的数据库产品很快捕捉到了这个需求,如今所有云厂商都进入了“向量搜索”市场。就连原本不卖数据库的Cloudflare也进入了市场。这是因为任何“与数据有关”的公司都想从RAG负载中分一杯羹。
但这并不仅仅是大公司们害怕自己错失良机。现有的数据库产品提供向量搜索是合理的选择,这样就不需要将数据库移动到专门的向量数据库。同一个数据库中同时搜索向量和原始文档也能降低延迟。因此,现有的数据库进入这个市场,对客户是有利的。
一般而言,独立的向量数据库会带来额外的开销和复杂性。假如你使用MongoDB,在多个地区的数据库中保存了几亿个文档。如果使用独立的向量数据库,比如Pinecone,就意味着可能要在两个数据库之间跨地区传递数十亿个嵌入。这部分成本非常高,更不用说额外的复杂性了,因为你还要自己生成嵌入。
而使用一个支持向量搜索的数据库(比如Mongo或Elastic),就可以更快、更便宜、更简单。
当然,提供向量搜索也是一种防御措施。RAG是生成式AI最大的两种负载之一(另一种是推断)。不提供向量搜索意味着放弃RAG负载,就会导致客户迁移到其他数据库。这对于数据库公司是一种威胁。
现有的数据库会越来越多地支持RAG负载的整个生命周期,包括生成嵌入。
这种融合趋势将产生一些后果:
▶ 苹果承认iPhone 15系列存在烧屏问题,但拒绝召回;Win11用户量将达5亿;Node.js 21发布 | 极客头条
▶揭秘高效编程“武功秘笈”,手把手带你写一波!
▶中国大模型掌门人首次集结、全球研发中心掌门人齐聚现场,1024 程序员节「岳麓对话」重磅官宣!