几乎每一个“人工智能驱动搜索”和检索增强生成（RAG）功能背后，都依赖于同一个默默无闻的主力技术：基于向量的相似度搜索。如果你正在构建任何通过语义而非精确关键词来查找相关内容的系统，你需要理解向量——以及更重要的是，何时需要、何时不需要为它们使用专用的数据库。
从文本到向量
嵌入是一组数字——即一个向量——它捕捉了一段文本（或图像、音频）的含义。嵌入模型将“取消我的订阅”和“如何停止计费”转化为在空间中位置相近的向量，尽管它们几乎没有任何相同的词汇。
这种邻近性正是其中的诀窍。含义被转化为几何关系：相似的概念在高维空间中彼此靠近，而“查找相关内容”也就变成了“查找邻近的向量”。
相似度搜索的工作原理
一旦你的内容以向量形式存储，检索在原则上就很直接：
- 将用户的查询转化为向量。
- 找到与它最接近的存储向量——通常通过余弦相似度计算。
- 返回这些最近邻向量所属的内容。
挑战在于当拥有数百万个向量时，如何快速执行第二步。与每个向量逐一比较太慢了，因此向量索引使用近似最近邻（ANN）算法，以牺牲微小的精度为代价换取巨大的速度提升。
你真的需要向量数据库吗？
这才是关键问题，而诚实的回答是：通常起初并不需要。
如果你已经在运行 PostgreSQL——而使用 Supabase 就意味着你在运行它——那么 pgvector 扩展可以在你现有的数据库中直接添加向量列和 ANN 索引。这意味着：
- 只需维护一个系统进行运营、备份和安全防护，而不是两个。
- 单次查询即可实现向量数据与常规关系型数据之间的连接——可以同时按租户、日期或类别以及相似度进行过滤。
- 无需额外的服务进行同步、付费或保持一致性。
对于大多数拥有多达数百万向量的产品来说，pgvector 并不是一种妥协——它是务实且正确的选择。
专用向量数据库何时才物有所值
当你遇到真正的瓶颈时，再过渡到专用的向量存储：
- 超大规模——数千万或数亿个向量，此时专门构建的索引和分片技术变得至关重要。
- 高查询吞吐量，这会与你的事务性工作负载产生竞争。
- 高级检索功能，如复杂的混合搜索或过滤，专用引擎能更好地处理这些需求。
即便如此，也要将应用程序依赖的元数据保留在 Postgres 中；让向量存储只专注于它独具优势的领域。
确保检索质量
数据库很少是难点——检索质量才是。以下几点对质量的影响远超你对引擎的选择：
- 使嵌入模型与你的领域相匹配，并在索引和查询时使用相同的模型。
- 将向量搜索与关键词搜索相结合（混合搜索），以便产品名称等精确术语仍能命中。
- 在相似度计算之前或同时进行过滤，以确保结果符合租户隔离和权限要求。
- 对顶部候选结果进行重排序，将最佳上下文推至前列。
从 pgvector 开始简单入手，在真实查询中衡量检索质量，仅当数据指标表明有必要时才扩展基础设施。如果你正在构建人工智能搜索或检索增强生成（RAG）系统，并希望它快速且
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
