Polygres：用Postgres统一向量、图和关系检索，简化AI智能体架构

当数据库成为AI智能体的"工作记忆"

在构建AI智能体（Agent）的过程中，开发者面临一个反复出现的难题：如何让模型可靠地访问企业已有的数据？传统做法往往需要拼凑一套复杂的技术栈——向量数据库负责语义检索，图数据库处理关系数据，再加上一条同步管道把各个系统连接起来。这不仅增加了架构复杂度，也带来了数据一致性和维护成本的双重压力。

最近登上 Product Hunt 的开源项目 Polygres 试图从根本上简化这个问题。它的核心理念很直接：把你已经在用的 Postgres 数据库，直接变成 AI 智能体的"工作记忆"（working memory），或者说——整个数据库就是一个上下文窗口。

这里所说的"工作记忆"借用了认知科学中的概念。在人类认知中，工作记忆是一种容量有限但至关重要的短期信息处理系统——它负责暂存和操控当前任务所需的信息，是推理、决策和问题解决的核心基础。类比到 AI 智能体，大模型的上下文窗口（context window）就扮演着类似角色：模型只能基于当前"看到"的信息进行推理。Polygres 的野心在于，让整个数据库都成为智能体可随时调用的"认知工作台"，而不是让模型在有限的上下文窗口中挣扎。

该项目在 Product Hunt 上获得了 30 个投票和 22 条评论，排名当日第 14 位，被归类于开源、开发者工具与数据库领域。目前 Polygres 处于免费使用阶段，注册即可体验。

Polygres 解决了什么核心痛点

告别多系统拼接的RAG架构

当前主流的 RAG（检索增强生成）与智能体架构，通常要求开发者维护多个异构存储系统。语义搜索交给 Pinecone、Weaviate 这类向量库；关系推理需要 Neo4j 等图数据库；而结构化数据仍然躺在关系型数据库里。三套系统之间要靠 ETL 或同步管道保持数据一致，任何一环出问题都可能让智能体读到过时或错误的数据。

RAG 的核心工作原理是：当用户向智能体提出问题时，系统先从外部知识库中检索出与问题最相关的文档片段，然后将这些片段作为上下文注入大模型的提示（prompt）中，让模型基于这些"证据"生成回答。这种架构的优势在于不需要微调模型就能让其访问最新数据，但工程实现上却面临显著挑战：检索质量直接决定生成质量（garbage in, garbage out），而不同类型的查询（语义匹配、精确过滤、关系推理）往往需要不同的检索后端，导致系统复杂度呈乘数增长。典型的生产级 RAG 系统需要处理文档切片策略、嵌入模型选择、检索重排序（reranking）、上下文压缩等多个环节，每个环节都是潜在的故障点。

Polygres 的思路是回归数据源本身。它基于 Postgres 构建，通过一个统一的混合 API（hybrid API）同时提供四种检索能力：

• 结构化行检索：直接读取关系型数据
• 关联关系检索：处理数据之间的图式连接
• 语义匹配：类似向量检索的相似度查询
• 全文搜索：传统的文本检索

关键在于，这些能力都是在**数据源头（at the source）**完成关联的，无需额外的向量存储、图数据库或同步流程。

构建基于真实数据的Grounded Agents

Polygres 强调构建 "grounded agents"——即基于真实业务数据、有事实依据的智能体。相比让大模型凭空生成或依赖脱离上下文的检索结果，把关系型、图式和向量三种上下文在同一数据源中联合查询，能显著降低幻觉风险，也让智能体的输出更具可追溯性。

大模型的"幻觉"（hallucination）问题是当前 AI 应用落地的核心障碍之一。幻觉指的是模型生成看似合理但实际上不正确或无中生有的内容。其成因是多方面的：模型在训练阶段学到的是语言模式的统计规律而非事实本身；当模型缺乏足够的上下文信息时，会倾向于"编造"看起来连贯的答案来填补知识空白；而检索增强虽然能缓解这个问题，但如果检索到的信息本身是碎片化的、缺乏关联上下文的，模型仍可能基于不完整的信息做出错误推断。

Grounding（接地）技术的核心思想是：让模型的每一个推理步骤都能追溯到具体的数据来源。当关系型数据（"这个客户购买了什么产品"）、图式数据（"这个产品与哪些供应商有关联"）和语义数据（"与该产品功能相似的其他产品"）能在同一次查询中被联合获取时，智能体获得的上下文信息更加完整和自洽，这从根本上减少了模型需要"脑补"的空间。

Postgres 为什么是AI智能体的理想数据载体

选择 Postgres 作为底座并非偶然。作为最流行的开源关系型数据库之一，Postgres 本身已经具备强大的扩展生态：pgvector 提供向量检索能力，全文搜索是其原生功能，而通过递归查询和 JOIN 也能实现相当程度的图式遍历。

pgvector 是 Postgres 的一个开源扩展，它允许数据库存储和索引高维向量（vector embeddings）。向量嵌入是将文本、图像等非结构化数据通过深度学习模型（如 OpenAI 的 text-embedding 系列、开源的 sentence-transformers 等）转换为固定长度的浮点数数组的过程。这些向量在高维空间中的"距离"反映了原始数据在语义上的相似程度。pgvector 支持多种距离度量（余弦相似度、欧氏距离、内积），并提供 IVFFlat 和 HNSW 两种近似最近邻（ANN）索引算法。HNSW（Hierarchical Navigable Small World）算法是目前向量检索领域的主流选择，它通过构建多层图结构实现高效的近似搜索，在召回率和查询速度之间取得了良好平衡。虽然在十亿级向量的极端规模下，pgvector 的性能可能不及 Milvus、Qdrant 等专用向量数据库，但对于百万级以下的数据集，其性能已经足够满足大多数生产需求。

在图式遍历方面，虽然 Postgres 不是原生图数据库，但通过递归公共表表达式（Recursive CTE，即 WITH RECURSIVE 语法），可以实现多跳关系查询——例如"找到某用户的朋友的朋友中，购买过特定产品的人"。这种能力虽然在复杂图算法（如 PageRank、社区检测、最短路径）方面不如 Neo4j 等专用图数据库，但对于智能体场景中最常见的 2-3 跳关系查询已经绰绰有余。更重要的是，这些查询可以与传统 SQL 查询无缝组合，避免了跨系统查询的延迟和一致性问题。

Polygres 相当于把这些分散的能力封装成一个面向 AI 场景的统一接口。对于绝大多数企业而言，业务数据早已存放在 Postgres 中，无需迁移数据、无需引入新的基础设施，就能直接在"已有的数据之上"构建智能体。这种"零迁移"的特性，是它相比独立向量数据库方案的重要优势。

开源与灵活的部署方式

Polygres 提供了两种部署选择，兼顾了便捷性与可控性：

托管云服务

对于希望快速上手的团队，可以直接使用官方的托管云（managed cloud），省去运维成本，注册即用。

自托管开源组件

对于有数据合规、隐私或成本考量的企业，Polygres 提供开源组件支持自托管（self-host）。这意味着敏感数据可以完全保留在自己的基础设施内，同时享受统一混合检索带来的架构简化。开源属性也让社区能够审计代码、贡献功能，这在数据基础设施领域尤为重要。

适用场景与局限性分析

Polygres 代表了 AI 数据基础设施的一个明确趋势——收敛（consolidation）。随着智能体应用走向生产环境，过度复杂的技术栈正在成为负担。与其为每种检索模式维护一个专用系统，不如在一个成熟、可靠的数据库上提供统一的多模态检索能力。

这种收敛趋势并非 Polygres 独有，而是整个 AI 基础设施领域的结构性演进。2023-2024 年间，我们已经看到多个类似的信号：Supabase 在其 Postgres 平台上原生集成了 pgvector 和 AI 工具链；Neon 推出了面向 AI 场景的 serverless Postgres；而 AlloyDB（Google Cloud）和 Azure Cosmos DB for PostgreSQL 也纷纷在托管 Postgres 服务中嵌入向量搜索能力。在更广泛的数据库领域，SingleStore 提出了"数据库即 AI 平台"的定位，ClickHouse 增加了向量搜索功能。这些动向共同指向一个判断：生产级 AI 应用不需要一个全新的数据存储范式，而是需要在成熟的数据基础设施上叠加 AI 原生能力。对于工程团队来说，每减少一个需要维护的独立系统，就意味着更少的故障面、更低的人力成本和更快的迭代速度。

当然，这种"一站式"方案也面临考验。在超大规模向量检索场景下（例如数十亿向量的实时检索），Postgres 的性能是否能媲美专用向量数据库仍需验证；对于复杂的图算法（如大规模社交网络的社区发现、知识图谱的多步推理），专用图数据库的表达能力和计算效率也更强。Polygres 的定位更适合那些数据规模适中（百万到千万级记录）、希望降低架构复杂度、且核心数据已在 Postgres 中的团队。

对于正在探索 RAG 和智能体开发的开发者来说，Polygres 提供了一条颇具吸引力的路径：不必推倒重来，在你已有的数据库上就能构建有事实依据的 AI 应用。考虑到它目前免费且开源，这无疑是一个低门槛的试验起点。

核心要点