[开源] 数据自动脱敏, 防止密码､ 个人隐私等泄漏给 AI 的思路和方案
考察已有的方案, 在 github 上又看了几个脱敏工具, 也基本上用正则表达式替换实现, 弊端已有前述｡ 另一种思路是用 NER (命名实体识别) 算法/模型找到敏感数据, 但 NER 不够灵活, 容易误杀, 比如, 地名在很多场合是隐私数据 (地理位置开盒等), 但在旅游规划的等场景下, 地名却不应该被打码｡基于规则的脱敏, 无论是正则还是NER, 有个共同问题: 打的码不具有语义特征｡ 比如, 人名通常属于隐私数据 (不然大家上网怎么都取网名), 假设名侦探问个红楼梦贾府家庭纠纷案件, NER 脱敏跑一遍, 原文的人名替换成了甲乙丙丁或张三李四, 导致 AI 不得不浪费更多 token 先推理出亲属关系, 还不一定对｡ 正解是替换为父母子女兄弟姐妹等代称｡所以还得靠 LLM. LLM 的泄密问题前面佬友帖子说的很明白, 中转站的二手 API 风险较高, 大小模型厂商风险也是见仁见智｡ 最可靠的还是本地部署｡对我等穷鬼来说, 本地部署的普遍问题是买不起卡｡ 美帝坏, 老黄也不是什么善人｡ 就算买得起N卡, 显存也不够大参数模型和长上下文硬造的｡ 所幸, 如果仅用于脱敏, 搭配抠门穷鬼精心雕琢的上下文/提示词工程, 小参数量模型和短上下文还是可堪一用的｡ 有 Benchmark 为证:promptmask/eval/benchmark.md at master · cxumol/promptmask · GitHub0.3B 的文心一言､ qwen2.5-1.5B, 又不是不能用, 那很节约了｡不过, 跟我一样的底层穷鬼还是看看远方的 AI 厂商吧｡ 实在没条件本地部署的, 可以用信得过的靠谱 AI 厂商来跑数据脱敏｡ 我私下信得过 AI 厂商有: 网络菩萨 Cloudflare, AI菩萨 Huggingface. 如果你还信得过搜索菩萨"鸭鸭走", 也不是不行｡言归正传, 对于穷鬼本地部署的小模型, 提示词工程/上下文工程在设计思路上需要注意:[*]小模型指令遵循能力差, 提示符范式首选模式匹配 (few-shot)
[*]显存有限, 一下输出太多容易爆显存
[*]算力有限, 输出越长, 等得越久
2 和 3 都指向尽可能短的本地模型/助手输出｡ 那么首先排除思维链/思考模型｡
朴素､ 直观的脱敏思路是, 让本地模型/助手直接输出打码后的文本, 简单明了, 模式匹配做起来也容易｡ 但如果输入特别长, 输出也就特别长, 那么不仅等得久, 还可能产生幻觉使得原文走样, 还可能爆显存｡所以我思路是, 让本地小模型写出 json 格式的映射关系数据, 把敏感数据内容和要打的码一一对应｡ 这样做不仅在处理巨长输入时, 解决了输出巨长的毛病, 还有大好处: 可以去码, 也就是把打过的码还原回来｡在实现形式上, 最好用户是无感的, 润物细无声, 不改变用户操作习惯, 只要做出最微小的改动, 就能获得数据安全保障｡
为了舒服､ 无缝的用户体验, 应该提供两种接入方式:
[*]对于 Python 用户, 通过自定义类反代 OpenAI 官方 SDK(把 from openai import OpenAI 替换为 from 自动脱敏库 import 反代的OpenAI as OpenAI)
[*]对于一般用户, 用本地 API 网关反代厂商的 /chat/completions 接口
这样接入不仅无缝, 而且无感, 即进行 AI 对话时, 看不到打码的过程, 并且 AI 助手回复的内容如果包含打的码, 反代时会去码还原, 也看不到还原过程｡比如, 假设你通过反代网关对 gpt-5 说:“给我写个 http://api.example.com/v1/chat/completions 测活的 curl 命令, 模型名 gpt-100, 密钥填 sk-123456”
然后你得到的回复中, 可能就包含 “Bearer sk-123456” 的字样, 但实际上 gpt-5 并没有看到 sk-123456,而是看到了 ${API_KEY}, 并且回复了 Bearer ${API_KEY}, 然后本地网关根据之前小模型生成的掩码表, 又把将之还原回了 Bearer sk-123456
一言以蔽之, 打码和去码都在后台默默发生, 不降低用户体验｡目前适配了反代 OpenAI 格式的 API / SDK, 如果需要别的格式(Anthropic/Gemini/etc. 欢迎共创代码添加适配) 或者用于非 AI 对话 / LLM 场景下的脱敏, 也提供 mask/unmask 等底层接口, 以便灵活应对更复杂的情景｡ 流和非流齐备, 同步异步共舞｡ GitHub - cxumol/promptmask: Never give AI companies your secrets!
鸭鸭走，老太太太幽默了 我猜以后会有一门生意。
从客户与AI的对话中筛出敏感信息来… 大佬太牛了，这文章修改修改都能发论文了 有前瞻性，也很实用。 做开发的真得好好学学这个！看到搞打野的这么多，以前大家可能确实没太留意！ 如果我们假设每个人的变量名不是随意取的，那么可以将代码解析成AST语法树，接着筛选出所有变量名、字典的键，当然还有实际值的对应表。之后把所有变量名交给小模型筛选敏感信息，小模型返回变量名后，再在本地查询实际值，并将其替换成可供替换的形式。
这样做，一方面性能更高，实际提交给小模型的不需要是全部代码；另一方面，小模型可以使用API，不用担心泄密问题，因为它根本没有获取到密文 。 哈哈，这是我发的引用的第四个帖子，来学习一下。 好文，赞了 感谢分享 写成了英文博客，
打算往英文论坛投稿 我目前制定了一个 Claude Code preToolUse 规则，禁止读取.env/sensitive 等文件的内容。实际上，我不太建议将敏感信息直接写进代码里。不过这个项目的思路挺不错的，可以结合 git hooks 做进一步拓展，优化并提升敏感信息的检测机制。 对老友来说，大模型的泄密隐患让人如鲠在喉、如芒在背。比如
页:
[1]