基础RAG都没跑稳，IT却开始讨论Knowledge Graph，暴露的不是技术野心，而是决策顺序失控。文档入口是否统一、权限能否继承、Metadata是否完整、Chunk是否合理、答案能否追溯，这些问题还没解决，就急着定义实体、关系和Ontology，本质上是在一楼尚未封顶时设计空中花园。

Knowledge Graph当然有价值，尤其适合药物—靶点—通路—疾病—临床试验等多跳查询，以及证据追踪、影响分析和规则推理。但它不是比RAG更高级的装饰品，而是数据工程与知识治理工程。实体消歧、统一ID、关系抽取、来源标注、版本控制和持续更新，缺少任何一环，最后都可能只剩一张复杂却没人敢用于决策的图。

更值得警惕的是，部分IT团队选择Knowledge Graph，并非业务提出明确需求，而是普通RAG做不出满意的Demo，于是用新名词掩盖旧问题。检索失败可能源于数据质量、权限、切分策略和评估集缺失，但团队不回头修地基，反而继续增加GraphRAG、Agent、Reranker和Hybrid Search。组件越来越多，Latency、成本与维护负担同步上升，业务价值却没有被证明。

正确顺序很朴素：先选1个高频、高价值、边界清晰的场景，用50到100个真实问题建立评估集；再用基础RAG验证Recall、答案准确率、引用可靠性、P95 Latency和用户采纳率。只有当问题确实要求跨数据源实体关联、多跳路径或复杂证据链，且现有检索无法解决时，才逐步图谱化关键关系，而不是一开始就建设企业级知识宇宙。

所以，RAG没搞定就跑去做Knowledge Graph，真正不靠谱的不是技术，而是IT缺少产品思维、评估体系和投资纪律。小公司资源有限，更应追问三个问题：谁会每天使用、哪类决策因此改善、12个月内能否证明ROI。回答不了，就不该继续堆架构。技术路线是否成熟，不在于名词多新，而在于每增加一层复杂度，都能证明它解决了一个真实且昂贵的问题。