希腊语的问号跟分号长得一模一样，切段落的程序照着分号切了下去

摘要：希腊语的问号跟英文分号是两个不同的字符，可它们长得一模一样，归一化还会把前者折成后者。于是希腊语的问句在断句程序眼里从来不是问句。泰语句末根本没有标点，德语的句点同时兼着缩写和序数两份差事，亚美尼亚语的问号压根不在句末。检索的最小单位早就从页面降到了句子，而这一步在小语种上没人查过。本文给出十行代码就能跑完的自检办法。

抓答案那一步，为什么先要知道一句话到哪儿结束？

从一个希腊语箱包站的常见问题区说起

那是一家做希腊市场的箱包站，主推旅行箱和登机箱。

常见问题区写得很扎实，二十多组问答，结构化数据也标齐了。

英文站上这一块表现很好，经常被摘去当直接答案。

希腊语站的同一块内容，从上线起就一次都没有被摘过。

页面收录正常，结构化数据校验也全绿。

问题最后出在一个符号上：希腊语的问号看起来就是一个英文分号，而站点的问答抽取逻辑靠句末标点判断哪一句是问题。整整二十多个问题，在程序眼里全都是一句没说完的话。这件事排查了三个星期，因为屏幕上那个符号跟分号一模一样，没有人想到去核码位。

希腊人自己当然读得毫无障碍，只有机器读不出来。

这件事真正让人后怕的地方在于，排查的三个星期里团队几乎把能想到的都试了一遍：重写答案、调整标记结构、检查抓取权限、换了两版结构化数据。每一步都合理，每一步都无效，因为问题根本不在被检查的那些层上。

检索的最小单位这些年一路往下降

先把这件事的背景交代清楚。

很长一段时间里，检索处理的单位是一整个页面。

后来变成了页面里的某一段，段落级的抽取开始独立打分。

再往后，直接给答案的形态又把单位压到了一两句话。

单位每降一级，对文本切分精度的要求就高一级。

页面级只要认得出边界在哪个文件，段落级要认标签，而句子级要认的是标点。前两层的边界都是你自己写在代码里的，只有最后这一层的边界是写在自然语言里的，而自然语言的标点规则按语言各不相同。

边界从你的地盘挪到了语言的地盘，麻烦就是从这里开始的。

还有一层变化容易被忽略：单位越小，一个页面里可以被独立评估的候选就越多。同一页正文过去只作为一个整体参与竞争，现在被拆成几十个候选各自竞争。切分准的页面等于多了几十次机会，切分乱的页面等于把这些机会全废掉了。

这条趋势还有一个不太被提起的侧面：单位越小，内容之间的可替代性就越强。整页竞争的时候，品牌、结构、内链这些页面级信号还能起作用；到了单句竞争，能拿出来比的几乎只剩这一句本身说清楚了没有。前置切分因此变得比过去任何时候都关键。

页面被切成几句，决定了能被抽走什么

这一步的影响比想象中大。

一段内容能不能被摘出来当答案，前提是它得先被切成一个完整的单位。

切出来的东西太长，就会在展示时被截断。

切出来的东西太短，信息不完整，压根不会被选中。

切在错的位置，抽出来的就是一句半截话。

AI概览语言覆盖那篇讲过一门语言的语序会不会决定段落能不能被摘去当答案，那说的是语序。本篇讲的是更前面的一步：在讨论这一句写得好不好之前，先得确认它被当成了一句。

写得再好的一句话，如果没被切出来，它就不存在。

这一步的另一个特点是它完全不给反馈。抓取正常、收录正常、结构化数据校验通过，所有能看到的指示灯都是绿的。唯一的异常是那个板块从来不被摘取，而这是一个负向指标，负向指标在报表上天然不显眼，需要有人专门去找零。

这跟内容质量无关，是一步前置处理

这里需要把责任划清楚。

内容质量讲的是这段话写得清不清楚、有没有回答问题。

那一层的优化空间很大，也有很多现成的方法。

本篇讲的东西在那之前发生，属于纯粹的机械处理。

它不看你写了什么，只看字符串里有没有它认识的边界记号。

这个区分很重要，因为前置处理出问题的时候，所有针对内容质量的优化都不会有效果。你把答案写得再精炼，切分错了照样抽不出来。团队常常在质量这一层反复打磨半年，而真正卡住的是上游那一个符号。

先确认管道通不通，再谈往管道里灌什么。

把这两层分清楚还有一个现实好处：它决定了先花钱在哪儿。内容质量的投入是持续的、按篇计价的，而前置处理的排查是一次性的、按语言计价的。一次性投入通常几小时就能做完，持续投入却可能白烧半年，先后顺序错了代价很大。

还有一个判断先后的土办法：先问这个问题是不是全语言版本一致地出现。内容质量问题通常是零散的，这一页好那一页差；前置处理问题是整齐的，整个语言版本一起中招。看到整齐的零，就该往前置那一层找。

分词管词、断句管句，这两件事的证据差在哪儿？

分词的证据在词典里

先说大家更熟悉的那一件。

分词要解决的是一个词从哪儿开始到哪儿结束。

在没有空格的语言里，这件事靠词典加统计模型完成。

泰语分词那篇讲过切在哪儿由引擎的词典说了算。

词典的关键性质是：它是可以增补的。

你的品牌名切错了，把它加进自定义词典就好了。分词的错误几乎总有一个补词典的解法，成本可控，效果立竿见影，而且这份词典是你自己的资产。

这一层虽然难，但至少有一条明确的路可以走。

词典这条路还有一个附加价值，它的产出可以复用。为分词建的自定义词表，同一批词往往还能用在站内搜索的同义词配置、广告关键词的否定词表、以及内容审核的敏感词匹配上。一份投入几处受益，这在小语种上尤其划算。

断句的证据在标点里

断句要解决的是一句话从哪儿开始到哪儿结束。

它依赖的证据几乎全部来自标点符号。

句号、问号、感叹号，加上一点关于大小写和空格的规则。

Unicode的文本切分附录专门定义了句边界算法，而它开宗明义就说明这套默认规则需要按语言做本地化调整。

换句话说，规范自己承认默认档不够用。

更要紧的是，标点不是你能补的东西。它是写作者敲下去的既成事实，散落在成千上万个页面里。你没法像加词典那样，事后统一给所有句子补上正确的句末标记。

这一层的证据是只读的。

除了标点，断句还会用到一些辅助线索，比如下一个词是不是大写开头。而这条线索在没有大小写的书写系统上直接归零，中日韩泰阿拉伯语全都用不上。也就是说非拉丁语言不但主要证据更弱，连辅助证据都少了一条。

还有一类线索是句首词的性质，比如英语里句子很少以某几类虚词开头。这类统计线索同样是语言相关的，而且它需要足够的语料才能训练出来。语料充足的语言拿得到这层保险，语料少的语言就只剩标点这一条证据，容错空间被压到了零。

词典能补，标点不能补

把两件事放在一起，一条判据就出来了。

分词出问题，投入应该放在词典和自定义规则上。

断句出问题，投入必须放在写作规范和补充表述上。

两者的着力点完全不同，用错了会白花力气。

见过团队为了解决断句问题去堆词典，跑了半年一点效果没有。

更一般地说：凡是一类问题的证据来自你能修改的资产，就走增补路线；凡是证据来自已经写死的文本，就只能走绕开路线。这条判据在并列与列举那篇里也成立，那里的结论同样是不改原文、另补一份。

能改的和不能改的，从一开始就要分清楚。

这条判据还能解释一个常见的资源错配。团队在评估投入的时候，倾向于选那些有明确工具和明确产出的方向，因为它们好排期、好汇报。补词典正是这样一件事，它有工具、有产出、有进度条。而写作规范这类工作看起来什么都没交付，往往排不上号。

希腊语的问号为什么会被当成分号？

那个符号跟分号长得一模一样

现在回到开头那个案例。

希腊语有一个专用的问号，Unicode里给了它一个独立的码位。

它的字形跟拉丁字母体系里的分号完全一致，一个点在上一个点在下。

屏幕上、打印稿上、编辑器里，肉眼分辨不出任何区别。

而它在希腊语里承担的功能，是标记一个问句的结束。

这就构成了一个很少见的局面：两个功能完全相反的符号，共用同一个外观。一个是句子还没完，一个是句子完了而且是个问题。Unicode希腊与科普特文码表里能查到这个码位，说明栏里明确写着它相当于问号。

看得见的和真实的，在这里第一次彻底分家。

同形这件事本身在Unicode里并不罕见，罕见的是这两个符号的功能正好相反。多数同形字对的双方含义相近，比如不同书写系统里的同一个字母，误认了影响有限。而这一对里一个说没完一个说完了，误认的代价被放大到了极限。

还有一个让人哭笑不得的细节：因为两者外观一致，在多数字体里它们的宽度也完全相同。这意味着连排版差异都不会露出破绽，把希腊问号换成分号，整个版面一个像素都不会动。视觉排查在这里彻底没有着力点。

归一化会把它折成分号

更麻烦的一步在后面。

为了让搜索匹配更宽容，很多系统会先做一次字符归一化。

归一化的目的是把等价的写法统一成一种。

而希腊问号在兼容性映射里，恰好被映射到普通的分号上。

也就是说，你为了提高匹配率做的那一步，把这门语言唯一的问句标记抹掉了。

这跟大小写折叠那篇是同一族的坑：一个没有语言参数的通用变换，在某一门语言上是有损的。那次损失的是一个字母的身份，这次损失的是一个句子的类型。

而且这一步通常发生在你看不见的地方。

要判断自己的系统有没有做这一步，可以直接测：把一段带希腊问号的文本存进去再取出来，逐字符核对码位。存取一轮之后码位变了，就说明中间某一环做了归一化。这个测试比翻遍代码找归一化调用快得多，也更可靠。

后果落在问答类结构上

损失最集中的位置是问答类内容。

常见问题区的每一个标题，本质上都是一个问句。

问答类的结构化数据也依赖问句的识别。

而抽取式的回答系统在挑候选时，会明显偏好形式上成立的问答对。

希腊语页面上这些问句，在切分之后全都不是完整句子。

问答长尾那篇讲过整个语种里认真写完整回答的没几家，这是个机会。但机会的前提是你写的那些问答，在机器那里得先算数。写得再全，形式上不成立，一样进不了候选池。

这就是为什么这一层值得单独花时间。

还有一个连带损失落在站内搜索上。用户在站内搜一个带问号的问题，如果索引侧和查询侧的归一化不一致，同一个问句就匹配不上自己。这类不一致在多语言站上特别常见，因为两侧往往由不同时期的不同人配置。

这类损失还有一个特点，它会随着内容质量提升而变得更明显。问答写得越多、越认真，被这一层吃掉的价值就越大。于是团队会观察到一个很打击士气的现象：这个板块投入越多，跟英文站的差距反而越拉越开。

你自己的编辑器也看不出区别

这个坑还有一个格外恶劣的性质。

排查的时候，你看到的是渲染后的字形。

而渲染后的字形正好是两个符号唯一相同的地方。

把源码复制出来看，还是一样。

只有查码位才能分辨，而没人会平白无故去查一个标点的码位。

这跟域名同形字那篇的机制是一样的：凡是靠字形辨认的排查手段，遇到同形字就整体失效。可行的办法只有一个，把那一段文本丢进一个能显示码位的工具，逐字符看一遍。

说起来简单，难的是想到该去做这件事。

这里有个很实用的应对习惯：凡是排查到某一层怎么都说不通的时候，就把那段文本的码位打出来看一遍。这个动作成本几乎为零，却能挡住一整类靠肉眼永远发现不了的问题。不可见字符、同形字、方向控制符，全都在这一步现形。

一个句点在德语里兼了几份差事？

句末、缩写、序数三份差事

换到德语，问题的形状完全不同。

德语的句末标点跟英语一样是一个点，这没什么特别。

特别的是这个点在德语里还兼着另外两份工作。

第一份是缩写，德语的缩写几乎都带点，而且用得极频繁。

第二份是序数，德语的序数直接在数字后面加一个点。

于是一行德语正文里可能出现七八个点，而其中只有一个是句末。其余每一个，对断句程序来说都是一次误报的机会。德语复合词那篇讲的是词长带来的麻烦，这一条讲的是标点密度带来的麻烦，两者都源自德语正字法本身。

密度高到一定程度，这个信号的信噪比就塌了。

德语还有一类特别麻烦的缩写，是那种带空格的两段式写法。它由两个各自带点的部分组成，中间隔一个空格。断句程序看到第一个点后面跟着空格再跟着一个字母，判定条件几乎完全命中句末的特征，误报率在这类缩写上最高。

还有一个来自数字的干扰源：德语的小数点用逗号，千位分隔符用点。于是一个价格数字里就带着一个点，而它跟句末的点长得一模一样。规格密集的商品页上，光是价格和尺寸就能贡献一大批假句末。

序数点是强制的不是可选的

这里要强调一个容易被忽略的事实。

英语写序数用后缀，第一写成1st，不带点。

德语写序数就是数字加点，第一写成1.，没有别的写法。

日期里的日、楼层、条款编号、排名，全都带这个点。

商品页上写尺寸、写档位、写步骤序号，同样带。

换句话说，德语页面上假句末的数量跟内容的结构化程度成正比。你把内容写得越有条理，步骤分得越清楚，序数点就越多，断句出错的机会也越多。这是一条相当反直觉的关系。

写得好反而更容易被切错，说出去有点冤。

把序数点的影响估出来其实不难：抓一批德语页面，数一数数字后面直接跟点的出现次数，再数一数真正的句末数量。两个数一比就知道这门语言上的信噪比有多差。多数电商类德语页面上，这个比值会让人相当意外。

兼职越多，作为边界信号越不可靠

把这几门语言放在一起，可以提炼出一条能直接用的规律。

同一个字符在一门语言里承担的功能越多，它作为边界信号的价值就越低。

日语的句号只有一份差事，就是句末，几乎不会误判。

英语的句点有两份，句末和缩写，误判率中等。

德语的句点有三份，误判率明显更高。

这条规律的好处是可数、可比、可以直接拿来排优先级。要评估一门新语言的断句风险，先数一数它的句末标点在别处还兼着几份工作，一分钟就能给出一个粗略的分档。语言误判那篇提过一个类似的取向，先找出最容易出错的那一类再动手，比全面排查省事得多。

能数出来的判据，才有可能被真的用起来。

这条规律还能反过来用，帮着挑内容形态。同样一份信息，写成带序数的步骤说明和写成无序列表，在德语上的断句风险差别很大。知道了这一点，内容形态的选择就多了一个此前完全不在考虑范围内的维度。

要把这条规律用起来，最省事的形式是做一张表：一行一门语言，列出句末标点是什么、它在别处还兼几份差事、有没有专用的问号。这张表填一次就能长期用，新增语言时补一行，评估工作从半天变成十分钟。

没有句末标点的语言，边界靠什么？

泰语靠空格分句而不是分词

泰语给出的是这一类问题的极端形态。

泰语的句子结束时，不写任何标点。

句号、问号、感叹号在传统泰文里都不使用。

那句边界靠什么呢，靠空格。

泰语的空格标记的正是短语或句子的分界，而不是词的分界。

这跟泰语分词那篇的结论正好构成一对：那篇说泰语的空格不是词边界，本篇要补的是它其实是句边界。同一个字符，在泰语里干的是别的语言里句号干的活。而按空格切词的程序，等于把每一句当成了一个词。

一个字符在两门语言里承担的功能，可以完全不搭界。

这带来一个很具体的后果：泰语页面上如果为了排版好看而在词与词之间加了空格，等于凭空制造了一堆假句边界。而加空格这件事，恰恰是不懂泰语的前端和设计最容易做的一个善意改动，理由通常是这样看起来不那么挤。

中日文的句号不带空格

中日文的问题要温和一些，但同样真实。

中日文的句号是一个全角字符，后面不跟空格。

而不少老式的断句规则写的是句点加一个空格。

这条规则在中日文正文上一次都不会命中。

结果是整个段落被当成一句话处理。

日文排版需求文档里对句读点的用法有专门章节，能看出这套体系跟拉丁文的空格约定是两回事。规则写死了空格，就等于默默排除了所有不用空格的书写系统。

而这类规则往往藏在某个十几年前写的工具函数里。

这类规则的年代感是它最大的特征。写下它的时候，处理的多半是英文文档，句点加空格是完全合理的判据。问题在于它后来被复制进了一个又一个项目，而每一次复制都没有人重新问一遍这条规则默认了什么。

这类历史规则还有个特点，它们通常藏在最不起眼的地方，比如一个叫格式化工具的公共函数里。没人会想到去审它，因为它的名字听起来跟检索没有半点关系。排查这类问题时，按名字找是找不到的，只能按行为找。

两套句末标记并存的语言

还有一类情况介于两者之间。

天城文有自己的句末标记，是一竖。

但印地语网页上大量混用英文句点，尤其是技术类和电商类内容。

于是同一个站上两套标记并存，比例还不稳定。

断句程序按哪一套走，取决于它有没有为这门语言做过配置。

印度多语言那篇算过十一门语言分摊在九套书写系统上的账。混用率本身是个可以测的数：抓一批页面，两种标记各数一遍，比例出来就知道该不该单独配置。

能测的东西，就不该靠猜。

混用还会带来一个更细的麻烦：同一个段落里两套标记交替出现，断句程序按其中一套配置之后，另一套就成了噪声。所以混用率不只决定该不该单独配置，还决定了配置之后能拿到多少收益，比例太接近五五开的时候，两边配置的效果都好不了。

问句标记不在句末的语言该怎么办？

亚美尼亚语的问号标在重音音节上

再往下还有一种更彻底的情形。

亚美尼亚语有自己的句号，是一个冒号形状的符号。

它的问号更特别，不放在句子末尾。

而是标在被提问的那个词的重音音节上方。

也就是说问号可能出现在句子的中间，甚至靠前的位置。

任何靠看最后一个字符判断句型的逻辑，在这门语言上完全失效。不是判错，是根本没有可判的对象。

这类语言的市场通常不大，但一旦要做，这一层是绕不过去的。

这类语言还有一个共同点：它们的市场规模通常不足以让通用工具专门为其做适配。于是默认规则一直是它们唯一能得到的处理，而默认规则又恰好完全不匹配。资源少和适配差在这里形成了一个闭环，谁也没打算解开它。

面对这类语言，务实的选择往往不是修复而是绕开：把关键信息用结构化的方式再表达一遍，让机器不必依赖句子切分也能拿到。这条路对任何切分表现差的语言都成立，而且它的收益不随语言的资源多少而变化。

日语可以完全不用问号

日语给的是另一种偏差。

日语表达疑问靠句末的助词，问号是可选的。

正式文体里，一个疑问句常常以句号结尾。

母语者读到那个助词就知道这是问句，不需要额外记号。

而程序看到的是一个普通的陈述句结尾。

这一条跟日语敬语那篇有接口：越是正式的文体，越不写问号，而常见问题区恰好是要写得正式的地方。于是你的日语常见问题区里，可能一个问号都没有。

写得越规矩，形式上越不像问答。

这条对内容侧其实是个可以主动利用的信息。既然日语的正式问句可以不带问号，那么在常见问题区里主动把问号写上，就成了一个不损害地道程度的加分动作。日语网页上带问号的疑问句完全常见，只是不是必须，这个空间值得用起来。

判断句型的逻辑默认标记在句末

把这三门语言合起来看，能提炼出第三条原语。

所有判断这是不是一个问题的逻辑，都默认问句标记在句末。

希腊语的确在句末，但字符跟分号同形。

亚美尼亚语的不在句末，位置随重音走。

日语的可以完全不存在，靠一个词来承担。

三种偏差方式各不相同，共同点是那条默认假设在英语上成立得太好，好到没有人想过它是一条假设。凡是从来没被质疑过的规则，多半是因为它在制定者的语言上一直很准。

这条经验在小语种上会反复用到。

这条原语还有一个更广的用法：每次接一门新语言，先把自己流程里所有基于位置的假设列出来，逐条问一遍这条在目标语言上还成不成立。标记在句末、修饰语在名词前、否定在动词前，这些假设平时根本不会被写下来，因为它们在英语上从来没错过。

把这些隐含假设列出来还有一个用处，它能解释为什么某些工具在小语种上的表现会突然变差。表现变差通常不是模型能力问题，而是某一条被写死的位置假设在这门语言上不成立。找到那一条，往往比换一个更强的工具有效得多。

切错句子会在哪三个地方付出代价？

切多了：抽出来的答案缺半句

把后果分类之后，处理起来会清楚很多。

第一种错法是切多了，一句话被拦腰切成两段。

德语的序数点和缩写点最容易造成这种错。

抽取时拿到的是前半句，读起来像话没说完。

结论如果恰好在后半句，抽出来的就是一段无用的文字。

这一类错误的隐蔽之处在于抽出来的片段语法上完全通顺，它只是不完整。人读一眼就知道少了东西，机器不会知道。

能通顺地说半句话，是所有语言的共同特点。

要确认是不是这一类错法，有个简单的办法：把那一段的展示片段跟原文并排，看片段结尾处是不是恰好落在一个缩写或者序数后面。命中率相当高，因为这两类是德语里唯一会在句中制造假句末的成分。

切少了：整段并成一句被截断

第二种错法是切少了，好几句并成一大坨。

中日文用老式规则处理时最常见。

并起来的那一大段远超展示长度，只能被截断。

截断的位置是按字数算的，跟语义没有关系。

于是展示出来的就是一段在莫名其妙处断掉的文字。

可读性公式那篇提过句长在不同语言上的基线本来就不同。切少了会让实测句长虚高好几倍，任何基于句长的判断因此一起失真，包括可读性评分和摘要选择。

一个前置错误，会污染下游一整串指标。

这一类错法还有个连带影响，它会让所有跟句长有关的自动化判断集体失灵。摘要选句、可读性打分、内容质量评估，只要涉及句子这个单位的指标，全都建立在切分结果之上。切分错了，这些指标不是不准，而是根本在测另一样东西。

这类错法还有个反直觉的地方：它在中日文上比在拉丁语言上更常见，而中日文恰恰是很多团队认为已经处理得不错的语言。原因是中日文的其他环节都做过适配，唯独这一条老规则因为太底层而从未被碰过。

切错位置：问句和答案粘在一起

第三种最麻烦，边界落在了错误的位置。

希腊语常见问题区就是典型：问句没有结束，跟答案连成了一句。

抽出来的片段既包含问题又包含半截答案。

这种片段在问答匹配里得分很低，因为它看着不像一个答案。

而它同时也不像一个问题。

三种错法里，只有这一种会让内容同时失去两个身份。前两种至少还保住了一个残缺的单位，这一种连单位类型都错了。

所以排查时应该先找这一类。

这一类的另一个特征是它高度集中在特定板块上。问答区、步骤说明、条款列表这些一问一答或者一条一条的结构，最容易出这种错，因为它们的每个单元本来就短，边界判断错一次就整体串位。连续叙述的正文反而不太出这个问题。

三种错法的报表长相各不相同

好在这三种错法在数据上留下的痕迹并不一样。

切多了通常表现为长尾问句词有展现但点击率低。

切少了表现为摘要展示经常在奇怪的地方断掉。

切错位置表现为整个板块从来不被摘取，展现接近于零。

第三种最容易识别，因为它是彻底的零而不是偏低。

识别顺序也就有了：先找彻底为零的板块，再找展示形态异常的，最后才看点击率偏低的。零是最强的信号，而一个内容扎实的板块长期为零，几乎一定是结构性原因。

保哥的习惯是先看有没有零，再看数字大小。

把这三种长相记下来还有个好处，它能让人在看报表的时候多问一句。看到一个板块展现为零，第一反应通常是内容不行或者竞争太激烈；知道有这三种错法之后，就会先去确认它有没有被正确切分，而这个确认只要几分钟。

这三种长相还可以合成一张排查顺序表，按发现成本从低到高排：先扫零展现的板块，再看展示片段有没有在奇怪位置断掉，最后才对着点击率找。前两项看报表就能完成，第三项才需要逐条对照原文。

十行代码测出你的页面被切成了几句

浏览器里就有现成的断句接口

这件事的自检成本低得出人意料。

现代浏览器内置了一个国际化的文本切分接口。

它支持按词、按句、按字素三种粒度，并且接受语言参数。

MDN关于这个接口的文档给了完整的用法，选句子粒度就能拿到切分结果。

不需要装任何库，打开控制台就能跑。

做法很直白：把页面正文取出来，指定目标语言跑一遍句子粒度切分，数出句子个数。这个数字就是机器眼里这一页有几句话。浏览器支持情况可以先查一下，主流浏览器都已经支持。

十行代码，五分钟出结果。

要注意这个接口给出的是它自己的判断，不是搜索引擎的判断。两者用的规则数据未必一样，结果也可能有出入。但对自检来说这不影响结论，因为你要找的是那种明显偏离的情况，而明显偏离在任何一套规则下都会显现。

拿人工数的句数当对照

光有机器的数字还不够，得有个对照组。

找一个母语者，让他把同一段文字的句子数出来。

两个数字并排一看，问题的性质立刻清楚。

机器的数字明显偏大，说明切多了。

明显偏小，说明切少了。

两个数字接近但抽取效果仍然不好，那问题在别处。这个对照的价值在于它把一个模糊的怀疑变成了一个具体的比值，而比值可以写进工单，也可以跨语言比较。

没有对照组的数字，说服不了任何人。

让母语者数句子的时候，最好不要提前说明目的。一旦他知道你在查什么，判断就会往你想要的方向靠。更稳的问法是请他把这段话按句子分行抄一遍，让分行动作自然产生句数，而不是让他直接报一个数字。

拿到两个数字之后，还有一个值得多做一步的动作：把差异最大的那一段单独拎出来，请母语者标出他认为的每个句末位置。这份标注既是证据，也可以直接拿去当规则定制的输入，一份工作两处用。

该测哪几类页面

测试范围要收窄，不然成本还是高。

第一类必测的是常见问题区，因为它全是问句。

第二类是退换货和配送说明，那里缩写和数字最密集。

第三类是商品详情里的规格段落，序数和单位扎堆。

这三类的共同点是标点密度高于普通正文。

标点密度高，出错概率就高，而这三类恰好又是最可能被摘去当答案的内容。风险和价值同时最高的那一块，理所当然应该先测。

剩下的营销文案，出错了影响也有限。

这三类页面还有一个共同的优势：它们的正文都不长，人工核对的成本可控。全站抽检听起来严谨，实际做起来往往中途放弃。挑三类各两页，一个下午能出结论，而结论的方向性跟全站抽检不会有本质差别。

断句这件事该交给前端、检索层还是内容侧？

前端只能影响标记不能影响字符

知道问题在哪之后，得决定谁来修。

前端能做的是把每一句用独立的标签包起来。

这确实有帮助，因为标签边界比标点边界可靠得多。

但前端改不了正文里那个符号本身。

希腊语的问号还是那个问号，德语的序数点还是要写。

所以前端这条路的上限很清楚：它能提供一层额外的边界信号，但不能修复原有信号的歧义。把每个问答项包成独立的块，是性价比最高的一步，也基本是前端能做的全部。

额外信号有用，但别指望它兜底。

把每个问答项包成独立块还有个附带收益，它顺便把结构化数据的标注边界也理清楚了。很多站的问答标注跟视觉结构对不上，就是因为正文本身没有清晰的块边界。前端这一步做完，标注的准确率通常会跟着提高一截。

需要提醒的是，包块这件事要跟视觉结构保持一致，不能为了机器凭空加一层看不见的容器。加了看不见的容器，维护的人下一次改版就会把它删掉，因为他不知道那是干什么用的。凡是没有可见理由的结构，寿命都不会长。

检索层能换规则但你未必控制得了

检索层的空间理论上最大。

成熟的切分库都允许加载语言专属的规则。

ICU的边界分析文档说明了怎么用规则文件定制断句行为，包括处理缩写列表。

问题是这条路只对你自己的站内搜索有效。

外部搜索引擎和大模型用的是它们自己的切分逻辑。

这就把这条路的适用范围限定住了：能改的那一半通常不是最值钱的那一半。站内搜索值得改，因为它直接影响转化；外部那一侧你只能通过写作来影响。

分清哪些是你的地盘，能省下大量无效讨论。

还有一个容易被忽略的边界：即使是站内搜索，改切分规则也需要重建索引，而重建索引在大站上是有窗口期要求的。所以这条路虽然可行，排期成本却不低。评估的时候要把它算成一个中等规模的技术改造，而不是改个配置。

内容侧的空间比想象中大

剩下的责任落在内容侧，而这一侧的空间其实不小。

第一件事是在常见问题区的标题里，把问句写得不依赖标点也成立。

比如用疑问词开头，让句型本身就带信息。

第二件事是把关键结论写成独立的短句，别挂在长句的后半段。

第三件事是在规格段落里少用序数点，能写成列表就写成列表。

这三件事都不需要动技术栈，而且它们同时也是让人读起来更舒服的改动。这一层很少见地出现了机器和读者利益一致的情形，结构化数据那篇里那种正文和机器读的版本要分开写的取舍，在这里不必做。

能两头都讨好的改动，应该优先做完。

内容侧还有一个几乎零成本的动作：在写作规范里加一条，关键结论不要放在含缩写或序数的句子后半段。这条规则不需要任何语言学知识，写作的人一看就懂，而它恰好避开了断句最容易出错的那个位置。

内容侧这几条还有一个共同的优点：它们的效果不依赖任何一方的配合。前端改不改、检索层换不换规则，写作规范一旦落地就一直在生效。在跨部门协作成本高的团队里，这一点往往比理论上的最优解更重要。

一份可以照着做的句边界自检清单

五步查完一个语言版本

把整篇压成可以直接执行的五步。

第一步，挑三类高风险页面各取两页，导出正文纯文本。

第二步，用浏览器的切分接口按句子粒度跑一遍，记下句子数。

第三步，请母语者数一遍同样几段的真实句子数，两个数字并排。

第四步，差异明显的，把那几段逐字符查码位，重点看句末那一个。

第五步，按三种错法归档，切多了走写作规范，切少了走标记包裹，切错位置走符号核查。这五步里只有第三步需要母语者，其余全是机械操作。审校验收那篇说过，能交给不懂那门语言的人执行的检查才跑得下去，这份清单是照着那条原则设计的。

一个语言版本跑完大约需要两小时。

这五步里最容易走过场的是第四步查码位，因为前三步做完之后人往往已经形成了判断，觉得原因显而易见。但真正让结论站得住的恰恰是这一步，它把一个推测变成了一个可以贴进工单的证据。省掉它，整轮排查的说服力会打对折。

这套流程还可以顺手产出一份副产品：那份逐字符核过的文本，本身就是给译者和写作团队最好的说明材料。抽象地讲什么是同形字很难让人上心，把两个长得一样的符号连同码位一起摆出来，通常一遍就记住了。

优先测哪几类页面

如果连两小时都挤不出来，那就只测一类。

只测常见问题区，性价比最高。

它的问句密度最高，因此暴露问题最快。

它也是最可能被摘去当答案的内容形态。

而且它的篇幅短，人工数句子的成本最低。

换句话说，常见问题区在诊断价值、商业价值和测试成本三个维度上同时最优。要是只能做一件事，就做这一件。情态与承诺强度那篇给的那份清单也是从这一块开始的，两件事可以合成一轮做完。

同一批内容，一次抽检解决两个问题。

如果连一类都不想全测，还有个更省的版本：只挑常见问题区里最长的那三条问答，跑一遍切分看句数。问题如果存在，在这三条上几乎一定会显现，因为它们的标点最多。十五分钟就能得到一个粗略但方向可靠的判断。

挑最长的那三条还有个理由：长问答里更可能出现列举、缩写和数字，也就是所有假句末的来源。短问答标点少，即使切分逻辑有问题也不容易暴露出来，测了反而可能给出一个虚假的安全结论。

什么时候该承认这条不用管

最后说说什么时候可以放过。

如果你做的语言句末标点跟英语完全一致，风险本来就低。

如果那门语言的内容还没有任何被摘取的记录，先解决更前面的问题。

如果整个板块的流量占比极小，优先级自然靠后。

判断只需要两个数：这门语言的问句类内容占比，和它的句末标点兼职数量。

两个数都低，这件事可以先不管；有一个高就值得测一次，两个都高就该排进这个季度。测一次的成本是两小时，而问题一旦存在，它影响的是整个语言版本的问答类内容。

成本这么低的检查，实在没有理由拖着。

还有一种情况也该放过，就是那门语言的内容目前还处在刚起步的阶段，页面数少、更新频繁。这时候写作规范都还没定型，先做这一层的排查等于给一个还在动的东西做体检。等内容形态稳定下来再测，结论才有保存价值。

判断值不值得做，还可以把它跟别的排查合并考虑。如果这个季度本来就要抽检问答区的内容质量，那顺手跑一遍切分几乎不增加成本。单独立项的门槛高，搭车的门槛低，这类小而重要的检查最适合搭车。

常见问题解答

希腊语的问号可以直接换成英文问号吗？

技术上可以，但那是错别字，希腊读者一眼就能看出来。稳妥的做法是正文保留正确的符号，另外在结构化数据和标记结构上给出额外的边界信号。也就是说不动字符，改用别的方式让机器知道这里是一个问句的结束。这跟处理德语省略连字符的思路是一致的，规范归规范，补充归补充。实际操作里还有一个更轻的做法，就是在问答标题里同时用疑问词开头，让句型本身就带上问句特征，不完全依赖那个符号。结构化数据那一份也值得单独确认，因为它跟正文用的是两条链路，正文修好了不等于标注也修好了。

用标签把每一句包起来是不是就万无一失了？

不是万无一失，但确实是性价比最高的一步。标签边界比标点边界可靠，抽取时也更容易被识别成独立单位。它的局限在于你只能包到段落和条目这个粒度，段落内部的句子还是要靠标点切。所以它对常见问题区这种一问一答的结构效果最好，对连续叙述的正文帮助有限。另外要注意标签结构只对显式分块的内容有效，正文里连续的几句话仍然要靠标点切，所以它是补充不是替代。另外还要注意包块的粒度别过细，把每一句都包成独立元素反而会让页面结构变得难以维护。

这件事跟分词是不是同一个问题的两个说法？

不是。分词处理的是词边界，证据来自词典，而词典你可以增补；断句处理的是句边界，证据来自标点，而标点是写作时就定死的。两者的可干预程度完全不同，投入方向也就不一样。混为一谈最常见的后果是把预算全砸在词典上，而真正卡住的那一层一动没动。还有一个实际差别是排查顺序：分词问题通常在关键词报表上先冒头，断句问题只在抽取和摘要那一侧显现，两者的入口完全不同。两者的投入产出也不同：词典的效果是渐进的，断句一旦切对，整个板块的表现可能一次性回来。

浏览器的切分接口在冷门语言上准吗？

准确度跟这门语言有没有配套的规则数据直接相关。主流语言的表现相当不错，冷门语言可能就退回默认规则了。不过这不影响它当自检工具用，因为你要的不是绝对准确，而是机器切出来的句数跟人数的句数差多少。差多少这件事，用默认规则跑出来一样有意义。如果拿不准某门语言的支持情况，可以拿一段已知句数的文本先跑一遍当校准，看接口在这门语言上的基本表现如何。校准文本最好挑一段真实的站上内容，而不是随手编的句子，编的句子往往标点比真实内容规整得多。

德语的序数点真的没有别的写法吗？

正式书写里没有。日期、楼层、条款编号都是数字加点，这是正字法规定的。能做的是在结构上绕开，比如把步骤序号交给有序列表去生成，而不是在正文里手写。这样正文里的点就少了一大批，断句的误报率也跟着下来了。有序列表还有一个额外好处，序号由标签生成之后正文里那些点就消失了，同一段文字的假句末数量会明显下降。如果内容管理系统不支持有序列表，退一步也可以把序号写成不带点的形式，虽然不够规范但风险更低。

怎么快速确认某个标点的码位？

把那一段文本粘进任何一个能显示字符编码的工具，逐字符看一遍即可。也可以在浏览器控制台里对那个字符取码位，一行代码就有结果。关键不是技术难度，而是要想到去做这件事。绝大多数同形字问题拖了很久，都是因为没人怀疑过一个看起来完全正常的标点。如果是批量排查，可以写一个小脚本把整段文本的码位逐字符输出，重点看每个句末位置上的那个字符是不是你以为的那个。排查时重点看那些看起来完全正常的标点，真正有问题的从来不是那些一眼可疑的字符。

这件事该多久复查一次？

内容形态不变的话，一次查清就能管很久，因为标点规则本身不会变。真正需要复查的时机是换了内容管理系统、换了翻译供应商，或者新上了一门语言。这三个时刻都可能引入新的写作习惯，值得把那五步重跑一遍。日常更新则不必，改一篇文案不会改变整个语言版本的标点分布。换供应商这个触发条件尤其值得记，因为不同译者对标点的处理习惯差别相当大，而这种差别在验收时几乎不会被提出来。除了这三个时机，如果发现某个语言版本的问答区突然不再被摘取，也应该立刻重跑一遍这五步。

权威参考资料