第一部分，首先回顧一下 AI 助手的發(fā)展歷史。

這里引用了清華大學黃民烈老師分享的總結材料，他也是小布學術顧問委員會的核心成員之一。

從上圖中可以看到，對話助手的發(fā)展歷史非常悠久。早在 1966 年 MIT 開發(fā)了基于規(guī)則驅動的系統(tǒng)，面向心理咨詢場景。2011 年，蘋果發(fā)布了 Siri，在工業(yè)界引起了廣泛關注，是一個重要里程碑。微軟 2014 年推出小冰，主打智能聊天，后續(xù)也擴充了各種好玩的技能。近幾年隨著大規(guī)模訓練技術的發(fā)展，谷歌、Facebook、百度等頭部玩家都發(fā)布了基于大規(guī)模預訓練的端到端對話模型，將開放域對話的能力水平推向新高度。目前在一些產(chǎn)品上，大模型的聊天水平在特定場景下已經(jīng)不遜于人類表現(xiàn)，非常驚艷。

AI助手這個方向的用戶和從業(yè)者很容易受科幻大片的影響，在心里種下超能 AI助手的影子。前一段時間還在和同事討論這個問題，比如很早很早之前有一部美劇叫《霹靂游俠》，男主有一輛特別厲害的車，擁有堪稱完美的自動駕駛和AI助理功能，男主角和他的車一起穿梭在各種險境之中懲奸除惡，特別讓人羨慕。然后另外兩個典型的超級 AI 助理大家應該都非常熟悉了，鋼鐵俠的賈維斯和超能特戰(zhàn)隊的大白。這些科幻片雖然夸張，但還是非常清晰地描繪了 AI 助手這個方向的夢想。

與此同時，這也會帶來一些麻煩，用戶全被科幻片教育了，然后當發(fā)現(xiàn)夢想和現(xiàn)實的巨大差距的時候，都忍不住罵一句“智障”！這也是在這個方向經(jīng)常要面對的尷尬，但是夢想一定會實現(xiàn)的，而且隨著近幾年技術的高速發(fā)展讓它變得越來越可期待。

02

小布的誕生

接下來對小布助手的背景進行介紹。

小布助手是面向 OPPO 集團公司下的 3 個品牌手機和 IoT 設備打造的新一代AI助手。你完全可以把它類比成蘋果設備上的Siri，只不過它目前是專門為 OPPO 自家的設備服務的。

那么小布助手能幫用戶做什么呢？通過小布助手，我們希望能夠在用戶和設備之間建立一種對話式的連接，讓用戶使用設備和服務更方便。目前小布已經(jīng)支持的技能包括操作控制類的、影音娛樂類的、生活服務類的、信息查詢類的、智能聊天等，覆蓋了行業(yè)內(nèi)常見的所有對話技能。

這是小布的成長記錄。

最早這個產(chǎn)品是 2019 年開始上線，先是手機，然后是手表、電視等更多設備。在去年 2 月份月活突破 1 個億，這是一個非常重要的里程碑。然后去年 10 月份，開始往多模態(tài)方向發(fā)展。到今年 8 月份的時候，我們發(fā)布了一個大版本 4.0，有更多的新功能上線。

這是目前小布助手的核心數(shù)據(jù)。

龐大的用戶規(guī)模是這個產(chǎn)品的主要特征之一，目前已經(jīng)覆蓋了 3 億的用戶，最新月活也達到 1.4 億，每個月有 30 億次以上的交互量。

當然，這么大的用戶量和交互量也給技術的工作帶來了很多挑戰(zhàn)，后面會詳細介紹。

小布的演進

這部分重點介紹過往幾年在打造小布助手的過程中我們有哪些思考，以及針對這些思考所做的具體實踐。

1. 小布演進的思路

針對小布的用戶，我們的產(chǎn)品經(jīng)理做過很多調(diào)研、訪談和分析。數(shù)據(jù)表明用戶的需求是非常多樣的，覆蓋了很多差異化的場景。如果將需求從基礎到高階的方式分層，可以分為三個層次：

• 第一層主要解決效率問題，希望能方便、快捷的幫助用戶完成日常的簡單任務。比如：系統(tǒng)的操作控制、定鬧鐘、設置日程等。注重工作效率的用戶會比較喜歡這類的功能。

• 第二層中除了簡單的操作之外，希望系統(tǒng)可以更智能，更好的了解用戶的習慣、偏好，知道用戶對哪些內(nèi)容感興趣。除了被動的交互之外，希望系統(tǒng)可以給用戶主動的推送。

• 在第三層希望系統(tǒng)跟人一樣，像之前提到的擬人化的交互，滿足用戶的情感需求。比如，在用戶比較郁悶的時候可以陪用戶聊聊天；甚至可以成為用戶的知心朋友，在用戶不開心的時候給他一些寬慰和鼓勵。

這其中有些需求是當下技術完全可以做到的，也有一些很難做好。受科幻片的影響，有不少用戶對機器人的預期很高，這也為構建用戶滿意的產(chǎn)品帶來很大挑戰(zhàn)。

小布的演進思路，大致可以理解成從技能建設到反智障，再從反智障到懂用戶這樣的路徑。最基礎的是你得有足夠豐富的技能，能幫用戶做各種各樣的事，特別是得能支持剛需的場景。然后是得讓用戶感受到智能性，不能有太多的低級缺陷，不能太“智障”。最后還得讓用戶覺得你懂他，給他提供的服務是適合他的，也能和他聊的下去，建立某種情感鏈接。

后面的內(nèi)容主要圍繞小布的技能建設、反智障的方案、讓小布更懂用戶這幾部分展開。

2. 小布演進-技能建設

上圖是小布目前已有的技能概況。目前小布有 300 多個技能，對應 2500 多個細分意圖。從技能維度來看，技能量不算多。但真實場景中，技能對應的用戶量會呈現(xiàn)非常明顯的頭部效應，這 300 多個技能已經(jīng)覆蓋了 95% 以上的用戶需求。我們希望通過開放平臺的形式讓更多開發(fā)者以低成本的方式自助接入和建設更多技能。

從技能類別來看，主要包含指令型、信息獲取類、知識依賴類、聊天類、文字游戲類等。

• 在手機上，指令類的技能相對剛需，它可以解決用戶對效率的訴求，對用戶幫助很大。比如用戶在手機上安裝了很多 APP、或手機的一些入口比較深的設置項，通過語音直達的方式可以方便用戶更快速觸達功能點。

• 在電視類設備上，音樂、影視點播技能比較剛需。一方面，遙控器會容易找不到；另外，遙控器輸入法一般都不太好用，輸入比較費勁。語音的方式對于找片、搜片會特別方便。

• 開放域的聊天和知識問答的交互量很大，難度也比較高。用戶的需求會比較發(fā)散，范圍也比較廣。這部分就會比較難處理，后面也會介紹這部分的工作。

接下來介紹一下在技能建設過程中面臨的難點。特別是在疊加規(guī)模效應以后，會讓問題變得更加棘手。舉幾個例子：

• 第一個是語義理解。這個問題目前還沒有完美的解決方案，當面臨大量用戶口語化的表達時，總會出現(xiàn)各種各樣的 Badcase，這一點相信長期做 NLP 技術研發(fā)的伙伴可能都有體會。

• 第二個是開放域對話范圍比較廣。這里主要是指聊天和知識問答。對于聊天，用戶希望你能解悶，還希望你能安慰人，甚至希望你能陪它玩；知識問答包含的領域也很廣，什么問題都可能被問到，比如以小布為例，每個月能收集到的不重樣的問題得到千萬級以上，非常的發(fā)散和長尾。

• 第三個是效果優(yōu)化高度依賴人工。對話交互不像搜索、推薦場景，可以快速收集高質(zhì)量的反饋數(shù)據(jù)形成閉環(huán)，高效完成優(yōu)化。有一句調(diào)侃AI的玩笑，“有多少人工，就有多少智能”。雖然是玩笑調(diào)侃，但在對話的場景中也部分反應了目前的真實現(xiàn)狀。

• 第四個對于海量用戶，需要考慮模型的應用成本。目前模型的參數(shù)量像是打開了潘多拉魔盒，參數(shù)量扶搖直上，量級從億級到十億、百億、萬億級別。但應用這些模型進行推理的成本是很高的。如果這些問題未能得到解決，應用復雜模型的成本還是非常高的。

前面提到的這些是我們體會比較深的在技能建設中需要解決的難題。針對其中的部分問題，我也會著重介紹一下小布在演進過程中積累的一些實踐方案。

之前提到的系統(tǒng)開關、APP 控制都可以通過指令型技能完成。這類技能的特點是用戶 Query 的本身包含了比較豐富的語義信息和信號，有比較強的信息輸入將其結構化為意圖和槽位。此外，意圖和槽位之間也有比較強的關聯(lián)關系。我們采取了融合規(guī)則和多任務深度學習的方案。一方面，通過規(guī)則降低一些計算量的開銷。算法對于標準問法的識別準確率是非常高的。另一方面，引入多任務的深度學習模型也會兼顧意圖和槽位的關聯(lián)。這也是一個經(jīng)典的解決方案，可以很好的解決誤差累計的問題，能夠取得更好的效果。

結合小布實際的業(yè)務經(jīng)驗，使用數(shù)據(jù)驅動優(yōu)化和比較完善的規(guī)則校驗，再加深度學習的方式在指令型的技能上基本可以做到 95% 以上甚至更高的的召準率。

第二類是知識依賴型的技能，比如剛剛提到的音樂、影視等技能。單從用戶 Query很難判斷該 Query 屬于哪個技能。這類 Query 包含的實體信息有它自己的知識屬性，在判定知識所屬的類別之后，才能準確判定該 Query 所對應的技能。

比如，用戶說“你幫我放個原子彈”或“你幫我放個炸彈”。沒有背景信息的話，很難判斷對應的技能?！霸訌棥焙汀罢◤棥倍际歉枨拿帧ａ槍@些問題，我們采用了先做實體識別和鏈接，后做意圖識別判斷的方案，這樣可以有效的融合知識，最終獲得更精準的結果。

接下來介紹兩個開放域的場景。

開放域知識問答場景占到小布交互量的 15% 左右，屬于比較剛需的場景。知識問答可以看成搜索引擎的一種終極形態(tài)的期望。它可以直接給用戶簡短精準的答案，這也是用戶使用它的原因之一。針對這種開放域的知識問答問題，我們將其拆分為幾個不同的場景進行處理。

• 第一種是相對比較封閉的問題，比如：星座、交通限行相關的問題。這類問題目前是通過定制技能來解決的，效果相對也會更可控一些。

• 第二類是事實型的比較客觀的開放型問題，比如：問東京奧運會金牌得主是誰？這種我們是通過自建的知識圖譜，以及對一些結構化問題的解析轉化成圖譜來實現(xiàn)。這種方式的優(yōu)點是可以把答案做的特別精準。目前系統(tǒng)支持簡單的單跳和復雜的多跳場景。

• 第三種最復雜，屬于既開放又比較長尾的問題。目前通過檢索式、結合知識庫的方式來解決。在這種情況下，知識庫的構建就非常重要。除了人工構建，我們采用一些半自動化挖掘的方案，比如基于語義理解的一些方案。從去年開始，我們也引入了一些基于生成式大模型的方案探索，希望更高效的構建知識庫，且產(chǎn)生的知識庫的內(nèi)容也更優(yōu)質(zhì)。

另外一個開放域的場景是聊天。在手機設備上，智能聊天是占比最高的需求。一方面是因為用戶喜歡調(diào)侃語音助手，尤其是一些新用戶。另一方面，聊天貫穿在對話的整個過程中，在某種程度上是對話的潤滑劑。有部分用戶會有傾訴的需求，不方便跟周圍的人說。他們希望把小布當做樹洞，通過這種更安全的方式來溝通。

針對聊天場景，我們使用了檢索式、生成式以及記憶的方式融合的方案。檢索式大家比較熟悉，需要注意的是隨著近幾年預訓練模型的發(fā)展，在檢索匹配的時候我們引入了比較多的基于預訓練大模型的方案，希望可以把語義表征學習的更好一些，使得檢索更精準。因為檢索的范圍是有限的，要把開放域做的比較好，生成式已經(jīng)必不可少。這里我們采用了 UniLM 和 1vN 建模的模型，從而生成可控且相關的高質(zhì)量的回復。這里比較大的風險在于生成式的安全性。針對這個問題，我們做了很多 Query 安全性、答案安全性、Query 和答案組合安全性的控制機制。

為了讓聊天變得更有趣、有用，我們特別研發(fā)了記憶的能力，希望在聊天的過程中記住一些用戶主動提供、或用戶提到的一些信息，從而影響未來聊天的內(nèi)容。目前小布已經(jīng)支持記憶很多信息，比如：位置、節(jié)日、紀念日等，這部分的范圍也在逐步擴大。

3. 小布演進-反智障

接下來介紹一下對話助手建設不得不面對的問題，即：如何讓AI助手表現(xiàn)得不那么智障。這里面的主要問題就是：對于任何一個很小的低級錯誤，在實際用戶體驗中都可能會被放大，尤其是小布這種用戶體量非常大的 C端產(chǎn)品。要在行業(yè)中存活下來，讓系統(tǒng)具有反智障的能力是非常重要的。

針對反智障，我們的第一個抓手是技術升級，因為它可以帶來大影響面的效果提升。前面提到小布誕生的比較晚，在 2018、2019 年這個時間階段，當時深度學習在 NLP 領域的應用已經(jīng)非常成熟，所以小布的技術體系也是以深度學習為主。因為小布的整個技術沒有傳統(tǒng)的歷史包袱，技術升級也會相對容易一些。這幾年預訓練的發(fā)展給技術升級帶來了紅利，我們也建設了從一億到十億的大參數(shù)模型的落地，從而促進小布在語言理解、泛化能力的提升，避免比較低級的問題。

模型包含多任務解碼的設計，從而對下游的適配性更強。另外，在通用語料的基礎上，我們疊加了特定領域對話的語料對模型進行持續(xù)的預訓練。此外，我們考慮了知識增強這個方向，使得模型對知識有更好的理解。在知識增強這個方面我們也會考慮用戶提到的實體相關的信息，將實體的信息關聯(lián)到實體相關的百科內(nèi)容中，讓模型在知識理解做的更好。

這里重點介紹一下面對大量用戶產(chǎn)生的交互流量如何控制大模型落地成本。否則，技術升級只能作為試點技術，不能進行大規(guī)模的推廣。針對這一問題，我們引入了統(tǒng)一表征的落地方案。在實際應用時，骨干網(wǎng)絡只計算一次。在下游應用時，骨干網(wǎng)絡的計算結果只需要微調(diào)少數(shù)的層次，就可以在效果沒有太大損失的情況下取的差不多的收益。這其實就是構造大模型的一次推理，同時解決下游 N 個任務運用的問題。計算量大概可以節(jié)約75%左右，這樣模型落地就不會有太大的問題。這也是我們的預訓練和提升反智障能力在工程落地方面做的重點事項。

在大模型實際落地應用的效果方面，為意圖識別方向帶來 2% 的質(zhì)量提升；在知識問答方向帶來的提升更大，有 4%。我們也會關注模型在同行業(yè)的競爭力，整體效果還是比較滿意的，特別是限制在可以工業(yè)化大規(guī)模應用，參數(shù)在十億級以下規(guī)模的體量下，模型的效果是很好的。

第二個反智障的舉措是自主缺陷發(fā)現(xiàn)與優(yōu)化。在實際的工業(yè)應用中，AI 助手的交互環(huán)境是非常復雜的，這會給語音識別和語義理解帶來很大的挑戰(zhàn)。對這類問題應對的不好，就會讓用戶覺得助手很不智能。另一方面，盡管沒有特別好的方式來獲得直接的用戶反饋，我們希望將 Case 收集更加自動化，全部依賴人工會導致效率低下。之前做過數(shù)據(jù)統(tǒng)計，盡管小布有內(nèi)外部多個人工收集渠道，但半年時間只積累了幾百個 Case，這對產(chǎn)品優(yōu)化是遠遠不夠的。迫切需要探索新的技術，比如半自動化、自動化的技術讓缺陷的發(fā)現(xiàn)和修復變得高效。

這里舉兩個收益比較大的實踐案例：

• 第一個是結合語音語義聯(lián)合的無效交互的拒識。用戶在使用小布助手的時候，背景通常不是特別安靜的，這里面會有很多環(huán)境噪音帶來的無效輸入。如果不對這類噪音進行識別和處理，就會導致助手的響應不可預期。因為噪聲對應的意圖是不真實的，不管做出什么樣的響應都是不合適的。此外，在很多情況下，通過噪聲識別出來的文字，人類都很難理解其對應的意圖，機器去理解和響應就更困難了。因此，考慮從源頭對噪音數(shù)據(jù)進行識別，并拒絕噪音數(shù)據(jù)。針對這一問題，我們引入語音 ASR 識別的文本信息作為輸入進行聯(lián)合建模，更精準的過濾無效輸入。我們嘗試過單獨文本的方案，受限于數(shù)據(jù)的損失，單獨文本與多模態(tài)聯(lián)合建模效果有較大的差距。

• 第二個是自動化語義缺陷挖掘與修復。希望綜合利用語義、非語義的信號，自動識別出助手回答錯的問題，通過半自動化、自動化的方式讓缺陷修復更加高效。我們設計了全套缺陷挖掘和優(yōu)化的流程，借助半監(jiān)督、主動學習的優(yōu)化手段，挖掘召回存在誤判的 Case，推進其進行校驗和優(yōu)化，這可以讓系統(tǒng)進入良性循環(huán)。目前覆蓋 85% 以上的技能，覆蓋意圖識別問題量的 48%，這種方式比人工優(yōu)化效率高了兩個數(shù)量級。

4. 小布演進-懂用戶

以上是反智障的一些工作。第三部分是怎么更好的懂用戶，這是最難的，也是未來最有想象空間的。懂用戶包括，懂用戶的屬性、用戶的行為以及用戶的情感。希望通過懂用戶給用戶帶來更貼心的產(chǎn)品體驗，認為這個助手是為他打造的。同時，通過提升用戶對助手的信任感，增加用戶粘性。有了用戶的信任感和粘性后，未來助手才會有更大的發(fā)展?jié)摿Α?/span>

小布在懂用戶方面還在持續(xù)的發(fā)展中，目前覆蓋基本屬性，針對這些屬性小布也可以做到記憶、提醒和影響后續(xù)部分對話交互的過程。整體還需要進一步的深入挖掘，這也是我們未來發(fā)展的重點方向之一。

此外，在懂用戶行為方面，我們也已經(jīng)做了一些探索和實踐。比如，我們發(fā)現(xiàn)有些用戶在需求未滿足時會通過換不同的說法、澄清的方式希望助手更理解自己；有些用戶會在小布犯錯的時候罵他，給小布負向反饋；也有用戶會在小布很好完成任務時給小布正向的激勵反饋，對小布說謝謝或夸贊。我們了解到不同用戶的行為后，也針對不同的用戶行為做反饋，提升小布的理解能力。

針對反復澄清的用戶，我們實現(xiàn)了自動化離線學習外加在線澄清的方案用來實現(xiàn)和滿足用戶需求。通過澄清的方式，猜測用戶意圖，最終幫助用戶達成訴求。這不僅對當前用戶是有效的，對相似的用戶場景也是通用的。

針對用戶的批評和表揚，我們也制定了小布的口碑滿意度體系，降低用戶對小布的不滿，提升用戶滿意度。

懂用戶另外一個重要的維度是和用戶共情。針對這一方向，小布做了一些情感引擎和情感理解的工作，識別和跟蹤用戶的情感變化，為用戶提供情感關懷方面的交互。目前還處于比較初級的階段?？偟膩碚f，在技術層面上理解用戶情感是相對可控的。但如何在理解的基礎上交互讓用戶感受更好，這一課題還需要更多的探索。

此外，在理解用戶的潛在需求方面，我們也希望有更多的工作落地。比如，用戶反饋被打了或者被批評了。我們希望可以通過交互的方式深刻的挖到背后的原因，結合原因再使用交互的方式去滿足用戶的潛在需求，從而對用戶有一些疏導。

未來展望

以上就是小布演進過程中，我們做的思考和實踐。AI 助手目前在非常高速的發(fā)展中，如果大家關注到一些頂級會議論文研究方向的分布，會發(fā)現(xiàn)對話助手相關的研究是非?；钴S的。這里對未來 AI 助手的未來方向做一個簡單的展望。

首先，AI 助手覆蓋的設備載體越來越豐富。從用戶角度來看，擁有多設備的用戶也越來越普遍。在做好單設備體驗的同時，我們相信多端融合也會是 AI 助手的趨勢之一。通過 AI 助手實現(xiàn)更好的跨端協(xié)同智能，在協(xié)同體驗 AI 助手會有更強的競爭力。

在產(chǎn)品形態(tài)層面，目前產(chǎn)品已經(jīng)從傳統(tǒng)的語音、語義的方式轉向多模態(tài)數(shù)字人的方向演進，目前多模態(tài)也是必然的發(fā)展趨勢。小布在多模態(tài)虛擬人方向也有一些落地，如：虛擬人直播帶貨、播報天氣、播報新聞。實際上也吸引了很多用戶的關注，虛擬人的交互方式天然讓用戶的感知更明顯。

除了外在表現(xiàn)，我們認為內(nèi)在的靈魂同樣重要。完美的 AI 助手需要有情感，有記憶，有觀點。助手需要逐漸成長，值得信賴。所以我們認為人格化也是未來的趨勢。

除了剛提到的技能建設的基礎體驗，以及反智障、懂用戶這種持續(xù)的提升之外，我們希望小布助手在理論上有持續(xù)的發(fā)展。比如，借助于情感引擎、擬人對話能力等各方面的技術，給用戶提供有自我的 AI 助手，成為用戶貼心的伙伴。

最后想說一下，在 AI 助手這個方向，經(jīng)歷了從早期的客服機器人到全能型智能助手，再到多模態(tài)虛擬機器人的變化。AI 助手在車載、電視、智能家居等各個場景上被越來越廣泛的應用和接納。隨著設備互聯(lián)互通逐漸成熟，智能助手也慢慢迎來了自己最好的發(fā)展機會。在這些復合場景下，AI 助手的價值能夠帶來更好的體驗。相信未來在萬物互融的場景下，AI 助手會發(fā)展的越來越好。

以上就是 OPPO 對話式AI 助手小布技術演進之路的分享，非常感謝大家的時間！期待與大家一起交流！

05

問答環(huán)節(jié)

Q1：怎么用模型做好跨域的多任務指令？比如，播放周杰倫的雙截棍，并調(diào)大一點聲音。

A1：我們做過一些探索，但后來發(fā)現(xiàn)這種說法比較長，用戶實際表達時會有一些難度，覆蓋面不是很多。但從技術來看，這個問題是有意義的。我們探索過兩種不同的方案：

• 方案1：對用戶的query進行解耦，把它進行改寫。即：把復合指令拆解為多個單指令，單個進行解決。

• 方案2：端到端的方案，在任務設計時，考慮到多種意圖和槽位耦合的情況。在建模時提取query中包含的信息的意圖和槽位?；诮Y構化的信息，尋求最優(yōu)化的路徑，覆蓋滿足組合的指令。

主持人：小度、谷歌之前也遇到同樣的問題，這個主要的難點是很多意圖組合在一起后語料會比較稀疏。

Q2：意圖識別時如何區(qū)分閑聊和任務型對話？

A2：任務型的query是比較好區(qū)分的，因為很多任務型的對話是封閉的。閑聊的邊界非常難確定，我們現(xiàn)在采用的方案是由前置的自然語言理解模塊（NLU）對任務和閑聊分別做識別。任務型的判定會更精準一些；閑聊的對寒暄這類高頻的閑聊會更準確一些，但我們希望它的召回更強一些。兩個方面都做識別后，后置會去做融合排序，結合一些先驗的經(jīng)驗，比如：我們天然認為任務型判斷更精準一些，因此任務型的判定優(yōu)先級會更高。在融合排序時，會將判定優(yōu)先給到任務型。當任務型未覆蓋時，有一些會流轉到閑聊進行兜底意圖識別。當然，像寒暄類的高精準識別的閑聊，可以和任務類型意圖的判定做置信度競爭，避免數(shù)據(jù)分類太偏向任務型。

主持人：在小度實踐中比較難的其實不是閑聊和任務，而是閑聊和信息問答。這兩個都是開放域的對話，區(qū)分會更加困難。目前小度閑聊中有生成式的回答，什么類型的問答都能接住。這會導致閑聊型和信息問答更難區(qū)分。

Q3：在檢索式召回中，是否需要對領域的內(nèi)容進行finetune?在缺乏反饋的情況下，是否有好的冷啟動的方案？

A3：目前小布在知識問答和閑聊場景都有用到檢索召回。根據(jù)我們的實踐經(jīng)驗來看，是需要finetune的，需要做一些特定數(shù)據(jù)的增強。

預訓練可以讓冷啟動的成本更低。預訓練沒有標注的語料成本不是很高，加上這些語料對解鎖語義表征能起到很好的作用。

Q4：當前是否主要依賴于數(shù)據(jù)標注？

A4：非常坦率來講，確實依賴數(shù)據(jù)標注。但我相信未來的方向，包括我們現(xiàn)在做的一些嘗試，都已經(jīng)在往依賴標注數(shù)據(jù)比較少的方式前進。這么做一方面是由于標注成本，另一方面也是因為標注不能解決所有的問題。整個系統(tǒng)的迭代會隨著系統(tǒng)的深入和技能的增加，意圖打架以及邊界不清晰的現(xiàn)象會越來越難解。另外一個比較好的趨勢是預訓練會降低對標注數(shù)據(jù)的依賴。

總結一下就是，目前對標注的依賴還很重；但到了深水區(qū)，標注不能解決所有的問題。因此還需要探索新的方案，像今天分享提到的自主的發(fā)現(xiàn)一些缺陷、一些隱式的信號，并對其進行修復。

主持人：這里我也給大家一些信心。大家有一個共識：冷啟動的類目，尤其是沒上到線上的類目，確實比較依賴數(shù)據(jù)的標注。我們很多大模型會有很多pretrain遷移學習，但到了當前特別的領域下，會依賴數(shù)據(jù)標注。

但目前小布、小度包括業(yè)內(nèi)的一些公司都會去做一些自學習的探索。很多發(fā)布到線上的，對人工的標注會依賴的比較少，這部分可以通過用戶的反饋來學習。這還是可以給大家一些信心的。

Q5：針對跨任務多輪指代消解，有沒有好的方案？比如，先詢問我的會議是哪天？機器人回答之后，用戶再接著問，那天的天氣怎么樣？

A5：針對多輪指代有兩種策略：

• 第一種是結合上下文，用深度學習端到端的方式做指代消解。這個在前幾年好像效果沒那么好。但根據(jù)我們的實踐、借鑒行業(yè)經(jīng)驗、學術論文，我們發(fā)現(xiàn)端到端的指代消解在當前的時間節(jié)點已經(jīng)做的蠻不錯了，可以把當前的query還原成上下文無關的query進行處理?？梢杂枚说蕉酥复獾姆桨复竽懙倪M行嘗試。我的經(jīng)驗覺得這種方式已經(jīng)非?？尚辛?，我們也有實際的上線。

• 另外一種是根據(jù)狀態(tài)信息做一些繼承和切換，可以知道當前query結構化之后需要哪些信息，這些信息是否可以從前文的交互內(nèi)容中找到并填充到query中。這種方式會更偏向于規(guī)則和策略。

我會更偏向于前一種方式，經(jīng)過近一兩年的實踐，我覺得這個問題已經(jīng)不太大了。