心法利器
本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
2022年新一版的文章合集已经发布，累计已经60w字了，获取方式看这里：CS的陋室60w字原创算法经验分享-2022版。
往期回顾
心法利器[77] | 文本分类日常提点技巧
心法利器[78] | 端到端任务的拆解设计
心法利器[79] | 对话系统中的多路召回和排序
心法利器[80] | 稳定性和过拟合问题真的重要吗
心法利器[81] | chatgpt下非端到端方案是否还有意义
上一期和大家聊过了chatgpt下非端到端方案的意义和生存空间问题（心法利器[81] | chatgpt下非端到端方案是否还有意义），这一期在深入一点来聊，整个对话系统和搜索系统所非常常见的一个大模块，query理解的意义。
懒人目录：
什么是query理解
query理解目前的作用
目前query理解的系统问题
chatgpt内部没有显式query理解
后续设计是否还要保留query理解
不知道大家有没有发现一个问题
什么是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理解任务似乎都不需要了。
按照以为大佬的说法（张家俊：ChatGPT八个技术问题的猜想），应该是instruct tuning等的技术手段，似乎让模型产生了这种能力，针对绝大多数问题，模型能快速从这个系统里找到所需内容并整合输出，以前这种整合是需要人工拆解并逐步拼接处理的，但是现在，已经能够通过模型一步直达了。甚至，还能够更好地解决我在上一节所提到的三个问题：
维护成本问题。虽说chatgpt是个巨型的模型，但是如果要和成熟、完整的对话、搜索系统比，可能不见得就那么大了，毕竟可能他一个就够。
误差叠加问题。一个模型，不存在叠加。
query理解类目体系的模糊问题逐步凸显。连query理解都没有，什么意图类目体系之类的，根本就不存在，只要是问题，直接给出答案回答就是了。
所以，我们会发现，从设计的角度，他没有query理解，也能够很好地回答问题，甚至解决了搭建query理解模块所存在的固有的系统问题。
后续设计是否还要保留query理解
那么现在问题来了，后续，我们是否还要考虑这个query理解问题呢。先摆出答案，在很多现有系统中或者是设计中，是不能把他放弃的，但是在迭代升级过程中可以把这个给考虑进去。
首先，我们需要承认的是，chatgpt确实能够从系统层面解决了很多问题，很多功能可以逐步从零散非端到端的模块过渡到chatgpt这种比较统一的模块中的，一方面泛化性和总体效果应该会有不晓得提升，另一方面是从维护和管理上，似乎有了一个更为统一的综合模块，这个角度看，维护成本是有所下降的。
但是，我们仍旧不可忽略的是，单独的query理解模块，在对话策略的灵活性、工程资源对接的便捷性以及产品数据分析的可得性上，仍旧有很突出的优势，产品终究是一个系统，内部需要解决的问题有很多，我们不能一概而落，激进地直接把原来的放弃，而转为用新的，目前chatgpt仍旧有很多问题。
因此应该是基于每个业务，甚至业务内的多个功能模块点来综合设计，可以考虑把一些通用性的、开放域的，实时信息资源以来不紧密功能逐步向这里过度，此时意图识别可能没有那么的高优了，但是对于特定的一些场景，例如前面提到的实时性很高的天气，需要定制化的风控安全场景，内容需要频繁更新的场景，则需要更加谨慎，甚至继续走原来的技术路线，也并无不可。
不知道大家有没有发现一个问题
在我写这篇文章的过程中，突然发现一个有意思的事，本文里的chatgpt，把他换成bert，或者是端到端模型，似乎没有很大的违和感，这两个一定程度其实都能起到类似chatgpt的作用，或者说chatgpt的思路其实就是预训练模型的进一步升级，效果提升量变到质变的新的里程碑，这个新的里程碑一定程度让我们对“端到端”方案产生信心，自己在分析时很多时候考虑到的就是端到端和非端到端的对抗，可能有些片面，但是随着逐步分析，会发现其实除了效果体验的好坏，剩下的因素都聚焦在了端到端和非端到端的问题上了，这次聊query理解，最终仍然落到了这个问题上。
抛开效果因素来，我们会发现，chatgpt所代表的其实就是端到端方案目前已知的一个顶峰，它具备很高的泛化能力，同时在工程设计上也带来了很大的便利，而与之对应的就是目前工业界所广泛使用的非端到端的方案，有关这两者的对比和思考，可以看这篇文章：心法利器[81] | chatgpt下非端到端方案是否还有意义。
而回到效果因素上，毋庸置疑的是，在很多领域下，或者说高频热门的领域下，chatgpt似乎都有非常优秀的效果，这也是让外界恐慌NLP、搜索、对话系统的末日来临的根本原因，没错，就是效果好，用户体验层面看，很多问题确实回复的很好，满足用户了。
但是把多个因素综合在一起，作为实践者的我们，更多应该尽可能比对多种方案，因地制宜地选择才是对的。
当然了，外宣的，和真正用的，又不见得得是一个东西（狗头）。
