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_id | string | 唯一标识 | T20240512001 |
| variant | string | 变体词（用户可能输入的） | 莹光棒 |
| canonical | string | 标准词（用于改写后检索的） | 荧光棒 |
| rel_type | enum | 关系类型 | typo |
| cat_bind | list | 绑定类目路径，空表示全类目生效 | 玩具/派对用品 |
| weight | float | 改写权重 0~1 | 0.95 |
| scope | enum | 生效环节 | recall / category / correct |
| confidence | float | 置信度 | 0.92 |
| source | enum | 来源渠道 | 日志挖掘 / 人工 / 商家属性 |
| status | enum | 状态 | online / pending / offline |
| create_time | datetime | 创建时间 | - |
| owner | string | 负责人 | 运营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_click=5, min_jac=0.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(key=lambda 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 几条实际干出来的经验
第一，别追求词库大，追求词库准。一万条高准确率的词条，效果远好于十万条掺水的。词库大了之后维护成本是线性上升的，准确率却是下降的。
第二，人工审核不能省，但要想办法省在刀刃外。高频词条必须人审，长尾词条可以靠置信度和抽检。把审核资源花在影响面大的词上。
第三，每个季度做一次词库体检。把长期零命中的词条下线，把冲突的词条清理，把失效的类目绑定更新。词库和代码一样会腐烂，不定期清理会越来越难维护。
第四，把词库的变更和业务节奏对齐。大促前不要大规模改词库，宁可提前两周稳定下来。大促期间出现搜索问题，排查成本是平时的好几倍。
第五，留一条人工干预的快速通道。业务方发现某个词搜不出来，要能在几小时内加上，而不是等下一个迭代周期。这条通道的权限要收好，但一定要有。
我个人在实际操作中的体会是，词库这件事没有做完的一天。用户的语言在变，商品在变，行业黑话在变，词库就得跟着变。真正决定成败的不是你第一版做得多全，而是你有没有建立起一套能持续吸收反馈、快速验证、安全回滚的机制。机制在，词库自己会长；机制不在，再全的词表也会在半年内变成一堆没人敢动的历史包袱。
