大模型输出token的速度太低且为统计输出，所以目前大模型主要应用在toP（人）的相关领域；但其智能方面的优势又是如此的强大，自然就需要尝试如何将其应用到更加广泛的toM（物理系统、生产系统）领域中来。

破题思路

笔者比较熟悉AI的符号主义分支，所以自然的就想到：由大模型完成业务知识的理解与转换，然后以通用的知识应用系统-专家系统来驱动实际的业务处理。

我们查看一个虚拟的业务处理过程：

某远程数据采集站点失联检查
启动条件：通过检查数据采集日志，发现某站点所有设备失连
1、等待半个小时
2、如果有设备未失连，则结束
3、检查站点的通信状态
4、如果该站点通信正常，推断该站点采集系统故障，申请采集设备检修并结束
5、如果该站点通信不正常，推断该站点通信故障，申请通信设备检修

通过观察，我们能看出：

1、这样一个业务处理过程首先可以映射为用petri网表达的流程化处理结构

2、petri网的每个库所，可以用一个产生式进行描述

3、产生式的前件与后件，都可以用谓词逻辑进行描述

需要说明的是：很多企业、很多领域，起始阶段未必有足够精细的业务知识满足量化计算的要求，所以还应当引入模糊推理来支持人的经验判断，以降低应用门槛

这些工具都具有完备且成熟的理论支撑，所以只要我们的实现能做到形式良好，即实现代码可靠、稳定，那么整个系统就是可靠的、稳定的、完备的。

这样一来，我们可以构造一个通用的业务驱动系统（以下简称GESLM），然后通过两步：

1、 用大模型将业务人员书写或口述的业务知识（目前主要考虑SOP型业务处理逻辑）转换为业务操作描述模型

2、程序员对大模型解析出来的部分谓词【和业务现场密切相关的专用谓词】编程实现

就完成了一个特定业务场景的业务自动化处理。

甚至，由于单一谓词的复杂度较低，在有了足够多样板的情况下，大模型的code分支还能直接生成所需谓词的实现代码:)

问题与难点

GESLM由于是通用的，所以最佳的实现方案是从头构建。但这显然相当于抛弃了现有的海量业务系统资产。因此，以第三方库或微服务的方式来逐步推进较为有利。

但此种路线由于是将之嵌入到现有成熟系统中，会有如下的问题与难点：

1、每个业务功能，都需要进行大量的适配工作

这种适配工作主要包括：

a 数据准备，要从原有系统中将业务场景所需要的数据提取出来馈送到GESLM中

b 名字映射，传统编程模式由于有多道开发工序，会逐步完成人所理解的具有业务意义的概念到业务代码中的变量名的逐步转换。但GESLM由于利用大模型省去了中间的开发工序，所以很难自动完成业务名称到既有代码变量名的转换，目前只能由程序员进行适配

c 信息补足，业务知识是业务人员书写或口述，其会下意识的忽略掉很多在他看起来是天经地义的背景知识。但缺了这些背景知识，GESLM根本无法正常执行。只能由知识工程师一点点的通过和业务人员的讨论进行识别并补足

d 例外处置，SOP只是一个正常情况下的操作步骤。当出现问题时，我们人是可以随机应变、具体问题具体分析的进行解决的。但机器不行。所以必须考虑到各种意外情况，以确保在出现意外时，能得到正确的处置

2、规则变换的手工核查

业务规则是由面向人的自然语言书写，但程序执行的必须是形式化的描述性语言，两种无法直接映射。所以在很多地方都必须进行大幅度的转换：

a 规则转换

如示例中大家一目了然的规则1【等待半个小时】，在程序处理时，要分解为如下的动作序列：

• 启动一个定时器
• 等待一个定时事件【为防止同时有多个定时器同时工作，所以还必须专名，以便于取消等操作时不会误操作】
• 定时器半小时后超时，触发一个超时事件
• 等待中的库所恢复执行

将这些动作进行合并后转换成计算机来执行的形式规则：

• 一个启动定时器的规则
• 一个等待超时事件的规则
• 一个超时触发特定的超时事件的隐含规则

这种转换需要补足的知识过多，而大模型的不精确性就使得我们必须对本条这么简单的规则的转换结果都要进行手工的核查。

b 量词

我们都知道，谓词逻辑中有两个量词：全称量词、存在量词。对我们人来说，这两个量词很容易理解，但对计算机来说，一个量词其实是三个部件的合成：

• 关系谓词，提取量词对应的所有目标对象
• 判断谓词，对提取出的目标对象，在for循环中逐一进行判断
• 逻辑连接，全称量词就是判断谓词的逻辑与，存在量词就是判断谓词的逻辑或

可想而知，需要补足这么多的信息也必须进行手工的核查甚至是纠正与调整才能确保转换后的模型能正常工作。

c 谓词调整

比如上面示例中的规则3【检查站点的通信状态】，在刚应用时，可能就是人去检查，然后手工送入检查结果。之后，随着应用的深入，就可能改为程序自动检测了。

人工检查，由于需要等待人的处理结果，所以其实是要等待一个外部事件。自动检测，则是调用一个同步函数来执行检测并读取到检测结果。

但是，这两种情况的不同，由于是在实现层次进行区分的，大模型根本无法感知到，所以只能由程序员或未来的知识工程师进行手动调整。

以上只是笔者目前所遇到的较为重要的问题与难点，相信随着需要面对的业务场景的增多，问题与难点还会不断涌现。

解决方略

在我看来，这些问题与难点分为三类：

1、准备工作量大

这类问题是由于我们所选择的嵌入式发展路线所导致。即必须解决从现有IT系统到GESLM的跨越问题。

这类问题有一个特点，就是初始工作量较大，但随着嵌入的业务功能、对接的既有系统越来越多，工作量与成本就会越来越少，最终趋于忽略不计。

2、积累不足

这是因为积累的样板太少，所以目前只能以prompt工程的方式让大模型来理解业务知识。如果积累足够多的样板，使用大模型进行微调，相应的问题自然就可以得以化解。

3、背景知识的欠缺

这一部分最为麻烦。因为这些需要补足的知识并不存在于业务方所提供的业务知识中，而是存在于业务人员的从业经历与经验教训中，属于隐藏知识，根本无法直接程序化自动提取。

所以，即便是拿出再多的样板来训练大模型，都无法解决这类问题。

这类问题的解决只能通过在更高层次上积累企业运行数据与知识、行业数据与知识来构建企业与行业大模型来提供背景知识的补足。

至于谓词调整这种因工程实施的阶段性而诱发的问题，归于工程实施来解决就好了。

结语

由于目前样板积累的太少，因此我在【将业务知识转换为业务模型】时采用的是prompt工程的方案来实现的。所以适配与核验的工作量会比较大。

相信随着专用大模型【起码需要六种大模型：业务知识转换大模型、语法语义校对大模型、自动化适配大模型、验证与测试大模型、UI大模型、bug分析大模型】的成熟，相应的准备性与维护性工作量会大幅度的下降。

这样一来，业务系统开发的工序与工种将大幅度缩减，很有可能，不，我坚信：大多数的业务系统在不远的将来只需要一个知识工程师在行业大模型的支持下就可以完成定制性的开发了！最多其再稍微兼职一下程序员就够了。

相应的开发时间与开发成本也自然会大幅度下降；同时，还更满足用户的需求、充分支持其独特的业务逻辑、增强其竞争力；更稳定、更可靠。

作为程序员，我将消灭我自己。我也不知道该配一个笑脸还是哭脸为好。

附

1、流程的描述性定义

jxTMS设计思想之流程引擎与任务分发

2、web界面的描述性定义

jxTMS设计思想之web界面

3、运用模糊数学引入人的经验来降低业务知识不精细时的应用门槛

模糊控制-模糊是什么鬼