譯者 | 張怡

審校 | 梁策 孫淑娟

1.如何成為一個IDO?

IDO(insight-driven organization)指洞察力驅動(以信息為導向)的組織。要成為一個IDO，首先需要數據以及操作和分析數據的工具;其次是具有適當經驗的數據分析師或數據科學家;最后還需要找到一種技術或者方法，從而在整個公司實施洞察力驅動的決策過程。

機器學習是能最大限度發揮數據優勢的技術。ML流程首先使用數據訓練預測模型，訓練成功之后來解決與數據相關的問題。其中，人工神經網絡是最有效的技術，它的設計源自我們目前對人類大腦工作方式的理解。考慮到人們目前擁有的巨大計算資源，它通過大量數據訓練可以產生令人難以置信的模型。

企業可以使用各種自助化軟件和腳本完成不同的任務，從而避免人為錯誤的情況。同樣，你也完全可以基于數據進行決策來避免當中的人為錯誤。

2.為什么企業在采用人工智能方面進展緩慢?

使用人工智能或機器學習來處理數據的企業僅是少數。美國人口普查局(US Census Bureau)表示，截至2020年，只有不到10%的美國企業采用了機器學習(主要是大公司)。

采用ML的障礙包括：

• 人工智能在取代人類之前還有大量工作尚未完成。首先是許多企業缺乏且請不起專業人員。數據科學家在這一領域備受推崇，但他們的雇傭成本也是最高的。
• 缺乏可用數據、數據安全性以及耗時的ML算法實現。
• 企業很難創造一個環境，從而讓數據及其優勢得到發揮。這種環境需要相關的工具、過程和策略。

3.機器學習的推廣只有自動ML(AutoML)工具是不夠的

自動ML平臺雖然有著很光明的未來，但其覆蓋面目前還相當有限，同時關于自動ML能否很快取代數據科學家的說法也有爭論。

如果想要在公司成功部署自助化機器學習，AutoML工具確實是至關重要的，但過程、方法和策略也必須重視。AutoML平臺只是工具，大多數ML專家認為這是不夠的。

4.分解機器學習過程

任何ML進程都從數據開始。人們普遍認為，數據準備是ML過程中最重要的環節，建模部分只是整個數據管道的一部分，同時通過AutoML工具得到簡化。完整的工作流仍需要大量的工作來轉換數據并將其提供給模型。數據準備和數據轉換可謂工作中最耗時、最令人不愉快的部分。

此外，用于訓練ML模型的業務數據也會定期更新。因此，它要求企業構建能夠掌握復雜的工具和流程的復雜ETL管道，因此確保ML流程的連續和實時性也是一項具有挑戰性的任務。

5.將ML與應用程序集成

假設現在我們已經構建了ML模型，然后需要將其部署。經典的部署方法將其視為應用層組件，如下圖所示：

它的輸入是數據，輸出是我們得到的預測。通過集成這些應用程序的API來使用ML模型的輸出。僅從開發者的角度來看，這一切似乎很容易，但在考慮流程時就不是那么回事了。在一個龐大的組織中，與業務應用程序的任何集成和維護都相當麻煩。即使公司精通技術，任何代碼更改請求都必須通過多級部門的特定審查和測試流程。這會對靈活性產生負面影響，并增加整個工作流的復雜性。

如果在測試各種概念和想法方面有足夠的靈活性，那么基于ML的決策就會容易得多，因此人們會更喜歡具有自助服務功能的產品。

6.自助機器學習/智能數據庫?

正如我們上面看到的，數據是ML進程的核心，現有的ML工具獲取數據并返回預測結果，而這些預測也是數據的形式。

現在問題來了：

• 為什么我們要把ML作為一個獨立的應用程序，并在ML模型、應用程序和數據庫之間實現復雜的集成呢?
• 為什么不讓ML成為數據庫的核心功能呢?
• 為什么不讓ML模型通過標準的數據庫語法(如SQL)可用呢?

讓我們分析上述問題及其面臨的挑戰，從而找到ML解決方案。

挑戰#1：復雜的數據集成和ETL管道

維護ML模型和數據庫之間的復雜數據集成和ETL管道，是ML流程面臨的最大挑戰之一。

SQL是極佳的數據操作工具，所以我們可以通過將ML模型引入數據層來解決這個問題。換句話說，ML模型將在數據庫中學習并返回預測。

挑戰#2：ML模型與應用程序的集成

通過API將ML模型與業務應用程序集成是面臨的另一個挑戰。

業務應用程序和BI工具與數據庫緊密耦合。因此，如果AutoML工具成為數據庫的一部分，我們就可以使用標準SQL語法進行預測。接下來，ML模型和業務應用程序之間不再需要API集成，因為模型駐留在數據庫中。

解決方案：在數據庫中嵌入AutoML

在數據庫中嵌入AutoML工具會帶來很多好處，比如：

• 任何使用數據并了解SQL的人(數據分析師或數據科學家)都可以利用機器學習的力量。
• 軟件開發人員可以更有效地將ML嵌入到業務工具和應用程序中。
• 數據和模型之間以及模型和業務應用程序之間不需要復雜的集成。

這樣一來，上述相對復雜的集成圖表變更如下：

它看起來更簡單，也使ML過程更流暢高效。

7.如何實現自助式ML將模型作為虛擬數據庫表

找到解決方案的下一步是來實施它。

為此，我們使用了一個叫做AI Tables的結構。它以虛擬表的形式將機器學習引入數據平臺。它可以像其他數據庫表一樣創建，然后向應用程序、BI工具和DB客戶端開放。我們通過簡單地查詢數據來進行預測。

AI Tables最初由MindsDB開發，可以作為開源或托管云服務使用。他們集成了傳統的SQL和NoSQL數據庫，如Kafka和Redis。

8.使用AI Tables

AI Tables的概念使我們能夠在數據庫中執行ML過程，這樣ML過程的所有步驟(即數據準備、模型訓練和預測)都可以通過數據庫進行。

• 訓練AI Tables

首先，用戶要根據自己的需求創建一個AI Table，它類似于一個機器學習模型，包含了與源表的列等價的特征;然后通過AutoML引擎自助完成剩余的建模任務。后文還將舉例說明。

• 做預測

一旦創建了AI Table，它不需要任何進一步的部署就可以使用了。要進行預測，只需要在AI Table上運行一個標準SQL查詢。

你可以逐個或分批地進行預測。AI Tables可以處理許多復雜的機器學習任務，如多元時間序列、檢測異常等。

9.AI Tables工作示例

對于零售商來說，在適當的時間保證產品都有適當的庫存是一項復雜的任務。當需求增長時，供給隨之增加。基于這些數據和機器學習，我們可以預測給定的產品在給定的日期應該有多少庫存，從而為零售商帶來更多收益。

首先你需要跟蹤以下信息，建立一張AI Table：

• 產品售出日期(date_of_sale)
• 產品售出店鋪(shop)
• 具體售出產品(product_code)
• 產品售出數量(amount)

如下圖所示：

（1）訓練AI Tables

要創建和訓練AI Tables，你首先要允許MindsDB訪問數據。詳細說明可參考MindsDB文檔( MindsDB documentation)。

AI Tables就像ML模型，需要使用歷史數據來訓練它們。

下面使用一個簡單的SQL命令，訓練一個AITable：

讓我們分析這個查詢：

• 使用MindsDB中的CREATE PREDICTOR語句。
• 根據歷史數據定義源數據庫。
• 根據歷史數據表(historical_table)訓練AI Table，所選列(column_1和column_2)是用來進行預測的特征。
• AutoML自動完成剩下的建模任務。
• MindsDB會識別每一列的數據類型，對其進行歸一化和編碼，并構建和訓練ML模型。

同時，你可以看到每個預測的總體準確率和置信度，并估計哪些列(特征)對結果更重要。

在數據庫中，我們經常需要處理涉及高基數的多元時間序列數據的任務。如果使用傳統的方法，需要相當大的力氣來創建這樣的ML模型。我們需要對數據進行分組，并根據給定的時間、日期或時間戳數據字段對其進行排序。

例如，我們預測五金店賣出的錘子數量。那么，數據按商店和產品分組，并對每個不同的商店和產品組合作出預測。這就給我們帶來了為每個組創建時間序列模型的問題。

這聽起來工程浩大，但MindsDB提供了使用GROUP BY語句創建單個ML模型，從而一次性訓練多元時間序列數據的方法。讓我們看看僅使用一個SQL命令是如何完成的：

創建的stock_forecaster預測器可以預測某個特定商店未來將銷售多少商品。數據按銷售日期排序，并按商店分組。所以我們可以為每個商店預測銷售金額。

（2）批量預測

通過使用下面的查詢將銷售數據表與預測器連接起來，JOIN操作將預測的數量添加到記錄中，因此我們可以一次性獲得許多記錄的批量預測。

如想了解更多關于在BI工具中分析和可視化預測的知識，請查看這篇文章。

（3）實際運用

傳統方法將ML模型視為獨立的應用程序，需要維護到數據庫的ETL管道和到業務應用程序的API集成。AutoML工具盡管使建模部分變得輕松而直接，但完整的ML工作流也仍然需要經驗豐富的專家管理。其實數據庫已經是數據準備的優選工具，因此將ML引入到數據庫而非將數據引入ML中是更有意義的。由于AutoML工具駐留在數據庫中，來自MindsDB的AI Tables構造能夠為數據從業者提供自助AutoML并讓機器學習工作流得以簡化。

原文鏈接：https://dzone.com/articles/self-service-machine-learning-with-intelligent-dat

譯者介紹

張怡，51CTO社區編輯，中級工程師。主要研究人工智能算法實現以及場景應用，對機器學習算法和自動控制算法有所了解和掌握，并將持續關注國內外人工智能技術的發展動態，特別是人工智能技術在智能網聯汽車、智能家居等領域的具體實現及其應用。