Na era AIGC, os desenvolvedores precisam de um “banco de dados vetorial real”?
A resposta é simples, depende do cenário de aplicação do desenvolvedor . Por exemplo, escolher um restaurante cinco estrelas ou um restaurante fast food para jantar geralmente está relacionado ao seu apetite e expectativas.
Se você quer apenas uma refeição simples, um restaurante fast food pode satisfazê-lo. Da mesma forma, se você deseja construir rapidamente um robô de perguntas e respostas para seu site pessoal, ou criar um índice para 100.000 fotos em seu álbum de fotos, você pode escolher o método mais familiar e conveniente, seja usando um vetor livre serviço de nuvem de recuperação, ou É uma boa opção instalar o PG Vector, um plug-in de recuperação de vetores de código aberto baseado em PostgreSQL, ou instalar bibliotecas de recuperação de vetores de código aberto, como Faiss, HNSW e Annoy localmente por meio de pip.
Porém, se o nosso objetivo for um jantar de alta qualidade, muito provavelmente escolheremos um restaurante cinco estrelas. É como se quiséssemos construir um aplicativo de recuperação de vetores de nível empresarial. O volume de dados excede dezenas de milhões, a latência deve ser inferior a 10 ms e funções avançadas, como filtragem escalar, arquitetura dinâmica, multilocação, tempo real atualização/exclusão, importação em lote, etc. são necessários. Além disso, esperamos poder construir rapidamente uma demonstração utilizável em apenas dez minutos... Isso requer a ajuda das capacidades e vantagens do banco de dados vetorial nativo. É como um restaurante cinco estrelas, que não pode satisfazer apenas as suas necessidades básicas A exigência é garantia de qualidade e serviço.
Este artigo ainda é o familiar " Olá, série Vector DB" . Depois de ler este artigo, acredito que todos terão uma compreensão mais profunda de " se um banco de dados vetorial real é necessário ".
01.
Introdução de cinco minutos à recuperação de vetores
O banco de dados vetorial tem a vantagem de calcular rapidamente a similaridade vetorial e pode encontrar os K principais vetores entre os N vetores que são mais semelhantes ao vetor alvo no espaço de alta dimensão. No entanto, esta capacidade não é exclusiva dos bancos de dados vetoriais. Por exemplo, podemos implementar o algoritmo do vizinho mais próximo em menos de 20 linhas de código usando a biblioteca NumPy do Python.
Aqui está um exemplo simples:
import numpy as np
# Function to calculate euclidean distance
def euclidean_distance(a, b):
return np.linalg.norm(a - b)
# Function to perform knn
def knn(data, target, k):
# Calculate distances between target and all points in the data
distances = [euclidean_distance(d, target) for d in data]
# Combine distances with data indices
distances = np.array(list(zip(distances, np.arange(len(data)))))
# Sort by distance
sorted_distances = distances[distances[:, 0].argsort()]
# Get the top k closest indices
closest_k_indices = sorted_distances[:k, 1].astype(int)
# Return the top k closest vectors
return data[closest_k_indices]
Podemos tentar gerar 100 vetores bidimensionais e então encontrar o vizinho mais próximo do vetor [0,5,0,5].
código mostrado abaixo:
# Define some 2D vectors
data = np.random.rand(100, 2)
# Define a target vector
target = np.array([0.5, 0.5])
# Define k
k = 3
# Perform knn
closest_vectors = knn(data, target, k)
# Print the result
print("The closest vectors are:")
print(closest_vectors)
Esta abordagem oferece grande flexibilidade e é de baixo custo de implementação . Eu recomendo que você use NumPy ou outras bibliotecas de aprendizado de máquina para pesquisa vetorial se você:
Verificação de protótipo rapidamente.
Não há necessidade de persistência de dados.
O tamanho dos dados é inferior a um milhão e não há necessidade de filtragem escalar.
Os requisitos de desempenho da consulta não são altos.
Por outro lado, se você precisar construir rapidamente um protótipo de sistema e tiver certos requisitos de desempenho, o FAISS pode ser uma boa escolha . FAISS é uma biblioteca de código aberto da Meta para pesquisa eficiente de similaridade e agrupamento denso de vetores. Ele pode lidar com coleções de vetores de qualquer tamanho, até mesmo coleções que nem todas cabem na memória. O FAISS também inclui ferramentas para avaliação e ajuste de parâmetros. FAISS é escrito em C++, mas fornece uma interface Python/NumPy completa.
A seguir está um código de recuperação de vetor baseado em FAISS:
import numpy as np
import faiss
# Generate some example data
dimension = 64 # dimension of the vector space
database_size = 10000 # size of the database
query_size = 100 # number of queries to perform
np.random.seed(123) # make the random numbers predictable
# Generating vectors to index in the database (db_vectors)
db_vectors = np.random.random((database_size, dimension)).astype('float32')
# Generating vectors for query (query_vectors)
query_vectors = np.random.random((query_size, dimension)).astype('float32')
# Building the index
index = faiss.IndexFlatL2(dimension) # using the L2 distance metric
print(index.is_trained) # should return True
# Adding vectors to the index
index.add(db_vectors)
print(index.ntotal) # should return database_size (10000)
# Perform a search
k = 4 # we want to see 4 nearest neighbors
distances, indices = index.search(query_vectors, k)
# Print the results
print("Indices of nearest neighbors: \n", indices)
print("\nL2 distances to the nearest neighbors: \n", distances)
Parece bastante simples, o desempenho parece rápido o suficiente e pode lidar com cenários de produção em pequena escala. É claro que o desempenho da consulta também pode ser melhorado por meio de quantificação, redução de dimensionalidade e uso de GPU.
No entanto, embora bibliotecas de pesquisa vetorial como Faiss forneçam funções de pesquisa vetorial poderosas e eficientes, elas têm algumas limitações em ambientes de produção reais. Por exemplo, Faiss não fornece adição e exclusão de dados em tempo real, carece de suporte multilíngue, não pode fornecer chamadas remotas, não oferece suporte a filtragem escalar e não fornece soluções para problemas como persistência de dados, escalabilidade e recuperação de desastres. .
É por estas razões que as bases de dados vetoriais surgiram conforme os tempos exigem, proporcionando-nos uma solução mais completa e mais adequada para cenários de aplicação prática. O campo de batalha do banco de dados vetorial está atualmente dividido em quatro categorias:
Um banco de dados vetorial modificado ou implementado como um plug-in baseado em PG, Clickhouse, etc. Este tipo de solução baseia-se na base de dados relacional ou colunar existente, e adiciona funções de pesquisa vetorial através de modificação ou extensão de plug-in.PG Vector é um produto representativo deste tipo de solução.
Um banco de dados vetorial com suporte a índice vetorial denso adicionado com base na pesquisa invertida tradicional. Este tipo de solução baseia-se no motor de busca de índice invertido e estende o mecanismo de indexação para suportar a pesquisa vetorial.O ElasticSearch é um produto representativo deste tipo de solução.
Um banco de dados vetorial leve implementado com base na biblioteca de recuperação de vetores. Esse tipo de solução gira em torno de uma biblioteca de pesquisa vetorial como a Faiss, em torno da qual a funcionalidade do banco de dados é construída. Esses produtos costumam ter menor tamanho e maior eficiência operacional, sendo o Chroma um produto representativo desse tipo de solução.
Um banco de dados de dados vetoriais distribuídos nativos da nuvem com base no design vetorial nativo. Este tipo de solução projeta e implementa bancos de dados vetoriais do zero. Todo o sistema é otimizado para pesquisa vetorial de baixo para cima e geralmente oferece funções mais completas e avançadas, incluindo computação distribuída, backup de recuperação de desastres, persistência de dados, etc., Zilliz Cloud /Milvus é um produto representativo deste tipo de solução.
No entanto, "Nem todos os bancos de dados vetoriais nascem iguais" (nem todos os bancos de dados vetoriais nascem iguais) . Entre os vários tipos de bancos de dados vetoriais, cada solução tem suas vantagens e limitações exclusivas, e cada uma delas é adequada para diferentes cenários de aplicação.
Entre todas as soluções de banco de dados vetoriais, eu pessoalmente uso modificação mágica ou implementação de plug-in de bancos de dados vetoriais baseados em PG, Clickhouse, etc. (como PG Vector) e bancos de dados de dados nativos em nuvem vetorial distribuídos baseados em design vetorial nativo (como Zilliz Cloud /Milvus ) Estas duas soluções muito diferentes são particularmente promissoras.
Em seguida, precisamos analisar exaustivamente as razões a partir de múltiplas perspectivas, como os requisitos do cenário do usuário, o histórico de desenvolvimento de bancos de dados vetoriais e a particularidade da recuperação de vetores.
02.
Por que você precisa de um banco de dados vetorial específico
O banco de dados vetorial nasceu em 2019. Zilliz lançou e abriu o código-fonte do Milvus, o primeiro banco de dados vetorial do mundo. Naquela época, a função do banco de dados vetorial era relativamente simples, baseada principalmente na biblioteca de recuperação de vetores Faiss, encapsulando a interface de chamada de procedimento remoto (RPC) e suportando recursos de persistência baseados em Write-Ahead Logging (WAL).
Comparado com os métodos tradicionais de recuperação de vetores, o maior significado do Milvus 1.0 é que ele separa a estreita relação entre lógica de negócios, modelo e armazenamento de dados. Isso significa que os desenvolvedores de aplicativos não precisam mais prestar atenção à manutenção da infraestrutura subjacente, que inclui, entre outros, implantação de cluster, persistência de dados e migração de dados. Portanto, Milvus 1.0 fornece a muitos usuários uma transição do modelo tradicional de desenvolvimento de inteligência artificial estilo chaminé para a era dos grandes modelos (nesta era, os desenvolvedores costumam usar o seguinte modelo de desenvolvimento: modelo de linguagem grande (LLM) + ferramentas de orquestração + vetor banco de dados) transição.
Os cenários tradicionais de aplicativos de recuperação de vetores incluem sistemas de recomendação, pesquisa de imagens, robôs de perguntas e respostas e controle de risco de conteúdo. Eles são direcionados principalmente a usuários de nível empresarial com fortes recursos de IA e recursos de operação e manutenção. Os usuários estão preocupados principalmente com recursos de consulta e desempenho. ., escalabilidade sob grandes volumes de dados e capacidades de nível empresarial, como operabilidade, observabilidade e segurança.
随着大模型技术的蓬勃发展，向量数据库开始进入 2.0 时代，更多的个人开发者涌入赛道，对向量数据库的关注也逐渐迁移到开发效率、部署简单以及面向大模型加强场景的功能需求。也正是这波狂热的浪潮下诞生了诸如 Chroma 这样的套壳向量数据库，其跟存储引擎相关的代码不过寥寥十个文件。
不止 Chroma，DataStax、Redislab 等传统数据库厂商也纷纷加入战局。正如上文中提到的，基于 numpy 或者 Faiss可以五分钟快速实现一个"向量数据库"。然而，向量数据库绝不仅仅是用来进行简单的向量检索，要想真正提升开发者的开发效率和使用成本，需要系统开发者深入理解硬件、存储、数据库、AI、高性能计算、分布式系统、编译原理、云原生等方方面面，以确保其稳定性、性能和易用性。
构建向量数据库就像搭积木一样，需要分模块、分层次
数据持久化和低成本存储
作为一个数据库，数据不丢是最低的底线。许多单机和轻量级的向量数据库并没有关注数据的可靠性，Milvus 基于对象存储和消息队列的存储方案既通过存储计算分离提升了系统的弹性和扩展性，又保证了系统的可持久化性。更为重要的是，大多数 ANN 索引都是纯内存加载的，需要消耗大量内存才能执行检索。Milvus 是全球第一款支持磁盘索引的向量数据库，相比磁盘索引可以提供 10 倍以上的存储性价比。
高性能查询
查询性能是选择 ANN 而非 KNN 暴力搜索的核心需求。经过测试，市面上大量传统数据库向量检索插件其查询性能只有 Milvus 十分之一，且由于没有对索引进行分片，索引构造的时间和效率会随着数据量的增长大幅下降，因此只能适用于千万级数据量且不存在频繁增删的场景。
作为一个计算密集型应用，向量数据库的重要关注点在于充分压榨 CPU 算力，甚至利用异构算力实现加速。根据我们的内部测试结果，GPU 向量索引可以实现在千万数据集下万级别的 QPS，单机性能高于传统 CPU 索引一个数量级。向量数据库既是一个数据库，也是一个高性能计算系统，开发者需要拥有很强的 Hardware sympathy，这也是我认为我们需要 Purpose built 向量数据库的重要原因。
开源的向量数据库性能测试工具 Vector DB Bench《向量数据库的行业标准逐渐清晰！Vector DB Bench 正式开源！》，可以帮助用户迅速了解并对比不同向量数据库的性能和容量成本差距。
数据分布
传统数据库的分库分表分片往往基于主键或者分区键。对于传统数据库而言这种设置非常合理，原因是用户查询时往往给出确切的查询条件并路由到对应的分片。对于向量数据库而言，查询往往是找到全局与目标向量相似的向量，此时查询往往需要像MPP数据库一样在所有分区执行，算力需求随着数据量增长而增加。
向量原生数据库将向量作为一等公民，可以根据向量数据分布设置合理的分区策略，并充分利用数据分布信息设置查询策略来提升查询性能和查询精度。
易于使用
关于究竟什么是易用，不同的用户应该有自己的定义。向量数据库市场上，基于 GRPC 实现的多语言客户端，原生 Restful 接口和 SQL 接口都不乏拥簇。
见证了过去 10 年 NoSQL 到 NewSQL 的发展历程，我更愿意相信 SQL 这种表达能力更加丰富的查询语句才是最终的解决方案。除了基本的标量过滤，我们已经见到了用户对于聚合函数（Count，Groupby），函数和 Pagination 等传统数据库能力的需求。这也是我更看好基于 PG、Clickhouse 等进行魔改或者插件化实现的向量数据库的实现路径的一个原因。在对向量检索性能扩展性要求不高的场景下，这种实现方式的功能覆盖面更广，且与传统用户的使用心智更为接近。
与此同时，向量数据库的功能和数据模型必须贴近用户的应用场景。对于 AIGC 用户来讲，动态 Schema、多向量打分、标量向量混合打分、基于距离的范围查询这些查询能力都非常贴近业务场景，而这些场景并非简单的基于开源向量检索库就可以快速实现。
稳定可用
向量数据库是典型的 Big Data Serving 系统。一方面，向量数据库的写入来源于上游的推理系统，存在非常明显的离线和批量特性。另一方面，向量数据库很多应用场景面向在线查询，有严格的查询时延限制和高吞吐要求。在向量数据库的使用场景中，很多用户都要求单机故障能在分钟级恢复，同时也有越来越多的关键场景提出了主备容灾甚至跨机房容灾的需求。基于向量数据库的使用场景，传统基于 Raft/Paxos 的复制策略存在着资源浪费严重，数据预先分片困难等问题。Milvus 基于分布式存储和消息队列实现数据的可用性，基于 K8s 实现无状态故障恢复的无疑更省资源，故障恢复时间也更短。
向量数据库的稳定性另一个重要挑战是资源管理。传统数据库更加关注磁盘、网络等 IO 资源的调度管理，而向量数据库的核心瓶颈是计算和内存。Milvus 社区也有大量关于内存的管理和算力的调度的 PR，这些能力很难短期之内通过改造传统数据库或者在 Chroma 这种轻量级向量数据库中实现。
可运维可观测
想要成为一个企业级数据库，Milvus 不仅仅是提供软件，打包发布这么简单。Milvus 支持多种部署模式，例如 K8s Operator 和 Helm chart、docker compose、pip install 等，并提供了基于 grafana、prometheus 和 Loki 的监控报警体系。Zilliz 还开源了向量数据库可视化管理组件 Attu 以及向量数据库可视化工具 Feder，大大降低了向量数据库的管理难度，提升了向量检索的可解释程度。
得益于 Milvus 2.0 的分布式云原生架构，Milvus 也是业内首款支持多租户隔离、RBAC、Quota 限流、滚动升级的向量数据库。由于向量数据库计算、内存密集型的特性，传统数据库的隔离和限流能力很难在不做改造的情况下直接发挥作用。
智能化
Milvus 是一个 DB4AI 的系统，同时也是做了大量 AI4DB 的尝试。向量数据库与传统数据库的最大区别来源于对数据的返回准确度要求不同。传统数据库要求百分之百正确的返回结果，而向量数据库的 ANN 计算天生就属于近似匹配。通过 AI 改造向量数据库系统，其空间远远大于传统数据库进行调优或辅助问题排查。
基于 Milvus 打造的全托管企业级向量检索服务 Zilliz Cloud 创造性地提出了 AutoIndex，通过模型预测 recall 设置对应的查询参数，在大数据量下可以在 recall 几乎无损的情况实现 2-3倍 的性能优化。不仅如此，量化技术，降维，ranking 等传统 AI 领域的技术也被广泛应用于向量数据库中，传统数据库开发者明显缺乏对这些技术的理解。
03.
尾声
尽管构建向量数据库的是一件复杂的工作，使用向量数据库却是一件如使用 numpy、Faiss 般简单的工作，即使对 AI 并不了解的同学也可以在十分钟内基于 Milvus 快速实现向量检索。想要体验高性能，强扩展性的向量检索服务，仅仅需要三步：
1）请先参考 Milvus 部署文档 https://milvus.io/docs/install_standalone-docker.md部署 Milvus 服务。
2）参考 Hello Milvus 文档 https://milvus.io/docs/example_code.md，50 行代码即可实现向量检索功能。
3）查看 Towhee 的范例文档 https://github.com/towhee-io/examples/，了解向量数据库的应用场景，包括图片检索、知识增强、图文问答、视频去重等应用场景。
最后，向量数据库的确成为 AIGC 时代的明星，也引起了很多非议。愿行业内的朋友都能沉下心来做事，构建产品的核心竞争力，更好地服务于用户。无论是五星级酒店还是路边快餐，都应该给客人符合价值的产品，而不是仅仅关注在炒作本身。
本文作者
本文分享自微信公众号 - ZILLIZ（Zilliztech）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。