起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識關于智能產品的不確定性
編輯導語：隨著科技的不斷發展，更多智能產品開始深入到我們的生活工作中去，但智能產品很多都會存在一個不確定性，與用戶表達的意思不相符合；本文作者分享了關于智能產品的思考以及未來的發展，我們一起來了解一下。
最近半年負責了一款智能領域相關的產品，主要是通過NLU（自然語言理解）技術，識別用戶提供的文本，然后推薦對應的功能或者內容。
在負責期間，體驗最深的一點就是智能產品的不確定性。有句玩笑話說得好：什么叫智能，就是有時候出現，有時候不出現，就叫智能。這個玩笑話，一方面是對智能產品的總結，智能產品就是在“猜”，猜測用戶的意圖。至于為什么要猜，因為用戶不會真實告訴你想要什么，用戶甚至都不知道自己想要什么，所以只能靠“猜”。
當然，另一方面其實也是對于智能產品現狀的諷刺，目前受限于人工智能的技術限制，現在確實沒辦法做到非常智能的表現，很多時候我們會戲稱為“人工智障”。
作為產品經理，這時候不能僅僅是無奈，首先就需要擁抱這種不確定性，因為這種不確定性將會貫穿產品的生命周期；其次，產品需要想方設法通過一些策略來規避不確定性對產品表現帶來的影響。
一、為什么智能產品會存在不確定性
簡單聊聊智能產品為什么會存在不確定性，先來看看現在能接觸到的智能產品以及背后的技術都有哪些：
- 支付寶的指紋識別、人臉識別：圖像識別
- 手機的語音助手：語音語義識別
- 淘寶、今日頭條的信息流：推薦系統
以圖像識別為例，說說人工智能技術的邏輯：
這些產品采用的技術可以分為以下幾種：
監督學習：以水果分類為例子，在我們嬰兒時期，我們并不知道什么是蘋果什么是梨，是隨著我們慢慢學習，然后才認識這兩種水果。那么APP怎么識別呢？
首先也需要有學習的過程，需要事先知道一批水果是蘋果或者梨；然后把這批水果分成兩部分，第一部分用來訓練我們的識別模型（即學習的過程），另一部分用來驗證（可以認為是考試）；當我們驗證的效果高于某個值，比如準確率達到99%，我們就可以認為這個模型有效，這個模型就可以后續用來識別蘋果或者梨這兩種水果了，監督學習的特征在于我們事先知道了一些水果的分類；上述的產品基本都屬于監督學習。
無監督學習：無監督學習以聚類為主，比如有兩棵樹，一棵蘋果樹和一棵梨樹，工人采集完水果之后就隨便扔到了樹下，這時候要對樹下的水果進行分類；由于工人是隨便扔的，那么蘋果肯定離蘋果樹比較近，梨離梨樹比較近；我們不需要知道水果長什么樣子，也不需要知道他們長什么樣子，只要算一下水果之間的距離，就可以把水果分成兩堆；對于無監督學習，我們并不知道他們的特征，而是依靠他們之間的關系來判定的。
增強學習：阿爾法狗（就是打敗柯潔的那個）就是用這種算法的，但是具體比較復雜，有興趣可以自行了解一下。
為什么人工智能要用這些技術，我們以人臉識別為例，你為什么能識別出一個人？首先你肯定要見過，并且留下過比較深的印象；然后再次遇到的時候，你就會將遇到的人和腦海里的人進行比較，然后達到一定相似度的時候，你就會認出這個人是誰誰誰。
這個過程分為：認識-記憶-遇到-比對-識別，那么對應過來，監督學習的樣本可以認為是認識的過程，訓練模型就是記憶的過程，為了防止記憶有問題，我們還加了一個驗證的過程；最后就是遇到，然后比對和識別，整個流程是類似的；人尚且會認錯人，那么模擬人的識別而仿造出來的系統會出錯自然也就不意外了。
回到我負責的產品，是一款NLU產品，NLU全稱叫自然語言理解，“自然語言”就是指我們說的話；每個人習慣不同，知識水平不同，說出來的話也不同；比如說表達喜歡的話，普通人就一句“我喜歡你”，夏目漱石就會說“今晚月色真好”。
這種表達不同帶給產品的就是：對于單獨的一句話，可以確定它的意思。但是對于表達同樣意思的所有話，不敢保證所有的話都能被識別出來，因為無法窮舉或者明確定義，所以會帶來不確定性。
二、產品定義的確定性
智能產品的不確定性是天生的，產品經理有義務從自身的系統搭建去盡量減少這種不確定；這種在產品上能做的，首先就是要通過明確產品的定義，從根源上盡量減少不確定性。
以上面的例子來說，“今晚月色真美”這種例子會被杜絕在外，首先是受眾上而言，大部分人不會用這種表達方式。
其次，存在歧義，這句話明面上就是夸獎月色的，深層次才是表達喜歡的；所以這種有歧義的，在定義上的就需要杜絕。
那么回到普通的喜歡，通過研究可以發現，句式一般是“人名（包括代詞）+喜歡（或者愛，或者養）+人名（包括代詞）”；這個就是對于喜歡的定義，這個定義可以指導后續的樣本的選擇，樣本的選擇和標注對于后續模型的訓練是非常至關重要的一步，直接決定了模型的成敗。
智能產品有時候可以找到官方的定義，這時候就可以直接應用，比如說火車號，火車號是有準確定義的，參考如下：
高鐵：G1-G9998、C1-C9998、D1-C9998、Z1-Z9998、T1-T9998、K1-K9998
普通火車：1001-5998、6001-7598、7601-8998、Y1-Y998
如果沒有明確的定義，那么就需要自己抽象出產品的定義，用于指導后續的流程，有以下幾種方法：規則法、范圍法、枚舉法，下面一一敘述。
1. 規則法
上面描述的“我喜歡你”的定義，就是規則法的應用。規則法有兩步：收集樣本、歸納規則。
再舉一個例子，比如說什么是地址，這個乍一看，大家可能都比較好識別，但是怎么描述地址呢？我找了一圈也沒有找到官方的定義；所以我就跑到出現地址的地方，比如地圖、美團等應用，收集了周圍的地址，然后可以總結出來規則的一般形式有以下幾種：
1）長地址由以下的組成：
- 可以有 xx省、xx自治區、xx特別行政區或者沒有；
- 需要有 xx 市；
- 可以有xx區、xx縣、xx市或者沒有；
- 可以有xx鎮、xx街道或者沒有；
- 可以有xx村、xx鄉或者沒有；
- 需要有xx街 或 xx路 或 xx道 或 xx巷 或 xx弄 或 xx園；
- 需要有xx號；
- 可以有 與xxx（比如與海德二路交匯處） 或 xx號；
2）特殊位置（工廠、工業園、產業園、科技園、科學園、公園、寫字樓、小區）。
注意有一點，規則法的重點在于定義的范圍是準確的，求準不求全；規則法得來的定義，通常都是不完整的，不過沒關系，這個定義在后續的執行過程中，都可以隨時更新的。
2. 范圍法
范圍法的運用在智能產品的定義可能比規則還要寬泛，規則的難點在于怎么抽象，而范圍法在在于怎么劃定最終的范圍。
舉個簡單的例子，我們要識別餐館，這個東西的定義就感覺完全找不到頭腦；“小炳勝”可以是一個餐館（當然也可能是人名），“張三餃子”也可以是一個餐館，這個完全沒有規律可言，這時候可以從整個流程的末端入手。
識別是我們最開始的目的，我們最終的目的其實是為了提供給用戶對應的內容或者服務；對于餐館，我們提供內容其實是餐館的詳情，比如餐館的評分啦，地址之類的。這些評分從哪里來呢？美團，大眾點評都可以。
那么現在問題就比較簡單了，我們直接將前后兩個環節串起來，“餐館”的定義就可以定義成“大眾點評下美食類目下的店鋪”，定義簡單明了；后續需要驗證也比較簡單，直接去大眾點評搜索一下就可以了。
3. 枚舉法
枚舉的意思是，針對有限的個數的類別，可以把這個類別的所有個體一一列舉出來，這個叫枚舉；比如，請枚舉10以內的自然數，那么答案就是：0/1/2/3/4/5/6/7/8/9。
枚舉法在智能產品里用到得比較少，不過我也用過；我們有一次遇到的情況是要識別我們內部自定義的一個新品牌，這時候我們就直接把品牌名稱當成特征給到模型，定義也很簡單，就是包含品牌名字時，我們都認為符合產品定義，然后就突出對應的百科介紹。
枚舉出來的當然非常識別率非常高，不過相對應的適用范圍也比較少。
三、樣本標注的確定性
產品定義完了，和開發測試進行評審，大家達成一致，就可以開始繼續往下的工作了。前面講了，很多智能產品都是監督學習，依賴已經知道了分類的樣本。
那么怎么才能知道這些分類呢？
答案就是人工去標注，然后把標注完的結果給機器，相當于給機器一個受教育學習的過程；所以人工標注得好不好，決定了模型學習得好不好；就好比，你如果告訴學生“燒殺搶掠”是美德，那么他們就很大可能會變成流氓惡霸；如果告訴他們要做“謙謙君子”，那么他們就會變成另外一副模樣。
下面講講怎么保證樣本標注的準確性。
1）產品定義
樣本的標注，通常會有一個標注團隊，這是智能產品團隊的標配；如果沒有專門的標注團隊，那么通常是由測試兼任。
由于產品定義和標注不是同一個人，所以就要求產品定義要非常清晰，準確，可以用于指導標注工作的進行。
產品定義的時候，可以和團隊的其他成員充分討論，特別是之前有過相關經驗的同事，可以查漏補缺。具體可以參考前面【產品定義的準確性】的相關內容。
2）澄清評審
和其他需求一樣，定義完之后也需要有一次正式的澄清，或者叫評審；澄清的目的是為了給大家講清楚產品的定義，在講的過程中，相關的成員會比單純的看感受更深，更能激發討論；澄清的時候，可能還有引起一波新的討論，討論越多，對于產品的定義就會更加清晰，團隊也更加能達成共識。
3）樣本采集
明確了標準之后，還缺失一個東西，樣本的采集。
通常來講，一個品類至少要有50個以上的樣本，才能用于訓練；當然更好的是可以達到100個以及以上，視不同的情況而定，這個通常會由算法工程師給出來。
那么這些樣本從哪里來呢？
一個是研究機構公開的樣本庫，通常是國外機構官網可能會有，可以谷歌一下；不過學術領域和工程領域的差別有點大，不一定適用。
第二個是其他機構的售賣，這種可以走商務關系進行聯系。
第三種就是自行爬蟲爬取，通常是工程師根據產品的定義去爬取，然后清洗，最后形成可用的樣本。
4）預標注
標準有了，樣本有了，還需要先進行一輪預標注的過程；預標注可以先每種類別選取10個左右的樣本，先進行標注，用于討論用；這個環節的作用在于，有時候我們覺得我們已經知道了，但是真正開始上手的時候，才知道自己的無知，這個就是為了預防這種情況的出現；先標注一部分，然后和團隊討論，防止標注團隊在錯誤的道路上越走越遠，最后一發不可收拾，這個就是這個環節最大的作用。
5）充分討論
針對預標注的結果進行討論，首先產品肯定需要校驗是否符合自己的定義，其次，開發也可以從第三方視野給予建議和意見；還有就是前面說了，除開官方的規則定義，其他規則都是保準而不保全，那么就有可能有一些漏掉的，或者模棱兩可的地方；這個時候就可以統一討論清楚，大家明確了共識之后，該更新定義就更新定義，該繼續標注就繼續標注。
6）二次標注
為了節約時間成本，第二次標注就可以進行全量標注了；有了預標注和討論之后，第二次的標注普遍會更快更準。
7）抽樣驗證
針對全量標注的結果，產品經理還是需要進行抽樣檢查，如果發現抽樣的結果，比如抽查了10個，發現很多都標注不準確，這時候就需要打回去重新標注；如果標注結果沒什么大問題，就可以給算法工程師進行模型訓練了。
8）樣本充足
最后需要注意的一點是，前面講的50~100是一次訓練的樣本量，如果模型需要經過幾次的迭代的話，每次都需要這么多樣本量；因為如果每次都逮著一批樣本的話，可能會造成一種“過擬合”的現象，就是說模型針對這一批樣本，效果非常好，但是卻喪失了普遍性，導致對于其他樣本結果很差。
就類似如果對學生過分強調數學的重要性，有可能就會造成學生偏科一樣；所以樣本的數量要充足到可以支撐整個模型訓練的全過程，保證最后的模型具備普適性。
四、模型指標的確定性
智能產品沒正式上線之前，誰都不知道具體的效果會怎么樣。唯一知道的就是模型的指標如何，模型指標和上線標準是必要但不充分的關系；也就是說，模型指標好，上線效果大概率好，但是也可能不好；但是如果模型指標不好，那么上線效果一定會差。
智能產品的模型一般有幾個指標：精確率（precision）、召回率（recall）和F1值（F1-Measure）【1】。
- 精確率可以定義為查準率，比如想要預測景點，那么就需要拿預測為景點并且真的是景點的樣本數量，除以預測為景點的樣本數量。
- 召回率（真的好想吐槽這個翻譯，直譯過來，非常抽象，導致一直都記不住）可以定義為查全率；同樣以景點為例，分子是預測為景點并且真的是景點的樣本數量，分母是所有景點的樣本數量。
- F1值是這兩個值的加權，有興趣可以戳最后的鏈接了解【1】。
精確率和召回率是互斥的，如果想要提高精確率，那么就可能對召回率有點影響；反過來也一樣，舉個極端的例子，如果我把所有的預測結果都預測成景點，那么召回率就是100%，但是精確率就會很慘。
對于產品模型的指標，精確率和召回率通常表現出來就是兩個百分數，一般來講，雙80%我們覺得比較適合的上線標準，雙90%是比較優秀的標準，當然具體數值還是需要和團隊內部達成一致來確定；這個數值是非常確定的，確定完標準之后，整個團隊都需要按照目標一直迭代進步；指標達不到，最好不要上線，否則效果很差，這個是需要產品經理把關好的。
還有一點要注意的是，模型的指標還依賴模型的維護，上線之后，充分吸收真實環境下的結果反饋，有利于提升模型的指標；如果長時間不維護，那么大部分的模型都會越來越不準確。
五、產品指標的確定性
前面講了，對于智能產品而言，模型的數據不等同于真實上線的數據，他們是必要不充分的關系。模型的指標數據可以當做是開發給你交付的結果的衡量；但是對于產品而言，更加重要的是要制定自己給公司的交付物以及對應衡量的指標。
產品指標需要是確定的并且是正確的，可以指導產品朝著指定的方向前進。
產品指標在不同階段可能不同，比如在啟動期或者爆發期，可能以活躍量作為指標，用戶量大的才能存活下去。
產品成熟期，一般會以營收作為指標，營收才是產品能給公司提供的價值；衰減期的時候，要更加注重留存，盡量延長產品的生命周期，多給公司增加營收。
在特定階段，一個產品的指標有很多，但是核心指標一般不會很多，這幾個核心指標可以指引產品前進的方向。
通用指標：
- 營收相關指標：我能掙多少錢，這個對于公司來講尤為重要，比如說GMV、收入、CPM等；
- 活躍相關指標：雖然我現在不能掙錢，但是我可以把盤子做大，然后再考慮掙錢或者給其他業務導流，比如說：活躍、留存等；
領域指標：
- 電商類產品通常用到的核心數據指標有：「首單率」、「客單價」、「復購率」、「退款率」等；
- 社區類產品通常用到的核心數據指標有：「活躍用戶數」、「帖子發布數」、「互動用戶數」、「用戶對話數」、「留存率」等；
- 內容類產品通常用到的核心數據指標有：「用戶停留時長」、「跳出率」、「用戶互動比率」、「留存率」等；
- 工具類產品通常用到的核心數據指標有：「打開率」、「使用頻次」、「目標達成率」、「分享率」等；
- 游戲類產品通常用到的核心數據指標有：「活躍用戶數」、「用戶在線時長」、「付費用戶比率」、「留存率」等；
我的產品的指標：
轉化率：從產品的工具屬性出發，這個指標能證明提供的服務是契合用戶需求的，是產品最核心的指標，同時也是可以牽引整個團隊前進的指標，轉化率越高，說明我們預估的越準；
活躍量：從產品的內容屬性出發，如果活躍量達不到一定值，那么就無法吸引更多的CP來接入，就無法提供更多的服務；這個和轉化率存在矛盾性，比如活躍多了，轉化可能下降，所以要求團隊要在活躍量增長的情況下，維持轉化率不變或者稍微只降低一點點。
當然，還要保證【活躍量*轉化率】的不斷提升，才能預示著產品在不斷向好發展。
六、預測反饋的確定性
數據指標有利于牽引整體產品向既定方向去前進，但是這種牽引只給了方向，沒有給確切的方法，所以實操起來還需要有一些輔助。
模型的優化，雖然很大程度上依賴于算法工程師的努力；之前講了，算法工程師也需要依賴樣本的準確性，而依靠標注而來的樣本始終是有限的，所以可以把這個標注融入到產品中，這就是結果的反饋系統。
沒有反饋系統的流程
有反饋系統的流程
通過上面的圖可以看到，反饋系統增加了一個自下而上的渠道，通過將用戶的反饋加入到整個流程，可以幫助算法工程師優化識別算法，以提升下一次識別結果的準確率；同時，如果用戶還可以提供更加具體的產品意見的話，也可以幫助提升產品。
最后，反饋系統還是一個負向情緒的宣泄入口，用戶可以有地方宣泄自己的不滿，不至于覺得心里憋屈。
綜上，我覺得不僅是智能產品，所有產品都應該考慮嵌入一個反饋系統。
反饋系統需要考慮用戶的接受程度：淺層反饋系統就是好評和差評；中層反饋系統就是好評，+選擇差評原因；深層反饋系統就是：好評+填寫差評原因。
1. 淺層反饋系統
淺層反饋系統
舉一個簡單的例子，上述是知乎的一個回答，上面的“贊同”和“反對”就是一個最淺層的反饋系統，用戶可以表達自己對于回答的正向或者負向的情緒。
知乎收到用戶的反饋之后呢，如果贊同數很多，反對數很少，那么會認為這是一個好的回答，下次有可能就會推薦給更多的用戶。
這個系統同樣也適用于我的產品，如果用戶贊同了我們推薦的服務，那么可能是我們識別對了用戶的意圖，那么算法就可以做對應的調整；反之，如果是反饋了我們的服務，那么算法同學就要分析錯誤的原因，下次做修正。
2. 中層反饋系統
淺層反饋系統有個缺點，舉個例子，如果我們識別到用戶想去餐館，然后推薦了了美團對應的服務；然后此時用戶給了反對，那么有可能有如下幾個原因：a.我們識別錯了用戶意圖；b.我們識別對了，但是用戶想看大眾點評的結果；c.流程沒問題，但是用戶覺得響應太慢了。
諸如此類的原因分解可以有很多個，那么簡單的反對就沒辦法完整傳達用戶的意思，也可能造成誤解；這時候，可以把可能的原因列出來，注意不能多，大概3~5個，多了你就列為“其他”就可以了。
上圖就是一個典型的中層反饋系統，只列了3個原因，可以有效區分問題類型，把算法問題（內容錯誤或者不合理）篩選出來，幫助算法提升。
3. 深層反饋系統
在中層反饋系統中，用戶只有“選擇權”，但是“表達權”還缺少了一些，用戶無法暢所欲言，所以從用戶哪里獲取的信息就只會局限于實現限定的幾類。
深層反饋系統可以讓用戶暢所欲言，比如以下，一般還是有兩個步驟：
- 篩選反饋類型：這個還是需要做得，方便后期的篩選工作；
- 填寫用戶反饋語言，用戶分析用戶的意圖；
可以參考下面微信的例子，不過微信體量大，做到這么復雜都還是有比較多的反饋量，一般產品還是掂量一下自己的分量再學習。
4. 反饋報告
上述反饋系統都是用戶層面的，說點業務層面的。用戶反饋的時候，可以附帶一個叫“錯誤報告”之類的東西，這個可是一個寶藏。
錯誤報告可以上傳一些信息，幫助分析用戶狀態，比如：
- 系統版本號
- 客戶端版本號
- 用戶所在的場景（比如哪個APP）
- 所觸發的文字
- 預測的結果
這些可以有效還原用戶的場景，幫助分析用戶的意圖，結合用戶的反饋，可以達到更好的分析效果；當前需要注意，一切用戶的數據獲取都需要合法合規。
總結一下，預測反饋的確定性：明確用戶的意圖、明確用戶的場景；這兩點越明確越好，越能助力產品提升準確率。
七、尾聲
智能產品的不確定性或許一開始會讓人感到痛苦，不過仔細分析下來，玩法還是比普通產品多很多的；不過智能產品也有一個特點，就是見效慢，算法周期動輒幾個月，所以還需要有足夠的耐心去和自己負責的產品一起成長。
#專欄作家#
妖葉秋，交互設計師，人人都是產品經理專欄作家。做過ToC產品的交互設計，現在在嘗試ToB的業務。主攻交互，也懂點用研、視覺和產品的知識。愛生活、愛設計、愛讀書、愛總結，頭像下方是我的聯系方式，歡迎志同道合者與我交流。
本文原創發布于人人都是產品經理，未經許可，不得轉載。
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
