.png)
【关键词】
PostgreSQL 16、RAG、知识图谱、Neo4j、混合检索、企业知识库、证据链
【摘要】
企业在建设智能知识库时，往往同时面临RAG检索与知识图谱两个需求。现有主数据库是PostgreSQL 16，是否必须升级PG19甚至重建数据底座？本文给出了一套兼顾一致性、检索质量与可演进性的架构方案：以PG16为唯一事实源，pgvector+全文检索完成混合RAG，Neo4j作为可重建的图投影，Graph作为RAG的第三路召回。这套方案已在制造型企业的工艺文档、设备维修知识库等场景中验证可行。
不升级 PostgreSQL 19，PG16 也能把 RAG + Graph 做起来
一套兼顾一致性、检索质量与可演进性的企业级知识架构
适用读者：技术负责人、架构师、AI平台与知识库建设团队
企业在建设智能知识库时，往往会同时遇到两个需求：一边要用 RAG 找到与问题最相关的原始材料，另一边又希望借助知识图谱理解实体之间的关系、依赖和影响路径。于是，一个很自然的问题出现了：现有主数据库是 PostgreSQL 16，是否必须升级数据库，甚至重新建设一套数据底座？
答案是否定的。PG16 已经具备承担企业知识事实源的基础能力。真正决定系统能否落地的，不是把所有能力塞进同一个数据库，而是明确数据所有权、检索职责和一致性边界。
一、为什么不建议先升级数据库
PostgreSQL 19 的 SQL/PGQ 为属性图查询带来了重要进展，但截至 2026 年 7 月仍处于 Beta 阶段。更重要的是，数据库版本并不会自动解决文档切分、Embedding、实体抽取、关系治理、召回融合、重排、引用和质量评测。
企业真正需要解决的是架构问题，而不是版本焦虑。只要把知识数据、向量数据、关系数据和证据链设计清楚，PG16 完全能够作为稳定底座继续演进。
二、推荐方案：事实源与计算投影分离
图 1：PostgreSQL 保存权威知识，Neo4j 承担图遍历，三路结果统一融合
在这套架构中，PostgreSQL 16 不是一个单纯的向量库，而是整个知识系统的权威账本。文档、版本、Chunk、Embedding、实体、关系、证据和权限都在 PG16 中维护。Neo4j 不保存不可替代的主数据，只保存从 PG16 投影出来的节点和边。
这种设计看起来比“所有数据写两遍”多了一层，但它解决了企业系统最难处理的三个问题：一致性、可追溯性和可重建性。即使图模型发生变化，或者 Neo4j 数据需要清理，仍然可以从 PostgreSQL 重新生成完整图谱。
三、PG16 应该保存哪些数据
要让 RAG 和 Graph 真正协同，数据模型中不能只有 documents 和 embeddings 两张表。建议至少覆盖以下几类对象：
文档与版本：记录来源、版本、发布时间、有效期、状态和内容哈希。
Chunk 与定位信息：保存章节、页码、段落、字符范围和原文引用。
Embedding：保存模型、维度、生成时间和向量版本，避免模型切换后无法追溯。
实体与别名：统一客户、设备、产品、人员、组织等实体的业务身份。
关系与关系证据：关系本身之外，还要记录来源 Chunk、置信度、抽取模型和审核状态。
租户、知识空间和 ACL：权限约束必须进入召回过程，而不是在答案生成后补过滤。
Graph Outbox 与投影检查点：负责增量同步、重试、死信、重建和漂移检测。
四、RAG 不应只有向量检索
向量检索擅长理解语义，但对设备编号、合同号、产品型号、专有名词和精确条款并不总是可靠。企业知识库要获得稳定效果，至少需要三类检索能力共同工作。
三类候选可以通过 RRF 或业务权重融合，再交给 Cross-Encoder 或大模型进行重排。中文场景可在现有环境中使用 zhparser；只有当中文词法检索的质量或吞吐无法满足评测目标时，才需要考虑引入独立搜索引擎。
五、知识图谱必须有证据链
知识图谱最容易出现的问题，不是节点不够多，而是关系无法解释。假设图谱中出现“设备 A 依赖系统 B”这条边，系统必须能够回答：它来自哪份文档、哪个版本、哪一段文字、由哪个模型抽取、置信度是多少、是否经过人工审核。
因此，Graph 建设不应从 Neo4j 的节点和边开始，而应从 PostgreSQL 中的实体、关系和证据模型开始。推荐通过 Outbox 模式将变化投影到 Neo4j：PG 事务提交后产生待处理事件，Worker 使用稳定 ID 执行幂等 MERGE，失败进入重试或死信队列。
Neo4j 可以随时删除并从 PG16 全量重建。
投影 Worker 必须支持幂等、断点续传和批量补偿。
节点与边必须携带 tenant_id、space_id、version 和有效状态。
定期比较 PG 关系数量、版本和图投影状态，形成漂移报告。
低置信度、冲突和敏感关系应进入人工审核工作台。
六、GraphRAG 的正确位置：第三路召回
图 2：Graph 与向量、全文检索并行召回，最终统一回到原始证据
Graph 不应该成为脱离原始资料的独立答案链。更稳妥的做法是先识别问题中的实体，再从向量、词法和图关系三个方向寻找候选证据。Graph 负责补充“谁与谁相关、为什么相关、上下游是什么”，原文 Chunk 负责回答“证据究竟说了什么”。
最终进入大模型上下文的，不应只是图节点名称或一段拼接后的路径，而应该是经过权限过滤的原始 Chunk、关系证据和文档版本。这样生成的答案才能同时具备相关性、解释性和审计能力。
七、什么时候可以不使用 Neo4j
如果图规模较小，查询主要是固定一到两跳，而且不需要最短路径、复杂路径约束、图算法和交互式图探索，可以直接使用 PG16 的关系表与递归 CTE。这样组件更少，部署也更简单。
但当业务需要频繁多跳、影响链分析、上下游追踪、关系探索和图可视化时，将 Neo4j 作为计算投影通常更合适。Apache AGE 虽能在 PG16 中提供图能力，但会将图引擎的升级、兼容性和数据库运维耦合到主库，不宜作为当前主路线。
八、四阶段落地路线
图 3：先把 RAG 做准，再建设证据图，最后接入 GraphRAG
混合 RAG：完成 Chunk、向量、全文、标准问答、权限过滤以及引用返回。
知识抽取：建立实体归一、别名、关系证据、置信度、有效期和审核机制。
图投影：实现 Outbox、幂等同步、重试、死信、重建和漂移检查。
GraphRAG：接入第三路召回，通过 Golden Questions 验证真实贡献后再上线。
九、不要用“组件已部署”代替效果验收
安装了 pgvector、启动了 Neo4j、跑通了一次问答，只能证明链路存在，不能证明知识能力可用。正式验收至少应覆盖以下指标：
Recall@K、MRR 或 nDCG：检索结果是否覆盖正确证据。
引用准确率与答案有据率：生成内容是否能被原文支持。
Graph 贡献率：加入 Graph 后，有多少问题真正获得增益。
权限泄漏率：跨租户、跨空间和失效版本是否被严格隔离。
P95 检索延迟：向量、全文、Graph 和重排各阶段分别统计。
投影积压、失败率和漂移率：Neo4j 是否持续跟上 PG16 的变化。
结语
企业级RAG+Graph的关键，不是寻找一个包办一切的数据库，而是建立清晰的数据所有权和可验证的知识链路。PG16负责保存事实，pgvector和全文检索负责找到材料，Neo4j负责关系遍历，融合与重排负责把候选变成高质量上下文。
在这个基础上，未来无论PG19的SQL/PGQ逐渐成熟，还是图数据库和检索模型继续演进，都可以替换计算层，而不需要动摇主数据和治理体系。
精工数字化工厂在服务制造型企业数智化转型过程中，始终关注AI基础设施与业务场景的深度耦合。从智能工厂规划到知识底座搭建，从设备预测性维护到工艺文档智能检索，持续为制造业提供可落地、可演进的技术方案。
精工智能数字化工厂，制造业Online，持续在场，赋能企业高质量发展。
延伸阅读