十问 ByteHouse：如何基于 ClickHouse 玩转向量检索？

向量检索被广泛使用于以图搜图、内容推荐以及大模型推理等场景。随着业务升级与 AI 技术的广泛使用，用户期望处理的向量数据规模越来越大，对向量数据库产品的稳定性、易用性与性能需求也越来越高。为此火山引擎 ByteHouse 团队基于社区 ClickHouse 进行技术演进，提出了全新的向量检索功能设计思路，满足业务对向量检索稳定性与性能方面的需求。

在 12 月 28-29 日上海 QCon 全球软件开发大会上，火山引擎 ByteHouse 技术专家田昕晖将分享基于《云原生数仓 ByteHouse 构建高性能向量检索技术实践》话题。以下是InfoQ与火山引擎ByteHouse的十问十答，将提前为您揭秘一款 OLAP 引擎将如何设计高性能向量检索能力。

InfoQ：能否详细介绍一下向量检索在大型语言模型（LLM）中的具体应用？例如，它是如何改进语言理解和数据处理的？

火山引擎 ByteHouse： 简单来说，基于向量检索技术以及向量数据库可以为 LLM 提供一个外置的记忆单元，通过提供与问题及历史答案相关联的内容，协助 LLM 返回更准确的答案。

LLM 受限于训练时数据集的时效与规模，面对细分领域知识与最新内容的查询很难给出准确的答案。基于检索增强生成技术（Retrieval-augmented generation， 简称 RAG），即基于问题和历史答案，从外部知识库中检索相似结果作为 prompts 提供给 LLM ，以获取到更准确答案的方式是一种主要的解决方法，而向量检索就是 RAG 常用的技术。

由于向量检索主要是基于语义相似度来检索结果，搜索的对象是向量信息，相比传统的文本检索来说，结果更为准确，速度也更快。另一方面，LLM 的 prompts 会有一定的长度限制，过长的 prompts 也会增加 LLM 的处理时间，通过文本切块 + 向量检索技术，可以在 prompts 受限的情况下得到更为准确的结果，在保证准确度的同时也能确保较低的 LLM 响应延时。

InfoQ：在 LLM 的背景下，向量检索技术面临哪些独特的挑战和机遇？

火山引擎 ByteHouse ： 这里与向量数据库的挑战结合来谈。

一个是易用性与易维护性，当前已经发展出了很多的向量检索算法与向量数据库，是否能快速接入 LLM 调用链路中，以及如何维护，如何与现有的组件协作，如何去做数据传输，都会是用户选择会考虑的因素。

一个是成本，很多 ANN 算法库都需要将结构常驻内存来提升计算性能，这在数据规模较大的场景无疑会提升用户的使用成本，如何在不降低准确度、不增加显著的构建开销的情况下做到更低的资源占用，也是向量检索技术与向量数据库当前面临的一个挑战。

LLM 的出现对于向量检索与向量数据库无疑是一个非常好的发展机会，后续随着 LLM 以及大量其他非结构化数据检索需求的增加，向量检索与向量数据库会得到更多的关注，成为一种常规技术。

InfoQ：您如何看待当前向量数据库技术的发展趋势？

火山引擎 ByteHouse： 当前向量数据库的发展主要是两种思路，一种是从 0 开始建议一个专用的向量数据库，一种是基于现有数据库系统扩展支持向量检索功能。专用向量数据库大致的方向是以向量数据为中心设计存储结构与相应的读写机制，并且简化查询执行的调用链路，使用比较固定的 pattern 来执行查询，降低查询语句的解析开销。

采用这种方案的一些系统也在逐渐去提供更为复杂的数据管理机制，比如读写分离、WAL、数据分区等等。查询上也在不断去支持更多的数据类型，更为直观的查询 API 等。这些其实都是在补齐和传统数据库使用上的一些差别，在向一个完整数据库系统去演进。

而另一种扩展现有数据库的思路，则是基于现有数据库的数据管理机制以及查询执行链路中去添加向量检索技术的支持，包括向量索引的支持，查询执行的优化等等，是在一个现有框架的基础上，支持了一种新的计算模式。

在我看来，两种思路目前正在互相借鉴向一个中间状态去演化，各自有比较适用的场景。后续可能也会出现一种新的模块化向量检索的路线，即一个封装好基本向量数据存储与向量检索查询执行的模块以一种嵌入式的方式接入到不同系统中，以支持多样化的向量检索使用需求。

InfoQ：相比于传统的数据库技术，向量数据库在处理大规模数据方面有哪些明显的优势？

火山引擎 ByteHouse： 向量数据库的核心是通过支持一种或多种的向量索引，来加速向量检索相关的计算。此类索引通常会维护一个额外的内部结构来组织所有的向量数据，以降低检索时比较计算的执行次数。

传统数据库通常只能以全行扫描 + 相似度计算的方式来执行向量检索，而基于向量索引，可以通过很少的计算来快速得到近似的结果，因此性能会远好于传统数据库的处理方式，一般会有几十到几百倍的性能提升。

InfoQ：您能详细介绍一下 ByteHouse 在设计向量检索功能时的核心创新点吗？在向量检索技术的开发和实施过程中，您遇到了哪些主要的挑战？

火山引擎 ByteHouse： 主要的创新点在于：

支持较为常用的 HNSW、IVFPQ、IVFPQFastScan 等多种类型的向量索引，以应对不同的应用使用场景。同时对于这些向量索引的操作是基于 ByteHouse 现有的索引操作命令进行的扩展，对用户来说几乎没有学习成本，易于上手。

基于向量检索的应用特点，我们也对执行链路进行了重建，结合索引缓存、存储层过滤等机制，性能可以达到市场上主流向量数据库的标准。

主要挑战在于：ByteHouse 列存结构存在的读放大问题，这部分我们通过向量检索计算前置以及存储层过滤等方式进行了优化，显著降低了 IO 开销。

新写入数据以及服务重启会存在冷读的问题，导致性能波动。为此我们引入索引的 preload 机制，索引构建后自动载入缓存，同时支持对过期索引自动淘汰，避免多余的资源占用

索引构建会消耗比较多的资源，为了降低构建操作对正常查询的性能影响，我们引入针对构建操作的资源控制策略，允许用户基于使用场景动态控制索引构建使用的资源。

InfoQ：ByteHouse 是如何解决向量检索中的性能和稳定性问题的？在开发过程中，有哪些关键的技术创新或策略调整？

火山引擎 ByteHouse： 如上面提到的，ByteHouse 中支持向量检索最大的问题是列存带来的读放大问题，这个我们在 query 执行以及数据读取层都做了对应的优化，目标就是减少不必要的数据读取操作。向量检索功能在 ByteHouse 的 HaMergeTree 以及 HaUniqueMergeTree 上都有支持，基于两种引擎的可靠性方案来提供稳定性保障。

在开发过程中，我们发现 ByteHouse 现有的基于索引的执行链路对于向量检索类型负载来说，会有很多额外的读取和计算开销。为此，我们基于此类应用的特性重建了执行链路，移除了不必要的计算操作，结合行粒度的计算层与存储层的过滤下推，极大减少了原有链路的开销，达到了几十倍的性能提升。

InfoQ：您能提供一些 ByteHouse 在性能方面相较于其他解决方案的具体数据或案例吗？

火山引擎 ByteHouse： 我们最近基于业界最新的 VectorDBBench 测试工具做了测试，在 cohere 1M 标准测试数据集上，recall 95 以上的情况，可以取得 2600+ 的 QPS，p99 时延在 15ms 左右。对比多种专用向量数据库，性能也有明显的优势。

InfoQ：在实际应用中，ByteHouse 的向量检索功能有哪些显著的成功案例？

火山引擎 ByteHouse： 在最近的一个以图搜图的场景中，6 亿数据有写入的情况下，只使用 ES 1/5 的资源，全量搜索 top1000 可以做到 200ms 左右的延迟，top10 可以做到 30ms 以内的延迟，相比其他竞品有几倍的性能优势。

InfoQ：您如何看待向量检索技术在未来的发展前景？了解到有许多在向量数据库创业的企业，您觉得这个方向如何？

火山引擎 ByteHouse： 向量检索技术会成为一种数据库领域的常规技术，会有越来越多的传统数据库支持向量检索的技术，也会有更多更易用性能更强的向量检索算法以及算法库出现。这个方向目前还处于较早期的阶段，产品形态也还在探索，有很多的机会和可能性。

InfoQ：您认为接下来在这个领域将会出现哪些新的创新点或挑战？

火山引擎 ByteHouse： 一个是检索算法与索引方面的创新，包括自适应参数调优，early termination、与 filter 的结合、向量压缩、分布式检索结构等方面；一个是系统方面的创新，包括实时向量检索、嵌入式向量检索模块、索引推荐、数据隐私保护等方面。