品牌名在俄语里是西里尔、在日语里是片假名，你那个数提及次数的脚本一个都认不出来

摘要：要知道自己的品牌在AI答案里被提到过多少次，得先有一个能拿来数的字符串。可品牌名到了俄语是西里尔转写、到了日语是片假名、到了芬兰语后面还挂着格尾，你脚本里那个正则一个都匹配不上。这篇讲清跨语言监控为什么第一步就塌、别名表该怎么建、不同语言之间的百分比为什么不能直接比，以及基线归一那一步省不掉。

跨语言数提及，为什么第一步就已经错了？

字符串匹配藏着一个没人说破的前提

先把这套监控的实际做法摊开看。

绝大多数品牌提及监控，底层动作只有一个：在文本里找字符串。

拿品牌名当关键词，扫一遍答案，命中就计一次。

这个动作在单一语言环境里工作得很好，可靠、便宜、可复现。

它能工作，是因为有一个前提在默默成立：品牌名在这批文本里始终是同一串字符。

而这个前提，只在你和你的用户共用一套书写系统、一套语法的时候才成立。

一旦把监控范围扩到十种语言，这个前提就整块塌掉了，而塌掉的过程没有任何报错。脚本照跑，报表照出，数字照样一列一列排得整整齐齐，只是那些数字不再代表你以为的东西。这是工程上最难办的一类故障：不是崩溃，是静默地返回一个格式正确的错值。跟关键词工具返回的那个零是数据缺口不是需求缺口那篇讲的是同一类陷阱，只不过这次错的不是工具，是你自己写的那行正则。

为什么单语环境下没人发现这个前提，因为它从来没有被违反过。一个只做本国市场的团队，看到的所有文本都是同一套书写系统写的，品牌名永远是那一串字符，正则永远命中。前提被满足了十年，它就从假设变成了常识，从常识变成了没人再提起的空气。等到扩语言的那天，没有一份文档记录过这个假设存在，自然也没人想到要检查它。

品牌名在十种语言里不是一个字符串

具体到底会变成什么样，举几个公开可查的例子。

宜家在俄语里通行的写法是西里尔转写，跟拉丁原名一个字母都不重合。

耐克在日语里的常见写法是片假名，同样一个拉丁字母都没有。

这些不是网友的自发音译，而是品牌方自己在当地使用的官方写法。

再往下，同一门语言里往往还并存着拉丁原名和本地转写两套。

用户提问时用哪一套，取决于他的输入法、他的年龄、他是在哪儿第一次见到这个牌子的。

更麻烦的是模型在生成答案时会自己做选择，而它的选择不一定跟你的官方写法一致。用日语提问，答案里出现的可能是片假名，也可能是拉丁原名，还可能两种混着来——前半句用片假名当主语，后半句引用官网标题时又切回拉丁。这三种情况在同一批答案里同时出现是常态，不是异常。品牌名叫什么不由你定、由当地用户的输入法定那篇讲的是搜索框里的情形，到了AI答案这一层，多了一个会自己决定怎么写的生成方。

转写这件事本身是有规则的，不是随口音译。Unicode地区数据规范里的音译章节定义了成套的跨书写系统转换规则，能把拉丁字母按发音映射到西里尔、希腊、天城文等多套系统。拿它批量生成候选形态，再让母语者删掉不通行的那几个，比从零开始想快得多，也不会漏掉冷门但合法的写法。

零提及和零匹配在报表里长得一模一样

这是整篇文章的第一个核心结论。

报表里某门语言那一格是零。

它可能意味着这门语言的答案里确实一次都没提到你。

也可能意味着提到了很多次，只是你的正则认不出那些形态。

两种情况在数字上完全一致，在业务含义上南辕北辙。

前者要你去做内容，后者要你去修脚本，一个是几个月的投入，一个是一个下午的活儿。

而在实际工作里，团队看到零的第一反应几乎永远是前者，因为那个解释更符合直觉，也更符合大家对小语种市场的既有印象。于是预算批下去，内容做起来，三个月后数字还是零，才有人回头去看脚本。这个坑跟排名靠后和根本不在场在后台是同一个零那篇讲的结构一样，但位置不同：那一篇的零来自候选池，这一篇的零来自你自己的测量装置。

工程上有一个很省事的改法：给每次抓取多记一个标志位，表示这批答案里有没有出现任何一个已知的品类词。品类词都没出现，说明这批答案压根不在讨论你的行业，零是合理的；品类词出现了很多次而品牌一次没出现，那才是需要警觉的零。一个布尔值，就把两种零分开了大半。

这跟内容侧的不在候选池不是同一层

把两层分清楚很重要，否则会归错因。

内容侧的零，是你的页面根本没进检索器的候选集合。

测量侧的零，是页面进去了、答案里也提到了，只是你没数出来。

两者可以同时存在，而且经常同时存在。

排查顺序应该是先测量侧再内容侧，因为测量侧便宜得多。

修一遍正则和别名表，成本大概是半天；补一门语言的内容，成本是一个季度起。

判断该先查哪一层有个很快的办法：随手挑五条那门语言的答案，人眼读一遍，看看里面到底有没有你的品牌。人眼不做字符串匹配，它做的是语义识别，一眼就能看出片假名那一串是不是你。五条读完，你就知道零是真零还是假零。这个检查的成本是十分钟，可它极少被执行，因为一旦有了自动化报表，人就不再愿意用眼睛看原始数据了。

品牌名到底会以多少种形态出现？

转写：西里尔、片假名与其他书写系统

先说跨书写系统这一类，它最显眼也最容易补。

俄语、乌克兰语、保加利亚语、塞尔维亚语会把品牌名写成西里尔。

日语用片假名，韩语用谚文，希腊语用希腊字母。

阿拉伯语和希伯来语的转写还要处理元音省略，同一个名字能写出好几种。

这些形态之间不存在字符级的对应关系，靠正则的模糊匹配抓不到。

唯一可靠的办法是把它们逐个列进别名表，当作独立的目标字符串。

塞尔维亚语这类同时使用两套字母的语言更极端，同一门语言里就有两个合法写法，取决于内容发在哪个平台上。保加利亚语和塞尔维亚语用哪套字母写商品名比写了什么更决定谁能搜到那篇讨论的是收录侧，到了监控这一层，它变成了一个更朴素的问题：你的别名表里这门语言要占两行还是一行。答案是两行，而且这两行的计数要能合并也能拆开看。

各语言到底通行哪种转写，公开数据里能查到一部分。Unicode CLDR项目维护的各地区数据里包含了大量外来名称的本地写法惯例，虽然它不会收录你的品牌，但它能告诉你这门语言处理外来专名的一般倾向：是倾向转写还是倾向保留原文，这个倾向决定了你的别名表里哪一行该排在前面。

屈折：格尾、所有格与后置冠词

这一类比转写更隐蔽，因为它长得跟原名很像。

芬兰语会把品牌名当普通名词变格，后面直接挂上格尾。

土耳其语用撇号把后缀跟专有名词隔开，撇号后面那串会变。

俄语的品牌名如果被当成可变格词处理，六个格全都有不同的形态。

罗马尼亚语和保加利亚语的定冠词是后置的，直接粘在词尾。

这些形态里前半截还是你的品牌名，后半截多了几个字母，精确匹配全部失败。

处理办法是把匹配从等于改成以某个词干开头，但这一改又会引入新的问题：品牌名短的时候会误伤大量普通词。三个字母的品牌名在芬兰语里做前缀匹配，能匹配出一堆完全不相干的东西。屈折语站的锚文本报告里精确匹配那一栏的数字是假的那篇给过同一个两难，当时的解法是把精确匹配的需求整体挪到别的位置去；在监控这里挪不了，只能靠人工审一遍前缀匹配的结果，把误伤的踢掉。

要判断某门语言会把专有名词变到什么程度，翻一遍公开树库最直接。Universal Dependencies的芬兰语数据集里专有名词同样带完整的格标注，你能直接看到一个外来名字在真实语料里出现过多少种形态。列出现频次最高的那五六个，别名表就够用了，剩下的长尾形态出现概率低到不值得维护。

正字法：变音符号、连字符与大小写

第三类是同一套字母内部的小差别。

带变音符号的品牌名，用户经常打成不带符号的版本。

德语的元音变音有一套标准的退化写法，两种都合法。

连字符有没有、空格断在哪儿，各语言的排版习惯不同。

大小写在西里尔和拉丁之间也不完全对应，全大写的品牌名尤其容易出岔子。

这类差别的数量不多，但它们出现的频率非常高，漏掉的话计数会少一大截。

技术上有个现成的兜底手段：先做Unicode归一化，再做大小写折叠，然后再匹配。带重音的字母在编码上有组合与预组合两种形态，肉眼一模一样而字节不同，不归一化就会漏。String.prototype.normalize这个标准方法是最省事的入口，把所有待比对的文本先过一遍，能把这一整类问题消掉八成。剩下两成是排版习惯，只能靠列表穷举。

大小写折叠这一步在跨书写系统时格外容易出错，因为不同系统的大小写映射规则并不一致，个别字母在折叠之后会跟另一个字母重合。UAX #29文本分段规范定义的词边界规则可以配合着用，先按标准切出词，再逐词折叠比对，比在整段文本上做正则安全得多。

误拼与本地化改名

最后一类是最容易被漏掉的。

用户会打错，而且打错的方式在每门语言里是有规律的。

规律来自键盘布局和母语的拼写直觉，不是随机的。

把常见错拼收进别名表，通常能多捞回百分之几的提及。

另一种情况是品牌在某个市场用了完全不同的名字。

这类改名往往是历史原因造成的，公司内部知道的人还不多。

还有一种更隐蔽的形态：模型在生成答案时把品牌名意译了。如果你的品牌名本身是一个有含义的普通词，模型在某些语言里会把它翻译过去而不是转写，于是答案里出现的是那个词的本地对应词。这种情况下用户其实看到了你，可你的监控完全不知道。要发现它，只能靠人工读原始答案，或者反过来搜一遍你的品类词看看有没有眼熟的表述。

主键该怎么建，别名表长什么样？

每条记录必须带上匹配到的那个形态

这是本文最实用的一条工程建议。

监控记录里通常只存三样：语言、有没有提及、来源链接。

建议再加一列，存实际匹配到的那个字符串。

这一列存在，你才能回答零到底是哪种零。

这一列存在，你才能发现某门语言里有一种形态从来没被匹配到过。

这一列存在，别名表的维护就从猜变成了看数据。

加这一列的成本几乎为零，收益却是把一个不可观测的问题变成了可观测的。更妙的是它会自己长出新知识：跑三个月之后，把这一列做个频次统计，你会得到一张真实的形态分布表，告诉你在哪门语言里哪种写法最主流。这张表比任何一份品牌规范文档都更接近现实，因为它记录的是用户和模型实际在用的写法，不是公司希望大家用的写法。

这一列还有第二个用途，是发现别名表里的死行。跑满一个季度之后，如果某个形态一次都没被匹配到，说明它要么写错了，要么在真实语料里根本不出现。前者是bug，后者说明你的别名表在往里加没用的行。定期清掉死行，表的可维护性才不会随时间下降，否则三年之后没人敢动那张表。

别名表的三列结构

别名表本身不复杂，三列就够。

第一列是语言标签，写到地区一级。

第二列是这门语言下的一个形态，一行一个。

第三列是这个形态的类别：官方、转写、屈折、误拼、意译。

类别这一列看着多余，实际非常有用。

它让你能分开统计官方写法的提及率和非官方写法的提及率，两者的差值本身就是一个信号。

如果非官方写法的占比长期偏高，说明你在这个市场的品牌规范没有落地，本地媒体和用户各写各的。这不是监控的副产品，这是品牌部门真正想要而一直拿不到的数据。品牌名能规定一种写法、作者的名字规定不了那篇讲过命名权归谁决定了你能收敛还是只能汇总，别名表的类别列相当于给这个判断配了一个持续更新的度量。

第一列的写法要有纪律，别在同一张表里混用两种粒度。RFC 5646语言标签规范定义了语言、脚本、地区三段的组合方式，塞尔维亚语这类双字母系统的语言必须把脚本段写出来才能区分两套写法。定好粒度之后写进文档，后面加语言时照着填，不会出现一行写语种一行写地区的混乱。

归一化到底放在链路的哪一步

顺序错了会白做很多功。

正确的顺序是：抓取原文、原样存档、归一化后匹配、记录原始形态。

关键在于归一化只用于匹配，不覆盖存档。

很多实现直接把归一化后的文本存下来，原文就丢了。

丢了原文，前面说的那一列形态统计就无从谈起。

存储成本在这个量级上完全可以忽略，别为了省几兆字节把信息丢掉。

归一化的具体形式也要选对，兼容分解那一档会把一些视觉上不同的字符也合并掉，用在品牌名匹配上可能过头。标准里定义了好几档强度，各有各的适用场景，选之前值得花十分钟读一遍规范里的对照表。选完把这个选择写进文档，因为半年后换了人接手，没人知道当初为什么选的这一档，改一下整批历史数据就不可比了。

为什么不同语言之间的百分比不能直接比？

答案长度的基线本来就不同

这是第二个核心结论的第一块砖。

同一个问题用不同语言问，答案的平均长度差别很大。

有的语言下模型倾向于给三段话，有的语言下只给一段。

答案越长，能塞进去的品牌名越多，提及率自然越高。

这个差别跟你的品牌一点关系都没有，纯粹是语言层的属性。

可它会直接进到你的报表里，被读成品牌在这个市场表现更好。

验证这一点很容易：把每门语言的答案平均字数统计一遍，跟提及率画在同一张图上，多数情况下两条线的形状高度相似。相似到什么程度，就说明你的提及率里有多少成分是长度效应。见过最夸张的一次是两条线几乎重合，也就是说那份报表从头到尾在衡量的其实是模型在各语言下的话痨程度。这种时候讨论哪个市场该加预算，讨论的是一个跟预算无关的量。

统计答案长度这件事几乎零成本，抓取的时候顺手记一列字数就行。真正需要注意的是别用字符数直接跨语言比——同样一句话，中文的字符数和德语的字符数差得很远。要比就比信息单元数，粗糙一点的做法是数句子个数，虽然不精确，但至少不会因为语言的书写密度差异得出荒谬的结论。

每条答案挂几个来源，各语言也不一样

第二块砖跟引用直接相关。

答案底下的来源条数在不同语言下有系统性差异。

高资源语言的答案往往挂五六条来源，低资源语言常常只挂两三条。

坑位少，你被挂上去的概率天然就低。

这同样是语言层的属性，跟你做得好不好无关。

不做归一，你会把坑位少误读成竞争激烈或者内容不行。

而这两个误读会导出完全相反的动作：以为竞争激烈就加大投入，以为内容不行就换团队，而正确的动作可能是什么都不用改。回答语言和来源语言是两个独立字段那篇拆出的是来源的语言构成，这里要拆的是来源的条数基线，两者是同一批原始数据的不同切面。建议在同一次抓取里把两项都记下来，成本只多一列。

为什么高低资源语言的来源条数会有系统性差异，根子在候选池的绝对规模上。Common Crawl按语言统计的文档分布里头部与尾部相差好几个数量级，池子小的时候检索器凑不满预期条数，只能少挂几条。这不是策略选择，是可用素材不够，所以它不会因为你做了什么而改变。

低资源语言里模型更爱给泛泛回答

第三块砖来自模型行为本身。

本地来源稀薄的时候，模型给出的回答会更笼统。

笼统的回答里不太会点名具体商家。

它更可能说一句可以考虑几个主流品牌然后就此打住。

这种回答不算错，但它对所有品牌一视同仁地不提及。

于是那门语言的整体提及率被压得很低，所有玩家都一样低。

这条跟小语种AI稿里读着最顺的那一段恰恰是模型编出来的那篇是一枚硬币的两面：来源不足时，模型要么泛泛而谈，要么开始填补细节。前者对品牌是无差别的低曝光，后者是有风险的错误信息，两种都出现在同一批低资源语言里，取决于问题的具体形态。判断你落在哪一侧，看答案里有没有出现具体的数字、期限、型号——有就是在填补，没有就是在泛泛而谈。

判断一批答案是泛泛而谈还是在填补细节，有个两分钟能做完的检查：扫一遍答案里有没有具体的数字、期限、型号、认证编号。这类具体信息只可能来自某个来源，模型不太会凭空生成一个格式完整的编号却完全不挂来源。有具体信息又没有对应来源的，基本可以判定为填补，那一条要单独挑出来核。

你比出来的到底是语言还是品牌

把三块砖叠起来，结论就成立了。

德语一成二、印尼语零点四成，这个差值里有品牌的成分，也有语言的成分。

不做分离，你没法说出品牌那部分占多少。

而所有的资源分配决策，需要的恰恰是品牌那部分。

语言那部分你改不了，它对所有竞争对手一样。

把不可改的部分算进考核，等于给团队发了一张自己解不开的题。

这正是官方公布的是国家数、你要的是语言数那篇讲的那条原则的又一次应用：口径不一致时必须先换算，而不是把两个量纲直接相减。只是这一次两个量纲藏得更深，它们不在两个字段里，它们混在同一个百分比里。要把它们拆开，需要引入一个外部参照物，而这个参照物就是下一节要说的对照组。

语言层属性正在快速变化这一点也要考虑进去。斯坦福人工智能指数年度报告逐年记录的语言覆盖与能力数据显示，语种之间的差距在收窄，但收窄的速度各不相同。这意味着你今年测出来的基线，明年不一定还成立，所以基线必须定期重算，不能一次算完当常数用三年。

对照组该怎么选，基线怎么算？

拿本地头部三家当对照

方法说穿了很朴素。

每门语言里挑三个本地市场的头部同行。

用同一批问题、同一套流程，把它们的提及率也测一遍。

三家的平均值就是这门语言在这个品类下的基线。

你的数字除以这个基线，得到一个归一化后的相对分。

相对分才是可以跨语言横向比较的量。

挑对照组有两条纪律：必须是本地公司，必须跟你在同一个价格带。挑成跨国巨头，基线会被抬到没有参考价值；挑成小作坊，基线又太低。本地且同价格带这两条，保证了对照组面对的语言环境跟你完全一致，差别只剩经营本身。这跟做工具类内容时找外部真值当对照的思路是一样的：自己算出来的数字没有意义，除非旁边有一个已知的参照物。

归一化分数具体怎么算

算法要简单到能在表格里手算。

先算你的原始提及率，再算三家对照的平均提及率。

两者相除，得到一个以一为中心的比值。

大于一说明你在这门语言里跑赢了本地平均。

小于一说明跑输了，而且跑输的幅度可以跨语言比较。

别去做更复杂的加权和标准化，复杂度上去之后没人再信这个数字。

如果非要加一项，加对照组的离散度：三家之间差距很大的时候，平均值本身就不可靠。离散度大通常意味着这个品类在这门语言下还没有形成稳定格局，谁被提到有很大偶然性，这时候相对分的波动区间要放宽。把离散度写在报表的旁边，读表的人才知道该把这个数字看得多重，否则一个一点二和一个零点八会被当成同样确定的结论。

小样本情形要特殊处理。如果某门语言下你和三家对照的原始提及次数都是个位数，比值这个形式就不稳定，分母稍微动一下比值就翻倍。这时候建议退回绝对次数，只报你和对照各自被提到几次，不做除法。数字丑一点没关系，比一个看着精确实则随机的比值强。

对照组选错会发生什么

讲一个反面情形。

有团队图省事，十门语言用了同一组对照——三家全球品牌。

结果每门语言的基线都很高，自己的相对分一律很低。

报表看起来很一致，结论是全线落后。

实际情况是在几个小市场里他们已经是本地第一梯队。

用全球基线去量本地表现，等于拿姚明的身高给全班同学打分。

更常见的一种错法是对照组选了三家，可这三家在某门语言里根本不经营，于是那门语言的基线接近零，你的相对分被除成一个天文数字。这类异常值往往不会被当成错误，反而会被当成亮点写进汇报，因为它符合大家希望看到的结果。防这个的办法是给相对分设一个上限，超过上限的直接标记为待核，逼人回去看原始数据。

把提示词翻译过去，问的还是同一个问题吗？

机翻提示词会带来意图漂移

这一节讲的是变量干不干净的问题。

跨语言测量的标准做法是用同一个问题问十种语言。

可这个同一个问题是怎么来的，通常是机翻。

机翻之后，问句的意图会发生细微但真实的漂移。

有的语言里译文变得更正式，有的变得更口语。

语体一变，检索到的文档类型跟着变，提及率也跟着变。

已有研究发现提示词的语体和礼貌程度会影响模型输出的质量，而这种影响在不同语言之间还不一致。Should We Respect LLMs这项跨语言的提示礼貌度研究测的就是这件事，结论是同一档礼貌程度在英语、中文、日语上的效果并不相同。这意味着你把一条中性的中文提示词翻成敬语发达的语言时，如果译文自动升了一档语体，你测到的差异里就掺进了语体效应。

用模型来判断译文等不等价这条路也不完全可靠。How Reliable is Multilingual LLM-as-a-Judge这项研究发现模型担任评判者时在不同语言上的判断并不一致，也就是说你拿模型去校验跨语言的提示词等价性，校验器本身就带着语言偏差。结论是这一步的最终裁判还得是人，模型只能用来做初筛。

锚定实体：品类词加使用场景

解决办法不是不翻译，是给翻译加约束。

约束的核心是锚定住两个东西：品类词和使用场景。

品类词必须用当地实际通行的说法，不能用字典对应词。

使用场景必须一字不差地对应，不能因为当地习惯不同就换一个。

其余部分可以译得自然，这两项必须锁死。

锁住这两项，语言就成了唯一变量，别的都被固定住了。

为什么必须是这两项，因为它们直接决定检索器召回哪一批文档，而其余成分主要影响答案的措辞。换句话说，锁住检索侧的输入，放开生成侧的输入。这个取舍跟前一篇讲西语变体时那条只替换标记词的纪律是同一条原理的两个应用：变量要落在链路上你真正想测的那一环，不能让它扩散到整句话。

本地化重写的四条硬约束

把约束写成可执行的清单。

第一条，品类词由本地母语者提供，不由译者决定。

第二条，问句的疑问类型不变，是什么就不能译成怎么样。

第三条，不加也不减任何限定成分，包括时间、地点、价格区间。

第四条，语体统一到中性，所有语言都不用敬语也不用俚语。

四条都写进流程文档，让每次重跑都能复现。

第四条最容易破功，因为母语者的本能就是把句子改得更自然，而更自然往往意味着更符合当地的语体习惯。处理办法是提前告诉他们这批句子不是给用户看的，是测试用的，生硬一点没关系。这个说明不给的话，你会收到一批读起来很棒但彼此不可比的问句，而且返工时对方会觉得莫名其妙。母语者审校的验收判据那篇给的那套标准在这里要反着用：这一次读着自然反而是问题。

有人会问要不要加第五条，规定所有语言的问句长度一致。不建议加，因为各语言表达同一个意思所需的长度天然不同，硬凑长度反而会逼着译者加废话或者删信息。长度这一项该做的是记录而不是控制，把它当成一个协变量存下来，分析时如果发现长度跟结果强相关，再回头处理。

怎么验证十条问题真的等价

最后加一道验证。

把十种语言的问句都回译成同一门语言。

回译结果放在一起对照，看看有没有明显的意思差别。

有差别的挑出来重写，直到回译结果高度一致。

这一步不完美，但能抓住大部分明显的漂移。

做一次大约两小时，比事后发现数据不可比便宜太多。

回译对照还有一个副产品：它能暴露出哪些概念在某门语言里根本没有对应的常用说法。回译回来发现某一条变成了一句绕口的解释，说明当地人不这么表述这件事，那条问题本身就不该出现在测试集里。这跟两个市场的关键词表可以一字不差、落地页却得拆成两种那篇的观察相互印证：概念的可表达性，本身就是市场差异的一部分。

提及和引用是两个字段，报表里能合并吗？

被说到名字与被挂上链接

先把定义分清楚。

提及是答案正文里出现了你的品牌名。

引用是答案底下的来源清单里出现了你的域名。

两者可以同时发生，也可以只发生一个。

只被提及不被引用，说明模型知道你但没拿你的页面当依据。

只被引用不被提及，说明你的页面被读了但品牌没被说出口。

两种情况需要的动作完全不同：前者要补的是内容的可引用性，后者要补的是页面上品牌信号的显著度。把两者合成一个数字，得到的是一个既不指向内容也不指向品牌的中间值，任何人拿到它都不知道下一步该干什么。GEO三层可见性指标那一篇把这类指标拆层的思路，在跨语言场景下要再多拆一次，因为语言这一维会让两者的差距变得更大。

官方口径的措辞也值得留意。两百多个国家、四十多门语言那份扩容公告讲的全是回答语言的覆盖，通篇没有承诺来源的构成，更没有承诺答案里会不会点名商家。把公告里的覆盖读成自己会被提及，是很多团队排期时的第一个乐观假设，而这个假设从来没有被官方做出过。

跨语言时两者的差距会被放大

为什么在跨语言时更要分开看。

本地来源少的语言里，模型更依赖它的参数知识来提品牌。

参数知识里的品牌认知来自训练数据，大品牌天然占优。

而引用取决于当下检索到了什么页面，小玩家有机会挤进去。

于是在低资源语言里，提及率被大品牌占满，引用率反而更开放。

这两条线在同一门语言里可能一条向下一条向上。

对中小站来说这是个好消息：引用这一侧的门槛比提及那一侧低得多，而引用带来的点击是实打实的。把有限的力气压在引用上，比试图挤进模型的品牌认知里现实得多——后者需要的是多年的品牌建设，前者需要的只是一篇写得比同行更完整的本地语言内容。小语种问答长尾那篇算的就是这笔账。

只报一个数字会引出什么决策

讲清楚汇报的后果。

报一个可见度总分，老板会问怎么把它提上去。

这个问题没法回答，因为总分不对应任何具体动作。

报提及率和引用率两个数，问题会自动变成两个更具体的问题。

再加上按语言拆开，问题会变成十个市场各自的问题。

指标的粒度决定了讨论的粒度，这条规律在任何组织里都成立。

但粒度也不能无限细，超过一屏的报表没人看，最后大家还是只盯那个总分。实践下来比较稳的形态是：首页一张十行的表，行是语言，列是提及率、引用率、归一化相对分三项，后面挂明细。三列刚好能在一眼里看完，又足以区分出三类不同的问题。AI引用率监控闭环那篇给的四步流程可以直接套在这张表的后面，只是每一步都要按语言分开跑。

一次测多少条、多久测一次才不算噪声？

单次结果的抖动来自哪里

先搞清楚噪声的来源。

同一个问题连问三次，答案不会完全一样。

来源清单的变动比正文措辞的变动更大。

抖动来自采样、来自检索的近似算法、来自缓存状态。

这些都不是你能控制的，只能靠重复测量把它平均掉。

单次结果基本没有解释价值，把它写进周报是在制造噪声。

更麻烦的是抖动幅度本身在各语言之间不一样，候选文档越少的语言，抖动越大。因为候选池小的时候，排序上的微小扰动就能换掉整份来源清单；池子大的时候，头部几条相对稳定。这意味着你不能给所有语言设同一个显著性门槛，小语种那一侧的门槛必须放宽，否则你会不停地追逐一堆假信号。

区分抖动和真实变化，最省事的办法是留一组不动的对照问题。挑五条内容完全不涉及你也不涉及对照组的通用问题，跟主测试集一起跑。这五条的结果如果也在同步波动，说明那一轮整体环境有变；如果它们很稳而你的数在动，那就是真实变化。五条问题的成本可以忽略，价值却是给整套测量装了个基准表。

样本量与复测频率的账

给一组可以直接抄的数字。

每门语言三十条问题，每条跑三轮，是一个比较稳的起点。

十门语言就是九百次问答，自动化之后一天能跑完。

频率按月，季度做一次含对照组的完整测量。

月度测量只看自己的数，季度测量才重算基线。

基线不用每月重算，因为语言层的属性变得很慢。

这套配比的思路跟排名追踪的抽样设计那篇是一脉相承的：把预算花在样本的覆盖面上，而不是花在测量的频率上。频率翻倍带来的信息增量很小，覆盖面翻倍带来的增量很大，因为后者才能让你发现之前完全没看到的市场。跨语言场景下这个结论更成立，因为语言是一个天然的分层变量，每多一层都是全新的信息。

跨语言时噪声本身也不同

再补一条容易被忽略的。

比较两门语言的变化时，要比的是各自的相对变化。

德语涨了两个点和印尼语涨了两个点，含义完全不同。

前者可能在噪声范围内，后者可能是一次真实的跃迁。

判断标准是各自的历史波动区间，不是绝对数值。

所以历史数据要存够长，至少半年才能画出可信的波动带。

头三个月的数据基本只能用来建立基线，不要拿它做任何决策，这一点最好在项目启动时就跟老板说清楚。否则第一个月的报表一出来，就会有人根据某个孤立的数字提出行动方案，而那个数字什么都不代表。把观察期写进项目计划，是这类监控项目里最省事的一次预期管理。

还有一种跨语言特有的假信号：某门语言的答案形态整体改版。比如原本给列表式回答的语言突然改成段落式，列表里点名商家的概率远高于段落，于是提及率整体掉一截。这类变化跟内容无关，跟品牌无关，只跟那门语言下的答案模板有关。发现它的办法是每次抽查时顺手记一下答案的结构形态，改版会立刻显形。

这套监控该由谁来跑，成本压得下来吗？

三种实现路径的成本对比

先看有哪些选择。

第一种是买现成的监控工具，配置好语言和关键词。

第二种是自建脚本，调接口批量提问再解析结果。

第三种是人工，母语同事定期手动跑一批问题。

三种各有各的适用场景，不是越自动越好。

关键在于前两种都依赖那个字符串匹配，而问题恰恰出在那里。

现成工具的最大问题是别名表通常不开放给你改，或者只能加简单的同义词，加不了带类别的结构化别名。那份二十款监控工具的评测里的选型维度，在跨语言场景下要额外加一条：能不能自定义品牌名的匹配规则。这一条不满足，工具在小语种上给出的数字就不能用，无论它别的功能多强。

本地母语者在链路里的位置

人工那一环放在哪儿最值。

不是放在跑问题上，那件事机器做得更好。

是放在两个位置：建别名表，和抽查匹配结果。

建表是一次性的，每门语言一两个小时。

抽查是周期性的，每月每门语言二十条，半小时。

这两件事机器做不了，因为它们需要的是语言直觉不是规则。

把母语者放在这两个位置上，一个人每月投入的时间大约是半天，就能覆盖五到六门语言的质量兜底。而如果把他放去人工跑问题，同样的半天只够跑一门语言的一次测量，产出还不如脚本。资源放错位置在多语言项目里非常普遍，根源是大家默认母语者的价值在于产出内容，其实在监控链路里，他们最大的价值是当校验器。

抽查怎么抽也有讲究。别随机抽，要按形态分层抽：官方写法抽五条，转写抽五条，屈折形态抽五条，未匹配到任何形态的答案再抽五条。最后那一组最有价值，因为它专门用来发现别名表里缺了什么。纯随机抽的话，你抽到的绝大多数是已经匹配成功的样本，看一百条也发现不了新形态。

每月能压到多少工时

把账算完整。

初次搭建，含别名表和流程文档，大约两周人力。

之后每月的固定投入是脚本跑批加一次抽查，两到三天。

季度多一次完整测量含对照组，再加两天。

换算下来一年大约三十个工作日。

覆盖十门语言的话，平均每门语言一年三天。

这个成本能不能通过，取决于你怎么描述它的产出：说成一份报表，很难通过；说成十个市场的存在感体检，通过率高很多。后一种描述不是话术，它更准确——这套东西真正的产出不是数字，是一次次发现某个市场其实完全没被覆盖。GEO团队的四层落地框架那篇把监测放在了最后一层，跨语言场景下建议把它前移，因为它会直接改变前面几层的排期。

哪些数字最好别放进汇报

三个会误导决策的指标

逐个说清楚。

第一个是未做基线归一的跨语言提及率对比。

它会把语言层的属性读成市场表现，导出错误的预算分配。

第二个是提及与引用合并出来的可见度总分。

它不对应任何具体动作，只会引出一句把它提上去。

第三个是单月的变化率，尤其是小语种那几列。

第三个最危险，因为它天然是最刺激的那一列：小语种的基数小，百分比变化动辄三位数。报表上一列鲜红的增幅，实际可能是从两次提及变成了五次。防这个的办法很简单，把绝对数字和百分比并排放，只要绝对数字小于某个阈值就不显示百分比。这个改动五分钟能做完，能拦下一整年的错误解读。

还有第四个值得警惕的：跨语言的排名。把十门语言按提及率从高到低排成一张榜，会天然引出一个谁第一谁最后的叙事，而这个叙事里排在最后的那门语言，很可能只是因为它的答案短、来源少。榜单这种形态自带优劣暗示，用在本来就不可比的量上，误导性比单纯的数字更强。

换成什么口径更合适

给出替代方案。

用归一化相对分代替原始提及率。

用提及率和引用率两列代替合并总分。

用滚动三个月的移动值代替单月值。

再加一列样本量，让读表的人自己判断可信度。

四项改完，报表的行数没变，误读的空间小了一大截。

最后加一条：在报表的第一行写清楚这些数字不能回答什么。比如它不能回答某门语言的用户是不是真的更认可你，也不能回答提及涨了会不会带来订单。把边界写在最显眼的位置，比藏在附录里有用得多，因为读表的人往往只看第一屏。这一条是从排名监测为什么总对不上那篇里学来的老经验，换个场景照样成立。

常见问题解答

已经在用现成的监控工具，还需要自己建别名表吗？

需要，除非工具允许你自定义每门语言的匹配形态。多数工具的关键词配置只支持简单的同义词列表，无法表达带类别的结构化别名，也不会把实际匹配到的形态回传给你。没有这两样，工具给出的小语种数字就无法验证真伪。折中做法是继续用工具跑主流语言，小语种那几门单独用脚本跑一遍做交叉核对，差距大到一定程度就说明工具那一侧漏了。

品牌名只有三四个字母，前缀匹配误伤太多怎么办？

短品牌名不要用前缀匹配，改用词边界加人工审核。具体做法是先用较宽的规则捞出候选，再让人过一遍，把误伤的踢掉，同时把真实形态收进别名表。跑两三个月之后别名表基本收敛，人工量会降到很低。另一个补充办法是给匹配加上下文条件，比如附近出现品类词才计数，能拦掉大部分无关命中，代价是会漏掉少量只提品牌不提品类的情形。

对照组的三家同行，怎么保证选得客观？

用当地公开可查的口径来选，不要凭印象。可以看当地电商平台的品类销量榜、当地比价站的收录情况、当地行业媒体的年度盘点，三个来源交叉出现的公司基本就是本地头部。避免让本地销售同事凭感觉推荐，他们的名单往往偏向于自己接触最多的那几家。选完之后把选择依据记录下来，明年重选时才有可比性。

能不能只测一门通用语言，别的市场按比例推算？

不能，因为语言之间的关系不是比例关系。同一个品牌在两门语言里的表现可以完全脱钩，尤其当其中一门语言的本地来源池几乎是空的时候。推算的前提是变量之间存在稳定的相关性，而跨语言这一层恰恰不满足这个前提。真要省成本，正确的做法是减少每门语言的问题条数，而不是减少语言的门数——覆盖面比精度更重要。

模型换代之后历史数据还能用吗？

趋势能用，绝对值不能直接接续。底层模型换一次，答案长度、来源条数、品牌提及习惯都可能整体平移，这时候你看到的跳变跟自己的内容毫无关系。处理办法是在时间轴上打一个标记，标记前后各自算基线，跨标记比较时只比相对分不比绝对值。所以对照组的价值在这里第二次体现出来：它跟你一起经历了模型换代，相对分因此仍然可比。

有必要每门语言都做吗，先做三门行不行？

完全可以，而且推荐这样开头。选三门的时候建议拉开差距：一门高资源的大语种、一门书写系统不同的、一门屈折变化明显的。这三门能把前面讲的三类形态问题都覆盖到，别名表的结构和流程会在这一轮里定型。之后再扩语言时，加的只是数据不是设计，成本会低很多。反过来先做三门相似的语言，扩到第四门时经常要推倒重来。

这套东西的产出，怎么跟销售或者订单挂钩？

不建议直接挂钩，中间隔的环节太多。更现实的用法是把它当作前置的覆盖度检查：某个市场长期零提及零引用，那里就不该被写进下一年的增长目标，或者写进去之前先补一轮内容。把它定位成排期依据而不是绩效指标，既避免了归因扯皮，也避免了指标本身被优化。真正需要跟订单挂钩的，是从AI答案里点进来之后那一段的转化数据，那是另一套埋点的事。

权威参考资料