有些商品在这门语言里根本没有单数，可你的模板第一步就是取单数

摘要：词表和标题模板都默认每个名词有一个单数基本形，需要时再加复数。可每门语言里都有一批词只有复数形态，而且各语言里这批词并不重合，它还恰好压在成对用品、工具、衣物这些最日常的品类上。同一副护目镜，波兰语只有复数，德语只有单数，匈牙利语连一双鞋都算单数，中文根本没有这个维度。麻烦的是词干还原在这批词上不会失败，它会还原成另一个真实存在的词，于是全链路没有一处报错。本文给出识别办法、词表加一列的做法与两天能跑完的清查。

你的商品目录里，为什么会有一批词连单数都造不出来？

一家运动户外站的波兰语页面，标题上写着一条裤子的一半

有个客户做运动户外，滑雪护目镜、冲锋裤、抓绒手套、登山袜这几条线。

德语站跑了三年，数据稳定，团队照着同一套模板把波兰语站铺了出去。

模板没改，翻译请的是本地写手，商品数据从同一个库里出，看起来一切都对。

上线四个月，波兰站的品类页表现明显不如德语站，而两边的商品和价格是一样的。

保哥翻商品页的时候在标题上停住了：护目镜那个品类的标题里，波兰语词被模板削掉了一截，削出来的那个形态在波兰语里不存在。

更麻烦的是筛选结果那句提示，写的是找到1件商品，而那个品类词在波兰语里压根没有单数形态可以配这个1。当地用户读到的是一句谁都能看出不对、但又说不上哪里不对的话。

被削掉的那个形态还进了标题标签，也就是说搜索结果里显示的就是这个不存在的词。团队之前做过一次标题审计，审的是长度和关键词位置，没有人审过词形本身合不合法。

这批词有名字，而且被正经标注过

它不是特例，也不是写手的疏忽，语言学上早就有一个专门的名字。

通用依存标注体系在数这个特征下面列了一个专门的取值，叫作只有复数。

它的定义写得很直白：有些名词只以复数形式出现，哪怕它指的是一样东西。

换句话说，语义上是单数，形态上只有复数，两者对不上是这类词的常态。

这一条对做站的人有个很实际的含义：既然标注体系专门留了一个取值给它，说明它在多门语言里都成规模出现，不是一两个孤例。凡是能被标进特征表的东西，就能被批量识别，也就能被批量处理。

这个特征下面还有一个对称的取值，专门标只有单数的词。两个取值一起看，说明标注体系承认名词的数范畴可以缺一头，缺哪一头都算一种类型，而不是一种错误。

对做站的人来说，能被标进特征表还有一个更实际的含义：凡是有标注的地方就有现成数据可查，不必从零开始判断。后面讲到怎么找出这批词的时候，用的正是这批数据。

顺带提醒一句，这个取值在标注体系里的存在也解释了为什么各家工具的处理不一致：它是一个可选特征，标不标由各语言的标注团队决定。所以同一个工具在两门语言上的表现可以差很多，不是工具的问题，是数据的问题。

为什么它恰好扎堆在最日常的实物品类上

这批词的分布一点都不随机。

成对出现的东西占一大块，护目镜、眼镜、手套、袜子、耳机。

由两片合起来才能用的工具占一块，剪刀、钳子、镊子。

下半身穿的衣物占一块，裤子、短裤、连体裤。

再加上一批不成对但习惯上按整体说的东西，比如门、行李、假期。

把这几类摊开看会发现一件不太舒服的事：它们全是电商目录里最常见的实物品类，不是边缘长尾。也就是说，这个问题不出现在你的第一千个SKU上，它出现在你的第一个。

还有一件事值得注意：这批词在语料的词频表里位置很靠前，属于高频区，不是长尾。高频意味着它们同时出现在标题、面包屑、筛选器、结构化数据和商品数据里，一个词错了会同时错在五个位置。

同一副护目镜，五门语言给出五个答案

把同一样东西放进几门语言里对着看，差别大到有点滑稽。

波兰语的护目镜只有复数形态，想写一副得靠量词短语绕。

德语的眼镜反过来，标准形态是单数，一副就是一个词。

英语跟波兰语一边，只有复数。

匈牙利语走得更远，成对的东西一律按单数处理，一双鞋在语法上就是一只鞋的说法，因为一双被当成一个整体。

中文这边最省事，压根没有数这个语法维度，一副护目镜和三副护目镜里名词一个字都不用改。五门语言五种答案，而你的商品库里给这个品类只留了一个字段。匈牙利语那十八个格已经够让人头疼了，成对物品按单数算这一条还要再单独记一次。

芬兰语跟波兰语站在同一边，剪刀和裤子都只有复数形态。把这五门语言的答案并排放，能得出一条很实用的结论：跨语言复用同一张品类词表时，这一列一定要重新填，不能继承。

继承是这类错误最常见的来源。新市场上线时，团队通常从现有语言的词表复制一份再翻译，形态这一类属性会被原样带过去，而它恰恰是最不该继承的一列。

词干还原碰上这批词，为什么不是失败而是还原成功了但还错了？

还原器的工作前提是每个词都有一个基本形

词干还原这一步的目标很朴素：把一个词的各种形态收敛到同一个键上。

它的实现方式多数是规则加词尾表，遇到某个结尾就削掉，遇到某个结尾就替换。

这套做法能成立，靠的是一个从来没被写进文档的前提：每个名词都有一个可以被还原到的基本形。

对绝大多数词这个前提成立，对只有复数的词它不成立。

规则并不知道这一点，它照样削，削完之后照样返回一个字符串，也照样不报错。

多数实现其实留了口子，允许你配一份不参与还原的保护词表。这个功能通常是为品牌名和型号准备的，但它同样适用于这批词，而且是最省事的一种用法。

最坏的一种情形是还原出来的那个词真的存在

如果削出来的是一串没有意义的字母，问题反而容易发现。

真正难查的是削出来的那个形态在这门语言里确实存在，只是意思完全不同。

俄语的眼镜是一个只有复数的词，按常规规则削掉词尾之后，得到的是一个真实存在的名词，意思跟点数和小孔有关，跟眼镜没有半点关系。

于是索引里这个品类被并进了一个毫不相干的语义堆里，而所有校验都会通过，因为那确实是一个合法的俄语词。

这一类错误跟本站讲过的无糖和含糖被词干还原并成一个是同一个家族，区别在于那一类并的是两个真实词，这一类是把一个真实词并进了一个跟它毫无关系的词底下。

换个说法：那种错至少还留着一半线索，这种错连线索都没有，因为参与合并的两个词在字符串上完全说得通。

把这一类捞出来的办法不难：把品类词表整体跑一遍还原，只留下输出跟输入不同的那些行，再请母语者看一眼输出的那个词是什么意思。几百行的词表通常只有十几行会变，一眼就能扫完。

扫的时候重点看两类：输出的词在这门语言里存在但意思无关的，以及输出的词看着像词但母语者说没这个词的。前者危险，后者只是噪声。

这类错误为什么在任何日志里都留不下痕迹

软件工程里绝大多数错误会以异常的形式冒出来。

还原这一步不会，它的输出永远是一个字符串，永远返回成功。

索引侧不会报错，因为它收到的是合法输入。

查询侧也不会报错，因为它同样按规则处理了用户打进来的词。

最后表现出来的只是这个品类的站内搜索结果不太对、推荐位挂的商品有点怪、报表上这一类词的表现偏低。三个症状分属三个团队，没有一个会往字符层去找根因。

三个症状分属三个团队这件事值得展开一句：站内搜索归产品或者前端，推荐位归算法或者运营，关键词报表归检索这一侧。三方各自看到的都是一个可以忍受的小偏差，没有人手里有拼出全貌的那块。

词干算法的公开清单，本身就是一份哪些语言有人管的名单

做这件事之前有个便宜动作：去看一眼公开的词干算法项目收了哪些语言。

那份词干算法清单上大约三十门语言，覆盖了主要的欧洲语族。

值得留意的是它没有收哪些：日语、韩语、越南语、泰语、乌克兰语、希伯来语、波斯语都不在上面。

这不是项目做得不好，是这些语言的形态处理路子跟词尾削减不是一回事。

但对做站的人来说结论很直接：你要开的市场里有相当一部分，连一个公开的词干算法都没有，而你的站内搜索、你的推荐模块、你的关键词去重脚本，默认用的就是这份清单里有的那些。清单上没有的语言，你的系统多半是拿英语那套在硬凑。

清单上还有几个意外的条目，比如世界语和几门使用人口不多的语言，说明它是社区贡献驱动的，收录与否跟市场规模没有稳定关系。所以别拿商业重要性去推断某门语言有没有工具。

清单上没有你的目标语言时，值得花十分钟确认一下你的搜索引擎和站内搜索在这门语言上到底做了什么。常见答案有三种：完全不做处理、套用一个近亲语言的规则、或者退回按空格切分。三种的应对方式完全不同。

还有一种情况要留意：某门语言在清单上，不等于那套算法对你的品类有效。词干算法多数是拿通用文本调出来的，商品名里大量出现的品牌、型号、外来词，它未必处理得好。清单只能回答有没有，回答不了好不好。

关键词表按什么形态记这批词，才不会两头落空？

词表的默认列结构假设了单数是主键

多数团队的关键词表长得差不多：一列词、一列月搜索量、一列难度、一列意图。

那一列词填的是什么形态，通常没人规定，实际填的多半是词典原形。

而词典原形对绝大多数名词就是单数。

这个默认在英语站上从来不出事，因为英语的单数复数差一个字母，工具会替你合并。

到了形态丰富的语言上，这个默认会连锁出一串问题，本站在波兰语那七个格那篇里已经拆过一次，只有复数这批词是同一条链上更靠前的一环：连原形这个概念在这里都得重新定义。

还有一个连带影响在搜索量那一列上。关键词工具通常会把若干形态的量聚合起来报一个数，聚合规则不透明。对只有复数的词，聚合的对象里可能混进了那个被还原出来的无关词，于是这个数偏高。

给词表加一列数范畴，跟当年给缩略语加类型列是同一套动作

解法不复杂，就是在词表上加一列，标这个词的数范畴。

取值只要三个：只有复数、只有单数、正常可数。

这一列的成本接近于零，一个品类词表通常几百行，母语者半天能标完。

收益是后面所有批量脚本都能按这一列分支，而不是一刀切。

本站在缩略语那一批全英文的词里用过完全一样的思路：把语言学上已经想清楚的分类直接搬进词表，当成一个独立的词层特征，别指望脚本靠字符串长相去猜。

这一列建议同时放两处：词表里一份给内容和检索团队看，商品数据字段里一份给模板和下游系统读。两处的消费者不同，只放一处必然有一边读不到。

三个取值怎么判，判据要能交给不懂检索的人

标注这一列不需要语言学训练，只要一条能执行的判据。

问母语者一句话就够：这个东西只有一个的时候，这个词长什么样。

如果他给出的形态跟多个的时候一样，那就是只有复数。

如果他说这个词根本不分多少，那多半是只有单数或者不可数。

剩下的才是正常可数。这个问法的好处是它不需要对方懂什么叫数范畴，也不需要你懂那门语言，双方在同一个具体的东西上对齐就行。母语审校那一关最怕的就是问一句读着顺不顺，换成这种指着实物问形态的问法，答案立刻变得可验收。

如果对方不好意思说不知道，还有第二个问法：给他三件实物的图片，请他写一句说明这里有三件。他写出来的句子里名词长什么样，跟前一个问题的答案一对照，答案就闭合了。

标注的时候顺手记一件事：这个词有没有一个日常用的量词短语。有的话把那个短语一并记下来，它在写标题和筛选提示的时候立刻能用上，省掉一次回头再问。

标完之后哪几个脚本要改分支

这一列标完不改代码等于白标，要改的地方不多但要改全。

第一是词表去重脚本，只有复数的词禁止参与形态归并。

第二是标题模板，遇到这一列取值为只有复数的品类，跳过单数槽位。

第三是站内搜索的索引配置，把这批词加进不做还原的保护词表。

第四是商品数据同步，导出给下游的那份也要带上这一列，否则平台侧和数据源侧还是会各自还原一次。改动都在配置层，没有一处需要动业务逻辑。

还有第五处容易漏：导出给比价平台、广告平台和渠道方的那几张数据表。这些出口一旦漏掉，改过的形态会被外部系统按旧值同步回来，几个月后又冒出来。

用户在搜索框里打的到底是哪个形态？

这批词的搜索侧其实比想象中干净

讲到这里有个反直觉的好消息。

只有复数的词在搜索侧的形态分叉比普通名词少得多。

原因很简单：没有单数形态可以打，用户没得选。

普通名词至少要在单数和复数之间分流量，这批词天然集中在一个形态上。

所以真正需要纠结的不是主词怎么写，而是它前后跟着的那些成分。

这带来一个可以量化的附带好处：这类品类的关键词表行数明显少于同规模的普通品类。做词表预算的时候可以按这一列打折，省下来的行数配额留给别的品类。

真正分叉的是它前面那个数量说法

用户想买一副护目镜的时候，搜索框里打的很可能不止品类词。

带数量的查询在这类品类上占比不低，尤其是成对出售的品类。

而数量说法在各语言里的写法差得很开，有的靠量词短语，有的靠专门的成对量词。

这批说法多数不在你的词表里，因为词表是按品类词建的。

补的办法不是硬造，是去看搜索建议：在目标语言的搜索框里打出品类词，把下拉里带数量成分的那几条抄下来，通常十分钟能抄出七八条真实说法，比翻词典靠谱得多。

抄下来之后建议按三类归档：带纯数字的、带量词短语的、带专门成对量词的。三类在页面上的落位不一样，第一类适合放筛选结果提示，第二类适合放商品标题，第三类多数只适合放正文。

量词与品类词的搭配在各语言里不是同一件事

成对物品的量词是这批词最容易出洋相的地方。

英语要一个专门的成对量词才能给复数名词计数。

波兰语用另一套结构，而且这个结构还会牵动后面名词的格。

德语因为本来就是单数，直接用普通数词就行，一个词都不用加。

匈牙利语最省事，数词后面名词干脆不变复数。四门语言四种拼法，如果标题模板打算统一处理，那它注定在其中三门语言上是错的。

匈牙利语那条还有个连带后果：数词后面名词不变复数，意味着模板里那个复数分支在这门语言的这类品类上永远不该被触发。如果日志里发现它被触发过，那说明模板走错了分支，值得追一下。

半小时能把这批词的搜索侧验一遍

验证不需要工具授权，也不需要花钱。

把圈出来的品类词逐个丢进目标语言的搜索框，看下拉建议给出什么形态。

下拉给的形态就是真实用户在打的形态，它比任何词典权威。

再把这个形态丢回搜索框，看结果页第一屏是不是本品类的商品页。

是的话这个词就定死，写进词表的形态列。二十个品类词跑完不到半小时，而这半小时省掉的是后面几个月的形态争论。小语种关键词工具返回零的时候用的也是这一路办法，只是那边解决的是有没有量，这边解决的是形态对不对。

记录格式建议固定成四列：品类词、验证到的形态、下拉建议原文、验证日期。第三列留原文是关键，半年后复核时能直接看出当时是照着什么下的判断，而不是只剩一个结论。

标题模板里那个数量前缀，会崩在哪一步？

模板的槽位假设了名词能跟着数字变

品类页和筛选结果页的标题通常是拼出来的。

常见结构是数字加品类词加修饰语，比如多少件某某商品。

这个结构成立的前提是名词能根据前面那个数字变形。

只有复数的词没有可变的那一头，数字是1的时候找不到对应形态。

模板不会因此报错，它会拿手上有的那个形态硬填，填出来的句子在母语者眼里是明确的语病。

同一套模板通常还负责筛选结果页和分页标题，所以一处崩就是三类页面一起崩。这三类页面恰好是品类流量的主要承载者，损失面比看上去大。

复数规则表里没有给这批词准备分支

处理这类拼句的标准做法是用国际化组件的复数规则。

规则按语言给出若干个类别，波兰语和俄语这类语言的类别比英语多。

模板写的时候要给每个类别各写一句话，组件在运行时按数字挑一句。

问题在于只有复数的词根本用不到数量为1的那个分支，可模板还是要求你把它填上。

多数人会照着别的品类填一个，于是这个分支里躺着一个不存在的词形，只等某个筛选条件恰好只剩一件商品的时候露出来。本站在界面文案那批没进翻译文件的字里讲过这套组件怎么用，那边的问题是句子没被抽出来，这边的问题是句子抽出来了但有一个分支填不了。

各语言要写几个分支差别很大：英语和德语两个就够，波兰语和俄语要四个，阿拉伯语更多，中文只要一个。模板的复杂度不是由你的功能决定的，是由你要上的语言决定的。

只有复数的词让最难写的那个分支变成了死代码：它永远不会被执行，可组件仍然要求你填。这一格填什么没有正确答案，务实的做法是填一句不带数字的说法，让它就算被触发也不出病句。

崩掉之后的三种表现，只有一种看得出来

把后果拆开看，一共三种。

第一种是页面上直接出现病句，这种最容易发现，因为本地用户会截图来问。

第二种是模板输出的形态跟用户搜的形态对不上，这一种只表现为排名偏低。

第三种最隐蔽：模板输出的那个不存在的形态被当成有效词写进了页面标题，然后被抓进索引，成为这个页面的主词。

第三种的排查成本最高，因为从后台看一切正常，只有把标题标签逐条导出来对着母语词表比才看得见。

第三种的排查办法是把全站标题标签导出来，跟母语词表做一次字符串比对，只看这批品类的行。几千条标题跑一次不到十分钟，产出的是一份可以直接派活的清单。

还有一个容易忽略的暴露点：结构化数据里的名称字段多半也从同一套模板取值。所以模板崩掉的时候，页面上和给机器看的位置是同时崩的，只是后者没有人会去读。

最省事的解法是把数量前缀从这批品类上撤掉

这一段给一个不太体面但很有效的建议。

如果只有一两个品类踩这个坑，专门为它们写规则不划算。

更省事的做法是给这批品类的标题模板换一个不带数量的版本。

标题里少一个数字，检索上的损失基本可以忽略，因为数量成分本来就不承载多少检索价值。

而换掉之后，整条崩溃链一次性断掉。这是那种典型的用版面决定绕开语法决定的做法，本站在屈折语站的锚文本那篇里也用过一次：把需要精确形态的内容挪到不需要变形的位置去，比在原地跟语法较劲省力得多。

有一类品类不能撤：数量本身是卖点的，比如成套餐具、多件装的袜子。这类品类的用户就是在比几件装，撤掉数字等于撤掉卖点。这时候只能老老实实为它写规则，或者换一个不依赖名词变形的表达结构。

站内搜索与筛选器，会在这批词上出什么岔子？

索引侧和查询侧用的不是同一个还原器时

站内搜索出问题最常见的根因不是还原错了，是两边还原得不一样。

索引侧建库时用一套配置，查询侧解析用户输入时用另一套。

两边都正常工作，两边给出的键不一样，于是永远匹配不上。

只有复数的词特别容易触发这种不一致，因为它是规则表里的边缘情形，不同版本的实现对它的处理经常不同。

排查办法很直接：拿这批词在两侧各跑一次，把输出的键打印出来对着看。不一致的那几条就是问题所在，通常不超过五条。

还有一个容易忽略的触发时机：组件版本升级。同一个还原器的不同版本对边缘情形的处理经常不同，而索引是几个月前建的、查询用的是刚升级的版本。所以这类组件的版本值得锁死并记录。

筛选器的分类名和商品名会在这批词上撞车

分类名习惯上用复数，因为它指的是一类东西。

商品名习惯上用单数，因为它指的是具体一件。

这个约定在只有复数的品类上直接失效，两者写出来一模一样。

后果是面包屑上的分类名和商品标题看着重复，页面读起来像少了一层。

更实际的影响在结构化数据那一侧：分类页和商品页的名称字段取值相同，机器读到的层级信息就变薄了一层。属性枚举值那件事讲过面向机器的字段该怎么取值，这里是同一条原则在名称字段上的应用。

面包屑那一处有个简单的解法：给分类名加一个限定词，比如按用途或者场景加一个前置修饰。这样分类层和商品层在字面上就区分开了，也不需要改任何模板逻辑。

同义词表该给这批词写什么条目

站内搜索的同义词表是收拾这类问题最省事的地方。

给这批词写条目的原则是把用户可能打出来的所有形态都映射到同一个键上。

包括那个由还原器造出来的、语言里其实不存在的形态。

这一条听起来别扭，但它挡住的是自己系统制造出来的噪声。

同义词表的好处是它不对外展示，不会被当成堆砌，改起来也不需要发版。本站反复讲过这个位置是匹配层唯一安全的收纳处，只有复数这批词正好是它的典型用户。

还有个细节要定：条目写成单向还是双向。把错形态映射到真实形态用单向就够，反向不需要，否则会把正常查询也带偏。多数站内搜索组件默认是双向，需要显式改。

一个能当天跑完的对照测试

验证方案很土：准备一张两列的表。

左列是这批品类词的真实形态，右列是还原器给出的形态。

两列各在站内搜索里跑一次，人工看前十条结果有几条对得上。

右列返回的结果如果跟左列差很多，说明查询侧在做还原而索引侧没有，或者反过来。

二十个词跑完不到两小时，产出的是一个能直接汇报的数字，而不是一句感觉不太对。

判读标准建议先定死：前十条里有八条以上属于本品类算通过，五到七条算可疑，五条以下算不通过。不先定标准，跑完之后一定会陷入这算不算对的争论。

结构化数据和平台字段里，这批词该填哪个形态？

面向机器的字段不承担语感，但它承担一致性

结构化数据的名称字段是给机器读的，不需要读起来像人话。

但它需要跟页面上可见的那个形态保持一致。

只有复数的词在这里反而最省心：因为只有一个形态，不存在选哪个的问题。

真正要小心的是那些自动生成的字段，它们经常从商品名里截一段，截的时候顺手做一次还原。

这一截就把不存在的形态写进了给机器看的位置。本站在结构化数据要反着写回国际格式那篇里讲过面向人和面向机器的位置该分开优化，这里要补一句：分开优化不等于分开生成，两边的名词形态必须来自同一个字段。

自动生成的字段最常见的来源是截取商品名的前若干个字，或者从分类路径拼一段。两种来源都有可能在中间插一次还原，接入时值得逐个确认一遍它有没有做这件事。

平台侧的语言处理能力比网页侧弱一档

把商品放上第三方平台的时候，这批词的问题会重演一次，而且更难查。

平台侧的搜索多数不做词形还原，也不做复合词拆分。

好处是它不会替你还原出一个错的形态。

坏处是它也不会替你把不同形态合并，你填什么它就按什么匹配。

结论是平台侧的策略跟网站侧正好相反，本站在平台搜索词字段那笔字节账里算过这笔账：网站侧要收敛，平台侧要铺开。只有复数的词在平台侧反而是最好处理的一类，因为它本来就只有一个形态可铺。

平台侧还有一个反向风险：它的自动补全会把你填过的形态固化下来。你填错一次，这个错形态会作为候选出现在用户面前，被点击之后进一步被加强，最后变成一个你自己造出来的搜索词。

变体商品的标题继承会把错误形态复制到全站

变体商品是这类错误的放大器。

同一款护目镜有五种镜片颜色，多数系统会让变体继承主商品的标题结构。

主商品那条如果用了还原出来的错形态，五条变体全部照抄。

一个品类几十个SKU，几百条标题里同一个错误形态整齐地重复。

这时候看报表会得到一个很误导的信号：这个错误形态的展现量看起来很高，因为它出现在几百个页面上。展现量高不等于有人搜，它只说明你自己写了很多遍。

定位这类问题的办法是从模板反查而不是从页面反查：找出所有使用同一套标题模板的商品，按品类分组，只抽查每组的第一条。模板对了整组都对，模板错了整组都错，抽查一条就够。

别名类字段能放多个值，但不该乱放

结构化数据里有几个字段允许放多个取值，是收纳形态变体的好位置。

可以把品类词的真实形态和常见的口语说法一并放进去。

不该放的是那个由还原器造出来的形态，它不是一种说法，它是一个事故。

放进去的每个值都在向机器声明这是同一个东西，塞进不存在的词只会稀释这个声明。

判断标准很简单：这个形态有没有真实用户打过。搜索建议里出现过的可以放，只在你自己日志里出现过的不要放。

把这条判断操作化：搜索建议里出现过的可以放，站内搜索日志里被真实用户打过三次以上的可以放，只在你自己系统的输出里出现过的一律不放。第三类正是还原器造出来的那批。

集合名词是另一半，它的麻烦不在形态在计数

只有复数和集合名词是两件不同的事

这两类词经常被放在一起说，但它们的机制不一样。

只有复数的词是形态上缺了一头，语义上指的可能就是一件。

集合名词是形态上是单数，语义上指的是一堆。

家具、行李、首饰、餐具都属于后者。

做站的时候前者卡在词形，后者卡在计数：用户想买一件，而你的词表里那个词指的是一批。

还有第三类容易混进来的：不可数的物质名词，比如洗涤剂、油、纤维。它跟集合名词的区别在于它连一个整体都不指，只指一种东西。这一类在电商里靠包装规格来计数，处理方式又不一样。

库存单位怎么写才不会跟用户对不上

集合名词最直接的麻烦在库存和购物车。

德语的家具是一个集合概念，说一件家具要用一个专门的组合说法。

商品页上如果直接用那个集合词加数量，读起来像是在卖一整套。

解法是在这类品类上把上位词换成具体的下位词，卖的是椅子就写椅子。

上位词留给分类页和面包屑，它在那儿是对的；商品页要的是能被一件一件数出来的词。当年拿词典逐词换出来的那批词里，上位词错位是最常见的一类，因为词典给的往往正是那个集合形态。

购物车行和结算页是这一类词最后暴露的地方。列表页可以只写品类名蒙混过去，购物车必须写数量加单位，一旦写成集合词加数字，读起来就是买了三批而不是三件。上线前把这两页按语言各看一遍。

谓语一致那一层对检索的影响其实很小

讲集合名词绕不开谓语一致的话题，但这里要泼一盆冷水。

集合名词后面的动词该用单数还是复数，各语言各有习惯，英式和美式甚至相反。

这件事对读感有影响，对检索基本没有影响。

原因是查询串里几乎不带谓语，用户搜的是名词短语。

所以这一层交给母语写手按语感处理就行，不必写进技术规范，也不值得为它单开一次审校。把有限的审校预算花在名词形态上，回报高得多。

有一个例外值得留意：问答型的长尾查询里会出现完整句子，这时谓语就进了查询串。如果你的品类有大量这类长尾，那么这一层值得在正文里顺着当地习惯写，但仍然不必写进技术规范。

什么时候该把集合名词整个换掉

有一种情况值得动刀：这个集合词的搜索量明显低于它下面的具体词之和。

这通常意味着当地用户不拿这个层级说话。

判断办法是把集合词和三到五个下位词一起拉一遍量，看分布。

如果集合词只占两成以下，就把它从主词位置上撤下来，让位给下位词。

撤下来不等于删掉，它还可以留在导航和面包屑里承担结构角色。这跟两个市场的关键词表可以一字不差那篇的结论是配套的：词表能共用，落地页的层级安排未必能共用。

撤下来之后要顺手处理内链。原来指向集合词页面的锚文本要跟着改，否则会出现锚文本说的是上位词、目标页讲的是下位词的错配。改的量通常不大，但漏掉会让整块内链的相关性打折。

还有一个信号可以一起看：这个集合词在站内搜索里的零结果率。如果用户拿它来搜却搜不到东西，说明你的商品数据里根本没有按这个层级组织过，那它在页面上出现得越多越误导。

没有词典也没有语料的语言，这批词该怎么找出来？

先从自己的目录里捞，别从语言学清单里捞

网上能找到的只有复数词清单通常是按语言编的，动辄几百条。

照着那种清单一条条查，多数条目跟你的生意没有关系。

更省事的方向是反过来：先把自己目录里的品类词列出来，再逐条问它属不属于这一类。

一个中型独立站的品类词通常在两三百条以内，命中的一般不超过二十条。

二十条是一个人一个下午能处理完的量，而按语言学清单查要花掉一周还查不全你真正需要的那些。

按中文品类过一遍就行，这一点值得解释：成对用品、两片合起来用的工具、下半身衣物这几类在多数语言里是重合的，中文虽然没有数范畴，但品类的物理属性是一样的。所以中文清单能当筛子用。

三条免费路径，各自能查到什么

没有母语顾问的时候，有三条路可以走。

第一条是形态标注数据集，通用形态标注项目按语言给出词形表，能直接看到某个词有没有单数形态。

第二条是大型语料库的词频界面，莱比锡语料库覆盖的语种很多，查一个词的实际出现形态足够用。

第三条是当地的权威词典，德语这边的假期词条就直接标着只用复数，这类标注在成熟词典里是标配。

三条路的共同点是免费、不需要授权、查一个词都在一分钟以内。缺点是它们对低资源语言的覆盖会断档，断档的时候只能靠人。

三条路各有断档：形态数据集在低资源语言上覆盖不全，语料库如果主要由法律和新闻文本构成，对消费品类的判断会有系统性偏差，词典的更新速度跟不上新品类。查之前先看一眼这三项说明。

母语审校那一关该怎么问才问得出来

把稿子丢给母语者问一句有没有问题，多半得到的回答是没问题。

因为在他眼里，正确的形态本来就是唯一的形态，他不会觉得这里有个选择。

要问出东西来，得把问题换成填空题。

给他一句带数字1的句子，让他把品类词填进去，看他怎么处理。

他如果绕开了数字，改用一个量词短语，那就说明这个词确实没有单数，答案就出来了。这一招的价值在于它不依赖对方懂语法术语，只依赖他会说这门语言。

还有一种情况要留意：有些词在书面语里勉强能造出单数，母语者也能接受，但日常没人这么说。这时候他会给你一个形态，而这个形态在搜索侧几乎零量。所以问完形态之后一定要再跑一次搜索建议验证。

查出来之后一定要留档，因为它几年不变

这批词有一个很好的性质：它极其稳定。

颜色范畴会随流行走，代际用词会变，可一个名词有没有单数形态，几十年不动。

也就是说这次的投入是一次性的，往后开新品类只需要增量维护。

留档的形式建议直接落在词表那一列上，而不是另开一个文档。

另开文档的下场是三个月后没人记得它在哪儿，落在词表列上则会被后续每一次批量操作自动读到。

字段命名建议直接叫数范畴或者词形类别，别叫特殊词标记这类含糊的名字。含糊的名字会在半年后被别人拿去装别的东西，一年后这一列就变成了什么都有的杂物间。

把这件事收成一张两天能做完的表

第一天上午：从目录里圈出候选品类

第一步是把商品目录按品类导出来，只要品类名这一列。

然后按前面那几个类别过一遍：成对的、两片合起来用的、下半身衣物、习惯按整体说的。

过完通常能圈出十几到二十几条候选。

这一步不需要懂目标语言，按中文品类过就行，因为这几类在多数语言里是重合的。

圈完之后按流量排序，只有前二十条值得往下走，剩下的记进表里等以后。

导出的口径建议按叶子分类而不是按商品，因为同一个品类下几百个商品用的是同一个品类词。按商品导会得到几万行重复数据，按叶子分类导通常两三百行。

第一天下午：定形态，一条一条定死

候选圈出来之后，逐条确定它在目标语言里的形态。

顺序是先查词典标注，查不到再查语料库，还查不到才问人。

每条记三样东西：真实形态、数范畴取值、验证来源。

记来源这一列很关键，半年后复核的时候能立刻分清哪些可以跟着上游更新、哪些是自己判断的。

二十条走完通常两三个小时，如果有母语顾问在线会更快。

三条路都查不到的时候有个兜底：直接在目标国家的电商站上搜这个品类，看当地卖家的标题怎么写。当地卖家未必语法完美，但他们写的是真实在卖的说法，作为形态参考足够可靠。

第二天：改模板、加白名单、验一遍

第二天全部是工程动作。

把数范畴那一列同步进商品数据字段，让模板能读到。

给这批品类的标题模板关掉数量槽位，或者换一个不带数字的版本。

把这批词加进站内搜索的保护词表，禁止还原。

最后把同义词表补上，把还原器可能造出来的形态映射回真实形态。四个动作都在配置层，改完不需要回归测试整站。

改完之后的回归范围建议限定在这批品类的三类页面上：品类页、筛选结果页、商品页。不必回归整站，因为改动都在配置层且按品类分支，影响面是可枚举的。

上线前的四项检查与三档判据

上线前照着四条走一遍：标题标签里有没有出现不存在的形态、筛选结果那句提示在只剩一件时读不读得通、站内搜索用真实形态能不能搜到、结构化数据里的名称跟页面可见文字一不一致。

做不做这件事，也有三档判据。

目录里命中五条以上、且其中有主力品类的，值得按上面的两天流程做完。

命中一两条、且都是长尾品类的，只改标题模板那一处就够。

目标语言完全没有数这个语法维度的，比如中文和越南语这类，整件事不成立，直接跳过。判断顺序永远是先看语言有没有这个维度，再看自己踩没踩上。

还有第四种情形要单独说：多语言站里只有部分语言有这个维度。这时候正确做法不是给所有语言都加这一列，而是先按语言标一遍有没有数范畴，没有的语言整条流程跳过，别浪费审校预算。

最后补一条经验：这件事一旦做完就基本不用回头，因为词形不变、品类也不常变。所以它属于那种一次性投入、长期收益的工作，值得在新市场上线的第一个月里排掉，而不是等出了问题再补。

常见问题解答

只有复数的品类词，关键词表里到底该记哪个形态？

记那个真实存在的复数形态，并且在旁边加一列标明它属于只有复数这一类。不要为了跟其他行对齐而硬造一个单数填进去，那个形态在这门语言里不存在，写进表里之后所有下游脚本都会当它是真的。判断形态的最快办法是在目标语言的搜索框里打这个词，看下拉建议给出什么，下拉给的就是真实用户在打的。

词干还原把这批词还原错了，为什么系统一点提示都没有？

因为还原这一步的输出永远是一个字符串，它没有失败这个返回值。规则削掉词尾之后得到什么就返回什么，即便得到的是一个跟原意毫无关系的真实词，它也是合法输入。索引侧和查询侧都收到了合法输入，两边都不会抛异常。最后表现出来的只有站内搜索结果不准、推荐位挂错商品、这一类词报表偏低这三个症状，而它们分属三个团队。

做中文站需要管这件事吗？

不需要。中文没有数这个语法维度，一副护目镜和三副护目镜里名词一个字都不用改，所以整条链上不存在还原错、模板崩、形态对不上这些问题。真正要管的是从中文往外做的时候：目标语言里有这个维度，而你的模板和词表是按中文的直觉建的，那批默认假设会一路带过去。判断顺序是先看目标语言有没有这个维度。

这批词大概会占目录里多大比例？

按品类数算通常是个位数比例，一个两三百条品类词的站命中一般不超过二十条。但按流量算权重会明显偏高，因为命中的多是成对用品、工具和衣物这类日常品类，不是长尾。所以判断值不值得做，不要看命中条数占比，要看命中的那几条在流量里排第几。有主力品类在里面就值得做一遍。

能不能直接拿网上的只有复数词清单来对？

可以当参考，但别当主路径。那类清单是按语言编的，动辄几百条，其中跟电商目录有关的可能只有十几条，逐条查完要花掉一周。更省事的方向是反过来：先把自己目录里的品类词列出来，再逐条判断，命中的一般二十条以内，一个下午能处理完。清单适合用来做交叉验证，不适合用来做起点。

平台侧和自己的站，处理策略需要分开吗？

需要，而且方向相反。自己的站上要做的是收敛，把用户可能打出来的各种形态映射回同一个键，重点在同义词表和保护词表。平台侧多数不做词形还原，你填什么它按什么匹配，重点变成铺开，把该出现的形态都放进去。只有复数的词在平台侧反而最好处理，因为它本来就只有一个形态可铺，没有取舍。

集合名词要不要跟这批词一起处理？

可以放在同一次排查里，但要分开记，因为解法不一样。只有复数的词卡在形态，解法是保护词表加模板分支。集合名词卡在计数，解法是在商品页上换成能一件件数出来的下位词，把集合词留给分类页和面包屑。两类词唯一的共同点是都需要在词表上多一列来区分，所以顺手一起标注是划算的。

权威参考资料