了解什么是向量数据库、嵌入如何实现相似性搜索,以及在 AI 搜索与 RAG 场景中何时选择 pgvector、Pinecone 或 Weaviate。

向量数据库是为存储和检索嵌入而设计的系统——嵌入是表示文本、图像或其它数据“含义”的数值列表。与其问“这条记录是否包含确切单词 refund?”,不如问“哪些记录与这个问题最相似?”然后返回最接近的匹配项。
把每个文档(或产品、工单、FAQ)想象成地图上的一个点。关于同一主题的项会落得很近——即便使用了不同的词。向量数据库就是能够快速回答:这个新点附近有什么? 的工具。
传统的 SQL 数据库在你知道问题结构时表现出色:按日期、user_id、status 等筛选。关键词搜索在正确答案恰好包含你输入的相同词语时很有效。
向量数据库不同,因为它关注语义相似性。它适合处理诸如“如何拿回我的钱?”这样的查询,并能找到说“我们的退款政策……”的内容,而不需要完全相同的措辞。
这并不取代 SQL 或关键词搜索。在很多真实系统中,你会同时使用两者:用 SQL/过滤实现业务规则(地区、权限、新鲜度),用向量搜索处理“含义”。
如果只记一句话:向量数据库是一个针对嵌入的**“最相似项”引擎**,针对快速且大规模的相似度检索进行优化。
向量数据库之所以可用,是因为嵌入让你能用数值比较含义。你不去阅读每个数字;用它们来对两段内容的“接近程度”进行排序。
嵌入是一串数字(通常是数百或数千维),表示一段内容。每个数字捕捉由模型学习到的含义的某个方面。你不需要直接解释单个数字;重要的是相似内容会产生相似的数字模式。
把它想象成高维空间的坐标:关于“退款政策”和“退货”的句子会落得很近,即便他们使用了不同的词语。
不同的嵌入模型把不同媒体变成向量:
一旦一切都变成了向量,数据库就可以用相同的核心操作在大集合上搜索:“找到最接近的向量”。
决定“最接近”时,系统使用一些简单的评分规则:
你不需要手算这些——重要的是分数越高表示“越相似”。
大多数搜索质量的提升来自于更好的嵌入与更合理的分块,而不是换数据库。如果你的模型不能抓住领域术语(产品名、内部术语、法律表述),即使是最好的向量索引也只能返回“最接近的错误答案”。选择 pgvector、Pinecone 或 Weaviate 很重要,但选择合适的嵌入模型和输入格式通常更关键。
关键词搜索、SQL 查询与向量搜索解决不同问题——把它们混为一谈是导致令人失望结果的常见原因。
传统搜索(Elasticsearch、Postgres 全文等)匹配词语与短语。当用户知道要输入什么且文档包含这些词时,这类搜索表现很好。
它在以下情况表现欠佳:
向量数据库存储嵌入——含义的数值表示。查询也被嵌入,结果按相似度排序,因此即便确切词语不匹配,也能检索到概念相关的内容。这就是向量搜索在语义搜索和RAG中受欢迎的原因。
SQL 是处理以下工作的正确工具:
当精确性不可妥协时(例如 “orders for customer_id = 123”),向量并不是合适之选。
即使使用语义搜索,你通常也需要经典的筛选——价格区间、日期、语言、分类与权限。大多数真实系统采用混合方式:先用 SQL/元数据筛选,再在允许集合内做向量相似度排序。
当你把数据存入向量数据库时,每个条目都变成一串长数字(嵌入)。搜索即是:“找到与此查询向量最接近的向量”。
现实中的数据库可能包含数百万条向量。把查询向量与每个向量比较会太慢也太昂贵。因此向量数据库会建立一个索引——帮助快速缩小候选集的结构,让系统只对少量向量测距。
大多数向量搜索使用近似最近邻(ANN)。所谓“近似”意味着数据库尝试快速找到非常好的匹配,而不是每次都保证数学上绝对最优的前几项。
一个有用的类比是:不是逐本翻阅图书馆里的每本书,而是用一张聪明的地图先把你带到正确的书架。
这种权衡通常通过“索引要多努力搜索”的设置来调优:
实际上,召回率是“结果中包含人类认为正确答案的频率”。对于 RAG 来说,更高的召回率通常能减少遗漏关键事实(但会增加成本)。
不同产品(pgvector、Pinecone、Weaviate)以不同的默认值和调优项暴露这些思路,但目标一致:可控精度下的快速相似度搜索。
向量数据库的工作流大致是“存储事物,然后检索最佳匹配”的循环。关键是你要把含义(嵌入)与原始内容一起存储,以便检索能匹配概念,而不仅是精确词句。
首先收集文档(页面、PDF、工单、产品描述等),将它们拆分为块,并为每个块生成嵌入。
在数据库中通常存储:
在搜索时,将用户查询嵌入并请求最近的向量。
很多团队将向量相似度与关键词评分(类似 BM25)结合,这样既能得到语义匹配,又能奖励诸如 SKU、名称或错误字符串等确切词语。
在检索之前或过程中应用元数据过滤——尤其适用于多租户应用和权限控制。过滤也有助于提高精确度(例如“仅最近 90 天”、“仅在帮助中心”)。
常见模式是:先快速检索前 50–200 条候选,再用更强的模型或规则对前 10–20 条进行重新排序(新鲜度提升、来源优先级等)。
对于 RAG,你将最终的顶级块作为上下文发送到 LLM 提示,通常附带引用并指示“若未找到则不要回答”。结果是基于你存储内容生成的、有依据的回答,而不是模型的臆测。
如果你的目标是快速验证检索质量(而不是花数周时间接基础设施),像 Koder.ai 这样的低代码平台可以帮助你从聊天界面快速原型端到端的语义搜索或 RAG 应用。实际上,这意味着你可以快速搭建 React 前端、Go 后端和 Postgres 数据库(包含基于 pgvector 的方案),使用规划模式、快照和回滚进行迭代——准备好时再导出源码。
pgvector 是一个 PostgreSQL 扩展,让你可以直接在现有数据库中存储和搜索嵌入向量。你无需运行单独的“向量数据库”,只需在已有表中添加一个新列(vector),与存放用户、产品、文档和元数据的表同处。
当团队已经承诺使用 Postgres 且想减少系统数量时,pgvector 很有优势。如果应用的事实数据(truth)就在 Postgres 中,把向量也放在这里可以简化架构:统一备份策略、统一访问控制、统一迁移工具,以及熟悉的 SQL 用于连接和过滤。
最大收益是把结构化数据和向量放在一起。你可以做语义搜索同时应用“常规”约束——比如 tenant_id、category、status 或权限——而无需在系统间缝合结果。在运维上,这通常更容易交付:使用现有的 Postgres 部署加一个扩展。
高流量的向量工作负载会把 Postgres 推到其最初设计的边界之外。你需要考虑向量索引(常见的有 IVFFlat 或 HNSW)、内存设置、vacuum 行为和查询模式。
如果你预期会有非常大的嵌入集合、频繁并发的相似度搜索或快速增长,扩展与调优可能比托管向量服务更需要人工干预。但对许多团队来说,pgvector 是“简单起步”的选项,而且往往能走得很远。
Pinecone 是一个完全托管的向量数据库服务:你把嵌入(向量)连同 ID 和元数据发送给它,它为你提供快速相似度搜索,日常运维工作大多由服务方处理。
使用 Pinecone,通常不需要自己配置机器、每日调优低级索引设置或构建扩容与故障转移架构。你通过 API 上报向量、查询最近邻,并按元数据过滤结果(例如:语言、租户、文档类型或访问级别)。
Pinecone 非常适合:\n\n- 希望快速上线而不构建复杂运维管道\n- 在生产环境运行语义搜索或 RAG,且流量可能不可预测\n- 优先考虑稳定的延迟与运维可靠性而不是底层基础设施控制
团队通常在检索是核心功能且希望把“向量搜索作为服务”而非另一个自运维系统时选择它。
Pinecone 最大的优势是快速投入生产。托管的扩展与可靠性功能(根据计划而异)减少了容量规划和事故响应时间。它也通常能与常见的 AI 堆栈平滑集成,用于搜索与 RAG。
主要的权衡是供应商锁定和随查询量、存储与吞吐增长的持续使用成本。你还要确认数据驻留、合规要求以及组织对敏感数据的处理方式在签约前是否满足需求。
Weaviate 是一个开源向量数据库,提供完整的“AI 搜索后端”并带有 GraphQL API。如果你希望控制基础设施(或在自选云上部署),但仍想要一种类似产品的体验——模式、筛选、索引选项与集成——Weaviate 常被列入候选名单。
高层看,Weaviate 存储对象(你的文档、产品、工单等)及其元数据和向量嵌入。你可以用语义相似度查询它(“找类似的东西”),同时应用筛选(“仅过去 30 天”、“仅 category = support”)。GraphQL API 对想要表达性查询而不想设计大量自定义端点的团队很友好。
Weaviate 更适合那些:\n\n- 想要自托管或灵活部署选项(Kubernetes、虚拟机或托管)\n- 需要不仅仅是“向量”,还要模式和元数据建模\n- 预期会使用连接器/模块(用于嵌入生成、重排序或集成)随着系统增长而扩展
优点: 强大的模式/元数据支持、丰富的模块/集成生态、以及可配置的索引方法,便于调优性能。\n缺点: 如果自行运行,你需要负责运维——升级、扩容、监控、备份与事故响应。随着模块、多租户与复杂模式的增加,如果不早期制定清晰约定,系统可能变得难以理解与维护。
在比较选项时,Weaviate 常位于“把向量加到现有数据库”与“完全托管服务”之间,提供了灵活性但要承担运维责任。
选择向量数据库不是“谁最好”的问题,而是“谁更适合”:你想在哪里运行它、预期会有多大规模、查询模式如何、以及团队能承担多少运维工作。
pgvector 是“把向量放进 Postgres”。如果你的应用已经在 Postgres 上并且希望把商业数据与嵌入放在同一处,这很理想。\n\nPinecone 是托管服务。你以牺牲部分控制换取更快的采用速度:更少的调参、也更少要维护的基础设施。\n\nWeaviate 是开源并可自托管或使用托管方案。如果你想要一个向量原生系统但偏好开源工具,这通常是中间选项。
在较小规模下,三者都能良好工作。随着增长,问自己:\n\n- 现在与 12 个月后的向量数量?\n- 读写率(QPS、摄取突发)?
若预期快速增长与高 QPS,Pinecone 往往在运维简便性上胜出。若增长适中且你已在大规模运行 Postgres,pgvector 可能更具成本效益。
如果你需要大量关系型过滤(连接、复杂谓词)与相似度搜索并行,pgvector 很有吸引力。\n\n如果你需要混合搜索(关键词 + 语义)、丰富的筛选或强隔离的多租户支持,比较 Pinecone 与 Weaviate 的功能差异很重要。
诚实评估你的备份、监控、升级与值班负担。托管能减少运维负担。自托管可能更便宜,但前提是团队有能力并愿意可靠地运行它。
良好的向量搜索始于一个朴实但可靠的记录结构。把每个“可搜索单元”当作一行/对象,以便以后可以被获取、筛选和解释。
至少应存储:
这让检索变得简单:向量搜索返回 id,然后你取出 chunk + 上下文给用户或送入 RAG。
分块是你能控制的最大质量杠杆。小块更“精确”但可能丢失上下文;大块保留上下文但会稀释信号。
一个常见起点是 200–400 tokens,10–20% 重叠,然后根据内容做调整。对于 API 与法律文本,较小的块通常更好;对于叙事类内容,稍大的块更能保留意义。
存储你会实际查询的元数据:
避免放入巨大不可索引的 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- 用户行为:点击、“有帮助/无帮助”、后续查询。
这能让在模型或数据变化后出现的漂移与回归变得明显。
为保留期(向量与日志保存多久)、传输/静态加密与审计需求做计划。如果你在受监管环境中运营,记录数据流与访问路径以便评审不会阻碍发布。
即使有良好的向量数据库设置,若出现一些常见陷阱结果也会令人失望。下面列出最常见的问题以及早期的规避方法。
向量适合表示“含义”,但不适合硬性约束。如果把语义搜索作为唯一工具,结果会显得随机或不安全。
避免方法:把相似性搜索与结构化筛选(tenant_id、产品分类、语言、日期范围)结合起来。把元数据过滤当作查询设计的一等公民,而不是事后补救。
在少量提示看起来不错的演示中隐藏着严重的召回与相关性问题。
避免方法:建立一个小的评估集(如 30–100 个真实查询)并跟踪简单指标(top-k 相关性、点击率或人工判断)。在更改嵌入、分块或索引设置后重新运行评估。
嵌入模型在演进。切换模型(或版本)会改变向量空间,可能在不知不觉中降低检索效果。
避免方法:存储 embedding_model 字段并把嵌入视为可版本化工件。保留重嵌流水线并计划回填(常以增量方式进行)。若成本受限,可先重嵌最常用的内容。
如果你的应用有访问控制,检索必须尊重它——否则会暴露受限内容。
避免方法:在检索步骤中用每租户索引、元数据过滤或预计算的 ACL 字段强制权限。用测试验证:例如“用户 A 永远不能检索到用户 B 的文档”,即便是在 top-k 候选项中也要保证。
向量数据库是为存储嵌入(文本、图像或其它数据的数值表示)并快速检索最相似项而设计的系统。当用户按含义搜索(语义搜索)或你要构建 RAG(检索增强生成)时,它非常适合:帮助 AI 助手在回答前先从你自己的内容中拉取相关段落。
实践经验与经验法则:
在一天内构建一个小型概念验证:\n\n1. 选一个你关心的数据集(工单、文档、产品目录)。\n2. 为 500–5,000 条目生成嵌入。\n3. 实现搜索 + 评估:用 20–50 个真实查询比较结果,衡量“是否找到了正确的东西?”。\n4. 若要做 RAG,加入“检索 top-k 段落 → 生成答案”流程,检查事实性与引用质量。
如果你想要更多实施或成本方面的建议,请参见 /blog。有关定价或托管选项的信息,请查看 /pricing。
一个向量数据库存储并搜索嵌入(向量:长串数字),这些向量表示文本、图像或其它数据的含义。它不是匹配确切词语,而是返回在语义空间中与查询最相似的条目——当用户用不同的表达询问同一意图时非常有用。
嵌入是由机器学习模型生成的内容的数值“指纹”。你不逐个解读每个数值,而是使用整个向量来比较项之间的相似度。相似的内容(例如“退款政策”和“退货”)会被映射到彼此靠近的向量,从而实现语义检索。
关键词搜索匹配词语和短语(适合精确术语)。向量搜索匹配含义(适合同义词与意图相似的表达)。在实践中,团队通常采用混合搜索:
SQL 适用于结构化、精确的问题:ID、连接(joins)、聚合和严格筛选。向量搜索适用于模糊的“查找相似项”问题。常见模式是:
大多数系统使用**近似最近邻(ANN)**索引。索引会缩小候选集,这样只需对少量向量进行完整评分,而不是把查询向量与每个存储向量逐一比较。这样在延迟和成本上能获得巨大收益,但放弃了对“绝对最优解”每次都保证的承诺。
**余弦相似度(Cosine similarity)**比较的是向量的方向(它们是否指向相同方向)。**点积(Dot product)**既奖励方向相似,也会依赖向量的大小(如果未归一化的话)。
实际操作中:使用与你的嵌入模型推荐的衡量方式,并在索引与查询阶段保持一致。
分块决定每个向量代表的内容。太大:检索到的上下文可能混杂噪声;太小:可能丢失重要上下文。
一个实用起点:
之后根据内容类型调整(API 与法律文本通常更小;叙事类可稍大)。
RAG 通常是一个流水线:
根据部署与运维承受力选择:
常见陷阱包括: