韩雪冬个人网站,网站备案核验照片背景,品牌海外推广,图片设计网站有哪些更多技术交流、求职机会#xff0c;欢迎关注字节跳动数据平台微信公众号#xff0c;回复【1】进入官方交流群 背景
随着LLM#xff08;Large Language Model#xff09;的不断发展#xff0c;向量检索也逐渐成为关注的焦点。LLM通过处理大量的文本数据#xff0c;获取丰… 更多技术交流、求职机会欢迎关注字节跳动数据平台微信公众号回复【1】进入官方交流群 背景
随着LLMLarge Language Model的不断发展向量检索也逐渐成为关注的焦点。LLM通过处理大量的文本数据获取丰富的语义信息从而能够更好地理解和生成自然语言。然而LLM的输出通常是一系列概率分布这使得检索过程变得复杂。向量检索作为一种有效的检索方法它将LLM的输出转化为向量表示并利用向量之间的相似性来进行匹配。这种方式不仅能够直观地展示语义关系还提高了检索的效率和准确性。因此随着LLM的发展向量检索也相应地迎来了更多关注和研究。
对于向量检索来说一方面Milvus、Qdrant等专用向量数据库的出现提供了完备的向量检索能力另一方面也有一些数据库在自身基础上扩展出向量检索能力。作为火山引擎推出的一款云原生数据仓库ByteHouse近期推出高性能向量检索功能通过支持多种向量检索算法以及高效的执行链路可以支撑级大规模向量检索场景并达到毫秒级的查询延迟。
本篇内容将主要主要介绍向量检索的基本原理分析“专用向量数据库”与“数据库向量扩展”优劣势并介绍以ByteHouse为代表的具备向量检索能力的数据仓库应用场景。
向量检索介绍
概念解析
向量数据库的核心实现原理是向量化存储和索引技术。向量化存储是将向量数据转换为二进制格式进行存储以提高存储效率和查询速度。向量索引是将向量数据进行索引以便快速地进行相似度匹配和聚类分析等操作。
向量数据库中的向量是由多个维度组成的每个维度代表向量的一个特征。例如一张图片可以表示为一个三维向量分别代表图片的宽度、高度和颜色。向量数据库中的向量可以是稠密向量或稀疏向量稠密向量是指向量中大部分维度都有值稀疏向量是指向量中只有少数维度有值。
工作原理
向量数据库能够快速检索与查询相似的对象是因为它们已经预先计算了这些相似度。其中的基本概念称为近似最近邻ANN搜索它使用不同的算法进行索引和相似度计算。
当你拥有数百万个嵌入时使用简单的 K 近邻kNN算法计算查询与你拥有的每个嵌入对象之间的相似度会变得耗时。通过使用近似最近邻搜索你可以在一定程度上牺牲一些准确性以换取速度并检索出与查询近似最相似的对象。索引 - 为此向量数据库对向量嵌入进行索引。这一步将向量映射到一种数据结构中以实现更快的搜索。
数据预处理
在向量化存储之前需要对原始数据进行预处理包括数据清洗、特征提取和特征归一化等步骤。例如在文本向量化中需要对文本进行分词、去停用词和词干提取等处理然后使用词袋模型或词向量模型将文本转换为向量。
向量编码
将向量数据编码为二进制格式以便存储到磁盘或内存中。常用的向量编码方法有二进制编码、哈希编码和压缩编码等。哈希编码是将向量映射到一个哈希表中以便快速地进行相似度匹配。压缩编码是将向量中的冗余信息进行压缩以减少存储空间。
存储管理
将编码后的向量数据存储到磁盘或内存中需要进行存储管理包括数据分片、数据压缩和数据索引等步骤。数据分片是将向量数据分成多个块以便分布式存储和查询。数据压缩是将向量数据进行压缩以减少存储空间。数据索引是将向量数据进行索引以便快速地进行相似度匹配和聚类分析等操作。
数据查询
向量化存储后需要进行数据查询包括相似度匹配和聚类分析等操作。相似度匹配是指在向量数据库中查找与查询向量最相似的向量常用的相似度计算方法有余弦相似度和欧几里得距离等。聚类分析是指将向量数据分成多个簇以便进行数据分析和挖掘。
索引方式
向量检索算法基于其存储结构大致可分为四种。
第一种是 Table-based典型算法如 LSH。LSH 算法的核心思想是通过哈希函数将相似的向量映射到相同的哈希桶中从而实现高效的相似性搜索。这种方法能够在高维向量空间中快速找到相似的向量对为相似性搜索提供了一种高效的近似解决方案。第二种是 Tree-based。这是一种用于向量检索的索引方法。它利用树形数据结构如B树或平衡树来组织和管理向量数据使得向量的查找、插入和删除操作能够在对数时间内完成。这种索引方法对于大规模和高维度的向量数据集非常有效能够显著提高向量检索的效率。第三种是 Cluster-based也称为 IVFInverted File把向量先进行聚类处理检索时首先计算出最近的 k 个聚类中心再在这些聚类中心中计算出最近的 k 个向量。这种索引的优点是构建速度快因为构建时只需要多一个 training 的过程。相比于其他常用索引主要是 Graph-based 索引只需要额外存储倒排表和聚类中心结构所以内存额外占用比较少。但也存在相应的缺点由于每次查询要把聚类中心里面所有的向量都遍历一遍所以它的查询速度受维度信息影响较大且高精度查询计算量比较大计算开销大。这类索引通常还会结合一些量化算法来使用包括 SQ、PQ等。第四种是Graph-based 把向量按照相似度构建成一个图结构检索变成一个图遍历的过程。常用算法是HNSW。它基于关系查询并以构建索引时以及构建向量之间的关系为核心而主要技术则是highway和多层优化方式。这种算法的优点是查询速度快、并发性能好而缺点则表现为构建速度慢、内存占用高。
目前实际场景中使用较多的方法主要是后面的两种即 Cluster-based 和 Graph-based。
为什么OLAP引入向量检索
向量数据库目前还处于一个快速发展的阶段目前看有两个趋势
第一种是以专用向量数据库为基础不断添加更多复杂的数据类型支持以及更多的数据管理机制比如存算分离、一致性支持、实时导入等。此外查询上也在不断添加前后置过滤等复杂查询策略的支持。
第二种构建思路是数据库加向量检索扩展继续去支持更多的向量检索算法并且不断按照向量检索的需求添加特殊的过滤策略、简化对应的执行计划。
以上两种构建思路都在向一个统一的目标去汇合即带有高性能向量检索与完备数据管理和查询支持的数据库形态。
提升多维数据处理能力
随着大数据时代的来临数据量呈爆炸式增长用户需要更高效、更精准的数据分析工具来帮助他们快速理解数据背后的趋势和模式。向量检索能力的引入可以将数据从表格形式转化为向量表示利用机器学习算法对数据进行相似性匹配和聚类分析。这使得用户能够更快速地找到与查询条件相似的数据进行更深入的数据探索和洞察。因此引入向量检索能力是OLAP产品提升用户体验和满足用户需求的重要方向之一。
作为一款OLAP引擎ByteHouse在支持结构化数据的单表、多表复杂查询计算基础上扩展了向量检索能力支持向量数据存储、索引和高效检索从而支持商品推荐、智能问答系统、图片搜索、视频检索等应用场景。
基于 vector-centric 的思路ByteHouse 重新构建了高效的向量检索执行链路结合索引缓存、存储层过滤等机制使得性能实现进一步突破。另外为了应对不同使用场景ByteHouse 支持了 HNSW、Flat、IVFFlat、IVFPQ 等多种常见向量索引算法。此外新引入的向量索引支持当前的二级索引相关语义新的执行链路也对现有距离函数进行了适配以降低用户使用门槛和学习成本用户可以直接用 ClickHouse 的现有语义来使用高性能的向量检索功能。 支持更复杂的分析场景
向量检索的核心功能是能检索任意数据对象的相似度比如文本、图片、视频、声音等一切数字化内容的相似度因此以文本相似度检索、问答检索、图片声音视频检索、智能推荐为核心功能的应用场景都可以基于向量检索能力来构建。核心应用场景如下表所示
行业应用场景互联网电商商品以图搜搜互联网社交图像去重、视频原创验证、风控审核、关联推荐、舆情监控政府机构视频检索、指纹搜索、人体图像检索、车辆查找、内容查重金融文本检索、智能客服零售商品识别、自动售货机
大模型场景
大模型类应用主要有企业知识库、智能问答、大模型辅助系统、创作助手内容创作领域)等将企业行业深度相关的内容进行分割、整理录入到数据库中供下游使用包括企业员工的检索访问、企业内部问答访问、配合大模型更加智能有逻辑地回答问题。
以企业专属问答知识库为例将文档片段全部向量化通过语言模型如bert等存到ByteHouse。如果用户输入问题则对问题语句进行向量化以余弦相似度或点积等指标计算在向量数据库中和问题向量最相似的top k个文档片段通过大模型的上下文组织能力将查询结果包装成标准回答返回给应用系统。
在数据量较大而且需要做逻辑分割管理对于性能要求在几十ms到一两百ms对召回率要求较高。ByteHouse的优势是性能好、扩展性好能支撑海量数据集、支持SQL易用性好。
商品搜索和推荐
在电商场景中采用标量数据条件检索与图片检索相结合的方式搜索商品让用户能更直观地搜索到感兴趣的商品也可以基于向量相似度检索功能实现相似商品推荐功能。
例如用户要检索发货地在上海价格区间为200-1000元风格为韩版并与上传的一张图片相似度高的衣服。采用ByteHouse能用一条SQL同时对标量数据和向量数据进行检索简单易用检索性能高。 图片视频搜索
以图搜图这是向量检索在图片搜索中的常见应用。用户可以通过上传一张图片系统会返回与该图片相似的图片。这背后的原理是将图片转化为向量然后计算查询向量与数据库中其他向量之间的相似度从而找出相似的图片。视频处理在视频处理方面向量检索可以用于实时跟踪视频中的对象轨迹或者检索与特定动作或场景相似的视频片段。
如下图所示ByteHouse支持上传一张图片并输入时间、相似度、信息来源等条件检索全网视频中与目标图片相似视频该场景利用了ByteHouse的标量数据与向量数据混合检索能力采用如下的SQL语句即可进行快速检索:
SELECT unique_id,create_time,image_url,platform,update_time,post_category,post_id, post_publish_time,dist
FROM qian.photo_vec7
WHERE (post_publish_time 2023-11-22 11:00:00) AND (post_publish_time 2023-11-24 11:00:00) WHERE (post_category 1)
ORDER BY cosineDistance(vector, [10, 5, 23, 17, 9, 9, 3, 12, 32, 40, 32, 3, 8, 26, 26, 54, 93, 91, 8, 7, 41, 22, 19, 119, 5, 8, 77, 33, 61, 55,, 56]) AS dist ASC LIMIT 100;向量检索产品如何选型
向量检索能力比较
目前支持向量检索功能的产品主要有专业的向量数据库例如Milvus、Qdrant另外其他数据库产品如开源社区ClickHouse也支持了向量检索。我们从扩展性、易用性、混合负载能力等角度对比如下
MilvusQdrantESClickHouseByteHouse易扩展性存储计算分离存储计算耦合存储计算耦合存储计算耦合存储计算分离易用性自定义API不支持SQL自定义 API不支持 SQL自定义 API不支持 SQL支持较全的SQL语法支持较全的SQL语法混合负载能力支持基于简单类型标量的过滤不支持聚合支持基于简单标量类型过滤支持基于某个特定标量的 group by 操作group by key 必须为 string 或 integer 类型支持OLAP和vector search混合场景1.支持OLAP和vector search混合场景2.支持optimizer可以实现混合负载的CBO自动优化索引类型HNSW/IVF类索引/DiskANN 等HNSWAnnoyHNSW/IVFPQ/DiskANN等支持的数据类型较少较少支持常见数据类型支持常见数据类型单表是否支持多个vector否是是是检索性能高中低中高
选型总结
总结来看与专用向量数据库相比ByteHouse作为一款OLAP引擎还支持结构化非结构化数据具备更广泛的应用场景并且ByteHouse存储计算分离架构更容易解决向量数据库 index 构建任务重影响正常读写的问题。
在性能上一方面ByteHouse本身高性能查询特性为向量搜索相关查询提供高效率的执行底座另一方面ByteHouse 查询优化器能力在混合查询下可以根据 cost 去选择最优计划让查询性能更优。在功能上ByteHouse具备较全的 SQL 语法支持 并且还提供了大量的函数支持用户构造复杂的结构化数据与非结构化数据的混合查询语句具备灵活性、易用性。
通过将向量能力扩展到OLAP引擎上企业可以获得高效性能、集成便利、丰富的分析功能、可扩展性和成熟的生态系统等优势。这些优势可以帮助企业更好地利用向量数据进行高效的数据分析和挖掘从而更好地支持决策和业务发展。
点击跳转火山引擎ByteHouse了解更多
