LiteRT-LM 对话模板校验：按准确制品检查渲染边界

直接回答

对话模板预检是在发行或升级前，检查应用消息如何序列化给准确模型制品的边界。它要验证代表性的 Message 是否按预期渲染出角色、内容、控制标记、前缀和回合结束方式。这不是翻译或推理质量测量；可读的渲染字符串也不能证明已解析的 Android 依赖含同一 API，或真机任务一定成功。开始前应记录模型修订、分词器/模板身份、Gradle 实际解析的运行时组件、应用构建，以及该模型家族要求的输入格式。 Gemma 4 定义了特定于其分词器的字面角色名和回合标记。测试样例必须来自所选代际和制品的权威格式说明，不能从抽象的应用角色名、不同代 Gemma 或博客示例猜模板。使用 Gemma 4 格式时，应按文档字面核验 system、user、model 角色名、起始标记 <|turn> 和结束标记 <turn|>。开放生成前缀使用文档中的 <|turn>model；已完成的历史 model 回合使用规定的回合结束标记。只有产品路径确实有 system turn 时才加入；纯文本测试不要混入未验证的工具或多模态标记。 固定提交的 LiteRT-LM Kotlin Conversation 源码提供一个标记为 Experimental 的 renderMessageIntoString 辅助方法。只有先从已初始化的 Engine 创建 native Conversation、且该实例仍存活时，才能对准确 Message 和可选 extraContext 用它做诊断观察。方法会检查 conversation 状态；实例关闭或 native 渲染失败时可能抛错。它不保证所有发行制品或当前项目解析依赖都提供此 API。上游 commit 只是源码快照，不能证明应用 Gradle 最终解析到哪个版本。 常规 send API 接受 Message、Contents 或 text 与 extraContext，然后把消息表示交给 native runtime，由其处理提示模板渲染。不要把诊断生成的渲染字符串当普通消息文本再次提交，除非 API 契约明确声明入参已序列化；否则可能二次包装角色标记，或将可见控制标记当成普通内容。相反，也不要手工拼接字符串后就假定 native runtime 会按相同字节保留它。应把 typed send 路径与诊断渲染辅助方法分开测试。 预检夹具应小、合成且结构明确。可以覆盖一个 user 回合、一个已完成 model 回合后接新 user 回合、开放的 <|turn>model 生成前缀、可选 extraContext，以及以 <turn|> 结束的完整回合。对文档中的字面角色顺序、前缀开闭状态和结束标记设断言，并将夹具绑定到模型与模板版本。手工拼出的 golden string 只是测试输入，不是 native 模板输出的实测证据；须在测试中与存活 native Conversation 的 helper 渲染结果比较。 测试不应持久保存或记录真实提示词。渲染文本可能包含私人用户内容、系统指令或任务上下文，因此只用合成消息，并限制诊断输出。报告记录制品和模板标识、夹具编号、结构断言、观察到的渲染、已解析依赖坐标和结果即可。如果依赖版本缺少该 helper，或实验性 opt-in 无法使用，应通过文档支持的 typed send 路径和受控 native fixture 进行验证，或明确记录限制；不要把应用层手工拼接字符串伪装成真实运行时渲染结果。 按层解释失败。如果角色或标记错误，可能是应用序列化或格式预期问题；如果渲染夹具正确但 native send 失败，则应调查另一个边界，如依赖/API 可用性、模型加载或运行时行为。输出流畅或混乱本身不足以证明模板不匹配，必须对照实际请求和该模型格式。不要在同一实验中调整采样、替换分词器或切换制品。最终结论只对一个已命名配置的格式校验有效，不代表模型能力，也不构成设备基准。

固定模型准备升级 LiteRT-LM 依赖

Android 团队升级了 Gradle 实际解析的 LiteRT-LM 依赖，但模型家族名称没有改变。应用使用 typed Message 和 extraContext 发送多轮会话。一份近期成功记录来自较早的依赖版本，开发者考虑在发送前手工渲染提示词，以便更容易检查新输出。

决策

先核实当前解析依赖实际提供哪些方法，再用小型合成对话检查实验渲染辅助输出；随后通过 typed send 路径测试，不把已渲染字符串重复包装。

预期结果

发行记录写明依赖、制品与模板版本、结构夹具和观察到的阶段；不会声称上游源码快照等于应用依赖，也不会把模板校验说成设备支持或任务质量证明。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• LITERTLM-01：LiteRT-LM 使用自己的模型打包与 API，不等同于 GGUF。
• COVE-MODEL-02：当前模型配置的 SHA-256 字段为空，不能宣称模型制品已通过摘要验证。

只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。

实施流程

1. 固定准确输入与解析 API. 记录模型制品和分词器修订、提示模板版本、应用构建，以及 Android 运行时的实际解析坐标。引用 renderMessageIntoString 或 cancel 方法前先检查解析后的 class 方法；上游提交链接不证明 APK 中包含相同接口。
2. 将官方格式转换为结构断言. 针对准确模型代际，从官方格式文档抄录字面角色名和控制标记。Gemma 4 要核对 system/user/model、<|turn>、<turn|> 和开放的 <|turn>model 前缀；没有来源依据时不要把应用层 assistant 角色名替代成模板字面角色。
3. 创建最小合成消息夹具. 使用一轮、两轮示例、已完成的历史 model 回复、文档定义的开放 model 生成前缀以及单独的 extraContext 场景。手工拼出的期望字符串不是运行时观察值；在受控测试中与存活 native Conversation 的渲染结果比较。
4. 只在测试路径检查诊断渲染. 如果解析类提供 Experimental 的 renderMessageIntoString，在受控测试中 opt-in 并确认 conversation 仍存活。将结果与结构断言比较；方法可用或字符串看起来合理，都不能证明应用依赖与制品组合得到支持。
5. 单独执行真实 typed send 路径. 通过文档中的 send 或 sendAsync overload 提交 Message 及预期 extraContext。不要把渲染夹具再作为 user text 输入，也不要手工重复添加角色标记。分别记录 native 调用是否开始、是否到达终态，不与渲染断言混为一项。
6. 对比差异但限制结论范围. 发现夹具差异时，每次只变更一个版本化输入并保留旧记录。只有证据能区分时，才将问题归因于序列化、依赖 API 可用性、模型加载或任务输出。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 记录固定 Android 实际解析运行时和准确制品/模板身份；不能以某个上游源码快照推断依赖 API。
• 合成夹具按所选代际的官方格式断言角色顺序、前缀与回合结束行为，诊断不含私人提示词。
• 普通 typed send 路径与实验渲染分别验证；不会把已渲染消息再次套用模板。

决策对照表

需要避免的失败模式

• 从另一代模型复制角色标记或模板
• 把实验渲染输出当成正常发送入参
• 根据上游源码快照推断 Gradle 实际解析了相同 API

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• LiteRT-LM repository
• 固定提交的 LiteRT-LM Conversation.kt：typed send、实验渲染与取消 API
• 同一固定提交的 LiteRT-LM Kotlin 入门文档
• Google AI for Developers：Gemma 4 提示格式

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题