智能產品的不確定性 尾聲

最近半年負責了一款智能領域相關的產品,主要是通過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.1 可以有 xx省、xx自治區、xx特別行政區或者沒有

1.2 需要有 xx 市

1.3 可以有xx區、xx縣、xx市或者沒有

1.4 可以有xx鎮、xx街道或者沒有

1.5 可以有xx村、xx鄉或者沒有

1.6 需要有xx街 或 xx路 或 xx道 或 xx巷 或 xx弄 或 xx園

1.7 需要有xx號

1.8 可以有 與xxx(比如與海德二路交匯處) 或 xx號

2. 特殊位置(工廠、工業園、產業園、科技園、科學園、公園、寫字樓、小區)

注意有一點,規則法的重點在於定義的範圍是準確的,求準不求全。規則法得來的定義,通常都是不完整的,不過沒關係,這個定義在後續的執行過程中,都可以隨時更新的。

範圍法

範圍法的運用在智能產品的定義可能比規則還要寬泛,規則的難點在於怎麼抽象,而範圍法在在於怎麼劃定最終的範圍。舉個簡單的例子,我們要識別餐館,這個東西的定義就感覺完全找不到頭腦。“小炳勝”可以是一個餐館(當然也可能是人名),“張三餃子”也可以是一個餐館,這個完全沒有規律可言,這時候可以從整個流程的末端入手。識別是我們最開始的目的,我們最終的目的其實是爲了提供給用戶對應的內容或者服務。對於餐館,我們提供內容其實是餐館的詳情,比如餐館的評分啦,地址之類的。這些評分從哪裏來呢?美團,大衆點評都可以。

那麼現在問題就比較簡單了,我們直接將前後兩個環節串起來,“餐館”的定義就可以定義成“大衆點評下美食類目下的店鋪”,定義簡單明瞭。後續需要驗證也比較簡單,直接去大衆點評搜索一下就可以了。

枚舉法

枚舉的意思是,針對有限的個數的類別,可以把這個類別的所有個體一一列舉出來,這個叫枚舉。比如,請枚舉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%是比較優秀的標準。當然具體數值還是需要和團隊內部達成一致來確定。這個數值是非常確定的,確定完標準之後,整個團隊都需要按照目標一直迭代進步,指標達不到,最好不要上線,否則效果很差,這個是需要產品經理把關好的。

還有一點要注意的是,模型的指標還依賴模型的維護,上線之後,充分吸收真實環境下的結果反饋,有利於提升模型的指標,如果長時間不維護,那麼大部分的模型都會越來越不準確。

產品指標的確定性

前面講了,對於智能產品而言,模型的數據不等同於真實上線的數據,他們是必要不充分的關係。模型的指標數據可以當做是開發給你交付的結果的衡量,但是對於產品而言,更加重要的是要制定自己給公司的交付物以及對應衡量的指標。產品指標需要是確定的並且是正確的,可以指導產品朝着指定的方向前進。

產品指標在不同階段可能不同,比如在啓動期或者爆發期,可能以活躍量作爲指標,用戶量大的才能存活下去。產品成熟期,一般會以營收作爲指標,營收纔是產品能給公司提供的價值。衰減期的時候,要更加註重留存,儘量延長產品的生命週期,多給公司增加營收。

在特定階段,一個產品的指標有很多,但是核心指標一般不會很多,這幾個核心指標可以指引產品前進的方向。

通用指標:

1. 營收相關指標:我能掙多少錢,這個對於公司來講尤爲重要,比如說GMV、收入、CPM等;

2. 活躍相關指標:雖然我現在不能掙錢,但是我可以把盤子做大,然後再考慮掙錢或者給其他業務導流,比如說:活躍、留存等;

領域指標:

1、電商類產品通常用到的核心數據指標有:「首單率」、「客單價」、「復購率」、「退款率」等;

2、社區類產品通常用到的核心數據指標有:「活躍用戶數」、「帖子發佈數」、「互動用戶數」、「用戶對話數」、「留存率」等;

3、內容類產品通常用到的核心數據指標有:「用戶停留時長」、「跳出率」、「用戶互動比率」、「留存率」等;

4、工具類產品通常用到的核心數據指標有:「打開率」、「使用頻次」、「目標達成率」、「分享率」等;

5、遊戲類產品通常用到的核心數據指標有:「活躍用戶數」、「用戶在線時長」、「付費用戶比率」、「留存率」等;

我的產品的指標:

1. 轉化率:從產品的工具屬性出發,這個指標能證明提供的服務是契合用戶需求的,是產品最核心的指標,同時也是可以牽引整個團隊前進的指標,轉化率越高,說明我們預估的越準;

2. 活躍量:從產品的內容屬性出發,如果活躍量達不到一定值,那麼就無法吸引更多的CP來接入,就無法提供更多的服務。這個和轉化率存在矛盾性,比如活躍多了,轉化可能下降,所以要求團隊要在活躍量增長的情況下,維持轉化率不變或者稍微只降低一點點。當然,還要保證【活躍量*轉化率】的不斷提升,才能預示着產品在不斷向好發展。

預測反饋的確定性

數據指標有利於牽引整體產品向既定方向去前進,但是這種牽引只給了方向,沒有給確切的方法,所以實操起來還需要有一些輔助。模型的優化,雖然很大程度上依賴於算法工程師的努力。之前講了,算法工程師也需要依賴樣本的準確性,而依靠標註而來的樣本始終是有限的,所以可以把這個標註融入到產品中,這就是結果的反饋系統。

通過上面的圖可以看到,反饋系統增加了一個自下而上的渠道,通過將用戶的反饋加入到整個流程,可以幫助算法工程師優化識別算法,以提升下一次識別結果的準確率。同時,如果用戶還可以提供更加具體的產品意見的話,也可以幫助提升產品。最後,反饋系統還是一個負向情緒的宣泄入口,用戶可以有地方宣泄自己的不滿,不至於覺得心裏憋屈。綜上,我覺得不僅是智能產品,所有產品都應該考慮嵌入一個反饋系統。

反饋系統需要考慮用戶的接受程度:淺層反饋系統就是好評和差評;中層反饋系統就是好評,+選擇差評原因;深層反饋系統就是:好評+填寫差評原因。

淺層反饋系統

舉一個簡單的例子,上述是知乎的一個回答,上面的“贊同”和“反對”就是一個最淺層的反饋系統,用戶可以表達自己對於回答的正向或者負向的情緒。知乎收到用戶的反饋之後呢,如果贊同數很多,反對數很少,那麼會認爲這是一個好的回答,下次有可能就會推薦給更多的用戶。這個系統同樣也適用於我的產品,如果用戶贊同了我們推薦的服務,那麼可能是我們識別對了用戶的意圖,那麼算法就可以做對應的調整;反之,如果是反饋了我們的服務,那麼算法同學就要分析錯誤的原因,下次做修正。

中層反饋系統

淺層反饋系統有個缺點,舉個例子,如果我們識別到用戶想去餐館,然後推薦了了美團對應的服務。然後此時用戶給了反對,那麼有可能有如下幾個原因:a.我們識別錯了用戶意圖;b.我們識別對了,但是用戶想看大衆點評的結果;c.流程沒問題,但是用戶覺得響應太慢了;諸如此類的原因分解可以有很多個,那麼簡單的反對就沒辦法完整傳達用戶的意思,也可能造成誤解。這時候,可以把可能的原因列出來,注意不能多,大概3~5個,多了你就列爲“其他”就可以了。

上圖就是一個典型的中層反饋系統,只列了3個原因,可以有效區分問題類型,把算法問題(內容錯誤或者不合理)篩選出來,幫助算法提升。

深層反饋系統

在中層反饋系統中,用戶只有“選擇權”,但是“表達權”還缺少了一些,用戶無法暢所欲言,所以從用戶哪裏獲取的信息就只會侷限於實現限定的幾類。深層反饋系統可以讓用戶暢所欲言,比如以下,一般還是有兩個步驟:

1.篩選反饋類型:這個還是需要做得,方便後期的篩選工作;

2. 填寫用戶反饋語言,用戶分析用戶的意圖;

可以參考下面微信的例子,不過微信體量大,做到這麼複雜都還是有比較多的反饋量,一般產品還是掂量一下自己的分量再學習。

反饋報告

上述反饋系統都是用戶層面的,說點業務層面的。用戶反饋的時候,可以附帶一個叫“錯誤報告”之類的東西,這個可是一個寶藏。

錯誤報告可以上傳一些信息,幫助分析用戶狀態,比如:

系統版本號

客戶端版本號

用戶所在的場景(比如哪個APP)

所觸發的文字

預測的結果

這些可以有效還原用戶的場景,幫助分析用戶的意圖,結合用戶的反饋,可以達到更好的分析效果。當前需要注意,一切用戶的數據獲取都需要合法合規。

總結一下,預測反饋的確定性:一是明確用戶的意圖;二是明確用戶的場景。這兩點越明確越好,越能助力產品提升準確率。

尾聲

智能產品的不確定性或許一開始會讓人感到痛苦,不過仔細分析下來,玩法還是比普通產品多很多的。不過智能產品也有一個特點,就是見效慢,算法週期動輒幾個月,所以還需要有足夠的耐心去和自己負責的產品一起成長。


【1】準確率、精確率、召回率、F1值、ROC/AUC整理筆記https://blog.csdn.net/u013063099/article/details/80964865

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章