手机端小模型如何把口述转成联系人

把一句「Dave 的妻子 Jen 在 3 月 3 日满 40 岁，儿子 Leo 6 岁」变成人物卡片，难点不只是识别人名，还要理清关系、保留年龄，并处理口述里的省略和纠正。生日提醒应用 Circles 给出的方案是：用一个 270M 参数的小模型，在手机上专门做这件事。

作者报告，经过完整微调的 Gemma 3 270M，在 Pixel 8 Pro 的 CPU 上约 1 秒就能完成一次提取。这篇最值得读的，是他们怎样把一个通用模型问题，收窄成可训练、可校验的产品任务。

为什么通用模型能答对，却不适合直接上线

Circles 按人物及其家庭关系组织生日信息。用户录入一个家庭，原本要逐人填写姓名、关系、性别和日期，口述显然更省事。

云端 LLM 能在几秒内解析，但这些内容涉及孩子姓名、年龄和婚姻关系。Circles 没有账号和服务器，作者希望继续保持这个结构。端侧运行还带来离线可用、每条笔记没有云端推理费用的好处。

第一次尝试用的是 Gemma 4 E2B，配上任务指令、4 个示例，以及用于约束解码的 JSON schema。在 50 条笔记的测试集上，95% 的字段正确。

准确率看着不错，等待时间却太长：Pixel 8 Pro 上，GPU 约需 11 秒，CPU 约需 21 秒。约 1,100 token 的提示词，GPU 读取只花约 1.2 秒，真正拖慢体验的是生成阶段，每秒约 10 token。

缩短提示词不足以解决问题，输出生成才是当时的主要瓶颈。

作者还试过更小的现成模型，但有些社区版本连简单问题都返回空字符串，另一个在超过一半的笔记中生成损坏的 JSON，并持续循环到 token 上限。这个结果只能说明他们试过的版本不合适，不能推成所有小模型都不行。

270M 模型怎样把等待压到 1 秒

他们改用 Gemma 3 270M 做完整微调，让模型只学一种映射：口述笔记进去，紧凑 JSON 出来。

训练数据由生成器合成，共 18,000 条，覆盖英语、西班牙语和俄语。训练使用 MLX，在 MacBook Air（M5、16 GB）上跑了 3,400 步，约耗时 40 分钟。

推理时只输入笔记，不再附加指令和示例；输出省去空字段。运行时使用 LiteRT-LM，模型量化为 int8，文件大小 296 MB，在 CPU 上执行。

同一台 Pixel 8 Pro 上，作者报告平均每条约 1 秒，90 分位耗时为 1.2 秒，生成速度约每秒 46 token。训练后新写的 30 条留出笔记中，结果是：

• Gemma 4 E2B 加指令和示例，17 条完全正确，GPU 每条耗时 10.7 秒。
• 微调后的 Gemma 3 270M，21 条完全正确，CPU 每条耗时 1.0 秒。

这里的「完全正确」与前面的「95% 字段正确」不是同一个指标。一条笔记里只要错一个字段，就可能无法算作整条正确。

作者把 CPU 运行视为产品优势，因为这条路径不依赖旗舰 GPU 或 NPU。不过，原文没有提供其他档位手机的实测结果。

真正反复修改的是数据生成器

这套方案最有参考价值的部分，是错误怎样变成训练数据。

早期模型能找到 Jen，却丢掉下一句「他们的儿子 Leo」。原因很具体：训练数据没有覆盖跨句表达。加入两句、三句笔记后，多句测试中完全正确的数量从 5/24 提升到 17/24。

口述转写又是另一种输入。它可能没有逗号，数字可能写成阿拉伯数字或单词，还会出现填充词和「七号，不对，八号」这样的纠正。作者将三分之一的数据改成这种形式，再用手机实际转写出来的内容训练，真实口述测试从 6/15 提升到 13/15。

俄语还涉及姓名变格：句子里的名字形式，未必就是应该存入人物卡片的形式。生成器因此加入姓名、父称和昵称的变格处理。

另一个遗漏是主体本人。模型原先只提取主体周围的人，会丢掉主体自己的年龄。作者在答案结构里加入 self 标记来修正。

训练方式也有影响：从头训练新数据组合，模型学会了新模式，却退步于普通笔记；从上一版模型继续训练，并使用较小学习率，才保住两边表现。当前版本在真实口述测试中达到 14/15，在模拟口语测试中达到 24/24。

作者的经验是，改进主要来自数据覆盖，而不是训练代码。

他们的循环是新写测试集、分析错误、修改生成器、重新训练，再用下一批新测试检查。

我的判断

我认同这里的职责划分：模型负责提取，应用负责确定性处理。

Circles 会根据年龄计算出生年份，丢弃原话没有提供的年龄，匹配已有姓名、合并重复人物，并生成符合语言习惯的关系称呼。保存之前，用户必须检查卡片。作者称四分之三的笔记无需修改，其余通常只需改一个字段，但没有交代这项统计的样本规模。

这比让模型直接决定最终存储结果更容易控制。不过，规则也有边界。仅凭年龄推算出生年份，要考虑当年的生日是否已过，原文没有讲清这部分如何处理。

小模型胜出的结论也需要带着条件看：任务很窄，输出结构固定，而且作者能为三种语言编写数据生成器。30 条留出笔记和 15 条真实口述笔记能支持继续迭代，还不足以证明它在复杂家庭关系、长笔记或其他语言上同样可靠。原文也没有给出学习率等完整配置，训练经验不能直接当作复现配方。

部署成本同样存在。296 MB 模型没有塞进应用安装包：Android 使用按需 Play Asset Delivery，iPhone 使用 Apple 托管的 Background Assets，后者要求 iOS 26.4 及以上。首次打开口述功能才下载，能避免未使用者承担体积，但首次使用仍有等待。

能拿来做什么

• 做类似结构化录入时，可以先用通用模型建立基线，同时记录字段正确率、整条正确率和真实设备耗时，再判断是否值得微调小模型。
• 为口述输入准备测试时，应覆盖跨句指代、数字写法和中途纠正，并收集实际语音转写结果，不能只测试整理过的书面句子。
• 在前端人物卡片中保留保存前确认，把日期计算、重复合并和已有数据匹配交给应用规则处理。
• 接入端侧模型前，应把首次下载、离线可用范围和设备支持一起纳入交互设计。Circles 免费支持最多 10 个圈子，口述属于 Pro，模型下载也是这项功能体验的一部分。