通用大模型能写代码、能订机票,但一进企业就露怯——同样的故障报警,激光设备厂和新能源车企的根因完全不同,模型却给出一模一样的排查清单。滴普科技创始人赵杰辉近期撰文指出,这不是模型"不够强",而是企业级任务和公开领域任务根本就是两种结构。
企业里的真实推理往往是5跳、10跳、20跳的长链路。一次故障诊断从现象到根因可能要跨6个数据源,更麻烦的是这些链路不是固定故障树,而是"语境动态生成"的。某激光设备制造商和某新能源车企焊装产线出现完全相同的症状——"伺服过载报警+X轴定位漂移+节拍下降8%",前者根因是隔壁等离子焊机的谐波干扰,后者则是MES里72小时前的车型切换参数同步问题。这两条路径不在任何SOP手册里,区分它们需要的是本体层面的程序性理解,而非更多文档。
![]()
更深层的冲突来自规则本身。企业有成百上千份SOP、操作规程、合规手册,各管一摊,没人保证它们完全一致。"反洗钱合规"和"客户体验提速"两套规则在同一笔交易上冲突时,哪个优先?答案不在某份文档里,而取决于企业本体中两类规则的元层级如何定义。这种仲裁能力,通用模型无从习得。
工程上还有硬约束。一次企业级长任务推理动态展开的本体子图——相关实体、关联边、语义、SOP元层级关系——经常达到几十万token量级。即使1M context的模型,全部塞进prompt也不经济、不可靠。模型必须靠"权重里内化的结构"来导航,知道该往哪条边走、哪条边可以先剪掉。
更微妙的是"该停在哪"。停早了根因没找到,停晚了陷入无限回溯、token暴涨、用户体验崩溃。这种判断依赖模型对本体边类型的内禀理解:某条边表示"这是根因节点"(可终止),某条边表示"这是中间假设"(需继续)。边的程序语义无法靠名字塞进prompt来传递。
当Agentic Model进入制造、零售、医疗、金融等深度业务岗位,失效条件逐一暴露。业务对象不在训练分布内——"报警码""参数组""工位编号"背后的企业语义缺失,Plan能力退化为基于字段名的猜测。业务目标是派生结果——区域总监问"华东大区销售额完成率73%,差270万,明天讨论什么行动",模型答"加大促销、优化产品组合",却不懂"销售额"是销量、均价、渠道结构共同作用的结果,正确规划应先反向追溯到可执行杠杆。业务动作受多目标多规则约束——深度促销拉高销量却压低毛利,通用模型缺乏在本体层级的优先级仲裁能力。
赵杰辉将企业级Plan能力定义为"在通用模型之上建立更高一层的业务语义能力",并介绍了滴普科技Deepexi企业大模型的工程实践。核心判断是:企业AI落地缺的不是更强的通用模型,而是能把企业本体、规则、规程、因果内化为模型权重的"语义底座"。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.