背景
随着LLM技术应用及落地，数据库需要提高向量分析以及AI支持能力，向量数据库及向量检索等能力“异军突起”，迎来业界持续不断关注。简单来说，向量检索技术以及向量数据库能为 LLM 提供外置的记忆单元，通过提供与问题及历史答案相关联的内容，协助 LLM 返回更准确的答案。
不仅仅是LLM，向量检索也早已在OLAP引擎中应用，用来提升非结构化数据的分析和检索能力。ByteHouse是火山引擎推出的云原生数据仓库，近期推出高性能向量检索能力，本篇将结合ByteHouse团队对向量数据库行业和技术的前沿观察，详细解读OLAP引擎如何建设高性能的向量检索能力。
负载特征
向量检索的目标是查找与给定向量最相似的 k 个结果，广泛用于以图搜图、推荐系统等场景。近两年，随着大模型的普及，而基于向量检索构建的大模型检索增强功能，能够显著改善大模型的结果准确率低的问题，得到了广泛的关注。因此，向量检索相关技术，以及基于向量检索的向量数据库的概念逐渐流行起来，成为数据库领域一个热门话题。
实际使用场景中，向量检索针对的数据集大小通常会在 million 甚至 billion 级别，而查询延迟通常会要求在数毫秒到百毫秒内返回，因此，通常不会使用 brute force 的方式进行计算，而是会使用具有特殊结构的向量检索索引的方式来计算，比较流行的向量索引算法有 HNSW、Faiss IVF 等。
picture.image
这类基于向量索引的向量检索负载大概具有以下几个特点：
构建时间长，资源消耗大：索引的构建时间通常比较长，远大于数据插入的时间，以常用的 gist1M 数据集为例不同类型的索引构建时间大概需要几十秒甚至上百秒。此外，构建索引通常需要消耗较多的 CPU 及内存资源。因此，在实现向量检索功能时，需要考虑如何高效管理索引构建任务需要的资源，保证构建速度的同时，也不会影响其他任务的进行。
内存计算：HNSW、Faiss IVF 类索引都需要将索引结构全部读取到内存中，而索引结构通常会包含有所有向量数据的原始数据以及一些额外的结构相关数据，因此其大小通常会大于向量数据的总量