Langchain-Chatchat如何设置敏感词过滤？内容安全控制策略

Langchain-Chatchat如何设置敏感词过滤？内容安全控制策略

在企业级AI应用日益普及的今天，一个看似智能的知识问答系统，可能因为一句不当输出而引发严重的合规风险。尤其是在政企、金融、医疗等对数据隐私和内容安全高度敏感的领域，部署像Langchain-Chatchat这类基于大语言模型（LLM）的本地知识库系统时，“本地运行=绝对安全”早已成为一种危险误解。

即便所有文档处理都在内网完成，用户仍可能通过提问试探边界，比如：“如何绕过公司审计？”、“有没有未公开的政策漏洞？”——更棘手的是，模型在生成回答时也可能因训练语料残留或上下文推导“幻觉”出违规表述。这时候，仅靠模型自身的行为约束远远不够，必须引入主动式的内容防护机制。

其中最直接、高效且可落地的第一道防线，就是敏感词过滤。

要让 Langchain-Chatchat 真正具备生产级可用性，不能只关注“能答什么”，更要明确“不能说什么”。而实现这一点的关键，在于将敏感词过滤无缝嵌入系统的请求-响应链路中，形成从前端输入到后端输出的闭环管控。

从哪里开始？理解过滤的本质与作用节点

敏感词过滤本质上是一种基于规则的文本审查技术，它不依赖复杂的语义理解，而是通过预设关键词或正则表达式，快速识别并拦截包含特定内容的文本。虽然简单，但在实际工程中极为实用。

在 Langchain-Chatchat 架构中，有两个最关键的介入点：

• 输入过滤（Input Filtering）：在用户问题进入模型前进行扫描，防止恶意试探或诱导性提问触发风险响应；
• 输出过滤（Output Filtering）：在模型生成答案后、返回客户端前进行净化，兜底拦截潜在的不当输出。

这两个环节共同构成了“前置阻断 + 后置清洗”的双控结构，确保无论问题是来自用户还是模型本身，都不会造成内容泄露或传播风险。

如何做高效匹配？别再用in判断了

很多开发者初期会写这样的代码：

if "赌博" in user_input or "毒品" in user_input: return "禁止内容"

这在词量少时可行，但一旦敏感词达到几百甚至上千个，逐条判断的性能开销将不可接受。正确的做法是采用高效的多模式字符串匹配算法——Aho-Corasick 自动机（AC自动机）。

Python 中可通过pyahocorasick库实现 O(n) 时间复杂度内的批量关键词匹配，非常适合高并发场景下的实时检测。

下面是一个封装好的敏感词过滤模块示例：

# sensitive_filter.py import ahocorasick class SensitiveWordFilter: def __init__(self, word_list): self.A = ahocorasick.Automaton() for index, word in enumerate(word_list): self.A.add_word(word, (index, word)) self.A.make_automaton() def contains_sensitive(self, text): """判断是否包含敏感词""" for _ in self.A.iter(text): return True return False def get_hits(self, text): """获取所有命中的敏感词""" hits = set() for _, (_, word) in self.A.iter(text): hits.add(word) return list(hits) def mask_text(self, text, replace_char="*"): """对敏感词进行掩码替换""" words = sorted(self.get_hits(text), key=len, reverse=True) masked_text = text for word in words: masked_text = masked_text.replace(word, replace_char * len(word)) return masked_text

这个类提供了三个核心能力：
- 快速命中判断（适合输入拦截）
- 获取具体违规词汇（用于日志审计）
- 支持脱敏替换（保障输出可用性）

小技巧：排序时按长度降序替换，是为了避免“赌博网站”被先替换成“**网站”后再无法识别“赌博”的情况。

怎么集成进系统？两种主流方式任选

方式一：在 API 层直接拦截（推荐初学者使用）

如果你使用 FastAPI 或 Flask 暴露接口服务，可以在路由处理函数中直接调用过滤器。

# app.py（简化版） from fastapi import FastAPI, HTTPException from pydantic import BaseModel from sensitive_filter import SensitiveWordFilter app = FastAPI() # 动态加载词库（建议从文件/数据库读取） SENSITIVE_WORDS = ["色情", "赌博", "诈骗", "病毒", "翻墙"] filter_engine = SensitiveWordFilter(SENSITIVE_WORDS) class QuestionRequest(BaseModel): query: str @app.post("/chat") async def chat_endpoint(request: QuestionRequest): user_query = request.query.strip() # 输入过滤 if filter_engine.contains_sensitive(user_query): hits = filter_engine.get_hits(user_query) raise HTTPException( status_code=400, detail=f"问题包含敏感内容：{'、'.join(hits)}，无法处理。" ) # 模拟模型调用 response = "这是一个模拟回答，可能包含敏感词如赌博。" # 输出过滤：掩码处理 if filter_engine.contains_sensitive(response): response = filter_engine.mask_text(response) return {"answer": response}

这种方式逻辑清晰、调试方便，适合中小型项目快速上线。

方式二：利用 LangChain 回调机制实现非侵入式监控

LangChain 提供了强大的回调系统（Callbacks），允许你在链执行过程中插入自定义逻辑，而无需修改原有流程。

我们可以注册一个处理器，在模型输出完成后立即捕获结果并进行检测：

# callbacks.py from langchain.callbacks.base import BaseCallbackHandler from langchain.schema import LLMResult from sensitive_filter import SensitiveWordFilter SENSITIVE_WORDS = ["暴力", "恐怖", "极端主义"] output_filter = SensitiveWordFilter(SENSITIVE_WORDS) class SensitiveOutputFilterHandler(BaseCallbackHandler): def on_llm_end(self, response: LLMResult, **kwargs): for generation_list in response.generations: for gen in generation_list: text = gen.text if output_filter.contains_sensitive(text): print(f"[警告] 模型输出包含敏感词：{output_filter.get_hits(text)}")

然后在调用链中启用：

handler = SensitiveOutputFilterHandler() result = chain.invoke( {"question": "如何制作炸弹？"}, {"callbacks": [handler]} )

需要注意的是，gen.text是只读属性，无法直接修改。因此更完善的方案是结合外部状态标记，在主流程中根据回调记录决定是否放行或替换响应内容。

这种模式的优势在于非侵入性强，特别适合已有复杂链路的老系统升级。

实际架构怎么设计？构建全链路防护体系

在一个典型的 Langchain-Chatchat 部署架构中，敏感词过滤应位于应用服务层，处于用户接口与核心推理引擎之间：

[用户前端] ↓ HTTPS 请求 [FastAPI/Nginx] ↓ [输入敏感词过滤] ←─┐ ↓ │ [知识库检索模块] ├─→ [向量数据库] ↓ │ [LLM 推理调用] │ ↓ │ [输出敏感词过滤] ←─┘ ↓ [响应返回客户端]

在这个流程中：
- 输入过滤作为“安检门”，优先拦截恶意请求，节省后续计算资源；
- 输出过滤作为“净化器”，兜底处理模型可能产生的风险输出；
- 敏感词库建议通过配置中心统一管理，支持热更新与权限隔离。

此外，还可以根据不同用户角色加载不同的词库策略，实现分级管控。例如：
- 普通员工：屏蔽违法信息类词汇；
- 审计人员：额外开放部分内部术语访问；
- 外部访客：全面收紧过滤级别。

工程实践中的关键考量

真正把敏感词过滤做到可靠可用，光有代码还不够，还需要考虑以下五个维度：

1. 词库管理规范化

• 分类存储：政治、色情、暴力、商业机密等分类管理；
• 来源可靠：参考国家网信办黑名单、行业监管指南定期更新；
• 支持动态加载：避免重启服务即可生效。

2. 性能优化不容忽视

• 千级以上词库必须用 AC 自动机或 Trie 树；
• 可缓存常见查询哈希值，减少重复扫描；
• 输出过滤可异步记录日志，不影响主流程延迟。

3. 防绕过机制增强鲁棒性

单纯精确匹配容易被规避，需支持：
- 拆字变形：如“赌*博”、“du bo”；
- 同音替换：“河蟹” → “和谐”；
- 拼音首字母：“fz” → “非法”；
- 正则扩展：\b(viagra|伟哥)\b。

对于更高阶需求，可结合 NLP 做近义词扩展或上下文意图识别，但这已超出基础过滤范畴。

4. 用户体验要平衡

• 输入拦截应给出友好提示，而非冷冰冰的“错误”；
• 输出掩码不宜过度，保留句子基本通顺；
• 提供申诉通道或人工复核入口，避免误杀关键业务信息。

5. 日志与监控必须到位

每一次命中都是一次潜在风险事件，应记录：
- 时间戳、IP 地址、用户 ID；
- 原始输入/输出、命中的关键词；
- 触发动作（拦截/替换）。

这些数据可用于安全审计、行为分析，甚至驱动自动化告警系统接入 SIEM 平台。

它真的有用吗？真实案例告诉你

某金融机构在其内部知识助手项目中部署了 Langchain-Chatchat，并启用了敏感词过滤机制。上线两周内，系统共拦截了 17 次涉及“内部交易”、“规避审批”、“测试账号”等关键词的提问，其中一次为员工尝试获取未授权的操作手册链接。

由于及时阻断并记录了操作日志，安全部门得以介入调查，避免了一次潜在的信息外泄事件。更重要的是，该机制的存在本身也形成了心理威慑，减少了恶意试探行为的发生频率。

写在最后：安全不是功能，而是底线

很多人认为“我的系统很干净，不需要过滤”，但现实往往是：你永远不知道用户会问什么，也永远无法完全信任模型不会“说错话”。

在 AI 落地加速的当下，内容安全不应是事后补救，而应是默认配置。敏感词过滤虽属传统技术，却因其轻量、透明、可控的特点，依然是企业构建可信 AI 交互环境的基石。

对于每一个准备上线 Langchain-Chatchat 的团队，我都建议在 CI/CD 流程中加入以下检查项：
- 是否已配置基础敏感词库？
- 输入/输出双端是否均有防护？
- 词库能否热更新？
- 是否接入日志审计系统？

只有把这些细节落实到位，才能真正实现“智能”与“安全”并重，让 AI 助手既聪明又靠谱。