任务架构

端侧批量翻译设计:逐项保存、取消与部分导出

将文档集合拆成有稳定身份和独立状态的本地翻译项目。

审核状态: 内容已校验;中文稿供用户审核 · 2026-10-06 · Fact IDs: ARCH-01, THERMAL-01

直接回答

可靠的端侧批量翻译应是许多独立项目的协调器,而不是把所有文件塞进一个超大提示词。为每项输入分配稳定标识,并保留来源、目标语种方向、来源修订和输出状态。工作按符合实际运行时契约的有限单元推进;完成一项后先保存结果,再开始下一项。这样才能明确表示部分成功:如果第 18 项失败,应用可以展示前面哪些已完成、后面哪些仍在排队,而不是丢掉整个批次或把不完整导出伪装成完整结果。 批次状态和单项状态应分开。批次可以排队、运行、暂停、已取消、部分完成、失败或完成;单项则可以待处理、翻译中、需审核、完成、失败或因原因跳过。取消时应停止安排新项目,并按运行时契约请求当前推理取消;不能把已完成结果改成失败,也不能因为界面关闭就断定原生操作停止。如果产品承诺进程重建后可继续,还需保存足够状态以安全恢复。 分块策略应依据应用限制和模型接口设计,不要套用普遍文件长度阈值。文档通常需要按结构切分;任意字符数切块可能把标题、表格单元或影响含义的上下文拆开。保留块顺序和源文位置,记录边界,并给合并结果留审核步骤。不要悄悄删除格式、引用或未翻译片段。可以建议如何采集资源证据,但没有真实设备运行数据时,不能给出最大文件大小、吞吐量、完成时间、热状态或耗电估计。 重试应针对单个项目并有条件分类。只对明确的暂态或可由用户修正的问题重试,保留原失败记录,不要自动无限循环。重复请求不能生成重复导出行,也不能丢失先前结果的溯源。每项结果应关联模型制品修订、提示词修订、运行时身份和解析器版本以便后续审核。事实缺失时标未知,不要把所有历史结果都归给当前模型。 部分导出应附带项目编号、顺序、状态和未纳入项清单,并明确显示“部分完成”,不能把失败项替换成空译文。若用户编辑了结果,要区分模型原始输出和人工审核后的译文。如果导出格式无法表达部分状态,就让用户重试、单独导出完成项或取消;不要静默生成一份看起来完整的文件。 离线优先设计意味着本地数据源可以在无需远程推理请求时支持功能,但本地执行不自动保证所有输入文件都可读取、每个语种方向都受支持或每项任务都能完成。测试时要覆盖网络阻断、新批次、进程中断、资源缺失、取消和部分失败。Android 热状态 API 可在支持的系统版本观察平台信号,但它不等于模型速度测量,也没有普遍适用阈值。只报告确实采集到的准确工作负载和设备观察结果。

用户在登机前排入一批文件

用户连接网络时选择了一组旅行文件,希望登机后再翻译。其中一个文件格式不受支持,后续一项推理被取消,用户也可能在批次运行时关闭界面。应用必须保留已完成项目,并清楚说明剩余工作,而不能承诺完成时间。

决策

把操作表示为有顺序、逐项可恢复的批次;启动前检查本地输入,并在批次和单项两个层面明确显示取消、重试和部分导出状态。

预期结果

用户可以使用已完成译文,重试或跳过失败文件,并看到哪些项目仍未完成。应用不会推断吞吐量、耗电结果或普遍离线支持。

需要收集的证据

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

  • ARCH-01:端侧 AI 指推理在用户设备上执行,不代表所有准备步骤都不需要网络。
  • THERMAL-01:单次成功不能证明持续表现,也不提供未经测量的性能数值。

任务质量需要有版本记录的语料和验收规则;流畅的单条样例不等于准确度结果。

实施流程

  1. 创建稳定的批次清单. 为每个来源分配稳定编号、顺序、内容修订或安全摘要、格式和目标方向,并记录所选本地制品。只有确有需要时才保存文件名等元数据;不要把私人文档正文写入诊断日志。
  2. 校验输入并规划有界任务. 确认每项输入可读取和解码,在昂贵工作开始前识别不支持格式;只在产品能够还原的结构边界分块。保存块顺序和源文位置;没有设备证据时不要承诺普遍最大容量。
  3. 随进度持久化单项结果. 每项输出完成后先保存,再推进下一项。待处理、运行中、需审核、完成、失败和跳过状态独立于批次状态保存,使进程中断不会抹去部分成功。
  4. 实现取消与定向重试. 批次取消后停止新任务,并把停止请求传给当前推理的实际所有者。只有明确分类后或用户操作时才重试,保留上次记录,并用稳定结果键防止导出重复。
  5. 生成诚实的部分导出并安排审核. 导出清单包含项目顺序和状态;未完成批次标记为部分结果,并允许单独导出完成项或重试失败项。模型原始文字与用户编辑或审核后的译文分别表示。
  6. 离线与持续流程测试不靠猜测. 使用合成文档测试网络阻断、资源缺失、应用重建、任务中断和部分失败。任何测量都记录设备、制品、运行时、工作负载和可获得的热状态信号;没有实测就不写速度、耗电或温度结论。

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

验收标准

  • 每个选中项目都有稳定编号、顺序、语种方向和明确状态;不支持的输入仍可见并附原因。
  • 取消会停止后续调度并请求取消当前工作,同时保留已完成结果和先前尝试记录。
  • 导出能标明部分完成和遗漏项;所有性能或热状态说法都严格对应真实记录的运行。

决策对照表

维度选择或证据解读方式
一个大提示词把所有文档作为一次请求发送初期实现简单,但很难证明逐文件恢复、顺序、取消和部分导出的行为。
逐项协调器对有限任务逐项处理并持久化状态可以明确显示部分成功和定向重试,且并发策略较容易验证。
并行批次工作器同时处理多项独立内容在受测配置下可能提高利用率,但增加内存、取消、顺序和原生运行时协调要求;不能预设会更快。

需要避免的失败模式

  • 把整个文件夹塞进一个大提示词
  • 关闭页面就声称原生任务一定停止
  • 把未完成项目混进看起来完整的导出

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

最小复现记录

层级记录内容
设备厂商、型号、芯片、内存档位、操作系统版本
软件应用版本和 Git 提交号
模型系列、变体、版本、格式、文件长度、摘要、量化方式
运行时名称、版本、请求后端及实际后端证据
工作负载样例版本、输入摘要、提示词摘要、输出策略
结果完成、失败、取消、回退及保护隐私的诊断信息

发布检查表

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

来源与相关证据

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

常见问题

为了省事,应该把每份文档都放进同一个提示词吗?

这样会难以隔离格式错误文件、单独重试一项或导出已完成结果。有限任务协调器可把来源身份、顺序和失败状态始终保留在单项上。

取消批次就能保证原生推理停止吗?

不能。应用必须通过实际运行时所有者传递取消,并观察任务结束或资源清理状态。关闭界面或取消协程订阅本身不能证明原生工作已停止。

能否根据这个流程公布预计完成时间?

没有按指定设备、制品、运行时、输入分布和热状态重复测量时不能。设计指南可以规定记录方法,但不能填补缺失的基准结果。