当大语言模型需要跨会话记住用户的偏好、项目细节和交互历史时，传统的上下文窗口已经无法满足需求。开发者开始构建外部记忆系统来扩展 AI 的能力边界，但现有的向量数据库方案往往只能在语义相似度检索和结构化关系查询之间二选一。Supermemory 作为一款面向 AI 时代的记忆引擎，通过边缘化的 PostgreSQL 架构实现了向量与图存储的混合索引，为这一难题提供了新的解决思路。
纯向量检索的结构化困境
向量数据库的核心原理是将文本转换为高维向量，通过计算向量间的距离来衡量语义相似性。这种方法在处理 "找出与某段描述最相似的内容" 这类需求时表现出色，但它存在几个根本性的局限。首先，向量检索无法表达实体之间的显式关系。嵌入向量可以告诉你 "这段内容与另一段内容在语义上相近"，但它无法告诉你 "供应商 A 供货给德国" 或者 "产品 X 需要温控仓储" 这类业务规则。其次，向量搜索缺乏可解释性。当模型返回一个检索结果时，你只能看到一个相似度分数，无法追溯为什么这个结果被选中，这在需要审计或调试的 production 环境中是严重的问题。最后，向量检索在面对复合查询时力不从心。例如 "查找在欧盟地区且已认证的所有供应商" 这类需要同时满足多个条件的查询，纯粹依赖向量相似度很难精确实现。
知识图谱通过节点和边来显式表示实体与关系，可以自然地表达上述业务逻辑。但传统的图数据库通常不具备高效的语义检索能力，需要额外的向量索引来补充。Supermemory 的设计目标正是在同一个存储层中同时支持这两种查询模式。
边缘架构的技术选型
Supermemory 的技术栈围绕边缘计算场景进行设计，核心存储层基于 PostgreSQL 结合 pgvector 扩展，辅以 Cloudflare Durable Objects 实现自定义向量引擎。这一选型背后的逻辑是充分利用边缘节点的地理分布优势，将记忆存储和服务推送到离用户最近的位置，从而降低检索延迟并提升用户体验。根据官方数据，Supermemory 的设计目标是支持每用户 5000 万 token 的存储规模以及每秒数十亿级别的请求处理能力。
在边缘环境中部署 PostgreSQL 面临着资源限制和网络延迟的挑战。Cloudflare Workers 和 Pages 提供的计算资源相对有限，无法直接运行完整的 PostgreSQL 实例。因此 Supermemory 采用了两层架构：持久化的关系数据存储在 PostgreSQL 中，而需要高频访问的向量索引和热点数据则通过 Durable Objects 分布在边缘节点。Durable Objects 提供了有状态的计算单元，每个对象实例独占一个 V8 isolate，能够维护内存中的索引缓存并处理并发请求。这种架构使得向量检索可以在边缘完成，避免了对远程数据库的往返调用。
PostgreSQL 在 Supermemory 中承担的是结构化数据的存储和查询职责。用户的记忆内容、元数据、时间戳、操作日志等结构化信息存储在 PostgreSQL 表中，可以利用成熟的 ACID 事务和丰富的查询能力。同时 pgvector 扩展为这些文本内容提供了向量表示的支持，使得语义相似度检索可以在同一个数据库引擎内完成。这种统一的数据存储简化了系统架构，避免了维护多套存储系统的复杂性。
混合索引的工程实现
Supermemory 的混合索引策略可以概括为 "向量检索为主、图扩展为辅" 的层级结构。当用户发起一次记忆检索请求时，系统首先通过向量相似度搜索快速筛选出一批候选结果。这一步骤利用 PostgreSQL 的 IVFFlat 或 HNSW 索引在毫秒级时间内完成，能够处理大规模向量集合的近似最近邻查询。IVFFlat 索引通过预先将向量聚类来加速搜索，搜索时只需要检查少数几个聚类中心附近的向量；HNSW 索引则构建多层图结构，通过贪心遍历快速定位相似向量。
在向量检索结果的基础上，Supermemory 会根据查询意图决定是否需要进行图扩展。如果用户的问题是 "我上周在项目中遇到的内存泄漏问题是怎么解决的"，向量检索可以返回语义相近的记忆片段，但无法建立这些片段之间的因果关系和时间顺序。此时系统会激活知识图谱层，将相关记忆按照实体关系进行组织和展开，让模型能够沿着问题的逻辑链条进行推理。这种按需扩展的策略避免了每次查询都遍历整个图谱的开销，同时保持了系统对复杂查询的响应能力。
在存储层面，Supermemory 为每条记忆维护了向量表示和结构化元数据。向量表示存储在 pgvector 的 vector 类型列中，支持 cosine、L2 内积和 inner product 三种距离度量。元数据以 JSONB 格式存储，允许灵活地添加标签、来源、时间戳等附加信息。PostgreSQL 的 GIN 索引可以高效地查询 JSONB 字段，实现快速的元数据过滤。这种设计使得复合查询可以先用元数据筛选出候选集，再在候选集内进行向量相似度排序，避免了在全量数据上进行昂贵向量计算的问题。
边缘场景下的参数配置
在边缘环境中部署类似的混合索引系统时，有几个关键参数需要根据实际负载进行调整。首先是向量索引类型的选择：IVFFlat 索引在索引构建速度和存储开销上优于 HNSW，但检索精度略低，适合对延迟敏感且可以容忍少量误差的场景；HNSW 索引提供更高的检索质量，但需要更多的内存和计算资源，适合规模较小但精度要求高的工作负载。Supermemory 在 Durable Objects 中缓存了热点向量的索引结构，通过内存中的索引加速检索，将磁盘 IO 的影响降到最低。
向量维度是另一个需要权衡的因素。OpenAI 的 text-embedding-ada-002 使用 1536 维向量，更高维度的向量能够捕获更细微的语义差异，但也会线性增加存储和计算开销。对于边缘部署场景，建议根据实际需求选择合适的 embedding 模型，在语义表达能力和资源消耗之间找到平衡点。对于不需要极细粒度语义区分的应用，768 维甚至更低的维度可能已经足够。
关于知识图谱的扩展策略，建议采用惰性加载的方式维护图谱关系。只有当用户查询涉及需要关系推理的问题时，系统才动态地展开相关实体的邻居节点。这种策略可以显著降低存储和维护图谱的开销，同时保持系统对简单语义查询的响应速度。在实现层面，可以为每个实体维护一个轻量级的邻接表，只存储直接关联的实体 ID，需要时再按需加载完整的关系路径。
Supermemory 的实践表明，在边缘环境中构建高效的 AI 记忆系统并非不可能。通过 PostgreSQL 与 Durable Objects 的组合，系统既获得了关系型数据库的可靠性和查询能力，又利用边缘计算的低延迟特性提升了检索性能。混合索引策略让系统能够在语义相似度和结构化关系之间灵活切换，满足不同类型的查询需求。这种架构为构建全球化分布的 AI 应用提供了有价值的参考。
资料来源：
- Supermemory GitHub 仓库：https://github.com/supermemoryai/supermemory
- Supermemory 官方文档：https://docs.supermemory.ai/