Pg_vectorize：Postgres 上的向量搜索与 RAG

原文 ↗ Hacker News 讨论 ↗

Postgres 正越来越多地被推向向量数据库的角色，像 pg_vectorize 这样的项目建立在 pgvector 之上，在数据库内部直接为嵌入、向量搜索和检索增强生成（RAG）提供高层 API。评论者分享了 pgvector 在大规模场景下的实战经验，将其与 Pinecone 或 Meilisearch 等专门服务进行比较，并深入讨论了分块策略、召回率、性能调优和成本控制等实际问题。大家对将搜索与检索整合进 Postgres 充满热情，但也担心把复杂的 LLM 调用隐藏在数据库扩展中，并怀疑 RAG 相比直接使用更大的上下文窗口或微调模型，是否真的能稳定提升效果。

对 pg_vectorize 和用于向量的 Postgres 的整体反应

  • 许多人对将 Postgres 推向向量/RAG 平台持积极态度，认为这能赋能开发者，而不是依赖专有的“向量数据库”产品。
  • pg_vectorize 被视为 pgvector 之上的便捷高层封装，负责嵌入生成、索引管理和查询编排。
  • 也有人更喜欢直接使用 pgvector，以保持控制权并避免隐藏的复杂性。

成本、托管与架构

  • RAG 可能很昂贵：你需要先为语料库做一次嵌入，然后还要为每次查询支付嵌入和 LLM token 的费用。
  • 自托管嵌入模型（以及最终的聊天模型）被强调为一种控制成本并保持数据私有的方式，但也会增加运维复杂度。
  • 关于嵌入 + 检索是否应当放在数据库内部存在争论；有些人喜欢更简单的架构，而另一些人强烈偏好清晰的分层，并且不希望 Postgres 发起任何外部网络调用。

大规模使用 pgvector

  • 多个报告显示 pgvector 在生产环境中可用，包括处理数千万到数亿行。
  • 优势：开源、索引透明、与关系型数据集成良好、可观测性强。
  • 痛点：高度依赖 vacuum、HNSW 索引构建耗时且很慢、对带过滤条件的 ANN 支持较弱，以及一些 API 摩擦（例如 Python + numpy）。

RAG 的有效性与替代方案

  • 体验不一：有些人觉得朴素的 RAG“很差”或不令人满意；也有人报告效果极佳，尤其是在内部 PDF 和大型技术语料上。
  • 更强的系统会将 RAG 与领域结构结合起来（例如技术支持日志、知识图谱、由专家信号加权），从而获得远高于“纯向量式 RAG”的召回率。
  • 一些人认为在某些领域，直接使用大上下文窗口的 LLM 可以与 RAG 媲美甚至更好；但也有人认为，对于大语料库，RAG 仍然更便宜、更快且更可扩展。

分块与检索策略

  • 简单的固定大小分块往往表现不佳；多条评论强调：
    • 分层 / 语义分块（按标题、章节或上下文聚类）。
    • 使用小模型进行语义分块和上下文感知摘要。
    • “context cluster” / 基于树的方法以及分层摘要（例如类似 RAPTOR 的思路）。
    • 仔细选择哪些分块纳入上下文（类似背包问题的优化）。
  • 一些项目使用句子级嵌入，然后对质心进行聚类和索引。

RAG 概念与误解

  • 有人澄清，RAG 不只是“前置搜索的 LLM”，而是基于检索到的、按向量排序的上下文进行条件化生成的 LLM 输出。
  • 多人指出，“R”（检索）本身就是个难题，向量相似度只是其中一部分；通常还需要混合检索（关键词、结构、向量）。

比较、工具与替代方案

  • pg_vectorize vs PostgresML：pg_vectorize 将模型卸载到外部服务，重点放在嵌入/RAG；PostgresML 则在数据库主机上运行模型，并支持更广泛的 ML（例如监督训练）。
  • 对于较小或不同场景的替代方案包括：带扩展的 sqlite（sqlite-vss）、DuckDB、Meilisearch、Elasticsearch/OpenSearch，以及专用向量数据库。
  • 有人认为 Postgres “已经够用”且很有吸引力，因为它本来就在技术栈中；另一些人则在大规模、复杂工作负载下更偏好专门的搜索引擎。