嵌入空间水印：为第三方RAG服务打造可验证的数据审计方案

帮客户做知识库问答选型的那段时间，我最怕被问的不是效果，而是合规。对方拿着一份第三方托管RAG（检索增强生成）的采购合同问我：这些行业报告、内部合同上传之后，服务商声称只用于我们的索引，可我怎么验证？它有没有偷偷把数据混进别的租户的索引，有没有拿我们的语料去加热自己的模型？这个问题放在一年前几乎无解，大家的做法只有拼合同、拼品牌信任，技术上缺少可验证的手段。但现在有一条非常实用的技术路径——嵌入空间水印（Embedding-Space Watermarks），专门用来审计第三方RAG服务的数据使用行为。这篇文章我会从原理讲到三种能落地的注入方案，再给出一套完整的审计实验设计和踩坑经验，适合正在做RAG选型、负责企业知识库安全，或者自己开发RAG服务商想设计可追溯机制的同学参考。

1. 为什么需要审计第三方RAG：租来的服务，算不清的黑箱

1.1 托管RAG的三副面孔：全托管、自带索引、私有化交付

先把"Rent-a-RAG"这个概念说清楚。这不是某个新框架的名字，而是一种现实存在的服务形态——你不需要自建向量数据库、embeddng管线、GPU推理和检索服务，只按文档量或调用量付费，把一个完整的RAG链路托管给第三方。实践中我接触到的托管RAG大概分三类，审计的难度差别很大。

第一类是纯黑盒API。你把文档打包传上去，服务商负责解析、切片、向量化、索引、检索和生成，你只能拿到最终答案，有时附带几个来源ID。这类服务对客户完全不可观测，别说验证embedding模型是否按合同执行，连检索器到底用了什么索引结构都看不到。

第二类是自带索引。你用自己的向量数据库，或至少自己掌控文档解析和embedding流程，服务商只承接查询端的检索和LLM生成。这种模式的可控性强一些，能知道发过去的query是什么、返回的chunk是什么，但生成环节仍然是个黑箱——无法确认系统是否在生成前故意换掉了检索结果，也无法确认日志和缓存做了什么处理。

第三类是私有化交付，整套系统部署在企业内部，所有链路都能观测。这类看似最省心，但实际采购量不大，因为它贵而且需要专门的运维团队。很多企业最后出于成本考虑，都会走向前两种形态。

这三类形态对应一个共同问题：数据进入服务商的黑箱之后，客户手上没有任何技术层面的证据能证明数据被正确处理了。合同写了"不做用于训练、不做跨租户复用"，可合同只能约束结果，无法约束行为。

1.2 黑箱里的四个典型风险点

结合我在几个项目里看到的真实情况，第三方托管RAG最容易出问题的点集中在四个地方。

第一个是跨租户数据交叉。省成本的多租户架构通常只做逻辑隔离，很少做物理隔离。如果某个租户的query在检索阶段意外检索到另一个租户的chunk，服务商自己大概率也发现不了，但敏感数据已经从索引层面泄露了。站在受害租户的角度，你连"它是否检索到了别人的内容"都无法判断，因为LLM会把它包装成一段看起来很自然的回答。

第二个是悄悄换embedding模型。合同里写的是text-embedding-3-large，实际跑起来为了降成本可能换成了小一号的模型，或者换成了开源模型。embedding模型一变，检索召回分布就会变，最终表现为问答质量下滑。用户只能感知到"效果变差了"，却拿不出证据证明服务商违背了技术条款。

第三个是数据用于训练或微调。这是客户最敏感的点，服务商只要在某个内部版本里用客户文档做微调，哪怕只是做领域适配，都会造成不可控的知识残留。而且这种使用不像日志那样容易暴露，没有专门的检测机制基本上发现不了。

第四个是缓存与日志造成隐性复制。性能优化需要缓存，日志分析需要留痕，但如果缓存策略和日志保留策略设计得不干净，客户文档就可能以一种"服务商自己都未必意识到"的方式被复制到多个副本里。后面真出了数据问题，服务商甚至无法举证哪个副本被访问过。

这四个风险点有一个共同特征：都属于"行为合规"问题，而不是"效果"问题。传统的RAG评估——比如answer准确率、召回率、忠实度——解决的是"回答得对不对"，完全不关心"数据处理得正不正"。审计第三方RAG需要的是另一套方法论，而这正是水印技术进来的地方。

1.3 从"信任"到"可验证"：把审计做成采购交付物

我见过不少企业的采购流程，技术验收时看的是演示Demo和评测报告，上线后看的是SLA和工单响应时间。没有人检查过"数据到底被服务商拿去做了什么"。这里的关键转变是：把"可验证性"当作采购合同的显性交付物。

水印审计就是实现可验证性的手段之一。它的思路很朴素——在你自己的数据里埋下只有你能识别的标记，然后通过正常API交互，观察返回内容中是否能回收这些标记。如果能回收，说明数据确实被索引、被检索；如果无法回收，那就有理由怀疑数据链路出了问题。这种方法不需要破解系统，不需要探测服务商内部接口，完全是在合法权限内通过公开交互做验证。这一点很重要，因为审计的目的是获得证据，而不是攻击对方。

2. 嵌入空间水印的技术底盘：在向量里埋一根只有你知道的头发丝

2.1 RAG链路里哪些环节可以留下证据

要设计水印，得先知道RAG整条链路中哪些环节能留证据。完整链路大致是：文档解析→切片→embedding→构建索引→query embedding→ANN检索→重排→LLM生成。水印可以打的点很多，但可检测性完全不同。

文档内容层可以做文本标记。在切片里塞几个低频短语或特殊表达，LLM输出中一旦出现这些表达，就能直接匹配到。问题在于LLM生成阶段可能会做摘要、改写、过滤，让标记文本面目全非。

向量层可以做语义标记。对embedding向量施加一个低幅度的、可检测的扰动，或者让某些chunk在向量空间中落在一个"只有特定查询才能命中"的区域。检索阶段只要发生，证据就会被带到输出里，即使LLM对文本做了深度改写，语义相似度仍然可以完成匹配。

查询行为层也可以做标记。设计一组"水印查询"组合，让它们的分布形态能被统计学检测出来。这个方法不依赖检索结果的文本形式，但对查询量的要求较高，审计周期也会更长。

实操中我倾向于把三层证据都布上。文本层用于快速定位具体泄露片段，向量层用于应对改写，查询行为层用于反推模型和服务链路。三层证据互相印证，单层失败时不会整个审计方案失效。

2.2 文本层水印和向量层水印：一个怕改写，一个怕换模型

文本层水印最直观的做法是插入"哨兵块"。举个例子，我在一份技术报告中间藏过一段渲染极为正常、但包含一个全宇宙都不会自然出现的组合短语的段落。比如"七水合钌络合物在低温等离子体辅助下的催化活性曲线异常"——这个短语正常业务文档里不可能出现，我又把它嵌在一个真正讨论催化剂失活的段落中，让它在语义上一点也不突兀。检测时只要返回文本里出现了这个指纹短语，就说明系统确实把这个chunk检索了出来。

但文本层水印有一个致命弱点：怕LLM改写。现在的生成模型默认就会做摘要和重述，特别是服务商为了省token还会在system prompt里加一句"用简洁的转述回答"，这时候原文中的指纹短语很可能一个词都留不下来。我第一次做这个实验就吃过亏，检索出来了，也生成了，但答案是完全用服务商自己的话重写的。

向量层水印的做法就不一样。它不是在文本里做标记，而是在embedding向量上做文章。核心思路是：选一批marker chunk，对它们的embedding整体叠加一个密钥扰动向量，比如e' = normalize(e + α·w)。α是一个远小于1的能量系数。这样做的效果是，如果你不知道w，这些chunk在检索中的表现和正常chunk毫无区别；如果你知道w，你可以通过检测输出内容在向量空间中是否携带了这个特定方向的信号，来判断它是否来自被水印标记的索引。

向量层水印的优势在于抗改写。哪怕第三方LLM把一段话完全换了个说法，只要它还保留着"那段内容所对应的语义"，这段语义在embedding空间里就会落在距离原始chunk不远的位置。你就能通过计算输出文本的embedding与哨兵chunk embedding的余弦相似度来完成检测。

不过向量层水印有个前提条件：你得知道或者能大致猜出对方使用的embedding模型。因为扰动w是叠加在某一模型的向量空间中的，换一个空间w的方向就没有意义了。这个问题我们在第5部分会展开讲。

2.3 为什么非要选嵌入空间：语义指纹不怕换个说法

很多人会问，做文本水印不就行了吗，为什么还要进embedding空间折腾？我的理解是，RAG系统把数据从原始文本变成检索结果，中间经过了语义压缩这一层。传统文本水印像在纸质文件上加隐形墨水，复印一次还能看见，复印十次就没了。嵌入空间水印更像在文件的"含义DNA"上做标记——只要含义这个概念被检索器带到了输出里，检测就能生效。

这也是"嵌入空间水印"这个标题里Embedding-Space的真正含义。它不是为了炫技，而是为了应对RAG链路里普遍存在的文本改写和语义重述。一个合格的第三方RAG水印方案，至少要保证在文本层信号被清洗掉之后，向量层信号仍然可以作为第二道证据存在。

3. 三种能直接落地的水印注入方案

3.1 方案A：哨兵文档块（Canary Chunk）——给文档库放"诱饵"

方案A的意思是，在你准备上传的文档集中，混入2到5个哨兵块。每个哨兵块是一段语义完整、但包含极低频组合短语的文本。表面上看起来就是一篇正常报告中的某几段，实际上其中嵌入了只有你掌握的特殊表达。

设计时我一般遵循三条原则。第一条，哨兵块必须藏在真实的主题段落里，不要单独做成一个孤立文件，否则很容易被服务商的低质内容过滤给杀掉。第二条，每块里至少包含三个独立指纹短语，这样即使部分被改写，还有残余短语可以匹配。第三条，同一语义的水印要在多个文档中冗余部署，防止某一个chunk在切片和去重阶段就被去掉。

然后构造水印查询集。每个哨兵块对应5到10个查询问题，这些查询在正常文档集上命中率必须接近0，但在哨兵块存在时命中率要足够高。我一般在本地先用一批正常文档做负样本验证，要求1000个真实业务query对哨兵块的recall@10等于0，然后再把它放上线。这样才能保证哨兵块不会误伤正常检索。

检测时，把第三方返回的文本按两层做匹配。第一层是严格文本匹配：返回内容中是否包含了哨兵块里的指纹短语，用Levenshtein距离容错3个字符。第二层是语义匹配：把返回内容的embedding和哨兵块的embedding做余弦相似度，超过本地测试确定的阈值就判定命中。这一步能在文本被改写的情况下兜底。

3.2 方案B：向量偏置水印（Vector Bias Watermark）——密钥可检测的扰动

方案B更接近标题里的"嵌入空间水印"本意。它的操作流程是：

第一步，选定m个marker chunk，用你掌握的一个embedding模型把这些chunk向量化。第二步，生成一个密钥向量w，方向随机且与这批marker chunk所在流形的平均方向近似正交。第三步，对marker chunk的向量做扰动叠加e'i = normalize(ei + α·w)，α一般取0.1到0.3之间，具体值需要通过检索质量实验标定。第四步，把扰动后的向量写入索引，上传给第三方。之后，如果第三方返回的内容能检测出w方向的信号，就说明该chunk确实来自你上传、被加了水印的那份索引。

检测过程在数学上很直接：取第三方返回的文本，计算它的embedding，再和marker chunk的原始embedding求差向量，最后看这个差向量与密钥向量w的余弦相似度是否显著高于随机基线。实际落地时，我一般会构造一组"向量水印探测查询"，查询本身不是正常语言句子，而是随机噪声向量。只有加了水印偏置的索引，才能让这些探测查询命中对应chunk。这样连语义依赖都不需要，纯靠向量空间的信号做判断。

方案B对"自带索引"的托管场景最有效，因为你控制了上传之前的向量化过程。如果是纯黑盒API，服务商在你上传文档之后会自己重新embedding，那叠加在向量上的偏置就不存在了，方案B就会失效。

3.3 方案C：同义指纹改写（Paraphrase Fingerprinting）——追踪数据泄露

方案C解决的是另一类问题：数据泄露之后的溯源。核心思路是，把一个文档段落改写成一个"语义等价但表达唯一"的版本，然后把不同版本的文档分发给不同服务商或不同业务线。一旦在外部渠道发现了某次改写中的独特表达，就能反推出是从哪个环节漏出去的。

具体做法是选取一段需要保护的证据文本，用受控的同义词替换和句式变换生成多个改写版本。改写后文本的含义保持一致，但用词和句法带有人为制造的独有性。现实中，每当企业做供应商数据交换时，给A供应商的版本加入一个特定词，比如把"设备故障率"改成"装备失效频次"，给B供应商的版本改成"机组异常发生率"——这些改动不影响阅读，但成为天然的追踪标记。

方案C最核心的点在于，它不依赖对embedding模型的任何假设，因为检测依据是文本级别的唯一表达。副作用是它无法防止"语义蒸馏"式的泄露——如果LLM把整段话彻底变成自己的话，只保留核心含义，那你既抓不到原文短语，也不一定能通过embedding相似度抓住它，因为你根本不知道改写后的文本长什么样。

3.4 三种方案的适用场景对照

选型时我的建议是：先做方案A把"数据有没有被正确索引"这个问题验证掉；如果服务商暴露了索引结构或允许你自带向量，就叠加方案B；如果业务侧更关心数据分发后的泄露溯源，方案C单独使用就够了。三种方案并不互斥，反而应该组合部署，形成多层防线。

4. 一次完整的第三方RAG审计实验：从造数据到判定结论

4.1 审计数据集设计：哨兵块、水印查询、校准查询

完整的审计要从数据集设计开始。我通常把数据集分成四部分。

第一部分是业务文档集D。这部分就是你真实上传给第三方RAG的文档，可以是行业报告、内部制度、产品手册。保证这部分内容看起来完全正常，是为了让哨兵块的分布接近自然噪声。

第二部分是哨兵集C。按照方案A的规则生成2到5个哨兵块，每个块里至少3个独立指纹短语。如果是方案B，就额外对marker chunk做向量偏置处理。

第三部分是水印查询集Q_fp。数量控制在20到50条，覆盖每个哨兵块的不同语义侧面。每条查询都需要准备至少3个paraphrase变体，方便在线上做多样性处理。

第四部分是校准查询集Q_cal。这组查询的作用是估算本地和第三方之间的基线差距。我把等价的水印查询在本地模拟环境跑一遍，得到预期的命中区间，再拿同样的查询打第三方线上环境，对比两者的差异。如果说本地命中0.9，线上只有0.2，那就说明链路中存在某个环节不一致，需要进一步排查。

整个数据集设计完成之后，我会先用一个"模拟第三方RAG"做基线验证：LangChain + FAISS/Qdrant + 固定的embedding模型，所有链路开放，可以在本地复现。基线没问题了，才敢把同一套数据投到真正的黑盒API。这一步是审计可信度的根基——如果你在本地都无法确定这套水印的性能，就不能指望它在不可观测的环境里给出可靠信号。

4.2 指标定义：怎么判定"水印命中"

审计实验里我常用的核心指标有三个。

第一个是水印命中率。定义是：水印查询集中，返回内容被判定为包含哨兵信号的查询数量占总查询数的比例。每个查询独立判定，判定结果由文本匹配和语义匹配共同决定。

第二个是误报率。定义是：正常业务查询中，返回内容被误判为包含水印信号的比例。误报率是审计结论可信度的生命线，如果误报率偏高，你会冤枉服务商；如果强行压到0，命中率又会低到无法得出任何结论。实践中我一般把误报率控制在1%左右，在本地用1000条正常query建立对照组来估计。

第三个是信号噪声比（SNR）。这个指标主要用于向量偏置水印。计算时，把返回内容与marker chunk的残差向量和密钥向量w做相似度，再除以随机噪声方向上相似度的标准差。SNR大于3时，就可以认定水印信号存在。

4.3 与第三方RAG交互的采集策略：别让审计请求看起来像攻击

设计好数据集只是第一步，真正线上采集时最容易被忽略的是交互策略。审计请求不能像扫描器一样连续高频地打，否则会触发服务商的风控，账号被限流，审计直接中断。

我的一次标准做法是，把审计周期拉长到三到七天。每次会话里，水印查询只占10%到20%，其余是正常业务查询。水印查询的措辞、顺序和时间间隔都做随机化。每条查询在会话里的出现次数尽量控制在一次，如果必须重复验证，用paraphrase变体而不是原句。这样做的目的不是"偷偷摸摸"，而是保证审计行为不会干扰正常业务流量，也不会污染你自己的结论。

如果第三方API返回了来源ID或引用列表，我还会单独记录这些source信息。这可以将"返回内容包含哨兵块文本"和"返回内容明确引用了哨兵块ID"两个证据做交叉核对，能进一步提高结论置信度。

4.4 判定规则：四种可能结论

所有数据采集完成后，综合检测结果可以得到四类结论。

第一种是"数据已被正确索引，检索行为符合预期"。判断依据是水印查询的命中率落在本地基线区间内，文本层和向量层信号都能检测到，误报率低于预设阈值。这种结果在验收阶段很关键，它可以作为技术证据写进采购验收报告。

第二种是"数据未被正确索引"。典型表现是水印查询的命中率显著低于本地基线，但正常业务查询的表现没有异常。这时候需要怀疑三个环节：上传阶段被清洗、索引构建阶段被跳过、检索阶段被过滤器排除。三种情况对应的处理方式完全不同，需要进一步用其他手段甄别。

第三种是"索引中可能存在第三方来源的内容"。这个结论要特别小心。如果正常业务查询返回的内容中出现了你没有上传过的相似文本，它可能来自服务商的公共知识库、其他租户的数据，或者预置的默认语料。这种情况下水印审计的价值不在于证明服务商违规，而在于推动对方提供更透明的来源说明。

第四种是"数据被外部渠道泄露"。当你在完全没有向某个渠道提供过数据的情况下，在对方返回内容或公开内容中回收到了哨兵块信号，就能以很高置信度判定泄露。这通常需要方案C的改写溯源配合使用。

直接放一个简化版的检测pipeline代码，帮助理解整体流程：

# 水印检测核心流程示例（结构化示例，非生产代码） import numpy as np def detect_watermark(query: str, response: str, canary_fingerprints: list[str], canary_embedding: np.ndarray, threshold: float) -> dict: text_signal = any(fp in response or levenshtein_distance(fp, response) <= 3 for fp in canary_fingerprints) semantics_signal = cosine_similarity(embed(response), canary_embedding) return { "text_signal": text_signal, "semantic_signal": semantics_signal, "semantic_score": semantics_signal, "flagged": text_signal or semantics_signal >= threshold }

这个示例只是把逻辑骨架写出来。实际工程里，embed函数要对接你本地确认过的embedding模型，threshold必须由本地对照组确定，不能拍脑袋。

5. 实操踩坑实录：水印在真实第三方RAG上失效的六个场景

5.1 embedding模型被悄然更换：从命中率暴跌到模型指纹反推

我第一次在正式项目里上向量层水印时，本地基线水印命中率0.93，上第三方线上环境只剩0.21。当时第一反应是哨兵块在清洗阶段被杀了，于是我把文本层和向量层的检测结果分开查——文本层命中0.19，向量层信号更弱。这就奇怪了，哨兵块明显还在，为什么检索不到？

排查了两天，最后用了一个我从图像水印那边借过来的思路：先做"模型指纹推断"。方法不复杂，取一组固定句子，分别用几个候选embedding模型（bge-m3、e5-large、text-embedding-3-small）算出句子之间的相似度矩阵，形成该模型的"指纹"；然后构造一组检索探针查询，观察第三方对这些查询的召回行为更接近哪个模型的预测。结论是对方线上环境实际使用的embedding模型和合同标注不一致。

这个坑说明一个原则：向量层水印必须在灌数据之前先完成模型指纹校验。否则你辛辛苦苦叠加的扰动w，换一个向量空间就彻底失效了。

5.2 LLM摘要把文本指纹清洗得一干二净

另一个项目里，服务商在system prompt里强制"必须用自己的话简洁回答"。哨兵块里的指纹短语一个都没在返回文本里出现，文本层命中率直接归零。如果当时只做了方案A，这次审计就完全失败了。

最后是靠语义匹配层救回来的。我把返回文本按句子切分，每个句子和哨兵块的原始embedding算相似度，发现虽然没有任何原词重现，但其中两个句子的语义位置离哨兵块极近。最终语义信号达到0.81，虽然高于阈值，但已经比本地基线低了不少。

这次之后我总结出一个经验：凡是带LLM摘要的RAG服务，文本层水印永远只能作为辅助信号，不能作为主信号。主信号一定要落在语义层或向量层，否则你的审计方案会变成一场赌博。

5.3 数据去重与质量清洗把哨兵块静默删除

第三个坑是哨兵块被清洗。当时的第三方服务商有道质量过滤，专门删除"看起来可疑"的内容。我的哨兵块为了追求低频，塞了大量专业术语，结果被判定为"疑似乱码"直接处理掉。服务商也不会主动告诉你过滤掉了哪些块，只是数据上传后静默消失。

排查方式是做对比实验：同一份哨兵块，换成一个更贴近真实报告统计特征的版本。原版那种满屏低频词、单独成段的写法完全不可取；新版本把指纹短语嵌在一个正常主题段落的中间，上下文全部用真实业务文档里的普通句子。重新传入后，命中率恢复正常。

另外一个实用技巧是冗余部署。同一个水印语义做三个不同的改写版本，分散到三个不同的大文档里。这样即使服务商的清洗策略误杀了一部分，还有剩余版本可以当作检测样本。

5.4 阈值拍脑袋导致误判：ROC曲线才是依据

早期做语义匹配时，我直接把阈值定在0.85，理由是"0.85看起来足够高了"。结果审计报告里出现了误判：有一条正常业务查询的结果和某个哨兵块的相似度到了0.84，差一点就被标记为命中。这让我意识到，阈值必须从本地对照组里推出来，不能靠直觉。

具体做法是：在本地的模拟第三方RAG里采集1000条正常查询的返回内容，计算它们与哨兵块embedding的相似度分布。这个分布的尾部通常能告诉你噪声上限。然后再把1000条水印查询的相似度分布画出来，两个分布交叉点附近就是候选阈值。要压低误报率，就往噪声分布的99分位再偏右一点取。这样取出来的阈值，比任何拍脑袋的0.85都可靠。

5.5 哨兵块污染正常检索：水印不能影响产品质量

水印审计的底线是不能让水印本身破坏RAG的检索质量。有一个项目里，哨兵块的召回率做得太高，结果真实用户的一些正常业务query也把它撞了出来。用户在问答里突然看到一段和问题不太相关、但又不是完全无关的内容，体验立刻变差。

排查方式是做一次全量回归：拿1000条正常业务query对加入水印前后的检索结果做对比，要求加入水印后，每个query的top10结果与加入前完全一致。如果任何一个query的结果被水印污染，就重新设计哨兵块里的指纹短语，直到没有污染为止。

这条原则比很多人想象得重要。审计机制如果会损伤被审计系统的核心质量，那么无论它多有效都不会被业务方接受。水印必须像体检时抽的那管血，不会让你第二天跑不动步。

5.6 风控拦截导致审计中断：查询多样性是生命线

还有一次我的审计脚本在发出40条查询后触发了服务商的速率限制，账号直接进入人工审核。回看日志，问题很明显：我发的40条水印查询虽然语义不同，但句式高度相似，长度相近，时间间隔又固定，从风控视角看这就是典型的API扫描特征。

解决方式是给水印查询集注入多样性。每一条水印查询至少准备三种paraphrase变体，有的用陈述句式，有的用疑问句式，长度刻意拉开，时间间隔随机。另外，不再集中在一个时间段内把20条水印查询全部发完，而是把审计流量分散到很多天，每天混入普通业务流量里。这样既不会触发风控，也不会对服务商的实际负载造成可感知的压力。

5.7 一个扩展思路：模型指纹也可以作为审计手段

最后一个值得分享的扩展是嵌入手头这个方案的"模型指纹"思路。刚才5.1里提到的embedding模型推断，本身就能独立用作审计工具。正常情况下，你只需构造几组在模型A空间中紧密、在模型B空间中分离的查询对，把它们发给第三方RAG，观察检索结果的共现关系，就能判断它内部用的是哪个embedding模型家族。

这个技术对服务商"降本换模型"的问题特别有效。我就遇到过客户用这个办法发现，某第三方RAG实际使用的embedding模型，在检索效果的关键指标上比合同版本弱了不止一个档次。水印和模型指纹搭配使用，一个验证数据链路是否正常，一个验证模型链路是否合规，覆盖了RAG审计的两大核心问题。

在我自己落地这套方法的这段时间里，最深的体会是：水印审计最重要的不是技术多精巧，而是你能否把"可验证性"作为一条明确的技术要求写进采购合同和验收清单。很多服务商不是不想合规，而是缺少一种不破坏正常服务的方式向客户证明自己合规。嵌入空间水印正好补上了这个缺口。值得高兴的是，这套思路不止适用于传统RAG。随着Agentic RAG和Graph RAG越来越流行，检索结构会变得更复杂，水印也可以从单个chunk升级为子图结构、从单次检索升级为多步工具调用链路，审计方法本身也需要跟着迭代。但不管检索链路怎么变，"在自己数据里埋下可回收的证据"这个朴素原则，始终有效。