无糖和含糖在小语种词表里只差三个字母，词干还原把它们并成了一个

摘要：无糖、无线、免烫这类否定属性词，在英语里是两个词，在德语里是粘在词尾的四个字母，在芬兰语里是一个后缀。否定一旦长进词里，广告的否定关键词、站内搜索的排除语法、词干还原器全都失效，而失效的方式是把语义相反的两个词判成同一个。本文拆开这条链路上的六个落点，给出一份不需要懂那门语言就能跑的自检办法。

无糖这两个字，在小语种里未必是两个词

德语的frei是后缀不是一个独立的词

德语说无糖写成zuckerfrei，一个词，中间没有空格也没有连字符。

无麸质是glutenfrei，无咖啡因是koffeinfrei，构词方式完全一样。

这个frei单独拿出来确实是个词，意思是自由，但在这里它已经是后缀。

后缀和词的差别不在语感上，在处理上：后缀不能被空格切开。

凡是靠空格找边界的程序，看到zuckerfrei只会看到一个整体。

德语还有另一族否定后缀，比如无线写成kabellos，防水写成wasserdicht，构词逻辑跟frei那一族一样但用的是别的成分。这意味着你没法靠维护一张后缀清单来穷举，因为这类成分在德语里是开放的，新的组合随时会出现。

更麻烦的是同一个概念常常有两种写法并存，一种是后缀式的一个词，另一种是介词短语的三个词。两种写法的搜索量分布往往差得很远，而如果你只覆盖了其中一种，那就等于放弃了另一半。

芬兰语的ton把否定压进了词尾

芬兰语的无糖是sokeriton，含糖是sokerillinen，两个词共用同一个词干。

词干是sokeri，也就是糖，后面接的那几个字母决定了意思是有还是没有。

这两个形态在字符串上极其接近，前六个字母一模一样。

而它们表达的是一对完全相反的意思，中间没有任何过渡地带。

芬兰语的这个后缀还会跟着元音和谐变形，同一个否定后缀有两个形态。

更进一步，芬兰语的名词有十几个格，每一个格都会给这个否定形态再加一层结尾。于是同一个概念在真实文本里能写出十几种形态，而这十几种形态全都以同一个词干开头，跟含糖那一族的十几种形态混在一起。

这种情况下，任何按前缀匹配的逻辑都会把两族词一起捞出来。搜索建议、自动补全、站内搜索的模糊匹配，全部会同时返回意思相反的两组结果，而系统本身完全不知道自己做错了什么。芬兰语词干本身的变化另见芬兰语十五个格与词干交替的处理办法。

英语的sugar-free为什么是个例外

英语的sugar-free中间有一个连字符，某些写法里干脆是两个词。

这个连字符不是装饰，它是一条机器能看见的边界。

因为有这条边界，英语的否定属性词可以被切分、被排除、被单独统计。

英语的常见否定成分数量有限，前缀那几个加上free这一族，基本能列完。

所以英语站上从来不需要专门处理否定这件事，它是自动被处理掉的。

问题在于，正因为英语从来不需要处理，所有以英语为默认假设写出来的工具、语法和最佳实践，都没有为这件事预留位置。你不会在任何一份广告投放手册里读到否定词可能不是一个独立词元这句话，因为写手册的人从来没遇到过。

这条判据可以直接拿来筛语种：把你的目标语言列一遍，逐个问一句无糖这个概念在这门语言里写出来是几个词。答案是一个词的语言全部需要单独处理，答案是两个词的可以先按英语经验走。

英语这个例外还有一个副作用：它让整个行业默认否定是一件不需要讨论的事。你去翻任何一份多语言SEO清单，里面会有变音符号、有词形变化、有书写系统，唯独没有否定这一条，因为它在英语里从来没成为过问题。

否定粘进词里之后，会发生什么？

一个词的意思被反转，长度只加了四个字母

从sokeri到sokeriton，字符串多了三个字母，语义整个翻了个面。

从Zucker到zuckerfrei，多了四个字母，同样是完全相反的意思。

这个比例在信息处理上很不友好：改动量极小，后果极大。

几乎所有基于相似度的算法，都会把这两个词判成高度相关。

而它们确实相关，只是相关的方式是对立，不是同义。

算法能识别的是距离，识别不了方向。编辑距离告诉你两个字符串差多少，它不会也不可能告诉你差出来的这几个字母是加了一个限定还是把整句话否定掉了。这是一个原理上的限制，不是实现得不够好。

这条性质还有一个反直觉的推论：两个词越像，被错误合并的概率越高，而否定形态天生就是最像的那一类。也就是说，语义上最需要被区分开的一对词，恰好落在算法最容易搞混的位置上。

词表的行数不会变，语义面却翻了倍

做关键词表的时候，很容易把否定形态当成同一个词的变体收进去。

收进去之后表还是那么长，看不出有什么异常。

但这张表现在同时包含了两组意图完全相反的查询。

用它去分组、去算搜索量、去规划页面，得到的结论会混在一起。

最直接的后果是你以为某个词很值钱，其实值钱的是它的反面。

正确的做法是在词表里给否定加一列，把每一行标成肯定或者否定。这一列的填法可以半自动，先按后缀规则跑一遍，剩下拿不准的人工过一遍，一门语言通常一两个小时能标完。有了这一列，后面所有的分组和统计才是可信的。

这件事在英语项目上不需要做，因为否定词天然带着空格，分组的时候自然就分开了。到了德语芬兰语土耳其语这些语言，这一列不加，你的整张词表就是一份把正反混在一起的数据。相关的词表结构问题另见小语种关键词工具返回零时的补数据方法。

还有一个实际的影响落在分组上。把否定形态和肯定形态放进同一个广告组，系统会按整体表现来分配预算，而两边的转化率往往差很远，结果是好的那一边被差的那一边拖着，报表上却看不出原因。

分词器看不见这条边界

分词器的任务是找词与词之间的边界，它按空格、标点和词典来判断。

zuckerfrei在词典里就是一个条目，分词器没有理由把它切开。

就算切开了也未必是好事，切完之后否定的作用范围就丢了。

因为一个后缀被切下来之后，它跟哪个词干配对这条信息就不在了。

所以不切是对的，问题出在切与不切之外的那一层：语义标注。

跨语言的词边界判定有一套通用规则，可以参考Unicode标准附件29的词边界一节，但要注意那份规则解决的是形式上的边界，它不负责告诉你这个边界两边的成分在语义上是什么关系。

真正能表达这层信息的是词法标注体系。Universal Dependencies的极性特征就是专门为这件事准备的一个字段，它记录一个词形是肯定还是否定，跟词干和词性分开存放。这套字段存在本身就说明，语言学界很早就承认了这条信息没法从字符串里推出来。

排除词和负关键词为什么会全部失效？

广告的否定关键词是按词元匹配的

广告后台的否定关键词功能，工作方式是把查询切成词元再比对。

你添加一个否定词，系统会去查询里找有没有这个词元。

德语用户搜zuckerfrei的时候，查询里只有一个词元。

你想排除掉无糖那一类流量，就必须把整个zuckerfrei当成否定词加进去。

而这个词的形态有好几种，你得一个一个加，漏一个就漏一批。

更麻烦的是德语的复合能力，同一个概念可以出现在更长的复合词里，比如把品类词和这个属性直接拼成一个词。这类复合形态的数量在原理上是无限的，你不可能靠穷举把它们全部加进否定列表。

可行的应对是换一个层面处理：不在关键词层面排除，而在广告组层面拆分——专门开一组只投否定形态，出价和落地页都单独配。这样不需要排除，因为两类流量从一开始就走了两条不同的路。

顺便提醒一句，别指望靠给分词器加自定义词典解决。你可以把否定形态加进词典让它被识别成一个整体，但识别成整体之后系统仍然不知道它跟肯定形态是对立关系，缺的那条信息还是缺的。

站内搜索的排除语法也是同一个道理

大部分站内搜索引擎支持在词前面加一个减号来排除。

这个语法的前提同样是否定作用于一个独立的词元。

用户想找不含某种成分的商品，在这类语言里没法用减号表达。

他只能整个打出那个否定形态的词，然后指望系统认识它。

而系统认不认识，取决于你有没有给它配过对应的同义词或者规则。

这里有个容易被忽略的细节：就算用户会用减号语法，他减掉的那个词元也可能不存在。他想减掉的是糖这个成分，可页面上写的是含糖那个后缀形态，两者的字符串对不上，减号减了个空。

解决办法是在搜索层配一张显式的映射表，把每一对正反形态绑起来，并且明确标注方向。这张表没法自动生成，但它的规模不大，一个品类通常十几对就覆盖完了。

还有一个常被忽略的细节是排除语法本身的可发现性。用户不知道减号能用，站内搜索的输入框也不会提示他，所以就算你把语法支持得很好，实际用到它的查询也只占极小一部分，靠这条路解决问题不现实。

正则的否定前瞻救不了这一层

工程同学第一反应常常是写正则，用否定前瞻把某类形态排掉。

这个思路在单个词上能用，放到整张词表上就会开始出错。

因为否定后缀跟别的后缀在字符层面没有任何区别，正则分不出来。

芬兰语里以ton结尾的词并不都是否定，也有本来就长这样的词。

误伤一旦发生，你在结果里是看不出来的，只会觉得召回变少了。

正则的根本问题在于它工作在字符层，而这件事的信息在形态层。用字符层的工具去解决形态层的问题，能对付一部分特例，但没法收敛——每修一个误伤就要加一条例外，加到二十条之后没人敢动那个正则了。

更稳的路线是用现成的形态分析器。Hunspell拼写检查库的词典文件里带着完整的构词规则，能告诉你一个词形是由哪个词干加哪些词缀构成的，这个信息正是正则拿不到的那一层。

还有一种局面更难受：品牌方要求同时投正反两类商品。这时候两个广告组之间会互相抢量，因为查询里的词元有重叠，你需要在账户结构上再加一层否定或者用完全匹配把边界画死。

保哥踩过的那次：无线那一组把有线的全带出来了

保哥有个做家纺和家居配件的客户，德语站上有一整组无线类商品。

投广告的时候把无线那个词加进了关键词，同时想排掉有线的流量。

排除列表里加的是有线那个词，看起来天经地义。

跑了两周发现搜索词报告里全是有线相关的查询，排除完全没生效。

原因是德语用户打的那个复合词里，有线那部分不是一个独立词元。

这件事最坑的地方在于报表看起来是正常的：曝光有、点击有、花费也在跑，只有转化率一直偏低。如果不去逐条看搜索词报告，你会以为是落地页的问题，然后去改落地页，改上一个月也不会有起色。

后来的处理办法很简单，把无线和有线拆成两个广告组，各自用各自的关键词，谁也不排除谁。当排除机制在某门语言上不可靠时，最省事的替代方案是不排除，改成正面圈定，这条经验后来在好几门语言上都用上了。

另外要留意的是搜索建议这一层。用户还没打完就被联想词带走了，而联想词多半来自一个更粗糙的前缀匹配逻辑，正反形态在那一层混得比正式搜索结果还厉害，很多误入是在这里发生的。

词干还原为什么会把相反的两个词并到一起？

词干还原器默认就是要剥掉后缀的

词干还原的目的是把同一个词的各种形态归到一个键上。

它的做法是识别并剥掉结尾的那些变化成分，只留下核心。

否定后缀在形式上跟别的后缀长得一样，所以也会被剥掉。

剥完之后，含糖和无糖两个词都变成了糖这一个词干。

从算法的角度这没有错，它做的正是它被设计来做的事。

要看具体的剥离规则可以直接查Snowball芬兰语词干提取算法说明，里面列出了这套算法会处理哪些结尾。把你关心的那几对正反形态照着规则手工跑一遍，十分钟就能确认它们会不会撞在一起。

德语那一侧同理，Snowball德语词干提取算法说明的规则更短，但它对复合词基本不做拆分，所以德语的问题表现形式跟芬兰语不一样：芬兰语是被剥错，德语是根本没被拆开。

另一个值得注意的点是索引侧和查询侧必须用同一套还原规则。两侧配置不一致的时候，问题会表现得毫无规律——有的词能搜到有的搜不到，排查起来比两侧都错还难，因为你找不到一条稳定的复现路径。

芬兰语和土耳其语的情况更彻底

黏着语的后缀是一层一层挂上去的，还原器要剥好几层。

剥的层数越多，剥掉否定那一层的概率就越高。

土耳其语的否定后缀还会跟着元音和谐变出好几个形态。

这几个形态各自都要被识别，漏一个就会留下一批没归好的词。

结果是同一个概念的正反两族词，归并结果时对时错，不稳定。

土耳其语的规则可以参考Snowball土耳其语词干提取算法说明，这份算法的长度是德语版的两倍多，光是后缀处理就分了很多层，可以直观感受到黏着语的处理复杂度。土耳其语后缀堆叠的整体情况另见土耳其语后缀堆叠如何改变关键词形态。

不稳定比稳定地错更麻烦。稳定地错你至少可以补一条规则修掉，时对时错意味着你没法用一条规则覆盖，只能逐词处理。

黏着语还有一个特有的麻烦：否定后缀不一定是最外层的那一个，它后面还可能挂着格尾和人称结尾。还原器从外往里剥，剥到否定这一层的时候前面已经做了好几个判断，任何一步偏差都会传导下来。

为什么剥掉否定是一个合理的默认

词干还原被发明出来是为了提高召回，不是为了保证精确。

在信息检索的传统场景里，多召回一些不相干的结果代价很低。

用户扫一眼就能跳过，而漏掉相关结果的代价高得多。

所以整个技术路线的默认取向就是宁可多归并，不肯少归并。

这个取向在电商场景里正好相反，多召回一个反义商品是实打实的损失。

换句话说，问题不在算法有缺陷，而在于你把一个为图书馆检索优化的工具放进了一个要求精确匹配的商业场景。工具的默认取向永远来自它诞生时的那个场景，搬到新场景之前得先问一句它当初在优化什么。

把这条想清楚之后，选型的问题就变简单了：召回优先的场景继续用默认配置，精确优先的场景必须显式关掉否定后缀的剥离，或者干脆把这一族词放进保护词表。两种模式共存于同一个站是完全正常的。

剥完之后的召回长什么样

最典型的表现是用户搜无糖，结果页第一屏里混着含糖的商品。

更隐蔽的表现是排序被打乱，相关商品被挤到了第二屏之后。

还有一种是筛选器的数量对不上，标着十二件点进去只有五件相关。

这三种表现在后台的报表里都不会触发任何告警。

因为从系统的角度看，查询有结果、结果有点击、一切正常。

要把这类问题捞出来，只能主动去测。方法是准备一组反义词对，每对都在站内搜索里跑一次，人工看前十条结果里有几条是反面的。二十对词跑完不到半小时，得到的却是一个能直接汇报的数字。

还有一种表现出现在推荐位上。相关商品模块通常按词干相似度取数，于是无糖商品页的下方会挂满含糖商品，这个位置的错配比搜索结果更伤，因为用户没有在主动筛选，他默认这是系统的推荐。

字符串越像，语义越对立，这该怎么排查？

编辑距离在这里是一个反指标

做词表清洗的时候常用编辑距离来找疑似重复项。

距离小的两个词被判成同一个词的不同拼法，然后合并。

否定形态跟它的肯定形态之间，编辑距离恰好非常小。

于是这套清洗逻辑会精准地把最不该合并的一对合并掉。

而且距离越小的越先被合并，也就是错得越彻底的先被处理。

这不是编辑距离用错了地方，是它在这一类词上的信号方向反了。凡是用相似度来推断同义的场合，都要先确认这门语言里有没有靠微小形态差别表达对立语义的机制，有的话相似度就必须降级成一个提示而不是一个判据。

实际操作上最简单的补救是加一条前置规则：合并之前先查这一对词里有没有一个带否定标记，有的话直接跳过不合并。这条规则的实现成本几乎为零，前提是你的词表里已经有了那一列极性标注。

顺便说一句，这条规律不只作用在否定上。任何靠一两个字母表达对立语义的机制都会踩同一个坑，比如某些语言里区分单复数、区分主动被动的那些结尾，它们的字符距离同样极小而语义差别同样明确。

用一张正反对照表把陷阱穷举出来

这类问题的好处是范围有限，一个品类的属性词就那么多。

把品类里所有的属性词列出来，逐个写出它的否定形态。

写不出来的说明这个属性没有否定用法，直接跳过。

能写出来的就成对进表，一对占一行，正反两列。

一个品类通常十到二十对，一门语言半天能列完。

这张表的用处比想象中多：它同时是站内搜索的同义词配置来源、广告分组的依据、筛选器取值的命名规范，还是母语审校的核对清单。一份材料喂四个下游，这是它值得花半天时间的原因。

列表的时候有个小技巧，别只写词典形态，把每一对在真实文本里最常出现的两三种变形也带上。多写这几行不费事，但能省掉后面反复回来补的麻烦。

列表的时候顺手记一个信息很有用：这一对词在你的商品库里各自对应多少个SKU。数量为零的那一边说明你根本不卖，但它仍然要进排除逻辑；两边数量接近的说明这是一个真正的筛选维度，值得单独做落地页。

检验办法是拿反义词对跑一遍还原器

有了对照表，检验就变成一个机械动作。

把每一对词分别喂给你在用的词干还原器，看输出是不是同一个。

输出相同的那些对，就是会在站内搜索里出问题的对。

把这批对单独拎出来，在搜索配置里给它们加硬规则。

整个过程不需要懂那门语言，也不需要母语者参与。

这个办法跟大小写转换那一类问题的自检思路是同一个：不去理解语言，只去观察工具在这门语言上的行为是不是符合预期。你不需要知道芬兰语的后缀体系有多复杂，你只需要知道这两个意思相反的词进去之后出来了同一个结果。

把这个检验做成一个可以重跑的脚本，每次换搜索引擎版本或者换分析器配置的时候跑一遍，能挡掉一整类升级引入的回归问题。

如果你用的是搜索引擎自带的分析器而不是独立的还原库，检验方式要换一下：直接调它的分析接口，把词丢进去看输出的词元序列。多数搜索引擎都提供这个调试入口，返回结果比你自己猜要可靠得多。

站内搜索和筛选器会错到什么程度？

筛选器的取值命名会跟着一起错

筛选器的取值通常直接取自后台的属性字典。

那张字典多半是从英文版翻过来的，一个属性对一个值。

翻译的时候译员会给出这门语言最自然的写法，也就是那个粘合形态。

于是筛选器的取值本身就成了一个不可切分的整体。

再往下游走，这个取值会进URL参数、进面包屑、进结构化数据。

一旦进了URL，改动的代价立刻上一个台阶，因为地址已经被收录、被分享、被外链。所以这件事值得在建站早期就处理掉，晚一年处理成本要高一个量级。

还有一个更早的介入点是属性字典的翻译环节。翻译的时候如果能同时给出一个规范化的取值键，让页面显示文本和内部取值分成两列，后面所有的下游问题都会轻很多，成本只是多一列。

零结果和相反结果，哪个更糟

零结果至少是诚实的，用户知道这里没有他要的东西。

相反结果是不诚实的，用户以为找到了，点进去才发现不对。

从转化的角度看，第二种造成的流失更深，因为它消耗的是信任。

从排查的角度看，第二种也更难被发现，因为它不会出现在零结果报表里。

所以监控只盯零结果率的团队，会系统性地看不见这一类问题。

补一个指标不难：在站内搜索的日志里记录每次查询的前三条结果，定期抽样人工核对相关性。抽样量不需要大，每周三十条就能把明显的错配捞出来，而这三十条的人工成本大约是二十分钟。

这两种情况的处理优先级也不同。零结果可以慢慢补内容，相反结果必须立刻修配置，因为它每天都在消耗一部分本来会转化的流量，而且没有任何自愈的可能。

日志里怎么把这类问题看出来

第一个信号是同一个用户在短时间内反复修改查询词。

他在试各种写法，说明系统没给他想要的东西。

第二个信号是搜索之后立刻返回，没有点击任何一个结果。

第三个信号是点击了但很快回到结果页，也就是不满意的往返。

这三个信号在否定类查询上的出现率，明显高于普通查询。

把查询按有没有否定标记分成两组，分别算这三个指标，两组之间的差距就是这个问题的量化结果。这个数字很好用，因为它把一个技术细节翻译成了一句业务方听得懂的话——这类查询的失败率是普通查询的几倍。

要注意别把这三个信号当成单独的告警指标用，它们在正常查询上也会出现。有意义的是分组对比出来的差值，不是绝对值本身，这一点在给业务方汇报的时候要说清楚，否则很容易被当成搜索质量整体不行。

关键词表该怎么给否定词建结构？

否定要单独占一个维度而不是一行标记

很多团队的做法是在词表里加一个是否否定的布尔列。

这个做法能解决分组问题，但解决不了配对问题。

更好的结构是让每一行都指向它的对立形态。

也就是加一列存放反义词，形成显式的成对关系。

有了这一列，后续所有的下游配置都能自动生成。

这个结构还有一个额外的价值：它让缺口显形。一个属性如果只出现了肯定形态而反义列是空的，要么是这个属性确实没有否定用法，要么是你漏了半边，两种情况都需要人看一眼确认。

这一列还有一个隐性价值是它能被复用到别的语言。属性之间的对立关系是概念层的，跟语言无关，所以第一门语言的对照关系建好之后，做第二门语言只需要填形态那两列，工作量能减掉一半以上。

正反两个形态都要进表

常见的偷懒做法是只收自己商品对应的那一边。

卖无糖产品的只收无糖那一族，含糖那一族不管。

这个做法在英语项目上没什么问题，在这类语言上会漏掉排除逻辑的输入。

因为你要排除的正是另一边，而你手上没有另一边的形态清单。

所以两边都要收，哪怕其中一边你永远不会去投。

另一个理由是竞品分析。你的对手可能同时卖正反两类商品，他的页面结构和词覆盖会告诉你这个市场的实际分布，而你只有两边都收了才看得懂他的表。

还有一个理由是页面规划。看到两边的搜索量分布，你才知道该做一个页面还是两个页面。如果否定那一边的量足够大，它就应该有自己的落地页，而不是挤在一个通用分类页的筛选项里。

词形变体该收到什么程度

屈折语和黏着语的形态数量很大，全收会让表爆掉。

实用的边界是只收在真实查询里出现过的形态。

拿不到查询数据的时候，退一步收最常用的三到五个格。

剩下的靠搜索引擎自己的词形理解能力去覆盖，一般够用。

过度收集变体的代价不是存储，是维护成本和统计噪音。

判断收得够不够有个简单的办法：拿一周的站内搜索日志，看有多少条查询在你的词表里找不到对应行。这个比例低于一成就够用了，高于三成说明变体收得太少。锚文本里的词形处理另见屈折语里的内链锚文本与词形变体。

另一个实用的边界是别把只在正式文书里出现的形态收进来。词表的用途是接搜索，不是做语言学描述，一个形态如果一年到头没人在搜索框里打过，收进来只会稀释统计。

优先级怎么排

第一优先是搜索量高且有明确否定语义的那一批词。

第二优先是虽然搜索量一般，但会造成反向召回的那一批。

第三优先是纯粹为了统计完整性收进来的形态。

前两类要进配置，第三类留在表里做参考就行。

这样分完，真正需要做技术配置的通常只有二三十个词。

把范围收到二三十个之后，这件事就从一个听起来很大的语言工程，变成了一张开发一天能配完的表。大多数看起来无从下手的语言层问题，收敛之后的实际工作量都不大，难的是收敛这一步。

还有一类词要单独拎出来看：那些同时是否定属性又是品类词的词。这类词的搜索意图往往已经是导航型的，用户心里想的就是那个品类，处理方式跟普通属性词不同，应该给它独立页面而不是筛选项。

页面上的否定属性词该怎么写？

标题里的否定词该放哪个位置

否定属性词在标题里最好靠前，因为它是筛选条件不是修饰。

用户扫标题的时候，先确认这个东西符不符合他的排除条件。

放在末尾容易被截断，而截断掉否定词的后果是意思整个反过来。

这一点比一般的关键词前置更要紧，因为代价不对称。

普通关键词被截断只是少一个词，否定词被截断是说反话。

移动端的截断位置比桌面更靠前，所以这条在移动端优先的语言上更关键。德语这类词长的语言尤其要小心，一个复合词本身就可能占掉标题一半的宽度。德语复合词的长度问题另见德语复合词、变音符号与关键词研究。

另外要注意别把否定词写成缩写或者符号。有些团队为了省字符会用一个减号或者斜杠来表达不含，这在这类语言里读起来非常怪，也不会被任何检索机制理解成否定，纯粹是浪费了那几个字符。

属性表里的写法必须全站统一

同一个属性在商品A页面写成一个词，在商品B页面写成一个短语。

这种不一致在人看来无所谓，在机器看来是两个不同的属性值。

后果是筛选器把同一批商品拆成两组，每组的数量都不对。

用户点进任何一组都看不全，而两组都存在会让筛选面板显得很乱。

统一的成本很低，前提是有那张正反对照表当作口径来源。

需要提醒的是统一不等于只留一种写法。页面上的可见文本可以按语境灵活写，必须统一的是属性值那个字段，这两层要分开管，混在一起会让文案变得很僵硬。

统一的执行难点通常不在规则而在存量。上千个商品的属性值已经写了好几种，批量改的时候要小心那些看起来像但其实是别的属性的取值，改之前先导出一份全量清单人工扫一遍，比直接跑替换脚本安全。

别在同一段里把正反形态混着写

为了覆盖两个形态，有人会在一段话里把正反两个词都塞进去。

这个写法在中文里读着别扭，在这些语言里读着更别扭。

因为两个词长得几乎一样，连着出现会让读者以为是笔误。

而且这种写法会给机器一个混乱的信号，两个对立形态高频共现。

正确的做法是一页只主打一个方向，另一个方向放到别的页面。

如果确实需要在同一页说明两者的区别，把它放进对比表格或者问答区，用结构化的版面把对立关系表达出来，而不是靠句子里的并列。版面能表达的关系，不要用堆词去表达。

还有一个变体是在标题里同时塞两个形态，理由同样是想两边都覆盖。这个做法在这类语言上尤其糟糕，因为两个词几乎一样长又几乎一样拼，标题读起来像是排版出错了，点击率会掉得很明显。

结构化数据的属性值怎么填

商品的属性字段应该填规范化的取值，而不是页面上的营销文案。

规范化取值的来源就是那张对照表里的标准形态。

如果这个属性有对应的行业标准或者法规定义，优先跟着标准写。

食品类的营养声称在欧盟有明确的法定条件，写法不能随便发挥。

跟着法定口径写，既避免了合规风险，也顺便统一了全站的用词。

具体的声称条件可以查欧盟营养与健康声称的官方说明，那里规定了什么情况下才能标注无糖或者低糖这类字样。这类法定定义的存在其实帮了做内容的人一个大忙，它把一个原本各说各话的用词问题变成了一个有唯一答案的问题。结构化数据的语言字段另见小语种结构化数据的语言与地区字段怎么填。

如果这个属性没有现成的法定或者行业口径，那就在内部定一个并写进文档，重点是全站唯一而不是绝对正确。属性值最怕的不是选错了一个词，是三个团队各自选了一个词都觉得自己是对的。

一套两天能跑完的否定词审计流程

六步审计流程

第一步，把品类里所有属性词列出来，标出哪些有否定用法。

第二步，给每个有否定用法的属性写出它在目标语言里的两种形态。

第三步，把每一对形态喂给词干还原器，记下输出相同的那些对。

第四步，在站内搜索里逐对试搜，人工核对前十条结果的方向。

第五步，把出问题的对写进搜索配置和广告分组，各自单独处理。

第六步，把这张表并进术语表和审校清单，让它有一个固定的存放位置。

六步里最花时间的是第二步，需要母语同事参与，其余五步都可以自己完成。整体两天能跑完一门语言，而这两天买到的是一整类问题的根治，性价比在语言层的工作里算高的。

如果时间实在紧，最少可以先做第三步和第四步。这两步不需要母语同事参与，一个人半天能跑完，产出是一份出问题的词对清单，已经足够支撑第一轮配置修改。

一张能直接交给开发的规则表

这张表要有五列：肯定形态、否定形态、还原后是否冲突、处理方式、生效位置。

处理方式那一列只有几个固定取值，别写自由文本。

常见的取值是加同义词规则、加硬排除、拆广告组、不处理。

生效位置写清楚是站内搜索、广告后台还是商品属性字段。

有了这两列，开发拿到表就能直接排期，不需要再来问一遍。

另外建议加一列负责人，因为这张表的执行会横跨搜索、广告和内容三个团队，没有明确的归属，表会在中间环节停下来。表本身写得再清楚，也解决不了没人认领的问题。母语侧的验收另见小语种母语审校的验收清单怎么列。

表里还可以加一列预计影响，简单标成高中低就行。这一列不是给开发看的，是给排期的人看的——没有它，这张表在需求池里会一直排在功能需求后面，因为语言层的问题听起来永远不如新功能紧急。

哪些语言必须单独处理，哪些可以套模板？

黏着语和屈折语的差别在哪

黏着语的否定后缀是一个独立的语素，位置固定、形态可预测。

芬兰语、土耳其语、匈牙利语都属于这一类，处理起来有规律可循。

屈折语的情况更杂，否定可能藏在前缀里，也可能改变整个词形。

俄语的否定前缀相对规整，但它跟别的前缀混在一起时不好区分。

所以黏着语可以靠规则批量处理，屈折语更依赖逐词核对。

判断一门语言属于哪一类，不需要查语言学资料，看一遍它的否定形态清单就知道：形态整齐、位置固定的是前者，形态各异、位置飘忽的是后者。匈牙利语的格尾体系另见匈牙利语十八个格与元音和谐的关键词处理。

还有一个粗略但好用的分类办法：看这门语言的否定形态能不能被一条正则大致覆盖。能被一条正则覆盖到八成以上的，按规则处理；覆盖不到一半的，老老实实逐词列表，别在这上面浪费工程时间。

罗曼语系的情况介于两者之间

西班牙语、法语、意大利语的否定多数靠独立的介词短语表达。

这一点让它们接近英语，可以先按英语经验处理。

但它们也有一小批前缀式的否定形态，需要单独收进表里。

这批词的数量不大，通常十几个，人工列一遍就完了。

所以这几门语言的工作量小，但不能完全跳过。

值得注意的是，罗曼语系的形容词还要跟名词做性数一致，同一个否定形容词会有四种写法。这跟否定本身无关，但它会让你的词表行数翻倍。意大利语的性数一致问题另见意大利语形容词性数一致对选词的影响。

法语还有一个特有的坑是它的否定通常由两个成分组成，分别放在动词前后。这个结构在完整句子里没问题，但在关键词和属性值这类短片段里，常常只保留了其中一半，读起来意思就变得含糊。

哪几门语言可以直接套英语经验

印尼语和马来语的否定基本靠独立的词，可以直接套。

越南语同样如此，它的词是按音节分写的，否定成分天然独立。

泰语的否定词也是独立成分，只是整句不分词带来的是另一类问题。

这几门语言可以把预算省下来，投到别的语言层问题上去。

判断标准还是那一句：把无糖这个概念写出来，看它是几个词。

需要提醒的是，可以套英语经验不等于不用检查。省掉的是配置工作，不是验证工作，至少要拿三五对反义词跑一遍站内搜索确认没问题，这一步十分钟就能做完，省掉它有时候会让你错过一个本来能提前发现的意外。东南亚三门语言的差异另见越南泰国印尼在语言层为什么一处都不能共用。

还有一个值得单独提的类型是那些否定用前置独立词但会跟后面的词连写的语言。这一类看起来像英语，实际处理起来更接近德语，判断的时候别只看语法书上怎么说，要看真实文本里是怎么写的。

常见问题解答

只做德语一门语言，这件事值得花两天吗？

看你的品类有没有强否定属性。食品、母婴、家纺、化妆品这几类几乎必然有，因为无糖、无麸质、无甲醛、免烫、防螨这些都是用户主动搜索的筛选条件，而且往往是高转化词。工业品和纯功能类目就弱得多，那些品类的属性词多是数值和规格，很少有否定用法。判断办法很直接：打开你的筛选面板看一眼，如果有一整栏是不含某某，那这两天值得花，否则可以推后。还有一个信号是看你的竞品有没有为否定属性单独做落地页，做了说明这个市场的需求已经被验证过。

直接用搜索引擎自己的语言理解能力，不管这一层行不行？

外部搜索引擎那一侧确实可以少管一些，主流引擎对常见语言的否定理解已经不差，你的页面写清楚它多半能理解。真正必须自己管的是站内搜索、广告后台和筛选器这三处，因为这三处用的是你自己配置的分析器和匹配规则，没有任何外部能力能替你兜底。换句话说，外部引擎的进步能帮你减轻一部分工作，但减轻不了你自己那一半，而自己那一半恰恰离转化更近。所以判断要不要投入，看的是你自己控制的那三处配置，而不是外部引擎的能力边界。

怎么跟不懂这门语言的开发解释这个问题？

别解释语言学，直接给他看两个字符串和一个还原结果。把含糖和无糖两个词并排放着，指出它们前六个字母一样，然后展示词干还原之后输出的是同一个键。整个演示不超过三十秒，开发立刻就懂了，因为这是他熟悉的语言：两个语义相反的输入，产生了同一个键。用这个方式沟通比讲后缀和词干省事得多，也不会让人觉得你在用专业术语压人。这个演示还有一个好处，它把问题从语言问题转成了数据问题，排期的时候更容易被接受。

母语审校能不能发现这类问题？

正文里的用词他们能发现，配置层的问题他们看不见。母语审校拿到的通常是文案稿件，看不到词干还原的输出，也接触不到广告后台的否定关键词列表。所以正确的分工是让审校负责确认那张正反对照表里的形态写得对不对，配置层的验证由你自己拿脚本跑。把审校的工作范围明确限定在语言判断上，他们的效率和准确率都会更高，也不会因为看不懂技术细节而给出模棱两可的意见。换句话说，让审校判断语言，让脚本判断行为，两边各做各最擅长的那部分。

这套办法对AI搜索那一侧还成立吗？

问题的形态变了，但没有消失。生成式系统对否定的处理本来就比对肯定弱，训练语料里的否定表达也更少，而小语种的语料总量又更少，两个因素叠在一起，误读的概率不低。可以做的事是在页面上把否定条件写得更显式，比如单独做一个属性区块或者一段明确的说明，而不是只把否定藏在一个复合词里。结构清晰的表达对任何一种检索方式都是有利的，这一条不因技术路线变化而失效。真正需要重新评估的是那些原本靠精确匹配兜底的环节，它们在生成式检索里没有对应物。

如果站上根本没有站内搜索，还需要做吗？

需要做的部分变少了，但不会归零。没有站内搜索意味着你少了一个出问题的地方，也少了一个最好用的诊断入口。广告那一侧的否定关键词问题照样存在，筛选器和属性字段的命名问题照样存在，关键词表里正反混淆的问题也照样存在。实际上没有站内搜索的站更需要那张正反对照表，因为你失去了从日志里发现问题的能力，只能靠事前把表列清楚。没有日志的站要靠事前列表补上这块缺口，投入反而要更早一点。

这件事和大小写、变音符号那些坑是同一类吗？

处理链路很像，性质不同。大小写和变音符号出问题的时候，结果是匹配不上，表现为召回变少，用户搜不到。否定出问题的时候，结果是匹配到了相反的东西，表现为召回变多但方向错了。前者是漏，后者是错，而错比漏更难被发现，因为漏会体现在零结果率上，错不会体现在任何一个现成的指标上。所以这两类问题虽然排查手法接近，但监控方式必须分开设计。监控指标也要分开设：漏看零结果率，错看结果相关性抽检，两个数字不能合并成一个。

权威参考资料