树莓派上的离线大模型，如何判断自己不该回答？

导语

当生成式 AI 被部署到工厂、车辆、边缘网关或偏远设备，网络断开不再只是延迟问题，而会直接改变系统如何更新知识、发现错误和建立信任。Hugging Face Daily Papers 收录的一项研究，以网络隔离状态下的 Raspberry Pi 5 为测试平台，运行 Qwen2.5 1.5B、3B 和 7B，并用本地检索增强生成回答 300 个 SQuAD 2.0 问题，尝试把“离线 AI 是否可信”拆解成可测量的工程环节。

核心发现

• 检索门控能发现“知识库外”问题。 经过校准的检索分数门控，对语料库外查询的识别 AUROC 达到 0.97。但面对“相关主题存在、答案却不存在”的问题，AUROC 只有 0.68。这说明相似内容并不等于可回答内容，单靠检索相似度仍可能让系统产生过度自信的回答。
• 确定性校验比额外的 NLI 验证更实用。 研究中的规则校验器会检查输出格式；当模型生成格式错误的结果时，系统将其转换为明确的拒答，而且在该实验中没有观察到正确答案损失。相比之下，测试的自然语言推断验证器带来的增益有限。
• 小模型在部分指标上更划算。 3B 模型在答案是否包含金标准信息这一指标上达到与 7B 相同的水平，但延迟和估算能耗不到 7B 的一半。另一方面，7B 更常超过 token-F1 0.5，意味着“能找到答案”与“答案表达得更完整”并不是同一个维度。
• 更多上下文未必更好。 使用五个检索段落时，正确率从使用三个段落时的 75% 降至 52%。这提示边缘 RAG 不能只追求更大的上下文窗口，噪声、冲突信息和模型注意力分散同样会降低可靠性。
• 签名验证快，但不能验证真相。 知识包签名验证约需 4.5 毫秒，而在设备上为其中段落建立嵌入约需 29 分钟。仅做签名和哈希检查时，9 种更新攻击中有 6 种仍被接受；加入单调序列号、过期、撤销和模型兼容性检查后，实验中的 9 种攻击均被拒绝。

真正的信任边界

研究最值得警惕的结果，是一个“合法签名但已被投毒”的知识包通过了所有检查，并让 30 个目标问题全部失去正确答案。签名证明的是来源和完整性，不是内容真实性。换言之，密码学机制可以回答“这个包是否被授权发布、传输途中是否被修改”，却不能回答“发布者是否把错误信息签了名”。内容审核、发布前评估和可追溯回滚因此不能被更新协议取代。

实验还暴露出部署层面的限制。研究者在 16 GB 内存的树莓派上让模型、索引和服务保持常驻，报告的查询完成时最高常驻内存约为 1.5B 的 6.3 GiB、3B 的 9.4 GiB、7B 的 13.6 GiB；研究没有报告首 token 延迟。由此得到的模型比较更接近稳定运行状态，不能直接外推到内存更小、需要频繁加载模型的设备。

意义与影响

离线生成式 AI 的安全设计不应只有一个“是否联网”的开关，而应同时覆盖检索拒答、输出格式、模型选择、知识包更新、密钥保管和内容审查。对工程团队而言，更现实的路线是：用校准门控处理明显的知识缺口，用确定性校验保证接口行为，用分层更新验证抵御回滚和不兼容包，并把已知良好版本保留为可恢复快照。与此同时，不能把“签名有效”当成“答案可信”的替代指标。

这项研究规模仍有限，测试集中于单一设备、模型系列和 SQuAD 任务，且部分安全假设依赖计数器不可重置、信任库能被安全更新等前提。但它清楚展示了离线 AI 的关键难题：系统可以在没有网络的情况下运行，却不能因此自动获得判断事实真伪的能力。 Hugging Face Daily Papers