什么是query理解

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

query理解目前的主要作用

但需要強調的，是為什么我們要去做query理解，因為它存在的意義才是我們持續討論他在后續chatgpt下是否應該存在空間的落腳點。

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

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

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

細粒度的數據分析。例如那些意圖或者實體是用戶高頻提到的，此時進行針對性優化能大大提升整體效率。

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

下游的資源獲取的信息依據。

對話策略選擇的依據。

資源盤點和數據分析的依據。

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

系統內的其他組件，如下游的數據查詢、數據查詢。

用戶，理解用戶意圖后能給出更加精準的回復信息。

系統內其他人員，產品、運營甚至數據分析同事。

目前query理解的系統問題

然而，我們去構造這個模塊專門解決這類問題，會不會出現什么問題，答案是肯定的，而且隨著技術逐漸迭代，這些問題會逐步明顯，甚至可以說是系統問題了，畢竟只要有這個模塊，問題就存在，無法解決：

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

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

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

chatgpt內部沒有顯式query理解

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

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

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

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

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

所以，我們會發現，從設計的角度，他沒有query理解，也能夠很好地回答問題，甚至解決了搭建query理解模塊所存在的固有的系統問題。

后續設計是否還要保留query理解

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

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

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

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

不知道大家有沒有發現一個問題

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

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

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

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

審核編輯：劉清