Langchain-Chatchat支持自定义停用词表：优化检索相关性-开发者社区

Langchain-Chatchat 支持自定义停用词表：优化检索相关性

在企业知识管理日益智能化的今天，一个常见却棘手的问题浮现出来：为什么我们的大模型明明“读”了所有文档，回答却总是似是而非？比如员工问“年假可以跨年使用吗”，系统却从某段落中提取出“详见人力资源部规定”作为答案——看似合理，实则无效。这种“答非所问”的背后，往往不是模型能力不足，而是文本处理链条中的细节被忽略了。

Langchain-Chatchat 作为一款支持本地部署的知识库问答系统，在隐私安全与功能可定制性上表现出色。而其中一项容易被低估、却极为关键的功能，就是自定义停用词表。它虽不起眼，却是决定检索是否精准、回答是否靠谱的“隐形开关”。

传统自然语言处理流程中，停用词过滤被视为标准步骤——像“的”、“是”、“在”这类高频虚词通常会被直接删除，以减少噪声。但问题在于，通用规则无法适应专业语境。在一份法律合同里，“不得”中的“得”若被当作普通助词删去，剩下“不”，语义就彻底反转；在医疗文档中，“非典型肺炎”若因“非”和“典型”分别命中默认停用词而被拆解，信息完整性便荡然无存。

这正是 Langchain-Chatchat 提供自定义停用词机制的意义所在：让用户根据业务场景，动态控制哪些词该留、哪些该去。这个功能并不炫技，但它决定了系统能否真正理解你的行业语言。

整个知识库构建过程始于文档加载。无论是 PDF 报告、Word 手册还是纯文本文件，系统首先通过 PyPDFLoader 或 Docx2txtLoader 等组件将其转换为纯文本内容。接着进入关键阶段——文本切片（Text Splitting）。LangChain 的RecursiveCharacterTextSplitter按设定长度（如 chunk_size=500）将长文分割成小块，确保每段都能被嵌入模型有效编码。

此时，分词与停用词过滤登场。项目默认集成 Jieba 中文分词器，对每个文本块进行切词。而在这一步，如果沿用默认停用词表，可能会误伤关键术语。例如某企业内部常用缩写“OA系统”中的“系统”一词，若被归为泛化词汇而剔除，则后续检索“OA”时可能无法匹配到相关内容。

def load_stopwords(stopwords_path="config/custom_stopwords.txt"): stopwords = set() with open(stopwords_path, "r", encoding="utf-8") as f: for line in f: word = line.strip() if word: stopwords.add(word) return stopwords def preprocess_text(text, stopwords): words = jieba.lcut(text) filtered_words = [w for w in words if w not in stopwords and len(w.strip()) > 0] return " ".join(filtered_words)

上面这段代码展示了如何在文档预处理阶段引入自定义停用词逻辑。用户只需维护一个custom_stopwords.txt文件，增删词语即可全局生效。更重要的是，这一规则不仅作用于知识入库阶段，也同步应用于用户提问时的查询预处理，保证了向量空间中“问”与“答”的语义对齐。

实验数据显示，某金融机构在其内部政策库测试中启用自定义停用词后，Top-1 检索准确率从 72% 提升至 86%，平均响应时间下降约 15%。性能提升的背后，其实是噪声干扰的显著降低：原本频繁出现但无实质意义的引导性短语如“如下所示”、“请参见附件”等被主动过滤，使得真正承载信息密度的关键词得以凸显。

但这并不意味着停用词越多越好。实践中我们发现，过度删除会导致语义断裂。例如否定结构中的“未审批”、“不可撤销”一旦丢失核心虚词，就会变成误导性表达。因此建议：

停用词总量控制在 200~500 个之间；
明确保留逻辑否定词（如“非”、“不”、“禁止”）；
定期结合查询日志分析高频无效结果，反向推导需新增的过滤项；
使用 Git 对stopwords.txt进行版本管理，记录每次调整背景。

这套机制之所以能发挥价值，离不开 LangChain 框架本身的模块化设计。Langchain-Chatchat 并非闭门造车，而是深度依赖 LangChain 提供的标准接口完成各环节编排。从 Document Loaders 到 Text Splitters，再到 Embeddings 和 Vector Stores，每一个组件都像乐高积木一样独立又协同。

以向量数据库为例，系统可选择 FAISS 或 Chroma 存储文档向量。这些向量由本地嵌入模型（如 BGE、Sentence-BERT）生成。当用户发起查询时，问题经过相同的分词与过滤流程后也被转化为向量，并在向量空间中寻找最相似的 top-k 片段。这一过程被称为“语义检索”，其准确性直接受文本清洗质量影响。

from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-en-v1.5") vectorstore = FAISS.from_documents(processed_docs, embeddings) retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

可以看到，向量化入口完全开放，开发者可以在processed_docs上自由施加预处理逻辑。这也意味着，只要你在构建文档和处理查询时保持一致的停用策略，就能最大程度避免“训练—推理不一致”带来的偏差。

最终的回答生成由本地部署的大语言模型完成。这是整个 RAG（Retrieval-Augmented Generation）流程的收官之笔。不同于调用 OpenAI API，Langchain-Chatchat 支持将 Qwen、ChatGLM、Llama 等开源模型部署在私有服务器上，实现数据零外泄。

from langchain.llms import LlamaCpp llm = LlamaCpp( model_path="models/qwen-7b-chat-q4_k_m.gguf", n_ctx=4096, n_batch=512, n_gpu_layers=35, temperature=0.7, verbose=True ) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="map_reduce", retriever=retriever, return_source_documents=True )

借助 llama.cpp 加载 GGUF 量化模型，即使在没有高端 GPU 的环境下也能实现高效推理。7B 参数级别的模型在 Q4_K_M 量化下仅需约 6GB 显存即可运行，非常适合边缘设备或笔记本部署。同时，通过设置合理的上下文长度与批处理大小，可在响应速度与生成质量之间取得平衡。

整个系统的架构清晰体现了典型的 RAG 范式：

+------------------+ +---------------------+ | 用户前端 |<----->| 查询接口 (API) | +------------------+ +----------+----------+ | +-----------------v------------------+ | 查询预处理 | | - 分词 | | - 自定义停用词过滤 | +-----------------+------------------+ | +---------------------------v----------------------------+ | 向量检索引擎 | | - FAISS / Chroma | | - 基于语义相似度返回 top-k 文档片段 | +---------------------------+----------------------------+ | +---------------------------v----------------------------+ | 大语言模型 (LLM) | | - 本地部署（GGUF/Qwen/GLM等） | | - 结合检索结果生成自然语言回答 | +--------------------------------------------------------+

在这个闭环中，自定义停用词的作用贯穿始终。它不仅是文本清洗的一环，更是一种语义调控手段——通过对词汇粒度的精细把控，让系统更贴近真实业务需求。

实际应用中，一些典型问题得到了有效缓解：