工业 ERP 的 AI 价值，从“搜不到”追到“少买错”
工业物料语义检索的价值不在于让搜索更像电商，而在于减少重复录入、错误采购和库存浪费。
文章目录
在工业企业里，员工说“ERP 不好用”，常常不是因为系统完全不能工作，而是因为明明知道数据库里有一个物料，却怎么都搜不到。
找不到之后，员工可能重新录入一条数据。重复数据让系统更脏，下一次检索更难；到了采购环节，就可能变成买错、买重、单位搞错，最后形成长期库存甚至报废。
这个案例没有从“做一个更酷的 Agent”开始，而是花数月进入 ERP 及其上下游团队，先把“系统不好用”追到“采购预算为什么会被浪费”，再把数据清洗和语义检索放到最值得验证的环节。
落地场景：让工业物料真正找得到、选得对#
客户是一家需要管理大量机械设备、物料和资产的工业企业，从手套、螺丝钉、耳塞到卡车、机械臂，都要进入 ERP 数据库。大约 15 个团队与这套数据库交互，分别承担录入、采购、合同和仓储等职责。
同一物料可能有不同名称、描述、单位和录入习惯。老 ERP 主要依赖传统字段和关键词匹配，业务人员只能靠编码、准确名称或个人经验查找。数据规模变大后，这套方法开始失效。
项目要解决的不是“把搜索框改得更智能”，而是从源头减少重复录入，进一步减少错误采购、重复采购和长期库存浪费。
落地难点：问题在搜索框里，损失却发生在采购账上#
表面抱怨太宽，必须追到根因#
“ERP 不好用”无法直接交给工程师。FDE 需要观察员工怎么录入、怎么找物料、什么时候决定重新创建记录，再把一次搜索失败放回采购、仓储和库存处理的完整链路。
最终形成的因果链是：搜索困难 → 重复录入 → 数据污染 → 错误或重复采购 → 库存积压 → 长期报废 → 真实财务损失。
语义检索建立在脏数据之上#
如果历史数据本身包含重复、别名、不一致单位和不同描述方式，仅增加向量检索并不能自动解决问题。检索前的数据清洗和标准化，是语义理解能够产生稳定结果的前置条件。
15 个上下游团队意味着协调和集成风险#
不同部门的诉求不同，功能还可能改变原有分工。数据是否能取出，老 ERP 是否允许写回处理结果，业务是否允许触碰现有系统，用户是否相信检索结果，都比模型能不能生成答案更接近项目成败。
ROI 必须由业务确认#
搜索速度和模型准确率只是过程指标。项目最终要回答的是：重复数据有没有减少，错误采购有没有下降，采购浪费是否真的被避免。这个价值不能由 AI 团队自己宣布，而要有历史基线和业务人员确认。
如何落地：从数月诊断到小范围价值验证#
第一步，进入现场而不是拿着 AI 找问题#
项目围绕 ERP 及其上下游团队持续访谈，必要时直接坐在业务人员旁边观察真实工作。大约 15 个可处理功能点被梳理出来，最终优先选择数据质量和物料搜索两个问题。
第二步，把用例放回完整业务链条#
团队没有停在“做语义检索”，而是继续判断检索改进会不会减少重复录入、改变采购行为。只有明确业务损失如何发生，才知道应该从哪一个环节开始试点。
第三步，按多维度给用例排序#
FDE 与业务负责人共同确认每个功能解决什么问题、优先级是什么，再从数据可得性、能否写回系统、AI 可行性、技术难度、业务复杂度和用户接受度等维度评估。技术上能做，只是其中一项。
第四步，让 AI 负责理解，不替业务拍板#
数据清洗与标准化先处理历史记录，语义检索再理解“我要找的东西”可能对应哪些名称和描述。最终是不是采购、采购多少，仍然由业务人员决定。AI 介入的是发现和组织信息，而不是替代采购责任。
第五步，用小规模实验建立信心#
优先选择几周、甚至两周左右能够看到初步结果的场景。每一轮都检查重复数据、数据清洁程度、错误采购和采购浪费是否发生变化；如果问题定义或范围不对，就回到诊断阶段重新调整。
落地成果：把“大家知道有问题”变成可计算、可干预的问题#
案例最终落地了数据清洗和语义检索，目标是让业务人员更容易找到已经存在的物料，从源头减少重复录入，再减少错误采购和重复采购。
资料没有披露一个可以直接对外引用的统一节省金额或采购下降比例。因此，这个案例的已知成果应当写成两层：一是问题从“ERP 搜索不好用”被还原成了可计算的经营问题；二是解决方案开始围绕历史基线、小规模实验和业务确认建立持续验证机制。
| 变化前 | 落地后的变化 |
|---|---|
| 员工依赖编码、准确名称和个人经验找物料 | 用数据清洗和语义检索辅助匹配不同叫法 |
| 找不到后重新录入，数据越来越脏 | 从源头减少重复录入，维护数据质量 |
| 错误采购和库存浪费存在但不显性 | 建立历史基线，按业务结果持续衡量 |
| AI 团队单独决定做什么 | 业务部门共同确认优先级和价值 |
这个案例的价值不在于把工业 ERP 变成电商搜索，而在于把一次搜索失败和一笔真实采购浪费连接起来。只有这条业务链成立，语义检索才不再是孤立的 AI 功能。
这个案例给 FDE 的四个提醒#
第一，不要拿着现成的 Agent 或 RAG 去寻找场景，先进入业务现场找问题。
第二，业务人员说出的表面需求通常不是根因，要一直追问“然后呢”，直到连接到收入、成本、风险或库存结果。
第三，优先选择能快速证明价值的用例。早期结果既是技术验证，也是组织获得信心的方式。
第四，ROI 要在项目开始时定义，最终由客户业务人员确认，而不是由模型指标代替。
来源与边界#
- 原始资料：Datawhale《FDE案例100.pdf》，案例八“从数据清洗到语义检索：FDE解决工业采购中的隐性浪费”，案例访谈正文位于 PDF 第 79–87 页。
- 案例事实：约 15 个上下游团队与 ERP 交互；梳理出约 15 个功能点；问题集中在数据质量和物料搜索；方案落地数据清洗与语义检索；价值衡量关注重复数据、错误采购和采购浪费。
- 结果边界：资料没有披露统一的节省金额、采购下降比例或长期生产数据，不能把“减少错误采购”写成已被量化验证的结果。
- 产品化解读：关于“搜索只是手段、采购账才是结果”的因果链，以及 AI 与业务责任的边界，是基于案例事实的产品化分析。