为什么拉丁字母转目标文字需要一个专用小模型

你输入 aaj meeting hai，想得到的是 आज meeting है。原意不能变，英文单词也不能变，只有用拉丁字母写出的印地语需要进入天城文。这个很小的例子，就是 Convert 值得拥有专用模型的原因。

这是“转写模型系列”的第一篇，记录 UnimeType Transliteration-4B 背后的实际选择。

Convert 是一个边界明确的文字操作

Convert 处理的是已经写好的文字。它不负责改善语气，不补充解释，不总结段落，也不替用户编写回复。

例如：

ashita Tokyo de meeting ga arimasu

明日 Tokyo で meeting があります

有用的结果会保留 Tokyo 和 meeting，转换日语读音，并且只返回可以替换原文的正文。如果输出改变了这个约束，即使句子听起来更流畅，也不一定是更好的 Convert 答案。

Polish 和 Explain 需要不同的能力

Polish 可以改写措辞和句式。Explain 可能需要较广的知识和更长的回答。这两类动作的输出空间很大，因此继续使用能力更强的云端模型。

Convert 的目标窄得多。小型本地模型可以反复学习一组明确规则：

• 只转换应该转换的拉丁字母片段；
• 保留英文、代码、链接、账号名、数字和 emoji；
• 保留换行与标点；
• 只返回替换正文，不添加说明。

把动作分开后，错误也更容易判断。Convert 如果改坏一个网址，或者翻译了英文产品名，那么即使整句仍然通顺，结果也是错的。

专用模型把容量用在真正困难的边界上

难点不只是生成汉字、日文、阿拉伯字母或天城文。模型还要判断哪些片段属于目标语言，哪些片段必须原样保留。

例如：

qing yunxing npm test ranhou debug OpenAI API

真正有用的转换器需要转换中文读音，同时保留命令和产品名。聊天消息、问题追踪、学习笔记和社交帖子里，经常会出现这种混合边界。

通用聊天模型能够完成这个任务，但它还携带许多 Convert 不需要的能力。使用专用模型后，训练样本、测试案例和运行设置都可以围绕用户实际触发的这一个动作来设计。

产品边界很简单

UnimeType Transliteration-4B 只处理 Convert。Polish 和 Explain 仍是独立的云端动作。选择本地 Convert 模型，并不等于把所有写作功能都塞进同一个模型。

下一篇会介绍我们如何构建日常转写数据，而不把翻译语料当成输入数据。每种产品动作的实际行为见动作。