其他
比 pgvector 快 20 倍的 Postgres 向量运算插件：pg_embedding
原文：https://neon.tech/blog/pg-embedding-extension-for-vector-search
Neon 前不久发布了适用于 Postgres 和 LangChain 的 pg_embedding 扩展，相比于 pgvector，它将 Postgres 中基于图形的近似最近邻搜索速度提升了 20 倍，准确度达到了 99%。
CREATE EXTENSION IF NOT EXISTS embedding;CREATE INDEX ON items USING hnsw (embedding) WITH (maxelements = 1000000, dims=1536, m=32);from langchain.vectorstores import PGEmbeddingdb = PGEmbedding.from_documents( embedding=embeddings, documents=docs, collection_name="state_of_the_union", connection_string=CONNECTION_STRING,)db.create_hnsw_index(max_elements= 10000, dims = 1536, m = 8, ef_construction = 16, ef_search = 16)基准测试结果
SELECT pg_prewarm('3448836', mode => 'buffer');结果和分析
指标
执行时间：以执行 100个 最近邻搜索查询所需的平均时间来衡量。
准确率/召回率：以每个查询返回的真实最近邻的比例来衡量。
设置
数据集：我们使用 GIST-960 Euclidean 数据集进行基准测试。该数据集被广泛用于基准测试相似性搜索算法。
环境：基准测试在一个具有 4 个虚拟处理器 和16GB RAM 的 Neon 实例上进行。
配置：
对于 pgvector，我们在 [1, 2, 10, 50] 范围内变化 probes 参数，并在 [1000, 2000] 范围内变化 lists 参数。
对于 HNSW，我们用了 m 为 [32, 64, 128]，efConstruction 为 [64, 128, 256]，efSearch 为 [32, 64, 128 ,256 ,512]。
为什么 HNSW 比 IVFFlat 快？
使用 pgvector 的 IVFFlat
HNSW 和 pg_embedding 组合
m: 该参数表示在构建图形过程中，每个新元素创建的双向链接的最大数量。
efConstruction: 该参数用于索引构建阶段。较高的 efConstruction 值会创造更高质量的图和更准确的搜索结果。然而，这也意味着索引构建需要更长时间。下图表显示了使用 GIST-960 Euclidean 数据集时根据 ef_construction 值的构建时间。
efSearch: 此参数用于搜索阶段。与 efConstruction 类似，较大的 efSearch 值会在增加搜索时间的代价下提供更准确的搜索结果。该值应等于或大于 k（你想要返回的最近邻居数量）。
CREATE INDEX ON vectors_hnsw USING hnsw (vec) WITH (maxelements = 1000000, dims=1536, m=32, efconstruction=32, efsearch=32);你该选哪个索引？
搜索速度
准确性
内存使用量
索引构建速度
距离度量
内存限制 (pgvector)：如果你在严格的内存限制下工作，可以选择 IVFFlat，因为它通常比 HNSW 消耗内存更少，代价是搜索速度和准确性。 搜索速度 (pg_embedding)：如果你主要关注快速检索最近邻的速度，特别是在高维空间中，由于其基于图形的方法，pg_embedding 很可能是更好的选择。 准确性和召回 (pg_embedding)：如果对你的应用程序来说实现高准确性和召回至关重要，则 pg_embedding 可能是更好的选择。与 IVFFlat 相比，HNSW 基于图形的方法通常产生更高水平的召回。 距离度量 (pgvector)：无论是 pgvector 还是 pg_embedding 都支持 L2 距离度量。此外，pgvector 还支持内积和余弦距离。
结论
Star History 月度开源精选｜2023 年 6 月
全方位对比 Postgres 和 MySQL (2023 版)
Bytebase 2.4.0 - 支持全局控制数据查询及导出的权限 + 自定义审批流