模型长期记忆的重要性-阿里云开发者社区

模型长期记忆的重要性

2024-04-07 29

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生数据库 PolarDB MySQL 版，Serverless 5000PCU 100GB

简介： 文章探讨向量数据库作为ChatGPT等模型长期记忆的重要性，指出真正向量数据库需支持数据的增删查改与持久化。

免费体验阿里云高性能向量检索服务：https://www.aliyun.com/product/ai/dashvector

作为ChatGPT等大模型的long-term memory，向量数据库似乎即将成为继云原生，OLAP，流数据之后的投资热点。然而，不同的人对向量数据库的认知似乎是参差不齐的。谈到向量数据库，有的人在谈Faiss, SPTAG等ANN库，有的人在谈基于ClickHouse等数据库的向量拓展。这些系统中哪些称得上真正的向量数据库，而那些真正的向量数据库又是基于怎么样的架构，有怎么样的优劣，其实鲜有人探讨。这篇文章中我想谈谈在我的认知中什么是真正的向量数据库，以及对现有系统做一个简单的分析和概述。

向量数据库，是一种基于向量技术进行数据存储和检索的数据库系统。这里的“向量”，指的是数学中的多维向量，它可以用来表示数据点的多个特征。在向量数据库中，数据被转换成向量形式，并通过计算向量之间的距离来衡量数据之间的相似度。这种相似度计算的方式，使得向量数据库在处理非结构化数据（如文本、图像、音频等）时具有天然的优势。

在数据库技术出现之前，数据的管理主要依赖于文件系统和人工管理。例如，使用穿孔卡片、纸带等物理媒介进行数据存储。这些方式在处理大量数据时效率低下，且难以进行数据的有效检索和分析。

随着计算机技术的兴起，出现了关系型数据库（RDBMS），如Oracle、MySQL等。这些数据库使用表格的形式存储数据，并通过SQL语言进行数据的增删改查。关系型数据库在结构化数据的处理上表现出色，但在处理非结构化数据（如文本、图像等）时显得力不从心。

随着互联网和多媒体技术的快速发展，非结构化数据呈现出爆炸性增长，如何有效地存储和检索这些非结构化数据成为了一个亟待解决的问题，传统的基于关键字的检索方式无法准确捕捉非结构化数据之间的语义关系。

在人工智能和机器学习领域，研究者开始探索使用向量来表示数据。向量空间模型（VSM）为文本、图像等非结构化数据提供了一种有效的表示方法。通过计算向量之间的相似性（如余弦相似度），可以度量数据之间的语义相似度。

基于向量表示和相似性匹配的思想，向量数据库应运而生。它们专门设计用于存储和检索向量数据，并提供高效的索引和查询机制。与传统的基于关键字的检索方式不同，向量数据库能够捕捉到数据之间的语义关系，从而提供更准确、更智能的检索结果。

追溯数据库的发展历程，我们熟知的关系型数据库、非关系型数据库等如同历史长河中的砥柱，支撑起信息化社会的数据基石。而今，随着人工智能和机器学习的快速发展，尤其是深度学习技术的广泛应用，传统的数据库架构在处理大规模、高维度且结构复杂的数据时显得力不从心。于是向量数据库应运而生，以其独特的优势填补了这一空白。

一个数据库得支持两个基本功能：一个是数据的增删查改（CRUD），一个是数据的持久化。以一个基于向量推荐的短视频app为例，在用户发布了新的短视频/修改了视频之后，其他用户应该能在短时间内搜索到这个新的视频，这是支持增删查改。如果机房宕机，服务器重启，用户已经发布的短视频应该一个不多一个不少，这是支持持久化。如果我们基于这两个条件对照那些向量搜索库，就会发现Faiss，SPTAG们完全基于内存，不支持持久化，同时也没法进行数据的增删，因此不能算作数据库。同样的原因，Elastic等搜索引擎也不能被称为向量数据库。

看到这里，你可能会说等等，我用一个现有的关系型数据库/NoSQL来负责CRUD和持久化，而搜索的时候把所有向量导入到内存，用Faiss建一个in-memory index进行搜索不就好了。首先恭喜你，这是一个million dollar idea，很多向量数据库公司就是这么做的。比如之前融资1800万美元的ChromaDB就是基于Python实现了一个ANN index，并用DuckDB和Clickhouse来做持久化。从本质上来说，这是实现向量数据库的第一个思路：基于高性能的向量搜索库，开发持久化存储引擎。这一设计的优点是保证了向量数据库最重要的功能，也就是向量搜索的性能，同时也容易较为容易实现，但这个设计也有很多挑战，比如如何保证数据读写的一致性，使得新写入的数据能同步到内存中的index；如何保证数据库事务的Isolation（隔离性），使得并发的读写不会互相干涉；如何支持分布式储存和处理等等。在现有的关系型数据库中，这些模块都是需要精心设计，并投入大量工程来解决的。一些向量数据库没有很好的解决这些问题，例如ChromaDB的持久化储存不过用寥寥几个文件调用了已有数据库的接口，在知乎中被人诟病，但这并不代表这一实现向量数据库的思路有问题，大家所熟知的第一代Milvus其实也是基于Faiss进行开发，不同的是Milvus的团队设计并实现了一个基于LSM的储存引擎并支持快照隔离（snapshot isolation），同时提出了一个存算分离的分布式架构：

而实现向量数据库的第二个思路，是基于现有数据库，提供向量数据查询上的支持。其实这个思路比较有代表性的是pgvector，基于PostgreSQL的向量拓展。pgvector的优点在于，所有PostgreSQL支持的功能，包括ACID特性，logging & recovery，还有复杂的查询以及Join都能得到支持。缺点也很明显，PostgreSQL的缺点，例如非云原生，单机架构拓展性较低等也都一并继承。所谓成也PG，败也PG。这么做还有一个比较大的问题，那就是目前主流的向量KNN/ANN搜索index都是基于in-memory的假设设计的，而把这些index直接应用到一个基于硬盘的系统，可能会有性能上的下降。

除了上述思路，当然还有一个最硬核的思路，那就是从头开发一个向量数据库。代表性的开源系统有Manu (Milvus 2.0)和Weaviate。这个思路由于不依附已有的系统，在设计上最具灵活性，也能够根据向量数据应用场景的特点进行优化。这么做唯一的缺点，就是巨大的时间和人力成本。我们具体看一下这两个系统。

Weaviate对数据对象，对象文本的inverted index (倒排索引)，以及HNSW index都做了持久化，并通过Write-Ahead-Log支持数据的recovery。同时，Weaviate通过基于UUID的sharding来进行水平拓展，并支持eventual consistency(最终一致性)。 Weaviate的一大特点是通过Module的概念将embeddding模型也纳入了数据库，支持根据不同模型在线计算embedding。Weaviate架构：

Manu提出了log as data的概念，以log为骨干构建一个基于Publisher/Subscriber架构的系统，Manu的Logger是系统的Publisher，将所有数据定义，插入与更新的请求通过Write-Ahead Log暴露给系统中其他模块，而其他的模块，包括Data Node, Index Node， Query Node都是系统中的subscriber，根据所接收的log实时更新数据/index。Data Node将接收到的基于行的数据更新到Binlog中的列存，以提升查询效率。Manu通过一个中心化的时间戳服务来实现delta一致性，可以支持用户指定一个可容忍的最大时延。