Langchain-Chatchat如何设置知识库内容审核机制？

在企业逐步将大语言模型（LLM）引入内部知识管理系统的今天，一个看似智能的问答助手，可能因为一份误传的文档而“越界”输出敏感信息——这并非危言耸听。某金融机构曾因员工上传含客户身份证号的测试文件，导致系统在后续查询中无意泄露隐私，最终引发合规调查。这类风险正随着本地知识库应用的普及而日益凸显。

Langchain-Chatchat 作为当前最受欢迎的开源本地知识库问答框架之一，凭借其支持离线部署、多格式文档解析与向量化检索一体化的能力，已被广泛应用于企业私有化AI助手中的构建。然而，其默认流程并未内置内容安全防护机制。用户上传的PDF、Word等原始文件若包含机密信息、个人隐私或违规表述，一旦进入向量数据库，便可能被模型召回并生成不当回答，造成数据外泄或品牌声誉损失。

更关键的是，这种污染是持久性的：即便事后发现，清理已嵌入向量空间的内容也极为困难。因此，与其依赖LLM自身的“对齐能力”做后端过滤，不如在知识入库前就建立一道防火墙——前置内容审核机制，才是保障系统安全可控的核心防线。

要实现这一目标，首先要理解 Langchain-Chatchat 的知识处理流水线。整个流程从文件上传开始，经历加载、分块、向量化、存储，最终服务于检索与回答生成。真正的“黄金拦截点”出现在哪里？不是在模型输出时，也不是在向量写入后，而是文档被解析为纯文本之后、尚未切分为chunks之前。

这个阶段具备几个不可替代的优势：
- 文本已是可读形式，便于规则匹配和语义分析；
- 尚未进入索引流程，阻断成本最低；
- 可以按整篇文档粒度决策，避免碎片化误判。

举个例子：一份100页的产品手册中仅有一段涉及未发布功能的描述。如果等到分块后再审核，可能会导致整份手册的部分chunk通过、部分被拒，破坏上下文完整性。而在全文级别进行筛查，则能统一处理，保持数据一致性。

那么具体该如何实施？最直接的方式是在 make_db.py 流程中插入自定义逻辑。Langchain-Chatchat 的核心脚本通常会遍历指定目录下的所有文件，使用对应的 Loader（如 PyPDFLoader、Docx2txtLoader）将其转换为 Document 对象列表。我们完全可以在这一环节增加一层“守门人”。

以下是一个轻量但实用的实现方案：

from langchain.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
import re

# 敏感词库（建议从配置文件加载）
SENSITIVE_WORDS = ["机密", "绝密", "内部资料", "禁止外传", "身份证", "银行卡号", "密码"]

# 常见隐私信息正则模式
PATTERN_ID_CARD = r"\b[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]\b"
PATTERN_PHONE = r"\b1[3-9]\d{9}\b"
PATTERN_EMAIL = r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b"

def contains_sensitive_content(text: str) -> tuple[bool, list]:
    """
    检测文本是否包含敏感内容
    返回: (是否包含风险, 发现的问题列表)
    """
    issues = []

    # 关键词扫描
    for word in SENSITIVE_WORDS:
        if word in text:
            issues.append(f"包含敏感词: {word}")

    # 正则检测身份证
    if re.search(PATTERN_ID_CARD, text):
        issues.append("发现疑似身份证号码")

    # 手机号检测
    if re.search(PATTERN_PHONE, text):
        issues.append("发现疑似手机号码")

    # 邮箱检测（某些场景下需限制）
    if re.search(PATTERN_EMAIL, text):
        issues.append("发现邮箱地址")

    return len(issues) > 0, issues

def load_and_validate_document(file_path: str):
    """
    加载文档并在分块前执行内容审核
    """
    loader = PyPDFLoader(file_path)
    raw_documents = loader.load()

    valid_docs = []
    invalid_files = []

    for doc in raw_documents:
        content = doc.page_content
        is_risky, issues = contains_sensitive_content(content)

        if is_risky:
            print(f"[审核失败] 文件 {file_path} 存在以下问题：")
            for issue in issues:
                print(f"  - {issue}")
            invalid_files.append({"file": file_path, "issues": issues})
        else:
            valid_docs.append(doc)

    return valid_docs, invalid_files

这段代码虽简洁，却已构成一套完整的审核闭环。它利用 LangChain 提供的标准 Loader 解析文件，提取出原始文本后立即调用 contains_sensitive_content() 进行综合判断。只有通过检测的内容才会被送入后续的 RecursiveCharacterTextSplitter 分块流程。

当然，硬编码规则只是起点。真正成熟的审核体系需要更强的灵活性和扩展性。为此，我们可以设计一个通用的包装器类，将审核能力抽象为可插拔组件：

from typing import List, Callable
from langchain_core.documents import Document

class AuditedLoader:
    """带内容审核功能的文档加载器包装类"""

    def __init__(self, loader, auditor_func: Callable[[str], tuple[bool, list]]):
        self.loader = loader
        self.auditor_func = auditor_func

    def load(self) -> List[Document]:
        raw_docs = self.loader.load()
        cleaned_docs = []
        for doc in raw_docs:
            is_clean, issues = self.auditor_func(doc.page_content)
            if not is_clean:
                page_num = getattr(doc, 'metadata', {}).get('page', 'N/A')
                print(f"文档第 {page_num} 页被拦截：{issues}")
                continue
            cleaned_docs.append(doc)
        return cleaned_docs

通过这种方式，无论是处理 Word 文档还是 Markdown 文件，只需替换底层 Loader，即可复用同一套审核逻辑。更重要的是，auditor_func 完全可以替换为基于 NLP 模型的风险分类器，例如使用 BERT 微调一个敏感信息识别模型，从而提升对变体表达、隐晦语义的捕捉能力。

在实际架构中的位置也很清晰。假设你有一个标准的知识库构建命令：

python copy_test_files.py --filename example.docx
python make_db.py --rebuild

你只需要修改 make_db.py 中的文档加载部分，将原本直接调用 loader.load() 的地方，换成 AuditedLoader(loader, your_audit_func).load()，即可无缝集成审核功能。整个过程无需改动 Langchain-Chatchat 核心代码，实现了非侵入式增强。

对比常见的“输出端过滤”策略，这种输入端拦截的优势非常明显。后者往往需要在每次用户提问后，对模型生成的回答进行二次扫描和裁剪，不仅增加了响应延迟，还存在“治标不治本”的问题——只要原始文档仍在向量库中，同样的风险就可能反复出现。而前置审核则是一次性清除源头隐患，长期受益。

从工程实践角度看，还需注意几个关键细节：

• 性能优化：对于上百页的大型文档，全量扫描可能影响构建效率。可考虑采样策略，如仅检查前10页和关键词附近段落，结合快速失败机制提升吞吐。
• 动态配置：敏感词库不应写死在代码中。推荐通过 YAML 或 JSON 配置文件管理，并支持热更新，以便运营人员实时调整策略。
• 分级响应：不同风险等级应触发不同动作。例如，“测试”字样仅记录日志；发现真实身份证号则立即中断流程并发送告警邮件。
• 人工复核通道：对于模棱两可的内容（如“密钥”可能是技术术语），可标记为“待审”，交由管理员确认后再决定是否入库。
• 增量同步兼容：当使用 --update 模式添加新文档时，同样必须经过审核，防止历史漏洞被重新激活。

此外，日志与审计也不容忽视。每一次拦截都应留下痕迹，包括时间、文件名、命中规则、操作人等信息，形成完整的数据准入证据链。这对于金融、医疗等强监管行业尤为重要，有助于满足 GDPR、网络安全法等合规要求。

事实上，这套机制的价值远不止于“防错”。它还能显著提升问答系统的可信度。想象一下，当你知道知识库中不会混入错误政策解读、过期操作指南或外部协作方的保密协议时，你对该助手的回答自然更有信心。这才是企业级 AI 应用应有的样子：不仅是聪明的，更是可靠的。

目前已有不少团队在此基础上进一步演进。有的接入阿里云内容安全 API 或腾讯云文本审核服务，借助云端大模型提升识别精度；有的则构建内部审核平台，支持多级审批流和版本回滚。但无论走向何方，第一步始终是明确审核节点、建立基础规则、跑通最小可行流程。

最终你会发现，真正的智能不在于能回答多少问题，而在于知道哪些内容不该放进系统。Langchain-Chatchat 开放的架构为此提供了理想土壤。通过在数据摄入端构筑审核防线，我们不仅能防范风险，更能建立起一套可持续演进的企业知识治理体系——让AI在安全边界内释放最大价值。