一、引言
1. 因技術領域而異的人工智能產品
首先，要說明的是，每個人工智能產品都因其所屬的行業不同以及其應用的相關技術不同，有著很大的差異。比如：機器視覺產品和自然語言處理產品從行業數據特徵、業務場景以及算法模型等方面都顯得大相徑庭，雖然同屬於人工智能行業，但兩個細分領域下產品經理所需的背景和知識完全不同。
2. 人工智能產品分類
通常來說，人們從技術角度，將人工智能產品細分為：語音識別產品、自然語言處理產品、機器視覺產品和機器學習產品。
此外，還有一類終端應用產品，它通過各種終端載體形式，綜合應用了上述的多項技術。比如：對於車載智能終端上的語音助理，它主要應用了語音識別和自然語言處理兩個領域的技術，它的產品需求除了涉及到這兩個領域技術的應用策略外，還涉及語音助理客戶端上相關的產品設計。
本文嘗試以“智能車載終端語音助理”產品為例，從語音識別、自然語言處理兩類AI產品的角度出發，去儘可能的介紹人工智能產品需求與傳統互聯網產品需求的異同，也許無法完整的概括人工智能產品需求的方方面面，還請各位讀者見諒。
二、AI產品和互聯網產品PRD的異同
既然是PRD，AI產品的PRD也不外乎由文檔描述、需求背景、競品分析、需求範圍、需求內容幾大部分組成。其中，從文檔描述到需求範圍的部分，AI產品PRD和傳統互聯網產品PRD並沒有太大的不同，二者的差異主要集中在需求內容的部分。而需求內容這方面的差異又因PM角色的不同而有所不同，因此在展開這一部分之前，先簡要介紹一下車載語音助理產品的分工。
一般來說，一個車載語音助理可以由聲學前端&ASR、客戶端及Bot Framwork三部分組成，分別對應著聲學交互PM、客戶端PM及技能PM。
1. 車載語音助理的產品分工
1）聲學交互PM
通過制訂應用語音識別技術時的一些策略，來實現端上的一些產品特性。聲學交互PM有點類似傳統互聯網的策略PM，但需要PM對語音識別的各項技術及其應用的場景較為了解。
2）客戶端PM
主要對語音助理框架性的交互（GUI及CUI）體驗負責，過程中，往往需要形成一套交互規範供技能PM參考，保證端體驗的一致性。語音客戶端PM相比於傳統互聯網的客戶端PM，除了要對GUI交互熟悉之外，更需要對CUI交互有獨到的理解。
3）技能PM
基於Bot Framwork，設計各個技能的意圖、會話及服務，來實現端上的一些產品特性。技能PM需要對語義技術、語義設計有自己的理解，同時在服務設計上需要對CUI交互有自己的理解。
如果將語音助理比作一座大廈，那聲學交互PM就像是負責打地基的，提供了最基礎的語音交互能力；而客戶端PM，則像是用鋼筋搭起了整個建築的框架；而技能PM，則是用混凝土們將整個建築填充的更加豐滿。
2. 車載語音助理的產品需求
由於聲學交互PM、客戶端PM和技能PM的分工不同，他們的需求文檔在需求內容方面的側重就有所不同。
1）聲學交互類需求
這類需求，首先對技術提出了能力方面的要求，其次選取合適的場景將能力落地，形成一定的語音交互上的產品特性。
一方面，產品需要在需求文檔中說明“要運用的技術需要達到的能力”，並將這個能力包裝為接口，指定相應的輸入和輸出，同時規定一些性能指標。另一方面，產品也會結合一些場景，制訂一些策略，從而產出一些新的交互特性。這些特性，往往可能不是由一個單一的技術來實現的，可能需要將多種技術綜合應用。
例如：語音助理的多音區，其實包含了兩種技術能力。首先是聲源定位，即分辨車內發音人的來源是在主駕、副駕還是後排，其次是波束成形，即可以只對喚醒人所在方向進行收音，對過程中非喚醒人的聲音信號進行抑制。
在這個能力上，產品可以指定將多音區的聲源定位能力加入車控指令，從而實現副駕說打開車窗，僅開啟副駕側車窗的特性。也可以指定將多音區的波束成形能力接入語音交互的流程，使得主駕喚醒之後只接收主駕的指令。
2）客戶端類需求
一般來說，語音助理是圍繞一個bot來運作的，這個bot接收文字輸入，輸出語義或服務結果，過程中可能會涉及到多輪和應答。而客戶端類需求，就是針對bot從輸入到輸出的整個過程去定義框架性的交互體驗，同時，還會涉及到一些端上常規模塊的功能設計。
首先，需要定義bot接收文字輸入前所有流程的設計，主要是喚醒和識別流程中的GUI和CUI設計，以及過程中的異常流程處理，例如用戶不說話時如何處理、超時時如何處理、網絡異常時如何處理等。
其次，需要定義在bot運行過程中，包括語義解析、多輪會話及相應多輪應答以及最終輸出語義及服務結果時所需的框架性GUI設計，如顯示區域定義、顯示模板定義、GUI交互定義等。
值得指出的是，這兩部分需求的提出，往往伴隨著設計規範一起產出。對於GUI而言，類似於傳統互聯網的客戶端PM，需要給出整個界面的原型設計，不同的是，這裡往往需要給出模板化的設計，來儘可能的滿足各類場景下GUI展示的需要。CUI方面，會給出回覆語設計應該遵循的一些原則，例如：合作原則、禮貌原則等，同時，也會根據語音助理的設定提一些語氣方面的要求。
最後，是語音助理客戶端上一些常規模塊設計。例如：用戶登錄、設置、幫助等，而後者和傳統互聯網產品基本上是一致的。
3）技能類需求
這類需求側重於技能相關的語義 、會話及服務設計。
（1）語義設計
語義設計，分為語義表示定義、模板定義和語料定義三個部分。
語義表示定義，即定義技能所屬領域Domain、領域下的意圖Intent、意圖內的參數Slot以及參數對應的實體。例如：為了讓語音助理聽懂並回答“今天天氣怎麼樣？”
這一問題，技能PM需要設計一個天氣查詢的技能，定義它屬於語義所屬的領域 – 天氣、意圖 – 查詢天氣，定義用戶query中可能會出現的參數 – 地點、時間等，同時還要定義參數對應的實體庫。
模板的設計，其實就是寫一些正則表達式來保證冷啟動時的召回。這一部分可能會在專門的語義平臺上進行，不一定會在需求文檔中體現。
語料的定義，即語料的收集及標註。需要產品在需求中說明語料收集的場景、示意的問法等等給到專門的團隊，同時說明標註的規則，供標註人員在語料收集完成後進行標註工作。而標註好的語料，會給到語義模型進行學習，來提升意圖的準召率。
模板和語料的定義，直接關係到了語音助理在意圖上的泛化能力，也是需求中不容忽視的部分。不論是在語義表達的設計還是在語料定義的時候，都需要儘可能的考慮用戶的表達方式，儘可能的去覆蓋更多的說法。
（2）會話設計
會話設計，主要是針對多輪對話過程中的CUI及GUI設計，即根據當前所處的對話狀態對用戶進行引導，從而明確用戶的指令。如果用戶提供的信息還不足以執行任務，需要設計相應的澄清話術引導用戶完成填槽，過程中，可能會配合必要的視覺展示，供用戶進行決策。同時，GUI有時候還承擔了一定的用戶引導作用，提示用戶當前可以說些什麼指令來繼續對話。
（3）服務設計
服務設計，即最終服務結果呈現時的回覆話術設計及GUI的設計。還是以天氣舉例子，用戶聽到的“深圳今天是晴天，氣溫21到26攝氏度”就是典型的回覆話術設計，而看到的天氣卡片就是GUI的設計，上面可能顯示了天氣、氣溫、溼度、空氣質量指數等。
回覆話術的設計，包含成功執行和異常時的回覆。由於語音具備輸入高效，輸出低效的特點，因此在回覆語的設計上需要儘可能簡潔地給出必要的信息。
在結果的呈現上，需要產品在需求中定義視覺展示時頁面的信息如何排布，是否涉及二次交互等等。這一部分的內容類似傳統互聯網的原型設計，只是在設計的時候需要考慮車載端的交互特性。
三、結語
最後想說，無論是什麼領域的需求文檔，它都是一份產品需求文檔，和傳統互聯網的需求文檔在結構上並沒有什麼不同，具體的差異因為產品經理角色的不同體現在了需求內容的部分。
說明：如作者所說，由於人工智能產品的分類很多，還有計算機視覺、機器學習等其他領域的PRD特點沒有涵蓋，如果你是有興趣來分享輸出的AI產品經理，歡迎單獨聯繫我。
作者：星雲
本文由 @星雲 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pixabay，基於 CC0 協議