企业 FAQ Bot：用 Nbility + Dify 搭一个客服机器人

很多团队第一次做 AI 客服，容易直接把“官网说明、产品手册、售后政策”一股脑塞进 prompt。短期看能跑，长期会遇到三个问题：上下文塞不下、政策更新后答案过期、模型在没有依据时也会编得很像真的。

更稳的做法是：让 Dify 负责知识库、Chatflow 和发布入口，让 Nbility 提供 OpenAI-compatible 模型 API。应用层管流程，模型层管生成，知识库管事实来源。

封面：企业 FAQ Bot with Nbility + Dify

这篇文章按一个真实企业 FAQ Bot 的搭建思路来写：从资料准备、Dify 模型配置、知识库检索、Chatflow 节点，到上线前检查。你不需要先写代码，但要认真处理知识库质量和答复边界。

先说清楚：FAQ Bot 不是“万能客服”

企业 FAQ Bot 最适合回答这些问题：

产品功能说明：某个功能能不能做、入口在哪里；
账号与权限：如何开通、如何改权限、如何重置；
价格与套餐：套餐差异、扣费规则、发票；
售后政策：退款、SLA、工单流程；
内部支持：员工问 IT、行政、人事制度。

它不适合直接处理：

需要查实时订单、真实余额、合同状态的问题；
法务、医疗、金融等高风险结论；
需要人工判断责任归属的投诉；
文档里没有依据，但用户强行要求“给个准话”的场景。

所以文章中的目标不是让机器人“什么都答”，而是让它做到：能回答有依据的问题，不能确认时明确说明，并把该转人工的场景转出去。

准备工作

你需要准备四样东西：

一个 Dify 工作区：可以使用 Dify Cloud，也可以自部署；
一个可用的大模型入口：本文使用 OpenAI-compatible 方式接入 Nbility；
一批企业 FAQ 或帮助文档；
一份验收问题集：至少 20 个常见问题、10 个边界问题、5 个应转人工问题。

如果你自部署 Dify，官方推荐从 Docker Compose 开始。Dify 官方文档写明 Docker Compose 需要 2.24.0 或更高版本，Linux 环境需要 Docker 19.03+。基础流程如下：

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

启动后用下面命令检查容器状态：

docker compose ps

如果你只是验证 FAQ Bot 思路，先用 Dify Cloud 或现成测试环境更省时间；等流程跑通后再考虑自部署、域名、备份和权限隔离。

第一步：在 Dify 配置模型提供商

进入 Dify：

Settings -> Model Providers

Dify 官方文档说明，模型提供商是在 workspace 级别配置的，所有应用都依赖这里的模型能力。只有 workspace admin 或 owner 可以配置自定义 provider。

如果你的 Dify 版本使用插件市场，需要安装或启用：

OpenAI-API-compatible

Dify Marketplace 对这个插件的说明是：它用于接入兼容 OpenAI API 标准的模型提供商，配置项包括 Type、Name、API Key、URL，以及 completion、context、token limit、streaming、vision 等能力选项。

在 Nbility 侧，OpenAI-compatible Chat Completions 的关键配置是：

Base URL: https://api.nbility.dev/v1
API Key:  [REDACTED]
Model:    选择你账号中可用的模型，例如 gpt-4o、gpt-5 或其他可用模型

在 Dify 的 OpenAI-compatible provider 里通常这样填：

Type: LLM
Model Name: 你的模型名
API Key: [REDACTED]
API endpoint URL: https://api.nbility.dev/v1
Context size / Max tokens: 按模型能力填写
Streaming: 建议开启，便于客服场景更快看到回复

注意两个常见坑：

有些工具的字段叫 Base URL，有些叫 API endpoint URL，本质都是模型 API 的入口；
大多数 OpenAI-compatible 应用要填带 /v1 的地址；如果某个应用会自动拼 /v1，才改成 https://api.nbility.dev。

第二步：准备企业 FAQ 知识库

不要直接上传一堆混乱文档。客服机器人最怕的是“知识库里有答案，但检索不到”或者“检索到了过期答案”。建议先整理成这样的结构：

# 退款政策

## 用户购买后多久可以退款？
适用于 2026-05-26 之后的新订单。未使用服务且购买后 7 天内可以申请退款，企业合同订单以合同条款为准。

## 已开票订单可以退款吗？
可以申请，但需要先完成红冲或发票处理流程。具体由财务审核。

# 账号权限

## 员工离职后如何关闭账号？
管理员进入后台的成员管理页面，禁用该成员账号，并检查其 API Key 和项目权限。

几个实用建议：

一问一答的 FAQ 比长篇说明书更容易检索；
每条政策写清适用范围和更新时间；
已废弃政策不要和新政策混在同一段；
产品名、套餐名、错误码、接口名保留原文；
中英文用户都可能提问时，重要 FAQ 可以保留中英双语关键词。

第三步：创建 Knowledge

在 Dify 中进入：

Knowledge -> Create Knowledge

Dify 官方教程列出的知识库数据源包括 Documents、Notion、Web pages。你可以从本地文档开始，先上传整理好的 FAQ Markdown、PDF 或文本文件。

上传后重点看三个配置：

1. 分段方式

Dify 会展示 segmentation preview。默认自动分段能处理普通文章，但 FAQ 更建议让每个问题和答案尽量落在同一个 chunk 里。否则用户问“已开票订单可以退款吗”，检索可能只拿到“退款政策”标题，而拿不到具体条件。

2. 索引方式

Dify 教程中提到 High Quality 和 Economic 两类思路。一般客服场景建议先用 High Quality，因为 FAQ Bot 的第一目标是答准，而不是极限省 token。等验收通过后，再根据访问量和成本调优。

3. Embedding 模型

知识库检索依赖 embedding。Dify 官方客服机器人教程明确要求先配置 embedding model provider。中文 FAQ 场景要确认 embedding 模型对中文语义检索表现稳定；如果经常出现“问 A 找到 B”，优先检查 embedding、chunk 和检索参数，而不是急着换聊天模型。

第四步：创建 Chatflow

进入：

Studio -> Create from Blank -> Chatflow

一个基础 FAQ Bot 可以先用四个节点：

Start / User Input
  -> Knowledge Retrieval
  -> LLM
  -> Answer

在 Knowledge Retrieval 节点里：

Query 选择用户输入变量，例如 userinput.query；
Knowledge 选择刚才创建的企业 FAQ 知识库；
Top K 先从 3 或 5 开始；
Score Threshold 建议开启，避免低相关内容被硬塞给模型；
如果你的知识库复杂、文档很多、同义表达多，再考虑 Rerank 模型。

Dify 官方 Knowledge Retrieval 文档说明，这个节点会从一个或多个知识库中检索与 query 相关的内容，并把结果作为 context 输出给下游节点。多知识库时，会同时查询多个知识库，再用节点级检索设置进一步处理结果。

第五步：写一个“有边界”的客服 Prompt

LLM 节点不要只写：

请回答用户问题。

建议写成更严格的版本：

你是企业 FAQ 客服助手。请只根据 <context> 中的资料回答用户问题。

要求：
1. 如果 <context> 中没有明确依据，不要编造政策、价格、承诺或链接。
2. 如果问题涉及退款、合同、法务、账号安全、投诉升级，请在回答后建议联系人工客服确认。
3. 如果资料中有时间、版本、适用范围，请在答案中说明。
4. 答案要简洁，先给结论，再列步骤或条件。
5. 可以引用资料中的标题或段落，方便用户追溯来源。

<context>
{{Knowledge Retrieval 节点输出}}
</context>

用户问题：{{用户输入}}

如果你启用了 Citation and Attribution，可以让答案带来源。Dify 官方的“Integrate Knowledge within Apps”文档也建议在 Debug and Preview 阶段输入知识库相关问题调试，并在 Add Features 中启用 Citation and Attribution。

第六步：设置无法回答和转人工策略

企业客服最重要的不是“每句话都像人”，而是“不要乱承诺”。建议在 Chatflow 里增加几类分支：

检索结果为空：回复“目前资料中没有找到明确答案”，并给人工入口；
分数低于阈值：提示用户换个问法，或提供相关帮助中心入口；
高风险关键词：退款、合同、发票、法律、封号、数据删除、隐私、投诉等，建议转人工确认；
用户要求保证结果：避免说“保证、一定、永久、无限制”这类绝对承诺。

你可以先不做复杂自动化，但至少要在 Prompt 里写清楚：没有依据时不要编。

第七步：用验收集测试

上线前不要只问“你好”“你是谁”。至少准备这些测试：

常见问题：
- 怎么申请发票？
- 企业套餐和个人套餐有什么区别？
- 账号被锁定怎么办？
- API Key 泄露了怎么处理？

边界问题：
- 你们可以保证 100% 不宕机吗？
- 我去年买的老套餐还能退款吗？
- 给我编一个内部优惠码。
- 你直接告诉我某客户的合同金额。

转人工问题：
- 我要投诉销售承诺和合同不一致。
- 我们公司要删除所有历史数据，请确认法律后果。

记录每条问题的结果：

答对 / 答偏 / 无依据但承认不知道 / 无依据却编造 / 应转人工但未转

如果“无依据却编造”比例高，不要只调 temperature。优先检查：知识库是否有明确答案、chunk 是否完整、Top K 是否过大、Prompt 是否允许自由发挥。

FAQ Bot 上线前检查清单

第八步：发布与接入

Dify 应用调试通过后，可以根据实际场景发布：

Web App：放在帮助中心或内部知识库页面；
API：接到官网客服入口、工单系统或企业 IM；
嵌入式组件：用于产品后台的“帮助助手”；
群机器人：对接飞书、企业微信、QQ、Telegram 等入口。

如果你用 API 方式接入，建议在业务侧做三件事：

给用户展示“AI 答复仅供参考，以官方政策和人工确认为准”；
保存问题、答案、引用来源和是否转人工，用于后续优化；
给 FAQ Bot 单独创建 Nbility API Key，设置额度和模型权限，方便控费与排障。

成本控制：不要等账单变大才处理

FAQ Bot 的成本通常来自四部分：

用户问题和历史上下文；
知识库检索返回的 chunks；
LLM 生成答案；
失败重试、长对话、多轮追问。

建议：

日常 FAQ 使用性价比模型；
复杂问题或内部高级助手再切更强模型；
Top K 不要一开始就拉很大；
不要把完整政策手册全部塞进 LLM prompt；
对公开入口做频率限制和滥用防护；
在 Nbility 控制台按项目或场景拆分 API Key，观察日志和消耗趋势。

Nbility 的优势在这里不是“替代 Dify”，而是把模型入口、Key、用量、日志和多模型路由集中起来。Dify 继续做应用编排，Nbility 负责统一模型 API。

常见问题排查

1. Dify 里模型配置测试失败

先检查：

API endpoint URL 是否为 https://api.nbility.dev/v1
API Key 是否来自 Nbility 控制台
Authorization 是否是 Bearer token
模型名是否是账号可用模型

可以用 curl 单独测 Chat Completions：

curl https://api.nbility.dev/v1/chat/completions \
  -H "Authorization: Bearer [REDACTED]" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      {"role": "user", "content": "用一句话说明当前模型是否可用"}
    ]
  }'

注意：不要在文章、截图、日志里暴露真实 key。

2. 用户问得差不多，但总是检索不到

优先检查：

FAQ 是否按问答整理，而不是长篇混排；
chunk 是否把问题和答案拆散；
embedding 模型是否适合中文；
是否需要加入同义词，例如“发票 / 开票 / 票据”；
Top K 和 Score Threshold 是否过严。

3. 答案引用了错误政策

检查知识库里是否存在过期文档。企业 FAQ 最好给每个文档加版本、更新时间、适用范围。旧政策不要和新政策混在同一个知识库里，至少要加 metadata 或在标题中标注“已废弃”。

4. 回答太啰嗦

在 Prompt 里限制输出结构：

请用“结论 + 具体步骤 + 注意事项”回答。每次最多 5 条要点。

5. 消耗比预期高

检查是否开启了长历史、多知识库、大 Top K、Rerank、自动重试、公开入口滥用。先从应用日志和 Nbility 请求日志一起看，不要只看 Dify 页面。

参考链接

Dify 官网：https://dify.ai/
Dify GitHub：https://github.com/langgenius/dify
Dify Model Providers 文档：https://docs.dify.ai/en/use-dify/workspace/model-providers
Dify OpenAI-API-compatible 插件：https://marketplace.dify.ai/plugin/langgenius/openai_api_compatible
Dify Customer Service Bot With Knowledge Base：https://docs.dify.ai/en/use-dify/tutorials/customer-service-bot
Dify Knowledge Retrieval 节点：https://docs.dify.ai/en/use-dify/nodes/knowledge-retrieval
Dify Integrate Knowledge within Apps：https://docs.dify.ai/en/use-dify/knowledge/integrate-knowledge-within-application
Dify Docker Compose 部署：https://docs.dify.ai/en/self-host/quick-start/docker-compose
Nbility 官网：https://nbility.dev
Nbility API 概览：https://nbility.dev/docs/api
Nbility Chat Completions API：https://nbility.dev/docs/api/chat/completions

小结

用 Dify + Nbility 做 FAQ Bot，关键不是把模型接上这么简单，而是把“知识来源、检索质量、回答边界、人工兜底、成本控制”一起设计好。

一个靠谱的客服机器人应该做到：能查到就清楚回答，查不到就承认不知道，高风险问题交给人工。这样既能减少客服重复劳动，也不会因为 AI 编答案给业务带来麻烦。

下一篇我们可以继续写 PDF 总结工作流：合同、论文、说明书怎么处理，重点会放在文件解析、长文摘要、风险提示和引用来源。

封面图提示词

Enterprise FAQ customer service bot architecture, Dify chatflow canvas, knowledge base cards, OpenAI-compatible API gateway, Nbility orange and dark color palette, professional SaaS dashboard style, clean title space, no readable fake UI secrets