什么是query理解？query理解目前的主要作用

什么是query理解

有關(guān)query理解的具體概念，我之前在串講對話系統(tǒng)的時候有專門講過，這里就不重復(fù)了。（前沿重器[23] | 聊聊對話系統(tǒng)：query理解），還有這篇可以參考（心法利器[70] | 短文本理解的難點和解決方案）

query理解目前的主要作用

但需要強(qiáng)調(diào)的，是為什么我們要去做query理解，因為它存在的意義才是我們持續(xù)討論他在后續(xù)chatgpt下是否應(yīng)該存在空間的落腳點。

我們都知道，query理解后的下游內(nèi)容，是需要給下游使用的，同樣的，我們來想想幾個場景。

識別天氣意圖，并且提槽時間、地點信息。方便下游進(jìn)行查詢使用，和功能需求、工程架構(gòu)是綁定的，如“深圳明天的天氣”，我們需要知道天氣意圖，要去查的是天氣庫，然后查詢的是明天、深圳的天氣。

辱罵意圖。識別出來后，我們根據(jù)用戶的語氣，可以制定一定的安撫策略，或者引導(dǎo)用戶一起解決問題，這里，我們是需要根據(jù)意圖調(diào)整對話策略。

細(xì)粒度的數(shù)據(jù)分析。例如那些意圖或者實體是用戶高頻提到的，此時進(jìn)行針對性優(yōu)化能大大提升整體效率。

此時我們可以看到，其實query理解主要是在3個維度有很大作用：

下游的資源獲取的信息依據(jù)。

對話策略選擇的依據(jù)。

資源盤點和數(shù)據(jù)分析的依據(jù)。

這里，我們把query理解的作用放在一個系統(tǒng)，甚至一個產(chǎn)品層面來看的，他所提取信息，是可以供多個對象使用的：

系統(tǒng)內(nèi)的其他組件，如下游的數(shù)據(jù)查詢、數(shù)據(jù)查詢。

用戶，理解用戶意圖后能給出更加精準(zhǔn)的回復(fù)信息。

系統(tǒng)內(nèi)其他人員，產(chǎn)品、運(yùn)營甚至數(shù)據(jù)分析同事。

目前query理解的系統(tǒng)問題

然而，我們?nèi)?gòu)造這個模塊專門解決這類問題，會不會出現(xiàn)什么問題，答案是肯定的，而且隨著技術(shù)逐漸迭代，這些問題會逐步明顯，甚至可以說是系統(tǒng)問題了，畢竟只要有這個模塊，問題就存在，無法解決：

維護(hù)成本問題。隨著意圖、實體的逐漸增加，系統(tǒng)壓力會變得非常零散而巨大，可維護(hù)性會大大降低，想象一下，當(dāng)我們要維護(hù)幾十上百甚至更多意圖時，人力、機(jī)器的安排安排都是絕大的。

誤差的疊加問題。技術(shù)上有個共識，我們總不能解決所有問題，我們拆解的步驟越多，中間損失的可能也會越多，最終反饋到端到端層面問題就會更嚴(yán)重，這也是為什么query理解的召準(zhǔn)要做的這么高的根本原因，高頻的意圖、NER都要在雙85、雙90甚至更高，加了權(quán)得奔著95/96去了。

query理解類目體系的模糊問題逐步凸顯。在項目初期，我們會關(guān)注的是高頻、典型的問題，但是隨著問題的逐漸深入，我們是需要去解決困難的、邊緣的問題的，但是隨著query理解而產(chǎn)生的意圖、實體體系，我們所關(guān)注的問題就會擴(kuò)展到這些邊緣地帶，百科和專項知識問答的交叉，多類型藝術(shù)作品的重合（如電影、小說）、導(dǎo)航和地點查詢的交叉等。

chatgpt內(nèi)部沒有顯式query理解

我們其實可以比較明顯的知道，chatgpt其實是一個端到端或者說很接近端到端的對話系統(tǒng)方案，在這個方案下，我們可以看到，他們根本不需要意圖識別，不需要提槽，就能夠給出非常精準(zhǔn)的回復(fù)（當(dāng)然，模型內(nèi)部可能有，但這種事情是隱式的，看不出來），因此很多人也可能會感覺到，模型很輕松地就能夠回復(fù)復(fù)雜多樣的問題嗎，別說意圖識別、提槽這中間基本的任務(wù)，詞權(quán)重、糾錯、句法之類的query理解任務(wù)似乎都不需要了。

按照以為大佬的說法（張家?。篊hatGPT八個技術(shù)問題的猜想），應(yīng)該是instruct tuning等的技術(shù)手段，似乎讓模型產(chǎn)生了這種能力，針對絕大多數(shù)問題，模型能快速從這個系統(tǒng)里找到所需內(nèi)容并整合輸出，以前這種整合是需要人工拆解并逐步拼接處理的，但是現(xiàn)在，已經(jīng)能夠通過模型一步直達(dá)了。甚至，還能夠更好地解決我在上一節(jié)所提到的三個問題：

維護(hù)成本問題。雖說chatgpt是個巨型的模型，但是如果要和成熟、完整的對話、搜索系統(tǒng)比，可能不見得就那么大了，畢竟可能他一個就夠。

誤差疊加問題。一個模型，不存在疊加。

query理解類目體系的模糊問題逐步凸顯。連query理解都沒有，什么意圖類目體系之類的，根本就不存在，只要是問題，直接給出答案回答就是了。

所以，我們會發(fā)現(xiàn)，從設(shè)計的角度，他沒有query理解，也能夠很好地回答問題，甚至解決了搭建query理解模塊所存在的固有的系統(tǒng)問題。

后續(xù)設(shè)計是否還要保留query理解

那么現(xiàn)在問題來了，后續(xù)，我們是否還要考慮這個query理解問題呢。先擺出答案，在很多現(xiàn)有系統(tǒng)中或者是設(shè)計中，是不能把他放棄的，但是在迭代升級過程中可以把這個給考慮進(jìn)去。

首先，我們需要承認(rèn)的是，chatgpt確實能夠從系統(tǒng)層面解決了很多問題，很多功能可以逐步從零散非端到端的模塊過渡到chatgpt這種比較統(tǒng)一的模塊中的，一方面泛化性和總體效果應(yīng)該會有不曉得提升，另一方面是從維護(hù)和管理上，似乎有了一個更為統(tǒng)一的綜合模塊，這個角度看，維護(hù)成本是有所下降的。

但是，我們?nèi)耘f不可忽略的是，單獨的query理解模塊，在對話策略的靈活性、工程資源對接的便捷性以及產(chǎn)品數(shù)據(jù)分析的可得性上，仍舊有很突出的優(yōu)勢，產(chǎn)品終究是一個系統(tǒng)，內(nèi)部需要解決的問題有很多，我們不能一概而落，激進(jìn)地直接把原來的放棄，而轉(zhuǎn)為用新的，目前chatgpt仍舊有很多問題。

因此應(yīng)該是基于每個業(yè)務(wù)，甚至業(yè)務(wù)內(nèi)的多個功能模塊點來綜合設(shè)計，可以考慮把一些通用性的、開放域的，實時信息資源以來不緊密功能逐步向這里過度，此時意圖識別可能沒有那么的高優(yōu)了，但是對于特定的一些場景，例如前面提到的實時性很高的天氣，需要定制化的風(fēng)控安全場景，內(nèi)容需要頻繁更新的場景，則需要更加謹(jǐn)慎，甚至繼續(xù)走原來的技術(shù)路線，也并無不可。

不知道大家有沒有發(fā)現(xiàn)一個問題

在我寫這篇文章的過程中，突然發(fā)現(xiàn)一個有意思的事，本文里的chatgpt，把他換成bert，或者是端到端模型，似乎沒有很大的違和感，這兩個一定程度其實都能起到類似chatgpt的作用，或者說chatgpt的思路其實就是預(yù)訓(xùn)練模型的進(jìn)一步升級，效果提升量變到質(zhì)變的新的里程碑，這個新的里程碑一定程度讓我們對“端到端”方案產(chǎn)生信心，自己在分析時很多時候考慮到的就是端到端和非端到端的對抗，可能有些片面，但是隨著逐步分析，會發(fā)現(xiàn)其實除了效果體驗的好壞，剩下的因素都聚焦在了端到端和非端到端的問題上了，這次聊query理解，最終仍然落到了這個問題上。

拋開效果因素來，我們會發(fā)現(xiàn)，chatgpt所代表的其實就是端到端方案目前已知的一個頂峰，它具備很高的泛化能力，同時在工程設(shè)計上也帶來了很大的便利，而與之對應(yīng)的就是目前工業(yè)界所廣泛使用的非端到端的方案，有關(guān)這兩者的對比和思考，可以看這篇文章：心法利器 | chatgpt下非端到端方案是否還有意義。

而回到效果因素上，毋庸置疑的是，在很多領(lǐng)域下，或者說高頻熱門的領(lǐng)域下，chatgpt似乎都有非常優(yōu)秀的效果，這也是讓外界恐慌NLP、搜索、對話系統(tǒng)的末日來臨的根本原因，沒錯，就是效果好，用戶體驗層面看，很多問題確實回復(fù)的很好，滿足用戶了。

但是把多個因素綜合在一起，作為實踐者的我們，更多應(yīng)該盡可能比對多種方案，因地制宜地選擇才是對的。

審核編輯：劉清