企业级大模型知识库的准确度瓶颈，正在从检索环节暴露出来。由分块切分加向量相似度检索构成的 Naive RAG，在微服务拓扑资产、技术文档、金融合规审计这类场景会同时踩三个坑：一是信息孤岛，微服务调用关系分散在多份文档里，向量检索可能只命中“订单超时关闭”的片段，丢掉了下游“库存解锁”“消息重试”的上下文；二是多跳推理断裂，链路 A 到 B 在一份文档、B 到 C 在另一份文档，相似度检索识别不出 A 与 C 的关联，回答容易断章取义甚至产生幻觉；三是全局聚合失灵，面对“这套系统一共有多少个降级兜底策略”这类宏观问题，Top-K 根本覆盖不到全库的细碎节点。解决方向是引入图结构固化实体语义关系、用层次化社区发现沉淀全局摘要，再与向量检索互补融合。

落地架构分离线与在线两段。离线管道把文档分块后走两路：一路用大模型做实体与关系抽取、实体对齐消歧后写入 Neo4j 知识图谱，另一路做文本嵌入写入 Milvus 向量库；图谱侧再跑 Leiden 社区发现，由大模型分层生成社区报告并向量化回写。在线链路先做意图分析与实体识别，随后并行发起两路召回——向量 Top-K，与图谱的 2-Hop 子图加社区摘要——再用 RRF 融合与重排模型装配上下文，交给大模型生成结构化答案。选型对比上，Naive RAG 只依赖单一向量相似度，进阶方案补上 BM25 全文检索与重排，GraphRAG 则把图拓扑多跳与社区摘要一并纳入召回。

工程实现基于 Java 17、Spring Boot 3.2.3、Neo4j 5.x、Milvus 2.3+ 与 LangChain4j 0.29.1。图谱服务用 Cypher 做两件事：按识别出的实体名匹配 1 到 2 跳路径，返回三元组补足关系上下文；沿 BELONGS_TO 关系取出实体所属社区的标题与摘要。检索服务用 CompletableFuture 把向量召回与图谱召回并行执行，再合成“知识图谱结构化链路与全局摘要 + 相似文本碎片”两段上下文，并在系统提示里明确要求上下文不足时实事求是作答、严禁臆造。

三个坑必须提前规避。其一，实体消歧缺失会让图谱爆炸：同一个服务在不同文档里写作 OrderService、订单服务、trade-order-srv，直接抽取会分裂成三个孤立节点，需要在离线管道用同义词表映射加小模型向量聚类，把它们绑定到同一个图节点上。其二，社区发现的离线时延可观：Leiden 聚类极其耗时，每次上传文档都全量重算会让吞吐归零，可行做法是冷热分区，主干图谱按周做全量聚类，新增分块走局部子图合并、由增量三元组触发小范围重聚类。其三，多跳查询会引发耗时雪崩：在 MySQL、SpringCloud 这类超级节点上做无方向的 1 到 3 跳发散，会瞬间拉出数万条边并拖垮内存，必须在 Cypher 里设 LIMIT 与节点度阈值过滤，度数超过 200 的通用实体只保留与当前上下文共现的边，并在应用侧加降级超时。

效果验证在 1200 份技术架构与故障复盘文档、100 组包含跨系统链路分析与宏观全景查询的评测集上完成：检索命中率 Hit@5 从 62.4% 提升到 91.8%，全局性回答完整性的 LLM 评分从 2.8 升到 4.6，多跳推理准确度从 38.0% 升到 84.5%，代价是 P99 端到端延迟从 420 毫秒升到 890 毫秒。它的定位不是推翻向量检索，而是用知识图谱的确定性关联补齐向量模型的概率模糊性——“图谱定骨架、向量充血肉、大模型做表达”，正在成为新一代 RAG 架构的工程做法，涉及复杂多跳推理与全景总结的业务场景，值得尽早启动技术预研与落地。