让智能客服学会提问-Dify多轮澄清与知识库建设实战让智能客服学会提问：Dify 多轮澄清 + 知识库建设实战引言：客

让智能客服学会提问：Dify 多轮澄清 + 知识库建设实战

上一篇，我们让智能客服"能答"；这一篇，我们让它"会问"，并且把企业知识库这口井真正挖好。

引言：客服答不好，往往不是"答"的问题，而是"问"的问题

上一篇《手搓一个企业智能客服问答智能体》里，我们搭出了一套五节点工作流：

开始 → 条件判断(转人工分流) → 知识检索 → LLM → 直接回复

上线之后，它确实能回答不少标准问题："彩色标签打印机怎么换纸""映美云打印平台怎么获取 access_token"……但很快，真实用户就给我们上了一课。翻看对话记录，高频出现的其实是这类提问：

"打印不出来" —— 哪款机型？什么现象？连电脑了吗？用的什么软件？
"这个怎么弄？" —— "这个"到底是指哪个功能？
"多少钱？" —— 哪款产品？哪个配置？含不含配件？

这些问题的共同特征是：用户的描述是残缺的。

面对这种提问，我们上一版的工作流会把它直接丢进知识库检索，结果要么召回一堆不相关的片段，要么大模型只能含糊作答、甚至道歉。我们当时靠"找不到就引导转人工"来兜底——但这只是把难题推给了人。真正专业的客服，从来不是等着用户把问题说完整，而是像真人一样主动反问，把问题问清楚，再给出准确答案。

这就是本期的主题：多轮澄清。

同时，上一篇里我反复强调"知识库是根，工作流是干"，但"根"具体怎么栽，只给了原则、没给步骤。很多朋友留言问：文档怎么切？索引方式选哪个？TopK 和 Score 阈值到底设多少？所以这一篇，我把 Dify 知识库从 0 到 1 的详细建立过程也完整补上。

本文分两部分：

上半部分 · 多轮澄清：让客服学会"先提问，再回答"
下半部分 · 知识库建设：把 Dify 知识库从创建到调优的全流程讲透

一句话概括这两件事的关系：多轮澄清解决"问得清"，知识库解决"答得准"。两条腿都硬，客服才站得稳。

第一部分：多轮澄清——让客服学会"先提问，再回答"

1.1 什么是多轮澄清

多轮澄清，指的是当用户提供的信息不足以给出准确答案时，客服不急着回答，而是先通过一轮或多轮反问，补齐关键信息，再作答。

用户描述残缺，通常缺的是这三类信息：

缺失类型	典型表现	需要澄清什么
缺主体	"这个多少钱"	哪款产品、哪个型号
缺现象	"坏了""打不出来"	具体表现、报错信息、发生时机
缺前提	"怎么连不上"	什么系统、什么软件、什么连接方式

只要这三类信息补齐了，一个模糊的问题就能变成可检索、可回答的具体问题。所以多轮澄清的本质，是帮用户把"模糊诉求"翻译成"结构化问题"。

1.2 在 Dify 里实现多轮澄清的三个技术基础

这是最关键的前提——多轮澄清必须用 Chatflow，不能用 Workflow。原因有三：

① Chatflow 天然支持多轮对话

Workflow 是"一次性单次运行"的，跑完就结束，没有"下一轮"的概念。而 Chatflow 是面向对话的，用户和机器人可以一来一回地聊，这才让"反问—回答—再反问"成为可能。

② 会话变量（Conversation Variables）用来"记住"澄清进度

多轮澄清的核心难点是"别忘了已经问到哪了"。Dify 的会话变量正好解决这个问题：

conversation_  product_model = ""   # 已确认的产品型号
conversation_  issue_type    = ""   # 已确认的问题类型
conversation_  clarify_round = 0    # 已澄清的轮次

每一轮用户补充信息后，工作流就把新信息写进这些变量。下一轮进来时，变量还在，客服就知道"机型已经问过了，不用再问"。

③ 记忆（Memory）让模型看得到历史对话

开启记忆后，LLM 节点能读取历史对话内容，从而理解"这个""它""上面说的"这些指代。

一句话总结：Chatflow 提供"多轮的舞台"，会话变量提供"跨轮的记忆"，记忆让模型"看懂上下文"。三者缺一不可。

1.3 多轮澄清的工作流设计

在上一版工作流基础上，我们在"开始"之后、知识检索之前，插入一个信息完整度判断环节。改造后的链路：

开始
 │
 ▼
┌──────────────────┐
│ LLM：判断信息是否充足 │
│ (输出结构化JSON)     │
└────────┬─────────┘
         │
    ┌────┴─────┐
    │ 条件判断  │
    └────┬─────┘
         │
  ┌──────┴───────────┐
  │                  │
信息充足            信息不足
  │                  │
  ▼                  ▼
知识检索        ┌──────────────┐
  │            │ LLM：生成澄清问题 │
  ▼            └──────┬───────┘
 LLM：生成答案        │
  │            ┌──────┴───────┐
  ▼            │ 会话变量：记录进度 │
直接回复         └──────┬───────┘
                     │
                     ▼
                  直接回复(反问)
                     │
                     ▼
              ↘ 等待用户补充，回到「信息是否充足」判断

请注意最关键的一环：用户补充信息后，下一轮会重新走一遍"信息是否充足"的判断，而判断时会带上会话变量里已记录的信息。这就形成了一个跨对话轮次的"澄清循环"。

1.4 怎么判断"信息是否充足"？

有两种做法，我强烈推荐第一种。

方法 A：让 LLM 输出结构化的判断结果（推荐）

给 LLM 一个提示词，让它判断并输出 JSON：

你是一个客服信息完整度判断助手。

请判断用户的问题是否包含足够的信息以给出准确答案。
需要的关键信息包括：
- 产品/机型（哪款设备或产品）
- 问题现象或诉求（具体发生了什么，或想做什么）
- 必要的前提条件（系统、软件、连接方式等，视问题而定）

已知信息：{{ 会话变量中已收集的信息 }}
用户本轮输入：{{ sys.query }}

请严格输出如下 JSON，不要有多余内容：
{
  "is_complete": true/false,
  "missing_fields": ["缺少的字段，如 product_model"],
  "next_question": "如果信息不足，建议向用户提的下一个问题"
}

拿到这个 JSON 之后，用条件判断节点判断 is_complete：

true → 走知识检索
false → 走澄清反问

方法 B：关键词 / 正则匹配

比如用正则检查用户输入里有没有机型编号（如 MCP-\d+），没有就反问。优点是零成本、快；缺点是覆盖不全、容易误判。适合作为方法 A 的补充，而不是主力。

1.5 澄清话术的设计原则

反问不是随便问。四条原则，直接影响体验：

① 一次只问最关键的一个问题

不要一口气问五个问题——用户会烦，也容易漏答。这一轮缺什么最关键，就问什么。

② 尽量给选项，别让用户自由发挥

对比一下：

❌ "请问您用的是什么机型？"（用户可能答"就那个白的小票机"，等于没答）
✅ "请问是以下哪款机型：针式打印机系列、热敏系列、喷墨电票系列，还是其他？"

给选项能大幅降低用户的理解成本和回答成本，也更容易结构化。

③ 说明为什么要问

加一句"为了给您更准确的答复"，用户的配合度会明显提升——让他知道这不是机器人卡壳，而是流程。

④ 累积式澄清，绝不重复问

靠会话变量记录，已经问过的就不再问。这是多轮澄清里最容易翻车的地方：如果第二轮又问一遍机型，用户会立刻失去耐心。

1.6 引导客户正确描述问题

除了被动反问，还可以主动引导用户把问题描述清楚：

模板化引导：在开场或澄清话术中，给一个描述模板：

为了更快帮您解决问题，可以按这个格式描述：
【机型】_____
【现象】_____
【已尝试】_____
例如：MCP-58 打小票时字迹模糊，换过纸但还是不清楚。

示例式引导：给一个填写范例，比干巴巴的要求有效得多。

兜底机制：设置澄清轮次上限。比如 clarify_round >= 3 仍然无法判断清楚，就不再死磕，直接走上一篇的转人工分支：

IF clarify_round >= 3 AND 信息仍不足 → 直接回复(客服热线)

重要：一定要设上限。没有上限的多轮澄清会陷入"机器人反复问、用户越来越烦"的死循环。澄清是为了更好地服务，不是为了问而问。

第二部分：Dify 知识库从 0 到 1 的详细建立过程

如果说多轮澄清是"怎么问"，那知识库就是"拿什么答"。下面按 Dify 的实际操作顺序，一步步讲清楚。

2.1 第一步：创建知识库

进入 知识库 → 创建知识库，Dify 会先让你选择"数据源"，主要有几类：

数据源	适用场景
导入已有文本	本地已有的 PDF / Word / Markdown / TXT / Excel 文档
同步自 Notion	知识维护在 Notion 里的团队
同步自 Web 站点	官网帮助中心、在线文档站
自定义 API	对接自有系统的文档接口

选择数据源并上传文档后，就进入最关键的分段与索引设置。

2.2 第二步：文档准备与清洗（上传之前）

这一步发生在 Dify 之外，但决定了知识库的上限。

要做的清洗：

去掉页眉、页脚、页码、水印
删除目录、修订记录、无关附录
统一格式（表格尽量转成 Markdown 表格或纯文本）
一个文档尽量聚焦一个主题——不要把整本手册塞进一个文件

为什么强调"一个文档一个主题"：Dify 的分段是按文档内部结构切的。如果一个文档里混了十几个不相关主题，切片就会很杂，检索时容易召回无关内容。

2.3 第三步：分段（Chunk）设置

这是 Dify 知识库最核心的一步。进入配置界面后，先选分段模式：

① 自动分段与清洗

让 Dify 自动按默认规则切分。适合格式规范、结构清晰的文档。

② 自定义分段

手动设置规则，可控性更强。关键参数：

参数	说明	建议
分段标识符	按什么切，如 `\n\n`（空行）、`#`（标题）、自定义符号	按文档结构选：FAQ 用空行，手册用标题
最大分段长度	单个切片的最大字符数	500～1000，太长会稀释，太短会割裂语义
分段重叠长度	相邻切片重叠的字符数	设为最大长度的 10%～20%，避免答案被切断

③ 父子分段（Parent-Child，进阶）

Dify 支持"父子分段"：用较小的子块做检索（提高命中精度），命中后返回其所属的较大父块给模型（保证上下文完整）。这是兼顾"检索准"和"上下文全"的高级技巧，适合长文档、结构化手册。

不同文档类型的分段建议：

文档类型	分段方式	理由
FAQ / 一问一答	按"问答对"切	一个切片就是一条完整问答
操作手册	按小节 / 步骤切	保证切片内逻辑自洽
长背景文档	自定义 + 重叠	避免语义被切断
表格类	转 Markdown 后按行块切	保留表格的可读性

2.4 第四步：选择索引方式

Dify 提供两种索引方式，这是很多人纠结的点：

索引方式	原理	优点	缺点	适用
高质量	用 Embedding 模型把文本转成向量，做语义检索	能理解"近义、换种说法"，召回头部效果好	消耗 token、需要向量模型、成本高	大多数正式场景
经济	关键词倒排索引（全文检索）	免费、无需向量模型、速度快	只能字面匹配，换种说法就搜不到	术语固定、预算有限的场景

选择建议：

客服问答面向真实用户，用户表达千变万化，几乎一定要选高质量
如果知识库里有大量固定术语、编号、代码（如"access_token""MCP-58"），可考虑高质量 + 全文的混合检索

Embedding 模型：Dify 支持多种向量模型（如 bge 系列、Text-Embedding 等）。中文场景优先选对中文友好的 bge 系列（如 bge-m3），它在中文语义匹配上表现稳定。

2.5 第五步：检索设置（调优的核心）

知识库建好后，决定最终效果的其实是检索设置。三个关键参数：

① 检索方式

方式	说明
向量检索	纯语义相似度，最常用
全文检索	纯关键词匹配
混合检索	语义 + 关键词加权，兼顾两者

推荐：混合检索（既有语义理解，又保底关键词命中），或初期先用向量检索跑通再优化。

② TopK

召回前 K 个最相关的切片。不是越大越好：

太小（如 1～2）→ 可能漏掉答案
太大（如 10+）→ 塞进大量噪音，反而干扰模型

建议从 3～5 起步，用真实问题测，再微调。

③ Score 阈值

过滤掉相关度过低的切片。强烈建议开启。

它的意义在于：当知识库里根本没有这个问题的答案时，阈值能让检索"什么都召回不到"，从而让上游的"找不到就转人工"逻辑正确触发。不开阈值，等于把"没有答案"和"答案不相关"混为一谈，最后只能靠模型硬答。

④ Rerank 模型（可选但有效）

知识库多、召回噪音大时，加一个重排序模型：先粗召回一批，再由 Rerank 精排出最相关的几个。能明显提升命中质量，代价是多一次模型调用。

2.6 第六步：元数据管理

给文档/切片打上元数据标签，比如：

产品线：标签打印机 / 云打印平台 / 数电产品
版本：V1.0 / V2.0
文档类型：FAQ / 手册 / 话术

配合检索时的元数据过滤，就能实现"先按产品线缩小范围、再做语义检索"，精度会再上一个台阶。这也是上一篇里"拆多个库"之外的另一条精细化管理路径。

2.7 第七步：测试与调优

知识库不是建完就完事，必须用真实问题回归测试。

Dify 提供了召回测试功能：输入一个真实用户问题，直接看检索命中了哪些切片。用它来做：

测召回：正确的问题，能不能召回正确的片段？
测边界：知识库没有的问题，是不是能"什么都召回不到"（验证阈值有效）？
调切片：命中不准时，回到分段设置改切片大小/标识符
调参数：改 TopK、Score 阈值、切换检索方式

调优顺序建议：先调切片（影响最大）→ 再调检索方式 → 最后调 TopK / 阈值。

2.8 第八步：更新与维护

知识库是"活"的。建立固定节奏：

日常：产品文档更新后，及时替换对应知识库中的文档并重建索引
每月：复盘"大模型答不上来的问题"，把新问题补进知识库
每季：清理过时内容（旧机型、旧政策）

这个更新闭环，才是知识库越来越准、客服越来越聪明的真正原因。 一次建好就躺平的库，三个月后就会答错一堆。

总结：问得清 + 答得准，才是一个成熟的客服智能体

把两篇合起来看，一个成熟的企业智能客服智能体，是这样长成的：

能力	解决什么	关键技术
意图分流	该不该转人工	条件判断（关键词）
多轮澄清	用户没说清怎么办	Chatflow + 会话变量 + 记忆 + LLM 判断
知识检索	拿什么回答问题	多知识库检索 + 阈值控制
知识库建设	检索的底座	分段 + 索引 + 检索设置 + 持续更新
兜底	最坏情况怎么办	转人工 / 引导重新描述

三句话收尾：

先会问，再会答——多轮澄清让客服学会"把问题问清楚"，这是上一篇留下的最大缺口
知识库是根——切片、索引、检索这三步调好了，效果提升立竿见影
养，而不是建——知识库和澄清规则都需要持续迭代，一开始做得糙没关系，跑起来、再养聪明

从"能答"到"会问"，从"有个库"到"有个好库"——这两步走完，你的智能客服才算真正上岗。

本文承接《手搓一个企业智能客服问答智能体：基于 Dify 的工作流实战》，工作流基于 Dify Chatflow，多轮澄清依赖会话变量与记忆能力，知识库部分基于 Dify 知识库的标准创建流程。