Dify 生产落地案例

五、生产落地案例

案例一：SaaS 公司的客服知识库问答

业务背景：一家 SaaS 公司客服团队约 20 人，重复问题占比高，新人上手慢，历史资料沉淀在文档系统里，检索主要靠关键词搜索，命中率不稳定。

怎么搭：把产品文档、常见问题、售后政策分成三个知识库导入，按业务线分开而不是混成一个库；用 Chatflow 而不是纯聊天助手，因为需要先判断问题类型（计费、使用、故障），再走不同的检索与话术分支。前端在工单系统里嵌入 WebApp 的对话组件，客服边聊边查；同时把 Chatflow 开放成 API，接到官网的在线咨询入口。

关键配置：问题分类节点做意图路由；每个分支的知识检索节点只挂对应知识库，缩小召回范围比一个大库全量召回准确得多；模型温度调低；开启标注回复处理高频重复问题；回答末尾固定输出来源文档标题，让客服能一眼核对。

效果口径：用客服采纳率（回答被直接采用的比例）与首次响应时长两个指标衡量，而不是看模型自评分。上线后先用两周日志积累标注，再把高频问题的标注回复打开。

踩过的坑与解决：

• 检索质量差：初期把三份文档塞进一个知识库，召回经常串业务线，答非所问。改为按业务线拆库，加分类节点路由之后明显改善。
• 知识库更新不同步：文档改了但没有重新索引，回答还是旧政策，属于最危险的一类错误。解决是把「文档更新后重新上传并重建索引」写进内容发布流程，并指定专人负责。
• 并发高时超时：促销日咨询量翻倍，接口开始超时。定位到瓶颈在模型供应商的速率限制与自托管实例规格，处理方式是网关层加排队与降级（超时返回「请稍后重试」而不是直接报错）、按实测扩容实例，并与模型服务方申请提高配额。
• 成本失控：早期每个问题都走大模型加长上下文。改为先用小模型做意图分类，只对复杂分支走大模型，并给检索结果设 Top K 上限，成本随之回落。

案例二：内容团队的批量摘要与结构化抽取

业务背景：内容团队每周要处理上百份行业报告，人工提取公司、金额、时间、结论并撰写摘要，耗时且标准不统一。

怎么搭：建一个 Workflow 应用，输入为文件列表。用迭代节点逐个处理：文档提取器解析文本，LLM 节点做摘要，参数提取器抽取结构化字段，代码节点校验字段完整性，变量聚合汇总结果，结束节点输出结构化数组。整个 Workflow 通过 /v1/workflows/run 由内部系统调用，结果写回内部数据库。

关键配置：提示词里写死输出字段结构；提取不到的字段要求返回空值而不是猜测；代码节点做一次字段校验，缺失的标记为待人工复核而不是直接入库；迭代节点设置并发上限，避免触发模型限流。

效果口径：以人工复核修改率与单份文档处理耗时衡量。目标是让机器完成初稿，人工只做抽检，而不是追求零人工。

踩过的坑与解决：模型偶发返回带代码块标记的内容，导致下游解析失败——在提示词里禁止代码块，并在代码节点里做容错清洗；长文档超出上下文导致截断——先用文档提取器解析，再按章节切分后迭代处理，而不是把全文硬塞进去。