什么是向量数据库？ pgvector vs Pinecone vs Weaviate

用通俗语言解释向量数据库

向量数据库是为存储和检索嵌入而设计的系统——嵌入是表示文本、图像或其它数据“含义”的数值列表。与其问“这条记录是否包含确切单词 refund？”，不如问“哪些记录与这个问题最相似？”然后返回最接近的匹配项。

快速的心理模型： “找到最相似的东西”

把每个文档（或产品、工单、FAQ）想象成地图上的一个点。关于同一主题的项会落得很近——即便使用了不同的词。向量数据库就是能够快速回答：这个新点附近有什么？ 的工具。

它与 SQL 数据库和关键词搜索的区别

传统的 SQL 数据库在你知道问题结构时表现出色：按日期、user_id、status 等筛选。关键词搜索在正确答案恰好包含你输入的相同词语时很有效。

向量数据库不同，因为它关注语义相似性。它适合处理诸如“如何拿回我的钱？”这样的查询，并能找到说“我们的退款政策……”的内容，而不需要完全相同的措辞。

这并不取代 SQL 或关键词搜索。在很多真实系统中，你会同时使用两者：用 SQL/过滤实现业务规则（地区、权限、新鲜度），用向量搜索处理“含义”。

人们用向量数据库做什么

• 语义搜索：按意图而非精确词句搜索文档。\n- 推荐：基于相似性做“喜欢此项的用户也喜欢…”。\n- RAG（检索增强生成）：先获取最相关的段落，然后让 LLM 在这些上下文基础上生成回答。

如果只记一句话：向量数据库是一个针对嵌入的**“最相似项”引擎**，针对快速且大规模的相似度检索进行优化。

嵌入与相似性：核心概念

向量数据库之所以可用，是因为嵌入让你能用数值比较含义。你不去阅读每个数字；用它们来对两段内容的“接近程度”进行排序。

什么是嵌入（以及为什么是数字列表）

嵌入是一串数字（通常是数百或数千维），表示一段内容。每个数字捕捉由模型学习到的含义的某个方面。你不需要直接解释单个数字；重要的是相似内容会产生相似的数字模式。

把它想象成高维空间的坐标：关于“退款政策”和“退货”的句子会落得很近，即便他们使用了不同的词语。

文本、图像和音频如何变成向量

不同的嵌入模型把不同媒体变成向量：

• 文本：一句话、段落、工单或产品描述成为一个向量。\n- 图像：一张照片成为一个捕捉形状、物体和风格的向量。\n- 音频：一段音频可以根据声学模式被嵌入（或先转录为文本再嵌入）。

一旦一切都变成了向量，数据库就可以用相同的核心操作在大集合上搜索：“找到最接近的向量”。

什么是“相似性”（无需复杂数学）

决定“最接近”时，系统使用一些简单的评分规则：

• 余弦相似度（Cosine similarity）：比较两个向量的方向（它们是否朝向同一方向）。\n- 点积（Dot product）：奖励朝向相同且在幅度上兼容的向量。

你不需要手算这些——重要的是分数越高表示“越相似”。

为什么好的嵌入比数据库选择更重要

大多数搜索质量的提升来自于更好的嵌入与更合理的分块，而不是换数据库。如果你的模型不能抓住领域术语（产品名、内部术语、法律表述），即使是最好的向量索引也只能返回“最接近的错误答案”。选择 pgvector、Pinecone 或 Weaviate 很重要，但选择合适的嵌入模型和输入格式通常更关键。

向量数据库 vs 关键词搜索 vs SQL 查询

关键词搜索、SQL 查询与向量搜索解决不同问题——把它们混为一谈是导致令人失望结果的常见原因。

关键词搜索：精确词语占优

传统搜索（Elasticsearch、Postgres 全文等）匹配词语与短语。当用户知道要输入什么且文档包含这些词时，这类搜索表现很好。

它在以下情况表现欠佳：

• 同义词：例如 “attorney” 与 “lawyer”\n- 拼写错误：例如 “reciept” 与 “receipt”（可以加入容错，但本质上仍基于词）\n- 相同含义不同表达：例如 “cancel my plan” 与 “end my subscription”

向量搜索：含义占优

向量数据库存储嵌入——含义的数值表示。查询也被嵌入，结果按相似度排序，因此即便确切词语不匹配，也能检索到概念相关的内容。这就是向量搜索在语义搜索和RAG中受欢迎的原因。

SQL 查询：结构化需求占优

SQL 是处理以下工作的正确工具：

• 精确匹配（IDs、SKUs、邮箱）\n- 汇总与报表（计数、求和、仪表盘）\n- 严格的连接与业务逻辑

当精确性不可妥协时（例如 “orders for customer_id = 123”），向量并不是合适之选。

筛选依然重要

即使使用语义搜索，你通常也需要经典的筛选——价格区间、日期、语言、分类与权限。大多数真实系统采用混合方式：先用 SQL/元数据筛选，再在允许集合内做向量相似度排序。

向量搜索的底层工作原理（轻量级）

当你把数据存入向量数据库时，每个条目都变成一串长数字（嵌入）。搜索即是：“找到与此查询向量最接近的向量”。

索引：为什么不能把每个都比较一遍

现实中的数据库可能包含数百万条向量。把查询向量与每个向量比较会太慢也太昂贵。因此向量数据库会建立一个索引——帮助快速缩小候选集的结构，让系统只对少量向量测距。

ANN（近似最近邻）用通俗的话说

大多数向量搜索使用近似最近邻（ANN）。所谓“近似”意味着数据库尝试快速找到非常好的匹配，而不是每次都保证数学上绝对最优的前几项。

一个有用的类比是：不是逐本翻阅图书馆里的每本书，而是用一张聪明的地图先把你带到正确的书架。

延迟与准确率：所谓的“召回率”意味着什么

这种权衡通常通过“索引要多努力搜索”的设置来调优：

• 更低延迟：结果返回更快，但可能错过一些好匹配。\n- 更高召回率：能找到更多真正的最佳匹配，但可能更耗时。

实际上，召回率是“结果中包含人类认为正确答案的频率”。对于 RAG 来说，更高的召回率通常能减少遗漏关键事实（但会增加成本）。

你可能听到的索引类型

• HNSW：构建一个向量图，使搜索可以在邻居间“跳跃”高效查找。\n- IVF：先将向量聚类，再只搜索最有希望的簇。

不同产品（pgvector、Pinecone、Weaviate）以不同的默认值和调优项暴露这些思路，但目标一致：可控精度下的快速相似度搜索。

用于搜索与 RAG 的典型向量数据库工作流

向量数据库的工作流大致是“存储事物，然后检索最佳匹配”的循环。关键是你要把含义（嵌入）与原始内容一起存储，以便检索能匹配概念，而不仅是精确词句。

1) 摄取：文档 + 嵌入 + 元数据

首先收集文档（页面、PDF、工单、产品描述等），将它们拆分为块，并为每个块生成嵌入。

在数据库中通常存储：

• 文本/内容：用户可能阅读的块\n- 嵌入：用于相似度搜索的向量\n- 元数据：如 tenant_id、source、category、created_at、权限

2) 查询：检索候选项（向量、关键词或两者）

在搜索时，将用户查询嵌入并请求最近的向量。

混合搜索：结合关键词信号与向量

很多团队将向量相似度与关键词评分（类似 BM25）结合，这样既能得到语义匹配，又能奖励诸如 SKU、名称或错误字符串等确切词语。

过滤：按属性缩小结果（租户、分类、时间）

在检索之前或过程中应用元数据过滤——尤其适用于多租户应用和权限控制。过滤也有助于提高精确度（例如“仅最近 90 天”、“仅在帮助中心”）。

重新排序：在检索后提升前排结果

常见模式是：先快速检索前 50–200 条候选，再用更强的模型或规则对前 10–20 条进行重新排序（新鲜度提升、来源优先级等）。

3) RAG：将上下文提供给模型

对于 RAG，你将最终的顶级块作为上下文发送到 LLM 提示，通常附带引用并指示“若未找到则不要回答”。结果是基于你存储内容生成的、有依据的回答，而不是模型的臆测。

快速原型建议：更快交付 RAG 搜索功能

如果你的目标是快速验证检索质量（而不是花数周时间接基础设施），像 Koder.ai 这样的低代码平台可以帮助你从聊天界面快速原型端到端的语义搜索或 RAG 应用。实际上，这意味着你可以快速搭建 React 前端、Go 后端和 Postgres 数据库（包含基于 pgvector 的方案），使用规划模式、快照和回滚进行迭代——准备好时再导出源码。

pgvector：把向量放进 Postgres

pgvector 是一个 PostgreSQL 扩展，让你可以直接在现有数据库中存储和搜索嵌入向量。你无需运行单独的“向量数据库”，只需在已有表中添加一个新列（vector），与存放用户、产品、文档和元数据的表同处。

何时适合用 pgvector

当团队已经承诺使用 Postgres 且想减少系统数量时，pgvector 很有优势。如果应用的事实数据（truth）就在 Postgres 中，把向量也放在这里可以简化架构：统一备份策略、统一访问控制、统一迁移工具，以及熟悉的 SQL 用于连接和过滤。

优点：事务数据与语义数据同一系统

最大收益是把结构化数据和向量放在一起。你可以做语义搜索同时应用“常规”约束——比如 tenant_id、category、status 或权限——而无需在系统间缝合结果。在运维上，这通常更容易交付：使用现有的 Postgres 部署加一个扩展。

需要考虑的权衡

高流量的向量工作负载会把 Postgres 推到其最初设计的边界之外。你需要考虑向量索引（常见的有 IVFFlat 或 HNSW）、内存设置、vacuum 行为和查询模式。

如果你预期会有非常大的嵌入集合、频繁并发的相似度搜索或快速增长，扩展与调优可能比托管向量服务更需要人工干预。但对许多团队来说，pgvector 是“简单起步”的选项，而且往往能走得很远。

Pinecone：托管的向量搜索服务

Pinecone 是一个完全托管的向量数据库服务：你把嵌入（向量）连同 ID 和元数据发送给它，它为你提供快速相似度搜索，日常运维工作大多由服务方处理。

你能得到（以及不需要管理的东西）

使用 Pinecone，通常不需要自己配置机器、每日调优低级索引设置或构建扩容与故障转移架构。你通过 API 上报向量、查询最近邻，并按元数据过滤结果（例如：语言、租户、文档类型或访问级别）。

最适合的场景

Pinecone 非常适合：\n\n- 希望快速上线而不构建复杂运维管道\n- 在生产环境运行语义搜索或 RAG，且流量可能不可预测\n- 优先考虑稳定的延迟与运维可靠性而不是底层基础设施控制

团队通常在检索是核心功能且希望把“向量搜索作为服务”而非另一个自运维系统时选择它。

优点

Pinecone 最大的优势是快速投入生产。托管的扩展与可靠性功能（根据计划而异）减少了容量规划和事故响应时间。它也通常能与常见的 AI 堆栈平滑集成，用于搜索与 RAG。

缺点与权衡

主要的权衡是供应商锁定和随查询量、存储与吞吐增长的持续使用成本。你还要确认数据驻留、合规要求以及组织对敏感数据的处理方式在签约前是否满足需求。

Weaviate：开源的向量数据库选项

Weaviate 是一个开源向量数据库，提供完整的“AI 搜索后端”并带有 GraphQL API。如果你希望控制基础设施（或在自选云上部署），但仍想要一种类似产品的体验——模式、筛选、索引选项与集成——Weaviate 常被列入候选名单。

它是什么

高层看，Weaviate 存储对象（你的文档、产品、工单等）及其元数据和向量嵌入。你可以用语义相似度查询它（“找类似的东西”），同时应用筛选（“仅过去 30 天”、“仅 category = support”）。GraphQL API 对想要表达性查询而不想设计大量自定义端点的团队很友好。

最适合的场景

Weaviate 更适合那些：\n\n- 想要自托管或灵活部署选项（Kubernetes、虚拟机或托管）\n- 需要不仅仅是“向量”，还要模式和元数据建模\n- 预期会使用连接器/模块（用于嵌入生成、重排序或集成）随着系统增长而扩展

优点与权衡

优点： 强大的模式/元数据支持、丰富的模块/集成生态、以及可配置的索引方法，便于调优性能。\n缺点： 如果自行运行，你需要负责运维——升级、扩容、监控、备份与事故响应。随着模块、多租户与复杂模式的增加，如果不早期制定清晰约定，系统可能变得难以理解与维护。

在比较选项时，Weaviate 常位于“把向量加到现有数据库”与“完全托管服务”之间，提供了灵活性但要承担运维责任。

如何在 pgvector、Pinecone 与 Weaviate 之间做选择

选择向量数据库不是“谁最好”的问题，而是“谁更适合”：你想在哪里运行它、预期会有多大规模、查询模式如何、以及团队能承担多少运维工作。

1) 部署模型

pgvector 是“把向量放进 Postgres”。如果你的应用已经在 Postgres 上并且希望把商业数据与嵌入放在同一处，这很理想。\n\nPinecone 是托管服务。你以牺牲部分控制换取更快的采用速度：更少的调参、也更少要维护的基础设施。\n\nWeaviate 是开源并可自托管或使用托管方案。如果你想要一个向量原生系统但偏好开源工具，这通常是中间选项。

2) 规模需求

在较小规模下，三者都能良好工作。随着增长，问自己：\n\n- 现在与 12 个月后的向量数量？\n- 读写率（QPS、摄取突发）？

若预期快速增长与高 QPS，Pinecone 往往在运维简便性上胜出。若增长适中且你已在大规模运行 Postgres，pgvector 可能更具成本效益。

3) 查询需求

如果你需要大量关系型过滤（连接、复杂谓词）与相似度搜索并行，pgvector 很有吸引力。\n\n如果你需要混合搜索（关键词 + 语义）、丰富的筛选或强隔离的多租户支持，比较 Pinecone 与 Weaviate 的功能差异很重要。

4) 运维需求

诚实评估你的备份、监控、升级与值班负担。托管能减少运维负担。自托管可能更便宜，但前提是团队有能力并愿意可靠地运行它。

数据建模建议，避免未来痛点

良好的向量搜索始于一个朴实但可靠的记录结构。把每个“可搜索单元”当作一行/对象，以便以后可以被获取、筛选和解释。

实用的最小模式

至少应存储：

• id：稳定的主键（UUID 或确定性哈希）\n- vector：嵌入向量\n- source：来源（文档 id、URL/路径、工作区、租户）\n- text chunk：被嵌入的精确内容（或其指针）\n- metadata：用于筛选和调试的字段

这让检索变得简单：向量搜索返回 id，然后你取出 chunk + 上下文给用户或送入 RAG。

分块：大小与重叠会改变结果

分块是你能控制的最大质量杠杆。小块更“精确”但可能丢失上下文；大块保留上下文但会稀释信号。

一个常见起点是 200–400 tokens，10–20% 重叠，然后根据内容做调整。对于 API 与法律文本，较小的块通常更好；对于叙事类内容，稍大的块更能保留意义。

有助于筛选（与解释）的元数据

存储你会实际查询的元数据：

• 访问/租户字段（权限）\n- 文档类型、语言、created_at\n- 产品、分类、标签\n- chunk_index 与章节标题（便于调试）

避免放入巨大不可索引的 JSON，尽量把常被筛选的字段保持为容易索引的简单字段。

对可能变化的内容进行版本控制

嵌入不是永恒不变的。记录 embedding_model、model_version 和 chunking_version（以及 created_at）。当你升级模型时，可以并行地重新嵌入并逐步切换流量，避免混用不兼容的向量。

性能、成本与质量考量

向量搜索在演示中看起来“即时”，但上线后可能更慢或更贵。好消息是主要驱动因素可预测，并且无论你用 pgvector、Pinecone 还是 Weaviate 都能被管理。

延迟与成本：真正影响的因素

大多数团队会低估非搜索部分的成本。\n\n- 嵌入生成：生成嵌入可能是最大的账单来源且最慢，尤其是当你嵌入大量文本或频繁重嵌入时。使用嵌入缓存并批量请求。\n- 索引与重建索引：向量索引加速相似度搜索，但构建索引需要时间与资源。为回填数据时的峰值做好计划。\n- 查询量与过滤：高 QPS、复杂元数据过滤和频繁的混合查询会增加延迟。关注 p95 延迟而不仅仅是平均值。

质量：相关性主要取决于你的输入

更好的相似度检索并不自动等于更好答案。\n\n- 分块：块太大会带来嘈杂上下文，太小会丢失含义。以 200–500 tokens 为起点，根据内容调整。\n- RAG 策略：检索只是第一步。简单的重排序或“先 top-k 再重排”策略通常比更换向量数据库带来更大的改进。\n- 时效性：如果数据在变更，陈旧的嵌入会导致错误匹配。为何时重嵌（如编辑时、夜间或按热门度）定义规则。

评估：在优化前先测量

创建一个小的测试集：30–100 个真实查询，每个带若干“好”预期结果。测量相关性（top-k 命中率），在你调整分块、索引或提示时跟踪变化。

必不可少的安全措施

把嵌入当成可能敏感的数据对待：\n\n- 为应用/用户强制执行访问控制。\n- 为多租户使用租户隔离（命名空间、schema 或独立索引）。\n- 制定敏感数据处理计划：脱敏、静态加密与保留策略。

运营与治理清单

向量搜索的质量不仅与索引有关，还与系统日常的运维方式密切相关。一些治理习惯可以防止“神秘结果”并让审计简单许多。

安全存储内容（或只存指针）

如果你的文档包含敏感数据，考虑把原始内容保存在主数据存储（对象存储、数据库、DMS），只在向量库中存储：\n\n- 一个 ID（指针），\n- 嵌入向量，\n- 最小化的元数据用于筛选。

这能在向量存储被泄露时降低暴露面，并简化访问控制。当你使用多个后端（例如为内部应用用 pgvector，为公开功能用 Pinecone）时也很有帮助。

正确处理更新与删除

如果不清理，嵌入会“记住”旧文本。\n\n- 编辑时：重新嵌入被修改内容并替换旧向量。\n- 删除时：删除向量与元数据，并验证索引反映了变更。\n- 对于 RAG：使缓存块失效，以避免被移除的信息再次出现。

可观测性与反馈回路

记录足够用于调试相关性但不记录敏感信息：\n\n- 查询文本（或脱敏后的版本）、过滤条件与延迟，\n- 返回的 top-k ID（及分数），\n- 用户行为：点击、“有帮助/无帮助”、后续查询。

这能让在模型或数据变化后出现的漂移与回归变得明显。

合规基础

为保留期（向量与日志保存多久）、传输/静态加密与审计需求做计划。如果你在受监管环境中运营，记录数据流与访问路径以便评审不会阻碍发布。

常见错误与如何避免

即使有良好的向量数据库设置，若出现一些常见陷阱结果也会令人失望。下面列出最常见的问题以及早期的规避方法。

1) 到处用向量（忘了筛选）

向量适合表示“含义”，但不适合硬性约束。如果把语义搜索作为唯一工具，结果会显得随机或不安全。

避免方法：把相似性搜索与结构化筛选（tenant_id、产品分类、语言、日期范围）结合起来。把元数据过滤当作查询设计的一等公民，而不是事后补救。

2) 跳过评估只凭感觉行事

在少量提示看起来不错的演示中隐藏着严重的召回与相关性问题。

避免方法：建立一个小的评估集（如 30–100 个真实查询）并跟踪简单指标（top-k 相关性、点击率或人工判断）。在更改嵌入、分块或索引设置后重新运行评估。

3) 不计划模型变更时的重嵌策略

嵌入模型在演进。切换模型（或版本）会改变向量空间，可能在不知不觉中降低检索效果。

避免方法：存储 embedding_model 字段并把嵌入视为可版本化工件。保留重嵌流水线并计划回填（常以增量方式进行）。若成本受限，可先重嵌最常用的内容。

4) 忽视权限控制

如果你的应用有访问控制，检索必须尊重它——否则会暴露受限内容。

避免方法：在检索步骤中用每租户索引、元数据过滤或预计算的 ACL 字段强制权限。用测试验证：例如“用户 A 永远不能检索到用户 B 的文档”，即便是在 top-k 候选项中也要保证。

快速回顾与推荐的下一步行动

向量数据库是为存储嵌入（文本、图像或其它数据的数值表示）并快速检索最相似项而设计的系统。当用户按含义搜索（语义搜索）或你要构建 RAG（检索增强生成）时，它非常适合：帮助 AI 助手在回答前先从你自己的内容中拉取相关段落。

你应选哪个？

实践经验与经验法则：

• pgvector（Postgres 向量）：当你已使用 Postgres 且想保持技术栈简单时选择。适合小到中等负载、需要紧密的关系型连接与筛选的团队。\n- Pinecone：当你想要一个托管服务、尽量少的运维工作并需要可预测扩容与性能时选择。\n- Weaviate：当你想要开源的向量数据库，有强大的功能与灵活性，并且能自行运维或选择托管服务时选择。

一个简单的下一步：用你的数据做原型

在一天内构建一个小型概念验证：\n\n1. 选一个你关心的数据集（工单、文档、产品目录）。\n2. 为 500–5,000 条目生成嵌入。\n3. 实现搜索 + 评估：用 20–50 个真实查询比较结果，衡量“是否找到了正确的东西？”。\n4. 若要做 RAG，加入“检索 top-k 段落 → 生成答案”流程，检查事实性与引用质量。

如果你想要更多实施或成本方面的建议，请参见 /blog。有关定价或托管选项的信息，请查看 /pricing。