了解如何使用與您相同的規則處理 AI 資料。
人工智慧 （AI） 很熱門，您的興趣會讓您喋喋不休地談論正向或反向鏈、神經網路、深度學習、貝葉斯邏輯、集群、分類器系統等。 這些都是人工智慧技術，但人工智慧被埋沒的神奇能力來自於它對所需資料的絕對數量和質量的同等重視。 事實上，人工智慧需要大資料。 在我的上乙個教程《智慧型資料，第 1 部分》中，我深入探討了資料在 AI 中的作用。 在本教程中，我將向您展示如何將眾所周知的軟體開發生命週期 （SDLC） 的迭代版本應用於 AI 應用程式的資料。 雖然有許多人工智慧演算法以不同的方式使用資料，但機器學習是對當前人工智慧熱潮貢獻最大的演算法。 出於這個原因，為了與上一教程保持一致，本教程中的大部分討論和示例仍然集中在機器學習上。 考慮有效收集、準備和使用 AI 資料的最佳方式，類似於軟體開發生命週期。 本著與敏捷開發的最新發展相同的精神，我喜歡採用定義明確的迭代方法來管理 AI 資料，而不是嚴格的“瀑布式”方法。
開發人員應該已經熟悉迭代 SDLC。 啟動乙個專案後，專案進入規劃和需求象限，然後在軟體的整個生命週期中持續迭代，真正將“週期”融入生命週期。 這個概念有很多變體，包括部署只是在測試後退出流程的想法。
當然，開發人員通常會從功能規範、資料庫模式、介面和結構圖、程式和測試用例的角度來考慮這些階段。 充其量，資料流圖包含在設計中，但資料似乎經常在 SDLC 中零碎處理，這對 AI 開發不利。
作為乙個整體，團隊可以做的最重要的事情是在規劃中包括對資料的需求，以及對部署環境的一般問題定義和理解。 如果您的團隊正在使用需要訓練例項的眾多 AI 技術之一，則您的團隊應確定要獲取哪種訓練資料。 這取決於可用的資料，以及問題陳述和需求，因為訓練資料越多，例如部署軟體所需的結果範圍越大，成功的幾率就越大。
可能存在反饋迴圈，其中缺乏適用的訓練資料導致需要修改解決方案。 原始需求可能能夠在將來的迭代中恢復。 例如，假設團隊正在開發乙個虹膜標記程式，但唯一可用於訓練的資料是眾所周知的虹膜資料集（有關更多資訊，請參見第 1 部分）。 研究小組可能會決定，對於早期迭代，目標應該是以高置信度從其他兩個物種中識別山鳶尾，但在區分維吉尼亞鳶尾和雜色鳶尾時接受較低的置信水平。 在以後的迭代中獲得更好的技術或資料後，可以提高期望值，自信地分配所有 3 個類別。 在分析和設計時，應合併 AI 的原始資料源。 當您開始收集這些資料時，您將開始了解如何對其進行審查、豐富、維護和評估。 盡早確定格式限制和引數，例如影象的最小和最大規格，或音訊的長度。 對於像 Iris 資料集這樣的資料，不要忘記控制資料單位。 您不希望將以英吋為單位記錄的測量值與以厘公尺為單位記錄的測量值混合在一起。 請記住一位高階數學老師的話，每個地方的每個數字都需要以單位標記，無論是在資料值本身（作為抽象資料型別）還是在資料模式中。 在任何情況下，您都可能希望在您的**或專家審查說明中包含某種單位驗證或轉換。
資料設計中應該包含的乙個非常重要但經常被忽視的方面是**。 每個資料項從何而來，我們能如何有效地跟蹤它？ 在人員或系統到達您的應用程式之前，監管鏈是什麼？ 您的應用究竟是如何通過演算法或專家評審來改變它的？ 如果發現異常、偏差原因或其他問題，這可能是了解需要修復或丟棄的較大聚合語料庫中的哪些資料的關鍵。 這對於系統的持續改進也很重要。 隨著應用程式的成熟，並且您更深入地了解哪些技術和流程有效，哪些無效，您可以對資料來源有相同的理解。
第 1 部分更完整地解釋了尺寸。 在此階段，您還必須決定或重新考慮要用作訓練樣本或演算法中的資料維度。 向資料新增更多細節是否會降低效能？ 這是否會改善結果，還是會因維度災難而損害結果的可靠性？ 分析和設計是建立降維技術的常見階段。
資料流圖 （DFD） 是乙個非常重要但未被充分利用的設計工件。 在 70 年代末頗具影響力的《結構化設計》雜誌上，Ed Yourdon 和 Larry Constantine 首次將詳細的資料流圖作為軟體工程過程的關鍵部分。 這項工作建立在 D**id Martin 和 Gerald Estrin 的早期工作之上。 安全等領域的開發人員認識到資料流圖對銀行應用程式的重要性，因為需要將其從遠端使用者的瀏覽器傳遞到零售分類賬和後端對賬系統中更安全的層。 類似級別的詳細描述是確定 AI 資料準備過程的重要組成部分，而這反過來又是在您的領域取得成功的重要因素。
人工智慧資料的DFD往往基於常見的資料採集和準備技術。 下圖是 DFD 的抽象版本，您應該根據問題域的性質、資料的性質和您採用的演算法採取更具體的步驟來更新它。
資料流圖是關於資料的，而不是關於流程的。 圓角框是流程，但應根據資料的處理方式來描述它們。 箭頭是顯示資料在流程中經歷的步驟的鍵。 最終的資料儲存庫是應用程式的語料庫。 雖然 DFD 不是乙個流程，但我提供了乙個迴圈圖示來提醒流程應該持續執行，不斷獲取分析所需的新資料（例如資料集評分的結果）並將其注入語料庫。
為了幫助您專門為專案建立 DFD，以下是此示例中包含的一些抽象過程。
資料採集是獲取最終包含在語料庫中的原始資料的過程。 這可以通過數位化或資料抓取（通過蠻力從網頁或其他地方提取資料）來完成。 資料整理是將資料格式轉換為輸入所需的格式，檢測機器理解的元資料特徵（包括**）並標記資料的過程。 您還將嘗試在此處識別離散資料項並消除重複項。 資料清理是評估已識別和標記的資料項以更正或刪除損壞、不完整或不準確的資料的過程。 評分和整合是指應用統計分析來確保生成的語料庫的整體健康。 每個資料項都可以根據其是否適合語料庫維護需求進行評分。 可以對要新增到語料庫的整個資料項集合進行評分，以確保以最大限度地提高演算法效率和準確性的方式對其進行組合。 一種流行的評分步驟模型是探索性資料分析 （EDA），它涉及一組中不同變數之間關係的多種視覺化表示組合。 執行全面的 EDA 是成功降維的重要因素。
在本教程中，我將繼續分析 SDLC 的後期階段，但接受資料分析和準備是 AI SDLC 所有階段的持續活動這一原則至關重要。
SDLC 從早期出現的許多軟體開發方法中吸取的關鍵經驗教訓之一就是將實施落實到位。 大多數人從事程式設計工作是因為他們發現這是乙個令人興奮的職業。 一步一步地引導計算機並看著它做一些特別的事情可能會令人興奮。 甚至搜尋錯誤並尋求演算法的改進也會令人興奮。
這種心理因素意味著開發人員總是傾向於盡快進入實施階段，而沒有對成功專案的規劃、分析、設計、結構化測試、系統管理和其他方面給予足夠的關注。 與實際編碼相比，這些其他階段可能看起來很無聊，但經驗和工程規範表明，與超支和截止日期相關的專案問題的常見原因包括未能明確調整需求以及缺乏對結構化測試的關注。
在 SDLC 圖中，您可以看到實現通常只是分析和設計的結束，並且這種重點也延伸到資料。 在實現階段對資料的關注主要是為了確保演算法編碼忠實地反映設計。
在測試過程中，一切都會改變。 在 AI 應用程式中，測試允許您檢視所有資料收集和準備是否成功。 訓練資料經過演算法處理，並與預期結果進行比較。 預期結果可能是在最初獲取訓練語料庫期間獲得的，也可能是從 SDLC 的先前迭代中獲得的。 在開發 AI 應用程式時，測試和評估之間的聯絡尤為重要，這是乙個關鍵時刻，這就是為什麼 AI 在 SDLC 上迭代的次數通常比在生產中使用之前需要更多次。
測試的核心是將預期結果與實際輸出進行比較，這是對演算法流程是否按預期訓練樣本的機械評估。 這只是確保人工智慧產生可靠、實際結果的過程的開始。 評估通常由專家監督，他們負責處理來自潛在實際應用程式的計畫外資料。 如果您正在開發手機**，您可能會有一組來自多個已知說話人的短語錄音，例如“迦納有多少人？ 您可以將語音響應與預期答案進行比較。 評估可能包括讓新演講者提出相同的問題或略有改變的問題，例如“奈及利亞有多少人？ 評估結果的專家能夠更好地理解**在更現實的條件下可以提供的可能結果。
評估過程通常涉及部署應用程式，讓測試人員使用它，然後讓客戶使用它。 來自所有這些資料的反饋可以指導後續的規劃階段，以幫助進行後續迭代。 也許來自實地的報道表明，**無法區分一些發言者的問題：“迦納有多少人？ “和” 蓋亞那的人口是多少？ 這可能是後續迭代中訓練和測試的重要樣本。
第乙個教程解釋了資料對於建立 AI 和認知應用程式的重要性，這種重要性如何在整個學科歷史中持續存在，以及它與 AI 在整個歷史上的成功和失敗有何關係。 在本教程中，我將按照與我相同的原則，解釋如何在類似的過程中處理 AI 資料。 應用傳統的迭代 SDLC 來利用當今可用的大量資料，同時對危險保持警惕。