「玄枢诞生记」RAG能搜文档,但搜不出＂12mm碳钢用3000W光纤会切不透＂

RAG 能搜文档，但搜不出“12mm 碳钢用 3000W 光纤会切不透”

树懒老K ｜ 玄枢诞生记 · 第 4 篇 RAG 让 AI 有了记忆，本体论让 AI 有了推理

如果你在做企业 AI 项目，你的架构里大概率有一个 RAG 模块。

把文档切片、做向量化、扔进向量库、用户提问时做语义检索、把检索到的片段拼进 LLM 的上下文窗口。这套流程在 2024 年已经被写进了无数技术博客的“企业 AI 最佳实践”里。

我也做过 RAG。去年给一个客户做设备手册问答系统，用了最标准的 RAG 架构。客户很满意——“终于能用手册里的知识回答问题了”。

但今年做玄枢的时候，我发现 RAG 有一个根本性的盲区。这个盲区不是“检索不准”或者“片段太碎”这种工程问题——这种问题可以靠更好的切片策略和 reranker 模型来解决。我说的是一个架构层面的盲区，一个 RAG 无论怎么优化都无法填补的洞。

RAG 能找到“历史上有人做过类似的事”，但它找不到“这件事在物理上能不能做”。

这两个问题的区别，决定了你的 AI 是在“回忆”还是在“推理”。

一个真实的场景：12mm 碳钢报价

假设一个销售在系统里输入：“帮我给客户报个价，切 12mm 碳钢，200 件，30 天交货。”

RAG 的做法：把“12mm 碳钢 报价”做向量化，去向量库里搜最相似的历史文档片段。可能搜到一份去年给某客户的报价单，上面写着“8kW 光纤激光器，报价 222 万”。然后 LLM 参考这份历史报价，生成一份新报价。

这个流程有什么问题？看起来没什么问题。它找到了一份真实的、经过人工确认的历史报价，参考它来生成新报价，很合理。

本体推理的做法：AI 先在本体图谱里激活“碳钢 12mm”这个实体节点，然后沿 CONSTRAINS 关系找到 PHY-001 约束规则——一条 BLOCKER 级的物理约束：碳钢切割厚度（mm）× 3.5 ≤ 激光功率（kW）。12 × 3.5 = 42kW，这意味着 12mm 碳钢至少需要 42kW 的功率……等等，这个系数对实际场景偏高。让我用真实数据：玄枢系统里 PHY-001 规定 12mm 碳钢的最低功率是 8kW（系数约 0.67，考虑了切割速度和辅助气体）。

好，约束校验结果：最低 8kW。如果销售指定的设备是 3kW 光纤激光器呢？

RAG 的回答：搜到一份 3kW 设备的报价，生成一份方案，看起来完整。但这份方案在物理上是错的——3kW 切不透 12mm 碳钢。RAG 不知道这件事，因为“切不透”这个物理事实不在任何一份历史文档里。历史文档里只有“3kW 设备报价 XX 万”的记录。

本体推理的回答：PHY-001 约束校验不通过，3kW 配置被直接排除（BLOCKER 级约束，零容忍）。AI 告诉你：“12mm 碳钢不能用 3kW 设备。推荐 8kW 标准配置（报价约 222 万）或 12kW 旗舰配置（报价约 231 万，切割速度更快、边缘质量更好）。”

这个区别不是“准确度差了一点”。这是对和错的区别。RAG 会生成一份物理上不可行的方案，因为它只能搜到“历史上有人用 3kW 报过价”，搜不到“3kW 切不透 12mm 碳钢”。

RAG 的本质是什么？

我不是在黑 RAG。RAG 是一个非常好的技术方案，在信息检索和知识问答场景下表现出色。但要理解它的盲区，需要先理解它的本质。

RAG 的本质是向量相似度搜索。 它做的事情是：把用户的问题变成一个向量，在向量空间里找距离最近的历史文档向量。“距离最近”意味着“语义最相似”。

这意味着 RAG 的能力边界是：它能找到和当前问题最像的历史记录。它不能做的是：

第一，因果推理。 “如果 3kW 切不透 12mm 碳钢，那么 8kW 能切多厚？”这个问题需要理解功率和厚度之间的物理关系（因果），不是找到一份“长得像”的历史文档就能回答的。

第二，约束校验。 “这个配置方案可行吗？”这个问题需要检查方案里的每一个参数是否满足所有约束条件。约束是规则，不是文档。你搜不到一条规则——你只能在一个结构化的规则库里执行它。

第三，约束传播。 “如果客户把材料从碳钢换成铝合金，后面哪些参数要改？”这个问题需要沿着约束关系链一路推导：材料变了 → 辅助气体从氧气变成氮气 → 切割参数全套变化 → 功率需求变化 → 设备选型变化 → 成本变化 → 报价变化。这条链上有 6 个节点、5 条约束关系。RAG 搜不到一条“链”，它只能搜到一堆零散的“点”。

第四，反事实推理。 “如果功率从 8kW 降到 6kW，会发生什么？”这个问题在历史文档里大概率没有答案——因为现实中没有人会用 6kW 去切 12mm 碳钢（切不透）。RAG 搜不到“没有人做过的事”，但本体推理可以告诉你“会发生什么”：PHY-001 不通过、切割速度下降到不可经济值、边缘质量达不到标准。

那本体推理的本质是什么？

如果 RAG 的本质是“在历史中找相似”，本体推理的本质就是“在结构中做推导”。

它需要的不是“历史文档”，而是三种结构化的知识：

第一，实体结构——“世界由什么组成”。 一台激光切割机由激光器、切割头、床身、数控系统、辅机组成。激光器有功率、波长、冷却方式等属性。碳钢有厚度、密度、反射率等属性。这些不是文本，是节点和属性。

第二，关系结构——“什么和什么相关”。 激光器 PART_OF 整机。PHY-001 APPLIES_TO 碳钢-功率组合。冷水机 DEPENDS_ON 激光器热负载。这些关系不是文档里的文字，是图谱里的边。

第三，约束结构——“什么不能做”。 PHY-001：碳钢厚度 × 系数 ≤ 功率（BLOCKER）。GAS-001：304 不锈钢禁止使用 O2 辅助气体（BLOCKER）。SAF-001：12kW 以上必须配安全联锁（WARNING）。这些约束不是“建议”，是可执行的规则。

当这三种结构组合在一起时，AI 就能做 RAG 做不到的事：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
用户说：12mm 碳钢，3kW 设备↓激活实体：碳钢-12mm, 设备-3kW↓沿 CONSTRAINS 关系找到 PHY-001↓执行 CEL 表达式：thickness × 0.67 ≤ power → 12 × 0.67 = 8.04 > 3↓约束校验失败（BLOCKER）↓排除 3kW 配置，搜索满足约束的替代方案↓沿 APPLIES_TO 找到 8kW 和 12kW 设备均满足↓沿 COST_OF 计算两套方案的成本↓输出 A/B 两套可行方案

这条推理链穿过了 5 个实体节点、4 种关系类型、1 条约束规则、2 个成本映射。RAG 做不到这件事，因为这条链不存在于任何一份文档里——它只存在于本体图谱的结构中。

CEL：约束表达式语言，101 条规则的“执法者”

前面提到的 PHY-001、GAS-001 这些约束，在玄枢里是用一种叫 CEL（Constraint Expression Language，约束表达式语言）的格式编码的。

CEL 的设计原则是：人可读、机器可执行、结果可审计。

一条 CEL 规则长这样（以 PHY-001 为例）：

1
2
3
4
5
6
7
8
9
10
11
12
13
rule_id: PHY-001name: 功率-厚度约束severity: BLOCKERcategory: Physicalcel_expression:  operator: compare  left: { entity: "material", attribute: "thickness_mm" }  op: "<="  right:    operator: chain.derive    source: { entity: "laser", attribute: "power_kW" }    transform: "value / 0.67"message: "材料厚度超出激光器功率能力"

这条规则说的是：材料厚度（mm）≤ 激光功率（kW）÷ 0.67。如果不满足，直接阻断（BLOCKER），不允许生成方案。

玄枢目前有 101 条 CEL 规则，覆盖 7 种操作符：compare（数值比较）、and（多条件与）、case（条件分支）、cross_ref（跨实体校验）、in_set（集合成员）、chain（链式推导）、range（区间校验）。全部 101 条规则跑完需要 0.15 毫秒。

0.15 毫秒。这意味着 AI 在生成方案之前，可以先把所有约束跑一遍，把所有不可行的配置方案排除掉，然后在可行空间里做优化。这个过程对用户来说是透明的——他看到的是“AI 推荐了 A 和 B 两套方案”，看不到的是“AI 已经在后台排除了 15 套不可行方案”。

CEL 和 LLM 是协同关系，不是替代关系。 CEL 做硬约束校验（确定性的、可审计的、零误差的），LLM 做软约束建议和自然语言解释（概率性的、灵活的、有上下文理解能力的）。比如 CEL 告诉你“3kW 不可行”，LLM 告诉你“为什么不可行——因为 3kW 光纤激光器的功率密度不足以穿透 12mm 碳钢的截面，切割过程中会出现底部挂渣、切缝不贯穿等问题”。

一个本体 + 三个认知层：不是四个并列的知识库

第 2 篇提到过，专家评审让我把“四体并列”（产品本体、约束本体、成本本体、经验本体）改成了“一个本体 + 三个认知层”。这个改动在本文的场景里体现得最清楚。

一个本体：产品本体（Product Ontology）。描述“一台激光切割机是什么”——36 个核心物理实体、PART_OF 关系树、DEPENDS_ON 依赖关系。这是所有认知的基础。

认知层一：约束规则层（Constraint Rule Layer）。描述“什么不能做”——101 条 CEL 规则，4 个严重级别（BLOCKER/ERROR/WARNING/INFO），4 个约束类别（Physical/Process/Compatibility/Regulatory）。这一层的节点不是物理实体，而是“法则”——它们依附于产品本体存在，但有独立的逻辑生命。

认知层二：成本映射层（Cost Mapping Layer）。描述“多少钱”——从顶层报价模板到末级成本项的 5 级树结构。每一级成本项都通过 COST_OF 关系关联到对应的产品实体。这意味着：如果你换了一个零部件（比如把 IPG 激光器换成锐科激光器），成本会自动沿着 COST_OF 关系链重新计算。

认知层三：经验 CBR 层（Experience Case-Based Reasoning Layer）。描述“踩过什么坑”——历史案例包含配置快照、决策理由、教训总结、客户反馈。CBR 的四阶段检索（结构化过滤 → BM25 → 向量召回 → 图约束 + 时效衰减）确保 AI 在做决策时不只是看规则，还看“前人在这条路上摔过什么跤”。

这三个认知层不是三个独立的知识库。它们围绕同一个产品本体展开，通过跨层关系（APPLIES_TO、COST_OF、RELATED_TO）连成一张完整的认知网络。

RAG 做不到这一点，因为 RAG 的知识是“扁平”的——所有文档被切片成向量，混在同一个向量空间里。 它没有“层”的概念，不知道“这条知识是约束规则还是经验案例”，更不知道“这条约束适用于哪个产品实体”。

RAG 和本体推理的正确关系

我不是说 RAG 没用。在玄枢的架构里，RAG（Qdrant 向量搜索）是三层数据流的第一层。它的职责是语义模糊匹配——用户说“不锈钢”，向量搜索能匹配到“SUS304”；用户说“白钢”（304 的民间别名），也能匹配到。这种语义模糊匹配能力是本体推理不具备的——本体推理需要精确的实体 ID。

所以正确的架构是：

1
2
3
4
5
6
7
用户自然语言提问    ↓第一层：RAG（Qdrant）→ 语义模糊匹配 → "这个用户大概在说什么"    ↓第二层：本体推理（Neo4j）→ 结构化推理 → "这些实体之间有什么关系和约束"    ↓第三层：Agent 推理引擎 → 综合决策 → "知道了这些，该怎么做"

RAG 是入口（把自然语言翻译成实体线索），本体是内核（做推理和校验），Agent 是出口（生成方案和建议）。三者各司其职。

但如果你的架构里只有 RAG 没有本体，就相当于一个人只会“回忆”不会“思考”。 他能告诉你“上次张三切 12mm 碳钢用了 8kW”，但他不能告诉你“你这次用 3kW 为什么不行”——因为“为什么不行”需要理解物理规律，不是“回忆”能解决的问题。

一个反直觉的结论

很多人觉得 LLM + RAG 就是“AI 原生”的终极方案。但我做了玄枢之后的感受恰恰相反：LLM + RAG 是 AI 应用的起点，不是终点。

RAG 解决了“AI 能不能访问企业知识”的问题。但它没有解决“AI 能不能推理企业知识”的问题。

“搜到”和“理解”是两个完全不同的能力层级。搜到了 100 份报价单，不代表 AI 理解了报价背后的物理约束、工艺逻辑和成本结构。搜到了“上次张三用了 8kW”，不代表 AI 知道“为什么不能用 3kW”。

本体推理解决的就是“理解”这一层。它让 AI 不只是“看到”知识，而是“理解”知识之间的因果关系、约束关系和传播链路。

金句：RAG 让 AI 有了记忆，本体论让 AI 有了推理。记忆让你不重复犯错，推理让你不犯新错。对企业 AI 来说，后者比前者重要十倍。

老 K 碎碎念

写这篇文章的时候我犹豫了很久——怕被误解成“RAG 不行”。RAG 当然行，它在正确的场景下是神器。但问题是太多人把 RAG 当成了 AI 应用的全部，而不是起点。去年我自己也犯过这个错：给客户做的设备手册问答系统，客户问“我的设备最近老出故障怎么办”，RAG 搜到一份维修手册回答说“请检查冷却系统”。客户说“我的设备没有冷却系统，是风冷的”。RAG 不知道这件事——它搜到的那份手册是给水冷设备写的。如果有本体约束“设备 A 系列 → 冷却方式=风冷 → 不适用水冷维修方案”，这种错误就不会发生。这件事让我下定决心：玄枢的核心不是 RAG，是本体推理。RAG 只是入口。

加入「树懒老K · AI 研习社」

如果你也被 RAG 的‘差不多对’坑过——搜到一份历史报价，照着生成了一个物理上不可行的方案——你应该知道我在说什么。RAG 的天花板不是工程问题，是架构问题。这个认知差异，值得和同行好好聊聊。

如果你也在做 AI 落地，不管是本体建模、知识图谱、Agent 架构还是 RAG 方案，群里都有来自制造、供应链、质量、IT 领域的实战伙伴，大家一起拆真实案例、聊真问题。

扫码加入「树懒老K · AI 研习社」，带上你的真实问题来。

树懒老K · 慢一点，深一度。

下一篇：「‘帮我给中集报个价’——这句话穿越了 1076 个本体节点」 —— 用一次真实的一句话报价，完整拆解三层数据流：281 个向量 → 1076 个节点 → 1671 条关系 → 一份 185 万的报价单。

本文数据来源：玄枢 Ontaxis 12mm 碳钢推理链实测（PHY-001 约束校验）、CEL 规则库 101 条规则执行日志（0.15ms 全量校验）、Qdrant 281 向量检索日志、三层数据流架构设计文档。所有约束规则和推理结果来自生产环境实测。