VectorChord 技术博客与版本发布

值此马年新春开启之际，我们非常高兴地宣布发布 VectorChord 1.1。 VectorChord 1.0 是 Postgres 原生向量搜索的一个重要里程碑：它让大规模索引构建变得足够快，感觉就像日常迭代而非停机维护。在 1.1 版本中，我们在此基础上更进一步，推出了 RaBitQ8：这是一种全新的向量类型，相比 float32 可节省 4 倍存储空间并提供更快的搜索速度，同时召回率损失不到 1%。配合 RaBitQ4 以及更具可组合性的查询控制能力，VectorChord 1.1 已准备 …

对于希望自行部署十亿级规模向量搜索的团队而言，真正的挑战往往不在于原始性能，而在于实用性。许多专为十亿级规模、低延迟向量搜索而设计的解决方案都伴随着诸多现实约束，需要在各种权衡中做出妥协，从而影响了落地的难易程度。 现有的大多数方案通常属于以下几类之一： 运维复杂：依赖多节点分布式系统，长期管理、运维和维护的难度较高。 构建耗时过长：需要漫长的索引构建时间，导致重建索引成本高昂，且极易影响生产环境负载。 内存开销巨大：单机往往需要高达 1 TB 的内存，高昂的硬件成本让大多数团队望而却步。 这些 …

两年前，当我们发布第一篇 pgvecto.rs 博客文章时，我们下了一个赌注：Postgres 是进行向量搜索的最佳场所。从那时起，我们一直围绕这个信念持续迭代——从支持过滤向量搜索的 VBASE，到更长维度的向量支持，再到 RaBitQ 量化方案以及对磁盘友好的索引布局。 随着 VectorChord 1.0 的到来，我们再次实现了突破。在一台 16 vCPU 的机器上，我们现在可以在 20 分钟内为 1 亿（100M）个向量构建好索引；而在相同规模下，pgvector 需要超过 50 个小时 …

1. 引言 在过去几个月里，我们收到了来自用户和合作伙伴的一致反馈：尽管我们提供可扩展、高性能 pgvector 替代方案的目标广受好评，但在十亿级规模下，索引构建时间和内存占用仍然是大家关注的主要痛点。 现在，VectorChord 可以在一台仅配备 12 GB 内存的 16 vCPU 机器上，在 20 分钟内为 1 亿个 768 维向量构建索引。相比之下，使用 pgvector 为相同规模的数据构建索引，在 16 核实例上需要大约 200 GB 内存和约 40 小时。而且当内存不足时 …

我们非常激动地宣布发布 VectorChord 0.5！此次发布标志着我们在提供更灵活、更强大、更可控的向量搜索能力这一使命上迈出了重要一步。在 0.5 版本中，我们引入了两项重大更新：对 DiskANN 图索引的实验性支持，以及全新的用于主动监控 IVF+RaBitQ 索引健康状况的召回率评估工具。 全新索引预览：RaBitQ 赋能的 DiskANN 索引 从第一天起，VectorChord 的核心索引方案就建立在一个强大的组合之上：基于聚类的 IVF 算法与 RaBitQ 量化——也就是我们 …

现代应用普遍依赖 PostgreSQL 完全符合 ACID 的事务特性、表达力丰富的 SQL 以及繁荣的扩展生态系统。虽然 PostgreSQL 在处理关系型负载方面表现得无与伦比，但许多项目同样需要在庞大的文本集合（如商品描述、客服工单、技术文档）中进行搜索，并将最相关的行优先呈现给用户。PostgreSQL 的原生工具为此提供了一定基础，但其默认的排序逻辑往往会让最理想的匹配结果被淹没在不太有用的结果之下。VectorChord‑BM25 通过将 BM25 相关性评分算法直接引入 …

我们很高兴地宣布发布 VectorChord 0.4，这是一次全面增强 PostgreSQL 高性能向量搜索能力的重要更新。我们相信，此次发布进一步拓展了 PostgreSQL 向量搜索的能力边界，引入了多项关键架构改进，旨在为严苛的真实业务负载降低延迟并提升吞吐量。 如果你正在 PostgreSQL 上构建相似度搜索、RAG 流水线或其他 AI 驱动的应用，这些更新正是为你量身打造的。我们重点聚焦于两大领域：利用 PostgreSQL 不断演进的底层能力大幅提升冷查询（Cold Query）的 …

在标准的检索增强生成（RAG）方案中，一种常见做法是将长篇文档切分为更小、更易于管理的文本块（chunk）。这样做主要是为了结合句子嵌入（sentence embedding）与关键词 BM25 评分来提升检索效率，使系统能够快速定位并提取出相关的信息片段。虽然这种方法在许多场景下行之有效，但它也带来了一个显著的挑战：单个文本块很可能会丢失其原本所处的上下文语境。 不妨以历史文献集合为例。如果用户询问某个特定历史事件，而检索出的文本块写着：“条约正式签署，敌对状态宣告结束。” 脱离了前后的文本， …

在本文中，我们将介绍一种利用真实世界的 LAION-400M 数据集和 PostgreSQL 中的 VectorChord 扩展，以高性价比方式上传、构建索引并搜索大规模向量数据的方法。 我们将向您展示需要什么样的硬件配置，才能使用 VectorChord 在这一海量数据集上进行搜索，并确保您获得既准确又快速的搜索体验。 VectorChord 是一款 PostgreSQL 扩展，能够将高性能向量数据库能力直接引入您的 PostgreSQL 数据库中，并尽可能高度兼容热门的 pgvector 扩 …

检索增强生成（Retrieval-Augmented Generation, RAG）正在彻底改变我们与海量数据集及语言模型的交互方式。通过在生成回答之前先检索相关信息，RAG 系统能够提供更准确、更具上下文感知能力且实时更新的答案。然而，构建稳健、可扩展且高效的 RAG 流水线依然面临诸多挑战，在生产环境中更是如此。 许多解决方案采用了复杂的架构，分别为向量搜索、关键词搜索和主数据存储使用不同的数据库。这通常会导致数据同步难题、更高的基础设施复杂度以及高昂的运维成本。 如果可以直接在你信赖的 …

今天，我们非常激动地宣布发布 Vechord——一个全新的 Python 库，旨在大幅简化直接在 PostgreSQL 数据库之上构建稳健搜索基础设施的流程。 在人工智能与大语言模型（LLM）飞速发展的今天，检索增强生成（RAG）和语义搜索已成为不可或缺的核心组件。然而，搭建所需的向量搜索基础设施往往意味着学习全新的数据库技术、管理复杂的系统集成，或是与繁琐的框架搏斗。这不仅增加了研发摩擦，还会拖慢开发进度，对于已经熟悉 PostgreSQL 的团队而言尤为如此。 挑战：混合搜索的复杂性 构建搜 …

为文档构建高效的检索增强生成（RAG）系统，往往让人感觉像是在与杂乱复杂的流水线搏斗。尤其是在处理 PDF 或扫描图像时，传统方法高度依赖光学字符识别（OCR）和版面分析。这些步骤不仅耗时、容易出错，而且经常会丢失表格、图表和排版格式等至关重要的视觉上下文信息。但如果可以直接根据文档的“视觉外观”进行查询，而不仅仅依赖提取出来的纯文本呢？ 本文将手把手带你构建这样一个系统：直接在你熟悉的 PostgreSQL 数据库中构建一套免 OCR 的 RAG 系统。我们将结合 ColQwen2 视觉语言模 …

我们非常激动地宣布发布 VectorChord 0.3！这一重要里程碑直接在你的 Postgres 数据库内部显著提升了高级向量搜索技术的性能与适用性。在带来 ARM 支持与更快索引构建的 0.2 版本基础上，0.3 版本攻克了现代检索领域的最大难关之一：具备晚期交互（Late Interaction）能力的高效多向量搜索。 超越单向量：为什么多向量如此强大 多年来，向量搜索主要将整篇文档或整个查询表示为单个稠密向量（Dense Vector）。这种方法虽然强大，但需要将复杂的信息平均或压缩为单 …

监测地球的健康状况是我们这个时代最严峻的挑战之一。我们的星球正面临巨大的环境压力，而要理解这些变化，就必须筛选超乎想象的海量卫星数据——持续不断捕获的 PB 级像素图像。从追踪亚马逊雨林的森林砍伐，到识别偏远地区的非法采矿作业，再到监测农业活动对敏感生态系统的影响，将这些原始数据转化为可落地的行动情报至关重要。 Earth Genome 打造的 Earth Index 平台正在正面迎击这一挑战。如今，它已实现全球覆盖，利用 AI 的力量让地球上的每一寸陆地表面都变得可搜索。这不仅是一项技术成就， …

引言：真实场景中的挑战 并非所有场景都需要专用的向量数据库。借助 pgvector、pgvectorscale、VectorChord（演进自 pgvecto.rs）等 PostgreSQL 扩展，您可以在无需额外基础设施的情况下同时获得向量搜索与关系型数据库的能力。但实际落地并非总是顺风顺水，以下是真实用户的反馈： 首次查询耗时 30 秒，而重复查询只需 100 毫秒。问题出在极其缓慢的 I/O 上。 为 1,200 万行 75 维向量构建索引需要 3 个小时，这正常吗？ 在为 2 亿条 75 …

我们很高兴地宣布发布 VectorChord-BM25 0.2 版本！这款 PostgreSQL 扩展旨在将先进的基于 BM25 的全文检索排序能力直接引入您的数据库中。 借助 VectorChord-BM25，您无需依赖外部搜索引擎，即可直接利用信息检索领域的标准算法——BM25 的强大能力。本次发布迈出了重要一步，重点强化了核心文本处理组件：分词（tokenization），从而带来了更高的灵活性以及显著提升的多语言支持能力。 重磅消息：推出 pg_tokenizer.rs …

你可能在一些技术讨论或博客文章中看到过这样的观点：与专用搜索引擎或特定扩展相比，PostgreSQL 内置的全文检索（Full-Text Search，简称 FTS）在性能上表现不佳。近期一个典型的例子是 Neon 发布的博客文章《Performance Benchmark: pg_search on Neon》（链接）。 在这项基准测试中，Neon 将其数据库平台上搭载 pg_search 扩展（基于 Rust 的 Tantivy 库并通过 pgrx 构建）的查询性能，与使用 tsvector …

在 RAG（检索增强生成）时代，如何从海量数据集中高效检索相关数据，对企业和开发者而言至关重要。传统的基于关键词的检索方法（例如使用 BM25 作为评分机制的方法）擅长根据词频和精确关键词匹配对文档进行排序，因此对于结构化查询和关键词密集型内容非常有效。然而，它们在理解同义词、上下文细微差别和语义意图方面往往力不从心。相反，基于向量的检索能够捕捉深层语义，在多样化查询上具备更好的泛化能力，但有时会在精确关键词匹配上牺牲准确性。混合搜索（Hybrid Search）通过将 BM25 的精确性与向量 …