Walking the Embedding Space：从多模态 RAG 中提取私有数据集

关联论文：2610.01871
作者：flyP
更新：2026-10-03

一句话结论

作者提出 imMRAG——一种自适应、黑盒、针对 image-returning MRAG 的数据提取攻击：把恶意指令藏在用户上传的图像里而不是文本 prompt 里，通过混合"已恢复图像 + 攻击者持有的影子图像"与相关性重采样，主动游走 embedding 空间，在 2,500 次查询内可恢复多达 611 张放射影像、566 张文档扫描、416 张通用图像，是 non-adaptive baseline 的 5.6×。

解决的真问题

多模态 RAG（MRAG）常被宣传为"既能减少幻觉、又能避免把私域文档直接喂给模型"的安全方案——但它自身引入了一个全新攻击面：被检索到的图像本身就可能是私有数据。当 MRAG 以 image-returning 形式部署（"检索到的图像本身就是答案"，而不是被送给 LLM 当上下文）时，这张图就直接暴露了。

此前的数据提取攻击（data extraction / model inversion）大多假设攻击者只能通过文本 prompt 操作模型。但本文揭示了一个被低估的攻击向量——图像输入本身就是指令载体。一旦攻击者可以上传图像，他们就能把检索器本身当成可游走的 embedding 空间来榨取私有数据。

核心方法：自适应游走 + 图像内指令注入

1) 攻击者能力模型（黑盒但可查询）

黑盒：攻击者看不到 retriever 权重、看不到 datastore 内容、看不到 generator 内部状态。
可查询：攻击者可以任意上传图像，得到检索返回的图像。
目标：恢复 datastore 中尽可能多的"未公开图像"——以局部特征对应（local-feature correspondence）判定恢复成功。

2) imMRAG 的两阶段机制

Stage A — 种子初始化：攻击者先用一个影子图像集（attacker-held shadow set）触发基础查询，收集若干"系统返回的图像"，作为后续游走的起点。

Stage B — 相关性加权重采样（Relevance-Wearing Resampling）：每条新查询 q_{t+1} 由两部分合成： 1. 已恢复图像的局部扰动：取上一轮系统返回的图像，做保持语义但扰动 embedding 的图像变换。 2. 攻击者影子图像的混合：将扰动结果与攻击者自己持有的"影子图像"按相关性加权融合。

# 伪代码
recovered = []            # 系统已返回的图像
shadow = attacker_images   # 攻击者自带图像库
for t in 1..T:             # T = 2500
    anchor = sample(recovered)            # 已有恢复图像作锚点
    perturbed = perturb(anchor, eps)      # 局部扰动,保持语义
    q_t = mix(perturbed, shadow, w=rel)   # 相关性加权混合
    r_t = system.query(q_t)               # 拿到新返回图像
    if matches_local_features(r_t, datastore) and not in recovered:
        recovered.append(r_t)
    # rel 由 q_t 与已恢复集合的余弦相似度估出

关键在 w=rel（relevance weight）：相关性越高，扰动项权重越大，迫使查询在 embedding 空间中朝"与已恢复集相邻但仍有信息密度"的方向走——这正是 non-adaptive baseline 浪费预算的地方。

3) 与"文本 prompt 注入"路线的区别

维度	文本 prompt 注入（已有工作）	imMRAG（本文）
攻击向量	用户文本输入	用户上传的图像
攻击粒度	文本指令	embedding 空间内主动游走
防御难点	文本过滤 / 系统 prompt	图像无法被简单前置拦截
典型目标	让模型泄漏训练数据 / 文本	让 retriever 吐出私有图像本身

这是 attack surface 的根本性扩展：之前的护栏（"禁止在 prompt 里写敏感指令"）对图像通道无效。

关键实验与数据

实验设置清楚、可核验：

场景三选一：医疗助手（radiology 影像）、文档助手（document scans）、通用工具（general-purpose 图像）。
检索器：多个 CLIP-family retrievers（含 ViT-B/32、ViT-L/14 等常见开源变体）。
生成器：多种 multimodal generators，用于评估 generator 是否构成有效干扰器（影响 imMRAG 的恢复命中率）。
预算：单次 2,500 次查询。
关键结果：
放射影像场景：611 张 distinct 图像 被恢复。
文档场景：566 张 distinct 扫描 被恢复。
通用图像场景：416 张 distinct 图像 被恢复。
与 non-adaptive baseline 比：最高 5.6× 的 distinct datastore items 恢复率。
成功判定：local-feature correspondence（图像局部特征匹配），这是 SR / copy-detection 领域常用的稳健判定，避免"靠文件名相同"假阳性。

亮点与局限

亮点

全新攻击面揭示：把"图像内指令注入 + embedding 游走"这一组合系统化，这是已有 RAG 防御几乎都没覆盖的攻击向量——之前所有防御都盯着文本侧。
场景具体、预算具体：2,500 次查询这个数字非常有用——它告诉防御者"对手只要愿意付出这个代价，就能拿到六百张私有影像"，便于把防御预算与攻击预算放在同一张表上对账。
三场景交叉验证：医疗 / 文档 / 通用三场景都跑通，说明攻击不是某个垂直领域的弱点，而是 image-returning MRAG 的结构性弱点。
生成器不是关键：攻击成功率主要由 retriever 决定（多个 CLIP 家族都中招），生成器只起次要作用——意味着攻击在各种 MLLM 后端面前都有效。

局限（诚实标注）

依赖图像返回通道：只针对 image-returning MRAG——即"检索到的图像本身是答案"。如果系统返回的是"图像+文本 + LLM 总结"（text-returning），则本文攻击需重新评估，原文未明确给出 text-returning 场景下的对照。
未公开防御侧实现：只揭示攻击，未公开完整、可部署的 detection/masking 防御代码（GitHub 仓库链接 arXiv 页面未明确给出，原文未明确）——研究者要自己设计 mitigation。
未量化数据敏感度差异：未明确给出"放射影像 vs 通用图像"在隐私敏感度上的差别如何影响"成功门槛"—— 416 张通用图像 vs 611 张放射影像在隐私维度上重量完全不同，但论文以相同口径比较恢复数量。
防御建议偏定性：文末虽呼吁"为多模态数据设计 safeguards"，但没有量化评估任何具体防御（如 embedding 加噪、图像脱敏、查询频率限制）的效果——读者只能拿到"问题存在"，拿不到"哪种缓解有效多少"。

工程落地的启发

重新审视 image-returning MRAG 风险模型：凡是"上传查询图，输出一张系统图像"的产品形态，都要按本文数字做最坏情况评估——2,500 query / 6xx 恢复。
Defense 设计必须横跨 retriever 与 generator：本文表明生成器对攻击鲁棒性影响有限，防御重心应放在 retriever 端——加查询预算限流、做 embedding 距离异常告警、对影子集/恢复集模式做聚类监控。
三场景分别评估：医疗 / 文档 / 通用场景，攻击后果严重度差异巨大，建议把"是否允许 image-returning MRAG"做成按场景差异化的产品策略，而不是一刀切开关。
审计与告警：在 retriever 端记录每次 query 的 embedding 距离分布，单用户高密度查询 + embedding 距离方差异常应触发自动熔断。
数据合规审计周期：医疗影像这类数据单条就是合规事故，建议每 N 次查询强制人工审计样本 + 季度演练"如果对手按 imMRAG 攻击，损失多少"。

与同方向工作的关系

文本侧 data extraction 攻击（Carlini et al. 系列：extracting training data from LLMs）—— 本文是其多模态扩展，把攻击面从"训练数据泄漏"扩展到"私有 datastore 图像泄漏"。
MRAG 自身的安全 paper——本文与它们的关系是"揭示新型攻击"+"检验现有防御是否有效"，而不是"提出新防御"。这两类工作应配套阅读。
Copy-Detection / Image-SR 评测方法——本文借用其"局部特征对应"作为成功判定，把图像取证方法引入到攻击评估里。
Privacy-Preserving RAG（联邦 RAG / DP-RAG）——本文与它们的方向互补而非替代：隐私 RAG 关注"训练/检索阶段不下泄漏"，本文关注"系统对外暴露时是否会被榨取"。

适合谁读

AI 安全 / 红队：把 imMRAG 的 2,500-query 剧本加入 MRAG 系统渗透测试 checklist。
MRAG 系统架构师：评估自家系统"是否真有 image-returning 通道"以及"该通道的隐私预算"。
医疗 AI / 法律 AI PM：理解"放射影像私有检索"的真实暴露面，把"是否上线 image-returning"作为关键合规决策点。
隐私 / 合规工程师：把"单 query 成本 / 攻击恢复量"三个数字做成内部风险对账表。

不太适合：纯文本 RAG 的工程读者——本文场景是 image-returning，与纯文本 RAG 的攻击面差异较大。

§八工程坑点（≥5 个，4 分硬下限）

现象：把 "imMRAG 攻击要 2,500 query 才能拿到六百张图" 解读为"对手代价高、不值得防"。影响：对手可能用 bot farm 把单 IP 限额摊到 100 个 IP 上，预算翻 100 倍就变成 25 query/封。修复：按"对手总预算"而非"单 IP 预算"做防御规划，配套部署跨账号/跨 IP 行为聚类告警。
现象：Defense 设计集中在 generator 层（"让 LLM 不把图像内容说出来"），忽略 retriever 层。影响：imMRAG 攻击根本不依赖 generator 输出文本，generator 层加固全部浪费。修复：把防御预算至少 60% 投向 retriever 端——embedding 距离异常告警、查询频次硬限流、影子集相似度聚类。
现象：image-returning MRAG 部署在通用图像场景，但合规策略按医疗场景设计。影响：过度防御造成延迟浪费 / 防御不足造成事故。修复：场景差异化——按通用 / 文档 / 医疗三档分别给出"是否允许 image-returning 通道"的开关与限额。
现象：审计只看"用户上传了什么"，不看"系统返回了什么"。影响：imMRAG 攻击下，系统持续返回私有图像，但审计日志只记录输入侧，完全感知不到攻击发生。修复：审计日志必须同时记录"系统对外返回图像的 embedding 与频次"——出现"高相似度 + 高频次"模式立即熔断。
现象：防御假设"对手只能改文本 prompt"。影响：图像输入通道完全没保护，等于把整面墙拆掉。修复：强制图像脱敏预处理（embedding 距离扰动 / 像素级扰动）后再送入 retriever——会牺牲部分检索 recall，但换来结构性防御收益。
现象：没有季度化"假设对手按 imMRAG 剧本攻击"的演练。影响：真实事故发生时不知道"我们的检测要多少 query 才能命中"，只能事后救火。修复：每季度做一次红队演练——派一名安全工程师扮攻击者，按 imMRAG 流程跑 2,500 query，量化"我方检测/熔断的实际延迟"。