电商搜索专业词库建设：同义词、纠错与类目映射全链路

1. 电商搜索里最脏最累的活先把话对上做站内搜索的都清楚一个事实用户和商家从来没说过同一种语言。用户搜防晒衣女夏薄款商家标题写的是冰丝防晒外套 UPF50 户外骑行服用户搜手机壳苹果14商家写适用 iPhone 14 保护套 磨砂防摔用户搜踩屎感拖鞋商家压根不会把这四个字写进标题。这两端之间隔着的不是技术是一整套电商搜索专业词库。它做的事情说起来很朴素——把用户嘴里的词、键盘上打错的词、行业里流传的黑话翻译成商品标题和属性表里真正存在的词让搜索能召回、类目能判对、排序有依据。这个词库解决的是搜索链路最上游的问题。分词切错了、同义词没配、错别字没纠正、口语词没有映射后面排序模型再强也是白搭因为压根没把对的商品捞出来。它适合三类人参考做搜索召回的算法同学、管类目和商品属性的运营同学、负责搜索效果和 badcase 处理的业务同学。哪怕你所在的项目只做站内搜索的一个小模块词库这块的基本功绕不开。我见过不少团队一开始都想跳过这步直接上向量召回、上语义模型结果发现长尾 query 的无结果率还是压不下去。原因很直白向量模型擅长处理意思相近但不擅长处理业务约定。用户搜苹果15到底是水果还是手机向量分不出来类目绑定能分出来用户把荧光棒打成莹光棒字面上风马牛不相及拼音纠错能救回来。所以这篇内容我会从设计思路、字段结构、数据来源、算法实现、链路落地到维护机制把这个词库从零到一的完整过程拆干净。2. 为什么电商搜索必须自建专业词库2.1 通用词库在电商场景失效的三个现场拿任何一个开源中文同义词表直接上线第一周就会收到一堆 badcase。这不是词表质量差是场景不对。通用同义词表认为苹果和梨是并列的水果电商场景里苹果首先是手机品牌其次是水果类目这两个意图要靠类目绑定去切分通用词表认为连衣裙和裙子是上下位关系但召回层直接等价替换会把半身裙全捞进来转化率立刻掉一截。第一个失效现场是一词多义。同一个词在不同类目下指向完全不同的商品小米可以是手机也可以是杂粮樱桃可以是水果也可以是颜色鼠标可以是硬件也可以是垫子。通用词库不解决歧义电商词库必须靠 term 与类目的绑定关系解决。第二个失效现场是口语与黑话。踩屎感老爹鞋奶奶灰奥利奥配色空调房必备这些词在行业里流传极广但任何公开词表都不会收录。用户搜索时偏要用这些词商家标题偏不写这些词中间这道桥只能自己搭。第三个失效现场是型号与规格的写法差异。500ml和0.5L、128G和128GB、均码和F、XL和加大号这些在商品属性表里是标准的在用户输入里是随机的。通用词库不做单位归一搜索就会漏召回。一个判断标准凡是需要业务知识才能判断两个词能不能互相替换的场景通用词库都搞不定必须自建。2.2 词库、分词词典、纠错词典的分工边界很多人把这几样东西混在一起维护最后维护成本爆炸。我建议在项目规划阶段就切清楚各管一段词典类型输入形态作用位置失效后果分词自定义词典单个词 词频切词阶段专有词被切碎后续全错同义词/变体库term 对 关系类型召回改写、类目预测长尾无结果、召回不全纠错词典错词 → 正词 拼音/形近特征query 预处理明显错字搜不到类目映射表term → 类目路径 权重意图识别类目判错排序失真排除词表term × 类目 → 屏蔽召回过滤跨类目串词这里最容易踩的坑是分词词典和同义词库打架。防晒衣如果没进分词词典会被切成防晒衣词库再把防晒衣映射到防晒服改写出来的 query 就变成防晒 服这种四不像。所以正确的上线顺序是先补分词词典把核心品类词切对再上同义词库做改写最后上纠错。顺序反了你会花大量时间去排查其实是切词导致的假 badcase。2.3 选型为什么先做规则词库再谈模型我也试过一上来就用词向量做同义词挖掘用 query 的 embedding 余弦相似度筛出 Top-K 当同义词。结果很典型把连衣裙和半身裙、运动鞋和运动袜、华为和荣耀都挖成了同义词。向量只反映上下文分布相近不反映可替换性。两个词在语料里经常一起出现向量就靠近但它们在交易场景里是完全不同甚至互斥的商品。所以合理的落地路径是规则词库打底模型做辅助挖掘人审做最后一道闸。规则词库覆盖高频、高确定性的词对保证基础体验模型负责从日志里捞出候选交给人工确认确认后的结果回流词库。这条链路跑顺了词库的准确率能稳定在很高水位而不是每次上线都靠运气。还有一个现实考量是可解释性。搜索出问题时运营同学会来问为什么搜 A 出来了 B。如果答案是模型觉得像这个问题没法回答如果答案是词库里 A 映射到了 B权重 0.8绑定类目是 XX问题五分钟能定位。词库是搜索系统里少数几个能被非技术同学理解和干预的模块这个价值不应该被模型能力掩盖。3. 词库的字段设计与分层结构3.1 一条词条应该长什么样字段设计决定了后续所有工作的顺滑程度。我用的结构大致如下字段不多但每个都有明确用途字段类型说明示例term_idstring唯一标识T20240512001variantstring变体词用户可能输入的莹光棒canonicalstring标准词用于改写后检索的荧光棒rel_typeenum关系类型typocat_bindlist绑定类目路径空表示全类目生效玩具/派对用品weightfloat改写权重 0~10.95scopeenum生效环节recall / category / correctconfidencefloat置信度0.92sourceenum来源渠道日志挖掘 / 人工 / 商家属性statusenum状态online / pending / offlinecreate_timedatetime创建时间-ownerstring负责人运营A重点说三个字段。cat_bind是整个词库的灵魂没有它词库就是一堆危险的等价替换scope决定这条词在哪个环节生效纠错词不该进召回改写召回改写词不该进类目预测weight给下游留了调节空间同义词不是二元的是分强弱的。3.2 关系类型同义词不是一个筐把同义当成一种关系是新手最常见的错误。实际业务里至少要区分七种等价同义防晒衣 防晒服可 1:1 替换权重给满。上下位裙子 → 连衣裙只能单向扩展反向会放大范围权重给 0.5 左右。属性约束加厚 加绒加厚属于修饰词补全只在特定类目生效。缩写与别称iPhone 苹果手机双向但要注意品牌歧义。错别字与变体莹光棒 → 荧光棒只做单向纠错不进召回扩展。型号规格128G 128GB单位归一双向。排除关系苹果 × 水果类目这是负面词作用是阻止错误映射。排除关系最容易被忽略但收益极高。用户搜苹果如果词库里有苹果 → 手机的映射水果类目的商品就被压下去了这时候如果还想保留水果意图就必须配一条苹果 × 手机类目的排除规则让两类意图各自成立。没有排除词表的词库越做越容易串类目。3.3 分层结构核心词、品类词、属性词、修饰词词库规模上去之后必须分层管理否则一次全量发布就是灾难。我按影响面分四层第一层是核心同义词数量几千条覆盖头部品类和品牌改动必须走完整评审因为影响面最大。第二层是品类词几万条量级随类目运营一起维护属于周期性更新。第三层是属性词和修饰词数量最多主要靠日志挖掘和模型候选人工抽检。第四层是长尾和错别字走自动化生成加抽样审核允许一定噪声但要有监控。分层的意义在于发布策略可以差异化。第一层走全量灰度加人工复核第二层走小流量验证第三、四层直接上但配上效果监控和快速回滚。如果所有词条一视同仁地走人工审核你的团队会被审核队列拖死。4. 词库从哪里来六条采集通道4.1 搜索日志最高价值也最难处理搜索日志是词库的主矿脉但要挖对地方。我一般看四类信号无结果 query、低点击 query、改写后点击提升的 query、同一 session 内的连续搜索。最后这个最有意思用户搜防晒衣没找到紧接着搜防晒服点进去了这一对就是天然的候选同义词而且是真实用户行为验证过的。日志挖掘的坑在于噪声。大量 query 是偶发的、无意义的、甚至是爬虫产生的。我的做法是先做频次过滤只保留周搜索量超过阈值的 query具体阈值按站点体量定中小站点几十次就够大站要几百次再做 session 内的行为关联最后才做聚类。跳过频次过滤直接聚类你挖出来的同义词会全是拼写错误和乱码。4.2 商家标题与商品属性反向挖词的好地方商家侧的数据被很多人低估了。同一个 SPU不同商家会写出五花八门的标题这些标题之间的差异本身就是变体来源。比如同一款保温杯标题里可能出现保温杯焖烧杯车载水杯办公水杯这些词在用户侧的表达里也会出现形成对应关系。商品属性表更适合挖规格归一。容量500ml和标题里的0.5升适用机型iPhone 14和标题里的苹果14这类映射靠属性表反查非常准几乎不需要人工审核。我一般会写个脚本把属性值和高频标题片段做比对自动生成候选人工只处理有歧义的部分。4.3 客服会话与售后评价口语词的富矿用户跟客服说话的时候用的绝对是最自然的表达。我想要那种软软的踩上去很舒服的拖鞋那个能充电的暖手的东西这些描述里藏着大量从未出现在标题里的口语词。售后评价同理显瘦不掉色不闷脚这些词用户会在评价里高频使用但在搜索词里出现频率被严重低估。这条通道的处理成本高因为是非结构化文本但产出质量很高。我的做法是用评价和会话做词频统计 人工挑词不做全自动挖掘每周固定读几百条把有价值的词手工登记进词库。听起来很土但这是最有效的补充渠道。4.4 外部词表与人工标注打底不能少公开的中文同义词表、行业品类词表、开放的商品类目体系这些可以拿来打底但不能直接用必须过一遍类目适配。我的做法是先用一份通用词表做基线然后跑一轮 badcase 回归看哪些词条在电商场景下会出问题把问题词条标记为待审。这一步能省掉大量从零开始的工作量。人工标注要控制规模。不要指望标注同学从零造词库那是无底洞。正确的姿势是给出候选 给出上下文 只让人判断 yes/no。比如把防晒衣 → 防晒服这条候选连同最近一周的相关 query 一起给出来标注同学只需要判断能替换/不能替换/只在某类目能替换效率会高很多。4.5 错别字生成拼音、形近、输入法三路并进错别字词条没必要全靠日志捞可以主动生成。三条路子拼音路线把标准词转成全拼和首字母找同音词。荧光棒 → yingguangbang → 莹光棒迎光棒命中率很高。形近路线基于字形结构找相似字适合处理己/已戊/戌祼/裸这类视觉混淆。输入法路线统计输入法候选序列里相邻词的替换概率这条路需要外部数据支撑中小团队可以跳过。生成之后一定要过滤只保留在日志里真实出现过的错写形式并且设置频次门槛。否则你会得到几万条永远没人搜的错别字白白撑大词库体积。4.6 冷启动先跑通最小闭环新项目没有历史日志怎么办我的建议是先做三百条。把平台 GMV 占比最高的二十个类目挑出来每个类目人工整理十几条核心同义词和常见错别字配上类目绑定先上线跑一周。一周之后你就有真实日志了能看到哪些 query 还在无结果这些就是下一批词条的目标。这个过程千万别反过来做——先花两个月整理一万条词再上线。没有真实反馈的词库方向大概率是偏的等你上线发现不对前面两个月的功夫全白费。5. 核心算法与实操从日志到词表5.1 query 归一化所有工作的前置步骤在做什么聚类、什么相似度之前先把 query 洗干净。全半角、大小写、繁简、多余空格、标点符号、数字单位这些不统一后面所有计算都是噪声。这是我实际用的一份归一化脚本import re import unicodedata UNIT_MAP { 毫升: ml, ml: ml, ML: ml, 升: l, l: l, L: l, 克: g, g: g, G: g, gb: gb, g: gb, # 需结合上下文这里只做简单示例 } def normalize(q: str) - str: # 全角转半角 q unicodedata.normalize(NFKC, q) # 转小写 q q.lower() # 去标点与特殊符号保留中文数字英文 q re.sub(r[^\u4e00-\u9fa50-9a-z.], , q) # 数字与单位之间插入分隔 q re.sub(r(\d(?:\.\d)?)\s*(ml|l|g|gb|寸|码), r\1\2, q) # 单位统一 for src, dst in UNIT_MAP.items(): q q.replace(src, dst) # 去重复字符如 aa - a但要避开正常双写 q re.sub(r(.)\1{2,}, r\1, q) return q def parse_size(q: str): 把 0.5l 归一成 500ml m re.search(r(\d(?:\.\d)?)(ml|l), q) if not m: return q val, unit float(m.group(1)), m.group(2) if unit l: val, unit val * 1000, ml return q.replace(m.group(0), f{int(val)}{unit})这段代码看起来简单但实测下来能消掉三成以上的看起来搜不到其实是写法不同的假 badcase。特别提醒一句re.sub(r(.)\1{2,}, ...)这条去重复字符的规则要谨慎用有些词本身带叠字娃娃包包仔仔压错了反而制造新问题。我一般是先只处理三连以上的重复双写保留。5.2 用点击共现判定同义指标与阈值怎么定判断两个 query 是不是同义最靠谱的信号不是文本相似是点击行为的重合度。逻辑很直白如果搜 A 的人和搜 B 的人点的是同一批商品那 A 和 B 大概率是同一个意思。具体做法是构造 query 到商品集合的映射用 Jaccard 相似度衡量重合度def jaccard(set_a, set_b): if not set_a or not set_b: return 0.0 inter len(set_a set_b) union len(set_a | set_b) return inter / union def candidate_pairs(query2items, min_click5, min_jac0.35): query2items: {query: set(item_id)} queries [q for q, s in query2items.items() if len(s) min_click] pairs [] for i in range(len(queries)): for j in range(i 1, len(queries)): a, b queries[i], queries[j] jac jaccard(query2items[a], query2items[b]) if jac min_jac: pairs.append((a, b, round(jac, 3))) pairs.sort(keylambda x: -x[2]) return pairs阈值怎么定这个不能拍脑袋。我的经验值是Jaccard 到 0.35 以上基本是强相关0.2 到 0.35 之间需要结合类目一致性再判断低于 0.2 的不建议采纳。但这只是起点真正上线前要做的是抽样验证——从候选里随机抽 200 对人工看统计准确率如果低于 80% 就往上抬阈值。还有一个补充指标是类目一致率。两个 query 点击的商品如果有 80% 以上落在同一个二级类目可信度会显著提升如果一半点手机一半点水果那基本可以判定是歧义词需要配排除规则而不是同义词映射。5.3 拼音相似度与编辑距离专治错别字错别字匹配的经典做法是拼音加编辑距离。核心思路是把中文转成拼音序列用编辑距离衡量差异同时限制声母韵母的差异幅度from pypinyin import lazy_pinyin def pinyin_seq(word: str) - str: return .join(lazy_pinyin(word)) def edit_distance(s1: str, s2: str) - int: m, n len(s1), len(s2) dp list(range(n 1)) for i in range(1, m 1): prev dp[0] dp[0] i for j in range(1, n 1): tmp dp[j] cost 0 if s1[i - 1] s2[j - 1] else 1 dp[j] min(dp[j] 1, dp[j - 1] 1, prev cost) prev tmp return dp[n] def typo_score(a: str, b: str) - float: pa, pb pinyin_seq(a), pinyin_seq(b) dist edit_distance(pa, pb) max_len max(len(pa), len(pb)) return 1 - dist / max_len if max_len else 0.0实践里的关键点是加约束。纯拼音编辑距离会把苹果和平锅判成高度相似所以必须加两道闸一是拼音相同但汉字不同的要求至少有一个字相同或者出现在同一类目下二是长度差异超过 2 个拼音音节的直接淘汰。这两条约束能把误召率压下来一大截。另外要注意多音字。lazy_pinyin默认取常用读音遇到重庆朝阳银行这类词会出错最好是维护一张多音字表对这些词做特殊标注。5.4 词条质量打分与置信度分级候选挖出来一大堆不可能全部上线。我给每条候选算一个综合分公式大致是score 0.45 * 行为相似度 0.25 * 类目一致率 0.20 * 文本相似度 0.10 * 来源可信度行为相似度用 Jaccard 或点击数余弦类目一致率按点击商品类目分布算文本相似度用拼音和编辑距离来源可信度是人工给各通道的先验人工标注 1.0属性反挖 0.9日志挖掘 0.7模型召回 0.5。算完之后score ≥ 0.8直接进 pending 队列抽检 10% 后上线0.6 ≤ score 0.8全量人工审score 0.6只保留在候选池不进入审核队列这套分级让我把人工审核量压到了候选量的两成左右同时上线词条的准确率能维持在可接受水平。不要追求 100% 准确搜索是个概率系统只要准确率稳定、有监控、能回滚就够了。6. 词库落地到搜索链路改哪些地方6.1 召回层改写策略的三种模式词库在召回层的用法不是简单的看到变体就换成标准词而是分三种模式强等价改写是直接把 query 里的变体替换成标准词适用于错别字和高置信同义词。用户搜莹光棒改写为荧光棒再检索用户无感知。扩展召回是同时用原词和标准词检索结果合并。适用于上下位关系和不确定的同义词。用户搜裙子除了裙子本身还扩出连衣裙、半身裙但排序时原词匹配的加权更高。这条路要控制扩展数量一般不超过 3 个扩展词否则召回集合会爆炸。类目约束改写是指只有在特定类目下才做替换。用户搜小米在手机类目下映射到品牌在食品类目下映射到杂粮词条通过 cat_bind 字段实现分流。三种模式要分开配置用一个开关全量打开出问题的时候你根本不知道是哪条规则导致的。6.2 类目预测与意图识别词库在类目预测环节的价值被严重低估。query 到类目的映射本质上就是一份词库。用户搜口红类目直接给美妆搜口红支架类目给家居。这里面支架这个后缀就是拦关键词能有效纠正纯词义带来的类目误判。我在做类目预测时用的是三层结构词条精确匹配 → 后缀/前缀规则 → 模型兜底。前两层都依赖词库覆盖了大部分高频 query第三层处理长尾。这种结构的好处是高频 query 的类目准确率可以做到很高而且出错时能快速定位是哪条词或哪条规则的问题。类目映射表要支持一对多也就是一个词可以绑定多个类目带权重。用户搜苹果手机类目权重 0.7水果类目权重 0.3排序时按权重分配流量而不是二选一。这个设计对歧义词特别友好。6.3 排序层的加权与词条权重词条权重不该是摆设。同一个标准词来自不同变体的映射权重应该有差异。错别字映射权重给 0.95因为用户意图非常明确就是那个标准词上下位扩展权重给 0.5因为扩展出来的东西只是可能相关。在排序阶段我会把query 与商品的词条匹配强度作为一个特征喂给排序模型命中标准词的记 1.0命中同义词的记 0.8命中上下位扩展词的记 0.5。这个特征单独看贡献有限但和文本相关性特征叠加之后对头部结果的改善很明显。提醒一句词条权重不要写死在代码里一定要配置化。搜索的效果调优是长期活每次改权重都发一次版节奏根本跟不上。6.4 无结果与少结果的兜底词库再全也有覆盖不到的时候。兜底策略我一般配三层第一层是放宽约束。query 加了太多修饰词导致无结果就逐级剥离修饰词重试。用户搜加厚防滑耐磨厨房地垫 60x90 灰色没结果就去掉颜色、去掉尺寸、再去掉材质直到有结果为止。第二层是类目兜底。query 完全没结果但类目预测是明确的就推该类目的热销商品。用户虽然搜的不是他想要的但至少有东西可看比空白页强。第三层是纠错兜底。无结果时触发一次纠错重新检索把纠错结果展示给用户并提示已为您显示 XX 的结果。这一层要谨慎纠错错了会让用户觉得搜索很蠢所以只在无结果时触发有结果时不要轻易改用户的 query。7. 维护机制与效果评估7.1 版本管理、灰度与回滚词库必须当成代码来管。每次发布打一个版本号记录变更清单支持一键回滚。我见过太多团队把词库放在一张数据库表里运营直接改改完没有记录出问题只能靠猜。发布流程我是这么走的先在内部环境跑一遍回归集一批标注好的 query 和期望结果通过率不低于基线才允许进灰度灰度先放 5% 流量观察 24 小时的核心指标没异常再放到 30%最后全量。每次只放一个变更包不要多个变更混在一起发否则出问题无法归因。7.2 核心指标看哪几个数词库的效果评估不能只看大盘 CTR那个噪声太大。我盯的是这几个指标定义观察方向无结果率无结果 query 数 / 总 query 数越低越好重点看长尾改写率触发词库改写的 query 占比稳定在合理区间暴涨说明有异常改写后点击率改写 query 的点击率 vs 未改写改写后应高于未改写类目准确率抽样人工评估高频 query 应保持高位首屏点击率首屏结果的点击占比综合指标受多因素影响badcase 数用户反馈与内部发现的错误按周统计趋势其中改写后点击率是最能直接反映词库质量的指标。如果改写后的点击率低于未改写说明你的词条在制造噪声要立刻排查。我遇到过一次某批上下位词条配得太宽改写后点击率掉了十几个百分点回滚之后立刻恢复。7.3 一个容易被忽略的机制badcase 回流搜索团队一定要有一个 badcase 收集入口而且要有专人跟。用户反馈搜不到搜出来的不对这些是最真实的问题来源。我的做法是把 badcase 按类型打标签无结果、类目错、串类目、排序差每周做一次归因属于词库问题的进词库待办属于其他环节的转给对应同学。这个机制跑起来之后词库就从一个静态的资源变成了一个持续进化的系统。有很多词条我根本想不到但用户反馈会告诉我。这比任何挖掘算法都直接。8. 踩过的坑与常见问题速查8.1 那些让我加班到深夜的典型问题同义词过度扩展导致类目漂移。这是最常见也最伤的。把连衣裙扩到裙子之后半身裙、短裙全被捞出来转化率直接掉。解决办法是上下位关系必须配类目约束不能全类目生效。排除词漏配导致跨类目串词。搜苹果出来水果搜小米出来杂粮这类问题靠增加绑定类目解决不要试图用文本规则硬判。纠错词条把正确输入改错了。有些品牌的官方写法看起来像错别字比如某些自造词。这类词必须进白名单纠错时跳过。我的做法是维护一份禁改词表优先级高于所有纠错规则。词库膨胀导致召回噪声。词条从一万涨到十万召回集合跟着膨胀排序压力上来了效果反而变差。控制方法是给扩展召回设上限并且定期清理长期无命中的词条。分词词典和同义词库版本不同步。新加的同义词依赖的切词结果在老版本分词器上根本切不出来导致词条不生效。这两个词典必须同批次发布。权重写死导致调优困难。前面提过再强调一次所有阈值、权重、开关全部配置化。8.2 常见问题速查表现象可能原因排查方法处理方式某 query 无结果分词错误 / 缺同义词 / 错别字打印分词结果和改写日志补词典或补词条结果跨类目混乱排除词缺失 / 类目绑定错误查词条的 cat_bind 配置补排除规则改写后效果变差扩展过宽 / 权重设置不当对比改写前后点击率收窄范围或降权词条上线不生效版本未同步 / scope 配错查词条状态和生效环节修正配置并重新发布错别字纠错误伤品牌词被当错字查禁改词表加入白名单长尾 query 覆盖低词库规模不足看无结果 query 分布定向补充同一词不同类目结果冲突一对多权重未配置查类目权重分配调整权重比例8.3 几条实际干出来的经验第一别追求词库大追求词库准。一万条高准确率的词条效果远好于十万条掺水的。词库大了之后维护成本是线性上升的准确率却是下降的。第二人工审核不能省但要想办法省在刀刃外。高频词条必须人审长尾词条可以靠置信度和抽检。把审核资源花在影响面大的词上。第三每个季度做一次词库体检。把长期零命中的词条下线把冲突的词条清理把失效的类目绑定更新。词库和代码一样会腐烂不定期清理会越来越难维护。第四把词库的变更和业务节奏对齐。大促前不要大规模改词库宁可提前两周稳定下来。大促期间出现搜索问题排查成本是平时的好几倍。第五留一条人工干预的快速通道。业务方发现某个词搜不出来要能在几小时内加上而不是等下一个迭代周期。这条通道的权限要收好但一定要有。我个人在实际操作中的体会是词库这件事没有做完的一天。用户的语言在变商品在变行业黑话在变词库就得跟着变。真正决定成败的不是你第一版做得多全而是你有没有建立起一套能持续吸收反馈、快速验证、安全回滚的机制。机制在词库自己会长机制不在再全的词表也会在半年内变成一堆没人敢动的历史包袱。