Langchain-Chatchat意图识别模块：区分咨询/投诉/建议类请求-开发者社区

Langchain-Chatchat 意图识别模块：如何精准区分咨询、投诉与建议类请求

在企业客服系统中，一个用户输入“这功能根本没法用，每次点进去都闪退”，到底该归为技术问题咨询？还是情绪化投诉？亦或是一条潜在的产品改进建议？

这类模糊表达在真实场景中极为常见。传统的关键词匹配或规则引擎往往束手无策——它们能识别“投诉”二字，却难以理解“我快被你们的APP逼疯了”背后的愤怒。而基于大语言模型（LLM）和 LangChain 构建的本地知识库系统，正逐步成为解决这一难题的新路径。

Langchain-Chatchat 作为开源领域内较成熟的本地化 RAG（检索增强生成）框架之一，不仅支持将企业私有文档转化为可查询的知识库，更关键的是，它允许我们在不泄露数据的前提下，构建具备语义理解能力的意图识别模块。这个看似简单的“分类器”，实则是实现智能服务分流的核心枢纽。

从“只答不判”到“先判后处”：为什么需要意图识别？

早期的智能问答系统大多停留在“有问必答”阶段：用户提问 → 匹配知识库 → 返回答案。这种模式对标准咨询有效，但面对复杂诉求时显得力不从心。

比如：
- 用户说：“上次买的商品包装破损。” —— 是要退货？索赔？还是单纯吐槽？
- 又或者：“能不能加个夜间模式？” —— 看似是询问功能是否存在，实则可能是产品建议。

如果没有意图识别，所有请求都会进入统一的问答流程，导致两个后果：一是简单建议被当作疑难问题处理，资源浪费；二是真正紧急的投诉未能及时升级，影响用户体验。

引入意图识别后，系统可以做到“先判后处”：

graph TD A[用户输入] --> B{意图识别} B -->|咨询| C[调用知识库返回答案] B -->|投诉| D[生成高优工单并告警] B -->|建议| E[结构化存入产品池]

这种路由机制让 AI 不再只是“回答机器”，而是具备初步判断力的“智能前台”。

如何让大模型学会分类？不只是打标签那么简单

在意图识别的设计上，很多人第一反应是训练一个 BERT 分类模型。但这需要大量标注数据，且一旦新增意图类别就得重新训练，维护成本极高。

Langchain-Chatchat 提供了一种更轻量、灵活的方式：利用本地部署的大语言模型 + Prompt 工程实现零样本或少样本分类。

以 ChatGLM3-6B 或 Qwen-7B 这类支持中文的开源模型为例，我们无需微调，仅通过设计合理的提示词（Prompt），即可引导模型输出预设的类别标签。

from langchain.prompts import PromptTemplate from langchain.chains import LLMChain from langchain_community.llms import ChatGLM INTENT_PROMPT = """ 你是一个专业的客户意图识别助手。请根据以下用户输入内容，判断其主要意图类别。 可选类别：[咨询, 投诉, 建议] 只需返回一个类别名称，不要解释。 用户输入： "{user_input}" 意图类别： """ prompt = PromptTemplate(template=INTENT_PROMPT, input_variables=["user_input"]) llm = ChatGLM(endpoint_url="http://localhost:8001", model_kwargs={"temperature": 0.01}) intent_chain = LLMChain(llm=llm, prompt=prompt) def recognize_intent(text: str) -> str: result = intent_chain.run(user_input=text) return result.strip()

这段代码的核心思想在于“约束输出空间”。通过明确限定可选类别，并强调“只返回类别名称”，配合极低的temperature值（接近确定性推理），我们可以让 LLM 在没有专门训练的情况下完成稳定分类。

当然，实际应用中还需注意几点：

Few-shot 示例提升准确性：对于边界模糊的情况，可在 Prompt 中加入几个典型示例，帮助模型更好理解分类标准。
后处理校验：模型可能偶尔输出非预期值（如“意见”、“反馈”等）。建议设置白名单过滤，确保输出始终落在[咨询, 投诉, 建议]范围内。
缓存高频请求：对常见表达进行缓存，避免重复调用模型造成性能损耗。

这种方式的优势在于迭代速度快——调整分类逻辑只需修改 Prompt，无需重新训练模型，特别适合业务初期快速验证。

深度集成：意图识别如何嵌入整个问答流水线？

在意图识别之后，系统的走向取决于分类结果。Langchain-Chatchat 的强大之处在于其模块化架构，使得不同路径可以灵活编排。

完整的处理流程如下：

文档摄入与向量化
- 支持 PDF、Word、TXT 等多种格式；
- 使用UnstructuredLoader或PyPDFLoader解析内容；
- 文本按段落切分（chunk_size 推荐 256~512 tokens）；
- 利用 M3E 或 BGE-zh 等中文 Embedding 模型生成向量；
- 存储至 FAISS 或 Chroma 等本地向量数据库。
查询处理与意图驱动路由
- 用户输入 → 经过清洗与标准化；
- 调用意图识别链获取类别；
- 根据类别选择后续处理链：

# 初始化RAG问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 主处理逻辑 def handle_query(query: str): intent = recognize_intent(query) if intent == "咨询": response = qa_chain({"query": query}) return { "type": "answer", "content": response["result"], "sources": [doc.metadata for doc in response["source_documents"]] } elif intent == "投诉": create_ticket(user_query=query, priority="high") trigger_alert("new_complaint_received") return {"type": "ticket_created", "message": "已提交工单，请耐心等待回复"} elif intent == "建议": save_suggestion(extract_key_points(query), category="ux_improvement") return {"type": "suggestion_recorded", "message": "感谢您的宝贵建议！"}

日志记录与反馈闭环
- 所有交互记录入库，用于分析高频问题、识别模型盲区；
- 当置信度过低或人工介入时，可触发标注任务，持续优化 Prompt 或未来微调模型。

整个流程完全运行于内网环境，敏感信息不出域，满足金融、医疗等行业的合规要求。

实战中的关键考量：别让“聪明”的模型犯低级错误

尽管大模型语义理解能力强，但在落地过程中仍需警惕一些常见陷阱。

1. 意图边界的清晰定义

“你们有没有夜间模式？”
“希望以后能出个深色主题。”
“别的APP都有暗黑模式，你们怎么还不做？”

这三个句子表达相似，但情绪强度递增。是否都算“建议”？还是最后一个应视为“隐式投诉”？

建议制定明确的判定规则：
- 明确使用“建议”、“希望”、“能不能”等词汇 → 归为“建议”；
- 含有强烈负面情绪（如“垃圾”、“差评”、“再也不用了”）→ 即使未提“投诉”也判为“投诉”；
- 单纯询问存在性或操作方式 → “咨询”。

可通过构建小型测试集定期评估模型一致性。

2. 支持上下文感知的多轮修正

用户可能在对话中转变意图：

用户：我想查下订单状态。（咨询）
用户：等等，快递三天都没动，怎么回事？！（转为投诉）

理想情况下，系统应结合历史对话更新判断。LangChain 的ConversationBufferMemory或SummaryMemory可用于保留上下文，在新一轮识别时拼接完整对话历史。

3. 人机协同：当AI不确定时交给人工

并非所有请求都能被准确识别。当模型输出置信度低于阈值（例如无法判断“你们的产品还行吧”是中性评价还是委婉批评），应标记为“待审核”，交由人工复核，并反哺训练数据。

对比传统方案：为什么这套方法更具优势？

维度	关键词匹配	传统机器学习分类	LLM + LangChain 方案
泛化能力	差，依赖精确匹配	中等，需大量标注数据	强，支持零样本推理
部署安全性	可本地部署	可本地部署	完全本地化，无数据外传风险
维护成本	高（频繁更新词典）	中（需定期重训练）	低（仅调整 Prompt 即可）
多意图识别	不支持	支持	支持
上下文理解	无	有限	强（Transformer 长距离依赖）