Langchain-Chatchat如何设置停用词表？-开发者社区

Langchain-Chatchat 中停用词表的设置与优化实践

在构建企业级本地知识库问答系统时，一个常被忽视但极具影响力的细节浮出水面：如何有效过滤那些高频却无意义的词汇？比如“的”、“是”、“在”这类词语，在日常交流中不可或缺，但在语义检索场景下却可能成为干扰项。这正是 Langchain-Chatchat 这类基于大语言模型（LLM）的知识问答系统中，停用词表所要解决的核心问题。

随着 AI 技术深入企业内部应用，从客服机器人到技术文档助手，越来越多组织希望借助 LLM 实现对私有知识的精准访问。Langchain-Chatchat 作为开源领域中的代表性项目，不仅支持 PDF、Word、TXT 等多种格式文档的离线处理，更通过模块化设计实现了高度可定制的文本预处理流程——其中，停用词机制便是提升检索准确率的关键一环。

那么，这个看似简单的“黑名单”功能，到底该如何配置才能真正发挥作用？它又在系统架构中扮演着怎样的角色？

停用词的本质：不只是“去掉常用词”

停用词（Stop Words），顾名思义，是在自然语言处理过程中被主动忽略的一类词汇。它们通常是语法功能词，如助词、介词、连词等，在中文里像“了”、“呢”、“我们”、“这个”等出现频率极高，但单独存在时几乎不携带实质语义信息。

如果不加以处理，这些词会在向量化阶段拉高向量空间的维度冗余，导致两个本应差异明显的句子因共现多个虚词而被判为“相似”。例如：

文档 A：“系统在启动时会检查配置文件。”
文档 B：“用户在登录后会收到通知消息。”

若不停用“在”、“会”，仅凭这两个词的共现就可能导致错误匹配。而经过清洗后，前者变为“系统启动检查配置文件”，后者为“用户登录接收通知消息”，语义区分度显著增强。

因此，停用词的作用远不止“减少数据量”这么简单，它直接影响的是向量表示的质量和语义检索的准确性。

在 Langchain-Chatchat 中的工作机制

Langchain-Chatchat 的整体流程可以概括为六个阶段：

文档加载→ 2.文本分割→ 3.预处理（含分词与停用词过滤）→ 4.向量化编码→ 5.向量存储与检索→ 6.LLM 回答生成

停用词处理主要发生在第 3 阶段，即文本预处理环节。值得注意的是，这一过程必须双向一致：不仅文档内容需要过滤，用户的查询语句也应使用相同的规则进行清洗，否则将造成“训练-推理”空间错位，严重削弱检索效果。

以下是典型的技术实现路径：

如何加载自定义停用词表

最常见的方式是从文件读取，每行一个词，构建成集合以实现 O(1) 查找效率：

def load_stop_words(file_path: str): """ 从文本文件加载停用词，返回 set 类型便于快速查找 """ stop_words = set() with open(file_path, "r", encoding="utf-8") as f: for line in f: word = line.strip() if word and not word.startswith("#"): # 忽略空行和注释 stop_words.add(word) return stop_words # 示例调用 STOP_WORDS_FILE = "data/stopwords.txt" stop_words = load_stop_words(STOP_WORDS_FILE) print(f"已加载 {len(stop_words)} 个停用词")

你可以在data/目录下维护一份标准停用词文件，推荐参考哈工大、百度或 CNKI 提供的中文停用词库作为基础，并根据业务场景增删调整。

分词与过滤的实际操作

中文处理离不开分词工具，Langchain-Chatchat 默认集成 Jieba 是最常见的选择。以下是一个完整的预处理函数示例：

import jieba def preprocess_text(text: str, stop_words: set): """ 对文本进行分词 + 停用词过滤 """ tokens = jieba.lcut(text) # 使用精确模式分词 filtered_tokens = [ token for token in tokens if token not in stop_words and len(token.strip()) > 0 and not token.isspace() ] return "".join(filtered_tokens) # 或使用空格连接：" ".join(filtered_tokens)

注意这里的选择：是否保留空格取决于后续 embedding 模型的输入要求。例如m3e或bge系列中文模型通常能良好处理无空格文本，但某些 Sentence-BERT 变体可能更适应带空格的形式。

与 LangChain 文本分割器的集成

为了确保每个 chunk 都经过统一清洗，建议将停用词逻辑封装进自定义的TextSplitter：

from langchain.text_splitter import RecursiveCharacterTextSplitter class StopWordTextSplitter(RecursiveCharacterTextSplitter): def __init__(self, stop_words=None, *args, **kwargs): super().__init__(*args, **kwargs) self.stop_words = stop_words or set() def split_text(self, text: str): # 先按原策略切分 raw_chunks = super().split_text(text) # 再对每个 chunk 进行清洗 cleaned_chunks = [preprocess_text(chunk, self.stop_words) for chunk in raw_chunks] return cleaned_chunks

这样做的好处是解耦清晰，既复用了成熟的分割逻辑，又能灵活插入业务特定的清洗步骤。

使用方式如下：

text_splitter = StopWordTextSplitter( stop_words=stop_words, chunk_size=500, chunk_overlap=50 ) documents = text_splitter.split_text(full_document_content)

整个流程无缝嵌入现有 pipeline，无需修改上层逻辑。

架构位置与影响链条

停用词处理虽小，却处于整个知识问答系统的“上游咽喉”位置：

[原始文档] ↓ (Loader) [Document 对象] ↓ (Text Splitter + 停用词过滤) [Cleaned Chunks] ↓ (Embedding Model) [Vector Embeddings] ↓ (Vector Store) [FAISS / Milvus] ↓ (Retriever) [Top-k 相似片段] ↓ (LLM Prompt 组合) [Final Answer]

一旦在此处引入偏差，后续所有环节都将继承错误。例如：
- 若误删关键术语（如把“API”当作缩写词删除），相关知识点将永远无法被检索；
- 若未对查询做同样处理，则用户提问“怎么配置 API？”对应的向量与文档中已被清洗过的“配置接口”无法对齐，导致漏检。

这也解释了为何许多团队在初期搭建系统时感觉“效果不稳定”——表面看是模型不准，实则可能是预处理环节埋下的隐患。

实践中的常见误区与应对策略

✅ 推荐做法

实践	说明
选用权威词表为基础	如哈工大停用词表包含近 700 个高频虚词，适合作为起点；避免自行凭感觉编写。
结合业务微调	法律文档中的“应当”、医疗文本中的“患者”，虽然频发但具语义价值，不应盲目加入停用词。
保持查询一致性	用户输入的问题必须走相同的分词+过滤流程，确保向量空间对齐。
动态维护能力	可考虑开发简易后台界面，允许管理员实时增删停用词并热更新，适应知识演进。

❌ 应避免的陷阱

直接替换原始字符串：不要用.replace("的", "")这种粗暴方式，容易破坏词语边界，如“目的地”变成“原地”。
混用英文停用词表处理中文：英语中的 “the”, “a”, “is” 并不适用于中文语境，且可能导致编码异常。
过度删除导致语义断裂：否定词如“不”、“非”必须谨慎对待，否则“不能访问”变成“能访问”，完全反转原意。
忽略 tokenizer 特性：若使用 BERT 类模型（如bert-base-chinese），其 WordPiece 分词本身已具备一定抗噪能力，过度干预反而适得其反。

一个典型的反例是某团队为追求“极致精简”，将所有单字词全部设为停用词，结果“云平台部署失败”变成了“平台部署失败”，丢失了“云”这一关键上下文，导致检索偏离。