离线急救助手HandsOnAid:手机端小模型实测

HandsOnAid 用 4-bit Gemma 2B 微调实测离线急救 AI,最佳仅 2.51/5,揭示能力边界与数据短板。
HandsOnAid 项目在无网络、无云端支持的条件下,用 4-bit 量化的 Gemma 2B 模型结合 QLoRA,在 5,550 条 FirstAidQA 急救问答上微调,并在真实手机上评测其响应速度与答案质量。研究横向比较七种配置,采用四模型盲评加医学专家交叉验证、12 条安全否决项的评测体系。结果显示微调带来 +1.08 的平均分提升,但最佳配置(4-bit 微调加检索)也仅得 2.51/5,绝对水平偏低。Pixel 7 Pro 纯 CPU 断网下首字延迟 6.86 秒、完整回答 14.88 秒。关键词审计进一步指出,训练语料对 ANZCOR 指南细节覆盖不足,数据缺失可能是低分主因。
在无信号、无救护车的偏远场景里,一部手机和一个小模型能否承担急救咨询的角色?HandsOnAid 这个项目给出了一个可测量的答案。研究团队用 4-bit 量化的 Gemma 2B 模型,在 FirstAidQA 数据集上做 QLoRA 微调,并在真实手机上测试了响应速度与答案质量。结论并不完美——最佳配置的评分仅为 2.51/5——但它清晰地揭示了「离线急救 AI」当前的能力边界,以及训练数据覆盖度对安全性的决定性影响。
方案设计:小模型、低比特与检索增强
HandsOnAid 的技术路线很务实:选择 Gemma 2B 这样能在手机端跑起来的模型,用 4-bit 量化压缩显存占用,再通过 QLoRA 在 FirstAidQA 的 5,550 条急救问答对上做参数高效微调。这一组合的核心诉求是——在断网条件下,用消费级硬件提供可用的推理能力。
研究团队并未止步于单一模型,而是横向比较了七种配置:基础模型、4-bit 与 8-bit 微调版本,以及叠加长度下限(length floor)、安全门控(safety gate)、检索增强(retrieval)的变体。其中「长度下限」用于避免过短、信息不足的回答;「安全门控」试图拦截高风险建议;「检索」则从知识库中调取相关内容辅助生成。这种多配置对比的做法,比只报告一个最优结果更能说明各组件的实际贡献。

QLoRA(Quantized Low-Rank Adaptation)是一种参数高效微调技术,它将 4-bit 量化与 LoRA 结合:基座模型的权重被冻结并以低比特存储,训练时只更新注入到各层的小型低秩适配矩阵。这样可将微调所需的显存降低一个数量级,使得在单张消费级显卡甚至部分边缘设备上微调十亿级参数模型成为可能。QLoRA 的关键设计还包括分页优化器与双重量化,用于进一步压缩优化器状态和量化常数的开销。在本项目中,QLoRA 让团队无需全参数微调即可把急救领域知识注入 Gemma 2B,同时保持部署时的 4-bit 推理格式。
FirstAidQA 是面向急救问答的指令微调数据集,包含 5,550 条问答对,覆盖心肺复苏、止血、烧伤处理等常见急救场景。其构建通常从权威急救指南与教材中抽取知识点并改写为自然问答形式,因而答案风格偏标准化、步骤化。数据集的质量与覆盖广度直接决定模型能学到哪些急救细节,这也是后文关键词审计发现覆盖不足时,低分可能源于数据而非模型的重要背景。
评测方法:四模型盲评与医学专家交叉验证
急救领域的评测难点在于「安全」很难用自动指标衡量。HandsOnAid 的做法是构建一个 41 对的问答库,参考答案经过医学审核并遵循 ANZCOR 指南,同时采用严格的 0-5 分评分标准,并设置 12 条安全否决项——触及即扣分。
评分环节引入了四个前沿模型作为盲评裁判:GPT-5.6 Sol、Claude Opus 5、DeepSeek广告 V4 Pro 和 GLM-5.3,每条回答由它们独立打分。为检验裁判可靠性,还埋入了 45 条隐藏对照项。更关键的是,一位医学专业人士对基础模型、4-bit 微调版和检索配置下的 40 条回答做了盲评,结果与四个模型裁判的平均分接近。这一交叉验证提升了评分的可信度:LLM 裁判在急救问答上的判断,与人类专家的方向基本一致。
ANZCOR 指南指澳大利亚与新西兰复苏委员会(Australian and New Zealand Committee on Resuscitation)发布的急救与复苏临床指南,涵盖基础生命支持、心肺复苏按压深度与频率、AED 使用、窒息与出血处理等标准化操作建议。它是澳新地区的权威急救参考,也被广泛用于急救培训与考核。本项目以 ANZCOR 指南作为参考答案与评分标准的依据,意味着模型的回答需要与这些具体、可核查的操作细节对齐;评分标准中要求的细节若在训练语料中缺失,模型便难以在评分中得分。
安全否决项(safety veto)是高风险领域评测中的一种硬性规则:当回答包含可能直接导致伤害的建议(如错误的按压位置、延误呼救、危险的家庭处理方式)时,无论其余部分质量如何,该条回答都会被判定为不安全或大幅扣分。它弥补了平均分制对「少数致命错误」不敏感的缺陷,使评测更贴近急救场景中「一次错误即可能致命」的现实。
结果解读:微调有效,但绝对水平仍偏低
数据给出了两个层次的结论。积极的一面是,微调带来了 +1.08 的平均分提升,基础模型的平均分升至 2.34。这说明即便只有 2B 参数、4-bit 量化,领域微调仍能显著改善回答的相关性和针对性。
但绝对分数并不乐观:最佳配置——4-bit 微调加检索——也只拿到 2.51/5。换言之,即便叠上检索增强,系统给出的急救建议仍处在「部分正确、需要谨慎对待」的区间,离可靠的安全咨询还有明显距离。
团队进一步做了关键词审计,发现问题可能出在数据侧:训练语料对 ANZCOR 指南中若干评分标准所要求的细节覆盖有限。这指向一个容易被忽视的结论——低分未必是模型能力不足,而可能是训练数据里根本没有这些信息。对急救这类高风险领域,数据覆盖度的审计应当与模型调优同等重要。
端侧性能:首字延迟与完整回答耗时
离线可用性的另一半是速度。在 Pixel 7 Pro 上,使用六个 CPU 线程、完全断网的条件下,4-bit 微调模型在十道问题上的平均表现为:首个可显示文本耗时 6.86 秒,完整回答耗时 14.88 秒。
这组数字需要放在急救场景里理解。十几秒的等待在紧急情况下并不算短,但考虑到设备完全离线、没有云端算力支持,这个延迟已经落在「可用」的边缘。首字延迟不到 7 秒意味着用户能较快看到系统开始响应,这对缓解焦虑有实际意义。当然,纯 CPU 推理的功耗与发热,以及更长、更复杂问题的耗时表现,仍是实际部署前需要考察的维度。
首字延迟(time to first token, TTFT)指从用户提交问题到模型输出第一个可显示 token 所需的时间,是衡量交互响应感的核心指标;完整回答耗时则反映生成全部内容的总时延,与输出长度和每秒 token 生成速率直接相关。在端侧纯 CPU 推理中,这两个指标受模型参数量、量化精度、线程数与内存带宽共同制约。对急救场景而言,TTFT 决定用户是否感到系统「有反应」,而完整耗时决定用户多久能读到完整步骤,二者需分开评估。
对离线急救 AI 的三点启示
第一,小模型加领域微调是可行路径,但「可行」不等于「可信」。2.51/5 的分数提醒我们,此类系统当前更适合作为辅助参考,而非替代专业判断。
第二,评测体系的设计与模型本身同样重要。多模型盲评、隐藏对照项、医学专家交叉验证、安全否决项——这套组合拳为高风险领域的 AI 评测提供了一个可借鉴的模板。
第三,数据覆盖度是安全性的隐形天花板。关键词审计揭示的指南细节缺失,说明在急救这类标准严格的领域,训练语料的完整性与准确性应当被当作一等公民对待。
HandsOnAid 的价值不在于证明离线急救助手已经成熟,而在于用可复现的方法,把「差多远」量化了出来。对后续研究者而言,这份基线比一个漂亮的宣传数字更有用。
相关推荐

Pi Agent凭什么爆火?极简内核+可扩展的AI编程新思路
Pi Agent 为何在 AI 编程工具赛道脱颖而出?本文解析其极简内核、按需扩展的设计哲学,对比 Cloud Code、Codex 等主流工具的功能膨胀困境,探讨开发者自主控制 agent 的价值与轻量路线的取舍。

Claude Code用量总提前耗尽?7个技巧让额度撑更久
Claude Code额度总提前耗尽?本文整理七个实用技巧:切换到新任务时使用 slash clear、按任务选择Sonnet或Opus、调低effort等级、精简CLAUDE.md、关闭不用的MCP服务器、plan mode先规划、用slash usage定位消耗源头,帮助你延长用量额度的使用时间。

Cursor多智能体协作:浏览器扩展里看AI设计网站
YouTube短视频展示了多光标AI智能体在浏览器中协作设计网站的画面,其载体为浏览器扩展而非独立平台。本文梳理该演示的关键细节、信息缺口及其反映的多智能体协作趋势。