1. 移动搜索优化的底层逻辑与核心挑战1.1 移动搜索到底难在哪里做搜索的人都有一个共识移动端搜索和PC端搜索表面上看只是屏幕大小不一样实际上背后的技术栈和优化思路完全是两码事。我从2018年开始接触移动搜索优化踩过的坑比写过的代码还多今天就把查询处理这一块的实战经验系统性地梳理一遍。先说移动搜索的核心挑战。第一是输入成本高。手机屏幕就那么大用户打字慢、容易打错所以移动端的查询词普遍比PC端短。PC端用户可能搜“北京朝阳区性价比高的日料自助餐厅”移动端用户大概率只打“朝阳日料”。这就意味着查询处理模块必须在极短的文本里精准捕捉用户意图容错空间非常小。第二是场景碎片化。用户可能在走路、坐地铁、排队的时候搜索注意力极度分散。搜索请求的响应时间如果超过1.5秒跳出率会急剧上升。我们实测过移动端首屏结果加载时间每增加500毫秒用户二次搜索率下降约12%。这不是理论值是真实AB实验跑出来的数据。第三是多模态输入。现在的移动搜索早就不只是文字了语音搜索、拍照搜索、扫码搜索都在分流传统文本查询。查询处理模块需要兼容这些异构输入把它们统一转化成可检索的查询表示。1.2 查询处理在移动搜索中的定位查询处理是搜索链路里承上启下的关键环节。上游对接用户输入下游对接召回和排序。它的核心任务可以拆成四步查询理解、查询改写、查询扩展、查询路由。查询理解是搞清楚用户到底想要什么。比如用户搜“苹果”是要买水果还是找iPhone在移动端这个判断需要结合地理位置、时间、用户历史行为等上下文信号。查询改写是纠正错误、补全省略。用户打“星巴克 望京”改写模块要能补全成“星巴克 望京门店”。查询扩展是增加召回率比如“感冒药”可以扩展出“感冒灵”“布洛芬”等。查询路由是决定这个查询走通用搜索、垂直搜索还是本地搜索。这四个环节在移动端的侧重点和PC端完全不同。移动端更依赖上下文信号更强调低延迟更注重个性化。下面我会逐一拆解每个环节的实操要点。1.3 移动端适配对查询处理的新要求移动端适配不只是前端响应式布局的事查询处理层面也要做针对性调整。最典型的是查询长度归一化。移动端查询平均长度只有2.3个词PC端是4.1个词。如果沿用PC端的查询处理策略很多短查询会因为信息量不足而无法精准召回。我们的做法是建立移动端专属的查询意图分类模型把短查询按照意图强度分成强意图、弱意图和模糊意图三档。强意图直接走精准匹配弱意图走语义扩展模糊意图走推荐引导。这套分类模型上线后移动端搜索的点击率提升了18.7%。另一个关键适配点是输入法联想与搜索建议的联动。移动端用户输入时输入法会给出候选词搜索框也会给出搜索建议。这两个模块如果各自为政用户体验会很割裂。我们通过共享用户输入前缀和上下文特征让输入法候选词和搜索建议保持语义一致用户选词后直接触发搜索减少了二次编辑的成本。2. 查询理解与用户意图识别的实战拆解2.1 移动端用户意图识别的信号体系意图识别是查询处理的第一步也是最容易出错的一步。移动端的意图识别不能只看查询词本身必须构建多维信号体系。我把我们线上用的信号分成四类查询文本信号分词结果、词性标注、命名实体、查询长度、是否包含疑问词上下文信号时间、地理位置、网络类型、设备型号、操作系统用户画像信号历史搜索记录、点击行为、停留时长、常用搜索类别实时行为信号输入速度、修改次数、是否使用语音输入这四类信号的权重不是固定的。比如用户搜“附近的加油站”地理位置信号的权重会压倒性高于其他信号。用户搜“Python教程”历史行为信号的权重会更高。我们用一个轻量级的GBDT模型做信号融合线上推理延迟控制在8毫秒以内。注意移动端意图识别模型不能太重。我们试过用BERT做意图分类准确率确实高但推理延迟到了45毫秒在低端安卓机上直接卡顿。后来换成了蒸馏后的小模型准确率只掉了1.2个百分点延迟降到了6毫秒。2.2 短查询的意图补全策略移动端短查询是意图识别的重灾区。用户搜“苹果”可能是水果、手机、电影、公司。怎么判断我们的策略是上下文优先、行为兜底、推荐引导。上下文优先是指先看地理位置和时间。如果用户在水果店附近搜“苹果”大概率是水果。如果用户在写字楼里搜“苹果”大概率是手机或电脑。行为兜底是指看用户历史行为。如果用户之前搜过“iPhone 15”那这次“苹果”大概率还是手机。推荐引导是指当意图实在无法判断时在搜索结果页顶部展示多个意图入口让用户自己选。这套策略的关键在于意图置信度阈值的设定。我们把置信度分成三档高于0.85直接走精准结果0.6到0.85走混合结果低于0.6走推荐引导。这个阈值是通过大量AB实验调出来的不同品类的最佳阈值还不一样。电商类可以放宽到0.55本地生活类要收紧到0.7。2.3 语音搜索查询的特殊处理语音搜索在移动端的占比越来越高我们平台的数据是已经超过35%。语音查询和文本查询有本质区别语音查询更长、更口语化、包含更多冗余信息。比如用户会说“帮我找一下附近营业到晚上十点的火锅店”文本查询可能只是“附近火锅店 营业到十点”。语音查询处理的第一步是口语化归一化。把“帮我找一下”这类指令性前缀去掉把“晚上十点”转成“22:00”把“附近”转成地理位置范围。第二步是意图结构化。把归一化后的查询拆成品类、属性、位置、时间四个槽位。第三步是槽位补全。如果某个槽位缺失根据上下文自动补全。我们实测下来语音查询经过这套处理后召回准确率从62%提升到了89%。但要注意语音识别的错误率本身就有5%到8%所以查询处理模块还要有一定的容错能力。我们的做法是在归一化阶段加入同音词纠错比如“火锅”和“活锅”都能正确识别。2.4 意图识别的评估与迭代意图识别做得好不好不能只看准确率。移动端更关注首屏点击率和搜索满意度。我们建立了一套三层评估体系评估层级核心指标目标值监测频率模型层意图分类准确率≥92%每日业务层首屏点击率≥65%实时用户层搜索满意度≥4.2/5每周模型层指标达标不代表业务层达标。我们遇到过模型准确率93%但首屏点击率只有58%的情况原因是意图分类太细把用户导向了错误的垂直结果页。后来把意图类别从47个合并到23个点击率立刻回升到67%。迭代节奏上我们保持每周一次小迭代、每月一次大迭代。小迭代主要调阈值和特征权重大迭代才会动模型结构。每次迭代必须跑够7天的AB实验样本量不少于50万次搜索请求。3. 查询改写与扩展的落地方法3.1 移动端查询改写的触发条件查询改写不是越多越好。移动端资源紧张每次改写都会增加延迟。我们设定了一套触发条件只有满足以下任一条件才触发改写查询词包含明显错别字或拼音混输查询词长度小于3个词且意图置信度低于0.7查询词包含省略号、破折号等不完整标记查询词命中同音词歧义库查询词在历史日志中低频出现且无点击这套触发条件把改写率控制在12%左右既保证了效果又控制了延迟。改写模块的平均耗时是4毫秒对整体搜索延迟的影响可以忽略不计。3.2 基于编辑距离与语义相似度的改写算法改写算法我们用了两套并行编辑距离改写和语义相似度改写。编辑距离改写主要处理错别字和拼音混输。比如“星巴克”打成“新巴克”“望京”打成“望金”。我们维护了一个高频错词库用BK树做快速检索编辑距离阈值设为2。超过2的编辑距离基本不是错别字而是另一个词了。语义相似度改写主要处理省略和口语化表达。比如“朝阳大悦城 火锅”改写成“朝阳大悦城附近火锅店”。我们用Sentence-BERT做语义编码在向量库里找最相似的完整查询。这里的关键是向量库的构建我们把历史搜索日志里点击率高的查询作为候选集每周更新一次。两套算法的结果会做融合编辑距离改写的优先级更高因为错别字纠正的确定性更强。语义改写的结果会带上置信度分数低于0.75的不采纳。3.3 查询扩展的召回与排序策略查询扩展的目的是增加召回率但很容易引入噪声。我们的策略是保守扩展、严格排序。保守扩展是指只扩展同义词、上下位词和相关词不做跨品类扩展。比如“感冒药”可以扩展“感冒灵”“布洛芬”“999”但不能扩展“体温计”。我们维护了一个品类知识图谱扩展词必须和原词在同一个二级品类下。严格排序是指扩展词召回的结果要单独排序不能和原词结果混在一起。我们给扩展词结果一个降权系数通常是0.7到0.85。如果原词结果足够多扩展词结果只放在第二页。如果原词结果少于10条扩展词结果才会提到首屏。这套策略上线后长尾查询的召回率提升了23%但首屏点击率没有下降说明扩展词的质量控制住了。3.4 改写与扩展的效果监控改写和扩展的效果监控不能只看召回率。我们重点关注三个指标改写采纳率、扩展点击率、负反馈率。改写采纳率是指改写后的查询被用户点击的比例。如果改写采纳率低于40%说明改写方向有问题。扩展点击率是指扩展词结果被点击的比例。如果扩展点击率低于原词点击率的60%说明扩展词质量不行。负反馈率是指用户点击后快速返回并修改查询的比例。如果负反馈率高于8%说明改写或扩展引入了错误。我们每天会跑一次监控报表对异常指标做归因分析。常见的异常原因包括错词库过期、知识图谱品类漂移、向量库更新不及时。这些问题都有对应的自动化修复流程。4. 移动端搜索排序算法的适配与调优4.1 移动端排序与PC端排序的差异移动端排序和PC端排序的目标函数就不一样。PC端更看重相关性和多样性因为屏幕大用户可以慢慢挑。移动端更看重首屏命中率和点击效率因为屏幕小用户没耐心翻页。我们的移动端排序模型在特征工程上做了针对性调整。PC端排序模型里文本相关性特征的权重占比约35%移动端降到了22%。取而代之的是位置特征和时效性特征权重分别提升到了18%和15%。位置特征包括用户与商户的距离、商户所在商圈的活跃度。时效性特征包括商户的营业状态、最近更新时间。另一个差异是多样性控制。PC端首屏可以展示10条结果多样性很重要。移动端首屏只能展示3到4条多样性反而会降低点击率。我们的做法是移动端首屏只展示最相关的品类多样性控制放在第二屏。4.2 轻量级排序模型的选型与部署移动端排序模型必须轻量。我们试过用DeepFM效果不错但推理延迟到了80毫秒不可接受。后来换成了双塔模型GBDT融合的方案。双塔模型负责用户侧和物品侧的向量化离线训练好之后用户塔和物品塔可以分开部署。用户塔在客户端做粗排物品塔在服务端做精排。GBDT负责融合双塔的向量分数和其他特征做最终排序。这套方案的推理延迟控制在15毫秒以内准确率比纯GBDT提升了6.3个百分点。部署上我们把用户塔模型量化到INT8体积从45MB压缩到12MB可以直接嵌入App。物品塔模型放在服务端用TensorFlow Serving做推理。GBDT模型用XGBoost的C接口嵌入到搜索服务里。4.3 实时特征与离线特征的融合移动端排序非常依赖实时特征。用户当前的地理位置、网络状态、设备电量都会影响排序结果。我们把特征分成三类离线特征用户长期兴趣、物品静态属性每天更新一次近线特征用户最近1小时的点击行为每5分钟更新一次实时特征用户当前会话的搜索词、点击序列每次请求实时计算三类特征的融合策略是分层加权。离线特征权重0.3近线特征权重0.4实时特征权重0.3。这个权重是通过在线学习动态调整的不同用户群体的最优权重不一样。新用户的实时特征权重会更高老用户的离线特征权重会更高。实操心得实时特征的计算不能放在搜索主链路里否则延迟不可控。我们的做法是异步预计算把实时特征写入Redis搜索请求直接读Redis。Redis的读延迟稳定在1毫秒以内。4.4 排序效果的AB实验设计排序调优离不开AB实验。移动端的AB实验有几个坑要注意第一实验单元要选对。用用户ID做实验单元比用设备ID好因为用户可能换设备。但用户ID的实验单元会导致实验组和对照组的用户画像有差异需要做分层抽样。第二实验周期要够长。移动端用户行为波动大周末和工作日的搜索模式完全不同。实验至少跑7天覆盖一个完整周期。第三核心指标要选准。首屏点击率是核心指标但也要看人均搜索次数和次日留存。我们遇到过首屏点击率提升但次日留存下降的情况原因是排序太激进把用户不感兴趣的结果推到了首屏。第四实验流量要够大。移动端搜索的点击率本身就不高实验组和对照组的差异可能很小。我们要求每组每天至少10万次搜索请求才能检测到5%以上的相对提升。5. 移动端适配的工程实践与性能优化5.1 网络环境自适应策略移动端网络环境复杂4G、5G、WiFi切换频繁。查询处理模块必须做网络自适应。我们的策略是分级降级5G/WiFi环境走完整查询处理链路包括语义改写和向量扩展4G环境跳过语义改写只做编辑距离改写和基础扩展弱网环境只做查询理解不做改写和扩展直接走缓存结果分级降级的触发条件是实时网速检测。我们每5秒测一次网速低于500Kbps就降级。降级后的搜索延迟从平均320毫秒降到了180毫秒用户感知明显改善。5.2 客户端与服务端的查询处理分工查询处理不能全放在服务端客户端也要承担一部分。我们的分工原则是能本地做的本地做本地做不了的传服务端。客户端负责输入法联想、搜索建议、查询词归一化、简单错别字纠正。这些操作在本地完成延迟几乎为零。服务端负责意图识别、语义改写、查询扩展、排序。这些操作需要大量计算资源必须放在服务端。客户端和服务端的通信协议用了Protobuf比JSON省了40%的流量。查询请求的平均大小从2.3KB降到了1.4KB弱网环境下的成功率提升了15%。5.3 缓存策略与冷启动优化移动端搜索的缓存策略很关键。我们用了三级缓存客户端缓存缓存最近20条搜索结果的摘要命中率约18%CDN缓存缓存热门查询的完整结果命中率约35%服务端缓存缓存查询处理中间结果命中率约52%三级缓存叠加后整体缓存命中率约72%。缓存未命中的查询才走完整处理链路。冷启动优化主要针对新用户和新设备。新用户没有历史行为意图识别只能靠上下文信号。我们的做法是给新用户一个默认的意图分布偏向通用搜索和本地搜索。新设备第一次搜索时客户端会预加载一个轻量级的意图分类模型减少服务端依赖。5.4 性能监控与告警体系移动端搜索的性能监控要覆盖全链路。我们监控的指标包括监控环节核心指标告警阈值处理时效客户端输入响应时间100ms立即网络请求成功率98%5分钟服务端查询处理延迟50ms立即服务端排序延迟30ms立即业务首屏点击率60%30分钟告警触发后值班同学要在5分钟内响应。我们有一套自动化预案常见的延迟飙升和成功率下降都有对应的降级开关。比如查询处理延迟超过50毫秒自动关闭语义改写模块只保留基础改写。6. 常见问题排查与避坑指南6.1 意图识别错误的典型场景与修复意图识别错误是移动端搜索最常见的bad case。我整理了四类典型场景场景一同词不同意图。用户搜“小米”可能是手机、粮食、电影。修复方法是加强上下文信号权重特别是地理位置和历史行为。如果用户在手机卖场附近优先手机意图。场景二短查询意图模糊。用户搜“苹果”意图置信度只有0.4。修复方法是走推荐引导在首屏展示多个意图入口让用户选择。场景三语音识别错误导致意图偏移。用户说“找附近的咖啡馆”识别成“找附近的咖啡管”。修复方法是在查询理解前加一层语音纠错用同音词库做映射。场景四多意图混合。用户搜“朝阳大悦城 火锅 营业时间”包含位置、品类、属性三个意图。修复方法是做槽位拆分分别召回后再融合排序。6.2 查询改写引入的噪声与过滤查询改写最大的风险是引入噪声。我们遇到过改写后的查询和原查询意图完全相反的情况。比如用户搜“不辣的火锅”改写成了“辣的火锅”原因是改写模型把“不”字当成了停用词。修复方法是建立否定词保护机制。改写前先检测查询中是否包含否定词如果包含改写时保留否定词并调整改写方向。我们还建立了一个改写黑名单把容易出错的查询模式加入黑名单禁止改写。另一个噪声来源是过度扩展。用户搜“iPhone”扩展出了“iPhone 15”“iPhone 14”“iPhone 13”结果首屏全是不同型号的iPhone用户反而找不到想要的那一款。修复方法是限制扩展词数量每个查询最多扩展3个词且扩展词必须和原词有明确的上下位关系。6.3 排序偏差的检测与纠正排序偏差是指排序模型对某些品类或某些用户群体有系统性偏好。我们每个月会做一次偏差检测用公平性指标衡量不同品类的曝光分布。检测方法是把搜索查询按品类分组计算每个品类的曝光占比和点击占比。如果某个品类的曝光占比远高于点击占比说明排序模型对这个品类有过度偏好。比如我们检测到“奶茶”品类的曝光占比是12%但点击占比只有6%说明排序模型把太多奶茶店推到了首屏。纠正方法是品类配额。在排序阶段给每个品类设定曝光上限超过上限的结果降权。奶茶品类的曝光上限设为8%上线后点击率回升了3.2个百分点。6.4 移动端特有的兼容性问题移动端兼容性问题比PC端复杂得多。我们踩过的坑包括低端安卓机内存不足查询处理模型加载失败。修复方法是模型分级加载低端机只加载轻量模型。iOS和安卓的输入法差异iOS输入法的候选词顺序和安卓不同导致搜索建议的点击率有差异。修复方法是针对不同操作系统训练不同的建议排序模型。折叠屏手机的屏幕适配折叠屏展开后屏幕变大首屏结果数量需要动态调整。修复方法是根据屏幕宽度动态计算首屏结果数。暗黑模式下的结果展示暗黑模式下图片对比度不足影响点击率。修复方法是针对暗黑模式单独调整图片亮度。6.5 常见问题速查表问题现象可能原因排查方法解决方案首屏点击率下降排序模型偏差检查品类曝光分布调整品类配额查询处理延迟飙升语义改写模块耗时查看模块耗时监控降级或关闭改写语音搜索准确率低语音识别错误对比识别文本和实际查询加语音纠错层新用户搜索满意度低冷启动意图识别不准检查新用户意图分布调整默认意图权重弱网环境搜索失败请求体过大检查请求大小启用Protobuf压缩改写后意图偏移否定词被忽略检查改写前后意图加否定词保护7. 个人实操体会与后续优化方向移动搜索优化这件事说到底是在效果、延迟、成本三者之间找平衡。我做了这么多年最大的体会是不要追求单点极致要追求系统最优。意图识别准确率从92%提升到95%可能要多花3倍的计算资源但首屏点击率可能只提升1个百分点。这1个百分点值不值得要看业务阶段。拉新阶段值得留存阶段可能就不值得。另一个体会是数据比算法重要。我们花在特征工程和数据清洗上的时间远多于调模型的时间。移动端搜索的bad case很多是数据问题不是算法问题。比如地理位置数据不准导致“附近”搜索的结果偏差很大。修复数据源比换模型有效得多。后续优化方向我重点关注两个一是多模态查询处理把图片、语音、文本的查询表示统一到一个向量空间实现跨模态检索。二是端侧智能把更多的查询处理逻辑放到手机本地减少服务端依赖进一步降低延迟。这两个方向都还在早期探索阶段有进展再和大家分享。最后分享一个小技巧移动端搜索的AB实验一定要看分设备型号的数据。高端机和低端机的用户行为差异很大整体指标提升可能掩盖了低端机的指标下降。我们有一次实验整体点击率提升了2%但拆开看发现低端机下降了5%原因是模型太重导致低端机卡顿。后来针对低端机做了模型裁剪才把指标拉回来。