- 经验来源
- 本文记录我在一个生产级 RAG 问答系统里，对「是否引入知识图谱」做技术选型评估的完整推理，已剥离具体业务，保留可迁移的决策框架。
- 判断边界
- 「不做知识图谱」是针对这个系统当前瓶颈的结论，不是说知识图谱没价值。换一个以多跳关系推理为主的业务，结论可能完全相反。
为什么这个决策值得写下来
知识图谱把知识建成「实体 + 关系」的网络，强项是沿关系链做多跳推理与实体消歧——这是当前 AI 圈很热的方向。正因为热，团队评审、面试、客户对话里都很容易被问到一句："你们为什么不上知识图谱？"
很多人面对这个问题的默认回答是"来不及做"或者"排期里有"。但"来不及"是一个时间借口，不是技术判断。我想给的是另一种回答：一条有依据的取舍。把"不做"也当成一个需要论证的决策，而不是一句含糊的"以后再说"。
"不做某个热门技术"往往比"堆上它"更需要论证能力——你得说清它解决的问题在你这里是否真实存在。
三条不做的理由，按「价值 - 成本 - 风险」拆
我把判断拆成三个维度，每一条都对着一个具体事实，而不是感觉：
| 维度 | 判断 |
|---|---|
| 价值 | 检索瓶颈不在关系推理。主流量是政策/规则类问答（已由向量 RAG 重度覆盖：混合检索 + 重排 + HyDE + 父文档）和个人数据查询（很多意图直接跳过知识库）。知识图谱主打的多跳推理，不是当前召回失败的主因——为不痛的问题上重基建是过度工程。 |
| 重复建模 | 业务里真正"像图"的部分——结构化的网络、关系、层级——已经用关系型数据库 + 专用查询工具建好了，结果精确、可校验、可单测，比通用知识图谱更准更快。再叠一层 KG 是重复造轮子。 |
| 成本 | 实体抽取、关系抽取、图谱构建与增量更新、查询期子图召回是一整套新管线，还要长期维护 schema 漂移。对当前业务规模，ROI 不成立。 |
注意这三条的共性：都是用具体事实反驳"它会带来价值"这个假设，而不是泛泛地说"太复杂"。"太复杂"不能成为理由，因为复杂但值得的事多了去了；"我们的瓶颈不在它解决的那类问题上"才是理由。
瓶颈驱动，而不是热词驱动
这次决策最核心的方法论，是从"检索瓶颈到底在哪"反推，而不是从"业界都在做 GraphRAG"出发。我先把召回失败的案例分类：是关键词没匹配上？是语义检索排序不对？是文档本身没覆盖？还是真的需要跨多篇文档做关系链推理？
分类完发现，绝大多数失败属于前三类——这些是混合检索、重排、补文档能解决的，知识图谱帮不上忙。真正需要多跳关系推理的查询占比极低，而且其中"像图"的那部分早就被关系型数据库精确覆盖了。于是结论自然浮现：知识图谱解决的问题，在这个系统里并不痛。
不是「永不做」，而是「设好触发条件再做」
成熟的"不做"必须给出复活条件，否则就是拍脑袋拒绝，和拍脑袋接受没有本质区别。所以我给这个决策配了明确的重评触发信号：
把"不做"管理成一个有触发条件的决策，好处是它不会僵化。当业务真的长出多跳推理需求时，我们不需要重新吵一架，只要对照触发信号判断"到了没有"。决策被记录下来、附带复活条件，团队就不必每隔几个月重新讨论同一个问题。
技术选型要跟着真实瓶颈走，不跟着行业热词走
这件事我想抽象成一条可复用的纪律。面对任何一个热门技术，与其问"我们要不要做"，不如先问三个问题：
- 它解决的问题，在我这里是否真实存在、有多痛？（价值）
- 有没有更便宜的替代方案已经覆盖了这个问题？（重复建模）
- 它的引入和长期维护成本，对当前规模 ROI 成不成立？（成本）
这三问能挡掉大量"因为别人都在做所以我们也做"的冲动。技术债不只来自"做错的东西"，也来自"做了不需要的东西"——后者甚至更隐蔽，因为它通常顶着一个时髦的名字，让人不好意思反对。
总结：把「不做」也做成一个有依据的决策
这次评估留下三个我愿意反复讲的判断。第一，瓶颈驱动而非热词驱动：用"检索瓶颈到底在哪"反推出知识图谱解决的问题并不痛。第二，识别重复建模：看穿业务里"像图"的部分已被更便宜的方案覆盖，避免造重复的轮子。第三，把"不做"做成可复活的决策：给出明确的重评触发条件和分步落地顺序，展示"克制但不僵化"的技术规划纪律。
产品经理和工程师的价值，不只在于能把一个热门技术堆上去，更在于能在压力下说清楚"为什么暂时不"，并且让这个"不"是可被未来推翻的。
欢迎通过邮件和我交流：shaoyanyan91@163.com