Sumibi 与 LLM 假名汉字转换：从上下文到抽象语义的实践指南

Sumibi 是一个思路比较特别的日语输入系统：它不维护带统计信息的转换词典，也不做统计处理，手上只有一份用于补充同音异义词候选的简单 SKK 词典。真正的转换动作，是把罗马字（或平假名）交给大语言模型，由模型返回汉字假名混合文。它适合想了解「LLM 直接做かな漢字変換」这条路能走多远的人，也适合已经在用传统 IME、想对比两种路线差异的开发者。需要注意的是，Sumibi 的转换质量高度依赖所选模型的规模与能力，同一系列里不同参数量的模型表现差距可能很大。

准备工作

在动手之前，先把下面几件事确认清楚。Sumibi 本身是一个开源项目，具体支持的模型、依赖版本与安装方式请以项目当前信息为准，本文只讲通用流程与思路。

运行环境

一台可以运行本地大模型的机器，或者可以访问远程模型接口的环境。本地运行对显存或内存有要求，模型越大要求越高。
一个可用的 LLM 推理后端。Sumibi 的转换完全依赖模型输出，所以后端是否稳定、是否支持足够的上下文长度，直接决定体验。
一份 SKK 词典文件，用于在同音异义词场景下补充候选。Sumibi 不靠统计词典，这份词典是它唯一的本地语言资源。

模型选择上的前置认知

素材里给出的本地模型基准测试结果值得先看一眼，它会影响你对模型的选择。同一系列（Gemma 4）下，用平假名输入测得的字符错误率（CER）差异明显：

模型	平假名输入的字符错误率（CER）
Gemma 4 E4B	26.0%
Gemma 4 26B-A4B	15.6%

模型规模不是决定精度的唯一因素，但这组数据至少说明：更大的模型更容易利用上下文和语义关系来完成转换。选模型时不要只看参数量，也要看它在日语文本上的实际表现。

输入形式的准备

一个容易踩的坑是输入形式。直接把罗马字交给模型，精度往往不如先转成平假名再交给模型。原因推测是训练数据里罗马字形式的日语非常少。所以如果你的输入习惯是罗马字，最好在送入模型之前先做一次罗马字到平假名的转换。

操作步骤

第一步：确定转换的基本链路

Sumibi 的转换链路可以概括为：接收罗马字或平假名输入，必要时先做罗马字到平假名的归一化，然后把输入连同周边上下文一起组织成提示词，交给 LLM，由 LLM 返回汉字假名混合文，最后把结果回填到输入位置。

这条链路里没有统计转换这一步，也没有 n-gram 打分。传统方式会先从词典列出读音匹配的候选，再从语料统计出的词频和相邻数词的共现频率里挑出概率最高的组合；Sumibi 把这一步整个交给了模型。

第二步：准备同音异义词词典

不要指望让模型自己列举同音异义词候选。素材里提到过一个很典型的现象：让模型列举「kansei」的候选时，它反复只返回「完成」。模型擅长在上下文里挑一个，不擅长穷举读音对应的所有写法。

所以正确做法是在本地保留一份同音异义词词典，由 Sumibi 侧负责候选的枚举与补充，模型只负责在给定上下文下做选择。词典格式采用 SKK 词典即可，不需要额外的统计信息。

第三步：组织提示词，加入周边上下文

这是提升转换质量最关键的一步。把转换位置周边的若干行文本作为上下文一并放进提示词，让模型据此判断当前讨论的是哪个领域、正在使用哪种书写风格。

效果对比很明显。以下例子中，左侧是不给上下文的结果，右侧是给了上下文的结果：

输入	无上下文	有上下文
結果に ijyou があります	結果に以上があります	結果に異常があります
荷物を hassou します	荷物を発想します	荷物を発送します
変換 seido wo agemasu	変換制度を上げます	変換精度を上げます

上下文不只影响专业词汇的选择，也影响书写风格的统一。下面这个例子是在第二行行末做转换：

输入	无上下文	有上下文
ニンテンドースイッチ2を買いました。nintendo switch 2 ha nintendo switch toha chigattte、	ニンテンドースイッチ2を買いました。Nintendo Switch 2は Nintendo Switch とは違って、	ニンテンドースイッチ2を買いました。ニンテンドースイッチ2はニンテンドースイッチとは違って、

没有上下文时，模型会选自己最熟悉的英文表记；有上下文时，它会跟随文中已经出现的片假名表记。这说明模型是在根据当场文章的写法调整输出，而不是单纯调用领域知识。

第四步：在提示词里加入防改写指令

模型从上下文补全语义的能力，和「把输入改写成更自然的文章」的倾向是一体两面。开发早期出现过模型在输出里插入原输入中并不存在的句子的情况。解决办法是在提示词里明确加一条约束，大意是「不要生成原罗马字中不存在的句子」。加入这条指令后，这类问题明显减少。

如果你的场景对忠实度要求高，这条约束应当作为提示词的固定组成部分，而不是可选项。

第五步：处理模型不擅长的部分

把模型不擅长的任务从模型侧移走，交给 Sumibi 侧处理。已经确认的两类不擅长：

同音异义词的穷举：交给本地 SKK 词典。
罗马字的读解：在送入模型前先转成平假名。

另外，上下文学习只是当场生效的适配，它不会把用户的修正永久记住。用户词典和修正历史需要由 Sumibi 侧保存，并在需要时把相关信息传给模型。不要指望模型自己记住你上次改过什么。

一个完整示例

下面走一遍从输入到输出的最小流程。假设用户正在写一段关于设备检测的文本，光标停在需要转换的位置。

1. 收集输入与上下文

当前输入（罗马字）：

kekka ni ijyou ga arimasu

周边上下文（前几行）：

センサーの測定値を確認しました。
kekka ni ijyou ga arimasu

2. 罗马字转平假名

把待转换部分归一化为平假名，避免模型直接读罗马字：

けっか に いじょう が あります

3. 组装提示词

提示词里包含三块内容：周边上下文、待转换的平假名、以及防改写约束。

以下の文脈を参考に、ひらがなを漢字仮名交じり文に変換してください。
元のローマ字にない文章を作り出さないでください。

文脈:
センサーの測定値を確認しました。

変換対象:
けっか に いじょう が あります

4. 取得模型输出

模型返回：

結果に異常があります

5. 回填与记录

把结果回填到光标位置。如果用户做了修正，把修正记录保存在 Sumibi 侧的用户词典或历史里，供后续使用。这一步不要依赖模型自身的记忆。

把上下文去掉再跑一次同样的输入，模型很可能返回「結果に以上があります」。这个对比就是上下文起作用的最直接证据。

注意事项

模型能力的边界

模型能高度处理文章中的模式和关系，但它并没有用身体经验过词语所指的现实。能生成自然的文章，和正确理解输入者的意图，不是同一件事，它同样会产出看似合理的错误。评估时不要把「是否理解」当成二选一的问题，而应当把「对转换有帮助的能力」和「容易失败的条件」分开来看。

已知的失败模式

同音异义词穷举失败：让模型列举候选时，它可能反复返回同一个词。用本地词典解决。
罗马字读解精度低：训练数据中罗马字日语极少，先转平假名再送模型。
过度补全语义：模型可能插入原输入中没有的句子。用提示词约束抑制，但不能保证完全消除。
上下文学习不持久：它只是当场适配，不会记住用户的修正。持久化要靠 Sumibi 侧。

上下文长度与领域差异

前面的上下文越长，转换精度往往越高，但不同领域之间的精度差异也会显现出来。这意味着在某个领域调好的提示词，换到另一个领域未必同样有效。评估时应当分领域看结果，而不是只看一个总体数字。

歧义越大，恢复越难

模型从歧义输入中恢复意图的能力是有上限的。像只打辅音的省略输入这种歧义极大的情况，精度会大幅下降。如果你的输入习惯包含大量省略，需要预期到这一点。

易变信息以官网为准

本文涉及的模型名称、规模、错误率数据来自特定时间点的测试，模型版本、可用性、许可证与运行成本都可能变化。实际选型与部署前，请以项目和相关模型的官方当前信息为准。