网站服务器租用协议wordpress category 分页

当前位置： 首页 > news >正文

网站服务器租用协议,wordpress category 分页,深圳网站建设公司jsp,广州高端网站建设定制大模型输出token的速度太低且为统计输出#xff0c;所以目前大模型主要应用在toP#xff08;人#xff09;的相关领域#xff1b;但其智能方面的优势又是如此的强大#xff0c;自然就需要尝试如何将其应用到更加广泛的toM#xff08;物理系统、生产系统#xff09;领域中…大模型输出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、运用模糊数学引入人的经验来降低业务知识不精细时的应用门槛 模糊控制-模糊是什么鬼