大模型輸出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、運用模糊數學引入人的經驗來降低業務知識不精細時的應用門檻

模糊控制-模糊是什么鬼