Langchain-Chatchat识别敏感信息并自动脱敏

Langchain-Chatchat 识别敏感信息并自动脱敏

在金融、医疗和法律等行业，企业每天都在处理大量包含个人身份信息（PII）、银行账号、健康记录等高敏感数据的文档。当这些私有知识被用于构建AI问答系统时，一个核心问题浮出水面：如何在不泄露隐私的前提下，让大模型“读懂”内部文件？

这正是 Langchain-Chatchat 这类本地化知识库系统的价值所在——它不仅把整个AI推理链条拉回内网，更进一步提供了动态防护机制：在用户提问、检索匹配、答案生成的每一个环节，实时识别并脱敏潜在的敏感内容。

LangChain 并非只是一个调用大模型的工具包，它的真正威力在于“可编程性”。通过其模块化的组件设计，开发者可以像搭积木一样组装复杂的AI流程，并在关键节点插入自定义逻辑。比如，在RetrievalQA链中，从用户输入到最终输出之间，存在多个可干预的“钩子”（hooks），其中最实用的就是回调机制（Callbacks）。

以一段典型的问答链为例：

from langchain.chains import RetrievalQA from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS from langchain_community.llms import HuggingFaceHub embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2") db = FAISS.load_local("vectorstore", embeddings, allow_dangerous_deserialization=True) llm = HuggingFaceHub(repo_id="google/flan-t5-large", model_kwargs={"temperature": 0}) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=db.as_retriever(search_kwargs={"k": 3}), return_source_documents=True )

这段代码看似简单，但背后隐藏着巨大的控制空间。return_source_documents=True不只是为了展示引用来源，更是为了后续做上下文审计提供可能。而真正的安全防线，往往不是写在主流程里的，而是藏在那些容易被忽略的“边角料”功能中——比如回调处理器。

Chatchat 系统在此基础上做了深度封装，原名 Qwen-Chatchat，现已演变为支持多模型、多向量库的通用框架。它的核心定位很明确：为企业提供开箱即用的中文私有知识问答能力，且全程无需联网。无论是 PDF 合同、Word 报告还是 Excel 表格，都能被解析、切片、向量化后存入本地数据库（如 FAISS 或 Chroma）。用户提问时，系统先进行语义检索，再将相关段落作为上下文喂给本地部署的大语言模型（如 ChatGLM、Baichuan 或 Llama），最后生成自然语言回答。

这个过程听起来顺畅，但如果某份合同里恰好提到了员工身份证号或客户电话呢？模型会不会原封不动地复述出来？

这就引出了最关键的一环：动态内容审查。

LangChain 提供了BaseCallbackHandler接口，允许我们在 LLM 处理前后注入检测逻辑。设想这样一个场景：HR 员工在界面上问：“张三的联系电话是多少？” 系统确实能从某份简历文档中检索到对应信息，但在返回结果前，必须确保不会直接暴露完整手机号。

我们可以通过注册一个自定义回调来实现这一点：

from langchain.callbacks.base import BaseCallbackHandler class SensitiveInfoHandler(BaseCallbackHandler): def on_llm_start(self, serialized, prompts, **kwargs): for prompt in prompts: if contains_sensitive_info(prompt): print(f"[警告] 检测到潜在敏感信息：{mask_sensitive_content(prompt)}") def on_llm_end(self, response, **kwargs): result = response.generations[0][0].text if contains_sensitive_info(result): masked = mask_sensitive_content(result) print(f"[脱敏输出] 原始结果包含敏感信息，已自动处理：{masked}")

这里的关键是两个方法：on_llm_start在提示词送入模型前进行拦截，防止敏感内容被“学习”或误用；on_llm_end则是在模型输出后第一时间检查，一旦发现泄露风险立即脱敏。这种“前置过滤 + 后置拦截”的双保险策略，构成了完整的防护闭环。

那么，怎么判断什么是“敏感信息”？

最直接的方式是使用正则表达式匹配结构化数据。例如手机号、身份证、银行卡号都有固定的格式规律。下面是一个轻量级的实现：

import re SENSITIVE_PATTERNS = { "phone": r"1[3-9]\d{9}", "id_card": r"[1-9]\d{5}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]", "bank_card": r"\d{16}|\d{17}|\d{18}|\d{19}", "email": r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}" } def contains_sensitive_info(text: str) -> bool: for pattern in SENSITIVE_PATTERNS.values(): if re.search(pattern, text): return True return False def mask_sensitive_content(text: str) -> str: for pattern in SENSITIVE_PATTERNS.values(): text = re.sub(pattern, lambda m: "*" * len(m.group()), text) return text

这套规则虽然简单，但在实际应用中非常高效。对于非结构化信息（如人名、地址），还可以引入轻量级 NER 模型辅助识别，比如 WeBankTeam 开源的 Pledu-NER，专门针对中文金融场景优化，能在低资源环境下实现较高的召回率。

整个系统的典型部署架构如下：

+------------------+ +---------------------+ | 用户终端 |<----->| Web 前端 (React) | +------------------+ +----------+----------+ | v +---------+----------+ | 后端服务 (FastAPI) | +---------+----------+ | +------------------+------------------+ | | | +---------v------+ +-------v--------+ +-----v-----------+ | 文档解析模块 | | 向量数据库 | | 大语言模型 | | (Unstructured) | | (FAISS/Chroma) | | (ChatGLM/Llama) | +----------------+ +----------------+ +-----------------+ | +--------v---------+ | 敏感信息检测模块 | | (正则+NER+回调) | +------------------+

所有组件运行于企业内网，物理隔离公网。敏感信息检测模块贯穿三个关键节点：
1.文档入库阶段：对每一段文本进行扫描，标记或脱敏后再存入向量库；
2.用户提问阶段：分析 query 是否涉及敏感查询意图；
3.答案生成阶段：拦截模型输出，防止原文中的敏感字段被原样返回。

举个真实案例：某金融机构希望用 AI 辅助尽调报告撰写。他们上传了上百份客户签署的协议扫描件，其中包含身份证号码和联系方式。如果直接导入，哪怕模型本地运行，也无法保证这些信息不会在某些边缘情况下被意外输出。

解决方案是在文档解析后、向量化前加入预处理步骤：

for chunk in text_splitter.split_text(raw_text): if contains_sensitive_info(chunk): chunk = mask_sensitive_content(chunk) # 继续嵌入与存储

同时，在问答链中注册SensitiveInfoHandler，确保即使检索命中了未完全清理的数据片段，最终输出仍是安全的。

此外，权限分级也至关重要。并非所有人都应看到同样的内容。例如 HR 可以查看员工真实联系方式，而普通员工只能看到掩码版本。这就需要结合系统级的身份认证与策略引擎，在不同角色间实施差异化脱敏策略。

日志记录也不容忽视。每一次触发脱敏的行为都应被审计追踪，包括时间、用户、原始内容摘要、操作类型等。这不仅是合规要求（如《个人信息保护法》《数据安全法》），也是建立可信 AI 体系的基础。

当然，任何技术都有边界。正则匹配虽快，但难以覆盖变体表达；NER 模型虽准，却带来额外计算开销。实践中建议采用分层策略：先用规则做快速筛查，再对高置信度候选文本启用模型精检。另外，避免过度脱敏也很重要——比如“北京”不该被当成地址脱敏，“李四”也不一定就是真实姓名，需设置合理的上下文判断逻辑。

还有一个常被忽视的风险点：模型记忆。即便数据不出内网，若模型在微调过程中反复接触同一组敏感样本，仍可能形成“记忆泄漏”。缓解方式包括在训练时注入噪声、限制上下文窗口长度、定期清理缓存等。

最终，Langchain-Chatchat 的意义不只是技术整合，而是为企业提供了一种“可控智能化”的路径。它让我们不再面临“要么不用AI，要么冒数据泄露风险”的两难选择。相反，我们可以构建一个既能理解私有知识、又能动态守卫数据边界的智能系统。

这样的能力，在当前全球加强数据监管的大趋势下尤为关键。无论是 GDPR、CCPA，还是中国的《个人信息保护法》，都强调“数据最小化”和“目的限定”原则。而 Langchain-Chatchat 所实现的，正是这一理念的技术落地——在保障效率的同时，守住安全底线。

未来，随着更多专用脱敏模型、差分隐私技术和联邦学习方案的成熟，这类系统的安全性还将持续进化。但至少现在，我们已经可以用相对低成本的方式，迈出可信 AI 的第一步。