小程序搜索排名低迷？外链权重隐形逻辑揭秘

文章配图，仅供参考

　　小程序搜索排名低迷？去年五月份，我们那批改字段的兄弟刚上线就踩进坑里。我原以为是关键词埋点漏了，结果一查日志刷得太快看不清，滚屏像瀑布，全是“MISS_CACHE”打头的行。再切缓存链路，发现搜“奶茶”和搜“喜茶”走的压根不是同一套路由——前者查ES，后者直连MySQL主库。不是策略配错，是去年五一前那个紧急灰度，前端顺手把path里带“/brand/”的请求全标成“高意图”，后端缓存中间件自动降级了。没人改配置，它自己就裂开了。

　　优胜劣汰。这词不是虚的。上周复盘会，小王举着堆栈截图说“是不是得加个限流兜底？”我盯着他屏幕右下角时间戳——5月17号14:28，正是那次雪崩开始的时间。可我说不出口，那天我还在帮产品对齐“附近门店”的经纬度精度，没盯住搜索服务里那个被注释掉的幂等校验开关。现在想，它不是没用，是早被当成脏数据过滤掉了：用户搜“美甲”，返回“美甲店”没问题；但搜“美甲店”却返回“美容院”，因为上游同步时字段映射表里，“category_name”字段被强制截断了12字符，后面全填“…”。没人敢动这张表，字段类型还是TEXT，索引建在子串上。你问我为什么？——去年五月份，DBA老李离职交接单上就一句：“别碰t_category_map，祖传的。”

　　咖啡机坏了三天，行政一直没换新滤网，煮出来像中药渣。我每次接水都绕开那台机器，结果昨天看见阿哲踮脚往里面塞纸巾，说是“防漏水”，塞完转身就去调定时任务——他负责的“搜索热榜刷新”每晚十点跑一次，但上周连续四天凌晨三点又触发了一次，日志里只写“trigger: manual override by system”，根本没留人名。我们查了半天，发现是运维侧灰度发布时顺手启了个临时job，名字叫“hot_rank_fallback_v2_2023”，但没关。它和线上job共用同一张锁表，抢不到锁就退避重试，重试间隔设的是指数退避，最大值填成了“2147483647”，单位是秒。懂吧？就是等它自己死，大概六十八年。

　　监控大盘上那条绿色的线一直在抖，不是波动，是高频颤动，像心电图进了ICU。运维说这是“探针抖动”，建议忽略。我信了。直到有天发现抖动频率和Nginx access log里“499”错误码出现节奏完全一致——用户等不及关页了。499？那是客户端主动断连，不是后端扛不住。可我们的搜索排名算法还傻乎乎地把这种请求当真实曝光计数，越抖，越把它当热门信号喂给排序模型。结果呢？真正搜三次才点进去的用户，排得比搜一次立刻关掉的还靠前。算法在学垃圾，人还在调learning rate。

　　所以外链权重那套“隐形逻辑”，真不是藏得多深。去年五月份，市场部推了一个联合活动，要求所有合作方在H5页里加跳转小程序的button，带参数utm_source=xxx&pid=yyy。我们后端认这个pid，存进搜索行为日志的extra字段，但前端没统一encode，某家合作方传了中文“品牌联名款”四个字，base64一解就乱码，最后落库变成一堆问号。而搜索权重模型恰好拿这个字段做外链信任度加权——乱码越多，权重越高，因为它误判成“高价值长尾特征”。这事儿谁发现的？保洁阿姨。她扫工位时看见阿哲电脑屏上飘着一长串%EF%BF%BD，顺口问“这啥编码？看着像烫坏的字”。我原以为是日志系统bug，结果grep整个repo，发现只有两个地方用了raw_url_decode，其中一处在支付回调里，另一处在…一个被注释掉的AB测试开关下面。

　　工位隔断上贴的便签卷了边，上面是我写的“查pid乱码是否影响召回”，墨迹有点晕，可能哪天手抖蘸了咖啡渍。我没撕。小王上个月说要重构搜索日志schema，新加个normalized_pid字段，用jsonb存。我点头了。但今天早上看到他PR里写了句注释：“暂不迁移旧数据，等Q3统一归档。”我没回。反正也没人真去看那条绿线怎么抖的。

　　下一步？先让阿哲把那个抖线告警从P0降成P2，再让他把“hot_rank_fallback_v2_2023” job名改成“hot_rank_fallback_v2_deprecated_do_not_use”，然后……算了，你记得周四下午三点前，把t_category_map里“category_name”字段的索引删了再重建，用FULLTEXT。别告诉老李，他早就不管这事了。要是报错，就回滚到上个周五的备份，那个备份我知道在哪，物理机柜第三层，贴着“2022年灾备”标签的蓝盒子底下，压着半包没拆封的挂耳咖啡。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!