pmml

嗨伙計！ 從今年年初開始，就有了重新設計Drools PMML模塊的計劃。

在這篇文章中，我將描述我們將如何處理它，目前的狀態，未來發展的想法等，等等……敬請期待！

背景

PMML是一個標準，旨在“ 為分析應用提供一種描述和交換由數據挖掘和機器學習算法產生的預測模型的方法。 ” PMML標準定義了一系列受管理的模型，我們將其稱為“模型”。

換句話說，這可能不是那么明顯的結果是，PMML可以被認為是不同預測模型的協調器 ，每個預測模型都有不同的要求。 Drools有其自己的PMML實現。 它的原始設計是基于100％流口水引擎的，但是從長遠來看，這對所有模型都不令人滿意，因此決定采用不同的方法來實現新版本。 現在，這里的故事開始了……

要求

簡而言之，PMML實現應允許：

加載PMML文件（xml格式）

提交輸入數據

返回預測值

聽起來很簡單，不是嗎？

方法

擬議的體系結構旨在遵循“清潔體系結構”原則以模塊化方式滿足要求。

為了實現這一點，定義了清晰的邊界和可見性的組件。 總體思路是，存在與核心功能嚴格相關的特定任務，而其他“外部”功能則應保持不可知。 任何想深入研究此問題的人都可以閱讀RC Martin撰寫的“ Clean Architecture”一書，但從本質上講，將good-ol的設計原則應用于整個體系結構只是一個問題。 明確定義此目標后，實現該目標所需的步驟為：

識別核心邏輯和實施細節（特定于模型）

在“獨立”模塊中實現核心邏輯

為特定于模型的模塊編寫代碼

我們選擇實現插件模式以將核心邏輯綁定到特定于模型的實現，主要有兩個原因：

增量開發和整體代碼管理：核心模塊本身不依賴于任何特定于模型的實現，因此可以增量地提供/更新/替換后者，而不會對核心產生任何影響

可以用自定義的實現替換提供的實現

我們還預見到了可能會根據原始PMML結構在運行時選擇實現的可能性（例如，根據給定PMML的大小使用其他實現可能是有意義的）

（我作弊：那是三個）

這是原始PMML模型的Kie表示形式的定義。

對于每個實際模型，都有特定的實現，并且可以是任何類型的對象（java映射，drools規則等）。

我們可以避免嗎？ 也許。 我們可以使用由規范的xsd直接生成的模型。 但這是為了描述所有預測模型而設計的，盡管它們中的任何一個都可能以不同的方式和不同的約定使用它。 因此，此內部視圖將準確表示每個特定模型所需的內容。

組件

我們確定了以下主要功能組件：

編譯器

組裝工

執行者

編譯器

該組件讀取原始PMML文件并將其翻譯為我們的內部格式。

它的核心方面只是將xml數據解組到Java對象中。 然后，它使用Java SPI檢索特定于給定PMML模型的模型編譯器（如果找不到模型編譯器，則將PMML忽略）。

最后，檢索到的模型編譯器會將原始PMML模型“轉換”為我們特定于模型的表示形式（ KiePMMLModels ）。

該組件的核心部分不直接依賴于任何特定的Model Compiler實現 ，甚至不依賴于任何Drools / Kie –因此，它基本上是一個輕量級/獨立的庫。 如果該組件的執行不是很費時，則可以在運行時 （即，在客戶項目的執行期間）或在kjar的編譯期間（例如，對于流口水實現的模型）調用該組件。

組裝工

由編譯器內KIE知識庫創建該組件存儲KiePMMLModels。 其他組件都不應該對此組件有任何依賴性/知識。

反過來，它必須對實際沒有任何依賴性/知識/引用 模型編譯器實現。

該組件負責PMML模型的實際執行。 它接收PMML輸入數據，檢索特定于輸入數據的KiePMMLModel并計算輸出。

對于每個模型，都有一個特定的“執行器”，以根據模型類型允許不同類型的執行實現（drool，外部庫等）。 它的核心端僅接收輸入數據并檢索特定于給定PMML模型的模型執行器（如果找不到，則將忽略PMML）。 最后，檢索到的模型執行者將基于輸入數據評估預測。 該組件的核心部分不直接依賴于任何特定的Model Executor實現，但是當然嚴格依賴于Drool運行時。

整體架構

模型實施

基于Drools的模型

一些模型將委托給drools引擎，以在重載下實現最佳性能。 以下是有關此類實現的一般方案的一些詳細信息。

編譯器在生成kjar時（或在運行時熱加載PMML文件時）被調用

編譯器讀取PMML文件并將其轉換為“ descr”對象（請參見BaseDescr ， DescrFactory ， DescrBuilderTest ）

不管如何調用模型編譯 器，都必須在調用drools編譯器后立即對其進行調用，以使基于descr對象生成Java類

匯編器將生成的類放在kie base中

執行程序加載生成的“ drools模型”，并使用輸入參數調用它

DRL詳細信息

• 對于DataDictionary中的每個字段，必須定義一個特定的DataType
• 對于樹的每個分支/葉子，必須生成全路徑規則（即具有到達路徑的規則-例如，“晴天”，“晴天溫度”，“晴天溫度濕度”）
• 創建了一個“狀態持有者”對象，該對象包含已觸發規則的值–更改該值將觸發與之匹配的子分支/葉規則（例如，規則“ sunny”將觸發“ sunny_temperature”，而后者又將觸發） “ sunny_temperature_humidity”）
• 此類“狀態持有人” 可能包含評估的信息/部分結果，最終將在需要結果組合的地方使用
• 價值缺失策略可以在身份持有者內部實施， 也可以作為爆炸規則

測試中

對于每個模型，都會有一組標準的單元測試，以主要驗證各個代碼單元。 除此之外，在特定于模型的模塊內（是的，它是繞口令），將有一個集成測試子模塊。 后者將驗證不同或多或少復雜的PMML文件的整體正確執行，以盡可能模擬實際場景中可能發生的情況。

回歸

回歸模型是第一個實現的模型。 由于其固有的簡單性，我們選擇為其提供純基于Java的實現。 目前，它仍處于PR之下，并且正在添加新的完整測試。

樹

在評估了所有優點/缺點之后，我們認為該模型可以作為采用基于流口水的方法來實施的很好的候選者。 作為一個易于遵循的簡單模型，我們選擇將其用作流口水方法的第一個測試。

待辦事項

這是尚未實現的，與特定模型沒有嚴格關聯的缺失功能的列表。 在開發過程中將對其進行更新：

• 設置基準框架項目（請參閱Drools基準 ）
• 管理擴展標簽（請參閱xsdElement_Extension ）
• 管理SimpleSetPredicate標記（請參閱SimpleSetPredicate ）
• 在細分中實現VariableWeight （動態替代靜態“權重”值）

不用說，任何評論（尤其是好的評論）和建議將不勝感激。

接下來的幾天再回來看看下一步！

再見！

翻譯自: https://www.javacodegeeks.com/2020/02/pmml-revisited.html

pmml

總結

以上是生活随笔為你收集整理的pmml_再访PMML的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。