1. 移动搜索的查询处理到底难在哪移动搜索和桌面搜索看起来只是屏幕大小不一样但真正做过搜索链路的人都知道查询处理这一层在移动端几乎是另一套逻辑。桌面端用户输入长尾词的比例高有耐心翻页、改词、加筛选条件移动端用户平均查询长度更短输入成本高很多人打两三个字就点搜索了甚至直接用语音输入一整句话。这就导致同一个查询处理模块在两端面对的数据分布完全不同。我在实际项目里遇到过最典型的情况PC 端搜索“无线蓝牙耳机降噪入耳式长续航”能拿到不错的召回同样的词搬到移动端用户实际输入的是“蓝牙耳机”“降噪耳机”甚至“耳机”。如果查询处理层不做针对性优化移动端的点击率和首屏满足率会明显掉一截。这不是排序算法的问题而是查询理解这一层没有适配移动端的输入习惯。所谓查询处理通常包含这几个环节查询预处理归一化、纠错、同义扩展、分词与词权重、查询意图识别、查询改写与扩展、以及查询与文档的匹配策略。移动搜索优化技巧核心就是围绕这些环节针对移动端“短查询、强意图、弱耐心、多模态输入”的特点做调整。适合阅读这篇内容的人包括正在做搜索链路的工程师、搜索产品经理以及需要理解搜索行为差异的移动端开发者。下面我会按查询处理的实际链路把每个环节在移动端该怎么调、为什么这么调讲清楚。2. 移动端查询预处理从输入那一刻就开始优化2.1 短查询的归一化策略要更激进移动端查询短意味着单个字符的噪声占比更高。桌面端一个错别字可能只占查询的十分之一移动端可能占三分之一。所以移动端的归一化不能照搬桌面端的阈值。我的经验是移动端查询预处理要把编辑距离阈值收紧同时把拼音纠错的优先级提高。具体来说移动端输入法联想和滑行输入会产生大量“音近形不近”的错误比如“降噪”打成“将噪”、“续航”打成“徐航”。这类错误用传统的字形编辑距离很难纠正但用拼音编辑距离就很容易命中。实际操作中我会在预处理阶段先做拼音转换再算拼音层面的编辑距离阈值设在 1 到 2 之间超过 2 就不纠避免把用户真实输入的长尾词改坏。另一个细节是数字和单位的处理。移动端用户经常输入“1000以内”“5g手机”“24寸”这些查询里的数字和单位如果被分词切碎召回会很难看。我的做法是在预处理阶段用正则先把“数字单位”的模式识别出来作为一个整体 token 保留再交给后面的分词模块。这个改动看起来小但在移动端电商搜索里对价格区间类查询的召回提升非常明显。2.2 语音输入的查询要单独走一条通道移动端语音输入的比例远高于桌面端而语音识别的结果和键盘输入有本质区别没有标点、同音字错误多、口语化表达多。比如用户说“帮我找一下附近评分高的火锅店”语音识别出来可能是“帮我找一下附近评分高的火锅店”但如果是短语音可能变成“附近高评分火锅”。我的处理方式是给语音来源的查询打上标记在预处理阶段走一条单独的通道先做口语化停用词去除“帮我”“找一下”“我想”这类再做同音字纠错最后再做常规归一化。这条通道和键盘输入通道并行最后在意图识别层合并。实测下来语音查询的纠错准确率比统一处理能高出不少因为口语化停用词如果不先去掉会干扰后面的分词和意图判断。注意语音通道的纠错词典要和键盘通道分开维护。键盘输入的错字往往是形近语音输入的错字往往是音近混在一起维护会让两边都变差。2.3 输入框的实时联想也是查询处理的一部分很多人把输入框联想当成前端功能其实它和查询处理强相关。移动端用户输入成本高联想词的质量直接影响最终提交的查询。我的做法是把联想词和查询处理层打通用户输入前缀时查询处理层实时返回高频完整查询、纠错后的查询、以及同义扩展查询前端按优先级展示。这里有个经验移动端联想词不要给太多3 到 5 个足够而且第一个必须是纠错后的查询。因为移动端屏幕小用户视线集中在输入框附近给太多选项反而增加选择成本。另外联想词要带热度排序但热度不能只看全局要结合用户历史行为和当前位置做个性化否则会出现“所有人都看到同一个联想词”的尴尬情况。3. 分词与词权重短查询里每个字都很贵3.1 移动端分词粒度要偏粗桌面端查询长分词粒度细一点没关系因为上下文足够多切错了也能靠其他词救回来。移动端查询短分词粒度太细会导致语义碎片化。比如“红色连衣裙”如果切成“红色”“连衣”“裙”召回和排序都会受影响切成“红色”“连衣裙”就合理得多。我的策略是移动端分词优先保证“最小完整语义单元”宁可粗一点不要细碎。具体实现上可以在分词模型里对移动端查询加一个长度惩罚项查询越短越倾向于合并相邻词。这个惩罚项的系数需要根据业务语料调我一般从 0.3 开始试观察 badcase 再微调。另外移动端查询里的英文和数字要特殊处理。“iphone15pro”这种连写如果不做拆分分词器可能直接当成一个未知词。我的做法是在分词前先做一次“字母数字边界检测”把“iphone15pro”拆成“iphone”“15”“pro”再分别处理。这个步骤在移动端尤其重要因为用户懒得打空格。3.2 词权重计算要引入移动端行为特征传统的词权重靠 TF-IDF 或者 BM25这些是全局统计特征没有考虑移动端的特殊性。我在实际项目里会额外引入几个移动端行为特征来调整词权重输入位置权重查询开头的词权重更高因为移动端用户习惯把核心词放在最前面。点击反馈权重如果某个词在移动端历史点击中被频繁点击说明它更能代表用户意图权重上调。纠错来源权重如果某个词是纠错后得到的权重适当下调因为纠错有不确定性。这些特征不需要很复杂的模型用简单的线性加权就能见效。我试过在移动端电商搜索里加这三个特征首屏点击率有可感知的提升。关键是这些特征的计算要轻量移动端查询处理的延迟预算很紧不能为了算权重拖慢整体响应。3.3 停用词表要针对移动端单独裁剪桌面端的停用词表直接拿到移动端用往往会误伤。因为移动端查询短很多在桌面端是停用词的词在移动端可能是核心词。比如“的”在桌面端可以去掉但移动端用户输入“我的订单”“我的收藏”这个“的”去掉后语义就变了。我的做法是移动端停用词表只保留真正的功能词比如“啊”“呢”“吧”这类语气词以及“帮我”“请问”这类口语化前缀。像“的”“了”“在”这些在移动端查询里要谨慎处理最好结合查询长度判断查询长度大于 5 个字时可以去小于等于 5 个字时保留。这个规则简单但有效能避免很多误伤。4. 用户意图识别移动端要猜得更准4.1 移动端意图分类的类别要更粗桌面端意图分类可以分得很细比如“商品购买意图”“信息查询意图”“导航意图”“对比意图”等等。移动端如果也分这么细模型很难在短查询上做出准确判断因为特征太少。我的经验是移动端意图分类先分三大类导航类用户想直接去某个站点或页面、事务类用户想完成某个操作比如购买、预订、信息类用户想获取信息。这三类在移动端的行为差异最明显也最容易通过点击行为验证。分类粗不代表效果差。实际上移动端用户意图往往更明确因为输入成本高用户不会随便搜。所以只要把这三类分准后面的排序和展现策略就能做得很不一样。比如导航类查询直接给跳转入口事务类查询给转化组件信息类查询给内容聚合。这比在细分类别上纠结要实用得多。4.2 用会话上下文补足短查询的信息量移动端搜索经常是多轮会话用户搜一次不满意会接着改词再搜。这个会话上下文是移动端意图识别的金矿。比如用户先搜“火锅”再搜“附近”再搜“评分高”单独看每个查询都很短但连起来看意图非常清晰找附近评分高的火锅店。我的做法是在查询处理层维护一个轻量的会话状态记录最近 3 到 5 次查询和点击行为。当当前查询很短时用会话状态里的历史查询做意图补全。具体实现上可以把历史查询的向量表示和当前查询的向量表示拼接再送进意图分类模型。这个改动不需要改模型结构只是输入特征变了但效果提升很明显。提示会话状态的过期时间要设短移动端用户切换任务很快超过 10 分钟的会话上下文基本没有参考价值反而会引入噪声。4.3 位置和时间是移动端意图的强信号移动端搜索和桌面端最大的区别之一是位置和时间几乎总是可用的。用户搜“咖啡”在写字楼附近和在学校附近意图可能完全不同早上搜“早餐”和晚上搜“早餐”意图也不一样。这些信号在桌面端往往拿不到或者不准确但在移动端是天然优势。我在查询处理层会把位置和时间作为意图识别的特征直接输入。位置不用太精确商圈级别就够时间按小时粒度处理。这两个特征加上查询本身就能把很多短查询的意图区分开。比如“咖啡”在写字楼附近早上搜大概率是外带咖啡在商场附近下午搜可能是堂食。这个判断不需要很复杂的模型规则加简单分类器就能做到。5. 查询改写与扩展移动端要克制5.1 移动端改写要少而准桌面端查询改写可以做得比较激进因为用户查询长改写错了还有其他词兜底。移动端查询短改写错了整个查询就废了。所以移动端改写的第一原则是宁可少改不可改错。我的做法是移动端只做两类改写纠错改写和同义改写。纠错改写必须有高置信度才执行置信度低于阈值的只做提示不改写。同义改写只做高频同义词比如“手机”和“移动电话”、“耳机”和“耳麦”低频同义词不碰。扩展查询比如加同义词、加相关词在移动端要非常谨慎因为扩展词会稀释原始查询的权重短查询经不起稀释。实测下来移动端改写率控制在 15% 到 25% 之间比较健康超过 30% 就容易出现改写错误导致的 badcase。这个比例不是绝对的要根据业务语料调但核心思路是移动端改写要克制。5.2 改写效果要用点击反馈闭环验证改写做得好不好不能只看离线指标要看线上点击反馈。我的做法是给每个改写策略打上标记在日志里记录改写前后的查询和用户点击行为。如果某个改写策略的点击率低于原始查询就降权或下线如果高于原始查询就加权。这个闭环不需要很复杂的系统用 A/B 测试框架就能做。关键是改写策略要可配置、可回滚不能写死在代码里。我见过很多团队把改写规则硬编码结果线上出问题只能发版解决响应太慢。移动端搜索的查询分布变化快改写策略必须能快速调整。5.3 别忽略“不改写”也是一种策略很多团队做查询处理总想着怎么改写、怎么扩展但忽略了“不改写”本身也是一种策略。移动端短查询里有相当一部分是明确的导航词或品牌词比如“淘宝”“微信”“美团”这些查询不需要任何改写直接走导航通道最快。我的做法是在查询处理层加一个“免改写白名单”命中白名单的查询直接跳过改写和扩展走最短路径。这个白名单可以基于高频查询自动生成也可以人工维护。别小看这个优化它能显著降低查询处理延迟因为白名单查询占比往往不低。6. 查询与文档匹配移动端排序的隐藏变量6.1 匹配策略要区分查询类型移动端查询处理完最终要落到和文档的匹配上。不同类型的查询匹配策略应该不一样。导航类查询要精确匹配事务类查询要匹配转化组件信息类查询要匹配内容主体。如果统一用一套匹配策略效果一定打折扣。我在实际项目里会把查询意图作为匹配策略的路由信号。导航类查询走精确匹配加站点权重事务类查询走商品或服务匹配加转化率权重信息类查询走内容匹配加质量权重。这个路由逻辑不复杂但能让每个类型的查询都用最适合的匹配方式整体效果提升明显。6.2 移动端排序要引入设备特征移动端排序和桌面端排序的差异不只是屏幕大小。设备性能、网络状况、屏幕分辨率这些特征都会影响用户对搜索结果的满意度。比如低端机上加载慢的结果用户可能没看到就划走了这个结果的质量再高也没用。我的做法是在排序模型里加入设备特征设备档次、网络类型、屏幕尺寸。低端机加弱网环境下排序要偏向轻量结果高端机加 WiFi 环境下可以偏向内容丰富的结果。这个特征在离线评估里看不出效果但线上 A/B 测试里对停留时长和点击率有正向影响。6.3 首屏结果要单独优化移动端首屏只有 3 到 5 个结果位用户大部分点击都发生在首屏。所以查询处理层要针对首屏做特殊优化。我的做法是把首屏结果的匹配阈值调高确保首屏结果和查询意图高度相关同时首屏结果的多样性要控制不能全是同一类型的结果否则用户会觉得“搜出来的都一样”。具体实现上可以在排序后加一个首屏重排模块对首屏结果做多样性约束和相关性兜底。这个模块不需要很复杂简单的规则就能见效。比如首屏至少包含一个导航类结果、一个信息类结果或者首屏结果来自至少两个不同站点。这些规则能显著提升首屏满足率。7. 实测中的几个坑和应对7.1 纠错过度导致长尾查询被改坏移动端纠错阈值收紧后长尾查询容易被误纠。比如用户搜一个冷门品牌名拼音和某个常见词接近就被纠成常见词了。这个坑我踩过后来加了一个“长尾保护”规则查询在历史日志里出现次数低于阈值的纠错置信度要求更高否则不纠。这个规则的本质是高频查询纠错错了影响大但纠错对了收益也大低频查询纠错错了影响小但纠错对了收益也小。所以低频查询不值得冒纠错错误的风险。这个逻辑听起来简单但实际做的时候很容易忽略。7.2 会话上下文引入噪声会话上下文用得好能补足短查询用得不好会引入噪声。我遇到过用户先搜“火锅”再搜“电影”如果会话上下文权重太高搜“电影”时可能还会带出火锅相关的结果。后来我把会话上下文的权重和查询长度挂钩查询越短上下文权重越高查询越长上下文权重越低。这样既能在短查询时补足信息又不会在查询已经明确时引入噪声。7.3 改写策略和排序策略打架查询改写和排序是两套逻辑如果各自优化很容易打架。比如改写层把“手机”改成“智能手机”排序层却认为“手机”权重更高结果改写后的查询反而排得不好。我的做法是把改写信息和排序特征打通改写后的查询在排序时带上改写标记排序模型知道这个查询是改写来的会适当调整权重。这个打通不需要改模型结构只是在特征里加一个改写标记位。但这个小改动能避免很多改写和排序不一致的问题。我建议做查询处理的团队一定要和排序团队对齐特征定义否则两边各自优化最后效果互相抵消。8. 个人经验移动搜索查询处理的优先级如果让我给移动搜索查询处理的优化排优先级我会这么排第一是预处理和纠错因为这是所有后续环节的基础预处理做不好后面全白搭第二是意图识别因为移动端意图明确识别准了后面策略就好做第三是改写和扩展这个要克制宁少勿多第四是匹配和排序这个和查询处理强相关但更多是排序团队的主场。还有一个经验是移动搜索查询处理的优化一定要看线上数据不能只看离线指标。离线指标好的策略线上不一定好因为移动端用户行为太复杂了。我习惯每周看一次查询处理的 badcase手动分析几十个 case比看一堆报表更有用。badcase 里往往藏着最真实的用户需求也藏着最值得优化的点。最后分享一个小技巧移动端查询处理的日志一定要记全包括原始查询、预处理后查询、纠错结果、改写结果、意图分类结果、最终匹配结果。这些日志串起来就是一个完整的查询处理链路。出问题时能快速定位是哪一环的问题做优化时也能清楚知道改动影响了哪一环。这个日志规范看起来是小事但实际做起来能省很多排查时间。
