让搜索引擎学会两种语言：一个懂用户，一个懂商品

你有没有想过一件事当你在应用商店里搜记账为什么弹出来的第一个结果往往是个理财类App而不是那个真正叫记账的软件这背后藏着搜索系统一个几十年都没彻底解决的老问题。今天要聊的这篇论文来自苹果公司的研究团队他们琢磨出了一个挺巧妙的办法让两个AI模型互相打配合一个专门理解用户在想什么一个专门理解商品是什么然后训练它们说同一种语言。先搞懂搜索到底难在哪搜索系统的第一道关卡叫做检索。检索从海量商品或内容库里先筛出一批可能相关的候选集交给后面的排序系统精挑细选。这一步一旦出错就没法挽回。你想想如果一个真正相关的App在检索阶段就被漏掉了那不管后面排序算法多牛用户都看不到它。反过来如果检索阶段塞进来太多垃圾候选后面的系统压力也会暴涨。所以检索系统必须同时兼顾两件事召回率要高别漏精确率也要高别乱塞。这两者其实是天然矛盾的。你要是把网撒得越大捞的鱼越多召回率越高但混进来的杂鱼也越多精确率就下降了。这就是所谓的**精确率-召回率权衡**几乎是所有检索系统绕不开的宿命。传统做法主要有两条路子。一条是老牌的关键词匹配最经典的代表是BM25算法。BM25一种基于关键词出现频率和重要性打分的经典检索算法通过倒排索引快速匹配查询词和文档词。倒排索引一种数据结构记录每个词出现在哪些文档里就像书末尾的索引页查一个词能立刻定位到相关页码不用整本书翻一遍。BM25这类方法简单快、可解释性强广告系统里广泛使用广告主直接竞价关键词但它的死穴是没法理解语义。你搜手机坏了修不了它未必能联想到维修服务这个词因为字面上根本不重合。于是第二条路是**稠密检索**把查询和商品都映射成一串数字向量通过向量之间的相似度来判断是否相关。稠密检索把文本转换成固定长度的数值向量embedding通过计算向量间的余弦相似度等方式衡量语义相似性代表方法有DPR、ANCE等。稠密检索能捕捉语义关联但代价是丢掉了关键词系统原本的可解释性和基础设施兼容性你没法直接看懂一个向量为什么和另一个向量相似。近几年又冒出了第三条路叫生成式检索,直接用语言模型生成商品的身份标识符来完成匹配。但这类方法对标识符设计的依赖极强一旦标识符设计得不好扩展性和泛化能力都会打折扣。问题来了这几年大语言模型这么火大家很自然地想能不能用LLM来帮检索系统一把已经有不少工作在做这件事了比如用LLM去扩写用户的查询词或者用LLM生成一些辅助数据去训练检索模型甚至用检索反馈去微调LLM。但这篇论文的作者们发现了一个共性问题几乎所有这些方法都只在查询这一侧下功夫商品那一侧的表示方式基本没变,还是靠一个独立的下游检索器去完成最终匹配。这就好比你努力提升自己的沟通表达能力却指望对方原封不动地保持老样子还能听懂你。系统里始终有一侧是不进化的那匹配效果的天花板自然被这一侧焊死了。于是研究者们提出了一个问题能不能让查询和商品两边都用LLM去生成关键词让两边同时进化直接在生成出来的关键词空间里做匹配这就是这篇论文的核心思路,论文管这个框架叫CoGRCo-evolving Generative Retriever共同进化生成式检索器。CoGR一个训练两个独立LLM分别为查询和商品生成关键词的检索框架两边生成的关键词通过倒排索引直接匹配兼容现有的关键词检索基础设施。两个AI模型一个学说用户话一个学说商品话CoGR的基本设计其实挺直白。给定一个用户查询用一个叫做**查询侧生成器**的LLM生成一组关键词。给定一个商品用**商品侧生成器**这个LLM也生成一组关键词。然后系统看两边的关键词集合有没有重合重合了就算匹配上再用BM25给检索结果排个序。这个设计本身不难理解,难的是怎么让这两套关键词对得上话。你想啊如果查询侧LLM生成的关键词都是省钱划算这种偏口语化的表达而商品侧LLM生成的关键词都是折扣促销这种偏商品属性的词即便语义上很接近字面上完全对不上那关键词匹配这套机制就彻底失效了。这就好比两个人明明想表达同一个意思一个说方言一个说普通话,内容一致但字面上根本对不上号。如果不想办法让他们说统一的语言再怎么聊都是鸡同鸭讲。所以CoGR分成两个阶段来解决这个对齐问题。第一阶段监督微调打地基第一阶段叫**监督微调**,简单说就是先给两个生成器一个共同语言的初始版本。监督微调SFT用人工标注或构造好的数据对预训练模型进行有监督训练让模型学会特定任务的输出模式。具体怎么做的论文里的算法思路是这样的先用原始的基础LLM给每个商品生成一批关键词得到商品侧的初始关键词集合。然后对每个查询把它所有相关商品的关键词都收集起来取出现频率最高的一批词作为这个查询的目标关键词。这个设计的巧妙之处在于它人为地在相关的查询-商品对之间制造了关键词重合。你查询的目标关键词本身就是从相关商品的关键词里筛出来的两边天然就有交集。这就像是给两个刚认识、语言不通的人先塞一本共同的短语手册让他们至少能用几个共通的词打个招呼不至于完全零基础地互相摸索。如果跳过这一步会怎样论文的消融实验后面会细说给出了答案直接从零开始做强化学习效果明显更差。相当于让两个语言不通的人在完全没有共同词汇的情况下就开始谈判,能达成一致但过程会曲折得多效果也打折扣。第二阶段让两个AI相互切磋共同进化这是全文最有意思的部分,论文标题里It Takes Two to Match一个巴掌拍不响说的就是这个。第二阶段用的是**强化学习**具体算法是GRPO。强化学习RL让模型通过与环境交互获得奖励信号不断调整策略以最大化累积奖励的训练方法不同于监督学习需要标准答案而是通过好不好的反馈来学习。GRPO一种强化学习算法全称是Group Relative Policy Optimization通过给同一个输入采样多个候选输出比较组内相对好坏来计算优势信号从而更新模型。训练方式是交替进行的先固定商品侧的索引不动只训练查询侧生成器训练好之后反过来固定查询侧索引训练商品侧生成器如此循环往复。为什么要这样交替而不是两边一起训练这里有个很现实的技术考量。如果两边同时训练、同时变化那对每一侧来说它面对的环境也就是对方生成的关键词是一直在晃动的靶子,你刚学会怎么打中一个位置对方立刻又变了。这种情况下训练会很不稳定很难收敛。论文的做法是每次只让一侧变化另一侧冻结相当于给训练中的那一方一个固定的靶子去瞄准。等这一轮训练完再把刚训练好的一方冻住换另一方去适应它。这就像是两位棋手轮流下棋而不是同时移动棋子,如果两人同时乱动棋盘谁都摸不清对方到底想干嘛棋局根本没法进行。只有一方走一步、稳定下来另一方才能针对性地应对。这种交替更新的策略本质上是用轮流换来了稳定。那么两边各自的奖励信号是怎么设计的这才是整篇论文最精细的地方。查询侧的奖励直接看检索效果好不好对查询侧来说奖励信号很直接,用**F1分数**。F1分数综合考虑精确率检索结果里有多少是真正相关的和召回率所有相关结果里有多少被检索到了的调和平均数是一个平衡两者的常用指标。对每个查询生成一组关键词去匹配商品索引看检索出来的商品集合里有多少真的是相关商品这是精确率又覆盖了多少应该被检索到的相关商品这是召回率最后用F1把这两者揉到一起作为奖励信号喂给GRPO去优化查询侧的模型。论文里还提了一句很实在的话:在实际的商业系统里精确率关系到用户体验别让用户看到一堆不相关的垃圾召回率关系到潜在收入别把能赚钱的相关商品漏掉。F1分数把这两者都照顾到了是个务实的选择。为了防止模型钻空子生成一大堆关键词硬撑召回率论文还设了一个关键词数量上限超过这个上限直接给零分,这算是一个简单粗暴但有效的约束。商品侧的奖励这个词到底有没有用要扣掉别人的功劳如果说查询侧的奖励设计还算直观商品侧的奖励设计就要绕个弯子了这也是全文技术含量最高的部分。问题出在哪你没法直接套用查询侧那套逻辑给商品打分。为什么因为商品的关键词好不好不能光看它自己检索到了多少相关查询,这个角度是错的检索系统真正的目标是查询能不能找到相关商品而不是反过来。论文管这个叫**反事实边际奖励**我觉得这是整篇论文设计最精妙的地方。反事实边际奖励通过对比替换某个商品的关键词前后整个系统检索质量发生的变化来衡量这组新关键词到底带来了多少净贡献而不是孤立地评价这组关键词本身好不好。具体怎么操作论文的思路是这样的先固定查询侧的索引把当前商品侧的关键词状态当作参考基准。然后只把某一个商品的关键词换成新采样出来的候选关键词集合其他所有商品的关键词都原封不动。这时候重新跑一遍所有查询的检索计算出一个新的总体F1分数,把这个新分数减去替换前的参考分数差值就是这组新关键词的奖励。打个比方这就像评价一个足球运动员在某场比赛里踢得好不好不能光看他自己进了几个球、抢了多少次断,更靠谱的方法是看如果把他换下场全队的比分会有什么变化。如果换下他之后球队输得更惨说明他确实起了作用如果没什么影响说明他的贡献被高估了。这种控制变量法式的评估剥离了其他因素的干扰精准定位到这一个商品的关键词到底值不值。如果不这样做直接让商品自己去优化检索到尽可能多相关查询会怎样论文里专门设计了一个对照实验叫Transposed F1转置F1就是把商品当成查询、反过来做检索匹配测这种对称设计的效果。结果这个变体在Internal数据集上的F1只有0.3743而完整版CoGR是0.3963,差了两个百分点。这说明商品侧不能简单地照葫芦画瓢套用查询侧的逻辑反事实边际奖励这种更精细的设计确实是必要的。这里还有个工程上的巧思值得一提。按理说每换一次某个商品的关键词就要把所有查询重新跑一遍检索这个计算量大得吓人。论文的解决办法是只关注这次替换实际影响到的那一小撮查询,因为一个商品的关键词变了只有那些原本能检索到它、或者现在新检索到它的查询F1分数才会变其余绝大多数查询根本不受影响直接用缓存好的历史统计量就能算出结果不用重新跑一遍全量检索。这个效率优化虽然是个技术细节但恰恰是让这套复杂奖励机制能在实际系统里跑起来的关键。十个对手两个数据集CoGR全赢了光有设计思路不够得看效果。论文选了两个数据集来验证一个是苹果内部的APP应用商店搜索数据训练集1.35万条查询验证集1500条商品库有3.96万个应用平均每个查询大概对应1000个相关应用;另一个是公开的WANDS商品搜索数据集来自家居电商Wayfair规模小一些训练集430条查询验证集50条商品库4.3万个产品平均每个查询约200个相关商品。对比的基线方法覆盖了三大流派一共10种代表性方法稀疏检索阵营里有经典的BM25和学习式稀疏检索方法SPLADE-v2稠密检索阵营里有DPR、ANCE以及用更大规模模型Qwen3-Embedding-4B做的零样本和微调版本生成式检索阵营里有DSI、DSI-QG、RIPOR还有一个跟CoGR思路比较接近的DeepRetrieval它只训练查询侧的语言模型去改写查询不动商品侧。结果如下用全量检索的F1分数衡量这是最核心的综合指标在Internal数据集上表现最强的基线是ANCE-Qwen4BF1是0.3575。CoGR 4B完整双侧优化版本达到了0.3963相比最强基线提升了10.9%。在WANDS数据集上最强基线依然是ANCE-Qwen4BF1是0.5012。CoGR 4B达到了0.6819提升幅度高达36.1%。这里有个特别值得琢磨的对比。论文专门做了一个冻结商品侧的CoGR变体表格里标注为CoGR\*也就是只训练查询侧、商品侧参数完全不动。这个变体在Internal上的F1是0.2617在WANDS上是0.4662,虽然比大部分传统基线要强但比完整版CoGR差了不少Internal差了约0.135WANDS差了约0.216。这个数据非常直接地证明了论文的核心论点只优化一侧是不够的两边必须一起进化。如果你只训练查询侧会怎样答案已经摆在这里了性能损失能达到20个百分点以上以WANDS为例从0.6819掉到0.4662降幅超过30%。这就好比谈恋爱只有一方在努力学习理解对方、调整自己的表达方式另一方原地踏步,关系或许会有改善但天花板很低因为沟通的鸿沟只填上了一半。训练过程也不是拍脑袋定的一两轮就完事论文进行了5轮查询侧和商品侧的交替训练。有意思的是从训练曲线看第一轮的提升最大从初始的约0.16跳到约0.28后面几轮的提升幅度逐渐变小、趋于平稳最终稳定在0.40左右。这说明这套交替共同进化的机制不仅有效而且是稳定收敛的不会训练着训着就跑飞了。关键词也在悄悄进化越来越精准、越来越像除了整体性能论文还专门分析了训练过程中关键词本身发生了什么变化这部分挺有意思能帮我们理解模型到底学到了什么。第一个发现是关键词变得越来越具体。训练前很多关键词是mobile移动的、fun有趣的这种放之四海而皆准的泛泛之词几乎不带信息量。训练之后这些笼统的词被淘汰取而代之的是cash management现金管理、survival horror生存恐怖这类更精准描述内容的多词短语。用数据说话单个词的关键词占比从37%降到了13%三个词及以上的长短语占比从12%涨到了31%。这个变化其实符合直觉。想想看如果你在应用商店搜好玩的游戏这个词太宽泛了几乎所有游戏App都能匹配上检索出来的候选集又大又不精准。但如果关键词是roguelike survival horror肉鸽生存恐怖能匹配上的商品范围一下子就收窄了精确率自然上升。强化学习用F1作为奖励本质上就是在惩罚这种广撒网但不精准的行为逼着模型往更具体、更有区分度的词汇上靠拢。第二个发现更有意思查询侧和商品侧的词汇量在训练过程中逐渐趋同。刚开始的时候商品侧词汇量很大因为商品描述本身信息量丰富查询侧词汇量很小用户的搜索词通常很短。但经过几轮训练之后两边的独特关键词数量逐渐接近,论文里给出的最终数字是商品侧约8.2万个查询侧约8.7万个,几乎收敛到同一个量级。这个现象恰好印证了前面提到的共同语言这个核心思路两个原本表达习惯完全不同的系统经过反复的博弈式训练居然真的在词汇丰富度上趋同了。这不是设计者提前规定好的而是训练过程自然涌现出来的结果挺让人意外的。多喂点信息效果还能更上一层楼论文还做了一个挺实用的补充实验如果给两个生成器多一点上下文信息效果会不会更好对商品侧默认输入包含应用的标题和描述。如果把描述去掉只留标题F1从0.3963掉到0.3759,说明描述里那些标题没法覆盖的细节信息确实在帮检索出力。对查询侧如果在提示词里加入现有搜索系统返回的搜索结果作为额外参考F1能从0.3963提升到0.4379。论文举了几个具体例子说明这个提升从哪来面对拼写错误、指代不清、涉及具体实体名称、或者非英语的查询比如中文查询解压软件额外的搜索结果能帮生成器先把查询的真实意图搞清楚再去生成关键词准确率自然更高。这个结果不算特别意外但很有实际意义:它说明CoGR这套框架不是封闭的可以很自然地接入更多外部信息源来进一步提升效果工程落地的灵活性还是有的。这项工作站在了哪些人的肩膀上又往前迈了一步检索这个领域的技术演进路径其实挺清晰的。稀疏检索的BM25之后出现了SPLADE这类学习式稀疏方法试图用神经网络学习词项权重而不是死板的统计公式。稠密检索这条线上DPR开创了双塔编码器的范式随后ANCE用更巧妙的负样本挖掘策略进一步提升效果GTR则把编码器规模做大来提升泛化能力。生成式检索这条线更年轻一些DSI最早提出用序列到序列模型直接生成文档的语义ID后续的RIPOR把检索导向的量化表示引入进来构建标识符。另外还有一条支线是用词汇本身作为标识符比如GENRE直接用文档标题、SEAL用文档子串这条路径和CoGR的关键词生成思路在精神上更接近。而利用大语言模型做检索反馈优化这个方向DeepRetrieval是一个关键的参照系,它训练一个LLM去改写查询、直接用检索指标作为奖励信号这个思路和CoGR的查询侧强化学习几乎是一致的。但DeepRetrieval止步于查询侧商品那端还是老一套的检索器。CoGR往前走的这一步就是把商品侧也纳入了同一套优化闭环让两边不再是一个进化、一个静止的不对称关系。论文里还提了一嘴这个思路和最近一些自我进化的LLM系统研究比如R-Zero、G-Zero这类工作在精神上是相通的多个角色互相博弈、共同进步而不是单方面被动接受监督信号。这算是给CoGR找到了一个更大的技术脉络归属。写在后面读完这篇论文最让我意外的一点其实是那个反事实边际奖励的设计。一开始我以为商品侧的奖励会直接照搬查询侧的逻辑,毕竟对称设计听起来很优雅。但论文用实验证明这种看似合理的对称设计Transposed F1反而效果更差。这说明检索系统里查询和商品的角色并不是完全对等的查询是发起方商品是被检索方评价一个商品关键词好不好天然应该放到整个检索系统的因果链条里去看而不是孤立地评价它自己检索能力强不强。这个细节让我重新想了一下很多看似对称的问题背后可能藏着不对称的因果结构直接照搬对称设计未必是最优解。另一个值得琢磨的地方是论文选的两个数据集都强调平均每个查询对应几百到上千个相关商品这和很多学术界常用的检索评测集往往一个查询只对应几个相关文档差异很大。这个选择其实暗含了研究者的一个判断真实的商业检索场景里相关性远比学术数据集里假设的要稠密得多这也是为什么F1这种精确率召回率平衡的指标比单纯的Top-K命中率更贴近业务实际需求。论文最后也留了一个开放的口子现在的排序阶段还是用BM25如果换成更强的排序模型这套框架的潜力还有多大空间没被挖出来这个问题我倒是挺想知道答案的。QAQ1CoGR是什么ACoGR是苹果研究团队提出的一种检索框架训练两个独立的大语言模型分别为用户查询和商品生成关键词两边生成的关键词通过倒排索引直接匹配完成检索同时兼容现有的关键词检索基础设施。Q2CoGR相比传统检索方法效果提升有多少A在苹果内部APP应用商店数据集上CoGR比最强基线方法F1分数提升了10.9%在公开的WANDS商品搜索数据集上提升幅度达到36.1%两个数据集上都超过了稀疏、稠密和生成式检索的十种代表性对比方法。Q3为什么CoGR要让查询侧和商品侧交替训练而不是同时训练A因为如果两侧同时变化每一方面对的匹配对象都是一直在晃动的目标训练会很不稳定。CoGR采用交替更新策略每次只训练一侧、冻结另一侧作为固定环境这样能让训练过程更稳定地收敛。