Memoria-智能影记创新实训博客（八）：本地优先设计下的隐私保护与云端大模型协同
Memoria-智能影记创新实训博客（八）：本地优先设计下的隐私保护与云端大模型协同
博客主题：隐私保护、本地计算与云端大模型协同
博客总结：前面的博客已经分别介绍了图片打标、语义搜索、故事生成、端侧模型部署、数字相册、创作推荐和大模型应用总结。本篇换一个角度，不再介绍单个功能，而是总结当前项目里一条贯穿始终的设计原则：能在本地完成的图片理解尽量留在本地，需要语言组织和复杂生成时再让云端大模型参与，并且云端只接收结构化线索，而不是用户相册原图。
1. 目标
Memoria 是一个围绕个人相册展开的智能创作 app。相册数据天然具有隐私性：照片里可能包含家人、朋友、住址、学校、工作地点、票据、聊天截图、证件、生活轨迹等信息。因此，在设计 AI 能力时，不能只追求“模型效果”，还要考虑哪些数据可以出端、哪些数据必须留在本地、模型输出如何被约束、失败后是否还能继续使用。
当前项目采用的是“本地优先 + 云端协同”的设计：
- 图片原始理解优先在本地完成。
- 云端大模型主要处理结构化文本线索。
- 需要直接看图的能力尽量交给端侧模型或本地规则。
- 所有模型输出都要经过校验、清洗和兜底。
这套设计让项目既能使用大模型提升理解和创作能力，又不会把用户相册变成一个完全依赖云端推理的黑盒系统。
2. 本地优先的第一层：图片向量和标签在本地生成
项目中最基础的图片理解能力来自 MobileCLIP2。它负责把图片编码成512维向量，再用文本 prompt 和图片向量之间的相似度完成标签匹配、废片过滤和语义召回。这个过程的关键是：图片不需要先上传给云端 LLM 才能被理解。
staticconstint expectedEmbeddingDim=512;finalexisting=_photoEmbeddingIndexRepository.readEmbeddingForPhoto(photo,modelVersion:activeModelVersion,);if(existing!=null&&existing.length==expectedEmbeddingDim){photo.imageEmbedding=existing;returnMobileClipEmbeddingResolution(reusedCache:true,profile:MobileClipEmbeddingProfile(backendLabel:effectiveBackend.label,providerLabel:'ObjectBox cache',),);}这段逻辑体现了两个本地优先思想。第一，图片 embedding 由端侧模型生成；第二，生成后的向量会写入本地向量索引，后续同一张图可以直接复用缓存。这样既减少重复推理，也避免每次搜索、推荐或故事生成都重新读取和分析原图。
打标结果aiTags也会进入本地数据库。后续语义搜索、创作推荐、故事生成和数字相册都优先复用这些本地沉淀的数据，而不是每次都把图片重新交给大模型。
3. 云端协同的边界：DeepSeek 主要处理结构化文本
项目确实使用了 DeepSeek，但它并不是无边界地接收用户原图。当前更稳定的主线设计是：本地先把图片转成标签、OCR、caption、时间地点等结构化线索，然后云端 LLM 基于这些线索做解析或写作。
LLMService的配置也通过--dart-define注入，避免把 API Key 硬编码在项目里：
staticconstString_defaultApiKey=String.fromEnvironment('LLM_API_KEY',defaultValue:'',);staticconstString_defaultModelName=String.fromEnvironment('LLM_MODEL',defaultValue:'deepseek-ai/DeepSeek-V3.2',);这条边界在语义搜索中最明显。用户输入自然语言后，DeepSeek 只负责把查询解析成 JSON 搜索计划，例如时间范围、地点、粗标签、正向语义、召回语义、负向语义。真正找图仍然发生在本地照片库和向量索引中。
如果没有配置 DeepSeek，语义搜索会退回本地规则；如果是短查询，也可以直接走本地短路语义检索。也就是说，云端模型负责复杂理解，本地逻辑负责可用性。
4. 故事生成：本地整理事实，云端组织语言
故事生成最能体现“云端协同”的价值。系统不会让 DeepSeek 自由想象一组照片的故事，而是先在本地整理素材：每张图的时间、地点、aiTags、OCR 摘要、已有 caption、用户手动 caption、本地 VLM caption 等都会被收束成结构化 JSON。
finalpayload=<Map<String,dynamic>>[for(varindex=0;index<materials.length;index++)materials[index].toJson(index:index+1,localCaptionResult:localCaptionMap[materials[index].photo.id],),];然后 DeepSeek 的任务才开始：基于这些事实生成title、subtitle、story、sections和highlights。提示词明确要求“不要编造未提供的事实”，并要求每个 section 只对应一张图片。
这种设计的好处是：DeepSeek 发挥的是语言组织和叙事能力，而不是无依据地“编故事”。如果用户选择本地 caption 模式，系统会先用端侧 VLM 给图片补充细节，再把这些细节作为文本素材交给 DeepSeek。这样既提升故事质量，也满足不直接上传原图的需求。
5. 数字相册：云端只改文案，不接管排版
数字相册进一步体现了“模型有边界”。相册书的页面结构、图片顺序、模板、坐标和元素校验主要由本地代码完成。DeepSeek 参与的是AI写文案：在布局已经固定的前提下，重写每个文本槽位里的标题、正文、题签和装饰短语。
finalrewritten=await_aiService.writeCopyForBook(title:widget.title,subtitle:widget.subtitle,sections:currentSections,document:document,storyTemplateId:widget.storyTemplateId,);数字相册提示词里有一个很关键的约束：布局已经固定，模型不能重新设计、不能重新排序、不能移动元素、不能增加或删除版式元素。也就是说，云端 LLM 只负责语言质感，最终可视化结构仍然由本地模板和 validator 控制。
这种方式避免了一个常见问题：如果完全让大模型返回自由排版结果，页面可能好看但不可控，也可能出现元素越界、文字压图、图片丢失等问题。当前项目选择让本地代码守住版式安全边界，让 LLM 只在安全区域内提升表达。
6. 创作推荐：本地内容沉淀驱动云端语义能力
创作推荐不是把用户相册发给模型，让模型“猜用户喜欢什么”。它更像是建立在本地数据沉淀上的主动发现机制：系统先有aiTags、caption、时间、地点、语义向量，再用预设主题或结构化查询去检索相册。只有真实命中的照片数量达到阈值，推荐才会展示。
这意味着推荐并不是纯粹的云端生成结果，而是由本地相册内容决定的。比如用户相册中反复出现餐桌、美食和聚餐 caption，系统才更容易推出“美食日记”；如果经常出现花草、树影、春日场景，才更容易触发“春天的气息”。云端模型和语义模板提供的是主题理解能力，本地照片库决定这条推荐是否成立。
7. 失败兜底：隐私设计也要保证可用性
本地优先不是只为了隐私，也服务于稳定性。如果所有能力都依赖云端，一旦 API Key 没配置、网络失败、模型返回格式异常，整条创作链路就会断掉。当前项目在多个关键节点都设计了兜底：
- 语义搜索：没有 DeepSeek 时走本地规则解析。
- caption：视觉接口失败时走本地 caption 合成。
- 故事生成：DeepSeek 返回异常时生成本地保底故事。
- 数字相册：AI 写文案失败时保留当前相册。
- 创作推荐：不满足阈值时不展示，而不是硬推。
这些兜底让“本地优先”不仅是一句隐私口号，而是实际提升了 app 的可用性。用户可以在没有云端模型的情况下继续浏览、搜索、整理和生成基础内容；云端模型则在可用时提升效果。
8. 总结
当前 Memoria 的 AI 架构可以概括为一句话：本地负责理解和沉淀，云端负责组织和增强。
MobileCLIP2 在本地完成图片向量和标签，让照片先变成可检索、可推荐、可创作的数据；本地 caption 和端侧 VLM 尽量承担需要直接看图的细节补充；DeepSeek 则主要处理结构化文本，完成复杂查询解析、故事写作、相册短文案和发布文案。每一层都有明确边界，每个模型输出都要经过业务代码验证。
这种设计让项目兼顾了三件事：隐私上，不上传用户原图；效果上，仍然能利用云端大模型的语言和推理能力；工程上，通过缓存、规则、校验和兜底保证功能不会因为模型不可用而整体失效。对一个个人相册类 app 来说，这种本地优先的 AI 架构比单纯追求“模型更强”更重要。