Apple基础模型为何需要确定性计算层：MetricBridge的实践

Apple的Foundation Models框架为iOS应用提供了一个免费、离线运行的30亿参数模型，每个会话拥有4096个token的上下文窗口。这是扎实的基础设施，其隐私特性也货真价实。但它所能提供的，与"这个应用能展示它的计算过程"是两码事——而当下不少应用正悄悄把这两者混为一谈。

语言模型不会做算术

语言模型的本质是预测下一个token，它并不执行算术运算。让它计算七个数值的平均值，它会输出一个"看起来合理"的字符串，因为这类合理的字符串曾出现在训练分布中。连续运行两次，你可能分别得到49.6和49.8——两个结果都能通过schema校验，但没有一个是你数据的真实函数。

这正是问题的核心。schema校验只验证输出格式是否合法，却无法保证数值的正确性。对于健康数据、财务指标这类需要精确计算的场景，一个"看起来对"但实际随机波动的数字，比明确的错误更危险，因为它披着可信的外衣。

这一现象在技术上被称为"幻觉"（hallucination），但对于数值计算场景，用"随机采样"描述更为精确。语言模型在推理时，即便采用贪婪解码（greedy decoding），其数值输出也受温度参数、注意力机制的浮点舍入以及底层硬件的细微差异影响，同样的prompt在不同调用间可能产生不同结果。更根本的问题是，模型对数字的"理解"是基于token序列的统计共现，而非符号逻辑。例如，"49.6"在模型内部只是一串字符token，它无法区分这个数值是来自对输入数据的真实计算，还是从训练语料中见过的类似上下文里"借"来的。这意味着即便某次输出碰巧正确，也无法保证下一次同样正确，更无法追溯其计算来源——而可追溯性恰恰是数据应用建立信任的核心。

把计算交给确定性层

框架自带的Tool protocol其实已经指明了正确方向：不要让模型去计算，而是让它调用某个负责计算的组件。

在MetricBridge项目中，这一思路落地为AskEngine.swift——一个纯粹的计算层。它将用户的问题解析为16种工具调用之一，解析出指标名称，在你记录的数据行上执行聚合运算，最终返回一个名为ComputedFacts的结构体。

这个结构体承载了相当完整的信息：规范化的指标名称、单位、范围标签、真正有数据的天数、原始的（日期，数值）数据行、核心聚合值及其标签，以及一个变化方向。模型从头到尾不计算任何数字，它只负责接收一份简短的摘要，然后把它"措辞"成人话。

Apple Foundation Models框架中的Tool protocol允许开发者将外部函数注册为模型可调用的工具，模型负责判断"何时调用哪个工具、传入什么参数"，而实际的执行逻辑完全由开发者控制的Swift代码完成。这与OpenAI的Function Calling、Anthropic的Tool Use在设计哲学上一脉相承：将LLM的自然语言理解能力与确定性的程序逻辑解耦。关键区别在于，工具调用模式下，数值的"生产者"是代码而非模型——模型只做意图解析和结果措辞，计算本身由有单元测试、可审计的函数完成。这使得整条数据链路具备了可复现性：相同的输入必然产生相同的输出，错误可以被定位到具体的代码行而非笼统地归结为"模型行为"。

两个诚实字段的设计巧思

ComputedFacts中还藏着两个值得称道的"诚实字段"，它们体现了对数据如实呈现的克制。

第一个是coverageDays，与dayCount并列存在。这样即便返回的是"最近一次数值"，答案也能反映整个序列的覆盖情况，避免以偏概全。

第二个是unevenWindows。当两侧比较的记录天数不同时，它会明确标注出来，而不是把跨度总和与按天计算的速率并排打印，制造误导性的对比。这种对数据局限性的主动暴露，恰恰是"展示计算过程"的真正含义。

可复现验证：字节级一致的证据

项目在仓库中提交了一个脚本bench_deterministic_layer.py，用来佐证"模型不参与计算"这一主张。它会构建一个带随机种子的30天HRV（心率变异性）序列，并打印一张"溯源卡片"。

卡片显示：核心数值49.6毫秒（7天平均），相比前14天（均值42.6毫秒）上升16.3%，dayCount为7，coverageDays为30。

关键在于可复现性：连续运行两次，输出字节级完全一致，两次的sha256哈希值均为f2e87621b46b2fe04cd81a86cb2183ed2e271237ca8d23b9123171445359d9d7。卡片末尾写着一行点睛之笔——"由计算层产出的数字：5个，由模型产出的数字：0个。"

这种可验证性正是确定性层相较于纯LLM方案的根本优势。同样的输入永远得到同样的输出，这是任何需要信任的数据应用的基石。

sha256哈希校验在这里扮演的是"数学证人"角色：两次独立运行产生完全相同的256位哈希值，在概率上等同于输出的每一个字节都完全一致。这是软件工程中验证确定性（determinism）的标准手段，常见于构建系统（如Bazel的hermetic builds）和密码学应用中。对于AI应用而言，这种验证方式尤具说服力，因为它用一个可公开检验的数字证明了"模型零参与计算"的主张——任何人拿到同一脚本和随机种子，都能在本地复现同一个哈希值，无需信任作者的声明。这与仅依赖单元测试的方式形成互补：单元测试验证逻辑正确性，而哈希一致性验证的是跨运行环境的输出稳定性。

可溯源不等于诊断

作者在文末划下了一条重要的边界：以上所有机制都不构成任何诊断或监测。

当某个指标偏离你近期的范围时，诚实的说法是"偏离你的个人基线"，而绝不是"异常"。能够追溯一个数字的来源，并不意味着它就是一个诊断结论。这种措辞上的审慎，与整个确定性设计一脉相承——技术上的可信度不应被过度延伸为医疗层面的权威。

对于AI应用开发者而言，这个案例提供了一个清晰的架构范式：让LLM做它擅长的事（理解意图、组织语言），把需要精确和可复现的部分交给确定性代码。隐私和离线能力是基础设施层面的优势，而"展示计算过程"则需要架构层面的刻意设计，两者不能混为一谈。