网站帮企业做推广价格怎么算,网站建设三网合一是什么,如何能让网站尽快备案通过,成都建立网站更多技术交流、求职机会#xff0c;欢迎关注字节跳动数据平台微信公众号#xff0c;回复【1】进入官方交流群 向量检索被广泛使用于以图搜图、内容推荐以及大模型推理等场景。随着业务升级与 AI 技术的广泛使用#xff0c;用户期望处理的向量数据规模越来越大#xff0c;对… 更多技术交流、求职机会欢迎关注字节跳动数据平台微信公众号回复【1】进入官方交流群 向量检索被广泛使用于以图搜图、内容推荐以及大模型推理等场景。随着业务升级与 AI 技术的广泛使用用户期望处理的向量数据规模越来越大对向量数据库产品的稳定性、易用性与性能需求也越来越高。为此火山引擎 ByteHouse 团队基于社区 ClickHouse 进行技术演进提出了全新的向量检索功能设计思路满足业务对向量检索稳定性与性能方面的需求。 在 12 月 28-29 日上海 QCon 全球软件开发大会上火山引擎 ByteHouse 技术专家田昕晖将分享基于《云原生数仓 ByteHouse 构建高性能向量检索技术实践》话题。以下是 InfoQ 与火山引擎 ByteHouse 的十问十答将提前为您揭秘一款 OLAP 引擎将如何设计高性能向量检索能力。 1、InfoQ能否详细介绍一下向量检索在大型语言模型LLM中的具体应用例如它是如何改进语言理解和数据处理的 火山引擎 ByteHouse 简单来说基于向量检索技术以及向量数据库可以为 LLM 提供一个外置的记忆单元通过提供与问题及历史答案相关联的内容协助 LLM 返回更准确的答案。
LLM 受限于训练时数据集的时效与规模面对细分领域知识与最新内容的查询很难给出准确的答案。基于检索增强生成技术Retrieval-augmented generation 简称 RAG即基于问题和历史答案从外部知识库中检索相似结果作为 prompts 提供给 LLM 以获取到更准确答案的方式是一种主要的解决方法而向量检索就是 RAG 常用的技术。
由于向量检索主要是基于语义相似度来检索结果搜索的对象是向量信息相比传统的文本检索来说结果更为准确速度也更快。另一方面LLM 的 prompts 会有一定的长度限制过长的 prompts 也会增加 LLM 的处理时间通过文本切块 向量检索技术可以在 prompts 受限的情况下得到更为准确的结果在保证准确度的同时也能确保较低的 LLM 响应延时。 2、InfoQ在 LLM 的背景下向量检索技术面临哪些独特的挑战和机遇 火山引擎 ByteHouse 这里与向量数据库的挑战结合来谈。
一个是易用性与易维护性当前已经发展出了很多的向量检索算法与向量数据库是否能快速接入 LLM 调用链路中以及如何维护如何与现有的组件协作如何去做数据传输都会是用户选择会考虑的因素。
一个是成本很多 ANN 算法库都需要将结构常驻内存来提升计算性能这在数据规模较大的场景无疑会提升用户的使用成本如何在不降低准确度、不增加显著的构建开销的情况下做到更低的资源占用也是向量检索技术与向量数据库当前面临的一个挑战。
LLM 的出现对于向量检索与向量数据库无疑是一个非常好的发展机会后续随着 LLM 以及大量其他非结构化数据检索需求的增加向量检索与向量数据库会得到更多的关注成为一种常规技术。 3、InfoQ您如何看待当前向量数据库技术的发展趋势 火山引擎 ByteHouse 当前向量数据库的发展主要是两种思路一种是从 0 开始建议一个专用的向量数据库一种是基于现有数据库系统扩展支持向量检索功能。专用向量数据库大致的方向是以向量数据为中心设计存储结构与相应的读写机制并且简化查询执行的调用链路使用比较固定的 pattern 来执行查询降低查询语句的解析开销。
采用这种方案的一些系统也在逐渐去提供更为复杂的数据管理机制比如读写分离、WAL、数据分区等等。查询上也在不断去支持更多的数据类型更为直观的查询 API 等。这些其实都是在补齐和传统数据库使用上的一些差别在向一个完整数据库系统去演进。
而另一种扩展现有数据库的思路则是基于现有数据库的数据管理机制以及查询执行链路中去添加向量检索技术的支持包括向量索引的支持查询执行的优化等等是在一个现有框架的基础上支持了一种新的计算模式。
在我看来两种思路目前正在互相借鉴向一个中间状态去演化各自有比较适用的场景。后续可能也会出现一种新的模块化向量检索的路线即一个封装好基本向量数据存储与向量检索查询执行的模块以一种嵌入式的方式接入到不同系统中以支持多样化的向量检索使用需求。 4、InfoQ相比于传统的数据库技术向量数据库在处理大规模数据方面有哪些明显的优势 火山引擎 ByteHouse 向量数据库的核心是通过支持一种或多种的向量索引来加速向量检索相关的计算。此类索引通常会维护一个额外的内部结构来组织所有的向量数据以降低检索时比较计算的执行次数。
传统数据库通常只能以全行扫描 相似度计算的方式来执行向量检索而基于向量索引可以通过很少的计算来快速得到近似的结果因此性能会远好于传统数据库的处理方式一般会有几十到几百倍的性能提升。 5、InfoQ您能详细介绍一下 ByteHouse 在设计向量检索功能时的核心创新点吗在向量检索技术的开发和实施过程中您遇到了哪些主要的挑战 火山引擎 ByteHouse 主要的创新点在于
支持较为常用的 HNSW、IVFPQ、IVFPQFastScan 等多种类型的向量索引以应对不同的应用使用场景。同时对于这些向量索引的操作是基于 ByteHouse 现有的索引操作命令进行的扩展对用户来说几乎没有学习成本易于上手。
基于向量检索的应用特点我们也对执行链路进行了重建结合索引缓存、存储层过滤等机制性能可以达到市场上主流向量数据库的标准。
主要挑战在于ByteHouse 列存结构存在的读放大问题这部分我们通过向量检索计算前置以及存储层过滤等方式进行了优化显著降低了 IO 开销。
新写入数据以及服务重启会存在冷读的问题导致性能波动。为此我们引入索引的 preload 机制索引构建后自动载入缓存同时支持对过期索引自动淘汰避免多余的资源占用
索引构建会消耗比较多的资源为了降低构建操作对正常查询的性能影响我们引入针对构建操作的资源控制策略允许用户基于使用场景动态控制索引构建使用的资源。 6、InfoQByteHouse 是如何解决向量检索中的性能和稳定性问题的在开发过程中有哪些关键的技术创新或策略调整 火山引擎 ByteHouse 如上面提到的ByteHouse 中支持向量检索最大的问题是列存带来的读放大问题这个我们在 query 执行以及数据读取层都做了对应的优化目标就是减少不必要的数据读取操作。向量检索功能在 ByteHouse 的 HaMergeTree 以及 HaUniqueMergeTree 上都有支持基于两种引擎的可靠性方案来提供稳定性保障。
在开发过程中我们发现 ByteHouse 现有的基于索引的执行链路对于向量检索类型负载来说会有很多额外的读取和计算开销。为此我们基于此类应用的特性重建了执行链路移除了不必要的计算操作结合行粒度的计算层与存储层的过滤下推极大减少了原有链路的开销达到了几十倍的性能提升。 7、InfoQ您能提供一些 ByteHouse 在性能方面相较于其他解决方案的具体数据或案例吗 火山引擎 ByteHouse 我们最近基于业界最新的 VectorDBBench 测试工具做了测试在 cohere 1M 标准测试数据集上recall 95 以上的情况可以取得 2600 的 QPSp99 时延在 15ms 左右。对比多种专用向量数据库性能也有明显的优势。 8、InfoQ在实际应用中ByteHouse 的向量检索功能有哪些显著的成功案例 火山引擎 ByteHouse 在最近的一个以图搜图的场景中6 亿数据有写入的情况下只使用 ES 1/5 的资源全量搜索 top1000 可以做到 200ms 左右的延迟top10 可以做到 30ms 以内的延迟相比其他竞品有几倍的性能优势。 9、InfoQ您如何看待向量检索技术在未来的发展前景了解到有许多在向量数据库创业的企业您觉得这个方向如何 火山引擎 ByteHouse 向量检索技术会成为一种数据库领域的常规技术会有越来越多的传统数据库支持向量检索的技术也会有更多更易用性能更强的向量检索算法以及算法库出现。这个方向目前还处于较早期的阶段产品形态也还在探索有很多的机会和可能性。 10、InfoQ您认为接下来在这个领域将会出现哪些新的创新点或挑战 火山引擎 ByteHouse 一个是检索算法与索引方面的创新包括自适应参数调优early termination、与 filter 的结合、向量压缩、分布式检索结构等方面
一个是系统方面的创新包括实时向量检索、嵌入式向量检索模块、索引推荐、数据隐私保护等方面
更多精彩欢迎关注上海 QCon 全球软件开发大会 点击跳转ByteHouse了解更多
