工程实践与深度解析

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

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

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

在标准的检索增强生成（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 视觉语言模 …

监测地球的健康状况是我们这个时代最严峻的挑战之一。我们的星球正面临巨大的环境压力，而要理解这些变化，就必须筛选超乎想象的海量卫星数据——持续不断捕获的 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 的精确性与向量 …

VectorChord 是一款专为可扩展、高性能且磁盘友好的向量相似度搜索而设计的 PostgreSQL 扩展，也是 pgvecto.rs 的继任者。在我们之前的博客文章中，我们展示了仅需每月 $250 的成本，VectorChord 就能在 1 亿规模的向量数据集上以 0.95 的精度实现 131 QPS——展现了大规模向量搜索中令人印象深刻的高性价比。 在此基础上，本文将聚焦于极致性能，探讨如何借助 VectorChord 在 PostgreSQL 中实现 10,000 QPS。我们将为您详 …

我们非常高兴与大家分享一款重磅新作：VectorChord-BM25，这是一款旨在让 PostgreSQL 全文检索更上一层楼的全新扩展。无论您是在构建小型应用还是管理大规模系统，这款工具都能将先进的 BM25 评分与排序能力直接引入 PostgreSQL，让您的搜索更智能、更迅速。 有哪些新特性？ BM25 评分与排序：借助 BM25 获得更精准、更相关的搜索结果，助您快速定位最重要的信息。 优化的索引结构：得益于 Block WeakAnd 算法，即便面对大规模数据集，搜索也能更加快速高效。 …

注：本文最初发表于 2023 年，探讨了专用向量数据库的适用性与必要性，特别是它与 Postgres 及其能力之间的关系。如需了解关于此话题的更多见解与讨论，请参阅以下链接：Do we really need a specialized vector database? | Hacker News。 随着大语言模型（LLM）的普及，向量数据库也成为了热门话题。只需寥寥几行简单的 Python 代码，向量数据库就能充当 LLM 廉价却高效的“外挂大脑”。但我们真的需要一个专门的向量数据库吗？ 为 …

传统的向量搜索方法通常采用句子级嵌入（sentence embeddings）来定位相似内容。然而，通过对词元嵌入（token embeddings）进行池化来生成句子嵌入，可能会牺牲词元级别所蕴含的细粒度细节。ColBERT 通过将文本表示为词元级多向量（multi-vectors）而非单个聚合向量，克服了这一局限。这种方法利用词元级的上下文后期交互（contextual late interaction），使 ColBERT 相比仅依赖句子嵌入的方法能够保留更微妙的语义信息，并提高搜索准确度 …

ARM64 正悄然成为高性价比云服务器的首选架构，尤其是在 AWS 上。借助 Graviton 系列（Graviton3 和 Graviton4）等基于 ARM 的处理器，你可以在不牺牲性能的前提下节省一大笔开销。这些 ARM64 实例比传统的 x86 实例实惠得多，是在云端平衡成本与性能的可靠选择。 话虽如此，由于 ARM 的架构与 x86 不同，未针对其进行优化的软件可能会因为指令模拟或缺乏优化而运行缓慢。这正是 VectorChord 大显身手的地方——它是一款专为可扩展、高性能且磁盘高效 …