一、智能客服：转人工率是最贵的指标

演示里三语客服：中文一万二千条、英语五千条、阿拉伯语一千八百条，自动解决率分别是 92%、90%、71%。 阿拉伯语的单条 token 比英语多 21%，自动解决率却低 19 个点。两个方向都在加成本。 转人工的总量是 1980 条。 这个数不只是人工费——它同时意味着用户体验断了一次，而断在「模型没听懂」这件事上， 比断在「系统繁忙」更伤。

所以这个场景的优化顺序很清楚：先把 token 膨胀解决掉（扩词表或者换更适合的词表），再解决准确率。 顺序反了会白花钱：token 贵三成、准确率还低两成的时候，先优化准确率， 你会为每一条更贵的请求付更多的次数。

二、搜索引擎：分片数就是机器数

索引是按语言分片的：每种语言一个独立索引，因为不同语言的分词、排序信号、停用词都不一样。 演示里五种语言、一万四千三百万文档，切成十七个分片。 中文五个、英语九个、日语一个、阿拉伯语一个、斯瓦希里语一个。 最后那一行最能说明问题：斯瓦希里语只有十二万文档，照样占一个分片。 每片的最小成本是固定的，长尾语言的单位成本最高。

所以小语种的索引常常合并进一个「其他语言」分片，用语言字段过滤。 省机器，代价是查询要多扫一些无关文档，延迟涨一点。 这笔取舍没有标准答案。判据是流量：那个语言的查询多到值得单独一片，就分开； 少到一年也没几次，就合并。

三、机器翻译：先定门槛，再定上不上自动

翻译场景最需要说清的是「门槛从哪来」。它不是模型分数，是错了赔不赔得起。 演示里门槛定在 4.0 分。英中、中英两对过线走自动，英阿、中阿、英斯三对回落人工。 过线的两对覆盖了九成流量，但它们是最好做的那几对。 剩下的百分之十散在难做的语言对上——那部分才是长尾的成本所在。

最后一行最扎心：英语到斯瓦希里语只有 2.4 分，离门槛差 1.6。差的不是模型架构，是那三十万句语料。 实践里常见的做法是「机器翻译加译后编辑」：先机翻，再让人改。 它的成本比纯人工低、比纯自动高，但质量可控——这是长尾语言唯一算得过来的方案。

四、共同的账：长尾的单位成本

三个场景的指标完全不一样，算的却是同一件事：服务一种语言的固定成本，除以这种语言的业务量。 固定成本是：词表名额、评测集、索引分片、人工兜底团队。 它不随业务量缩小——斯瓦希里语十二万文档也要一个分片，八万句语料也要一套评测。 业务量是：用户数乘使用频次。长尾语言两样都小。

所以「小语种效果差」这件事，最后落在财务报表上，不是落在技术报告上。 同一家公司可以为中文做得很深，为斯瓦希里语只做「够用」——不是做不到，是算不过来。 真正能改变这条账的只有一件事：把语料量提上去。词表、采样、模型结构都是在这之后才有意义的优化。

五、本章小结，也是全书小结

这一章四句话。第一，词表是零和的，多给一种语言就要从别人碗里拿，而谁拿得多由语料频次决定。 第二，语料分布极度倾斜，按自然分布训，稀有语言几乎不出现。温度采样能抬，代价是稀释高资源。 第三，优化有顺序：先加语料，再调采样，再扩词表，最后才谈模型结构。顺序反了，前面的功夫全白做。

第四，落地是算账。长尾语言的单位成本高，这是商业事实，不是技术缺陷。 回头看全书：第一章讲原理，第二章部署，第三章微调，第四章多轮对话，第五章行业化， 第六章用编排代替训练，第七章多语言。 七章讲的是同一件事的七个面：一个模型从论文走到能用，中间隔着的全是工程判断。哪个参数值得调、 哪笔钱值得花、哪个指标才是真的——这些没有标准答案，只有算清楚的账。

这本书到这里结束。剩下的部分，得在你的数据上才算得出来。

六、动手 Demo：客服、搜索、翻译：三个场景各算一笔账

三组造的数据，量级参照真实业务：三语客服工单、五语搜索索引、五组翻译语言对。 数是我编的，算的口径是真的。 客服看转人工率与 token 成本，搜索看分片数，翻译看达标线与流量覆盖。

TICKETS = [(u'中文', 12000, 0.92, 420),
           (u'英语',  5000, 0.90, 380),
           (u'阿拉伯语', 1800, 0.71, 460)]

for lang, n, acc, tk in TICKETS:
    esc = int(n * (1 - acc))        # 转人工条数
    print(lang, esc, n * tk / 10000.0)

# 搜索：每片装 1000 万文档，向上取整
shard = max(1, int(math.ceil(n / 1000.0)))

# 翻译：达标线 4.0，够了走自动，不够回落人工
print(u'上自动' if score >= 4.0 else u'回落人工')

实跑输出：

--------------------------------------------------------------------
客服、搜索、翻译：三个场景各算一笔账
--------------------------------------------------------------------


  ① 智能客服：准确率低的那一档最贵
  --------------------------------------------------------------------
| 语言 | 月工单 | 自动解决 | 转人工 | tokens（万） |
|---|---:|---:|---:|---:|
| 中文 | 12000 | 92% | 959 | 504.00 |
| 英语 | 5000 | 90% | 499 | 190.00 |
| 阿拉伯语 | 1800 | 71% | 522 | 82.80 |

  ! 阿拉伯语的单条 token 比英语多 21%，自动解决率却低 19 个点——两个方向都在加成本。
  ! 转人工的 1980 条不只是人工费的事：它同时意味着用户体验断了一次。
  低资源语言的那一档，钱和口碑一起亏。
  口径：tokens 按万计，单价随服务商变，这里只比相对量，不给金额。

  ② 搜索引擎：按语言分片，分片数就是机器数
  --------------------------------------------------------------------
| 语言 | 文档（万） | 分片数 | 每片文档（万） |
|---|---:|---:|---:|
| 中文 | 4200 | 5 | 840 |
| 英语 | 9000 | 9 | 1000 |
| 日语 | 800 | 1 | 800 |
| 阿拉伯语 | 300 | 1 | 300 |
| 斯瓦希里语 | 12 | 1 | 12 |

  ! 一共 17 个分片。
  注意最后一行：斯瓦希里语只有 12 万文档，照样要占一个分片——每片的最小成本是固定的，
  长尾语言的单位成本最高。
  ! 所以小语种的索引常常合并到一个「其他语言」分片里，用语言字段过滤。
  省机器，代价是查询要多扫一些无关文档。

  ③ 机器翻译：先定门槛，再定上不上自动
  --------------------------------------------------------------------
| 语言对 | 评分 | 月流量（条） | 处置 |
|---|---:|---:|:---:|
| 英→中 | 4.6 | 24000 | 上自动 |
| 中→英 | 4.4 | 18000 | 上自动 |
| 英→阿 | 3.8 | 3000 | 回落人工 |
| 中→阿 | 3.2 | 1200 | 回落人工 |
| 英→斯 | 2.4 | 400 | 回落人工 |

  门槛定在 4.0 分。
  达到门槛的走自动，达不到的回落人工——这条线不是「模型好不好」，是「错了赔不赔得起」。
  ! 达到门槛的语言对覆盖了 90% 的流量，但它们是最好做的那几对。
  剩下 10% 的流量散在难做的语言对上——这部分才是长尾的成本所在。
  ! 最后一行最能说明问题：英语到斯瓦希里语只有 2.4 分，离门槛差 1.6。
  差的不是模型架构，是那 30 万句语料。

  ④ 三个场景的共同点
  --------------------------------------------------------------------
  客服看的是「转人工率」，搜索看的是「分片成本」，翻译看的是「达标线」。
  三个指标长得完全不一样，算的却是同一笔账：长尾语言的单位成本。
  ! 这条账决定了商业决策，不是技术决策。
  同一家公司可以为中文做得很深，为斯瓦希里语只做「够用」——不是因为技术做不到，是因为算不过来。
  ! 真正改变这条账的只有一件事：把那 30 万句变成 3000 万句。
  词表、采样、模型结构都是在这之后才有意义的优化。

①客服这张表，三行看完就够了。中文量最大、准确率最高、单条 token 中等，是最健康的一档。 阿拉伯语最难看：单条 token 比英语多 21%，自动解决率低 19 个点，一千八百条里五百多条要转人工。 合计 1980 条转人工。这个数不只是人工费——每条都是一次体验中断。 断在「模型没听懂」上，比断在「系统繁忙」上更伤。 ②搜索这一格，前两行没什么可说的，中文五个片、英语九个片，跟文档量成正比。 最后一行才是重点：斯瓦希里语十二万文档也占一个片。 每片的最小成本固定，所以它的单位成本最高——高出将近一百倍。 这就是为什么要合并成「其他语言」片。省的是机器，付的是延迟。 ③翻译这张表，两行过线、三行回落。过线的覆盖九成流量。 但要看清楚：过线的是英中和中英，最好做的两对。 剩下百分之十的流量散在三对难做的上面，那才是长尾的成本所在。 最后一行差 1.6 分。差的不是模型架构，是那三十万句语料——这句话跟上一节的结论接上了。 ④三个场景的指标长得完全不一样，算的是同一笔账：固定成本除以业务量。 固定成本是词表、评测集、索引分片、人工兜底，它不随业务量缩小； 业务量是用户数乘频次，长尾语言两样都小。 所以这件事最后落在财务报表上。「小语种效果差」不是技术缺陷，是商业事实。 能改变这条账的只有一件事：把语料量提上去。其余优化都排在它后面。

30 秒实验

1. 把阿拉伯语的自动解决率从 71% 提到 90%，重跑第 ① 步。转人工条数降到多少？ 这时候还值得为它单独优化吗？
2. 把搜索的分片阈值从 1000 万改成 500 万，重跑第 ② 步。总片数变成多少？斯瓦希里语还是占一片吗？
3. 把翻译门槛从 4.0 提到 4.5，重跑第 ③ 步。还有几对能过线？流量覆盖率掉到多少？ 这时候业务上还能接受吗？

常见误区

1. 用总分评价一个多语言产品。总分由高资源语言撑起来，长尾语言的糟糕体验被平均掉了。
2. 先优化准确率再优化 token 成本。 token 贵的时候，每一次更准的调用也更贵，而且准确率提升带来的调用次数增加会把成本放大。
3. 给每种语言都单独开索引分片。长尾语言的单位成本会高到没法看，而它带来的收益只有「查询快一点」。
4. 把「模型能不能翻」当成「该不该上自动翻译」。 判据是错了赔不赔得起，不是分数够不够高——法律文书和商品标题，同一个分数，不同的门槛。
5. 以为多语言只是技术问题。 它最后一定是成本问题，而成本问题只有两种解法：加语料，或者接受「够用就好」。

全书到这里结束。 七章从原理走到落地，最后落在一句话上：技术决定能做到什么，账本决定做哪一部分。

• ☐ （全书完）

相关笔记

• 资源与评测：语料与采样的账
• 优化方向：词表与压缩率
• 业务分析：先用算术定方向
• 38 课 AI 训练师手册：需求分析与验收口径
• 🦙 Llama 大模型实践 · 索引