Langchain-Chatchat结合规则引擎提升可控性-平芜编程栈

Langchain-Chatchat 结合规则引擎：构建可控、合规的私有知识问答系统

在企业智能化转型的浪潮中，如何让AI真正“听懂”组织内部的语言，并安全、准确地回应员工或客户的问题，成为越来越多IT与业务团队关注的核心命题。尤其是在金融、医疗、法律等对信息准确性与合规性要求极高的领域，一个答非所问的回答可能不只是“尴尬”，而是直接引发风险事件。

通用大模型虽然能写诗作画、流畅对话，但面对企业私有文档时却常常“张冠李戴”——它不知道你公司的年假政策从哪年开始调整，也不清楚某个审批流程是否需要总监签字。更危险的是，它可能会基于训练数据中的公开信息，“合理推测”出本应保密的内容，比如某位高管的联系方式。

这正是Langchain-Chatchat的价值所在。作为一个开源的本地化知识库问答系统，它不依赖云端API，所有处理都在企业内网完成。你可以上传PDF版的《员工手册》、Word格式的《财务报销制度》，甚至是一堆扫描件，系统就能从中提取知识，构建一个只属于你们自己的“AI顾问”。

但这还不够。即便回答来源于真实文档，语言模型依然可能因为生成随机性而输出语气不当、逻辑跳跃，甚至踩中合规红线的内容。例如，在HR咨询场景下，一句“你可以直接辞职”听起来像是鼓励离职，哪怕上下文并无此意。

于是，我们引入了另一个关键角色：规则引擎。

Langchain-Chatchat 的核心能力是“知道该说什么”——通过文档解析、文本向量化和语义检索，将大模型的回答锚定在真实知识之上；而规则引擎的任务则是“确保说得对”——在输出前进行最后一道把关，防止任何越界表达流出。

这种“知识驱动 + 规则控制”的双层架构，不是简单的功能叠加，而是一种工程思维的进化：用AI提升效率，用规则保障底线。

整个系统的运作流程可以这样理解：

用户提出问题后，首先经过一层输入过滤。这个阶段并不急于调用大模型，而是先由规则引擎快速判断：“这个问题本身是否合法？” 比如有人问“总经理的家庭住址是多少？”，系统无需检索就能识别这是敏感请求，并结合身份权限决定是否拦截。

如果问题通过初审，则进入 Langchain-Chatchat 的标准 RAG（Retrieval-Augmented Generation）流程：

系统从本地知识库中加载相关文档；
使用中文优化的分块策略（如按段落或句子边界切分）将长文本拆解为语义完整的片段；
利用 BGE、Sentence-BERT 等嵌入模型将这些片段转化为向量，存入 FAISS 或 Chroma 这类轻量级向量数据库；
用户问题也被向量化，在库中查找最相关的 Top-K 条记录作为上下文；
最终，这个增强后的提示被送入本地部署的大模型（如 ChatGLM3、Qwen 或 Baichuan），生成初步回答。

到这里，大部分RAG系统的工作已经结束。但在我们的设计中，这才刚刚开始。

生成的回答并不会立即返回给用户，而是先进入输出规则校验环节。这里才是规则引擎真正发力的地方。我们可以预设一系列“安全阀”式的业务规则，例如：

若回答中出现“手机号”“电话”“邮箱”等关键词，且涉及管理层人员 → 自动替换为“该信息受权限保护，请联系行政部申请访问”；
若检测到建议性表述如“你可以辞职”“不用管流程” → 改写为“建议咨询人力资源部门了解正式流程”；
对于特定政策类查询（如年假、报销额度），强制附加引用来源：“详见《XX制度》第X章第X条”。

这些规则不需要重新训练模型，只需修改配置文件即可生效。这意味着当公司政策更新时，运维人员可以在几分钟内部署新的合规要求，而不必等待漫长的模型微调周期。

来看一个具体的实现示例：

import re from typing import Dict RULES = [ { "name": "block_contact_leak", "pattern": r"(手机号|电话|联系方式).*(经理|主管|领导)", "action": "reject", "response": "该信息属于公司机密，未经授权不得查询。", "severity": "high" }, { "name": "sanitize_resign_advice", "pattern": r"你可以辞职|直接走人|不用汇报", "action": "rewrite", "response": "如有职业规划调整，请按照《员工离职管理办法》提交申请。", "severity": "medium" }, { "name": "cite_leave_policy", "pattern": r"年假|带薪休假|请假", "action": "append", "response": "具体规定参见《员工手册》第三章第五条。", "severity": "low" } ] def apply_rules(generated_text: str) -> Dict[str, any]: for rule in RULES: if re.search(rule["pattern"], generated_text, re.IGNORECASE): if rule["action"] == "reject": return {"allowed": False, "output": rule["response"]} elif rule["action"] == "rewrite": return {"allowed": True, "output": rule["response"]} elif rule["action"] == "append": return {"allowed": True, "output": f"{generated_text} {rule['response']}"} return {"allowed": True, "output": generated_text}

这段代码虽然简洁，却体现了规则引擎的核心优势：低侵入、高响应、易维护。业务人员无需懂Python，只要按照JSON格式填写规则，就能参与系统的治理过程。相比动辄需要NLP工程师介入的模型微调方案，这种方式显著降低了运营门槛。

当然，实际部署中还需考虑一些细节问题。

首先是性能影响。正则匹配本身开销很小，但如果规则数量庞大或模式复杂（如嵌套逻辑），仍可能拖慢响应速度。对此，建议采用编译后的正则对象缓存机制，或将高频规则迁移至专用规则引擎（如 Drools、Easy Rules）以提升执行效率。

其次是冲突处理。当多个规则同时命中时，必须明确优先级顺序。通常可按severity字段分级处理：高危规则（如数据泄露防护）应优先于中低级别规则执行，避免被后者覆盖。

再者是可解释性。很多企业关心“为什么这个回答被修改了”。为此，可以在返回结果中加入元信息，例如标注“此回答已根据【sanitize_resign_advice】规则调整”，帮助用户理解背后的合规逻辑，增强信任感。

此外，对于边界模糊或高风险的案例，还可以引入“人机协同”机制——当规则触发高危动作时，不直接返回结果，而是转入人工审核队列，由管理员确认后再发布。这在法务、审计等极端敏感场景下尤为必要。

从系统架构上看，完整的流程呈现出清晰的分层结构：

+------------------+ +---------------------+ | 用户界面 |<--->| 提问输入 / 回答输出 | +------------------+ +----------+----------+ | +-------------v-------------+ | 规则引擎（输入过滤） | +-------------+-------------+ | +------------------------v-------------------------+ | Langchain-Chatchat 核心引擎 | | | | 1. 文档加载 → 2. 分块 → 3. 向量化 → 4. 检索 → 5. 生成 | | | +------------------------+-------------------------+ | +-------------v-------------+ | 规则引擎（输出控制） | +-------------+-------------+ | +---------v----------+ | 最终回答返回用户 | +--------------------+

每一层都职责分明：前端负责交互，输入规则做第一道筛子，RAG引擎提供智能生成能力，输出规则兜底合规，最后还可接入日志审计模块用于追溯分析。

这样的设计解决了许多现实痛点：