实战案例
三个由浅入深的例子:知识库 FAQ、分类后回答的工作流、用 Python 调 Service API。请先完成 快速上手 与至少一个 模型供应商。
案例 1:带知识库的 FAQ Bot
目标: 同事用自然语言问内部制度,回答必须能指向文档,而不是模型「感觉上对」。
准备一份 faq.md(示例片段):
步骤:
- Knowledge:新建库,上传
faq.md,分块用 General 或 Parent-child,索引 High Quality + 混合检索 - 检索测试:「市内交通一天能报多少?」应命中「80 元」那一段
- 新建 Chatbot,绑定该知识库
- 提示词写死依据与拒答,例如:
- 预览再问一句文档里没有的「加班餐补」——应走拒答,而不是编一个数
- Publish Web App,用另一浏览器打开验收
对照 LangChain 文档问答:那里自建 Retriever;这里知识库替代了那 30 行索引代码。
案例 2:先分类,再回答的 Workflow / Chatflow
目标: 制度问题走检索;闲聊或无关问题走固定拒答,避免把整库当搜索引擎扫。
在 Studio 新建 Chatflow(要对话壳)或 Workflow(只要 API 一次出结果)。画布:
- User Input — 用户消息作为
query - Question Classifier — 类别:
policy(差旅/设备/报销)、chitchat(问候)、other policy→ Knowledge Retrieval(案例 1 的库,query = 用户消息)→ LLM(仅依据检索)chitchat→ LLM(短欢迎 + 说明只能答制度)other→ LLM 或 Template(固定句子:「请改述为制度相关问题」)- 各边连到 Answer(Chatflow)或 Output(Workflow)
准备 15 条标注过的问句,看分类是否稳定。不稳就改类别描述(写成「询问金额、发票、工号领取」而不是一个词 policy)。这比纯 Agent 更适合合规:路径在图上,不在模型心情里。
案例 3:Python 后端集成
目标: 你们自己的站点收用户问题,服务端调用 Dify,不把 Key 暴露给浏览器。
user 用你们登录系统里的稳定 id。第二问必须带上 conversation_id,否则模型不知道「那」指什么。Chat 应用用 /v1/chat-messages;纯 Workflow 用该应用 API 页上的 run 接口并传 inputs。