前沿重器[84] | QP-OneModel：一个大模型搞定所有 Query 理解任务
前沿重器
栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）
2024年文章合集最新发布！在这里：再添近20万字-CS的陋室2024年文章合集更新
往期回顾
很多老粉应该知道，我早期做NLP，就是从搜索的Query开始，文本分类、NER、词权重之类的任务，之前也积累了很多经验，大家可以看看我早期的文章，里面基本都说了很多方案，时至今日仍然适用，大模型并未将其完全替代，本文最后会讲为什么。
随着大模型、生成式的技术逐步发展，Query理解的方案也在逐步升级，最近受朋友推荐，在读一篇小红书的论文，我理解这算是当前技术环境下比较有代表性的方案，因此和大家分享一下。
QP-OneModel: A Unified Generative LLM for Multi-Task Query Understanding in Xiaohongshu Search
https://arxiv.org/abs/2602.09901
背景
Query理解这个任务是搜索场景的老任务了，重点在于对Query的各方面信息进行理解和筛选，方便下游进行处理和检索，主要有如下任务。
意图识别。也有叫路由、Skills筛选、Planning之类的新鲜名词，很多性质和概念都有重合，但本质很类似，主要是定位query所属于的领域，确定下游需要的处理方案，查询数据库等，方便定制。
NER，实体抽取。从Query抽取出重要的片段信息，早年的抽取是因为数据库检索方案比较简陋，更多是字面的匹配，抽取片段后搜索能大幅提升召回率，而现在，尽管已经有向量匹配之类的模糊匹配模式，有这种抽取作为辅助，也还能提升准确率。
词权重。根据词汇的重要度给出打分，方便下游进行相似度计算的时候能有所关注，而放弃对一些助词、语气词之类的信息过分关注。这个近年来会比较少见。
这些任务常规的方式就是各做各的，以串联式为主，在BERT技术的引入下，由于本身语言模型的限制，对口语化、长尾的query处理效果有限，同时维护成本也比较高，当规则和类目有变化时就需要全量重训，灵活性不足。
大模型引入后，虽有整体的效果提升，但是因为本身还是各做各的，任务间缺少协同，而且小红书场景下俚语新词比较多，业务规则又多又杂，适配性仍然存在短板。
因此，论文提出一种端到端生成的方案，一次性将各种任务都提取出来，同时确保和实际任务能有足够的对齐，兼顾灵活性。
任务与格式
论文里，QP-OneModel主要做如下任务。
命名实体识别。从query里识别品牌、产品、系列等实体并分类。
中文分词。把连续无分隔的文本切成有意义的词汇单元。
词权重。给每个词按重要性打分（0–3 级），决定搜索匹配优先级。
Query分类。给query打多标签，确定垂直领域与核心意图，抽象出来就是类目分类，根据经验，一般有几百类。
意图描述。用自然语言直白解释用户到底想搜什么。这里的重点是能破解单一信号覆盖用户意图不全难题，优化意图体系并提升识别能力，为产运分析、后链路动作提供依据。
这些任务，作者把它都放到一个任务里，对给定的Query，要求一次性输出上面内容，这个对于生成式的模型，还是比较简单的，这是一个输入输出的例子。
注意一下这里的输入，除了query本身之外，还有3个内容。
可配置业务规则。实体类型定义、分词规则、词权重分级规则、分类边界与歧义处理、意图描述写法规范，当然，也为后续可配置化留下口子，未来业务运营需要对这些标准进行更新，就可以在这里入手。
用户历史查询上下文。把当前会话内最近几次查询一起输进去，解决歧义、指代、意图渐变。
平台笔记内容。检索 Top-K 高相关笔记放进 Prompt，让模型不脱离小红书内容生态。
接下来，就是重头戏——训练了。
训练
宏观上，训练会分为3个阶段。
阶段1：知识注入（Knowledge Injection）。利用精标+小模型预标注数据，快速学习基本的场景知识。
阶段2：目标分布对齐（Target Distribution Alignment）。用精标数据，提升预测准确性，严格符合在线要求。
阶段3：多奖励强化学习（Multi‑Reward RL）。解决SFT只会模仿答案，不理解逻辑的问题。
这个模式大家应该比较熟悉，思路上主要是两条大思路在穿插。
先粗后细。用海量数据先让模型了解任务边界和场景，后用精标数据收窄控制，提升准确率。这个思路早在BERT时代就已经有了，收益明显。
先SFT再RL。让模型先学死知识，固定格式，再通过RL让模型理解具体含义。最近写的前沿重器[82] | 淘宝LREM——先思考再embeding、前沿重器[80] | DeepTravel：滴滴的 RL Planning 落地实践、前沿重器[77] | 美团WOWService（上）：四阶段训练打造高质量可维护的对话模型，都有这个模式的身影，基本已经成为行业基操了。
接下来讲一下这3步具体是怎么做的。
阶段1：知识注入
数据层面，基于任务拆解，把原有的BERT模型（分词 / NER / 权重 / 分类）取出，基于在线日志数据进行预标注，得到大规模单任务伪标签数据，配合少量全任务统一人工标注，构造成这一步的训练数据，然后用于进行训练，这两种数据的结合，一方面确保业务正确性，另一方面
损失上，作者会把人工标注的数据和预标注数做个加权，按论文的说法是“balancing the two data sources”。
阶段2：目标分布对齐
阶段1用了历史日志，有噪声、过时、格式不统一，和线上真实流量不一致，所以在阶段2，只用人工标注的数据进行训练。这里，主要讲一下阶段2的核心差异。
只用人工标注数据。
格式更为严格，必须依照最终的输出格式。
严格遵守业务边界，避免存在过期的信息。
阶段3：多奖励强化学习
到了强化学习，就不再要求大模型只会模仿答案了，而是直接学习逻辑，进一步提升大模型自己的推理能力。
首先，大家最关注的便是强化学习的奖励，这里，作者把除了意图描述之外的4个任务的损失都加了进去，普遍都是用的F1。
训练策略上，使用的是经典的GRPO。
有个细节，4个任务之间，如果只是简单的加权求和，会出现任务之间好坏被平均的问题，在论文里叫“mask performance discrepancies”，论文中为了解决这个问题，会用Stage2 训练好的 SFT 模型去过滤数据，只保留某个任务上差异很大，但其他子任务差不多的样本，例如NER 错很多，但分词、权重、分类都对的样本，这样的训练会更稳定而高效。
加入KL散度。KL散度是加在GRPO的损失里的（注意，是损失！），这个KL散度用于衡量阶段2模型的差异。即使是大模型有自己的想法，也不能和他差距太远。
有关效果评估
论文内效果评估的全过程还是相对全面的，这里我把一些比较关键的结论给出供大家参考吧。
全面碾压传统BERT流水线（虽然这个baseline已经比较低了），平均增加7个点。
同体积下，单一任务累计效果不如统一一个模型的方案，这应该就是“1+1>2”的效果了。
适用领域模型，即小红书自己的RedOne2.0-based，比通用的Qwen3要好。
消融实验看来，3阶段的训练均有收益。
因为prompt内存在可运营的项目，所以对任务进行小幅度修改，是有收益的，8B模型效果比通用的32B效果要好。
专业的说，在不需要微调的情况下，经过本文方案微调的8B模型，是比通用的32B效果要强，因此，要是做新意图的拓展，这个方案还是不错的。论文里表5做了对比，大部分情况虽然和32B差距小，但在体积差距这么大的情况下，本文的方案已经可以说是胜利了。
从在线端到端效果来看，整体搜索质量有提升。
在线应用
有一块东西想专门讲一下，论文里提到了在线的应用，这个应该是搜索领域用大模型比较实用的实践方式了。
考虑到在线耗时的压力，在这种C端高频用大模型，成本肯定巨大，因此有选择地用，异步地用，是很有必要的，这里有两个关键工作。
数据筛选。只对高频、重要的case进行应用，毕竟低频、长尾或者没什么实际意义的case，无论采用哪种方案，效果都难以达到预期。
异步。高频的case，并非在线等用的时候再计算，而是离线提前算好入库，在线做kv-cache，命中时能直接出结果。
有些人可能会认为这种数据筛选，在线的命中概率会比较低，实际上并非如此。从我的经验看，在线的case其实非常集中，在一些场景下，例如我之前做的语音助手，因为任务比较固定，哪怕只是TOP100已经很高覆盖在线很大比例的query了，而在小红书的搜索场景，因为时事热点变化之类的原因，尽管会相对稀疏，但是28法则仍然是非常显著的，所以哪怕只有高频的使用这个功能，收益也已经是非常高的。
有些论文的小遗憾
论文整体的思路还是很明白的，可以作为具体任务的范式来实现的，不过还是有些小遗憾的，希望未来还有论文会补充这些细节。
第三章是提及了Intent Description的，但是第四章的损失，第五章的实验对比，对这块并没有什么很具体的解释，像是把这块给扣了。我自己的理解，Intent Description这个作为自然语言，在CoT上肯定是有收益的，但这个东西怎么体现在奖励和损失里，数据是怎么准备的，效果上又如何，没有在论文里找到，有些可惜。
user_rewrite和notes的加入，对实际任务的修正应该是很有用的，但是论文内只是提了一嘴，实际的实验讲的并不多。另外，在实际上，这两个东西的加入，和cache存在矛盾，一旦用户行为有变化，或者对热门/时效query，信息可能就会更新，此时的cache就失效了。与之类似的，业务规则的修改会影响一大批的query，此时一个小修改，可能会导致cache全部失效。
实验上，对比的其实不那么够，这里的baseline太低了也太少了。论文里只和BERT-Pipeline对比，还是不够，业内还有很多类似的模型，虽然可能是单任务，但做类似的事来做对比，可以增强论文在收益上评估的可靠性，例如我们可能无法确定，这个效果是否单纯因为用了更大体积的大模型或者是生成式的方式就能达到这个收益。
为何传统方案仍然有用
回归开头的那个问题，这里简单解释一下，回到Query理解这个问题本身，为什么大模型仍旧未能全面替代传统的方法。
回归论文，大家应该会发现一个细节，在线应用上，对于未命中cache的部分，论文内对长尾query，还是用的BERT模式，这不外乎就是因为两个原因，时间和金钱。
耗时。在线用大模型，生成式，耗时肯定相对长，大家可以回头看看论文里这个模型的输出大概有哪些token，即使是单并发，这个耗时压力也很大。
成本。我不太了解小红书的在线并发，不过从我以前的经验，C端热门产品的接口，在线并发上千上万是常态，大模型要达到可用的水平，这个成本大家可想而知。
其次，对于模糊甚至不明所以的case，在实际上，任何方案都对他们没辙，因为他们真的是模糊，别说模型，人工标也标不出来，这部分从性价比而言，有个相对解释的过去的结果就已经足够了。而且，这部分，在线的占比往往并不低，用户误触、实际需求模糊、粘贴错误之类的问题屡见不鲜，有资源的读者可以自己去查自己场景的数据看看这类型问题的占比，特指C端产品，当然B端产品，人为构造的Hard Case在一段时间内占比可能会更高一些。
第三，灵活性。尽管论文提供了可运营的方案，在prompt中设置了可调整的部分，也的确有了一定的成效，但在现实实践中，只能说是环节，根本问题还是在于深度学习模型的灵活性问题，举例子。
规则添加的多了，一大块，此时大模型的指令遵循能力开始下降，部分规则有失效风险，在测试集覆盖率不足的情况下，还难以检测。
此时，我们仍旧避不开微调模型的问题，把规则通过加数据训练的模式训进去。
总而言之，一方面，大模型带来了耗时和成本两个新问题，另一方面很多原本传统方案，现在大模型依旧是有，例如模糊和灵活性问题，传统方案中存在大量的妥协方案，例如新增类目可以通过向量召回的模式来补充，而且成本和耗时上相比大模型还是优势，于是，传统方案也有了不小的生存空间。
小结
小红书提出的QP-OneModel，是对大模型在Query理解任务上的一次大整合，把关键的Query理解任务都放了进来，形成了统一的方案，同时形成一种这个任务的范式，这个还是让我们备受启发，这种方法论的形成，能让我们在面对日常问题中有了不错的思维基础，还是挺不错的。
更多推荐
8
0- 0
已为社区贡献6条内容
所有评论(0)