RAG 会不会把你的资料漏出去？
简单说：会。而且不用黑进你的系统，会提问就行。
问题不在模型记不记得住，在检索这条通路本身。RAG 让回答有据可依、幻觉少了很多，这是它被广泛采用的原因。同一套机制反过来用，就是一个出口。
攻击者要的不是权限，是提问的入口。
拿到入口之后，他能从底层语料里一点点把个人可识别信息抽出来。arXiv:2609.16095 那篇讲的就是这个脆弱性，9 月 14 日提交，cs.CL，兼挂 cs.AI 和 cs.CR。
个人可识别信息，白话就是能指向某个具体人的字段。姓名、邮箱、联系方式。这类东西混进语料，就成了可挖的目标。
容易被忽略的地方在这儿。
大家习惯的威胁模型是另一个。以前担心的是"模型把我的训练数据背下来了"。RAG 一来，很多人松了口气，觉得数据在自己库里，模型不背这锅。
松早了。
检索是把外部内容塞进模型的上下文，它不是隔离带。你替它开的那扇门，谁都能敲。
这篇提的方案叫 RAG-CT，位置放在提问侧。白话版是这样的：恶意查询和正常查询在提问方式上不太一样。前者要绕着圈子逼近目标，后者问得直。这种差别会落在熵分布和间隔分布上。RAG-CT 就靠这两样判断一个查询是不是在挖数据。
判断完只做一件事：拦下来。不改底层模型，也不改检索器。
它从提问侧下手，我猜是因为另一头太难。要在数据侧判断什么算个人可识别信息，本来就说不清，还得保证脱敏之后检索照样有用。提问侧不一样，异常行为通常有形状。
轻量在这里是卖点。不动你的模型和检索器，意味着能在现有系统前面加一层。相比重训一遍模型，这现实得多。
整条链上有三个位置可以设防：语料进库的时候、检索发生的时候、回答出去的时候。这篇挑了中间那个。
为什么值得单独拎出来讲？因为它挪了防线的位置。
以前防泄露大多在数据上做文章，脱敏、打标、做过滤，防的是一个静态的库。RAG-CT 防的是动态的问答行为。
可以理解为：不是加固门，是看谁在敲门。
实验那部分我只看个大概。两类数据集，四种已有攻击策略，四种防御基线。论文说泄露明显降下来了，还说这套机制轻量有效。这类声称我一向打七折看。方向比数字重要。
下面这段是给普通人的，自己搭过 RAG 的估计都清楚。
大部分人往检索库里扔的是笔记、合同、邮件、聊天记录。你不一定被盯上，但这笔账得先算：那个库的可及范围，等于你开放的提问入口的范围。
只在内网、一天十个同事用，问题不大。挂到公网上做成一个人人可聊的小助手，那就等于你配了一串抽屉钥匙，见人就发一把。
反过来说，如果那个库喂的全是公开文档，风险就低得多。真正要小心的是掺了私人数据的那些。
最常见的坑是图省事。语料进库的时候筛一遍，是最笨也最有效的做法，只是很多人直接跳过。
入口拦得住一次，拦不住人家慢慢来。这类方案的实质是把攻击成本抬上去，不是把路堵死。任何放在入口的防御都是这个性质。
唯一让我犹豫的是误伤。做深度调研的人，提问方式也可能很像在挖数据。这篇我没看到误伤率这一项。这条我保留意见。
所以我的判断是，防这件事最划算的位置是入口，不是数据。库里塞的东西你很难穷尽地脱敏，但你能控制谁能提问、从哪几个角度提问。
老实说，这篇我只看懂一半。阈值怎么定、刁钻的正常查询怎么和恶意查询分开，我没吃透。先放在这里，等我搞明白再补一句。
记住一句就够：防 RAG 泄露，先管住谁能提问。