Langchain-Chatchat自动归类问题：将提问分配至对应知识分类

Langchain-Chatchat自动归类问题：将提问分配至对应知识分类

在企业知识管理日益复杂的今天，员工每天面对的不仅是海量文档，还有跨部门、多领域的信息孤岛。一个简单的“年假怎么休？”可能涉及人力资源制度；而“项目预算超支怎么办？”又牵扯财务流程。如果智能问答系统不能准确理解这些问题背后的领域意图，哪怕底层检索再强大，也容易答非所问。

正是在这种现实需求下，Langchain-Chatchat作为一款支持本地部署的开源知识库问答系统，凭借其对中文优化的支持和灵活的架构设计，成为构建企业专属AI助手的重要选择。它不仅能够解析PDF、Word等私有文档，还能通过语义向量检索实现精准响应。但真正决定其智能化水平的关键一步，是——如何把用户的问题自动分到正确的知识类别里？

这个问题看似简单，实则决定了整个系统的可用性。试想，如果员工问“报销发票的要求”，系统却去查了技术手册，那结果注定令人失望。因此，问题自动归类机制不是锦上添花的功能，而是整个知识路由的核心枢纽。

分类先行：为什么“先知道问的是什么”比“怎么回答”更重要？

大多数人在搭建问答系统时，第一反应是：“我要用更强的模型、更好的向量数据库。”但这往往忽略了最前端的环节——意图识别与分类。

Langchain-Chatchat 的高明之处在于，它没有试图用一个大模型覆盖所有领域，而是采用“分而治之”的策略：不同知识库独立存储、独立索引，在查询前先判断该走哪条路。这种思路类似于城市交通中的“立交桥系统”——与其让所有车辆挤在同一车道上抢行，不如提前分流，各走各道。

这个“分流”动作，就是自动归类。

目前，Langchain-Chatchat 支持三种主流的归类方式，也可以组合使用：

1. 基于关键词规则的硬匹配
   最直接的方式。比如问题中出现“报销”、“差旅费”、“发票”等词，就归为“财务类”。这种方式实现简单、响应快，适合术语明确、边界清晰的场景。缺点也很明显：一旦遇到表达变体（如“打车票能不能报？”），就可能失效。

2. 基于向量相似度的软匹配
   把用户问题编码成向量，再和每个知识库的“代表向量”做相似度比较（例如余弦相似度）。这里的“代表向量”可以是该类别下所有文档向量的平均值，也可以是人工构造的提示句向量。这种方法更具泛化能力，能捕捉语义层面的相关性，但依赖嵌入模型的质量，尤其是对中文的支持是否到位。

3. 基于轻量级分类模型的预测
   使用微调过的BERT、TextCNN或小型MoE模型进行多分类任务。训练数据可以是历史问题标注集，也可以通过大模型自动生成伪标签来构建。这类方法准确率高，适应性强，但需要一定的维护成本，比如定期更新模型以应对业务变化。

实际应用中，很多团队会选择“规则 + 向量”混合模式：先用关键词快速过滤出明显类别，对于模糊问题再交给向量或模型处理。这样既保证了效率，又提升了鲁棒性。

路由的艺术：LangChain 如何编排这场“知识导航”

如果说归类是“决策”，那么路由就是“执行”。Langchain-Chatchat 深度集成 LangChain 框架，利用其强大的链式编排能力，实现了动态的问题分发逻辑。

其中最关键的组件是RouterChain和MultiRouteChain。它们就像是一个智能调度中心，接收问题后，先调用一个“分类子链”判断去向，然后将请求转发给对应的“处理子链”。

下面这段代码就是一个典型的实现示例：

from langchain.chains.router import MultiRouteChain, RouterChain from langchain.chains.router.llm_router import LLMRouterChain, RouterOutputParser from langchain.prompts import PromptTemplate from langchain.chat_models import ChatOpenAI from langchain.chains import ConversationChain # 定义分类提示模板 route_template = """你是一个问题分类器。请根据以下问题内容，判断其应归属于哪个知识领域。 可选类别包括： 1. 财务报销 2. 人事制度 3. 技术文档 4. 行政管理 问题：{question} 请仅返回类别编号（1-4）。 """ prompt = PromptTemplate(template=route_template, input_variables=["question"]) llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0) router_chain = LLMRouterChain.from_llm(prompt=prompt, llm=llm, output_parser=RouterOutputParser()) # 构建各领域处理链 finance_chain = ConversationChain(llm=llm, prompt=PromptTemplate.from_template("你是财务专家...\n{input}")) hr_chain = ConversationChain(llm=llm, prompt=PromptTemplate.from_template("你是HR顾问...\n{input}")) tech_chain = ConversationChain(llm=llm, prompt=PromptTemplate.from_template("你是技术工程师...\n{input}")) admin_chain = ConversationChain(llm=llm, prompt=PromptTemplate.from_template("你是行政人员...\n{input}")) chain_map = { "1": finance_chain, "2": hr_chain, "3": tech_chain, "4": admin_chain } multi_route_chain = MultiRouteChain(router_chain=router_chain, destination_chains=chain_map) # 执行测试 response = multi_route_chain.run("差旅费可以报销哪些项目？") print(response)

有意思的是，这里并没有训练任何模型，而是直接让大模型当“分类器”。这其实是一种非常实用的设计：借助LLM强大的上下文理解能力，即使没有标注数据，也能完成初步的意图识别。而且只要修改提示词，就能快速调整分类逻辑，非常适合业务初期快速验证。

当然，如果你追求完全离线运行，也可以替换为本地部署的小型分类模型，比如 TinyBERT 或 Alpaca-Chinese 微调版本，依然可以接入相同的RouterChain接口，真正做到“插件式替换”。

知识隔离：不只是安全，更是精度的保障

很多人关注 Langchain-Chatchat 的“本地部署”特性，主要是出于数据安全考虑。但还有一个常被忽视的优势：知识库的物理隔离。

传统做法是把所有文档扔进同一个向量数据库，然后靠检索时的排序算法去筛选相关内容。听起来没问题，但在实践中很容易出错。比如搜索“合同审批流程”，系统可能会召回“技术协议模板”或“采购合同范本”，虽然都含“合同”二字，但用途完全不同。

Langchain-Chatchat 的解决方案很干脆：一个类别一个向量库。

这意味着：

• 财务文档存一份 FAISS；
• 人事手册存另一份 Chroma；
• 技术规范再单独建一个 Milvus 实例。

查询时，只加载目标类别的数据库。这样做有几个显著好处：

1. 减少噪声干扰：不会因为其他领域的高频词影响召回结果。
2. 提升检索速度：小库比大库快得多，尤其在资源受限的本地服务器上。
3. 便于权限控制：敏感文档（如薪资政策）可以直接限制访问权限，无需额外过滤。
4. 支持增量更新：新增一份产品说明书，只需更新“技术文档”库，不影响其他模块。

下面是创建独立向量库的一个典型流程：

from langchain.vectorstores import FAISS from langchain.embeddings import HuggingFaceEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter # 使用专为中文优化的 m3e 模型 embeddings = HuggingFaceEmbeddings(model_name="moka-ai/m3e-base") text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) # 假设已按类别分离文档 financial_docs = loader.load_and_split("finance_policy.pdf") hr_docs = loader.load_and_split("hr_handbook.docx") # 分别构建并保存 finance_vectorstore = FAISS.from_documents(text_splitter.split_documents(financial_docs), embeddings) hr_vectorstore = FAISS.from_documents(text_splitter.split_documents(hr_docs), embeddings) finance_vectorstore.save_local("vectorstores/finance") hr_vectorstore.save_local("vectorstores/hr") # 查询时按需加载 retriever = FAISS.load_local("vectorstores/finance", embeddings).as_retriever() docs = retriever.get_relevant_documents("年假如何申请？")

你会发现，这套流程非常符合工程直觉：模块化、可复用、易维护。更重要的是，它允许你在不同知识库之间使用不同的切分策略、不同的嵌入模型甚至不同的检索参数，真正做到“因地制宜”。

实战视角：系统是如何一步步工作的？

让我们还原一个真实场景：

用户在网页端输入：“我下周要出差，住宿标准是多少？”

系统开始工作：

1. 预处理阶段：问题进入系统，经过清洗和标准化处理（如去除标点、统一数字格式）。
2. 分类判断：系统调用分类模块。可能是规则引擎发现“出差”“住宿”属于财务高频词；也可能是向量匹配显示与“差旅管理办法”最接近；或者是LLM分类器输出类别“1”。
3. 加载对应库：确认为“财务报销”类后，系统加载vectorstores/finance目录下的 FAISS 索引。
4. 向量检索：将问题编码为向量，在财务库中搜索 Top-3 最相关的文本块，例如《差旅费管理办法》第5条：“一线城市住宿标准为每人每天不超过600元……”
5. 生成回答：将这些片段拼接成上下文，送入本地大模型（如 Qwen 或 ChatGLM3）生成自然语言回复。
6. 返回结果：前端展示答案，并附带来源文档名称和页码，增强可信度。

整个过程通常在1~2秒内完成，且全程在本地服务器运行，无需联网传输任何数据。

这样的体验，远胜于让用户自己翻找PDF目录或询问多个部门接口人。

设计背后的权衡：我们该如何配置这个系统？

在实际落地过程中，有几个关键决策点值得深思：

类别的粒度应该多细？

太粗不行，比如只有一个“公司制度”类别，等于没分类；太细则带来维护负担。建议初期划分5~8个核心领域，例如：

• 财务报销
• 人事政策
• IT支持
• 行政事务
• 产品资料
• 客户合同
• 法务合规
• 内部培训

后续可根据使用频率和混淆情况动态合并或拆分。

是否需要兜底机制？

总有问题无法明确归类，比如“最近有什么新政策？”或者“帮我写一封请假邮件。”这时可以设置一个“通用知识库”或默认路由路径，用于处理跨领域或开放性问题。

怎么评估分类效果？

光看回答准不准还不够，要建立反馈闭环：

• 记录每次分类结果；
• 提供“是否满意”按钮收集用户反馈；
• 定期分析误分类案例，优化规则或重训模型。

长期来看，这会形成一个持续进化的知识服务系统。

结语：从工具到范式，一场企业知识的静默革命

Langchain-Chatchat 并不只是一个技术工具包，它代表了一种新的企业知识管理模式：将静态文档转化为可交互的知识资产。

它的自动归类能力，本质上是在模仿人类专家的认知过程——听到一个问题，首先判断“这是哪个领域的事”，然后再调动相应的知识储备去解答。这种“先分类、再检索、后生成”的三层架构，既符合认知逻辑，也契合工程实践。

未来，随着本地大模型能力的不断增强，我们可以预见更多可能性：自动从文档中提取FAQ、构建内部知识图谱、实现多轮跨库推理……也许有一天，每个组织都会拥有自己的“企业大脑”。

而现在，我们已经站在了这场变革的起点上。