|
考察已有的方案, 在 github 上又看了几个脱敏工具, 也基本上用正则表达式替换实现, 弊端已有前述｡ 另一种思路是用 NER (命名实体识别) 算法/模型找到敏感数据, 但 NER 不够灵活, 容易误杀, 比如, 地名在很多场合是隐私数据 (地理位置开盒等), 但在旅游规划的等场景下, 地名却不应该被打码｡ 基于规则的脱敏, 无论是正则还是NER, 有个共同问题: 打的码不具有语义特征｡ 比如, 人名通常属于隐私数据 (不然大家上网怎么都取网名), 假设名侦探问个红楼梦贾府家庭纠纷案件, NER 脱敏跑一遍, 原文的人名替换成了甲乙丙丁或张三李四, 导致 AI 不得不浪费更多 token 先推理出亲属关系, 还不一定对｡ 正解是替换为父母子女兄弟姐妹等代称｡ 所以还得靠 LLM. LLM 的泄密问题前面佬友帖子说的很明白, 中转站的二手 API 风险较高, 大小模型厂商风险也是见仁见智｡ 最可靠的还是本地部署｡ 不过, 跟我一样的底层穷鬼还是看看远方的 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!
|
微信登陆 
