AnyDecisionModel 和 AnySpeechRecognizer 为 Swift 应用划清语音识别与决策的边界

客服录音包含两个不同的问题。首先，应用程序必须恢复调用者所说的内容。然后，它必须决定该请求是否属于计费、技术支持或其他团队。将两者视为一个开放式对话会使应用程序的责任更难看出。

开发者 Mattt 于 2026 年 10 月 29 日介绍 AnySpeechRecognizer 与 AnyDecisionModel。这些是面向 Apple 平台开发人员的第三方 Swift 软件包：一个提供语音识别引擎的选择，而另一个则返回类型化选择和概率分布。它们建立在熟悉的 Swift 模式之上，而不是 Apple 产品公告。 Mattt的介绍 通过同一个客服通话示例解释了这两项工作。

有趣的发展是能够单独选择和评估这些工作。本指南解释了这些包的贡献、本地和托管后端如何改变应用程序的设计，以及为什么数字置信度值仍然需要相应的产品策略。

Mattt 的表情符号磁铁示例应用程序使用 AnyDecisionModel 对表情符号进行排序。作者提供的文档屏幕截图，Apache 2.0；已缩放并添加留白。 图片来源 · 许可与图片说明。

转录文本和路由决策需要单独的验收测试

想象一下，呼叫者说：“发票错误，我无法登录下载。”转录文本可以正确地重现该句子，而路由策略仍然失败。公司是否会因为发票而将其发送给账务部门，会因为登录失败而将其发送给技术支持部门，还是会因为两者都存在而将其发送给一般队列？

答案取决于服务的政策。模型不能仅通过返回强烈首选标签来提供缺失的所有权规则。在评估任何后端之前，请写下每个允许的选项的含义以及当多个选项适合时应该发生什么。这为应用程序提供了一个比“输出看起来合理”更有用的目标。

分离阶段也使得错误更容易诊断。如果识别器更改了产品名称，请保留该记录并检查是否会使用正确的单词来更改决策。如果转录文本准确但所选团队错误，请检查选择定义和决策模型。这些是不同的修复任务，将它们组合起来隐藏了故障根源。

我们的看法是，这里最有价值的抽象是识别与决策之间的边界。每个阶段都应该产生一个产物供下一阶段检查。然后，产品团队可以决定哪些阶段值得自动执行，哪些阶段应该保留为供人判断的建议。

原创流程图：识别提供证据；范围明确的决策提供分布；应用程序决定允许执行哪些操作。

当应用程序的音频发生变化时，引擎的选择很重要

AnySpeechRecognizer 的自述文件，11 月 2 日检查，描述了以 Apple 的现代语音框架为模型的 API，具有 Apple、Parakeet 和 Qwen3-ASR 选项。引擎功能有所不同：已发布的比较列出了某些路径的实时临时结果和词级时间戳，而 Qwen3-ASR 提供没有词级时间戳的分段结果。该软件包预计为 Swift 6.2 或更高版本以及 macOS 或 iOS 26 或更高版本，并且特定模型有额外的硬件要求。

这种差异在产品设计中显而易见。实时字幕显示受益于在说话者结束之前到达的文本，但它必须表明临时文字可以更改。文件导入工作流程可以优先考虑最终结果，并让用户等待录制完成处理。相同的转录屏幕不应假装两种模式具有相同的计时行为。

对于说明性采访应用程序，词级时间戳可能至关重要，因为点击句子应该跳转到录音中的相关位置。对于说明性语音收件箱应用程序，分段级转录可能就足够了，因为主要任务是审阅短消息。定义交互后选择引擎，然后使用观众实际使用的语言、口音和录音条件进行测试。

语言支持应该得到同样的待遇。支持的语言列表是一项资格检查，而嘈杂的客户录音是一项验收测试。为授权审阅者保留原始音频，并提供更正重要名称或号码的方法。在决定识别器是否需要不同的配置或者产品是否需要更好的恢复交互时，这些更正是有用的证据。

该软件包还将音频捕获留给了应用程序。这是一条有用的所有权线：应用程序仍然负责录音权限、源选择和捕获的生命周期。识别库不应被误认为是整个录音功能，特别是当 UI 必须处理中断、取消和提前停止的用户时。

类型化决策减少解析工作，但责任仍在

AnyDecisionModel 的自述文件，于 11 月 2 日检查，记录了二元概率、允许选项的选择以及有序量表的分数。它提供本地 MLX、Core AI 和 llama.cpp 路径，以及 Jev 和 Ollama 后端。 API 返回结构化结果，而不是要求应用程序从解释性段落中恢复标签。

这可以大大简化应用程序。当允许的结果是部门时，应用程序的代码可以显式处理每个部门。当问题是消息是否需要审核时，结果可以为策略提供审核状态。应用程序仍然需要定义“审核”的含义以及谁拥有队列。

一个说明性的维护报告应用程序使区别变得清晰。工作人员记录描述，识别器生成文本，决策层建议几种设备类别之一。应用程序可以在保存之前将建议与转录文本一起显示。它不应该默默地将类别建议转化为安全决定、维修命令或操作设备的许可。

有序分数需要类似的具体定义。如果团队要求三个级别的紧急程度，则每个级别都应描述一项操作或服务期望。 “低”、“中”和“高”是很容易显示的标签，但当审阅者以不同的方式解释它们时，很难评估这些标签。在分歧成为模型训练或阈值问题之前，简短的书面评分准则可以使分歧变得可见。

这种比较是关于界面设计的，而不是声称一种技术总是获胜。有些屏幕既需要限定选项选择，又需要简洁的解释。保持解释与证据的区别，并在工作流程允许的情况下保持决策的可编辑性。

置信度描述的是分布，而不是准确性保证

AnyDecisionModel 自述文件做了一个非常有用的区别：本地置信度测量答案分布的集中程度， 不是所选答案正确的概率。它还警告不要比较来自不同后端的置信度值，就好像它们共享一个公式一样。校准应基于单独的评估数据来拟合。 项目文档，2026 年 11 月 2 日检查。

假设一项说明性测试以 0.90 的概率返回一个部门，并将其余部分分配给其他部门。这表明该模型在收到的问题和选项下有利于该部门。它没有为此类客户消息建立 90% 的历史成功率。类别定义可能很差，输入可能会忽略关键上下文，或者模型可能系统地更喜欢一种选项。

因此，有用的产品政策需要明确的“等待审查”路径。从审阅者可见的所有决策开始并收集更正。然后评估任何子集对于狭义定义的自动操作是否足够可靠。阈值是观察到的错误和这些错误的成本的结果，而不是因为看起来有信心而选择的数字。

评估集应包含不明确的消息、不熟悉的名称以及没有可用部门适合的情况。当每个示例都适合一个明确的类别时，系统可能会显得很强大，但在主导实际支持工作的混合请求上却失败了。让审阅者记录他们更改选择的原因，以便团队可以区分错误的模型答案和缺失的策略。

还要检查每个错误方向的成本。把普通请求送去复核会消耗时间；悄悄地将敏感请求发送给错误的受众可能会产生不同的后果。单一平均分掩盖了这种差异。报告对产品所有者重要的案例，然后选择他们可以向用户和维护人员解释的操作策略。

这也是为什么更改后端是产品更改的原因。相同的 Swift 调用可以隐藏不同的行为、数字语义和操作依赖性。在将旧阈值引入新配置之前重新运行评估。将模型标识符、配置和选项定义与结果一起保留，以便以后的审查可以解释决策是如何产生的。

原创示意图：强烈的偏好并不能消除评估正确性或定义操作策略的需要。置信度和准确性回答不同的问题。

本地操作改变了团队拥有的工作

在设备上运行模型对于语音收件箱或离线参考工具来说可能很有吸引力。团队可以围绕本地保留的输入和可预测的网络边界进行设计。但模型下载、支持的硬件、内存使用和首次运行准备成为用户体验的可见部分。隐私承诺应描述整个路径，包括后来添加到应用程序的任何托管阶段。

托管决策后端将一些操作工作转移到服务中，同时将网络行为、凭证和服务可用性引入流程中。当请求失败或保持待处理状态时，用户需要一个可理解的状态。重试应保留原始记录，并且不应意外重复已完成的下游操作。

当前的项目文档还区分了测试兼容性和实时服务验证。 AnyDecisionModel 表示 Jev 和 Ollama 协议兼容性测试使用固定测试样例。这是很有价值的测试覆盖范围，但要交付的应用仍应端到端验证其选定的服务配置。 AnyDecisionModel README，11 月 2 日检查。

避免承诺开发者使用的 Mac 和支持的最小手机具有相同的性能。部署目标说明代码打算在哪里运行；它不提供每个设备的延迟、电池或内存证据。应用程序可以从一台合格机器上的文件处理开始，然后在预期的交互在其他硬件上得到验证后扩展其支持范围。

从可审查的文件工作流程开始

初次试点应该使错误易于检查。基于文件的小型应用程序通常是比实时助手更清晰的起点，因为可以重播和比较相同的获准使用的音频。目标是在添加实时交互之前验证各个阶段及其交接。

1. 使用允许决策的简短列表和针对不明确情况的书面规则来定义一项任务。在应用程序的策略中包含审核选项。
2. 检查当前的包要求并添加相关的 Swift 包依赖。选择一种识别引擎和一种决策后端，而不是一次对每种组合进行资格认证。
3. 导入一小组授权录音。将原始文件、预期转录文本和审阅者决定保存在单独的记录中。
4. 按照包文档明确安装或暂存所需的模型资产。将准备和处理显示为不同的 UI 状态。
5. 运行识别，保留最终文本，并询问有关该文本的有限问题。将结果与源一起显示，而不是立即执行外部操作。
6. 分阶段检查错误，然后在进行更改后评估一组单独的记录。记录每个结果的配置。
7. 在扩展到实时捕获或自动路由之前添加取消、不可用模型和网络故障行为。

成功标准应该是产品所有者可以理解的。例如，语音收件箱试点可能要求审阅者可以找到源录音、更正转录文本并更改建议的队列，而不会丢失任何原始材料。即使在团队决定实现任何自动化之前，这也是一个有用的工作流程结果。

小决定仍然值得完整的产品设计

这些包提出了一个有吸引力的架构主张：使用一个组件来收听，使用另一个组件来选择，并使用应用程序代码来强制执行允许的操作。这就创造了衡量质量的地方和从失败中恢复的地方。它还使得数字答案的限制更容易与必须信任它的人讨论。

值得测试的期望是可维护性。团队可以在不重写整个应用程序的情况下更换识别器吗？它可以在不假装旧阈值仍然适用的情况下评估新的决策后端吗？用户能否在实际发生错误的地方纠正结果？

当一个小模型的工作很明确并且它的输出有一个负责任的所有者时，它就会变得有用。 Swift 抽象有助于连接各个部件；产品的决策策略为这些部分赋予了目的。

来源

• Mattt：介绍AnySpeechRecognizer和AnyDecisionModel，2026 年 10 月 29 日。
• AnySpeechRecognizer：要求、引擎比较和示例，于 2026 年 11 月 2 日检查。
• AnyDecisionModel：后端、校准和限制，检查于 2026 年 11 月 2 日。软件包代码许可证和单独模型许可证需要单独考虑。
• Mattt：表情符号磁铁文档和屏幕截图, Apache-2.0 文档； 2026 年 11 月 2 日检查。

保持实施决策与其源头的联系

Telli.sh 是保留授权源材料和实施决策背后的注释的一种选择。 创建笔记工作区。