症状：你的 RAG 只是找相似段落，却开始承担关系推理、权限判断和历史追踪。
最快解法：相似内容召回优先选 Vector Database；实体关系、多跳查询和审计优先选 Knowledge Graph；生产级 Agent 通常组合使用，但简单数据不要为了“完整架构”强行上图。
这篇文章适合正在为 RAG 应用选存储的开发者，也适合需要追踪复杂关系和决策依据的架构师。
如果你还在评估组合架构的成本、更新流程与权限边界，下面的指标对比可以直接用于方案评审。
先按检索问题做第一轮筛选
Knowledge Graph 和 Vector Database 的根本区别，不是“一个高级、一个简单”，而是它们回答的问题不同。
Vector Database 主要回答：“哪些内容和当前问题语义相似？”文档被切块、生成嵌入向量后，系统可以按照向量距离返回候选内容。这类方式适合产品文档问答、代码片段检索、客服知识库和快速 RAG 原型。向量检索通常还可以叠加关键词、标签、租户和时间过滤；例如 Azure AI Search 的官方文档就将向量字段与预计算嵌入、集成向量化和 RAG grounding 联系在一起。可参考 Azure AI Search 的 Vector Store 文档。
Knowledge Graph 则主要回答：“某个实体和哪些实体存在什么关系？”在 RDF 语义中，图由三元组构成；在属性图中，也通常用节点、关系和属性表达现实对象。W3C 对 RDF 图与三元组的定义可见 RDFa Core 官方规范。
你可以先用下面的判断：
- 用户问“哪篇文档解释了这个错误？”——优先 Vector Database。
- 用户问“这个供应商受到哪家母公司控制，相关合同又影响哪些项目？”——优先 Knowledge Graph。
- 用户问“某个用户过去做过哪些决定，为什么这次应该延续原方案？”——通常需要 Vector Database 加结构化 Memory，复杂时再加入 Knowledge Graph。
- 用户只是要在一周内验证 RAG 能否回答问题——不建议从图谱建模开始。
数据结构不同，维护成本也不同
向量方案的主要工作是文档切块、嵌入生成、索引构建和增量更新。你需要解决的不是“有没有关系”，而是切块是否完整、嵌入模型是否稳定、相似度阈值是否合适，以及召回结果能否满足权限过滤。
它的隐性成本主要有三类：
- 嵌入更新成本：原文改动后，相关切块通常需要重新生成向量。
- 身份丢失风险：如果只保存文本和向量，没有稳定的文档、实体、版本 ID，后续很难把搜索结果映射回真实对象。
- 关系表达不足：两个段落都提到“供应商 A”和“项目 B”，并不等于系统已经知道 A 负责 B，或者 A 通过某个子公司影响 B。
Knowledge Graph 的前期成本更重。你需要定义实体类型、关系类型、唯一标识、属性、来源、时间范围和删除规则，还要处理同名实体合并。例如“苹果”“Apple 公司”和“Apple Inc.”是否为同一实体，不能只交给相似度模型决定。
但图谱一旦治理完成，关系可以被多个应用复用。组织架构查询、供应链追踪、客户 360、合规审计和长期记忆都可以围绕同一批实体与关系构建，而不是每个应用重新从文本中猜一次关系。如果你正在梳理生产级 Memory 的数据边界，也可以结合本站的 AI Agent 架构与开发资料检查实体、来源和权限是否需要独立建模。
注意： GraphRAG 并不等于“部署一个图数据库就完成了知识图谱”。其官方文档说明，标准流程会使用模型进行实体抽取、关系抽取、摘要和社区报告生成；这些步骤会带来额外的索引成本与质量校验工作。(github.com)
多跳问题为什么不能只靠向量搜索
向量搜索可以召回包含相关词义的证据，但它天然不保证关系链条一致。
假设你要回答：“供应商 A 的二级母公司参与了哪些受监管项目？”一个只使用向量检索的流程可能分别召回：
- 供应商 A 的公司介绍；
- A 与母公司的股权说明；
- 某些项目的监管标签；
- 一份旧版供应商名单。
这些材料单独看都相关，但系统仍然需要确认实体是否相同、关系是否在有效期内、股权链条是否连续，以及项目是否确实属于目标范围。只把多个文本块拼到上下文里，不能自动得到可靠的路径。
图查询的优势，是可以直接限制节点类型、关系方向和路径长度。以 Cypher 为例，官方文档支持查询固定长度或可变长度路径，也可以在遍历过程中加入节点和关系条件；但路径范围过大时，匹配数量可能快速增长，因此仍然需要设置边界和过滤条件。可参考 Neo4j 可变长度路径文档。(neo4j.com)
这并不代表向量检索在多跳场景没有用。更稳妥的流程是：
- 用向量搜索找到可能相关的文档、实体别名和事件；
- 根据稳定 ID 将候选证据映射到图节点；
- 用图查询验证关系方向、时间和路径；
- 将路径、原始证据和权限结果一起交给模型生成答案。
GraphRAG 的官方查询说明也采用了类似思路：Local Search 会结合知识图谱中的实体信息与原始文本块，而 Global Search 则依赖社区报告回答更宏观的问题。(github.com)
解释性、权限与删除影响决定生产可用性
企业选择存储层时，不要只看召回率或接口响应时间，还要问三个运维问题：结果能否解释、权限能否继承、数据删除后是否真的消失。
Vector Database 的解释性通常来自“命中的文本块”和相似度分数。它适合展示引用原文，但相似度分数并不等于事实可信度。一个内容相近但主体不同的段落，也可能排在前面。
Knowledge Graph 更容易展示关系路径，例如：
项目 B → 由供应商 A 承包 → A 的母公司为 C → C 属于受监管集团
但图谱也有自己的风险：
- ❌ 关系抽取错误会被后续查询反复复用；
- ❌ 实体合并错误可能让多个客户、部门或项目被串联；
- ⚠️ 删除一个节点时，相关边、来源证据、缓存摘要和向量结果都要同步处理；
- ⚠️ 节点权限不等于文档权限，必须明确谁能看到实体、关系和关系来源。
组合架构尤其要注意身份对应关系。向量结果至少应保存文档 ID、实体 ID、版本号和租户信息；图节点则需要保存原始来源与有效时间。否则你会得到“向量召回了正确段落，但图查询连到了错误实体”的隐蔽故障。
性能和成本应按同一工作负载评估
不要拿某个厂商在小数据集上的 QPS，去和另一个系统在不同硬件、不同查询和不同索引配置下的结果直接排名。你真正需要测的是一条完整链路：
- 导入 1 批新增文档需要多久；
- 重新生成嵌入和重建索引需要多少资源；
- 实体关系抽取调用多少次模型；
- 查询是否需要多轮模型调用；
- 权限过滤后还剩多少有效候选；
- 数据删除、回滚和重建是否会阻塞线上服务。
以 pgvector 官方文档为例，HNSW 和 IVFFlat 的取舍并不相同：IVFFlat 构建更快、内存占用更低，但速度与召回率之间的权衡不同；文档还建议在不超过 100 万行 时，可从 rows / 1000 量级估算列表数，超过该规模则可考虑平方根级别的起点。这些是索引调参建议，不是跨数据库的性能排名。可查看 pgvector 官方索引说明。(github.com)
同一份文档还指出，HNSW 的 ef_search 默认值为 40，过滤条件、死元组和候选列表大小都可能改变最终返回结果。也就是说，Vector Database 的“速度”不能脱离召回率、过滤条件和索引参数讨论。(github.com)
Knowledge Graph 的成本则更多集中在建模、实体对齐、关系抽取、索引和查询优化。Microsoft GraphRAG 文档估计，标准方法中图抽取约占索引成本的 75%；这解释了为什么图谱适合高关系价值场景，却不适合所有内部文档库。(github.com)
组合架构应该怎样分工
组合不是把两套数据库并排部署就结束，而是要提前规定每一层的职责。
一个较稳妥的分工是：
- Vector Database：负责从非结构化内容中召回候选段落、事件和实体提及。
- Knowledge Graph：负责确认实体身份、关系方向、时间范围和多跳路径。
- 关系型数据库或对象存储：负责保存原文、版本、租户、审计日志和删除状态。
- 模型层：负责把已验证的证据和路径组织成自然语言答案，而不是自行补全缺失关系。
你可以按以下 5 步落地：
- 收集真实查询：至少整理一批普通问答、多跳问题、时间问题和权限问题，不要只用演示数据。
- 给问题分类：标记每个问题是相似内容召回、实体查找、关系遍历、历史追踪还是审计证明。
- 先做向量基线：用固定数据、固定嵌入模型和固定
top-k建立可复现结果。 - 只为失败问题增加图层：如果向量方案已经能稳定回答，不要为了架构完整而建模。
- 验证身份和删除链路：测试同名实体、旧版本文档、租户隔离、权限撤销和节点删除后的残留结果。
如果你正在设计生产级 AI Memory，除了存储选择，还应把版本、租户隔离、删除回滚和审计日志纳入同一份架构记录。这样后续切换或组合两种存储时，不必重新猜测数据责任边界。对于需要进一步核对服务范围、交付方式与支持边界的团队，也可以通过官方说明页面了解相关信息，再把这些条件加入技术评估表。
用这张决策矩阵确定单用还是组合
| 业务场景 | 首选方案 | 另一层是否需要 | 主要验收指标 |
|---|---|---|---|
| 简单文档问答 | Vector Database | 通常不需要 | 召回准确性、引用完整性、更新延迟 |
| 快速 RAG PoC | Vector Database | 可暂不部署图谱 | 上线速度、嵌入成本、调试难度 |
| 个性化 AI Memory | Vector Database ＋结构化元数据 | 关系复杂时加入 Knowledge Graph | 用户身份、时间线、记忆覆盖率 |
| 组织、供应链、多跳关系 | Knowledge Graph ＋文本证据 | 建议保留向量召回 | 路径正确性、实体对齐、时间有效性 |
| 监管审计与决策追踪 | Knowledge Graph | 通常需要原文与向量辅助 | 来源链、权限、删除和回滚 |
| 数据简单、关系变化频繁 | Vector Database | 没有明确失败样本时不建议上图 | 维护成本、上线周期、变更风险 |
选择前先回答 4 个问题
- 如果问题中的“相似”比“关联”更重要，先选 Vector Database。
- 如果答案必须说明“通过哪些关系得到”，优先 Knowledge Graph。
- 如果既要找资料，又要验证实体关系，采用组合架构。
- 如果关系数量少、数据变化快、团队没有图谱治理能力，暂时不要部署 Knowledge Graph。
所以，面向 AI Agent 的存储选择应从问题类型开始，而不是从数据库名称开始。对多数早期 RAG，Vector Database 是更低风险的起点；对复杂长期记忆，图谱可以承担实体和关系层；对生产 Agent，组合方案往往更完整，但必须明确谁负责召回、谁负责校验。
当前方案与 Mac 方案，怎么安排验证环境
如果你现在把所有实验都放在本地电脑上，常见问题是硬件长期被索引任务占用、多人无法复用同一环境、权限和依赖难以保持一致。临时使用通用云主机也可能遇到系统环境与 macOS 工具链不匹配、远程桌面体验不稳定、按需测试时资源配置不灵活等问题。
更实际的做法是：先用你已有的数据集和查询样本完成小规模基线，再根据测试周期选择独立的 Mac 远程环境验证本地模型、开发工具链和完整 Agent 流程。它不一定适合长期持续重负载，也不适合必须直连特定物理设备的场景；但如果你的目标是临时 PoC、跨团队测试或短周期验收，独立 Mac 环境通常比反复改造现有方案更容易控制变量。
在评估远程实验环境时，除了关注系统和工具链，还应确认交付范围、权限边界、数据保留方式与支持渠道。你可以将这些条件记录在采购评估表中，再与数据集、查询样本和验收结果一起比较。
在进入部署与性能测试前，还应把向量召回、图查询、Memory 更新和权限撤销放进同一套验收表中。这样最终比较的就不是“哪个技术听起来更先进”，而是哪种存储方式能在你的真实问题上稳定给出可追溯答案。
| 验证项目 | 只用 Vector Database | 只用 Knowledge Graph | 组合方案 |
|---|---|---|---|
| 首次搭建 | 快，适合 PoC | 慢，需要建模与抽取 | 中等，需要定义边界 |
| 语义召回 | 强 | 通常需要额外文本检索 | 强 |
| 多跳关系 | 弱，需额外验证 | 强，但依赖图质量 | 强 |
| 关系解释 | 主要依赖原文引用 | 可展示路径与节点 | 可同时展示路径和原文 |
| 内容更新 | 重点是嵌入与索引 | 重点是实体、关系和来源 | 两套同步机制都要维护 |
| 权限与删除 | 依赖元数据设计 | 依赖节点、边和来源治理 | 身份映射要求最高 |
| 适合团队 | RAG 开发团队 | 数据治理和平台团队 | 有持续运维能力的生产团队 |
最终决策可以压缩成一句话：先用 Vector Database 解决“找得到”，再用 Knowledge Graph 解决“连得上、证得明”；只有当真实查询证明需要关系层时，才值得承担组合架构的维护成本。