引導分析原則
自動化資料科學的系統最近引起了很多關注。 與智慧家居助手類似,為企業使用者自動化資料科學僅適用於定義明確的任務。 我們不希望家庭助理就改變主題進行深入的對話。 事實上,最成功的系統嚴重限制了可能的互動型別,無法處理模糊定義的主題。 真正的資料科學問題同樣含糊不清:只有業務分析師和資料分析師之間的互動式交流才能在新的有用方向上引導分析,從而可能引發有趣的新見解並進一步加強分析。
因此,一旦我們離開完全自動化的資料科學沙箱領域,挑戰在於允許資料科學家構建互動式系統,以互動方式協助業務分析師尋求新的資料洞察並預測未來結果。 KNIME將此稱為 “引導式分析”。 他們明確表示不會更換驅動程式(或完全自動化流程),而是在整個分析過程中隨時提供幫助和收集反饋。 為了實現這一目標,資料科學家需要能夠輕鬆建立分析應用程式,以便在需要專業知識和反饋時與業務使用者進行互動。
引導分析的環境
是什麼使資料科學家團隊能夠協作合併他們的專業知識並構建這樣一個互動式,甚至是自適應分析應用程式? 為業務使用者提供適當數量的指導和互動的應用程式?
理想情況下,這樣的環境會有一些屬性:
開放性。 環境不會在使用的工具方面釋出限制 - 這也簡化了指令碼大師(例如R或Python)與其他只想重用其專業知識而不深入其程式碼的人之間的協作。 能夠在同一環境中接觸特定資料型別(文字,影像等)或專用高效能或大資料演算法(如H2O或Spark)的其他工具將是一個優勢;
均勻性。 同時,建立資料科學的專家可以在同一環境中完成所有工作:混合資料,執行分析,混合和匹配工具,以及構建基礎架構以將其部署為分析應用程式;
靈活性。 在分析應用程式的下方,我們可以執行簡單的迴歸模型或編排複雜的引數最佳化和集合模型 - 範圍從一個到數千個模型。 這個(或至少它的某些方面)可以完全隱藏在業務使用者之外;
敏捷。 一旦應用程式在野外使用,新的需求將迅速出現:更多的自動化,更多的消費者反饋。 用於構建這些分析應用程式的環境需要使資料科學團隊的其他成員能夠直觀地將現有分析應用程式快速適應新的和不斷變化的需求。
簡而言之,具有不同偏好和技能的資料科學家需要協作構建,維護和不斷完善一組分析應用程式,從而向業務使用者展示高度不同的互動程度。 其中一些應用程式只需按一下按鈕即可顯示概述或預測。 其他人只允許終端使用者選擇要使用的資料來源。 其他人將向使用者詢問反饋,最終改進在引擎蓋下訓練的模型,並考慮使用者的專業知識。 這些模型可以是簡單的或任意複雜的集合或整個模型系列,終端使用者可能會或可能不會被要求幫助改進該設定。
自動什麼?
那麼所有這些無人駕駛,自動,自動化的AI或機器學習系統如何適應這種情況呢? 他們的目標是封裝(和隱藏)現有專家資料科學家的專業知識,或者應用或多或少複雜的最佳化方案來微調資料科學任務。 如果沒有內部資料科學專業知識,這可能很有用,但最終,業務分析師被鎖定在預先打包的專業知識和有限的硬編碼方案集中。
資料科學家的專業知識和引數最佳化都可以輕鬆地成為指導分析工作流程的一部分。 由於任何型別的自動化往往總是錯過重要且有趣的部分,因此新增引導分析元件使其更加強大:您可以指導最佳化方案並將預編碼的專業知識調整為手頭的新任務。
KNIME中的引導分析
資料科學家團隊使用KNIME工作流程進行協作,並透過KNIME Server的Web介面為其業務分析師同事提供訪問這些工作流程的許可權。 無需使用其他工具來構建Web應用程式; 工作流本身模擬構成分析應用程式的互動點(簡單的UI元素或複雜的互動式視覺化)。 工作流是將所有工具組合在一起的粘合劑:資料科學團隊的不同成員使用的不同工具,資料工程專家從各種來源混合的資料,以及對終端使用者可見的UI元件建模的互動點。
下圖顯示了此類工作流程的說明性示例:
幾個灰色元節點代表工作流的“互動點”:構建此工作流的資料科學家設計它們,以便在KNIME伺服器上執行時,工作流允許在分析中的這些點與其他業務分析師進行互動。在示例工作流程中,第一個互動點允許業務分析人員選擇要分析的資料集(“選擇資料”)。載入資料後,第二個互動點(“資料清理”)顯示資料概覽,並允許業務分析師進行互動:刪除無用的列,處理異常值,修復偏斜的分佈 - 無論資料科學家認為哪些有趣且相關這點。
中間的部分現在進行分析,並允許業務分析師提供反饋,直到達到令人滿意的結果。 工作流程透過允許分析人員直接將模型部署到 - 在這種情況下 - 資料庫或在互動式儀表板中檢查結果來結束。 這些節點中的每一個都透過一組互動式視覺化節點來模擬使用者互動,這些節點使用與KNIME中其他地方完全相同的工作流模式,允許資料科學家基本上設計一個捕獲業務分析師反饋的網頁。 下圖顯示了我們的“Analytics Interaction Point”的內部結構,以及從該節點為指導分析應用程式自動建立的頁面。
透過KNIME Server部署分析應用程式是跨團隊邊界協作的一個方面。 另一個重要方面是可重用性:KNIME Server還允許跨資料科學團隊共享元節點,使其他人能夠在現有部分之上構建:如上所述的互動點以及其他元節點,這些元節點可以封裝預先打包的資料混合,不同型別的分析,顯然也是(半)自動ML或無人駕駛(輔助)AI的化身。
引導分析:旅程在哪裡?
KNIME對引導分析非常感興趣。 最初,這通常僅用作強大的互動式資料探索和清理機制,但越來越多的使用者開始將分析新增到組合中,並允許使用者對資料進行爭論並對其分析進行微調。 這也促進了協作:透過對整個設計的視覺化工作流程的一致使用,資料科學家不斷重複使用現有的工作,並建立越來越複雜的指導分析工作流程。 管理模型工廠,透過結合主動學習方法互動式地改進模型,半自動機器學習都只是該框架的組成部分。 看看資料科學家如何繼續構建更加強大的並行工作的分析應用程式,這將是非常有趣的, 協助專家使用者建立真正有用的分析。 而不是將專家從駕駛員座位中取出並試圖使他們的智慧自動化。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31557424/viewspace-2220400/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 開閉原則——物件導向程式設計原則物件程式設計
- 物件導向OO原則物件
- 物件導向設計原則物件
- 物件導向設計的六大原則(SOLID原則)-——里氏替換原則物件Solid
- 物件導向之 開閉原則物件
- 互動設計原則分析
- 不止於物件導向的SOLID原則物件Solid
- 2.物件導向設計原則物件
- 物件導向設計原則和模式物件模式
- 物件導向的基本設計原則物件
- The Principles of OOD 物件導向設計原則物件
- EureKa與ZooKeeper的CAP原則分析
- 物件導向的編碼設計原則物件
- 物件導向的六大原則物件
- Java中物件導向的設計原則Java物件
- SpringBatch基本的批處理指導原則SpringBAT
- 物件導向設計的6大原則物件
- Spring Batch 基本的批處理指導原則SpringBAT
- 翻譯 | The Principles of OOD 物件導向設計原則物件
- 物件導向之六大設計原則物件
- OCP原則——開閉原則
- 七種常見的物件導向設計原則物件
- 10個產品主導的增長原則|Bessemer
- 物件導向設計原則&設計模式分類物件設計模式
- SOLID:物件導向設計的前五項原則Solid物件
- 61條物件導向設計的經驗原則物件
- 前端設計模式(0)物件導向&&設計原則前端設計模式物件
- 設計原則:開閉原則(OCP)
- 實驗1:UML與物件導向程式設計原則物件程式設計
- 設計和架構:業務開發指導原則架構
- 軟體開發中的10條最佳指導原則
- 設計原則之【介面隔離原則】
- 設計原則-依賴反轉原則
- 設計原則:介面隔離原則(ISP)
- SOLDI原則之DIP:依賴倒置原則
- SOLID原則Solid
- oop原則OOP
- 物件導向程式設計(OOP)的七大原則物件程式設計OOP