#MTPhotos #RAG #N100 #家庭服务器

记录 N100 上 MT Photos + mt-photos-ai 的部署现状，并分析在现有家庭服务网络架构下，把"文字搜图"升级为完整 RAG（检索+生成）是否有意义、该怎么落地。

相关：N100 网络重构与服务修复记录 · Docker 数据迁移至 HDD 方案 · N100 部署 OpenClaw 与 Hermes Agent 实录

一、当前部署状态（2026-07-20）

N100（MyUbuntuLocal, 192.168.2.14）上以容器形式部署：

容器 镜像 状态 挂载
mt-photos — 运行中 /nfs（照片库）
mt-photos-ai mtphotos/mt-photos-ai:onnx-latest（8f6709818fe1） Up 34h，python3 server.py，:8060 —

mt-photos-ai 提供 CLIP（文字-图片语义匹配）+ InsightFace（人脸识别/聚类），实现"文字搜图"式的场景识别检索。

二、家庭网络拓扑（快照，含 IP 修正）

设备 角色 IP 系统
MacBook Air M1 主控终端 192.168.2.13（原 192.168.0.110，子网重构后已迁移） macOS
N100（MyUbuntuLocal） 服务主机 192.168.2.14 Ubuntu 22.04
milin_desktop AI 推理机 192.168.2.10 Win11，RTX 5080
milin_win11 备用推理机 192.168.2.12 Win11，Ollama

详细拓扑、公网访问链路、磁盘结构见 N100 网络重构与服务修复记录。

三、现状定性：这是检索，不是 RAG

mt-photos-ai 的流程：

1
2
照片 → CLIP 编码 → 向量存入 mt-photos 自带库
文字查询 → CLIP 编码 → 向量相似度匹配 → 直接返回图片列表

没有生成（Generation）步骤——搜"海边的照片"，系统只返回缩略图，没有 LLM 参与总结或多条件推理。这是 Retrieval，不是 RAG（Retrieval-Augmented Generation）。

四、RAG 化是否有意义

有意义，但价值集中在"自然语言组合查询 + 总结"这类需求上，而不是替代现有的关键词搜图。

判断标准：照片库会持续增长到无法靠人工翻找的量级，且真实查询里存在"多条件组合"（时间+人物+场景）或"总结性提问"（“去年夏天海边那次都有谁在，大概几月”），而不只是单一关键词。

现有架构已经具备 RAG 需要的两块拼图，只是没有串起来：

  • 检索层：mt-photos 的 search API（CLIP 语义检索 + InsightFace 人脸库 + EXIF 时间/地点）

  • 生成层：OpenClaw（DeepSeek Chat 主力 / Ollama qwen3:8b fallback）+ Hermes Agent（OpenRouter），详见 OpenClaw 部署实录

落地方案

把 mt-photos 的 search API 接成 Hermes Agent（或 OpenClaw）的一个 tool：

  1. 自然语言问题 → Agent 拆解 → 调用 mt-photos search API（CLIP 检索 + 时间范围过滤）

  2. 检索结果关联 InsightFace 人脸标签 + EXIF（时间、GPS）

  3. 结构化信息喂给 LLM，生成综合回答，并标注具体照片文件名/路径供核实

这一步比引入独立向量数据库更划算——检索层直接复用 mt-photos 已有能力，不需要重新建 embedding pipeline。

五、约束与风险

  1. 算力分工：CLIP 编码/检索在 N100 上跑 onnx 已经够用，不需要 GPU；生成层的 LLM 推理才吃算力，应路由到 milin_desktop（RTX 5080）或云端 DeepSeek，不要指望 N100 本地扛生成任务。

  2. 磁盘：sda 系统盘已 93% 满，任何新增的结构化元数据缓存都应落在 /nfs（btrfs RAID1），与 Docker 数据迁移至 HDD 方案 的规划一并处理，不要再写系统盘。

  3. 隐私：家庭照片含人脸、位置等敏感信息，送入生成层做推理时，优先走本地模型（milin_desktop 的 Qwen3.5-35B 或 milin_win11 的 Ollama qwen3:8b），DeepSeek 云端 API 只用于非隐私查询。

六、待办