在那些大型语言模型LLMs火起来以后, 向量搜索技术也随之火了起来。当下存在像这样各类的专业向量数据库, 还有FAISSAI这般的库, 以及那些能够在传统数据库里集成的向量搜索插件。我们所撰写的这篇文章, 目的在于深入挖掘向量数据库究竟是什么, 并且要探讨向量搜索的复杂程度, 以比较向量数据库、向量搜索插件以及向量搜索库之间存在的不同之处。拥有那种能于一堆数量众多、排列紧密的向量数据里, 找出与给定的查询向量最为相似的若干结果这样特性的技术, 被称作向量搜索, 也可以叫做向量相似性搜索。在正式开启搜索举措之前, 咱们势必借助神经网络, 把关那些包含文本、图像、视频以及音频等的非结构化数据, 转变成高维数值向量, 也就是那所谓的嵌入向量。一旦获取到这些嵌入向量之后, 向量搜索引擎便能计算出它们与查询向量之间的空间距离, 距离越短, 相似度便会越高。现如今, 在市面上存有好多数量的向量搜索技术, 其中并非仅有像NumPy这般的机器学习库, 还存在如FAISS这类的向量搜索库, 而且有基于传统数据库所构建而成的向量搜索插件, 以及如此类型的专业向量数据库。然而, 专门的向量数据库并非是进行相似性搜索的仅有选项。在向量数据库问世以前, 诸如FAISS、ScaNN以及HNSW Small这般的向量搜索库, 便已然被广泛运用于向量检索当中了。能帮我们快速搭建起一个高性能的原型向量搜索系统的是这些向量搜索库, 就拿FAISS来说, 它是Meta开发的开源库, 其专门用于做高效的相似性搜索以及密集向量聚类, FAISS能够处理任何大小的向量集合, 哪怕是大到不能完全装进内存里的集合, 而且, FAISS还提供了评估以及参数调整的工具, 虽然FAISS是由C 编写的, 但它提供了/NumPy接口。然而, 这些向量搜索库仅仅是轻量级的近似最近邻, 也就是 ANN 库, 并非全托管的解决办法, 功能方面还存在少许限定。针对小规模且有限的数据集合, 这些库说不定够用, 就算是在生产环境里。可是, 一旦数据集合变大, 用户增多, 处理规模问题就愈发棘手。并且, 它们不许可对索引数据作出任何更改, 在数据导入之际也无法进行查询。与之相较, 向量数据库可算是料理非结构化数据保存和查找的更优良解决方法它们能够储存以及查询数百万加之数十亿个向量, 与此同时还能够给予实时回应它们相当灵活能够与用户持续增长的业务需求相适配。并且, 针对结构化以及半结构化数据而言, 如此这般的向量数据库具备诸多对用户十分友好的特性, 诸如云原生特性, 还有多租户特性, 以及可扩展性特性等等。涉及向量数据库以及向量搜索库, 于运作的抽象层面而言, 二者是全然不一样的, 向量数据库属于完整的服务, 然而ANN库却得被集成到你正着手开发的应用程序里。从这个意义来讲, ANN库仅仅是构建向量数据库的诸多组件当中的一个, 恰似建立在之上那般。当我们提及将某些全新的并非结构化的数据添加至向量数据库之中时, 这个工具简直便利到了极点。你瞧, 仅仅是这么不多的几行代码:from pymilvus import Collection collection Collection(book) mr collection.insert(data)仅需三行代码, 便可完成然而, 要是你运用的是诸如FAISS或者ScaNN这类库, 状况就并非如此简单了。在关键节点, 你必须手动重新构建整个索引, 这无疑麻烦许多。即便能够达成, 这些库在可扩展性以及支持多用户层面依旧成效不佳, 而这俩方面可都是向量数据库的关键优势所在啊。当前, 咱们已然弄明白了向量搜索库跟向量数据库之间的不一样之处, 接下来, 再瞧瞧向量数据库与向量搜索插件存在何种区别。你瞧着, 现今诸多那种传统样式的关系数据库以及搜索系统, 像和这种, 都已然开始往内部安置向量搜索插件了。就以8.0来讲, 它能够借助API端点去插入向量以及开展ANN搜索。然而, 这些向量搜索插件所存在的局限性是颇为显著的——它们并未拥有全面管理嵌入连同向量搜索的方式。它们更偏向于给现有的架构去打补丁, 功能存在限制, 而且也并非那么地优化。在传统数据库之上搞非结构化数据应用, 恰似你硬是要于燃油汽车里头去安装锂电池以及电动机, 这事情听起来就不太靠谱凭什么要这么讲呀? 是由于那些向量搜索插件欠缺两样关键的事物——可调节性以及好用的应用程序编程接口/软件开发工具包。我依旧是以人工神经网络引擎来当作实例的, 别的插件状况也大致相同, 我就不再过多阐述了。它支持借助这种数据字段类型去对向量进行存储, 并且还能够经由端点来实施查询:PUT index { mappings: { properties: { image-vector: { type: dense_vector, dims: 128, index: true, similarity: l2_norm } } } } PUT index/_doc { image-vector: [0.12, 1.34, ...] }GET index/_knn_search { knn: { field: image-vector, query_vector: [-0.5, 9.4, ...], k: 10, num_candidates: 100 } }拥有的ANN插件, 其仅能够运用一种索引算法此算法为Small, 简称为HNSW。并且它单单采用L2/欧几里得距离, 用以衡量向量之间的相似度。这虽说算是个不坏的起始, 然而同这种完备的向量数据库相比较而言, 仍旧略显逊色。用于操作时, 呈现出来的样子是这样的: field1 FieldSchema(nameid, dtypeDataType.INT64, descriptionint64, is_primaryTrue) field2 FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, descriptionembedding, dim128, is_primaryFalse) schema CollectionSchema(fields[field1, field2], descriptionhello world collection) collection Collection(namemy_collection, dataNone, schemaschema) index_params { index_type: IVF_FLAT, params: {nlist: 1024}, metric_type: L2} collection.create_index(embedding, index_params) search_param { data: vector, anns_field: embedding, param: {metric_type: L2, params: {nprobe: 16}}, limit: 10, expr: id_field 0 } results collection.search(**search_param)你瞧, 尽管和都能够去创建索引能够插入向量, 还能够进行最近邻搜索, 然而的API更为直观, 所支持的索引以及距离度量方式也更为多样, 可调性更为优良。往后还会去支持更多种类的向量索引, 甚至于能够运用类似SQL的语句来开展查询, 这便使得它的可调性以及易用性更上一个台阶。简要来讲, 它比那些向量搜索插件强出许多, 原因在于它原本就是为了构建向量数据库而专门设计的, 其具备更为丰富的功能, 并且架构也更加适宜去处理非结构化数据。要说并非所有向量数据库都毫无二致, 每个都存有其独具一格之处, 适配各异场景。针对那些仅需处置几百万向量的小规模生产环境而言, 向量搜索库以及插件还算得上友好, 要是你的数据量不大, 仅需基础的向量搜索功能, 这些技术便够用了。然而, 要是你的业务有着对上亿向量进行处理的需求的时候, 并且还得要那种具备及时响应能力的情况, 那么专业的向量数据库, 举例来说, 就会是我们所优先选择的对象了。