客服还在翻产品文档?用 Dify 搭 1 个问答 API,4 步把召回调准

本周帮一个内部系统加“问文档”入口，我第一版偷懒，把整份产品手册直接丢给大模型。用户问“试用期能不能开发票”，它回了一大段账号权限说明，唯独没提发票。这不是模型不够聪明，是我没把它该看的资料切好，也没让它只答有依据的内容。

这类需求我现在会优先用 Dify 做。README 里对它的定位是开源 LLM 应用开发平台，里面包含 AI workflow、RAG pipeline、agent、模型管理、观测能力等。我们这篇只用两个明确写进文档的能力：RAG Pipeline 覆盖从文档摄取到检索，并对 PDF、PPT 等常见格式的文本提取有开箱支持；Backend-as-a-Service 说明 Dify 的能力都带 API，可以接回自己的业务。

换句话说，做“产品文档问答”这条路是成立的：先把文档喂进去，再调好分段和召回，最后用 API 嵌到官网、客服系统或内部后台。

先跑起来：云端试用或本地 Docker

如果只是验证想法，可以直接用 Dify Cloud，不用自己维护服务器。想部署在自己环境里，README 给了 Docker Compose 路线。机器要求也不高：CPU 至少 2 Core，内存至少 4 GiB；本机要有 Docker 和 Docker Compose v2.24.0 或更高版本。

自托管可以这样启动：

cd dify cd docker cp .env.example .env docker compose up -d

跑完后访问 http://localhost/install 做初始化。这里我踩过一个坑：别急着上传文档，先确认服务能正常打开。部署出问题，文档里也提到去看 FAQ，再找社区。

第 1 步：别把一整本手册直接塞进去

Dify 的 RAG 能力包含文档摄取和检索，也支持 PDF、PPT 等常见文档格式。但我建议上传前先人工整理一遍，不然召回回来的内容会很杂。

我会按这个清单处理产品文档：

1. 一个标题尽量只讲一件事。比如“如何申请退款”就单独一节，不要和“发票规则”混在一起。

2. 用户常用问法要写进正文。比如“开票”“发票”“增值税普通发票”这类词，别只写一个内部黑话。

3. 版本、适用范围、前置条件要跟着正文走。很多错误答案不是模型编，而是它不知道这条规则只对某个版本有效。

4. 图片里的关键信息尽量转成文字。README 只说了文本提取，对图片内文字没有承诺，所以别把核心规则只放在截图里。

这一步看起来土，但后面会省很多调 prompt 的时间。

第 2 步：分段的目标，是让每一段都能独立回答一个问题

导入知识库后，重点看分段。官方 README 没有在这里给死参数，所以我不编某个具体字数或按钮。我的判断标准只有 3 个：

1. 这一段能不能单独回答一个问题？

2. 它有没有必要的上下文，比如标题、适用范围、例外条件？

3. 它是不是太长，把无关内容也带进来了？

举个例子。产品文档里常见这种结构：

退款规则 - 7 天内可退 - 已使用的额度不退 - 企业合同另有约定的，以合同为准

如果切得太碎，模型可能只拿到“7 天内可退”，丢掉“企业合同另有约定”；如果切得太长，它又会把计费、发票、账号注销一起拖出来。我的处理方式是把“退款规则”作为一段，保留完整限制条件，再把“企业合同例外”拆成补充说明，避免和通用规则混在一起。

分段没有魔法数值，只有“能不能独立回答”。

第 3 步：召回不准，先改资料，不先骂模型

召回这件事，说人话就是：用户提问后，系统到底找到了哪几段资料。Dify 的 README 明确提到 RAG 覆盖文档摄取到检索，所以调优也要围绕“摄取进去的内容”和“检索出来的内容”。

我一般会准备 10 个真实问题，覆盖 4 类：

1. 用户原话，比如“怎么改绑手机号？”

2. 口语说法，比如“手机号换了咋整？”

3. 边界条件，比如“海外账号能不能改绑？”

4. 容易混淆的问题，比如“改绑后原账号数据还在吗？”

测的时候不要只看最终答案，要看它有没有找到对应段落。常见情况是 3 种：

• 找不到：标题不够清楚，正文缺少同义词，或者关键内容被埋在长段落里。
• 找错：相邻章节太像，需要拆开，或者把适用范围写明白。
• 找到但答偏：段落里有噪声，删掉无关句子，或者把结论提前。

至于引用，我倾向于把它当成验收标准：对外问答最好让用户看到答案来自哪一节。README 没有细写引用按钮，所以这里不编具体入口；如果你的 Dify 版本里能看到来源展示相关选项，建议打开。如果没有，也可以在 prompt 里要求模型回答时标注章节名。这属于我的使用建议，不是文档固定配置。

第 4 步：用 API 嵌进真实业务

只做一个聊天窗口，价值有限。真正好用的是把它嵌到用户已经在用的地方。README 里有一句很关键：Backend-as-a-Service，所有 Dify 能力都有对应 API，可以无缝集成到自己的业务逻辑里。

工程上我会这样做：

1. 在 Dify 里完成问答应用和知识库挂接。

2. 找到该应用的 API 访问方式，密钥放在服务端，不要暴露到前端页面。

3. 前端只负责收集问题和展示答案，请求由后端转发。

4. 把“没答上来”的问题记下来，定期回补文档。

具体 API 路径和字段，我这里不编。README 没有展开接口细节，实际要以你部署的 Dify 文档和页面为准。可以确定的是，方向不是“做一个演示”，而是把它当成一个可调用服务。

两个容易忽略的坑

1. 模型不是越大越好。README 说 Dify 支持大量模型，包括 GPT、Mistral、Llama3 和任何 OpenAI API-compatible 模型。产品文档问答很多时候瓶颈在召回，不在模型文采。先用便宜稳定的模型把链路跑通，再决定要不要升级。

2. 上线不是结束。README 提到 LLMOps，可以监控和分析应用日志与表现，并基于生产数据持续改 prompt、数据集和模型。我建议每周看一次“答错或答非所问”的日志，把高频问题补进文档。

一句话收尾：产品文档问答不是靠模型硬猜，而是把资料切准、召回调稳，再用 Dify 的 API 接进真实业务。