1.如何成為一個IDO?

要成為一個IDO(insight-driven organization)，前提是要有數據以及操作和分析數據的工具;然后還要有一定經驗的數據分析師或數據科學家;最后需要找到一種技術或者方法，在公司實施洞察力驅動的決策過程。

機器學習是能極大限度發揮數據優勢的技術。機器學習流程是先運用數據訓練預測模型，訓練成功之后再處理與數據相關的問題。其中，人工神經網絡是很有效的技術，它的設計構思來自現階段我們對人腦工作方式的理解?？紤]到我們現階段擁有的巨大計算資源，它能通過大量數據訓練產生讓人難以置信的模型。

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

2.為什么企業在采用AI方面進展緩慢?

運用AI或機器學習來處理數據的企業僅是少數。美國人口普查局指出，截至2020年，只有不到10%的美國企業采用了機器學習。

采用機器學習的困難包括：

AI在取代人類之前還有大量工作沒有完成。首先是很多企業缺少且請不起專業人員。數據科學家在這一領域備受推崇，但他們的雇傭成本也是極高的。

缺少可用數據、數據安全性以及耗時的機器學習算法實現。

企業很難創造一個環境，來讓數據及其優勢得到發揮。這種環境需要相應的工具、過程和策略。

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

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

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

4.分解機器學習過程

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

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

5.將機器學習與應用程序集成

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

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

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

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

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

現在問題來了：

為什么我們要把機器學習作為一個獨立的應用程序，并在機器學習模型、應用程序和數據庫之間實現復雜的集成呢?

為什么不讓機器學習成為數據庫的核心功能呢?

為什么不讓機器學習模型通過標準的數據庫語法(如SQL)可用呢?

讓我們分析上述問題及其面臨的挑戰，來找到機器學習解決方案。

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

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

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

挑戰#2：機器學習模型與應用程序的集成

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

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

解決方案：在數據庫中嵌入自助機器學習

在數據庫中嵌入自助機器學習工具會帶來很多好處，比如：

任何運用數據并了解SQL的人(數據分析師或數據科學家)都能利用機器學習的力量。

軟件開發人員能更有效地將機器學習嵌入到業務工具和應用程序中。

數據和模型之間以及模型和業務應用程序之間不需要復雜的集成。

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

它看起來更簡單，也使機器學習過程更流暢高效。

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

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

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

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

8.運用AI Tables

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

訓練AI Tables

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

做預測

一旦創建了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就像機器學習模型，需要運用歷史數據來訓練它們。

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

讓我們分析這個查詢：

運用MindsDB中的CREATE PREDICTOR語句。

根據歷史數據定義源數據庫。

根據歷史數據表(historical_table)訓練AI Table，所選列(column_1和column_2)是用來進行預測的特征。

自助機器學習自動完成剩下的建模任務。

MindsDB會識別每一列的數據類型，對其進行歸一化和編碼，并構建和訓練機器學習模型。

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

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

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

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

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

（2）批量預測

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

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

（3）實際運用

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