讓你的AI模型儘量的靠近數據源

來源：Redislabs
做者：Pieter Cailliau、LucaAntiga
翻譯：Kevin （公衆號：中間件小哥）

簡介

今天咱們發佈了一個 RedisAI 的預覽版本，預集成了[tensor]werk組件。RedisAI 是一個能夠服務 tensors 任務和執行深度學習任務的 Redis 模塊。在這篇博客中，咱們將介紹這個新模塊的功能，並解釋咱們爲何會認爲它能顛覆機器學習（ML）、深度學習（DL）的解決方案。
RedisAI 的產生有兩大緣由：首先，把數據遷移到執行 AI 模型的主機上成本很高，而且對實時性的體驗很大的影響；其次，Serving 模型一直以來都是 AI 領域中 DevOps 的挑戰。咱們構建 RedisAI 的目的，是讓用戶能夠在不搬遷Redis 多節點數據的狀況下，也能很好地服務、更新並集成本身的模型。

 

數據位置很重要

爲了證實運行機器學習、深度學習模型中數據位置的重要性，咱們舉一個聊天機器人的例子。聊天機器人一般使用遞歸神經網絡模型（RNN），來解決一對一（seq2seq）用戶問答場景。更高級的模型使用兩個輸入向量、兩個輸出向量，並以數字中間狀態向量的方式來保存對話的上下文。模型使用用戶最後的消息做爲輸入，中間狀態表明對話的歷史，而它的輸出是對用戶消息和新中間狀態的響應。

爲了支持用戶自定義的交互，這個中間狀態必需要保存在數據庫中，因此 Redis +RedisAI是一個很是好的選擇，這裏將傳統方案和 RedisAI 方案作一個對比。

 

1、傳統方案

使用 Flask 應用或其它方案，集成 Spark 來構建一個聊天機器人。當收到用戶對話消息時，服務端須要從 Redis 中獲取到中間的狀態。由於在 Redis 中沒有原生的數據類型可用於 tensor，所以須要先進行反序列化，而且在運行遞歸神經網絡模型（RNN）以後，保證明時的中間狀態能夠再序列化後保存到 Redis 中。

 

 考慮到 RNN 的時間複雜度，數據序列化/反序列化上 CPU 的開銷和巨大的網絡開銷，咱們須要一個更優的解決方案來保證用戶體驗。

 

2、RedisAI 方案
在 RedisAI 中，咱們提供了一種叫 Tensor 的數據類型，只需使用一系列簡單的命令，便可在主流的客戶端中對 Tensor向量進行操做。同時，咱們還爲模型的運行時特性提供了另外兩種數據類型：Models 和 Scripts。

 

 Models 命令與運行的設備（CPU 或 GPU）和後端自定義的參數有關。RedisAI 內置了主流的機器學習框架，如 TensorFlow、Pytorch 等，並很快可以支持 ONNX Runtime 框架，同時增長了對傳統機器學習模型的支持。然而，很棒的是，執行 Model 的命令對其後端是不感知的：

AI.MODELRUN model_key INPUTS input_key1 …  OUTPUTS output_key1 ..

這容許用戶將後端選擇（一般由數據專家來決定）和應用服務解耦合開來，置換模型只須要設置一個新的鍵值便可，很是簡單。RedisAI 管理全部在模型處理隊列中的請求，並在單獨的線程中執行，這樣保障了 Redis依然能夠響應其它正常的請求。Scripts 命令能夠在 CPU 或GPU 上執行，並容許用戶使用 TorchScript 來操做Tensors 向量，TorchScript 是一個可操做 Tensors 向量的類 Python 自定義語言。這能夠幫助用戶在執行模型前對數據進行預處理，也能夠用在對結果進行後處理的場景中，例如經過集成不一樣的模型來提升性能。

咱們計劃將來經過 DAG 命令支持批量執行命令，這會容許用戶在一個原子性操做中批量執行多個 RedisAI 命令。例如在不一樣的設備上運行一個模型的不一樣實例，經過腳本對執行結果作平均預測。使用 DAG 命令，就可並行地進行計算，再執行聚合操做。若是須要全量且更深的特性列表，能夠訪問 redisai.io。新的架構能夠簡化爲：

模型服務能夠更簡單

在生產環境中，使用 Jupyter notebooks 來編寫代碼並將其部署在Flask 應用並非最優方案。用戶如何肯定本身的資源是最佳的呢？若是用戶主機宕機以後，上述聊天機器人的中間狀態會發生什麼呢？用戶可能會重複造輪子，實現已有的 Redis 功能來解決問題。另外，因爲組合方案的複雜度每每超出預期，執拗地堅持原有的解決方案也會很是有挑戰性。RedisAI 經過 Redis 企業級的數據存儲方案，支持深度學習所須要的 Tensors、Models 和 Scripts等數據類型，很好的實現了 Redis 和 AI 模型的深度整合。若是須要擴展模型的計算能力，只須要簡單的對Redis 集羣進行擴容便可，因此用戶能夠在生產環境中增長儘量多的模型，從而下降基礎設施成本和整體成本。最後，RedisAI 很好地適應了現有的 Redis 生態，容許用戶執行腳原本預處理、後處理用戶數據，可以使用 RedisGear 對數據結構作正確的轉換，可以使用RedisGraph 來保持數據處於最新的狀態。 

 

結論和後續計劃

一、短時間內，咱們但願使用RedisAI 在支持 3 種主流後端（Tensorflow、Pytorch 和 ONNX Runtime）的狀況下，儘快穩定下來並達到穩定狀態。
二、咱們但願能夠動態加載這些後端，用戶能夠自定義的加載指定的後端。例如，這將容許用戶使用Tensorflow Lite 處理邊緣用例。三、計劃實現自動調度功能，能夠實如今同一模型中實現不一樣隊列的自動合併。四、RedisAI會統計模型的運行數據，用於衡量模型的執行狀況。

五、完成上文中解釋的DAG 特性。

 

更多優質中間件技術資訊/原創/翻譯文章/資料/乾貨，請關注「中間件小哥」公衆號！