1. 移动搜索优化的底层逻辑与核心挑战1.1 移动场景到底改变了什么做了七八年搜索相关的工作我越来越觉得移动搜索优化这件事本质上不是把PC端那套东西搬到手机上那么简单。你得先想明白一个根本问题用户在手机上搜东西的时候跟坐在电脑前搜东西到底有什么本质区别我自己的总结是三个字碎、急、浅。“碎”指的是使用场景碎片化。用户可能在地铁上、在排队、在走路搜索行为随时被打断随时又继续。这意味着你的查询处理链路必须足够快首屏结果必须在极短时间内呈现否则用户直接关掉页面重新搜。“急”指的是意图表达急促。手机输入成本高用户懒得打完整句子往往就是两三个关键词丢进去。比如“附近火锅”“明天天气”“快递单号查询”这种极简查询背后隐藏的意图识别难度反而更大。“浅”指的是浏览深度浅。移动端屏幕小用户注意力集中在前几条结果上翻页率远低于PC端。这就对排序算法的精准度提出了更高要求——你必须在最前面几条就把用户最想要的结果给出来。这三个特点决定了移动搜索优化的核心方向查询处理要轻量化、意图识别要精准化、排序策略要场景化。后面我会围绕这三个方向逐一拆解。1.2 查询处理在移动搜索中的定位查询处理是整个搜索链路的第一道关口。用户输入一串字符系统需要完成一系列处理才能拿去检索和排序。这条链路大致包括查询分词、查询纠错、查询改写、查询扩展、意图分类、实体识别等环节。在PC端因为输入相对规范、查询长度较长查询处理的压力其实还好。但到了移动端输入法联想、语音输入、手写输入等各种方式混杂查询的噪声大幅增加。我见过太多案例用户搜“苹guo手机”或者语音输入把“三里屯”识别成“三里顿”如果查询处理环节没有做好纠错和改写后面的检索和排序再牛也是白搭。所以我的经验是移动搜索优化七成功夫在查询处理。这个判断可能有些激进但实际做下来确实如此。排序算法固然重要但如果查询本身没有被正确理解排序就是在错误的方向上做优化。1.3 移动端适配对查询处理提出的新要求移动端适配不只是响应式布局那点事。从查询处理的角度看移动端适配至少带来三个新要求第一多模态输入的融合处理。语音搜索在移动端的占比越来越高语音识别结果往往带有口语化特征比如“帮我找一下那个什么来着”这种查询需要做特殊的口语化归一处理。第二地理位置信号的深度利用。移动设备天然携带位置信息查询处理阶段就应该把位置信号融入意图判断。搜“加油站”在高速公路上和在市区步行街用户想要的结果完全不同。第三时效性敏感度的提升。移动搜索中大量查询带有强时效性比如“现在堵不堵”“今天有什么电影”查询处理需要能够识别时效意图并打上相应标签供后续排序使用。这三点如果不在查询处理阶段解决指望排序阶段去弥补效果会大打折扣。我后面会结合具体案例来讲怎么落地。2. 查询处理链路的关键环节拆解2.1 分词与归一化移动端的第一道坎分词这件事在中文搜索里是老生常谈但移动端有它的特殊性。我拿一个实际案例来说用户输入“上海虹桥火车站到浦东机场怎么走”。PC端的分词器大概率会切成“上海/虹桥/火车站/到/浦东/机场/怎么/走”这个切分没问题。但移动端用户可能输入的是“虹桥火车站到浦东机场”省略了“上海”或者输入“虹桥站到浦东机场”用了简称。如果分词词典里没有“虹桥站”这个简称就可能切成“虹桥/站/到/浦东/机场”语义就变了。我的做法是维护一套移动端专用的简称词典和别名库。这个词典不是静态的而是通过分析移动端搜索日志持续更新的。具体来说我会定期跑一个流程把移动端高频查询中出现的未登录词捞出来人工审核后加入自定义词典。这个工作看起来笨但效果非常明显。归一化方面移动端需要特别处理的有几类全半角混用用户可能输入“iPhone”数字是全角的需要归一化大小写混用搜“nike”和“NIKE”应该走同一套检索逻辑繁简混用虽然现在输入法基本统一了但偶尔还是会出现标点符号噪声移动端输入容易带入多余标点比如“北京天气”这些归一化操作必须在分词之前完成否则会直接影响分词结果的准确性。2.2 查询纠错不只是改错别字查询纠错在移动端的重要性怎么强调都不过分。移动端输入错误率远高于PC端原因很简单屏幕小、按键密、输入快。我统计过我们自己的日志移动端查询中包含疑似错误的查询占比超过15%这个数字相当惊人。但查询纠错不只是改错别字那么简单。我把移动端的查询错误分成几类每类的处理策略不同错误类型典型示例处理策略拼音错误“zhongguo”打成“zhonggu”拼音编辑距离纠错形近字错误“天气”打成“天汽”字形相似度纠错语音识别错误“三里屯”识别成“三里顿”音近纠错上下文验证输入法联想错误想打“航班”出来“航班动态”查询截断与候选生成多字/少字“北京大学”打成“北京学”编辑距离词频验证这里面的难点在于你怎么判断一个查询到底是有错误还是本身就是一个长尾查询。比如“天汽”这个词它可能确实是某个用户想搜“天气”打错了但也可能是一个汽车相关品牌或者某个小众领域的术语。如果无脑纠错就会伤害长尾查询的召回。我的经验是采用分级纠错策略第一级高置信度纠错。查询本身没有检索结果或者结果极少且纠错候选的检索结果丰富直接纠错。第二级低置信度纠错。查询本身有结果但纠错候选的结果质量明显更高此时不直接纠错而是在结果页顶部提示“您是不是要找XXX”。第三级不纠错。查询本身结果丰富且质量不错即使看起来像错误也不纠错。这个分级策略的核心依据是检索结果反馈而不是单纯依赖语言模型。我试过纯语言模型的方案在移动端场景下误纠率偏高后来加入了检索结果验证环节效果才稳定下来。2.3 查询改写与扩展让短查询也能有好结果移动端查询短这是不争的事实。用户搜“苹果”他到底是想买苹果手机、吃苹果、还是看苹果公司的新闻在PC端用户可能会搜“苹果手机最新款价格”意图很明确。但在移动端就是两个字“苹果”。查询改写和扩展就是解决这个问题的。我的做法是构建一个查询改写候选生成排序的框架候选生成阶段我会从几个来源生成改写候选基于点击日志的共现关系如果大量用户在搜“苹果”之后又搜了“苹果手机”那“苹果手机”就是“苹果”的一个改写候选基于知识图谱的实体关联苹果作为一个实体关联到苹果公司、苹果手机、苹果水果等多个义项基于会话上下文的改写如果用户上一个查询是“手机推荐”当前查询是“苹果”那大概率是延续手机这个主题基于地域的改写结合用户位置信息比如在商圈附近搜“苹果”更可能是苹果零售店候选排序阶段我会综合考虑几个特征候选查询的历史点击率候选查询与原始查询的语义相似度候选查询在当前场景下的时效性得分候选查询的个性化匹配度这里有个坑我踩过改写不能过度。早期我们做改写的时候恨不得把“苹果”改写成十几个候选结果排序阶段压力巨大而且经常把用户真正想要的结果给改没了。后来我定了一个原则改写候选不超过5个且必须保留原始查询的检索通路。也就是说原始查询的结果该出还是要出改写只是补充不是替代。2.4 意图识别移动搜索优化的胜负手如果让我选一个移动搜索优化中最关键的环节我会毫不犹豫地选用户意图识别。查询处理的其他环节都是为意图识别服务的而排序算法又依赖意图识别的结果。移动端的意图识别有几个独特挑战第一查询短导致意图模糊。前面说的“苹果”就是典型例子。我的处理方式是引入场景信号来消歧。场景信号包括时间、地点、设备类型、用户历史行为、当前会话上下文等。比如早上7点搜“苹果”更可能是想找水果店或者苹果相关新闻晚上8点在商圈搜“苹果”更可能是想找苹果零售店。第二意图粒度要求更细。PC端可能只需要区分“导航意图”“购买意图”“信息意图”就够了但移动端需要更细。比如同样是“购买意图”还需要区分“比价”“找优惠券”“直接下单”等子意图。因为移动端的转化路径更短用户期望一步到位。第三意图切换频繁。移动端用户经常在一个会话中切换意图。比如先搜“附近餐厅”然后搜“餐厅评价”然后搜“餐厅优惠券”。这三个查询的意图是递进的如果意图识别系统不能捕捉到这种递进关系就会导致推荐结果不连贯。我的意图识别框架大致是这样的输入层原始查询 归一化查询 改写候选 场景信号特征层查询文本特征 用户行为特征 场景上下文特征 知识图谱特征模型层多分类模型粗粒度意图 多标签模型细粒度意图 序列模型会话意图追踪输出层意图标签 置信度 时效性标签 地域性标签这个框架在实际部署中我特别想强调序列模型的重要性。很多团队做意图识别只做单查询级别忽略了会话级别的意图追踪。但在移动端会话意图追踪能显著提升体验。比如用户先搜了“北京到上海高铁”然后搜“票价”如果系统能识别出这是同一个出行意图的延续就可以直接把票价信息嵌入到高铁结果中用户不需要再点进去看。3. 移动端排序算法的场景化调优3.1 排序算法的基本框架与移动端差异排序算法这块PC端和移动端的基本框架其实差不多都是召回粗排精排重排的漏斗结构。但每个环节在移动端都有不同的侧重点。召回阶段移动端更强调多样性召回。因为移动端屏幕小用户翻页少如果召回的结果同质化严重用户很快就失去耐心。我的做法是在召回阶段就引入多样性约束比如同一个域名下的结果最多召回N条同一个内容类型的结果最多召回M条。粗排阶段移动端更强调效率。移动端对响应时间的要求比PC端高得多粗排模型不能太复杂。我一般用轻量级的GBDT或者双塔模型做粗排把候选集从几千条降到几百条。精排阶段移动端更强调特征丰富度。因为精排的候选集已经比较小了可以上更复杂的模型和更多的特征。移动端特有的特征包括设备类型、网络状况、屏幕尺寸、用户当前位置、用户移动状态步行/驾车/静止等。重排阶段移动端更强调业务规则和多样性。重排阶段通常会加入一些硬性规则比如前三条结果不能来自同一个站点必须包含至少一条时效性内容等。3.2 移动端特有的排序特征工程特征工程是排序算法的核心。移动端有一些PC端没有的特征我列一下我认为最重要的几类位置特征用户当前位置与结果中POI的距离用户所在城市与结果地域的匹配度用户移动速度通过GPS轨迹判断是步行还是驾车设备特征设备类型手机/平板操作系统影响App调起能力屏幕尺寸影响结果展示形式网络类型WiFi/4G/5G影响富媒体内容的加载策略时间特征查询时间点早上/中午/晚上/深夜查询时间与结果时效性的匹配度用户历史活跃时间段行为特征用户历史点击序列用户历史搜索序列用户在当前会话中的行为路径这些特征中我认为位置特征和时间特征是移动端排序优化的最大增量点。我做过AB实验加入位置特征后本地生活类查询的点击率提升了超过20%。加入时间特征后时效性查询的满意度提升了15%以上。3.3 排序模型的轻量化部署策略移动端排序模型面临一个矛盾模型越复杂效果越好但移动端对响应时间的要求又极其苛刻。我的解决思路是分级部署云端精排复杂的深度模型放在云端处理精排阶段。但要注意控制模型推理时间我一般要求单次推理不超过50ms。端侧粗排轻量级模型放在端侧处理粗排甚至部分精排工作。端侧模型的好处是响应快、不依赖网络但模型容量有限。我一般用模型蒸馏的方式把云端大模型的能力迁移到端侧小模型。端云协同对于特别复杂的场景采用端侧先粗筛、云端再精排的协同方式。这种方式需要处理好端云之间的通信延迟和数据一致性。这里有个经验不要追求单次排序的完美而是追求多轮交互的整体最优。移动端用户和搜索系统之间往往有多轮交互第一轮排序不需要把所有好结果都堆到前面而是要给用户留下探索的空间根据用户的反馈在后续轮次中动态调整。3.4 多目标排序在移动端的落地移动搜索的排序目标从来不是单一的。点击率重要转化率也重要用户停留时长、分享率、回访率都重要。多目标排序在移动端尤其重要因为移动端的用户行为更丰富可以采集到的反馈信号更多。我的多目标排序框架一般包含这几个目标相关性目标结果与查询的语义匹配度质量目标结果本身的内容质量时效性目标结果的时效性得分个性化目标结果与用户兴趣的匹配度商业目标结果的商业价值如广告、佣金等这些目标之间有时候是冲突的。比如商业价值高的结果可能相关性不是最好的。我的处理方式是加权求和约束优化给每个目标分配一个权重同时设置一些硬性约束如相关性得分低于阈值的结果不能进入前三。权重的设定不是拍脑袋决定的而是通过在线学习动态调整的。我会根据用户的实时反馈信号点击、跳过、停留时长等来调整各目标的权重。这个机制在移动端特别有效因为移动端的用户反馈更即时、更密集。4. 移动搜索优化的实战避坑指南4.1 常见问题速查表在实际做移动搜索优化的过程中我遇到过太多坑了。下面这张表是我整理的高频问题速查表希望能帮你少走弯路问题现象可能原因排查方向解决方案移动端结果与PC端差异大排序特征不一致对比两端特征工程统一特征口径移动端增加特有特征短查询结果差意图识别不准检查短查询的意图分类准确率引入场景信号做查询改写语音搜索效果差语音识别错误传导检查语音识别准确率增加语音专用纠错模块本地搜索结果不相关位置信号利用不足检查位置特征权重提升位置特征权重做距离衰减首屏加载慢排序模型太重检查模型推理耗时模型轻量化端云协同翻页率异常低首屏结果质量差分析首屏点击分布优化精排模型增加多样性时效性查询结果旧时效性标签缺失检查时效性识别模块增加时效性分类器提升时效权重个性化过度用户画像噪声大检查用户画像准确率引入置信度阈值低置信度不个性化这张表里的每一条都是我实际踩过的坑。比如“个性化过度”这一条早期我们做个性化排序的时候因为用户画像不够准确导致推荐结果偏离用户真实意图用户反而更不满意。后来我们引入了置信度阈值只有当用户画像的置信度超过一定阈值时才启用个性化低于阈值就走通用排序效果才稳定下来。4.2 实操心得从日志中挖掘优化点我想特别分享一下如何从搜索日志中挖掘优化点。这件事看起来基础但真正做深做透的团队不多。我的日志分析流程一般是这样的第一步查询聚类。把移动端搜索日志中的查询按照意图进行聚类看看哪些意图的查询量最大、满意度最低。满意度可以用点击率、换查询率、无结果率等指标来衡量。第二步失败案例归因。对于满意度低的查询逐条分析失败原因。是分词错了纠错错了改写错了还是排序错了这个工作很繁琐但价值极高。我一般会抽样几百条失败案例人工标注失败原因然后统计各类原因的占比。第三步优先级排序。根据失败原因的占比和修复成本确定优化优先级。占比高且修复成本低的先做占比低且修复成本高的后做。第四步AB实验验证。任何优化上线前都要经过严格的AB实验。移动端的AB实验要注意样本偏差问题比如不同机型的用户行为差异很大实验组和对照组的机型分布要尽可能一致。这套流程我跑了几年基本上每轮都能挖出十几个可优化的点。其中有些优化点的收益远超预期比如我们曾经发现“附近”类查询的失败率特别高深入分析后发现是位置信号的衰减函数设置不合理调整后本地搜索的满意度直接提升了十几个百分点。4.3 避坑技巧移动搜索优化中的三个不要最后分享三个我在移动搜索优化中总结的“不要”第一不要照搬PC端的排序权重。PC端和移动端的用户行为差异太大了PC端有效的权重在移动端可能完全失效。我见过一个团队直接把PC端的排序模型搬到移动端结果点击率掉了三成。后来重新训练移动端专用模型才恢复过来。第二不要忽视长尾查询。移动端的长尾查询占比比PC端更高因为移动端的输入方式更随意。如果只优化头部查询整体满意度很难提升。我的做法是专门为长尾查询建立一套轻量级的处理链路虽然单条查询的收益不大但积少成多整体收益很可观。第三不要过度依赖离线指标。离线指标如NDCG、MAP和在线指标如点击率、转化率之间往往有差距。我见过太多次离线指标提升但在线指标下降的情况。所以任何优化都必须经过在线AB实验验证离线指标只作为参考。4.4 一个真实案例的完整复盘说一个我亲自经手的案例。我们曾经发现移动端“附近”类查询的满意度持续偏低用户搜“附近加油站”“附近餐厅”结果往往不准确。排查过程是这样的首先看日志发现“附近”类查询的点击率只有普通查询的一半左右。然后抽样分析失败案例发现主要问题是位置信号没有被正确使用。具体来说我们的位置衰减函数设置得太陡了导致距离用户稍远但质量更高的结果被排到了后面。进一步分析发现不同意图的查询对距离的敏感度是不一样的。搜“附近加油站”用户对距离极其敏感超过2公里就不考虑了。但搜“附近餐厅”用户对距离的容忍度更高可能5公里内的优质餐厅也会考虑。于是我们做了一个意图感知的距离衰减函数根据查询意图动态调整距离衰减的斜率。加油站类查询用陡峭的衰减餐厅类查询用平缓的衰减。这个优化上线后“附近”类查询的点击率提升了接近30%用户换查询率下降了20%多。这个案例让我深刻体会到移动搜索优化没有一招鲜必须深入到具体场景中去打磨。5. 查询处理与排序算法的协同优化5.1 为什么查询处理和排序不能分开优化很多团队在组织架构上就把查询处理和排序算法分成两个独立的组各做各的优化。这种做法在PC端可能问题不大但在移动端会出大问题。原因很简单移动端的查询处理和排序算法之间的耦合度远高于PC端。查询处理阶段产出的意图标签、改写候选、时效性标签等直接作为排序算法的输入特征。如果查询处理阶段的信息有误排序算法再优化也是白费。我举一个实际例子。用户搜“明天天气”查询处理阶段识别出这是一个时效性查询打上了“时效性-高”的标签。排序算法拿到这个标签后会优先展示最新的天气预报结果。但如果查询处理阶段没有识别出时效性排序算法就会把历史天气数据也排到前面用户体验就很差。所以我的建议是查询处理和排序算法必须联合优化。具体做法包括建立联合的评估指标体系不只看查询处理的准确率也看最终排序结果的满意度定期做端到端的badcase分析从最终结果反推是查询处理的问题还是排序的问题在模型层面做联合训练让查询处理的输出直接针对排序目标进行优化5.2 端到端优化的一种可行路径端到端优化听起来很美好但实际落地难度很大。我分享一种我们实践下来比较可行的路径分阶段端到端。具体来说不是把整个搜索链路做成一个巨大的端到端模型而是把链路切成几个阶段每个阶段内部做端到端阶段之间通过标准化的接口衔接。比如第一阶段原始查询 → 归一化查询 纠错候选 改写候选 意图标签第二阶段归一化查询 候选 标签 → 召回结果集第三阶段召回结果集 标签 → 排序结果每个阶段内部可以用端到端模型但阶段之间的接口要标准化、可解释。这样既保留了端到端优化的收益又避免了完全黑盒带来的不可控性。我们在第三阶段做了端到端优化把意图标签直接作为排序模型的输入特征让排序模型自己学习如何利用这些标签。效果比人工设定规则好了很多因为模型可以发现一些人没有意识到的特征交互关系。5.3 协同优化中的评估体系设计协同优化的一个关键难点是评估体系的设计。如果查询处理和排序算法各自有自己的评估指标那协同优化的效果就很难衡量。我的做法是建立一套分层评估体系第一层组件级指标。查询处理的准确率、召回率排序算法的NDCG、MAP等。这些指标用于日常监控和快速迭代。第二层链路级指标。从查询到最终结果的端到端满意度可以用人工评估或者用户行为信号如点击率、换查询率、停留时长来衡量。第三层业务级指标。最终的商业转化率、用户留存率、DAU等。这三层指标之间要有明确的映射关系。比如组件级指标提升多少能带动链路级指标提升多少进而带动业务级指标提升多少。这个映射关系需要通过大量的AB实验来建立。我特别想强调的是不要只看组件级指标。我见过太多团队组件级指标很漂亮但业务级指标没变化。原因就是组件级指标和业务级指标之间的映射关系没有建立好优化方向偏了。5.4 未来可以探索的方向虽然题目是移动搜索优化技巧但我觉得有必要聊一下未来可以探索的方向因为技术迭代太快了。第一个方向是大模型在查询处理中的应用。大模型在语义理解方面的能力远超传统模型可以用来做更精准的意图识别和查询改写。但挑战也很明显推理成本高、响应延迟大。我的思路是用大模型做离线蒸馏把能力迁移到小模型上在线还是用小模型。第二个方向是多模态搜索。移动端天然支持拍照、语音等多种输入方式多模态搜索是移动端独有的机会。比如用户拍一张花的照片搜索“这是什么花”查询处理需要融合图像和文本两种模态的信息。第三个方向是隐私保护下的个性化。移动端用户对隐私越来越敏感如何在保护隐私的前提下做个性化排序是一个重要课题。联邦学习、差分隐私等技术值得关注。这些方向我都在跟进有些已经做了原型验证效果还不错。但技术落地需要时间急不得。6. 从实战中沉淀的方法论6.1 移动搜索优化的优先级判断做了这么多年的移动搜索优化我最大的体会是优化要有优先级不能眉毛胡子一把抓。我的优先级判断框架是这样的第一优先级查询理解准确性。如果查询理解都不准后面的排序优化都是白费。所以我会优先投入资源做分词、纠错、改写、意图识别这些基础能力。第二优先级首屏结果质量。移动端用户主要看首屏首屏结果的质量决定了用户对搜索的整体印象。所以我会优先优化前几条结果的排序。第三优先级响应速度。移动端用户对速度极其敏感响应速度慢会直接导致用户流失。所以我会持续优化查询处理和排序算法的效率。第四优先级个性化与场景化。在基础能力扎实之后再考虑个性化和场景化的优化。这些优化能带来增量收益但前提是基础能力已经做好了。这个优先级框架不是绝对的不同产品阶段可能不一样。但大方向是这样先做好基础再做增量。6.2 团队协作中的经验教训移动搜索优化不是一个算法团队能独立完成的需要算法、工程、产品、运营多个角色协同。我在团队协作中踩过不少坑分享几个教训教训一算法和工程要早期介入。很多优化方案在算法层面可行但工程落地成本极高。如果工程团队不早期介入方案可能根本落不了地。我的做法是算法和工程一起做方案设计确保方案在技术和工程上都可行。教训二产品经理要懂技术边界。产品经理提出的需求有时候超出了当前技术能力。如果产品经理不懂技术边界就会提出不切实际的需求。我的做法是定期给产品经理做技术分享让他们了解当前技术能做什么、不能做什么。教训三运营团队要参与评估。运营团队最了解用户他们的反馈对优化方向很有价值。我的做法是让运营团队参与badcase评估从用户视角判断搜索结果的好坏。6.3 个人成长路径建议如果你刚进入移动搜索优化这个领域我建议的成长路径是这样的第一阶段熟悉基础链路。先搞清楚查询处理、召回、排序、重排每个环节在做什么数据怎么流转指标怎么计算。这个阶段要多看文档、多问同事。第二阶段深入一个环节。在熟悉全链路之后选择一个环节深入下去比如查询处理或者排序算法。把这个环节的细节吃透成为这个环节的专家。第三阶段打通全链路。在深入一个环节之后再回到全链路视角理解各个环节之间的协同关系。这个阶段要开始做端到端的优化。第四阶段形成方法论。在做了多个优化项目之后开始总结自己的方法论。什么场景用什么方法什么指标反映什么问题这些经验要沉淀下来。我自己大概花了三年时间走完这四个阶段。每个人的节奏不一样但大方向是这样。6.4 一个值得反复琢磨的原则最后分享一个我反复琢磨的原则移动搜索优化要以用户价值为最终衡量标准。听起来像废话但实际做的时候很容易偏离。比如你可能会为了提升点击率而优化标题党为了提升转化率而过度商业化为了提升指标而牺牲用户体验。这些做法短期可能有效但长期一定会伤害产品。我的做法是定期做用户价值评估找真实用户来做任务测试观察他们使用搜索的体验听取他们的反馈。这些定性反馈往往能发现定量指标发现不了的问题。移动搜索优化做到最后拼的不是技术而是对用户的理解。谁更懂用户在移动场景下的需求谁就能做出更好的搜索体验。这个道理我花了很长时间才真正明白希望对你有所启发。
