别急着把私人文件交给本地 AI：真正该测的是隐私、速度和漏提取

一份合同，模型总结得头头是道：合作方、付款金额、交付内容都没错，甚至还贴心整理出了待办事项。

但它漏掉了退款截止日期。

更危险的情况是，邮件原文写着“无需付款”，模型却把它归类成了“待付款”。

真正让我犹豫的，不是它要等几十秒，而是它整理得太像对的了。

这正是端侧多模态模型最容易制造的错觉：文件没有上传云端，摘要也读起来通顺，于是我们自然认为它既安全又可靠。

可对于合同、账单、邮件和聊天截图来说，真正需要回答的是三个更具体的问题：

1. 文件和中间结果是否真的没有离开设备？

2. 整理一份资料到底要等多久？

3. 模型有没有悄悄漏掉金额、日期和行动项？

结论先说：端侧模型已经适合承担基础整理、初步分类和内容索引，但“本地运行”不等于绝对隐私，“摘要不错”也不等于字段可靠。

一、本地运行，不代表资料绝对不会外流

测试私人资料，第一步不是选模型，而是先划定隐私边界。

我们可以准备一批脱敏或合成文件，包括：

• 带姓名、手机号和订单编号的邮件
• 包含付款条款的合同 PDF
• 银行付款页面的合成截图
• 带日期、地址和行动项的聊天记录
• 含表格、印章和多栏排版的扫描件

真实私人文件不应出现在测试截图、附件和公开测试集中。即便正文打了码，也要继续检查文件名、系统通知栏、用户目录、PDF 元数据和图片缩略图。

因为“本地运行”只是在描述模型部署位置，并没有回答以下问题：

• OCR 是否调用了在线服务？
• 应用是否自动检查版本更新？
• 是否启用了遥测和崩溃报告？
• 对话历史是否以明文保存？
• 临时目录中是否残留页面图片？
• 联网搜索或云端回退是否默认开启？
• 模型下载器是否记录了文件路径？

一个完整流程通常包含：

导入文件 → PDF 转图片 → OCR → 模型推理 → JSON 输出 → 历史记录与日志

其中任何一环都可能联网或留下本地明文。真正值得关注的，不是产品页面上的“Local”标签，而是能否验证每一个环节。

二、不要挑三张成功截图，要建立固定测试集

端侧模型评测最常见的问题，是只展示成功案例。

清晰的订单页面、排版规整的 PDF、没有转发链的短邮件，本来就是最容易处理的样本。真实资料却往往是低清截图、扫描合同、复杂表格和中英混排。

更合理的做法，是建立一套固定测试集。例如准备 45 份脱敏或合成文件：

每份文件都要人工制作“标准答案”，至少标注：

• 姓名
• 联系方式
• 日期
• 金额
• 订单号、合同号等编号
• 行动项
• 截止时间
• 资料类别

如果测试集涉及隐私，不能公开原文件，至少应公开字段定义、评分脚本和等价合成样本，否则读者无法判断评测是否只挑了简单题。

三个必须保留的失败样本

第一类是否定句：

请确认，无需再次付款，原订单已完成结算。

标准答案中的行动项应是“确认结算状态”，而不是“安排付款”。

第二类是日期缺失：

如需退款，请于 2026 年 3 月 31 日前提交申请。

如果模型只提取出“3 月 31 日”，年份遗漏就可能导致错误归档。

第三类是表格错列：

模型不仅要读对数字，还要把金额与正确项目、状态关联起来。单独识别出“5,000 元”，并不等于真正理解了表格。

漏掉一个普通标签，最多影响搜索；漏掉退款日期、合同金额或“无需付款”，可能直接导致现实损失。

三、把测试环境写清楚，否则速度没有比较意义

“本地模型几秒处理一份 PDF”这类说法通常缺少前提。

同一个模型，在独立显卡、Apple 芯片和纯 CPU 设备上的表现可能完全不同；扫描版 PDF 还多出页面渲染与 OCR 时间。

正式发布结果时，至少应公开以下环境信息：

如果这些条件没有完整记录，速度数字看似精确，实际很难复现。

四、隐私实测：不只抓包，还要检查本地残留

隐私测试建议拆成四个阶段：

1. 安装

2. 首次启动

3. 模型下载

4. 正式推理

网络监控中应区分：

• 模型文件下载
• 版本更新检查
• 遥测与崩溃报告
• 联网搜索请求
• 资料内容或 OCR 文本上传

模型下载产生网络请求是正常现象，关键在于正式推理阶段是否仍向外部域名发送请求，以及请求中是否包含文件内容、路径或生成结果。

抓包之后，还要继续检查：

• 系统临时目录
• 应用缓存目录
• 对话历史数据库
• OCR 中间文件
• 运行日志
• 崩溃报告
• 最近打开文件列表

尤其要关注原文、OCR 结果和模型输出是否以明文长期保留。对高敏感资料而言，“没有上传云端”和“明文躺在缓存里”是两种不同风险。

默认安全和配置后安全，要分开评价

一款工具可能在关闭联网、遥测、自动更新和历史记录之后表现良好，但默认设置仍然保留完整对话。

因此，隐私结论不应该只是“安全”或“不安全”，而应该拆成两项：

• 默认安全程度：普通用户安装后直接使用，会产生哪些联网行为和本地残留？
• 正确配置后的安全程度：关闭遥测、历史记录和云端回退后，能否断网完成全部流程？

如果断网后仍能完成文件导入、OCR、推理和结构化输出，至少能证明核心链路具备离线运行能力。但这依然不能替代对缓存和日志的检查。

五、速度要拆开算，别把 OCR 的锅全甩给模型

处理一份扫描 PDF，通常至少包含三段耗时：

PDF 页面渲染 + OCR 识别 + 模型提取与整理

因此，速度测试不能只记录“点击开始到看到结果”，还应分别统计：

• 首次启动时间
• 首字延迟
• 单份文件总耗时
• 单页平均耗时
• P50 与 P95 耗时
• 连续处理吞吐量
• 峰值内存或显存
• 连续运行时的温度变化

邮件、文字版 PDF、扫描版 PDF 和截图也必须分组统计。文字版 PDF 可以直接提取文本，而扫描件需要先做 OCR，两者混在一起算平均值，结果没有多少参考意义。

如果对比云端 API，同样要计入：

文件上传 + 服务排队 + 模型推理 + 结果返回

不能拿本地端到端耗时，去比较云端模型单独的返回阶段。

六、最关键的不是摘要质量，而是漏提取率

摘要读起来是否流畅，只能说明模型具备语言组织能力。

对于私人资料整理，更重要的是字段级指标：

• 字段级准确率：模型已经输出的字段中，有多少是正确的
• 字段级召回率：标准答案中的字段，有多少被模型找到了
• 严重遗漏率：金额、日期、行动项等关键字段的漏提取比例
• 幻觉率：模型输出中有多少字段并不存在于原资料

对应的基础评分逻辑如下：

precision = correct_fields / max(extracted_fields, 1)
recall = correct_fields / max(gold_fields, 1)
miss_rate = missed_critical_fields / max(gold_critical_fields, 1)
hallucination_rate = unsupported_fields / max(extracted_fields, 1)

不要急着把这些指标压缩成一个综合分。

假设一份合同的摘要、联系人和分类标签都正确，模型却漏掉了付款截止时间，综合分可能依然“很好看”，但这份结果不能直接进入业务系统。

一个最小可复现提取流程

可以要求不同模型统一输出 JSON，减少格式差异带来的干扰：

schema = {
"document_type": "",
"people": [],
"dates": [],
"amounts": [],
"identifiers": [],
"action_items": [],
"deadline": None,
"uncertain_fields": []
}

prompt = f"""
请根据输入资料提取信息，并严格输出 JSON。
不要补充资料中不存在的内容。
看不清或无法确定的字段写入 uncertain_fields。
目标结构：{schema}
"""

这里最重要的一句不是“严格输出 JSON”，而是：

看不清时，允许模型承认不确定。

很多严重错误并非来自完全无法识别，而是模型在模糊输入上仍然给出了一个看似合理的答案。相比漏填，错误填写通常更难被发现。

七、谁适合纯端侧，谁更适合混合方案

端侧整理不是“能不能用”的二选一问题，而是要根据资料风险划边界。

适合完全端侧处理

• 普通邮件的初步分类
• 会议截图的关键词整理
• 个人资料的本地全文索引
• 非关键文件的摘要草稿
• 不直接触发业务操作的待办建议

这类任务即使漏掉少量次要字段，通常也不会造成严重后果。

需要规则校验或人工复核

• 合同金额与截止日期
• 发票、订单和付款凭证
• 扫描版表格
• 被印章、手写字遮挡的字段
• 包含否定、条件和例外条款的资料

可以增加日期格式校验、金额合计校验、编号正则匹配，并把 OCR 清晰度不足的字段自动标记出来。

不建议直接自动入库或执行

• 医疗诊断与用药信息
• 财务转账指令
• 合同违约与解除条款
• 身份证件及认证材料
• 会自动触发付款、审批或通知的字段

这些场景不能仅凭模型输出完成后续操作，无论模型运行在本地还是云端。

八、更实用的方案：本地预处理，再按需回退

对多数普通用户来说，最现实的路线不是追求“所有事情都在本地完成”，而是搭建一条可控的混合链路：

1. 在本机完成文件解析和 OCR

2. 删除姓名、手机号、地址等敏感信息

3. 使用端侧模型做初步分类和字段提取

4. 对金额、日期、编号执行格式校验

5. 将低置信度字段交给人工复核

6. 经用户明确授权后，再把脱敏片段交给云端模型

判断逻辑可以写成：

if contains_sensitive_data and local_confidence >= 0.85:
save_local_result()
elif contains_sensitive_data:
request_human_review()
else:
optional_cloud_fallback()

但要注意，模型自行给出的“置信度”通常没有经过校准，不能直接把 0.85 当成真实可靠概率。

更稳妥的判断依据应该包括：

• OCR 清晰度
• 日期、金额和编号的格式校验
• 多次提取结果是否一致
• 原文中能否找到对应证据
• 人工复核结果

九、一张表决定你该选哪种方案

如果设备跑不动多模态模型，或者本地模型在扫描 PDF、复杂表格上频繁漏字段，可以采用“本地脱敏＋按需调用云端”的方式：先在本机删除姓名、手机号、地址等敏感信息，再把低置信度片段交给云端模型复核。

需要用同一套提示词和评分表横向测试不同模型时，可以前往 api.884819.xyz 查看可用 API。平台内置 AI 对话功能，使用用户名和密码即可注册，不需要邮箱验证；没有月租和订阅，按量付费，Deepseek、千问等国产模型完全免费。

无论使用哪种服务，上传前都应检查数据保存、日志、训练使用和删除机制。涉及合同、医疗和财务资料时，不要默认任何第三方接口都适合接收原文。

十、发布评测前，至少准备好这些截图

为了让结论可验证，一篇完整评测至少应包含：

1. 测试设备、模型版本、量化规格和运行参数

2. 邮件、PDF、截图的“原始资料—标准答案—模型输出”对照

3. 网络监控或抓包结果，并标注测试阶段与请求域名

4. 断网运行成功或失败的界面

5. 缓存、日志和历史记录设置页面

6. 各类文件的速度分组柱状图或箱线图

7. 以资料类型和字段类型为坐标的漏提取热力图

8. 至少三个失败案例的局部放大图

截图完成后还要再次脱敏，特别检查通知栏、文件路径、文件名、缩略图和 PDF 元数据。

端侧多模态模型的隐私价值是真实的，但它不是安装完成后自动获得的能力。用户仍然需要关闭不必要的遥测、管理缓存、检查历史记录，并控制云端回退路径。

它已经可以成为私人资料的初筛员、索引员和草稿助手，但还不适合在无人复核的情况下成为合同审核员、财务操作员或医疗信息管理员。

这次解决的是“模型能不能读懂单份私人资料”。但当邮件、PDF 和截图不断积累，另一个更棘手的问题就会出现：本地知识库会不会把同名联系人混在一起，把旧合同当成新合同，甚至在删除文件后仍然检索出残留内容？

下一篇，我们会把同一套文件导入本地 RAG，专门测试检索命中、跨文档串档，以及资料删除后是否真的“忘干净”。

#端侧AI #多模态模型 #隐私安全 #PDF处理 #本地大模型 #AI教程 #8848AI #人工智能