企业官网建设流程全解析

Dify平台如何用“零代码”实现精准实体识别

在企业每天处理成千上万条客户反馈的今天，如何从一段杂乱无章的对话中快速提取出“谁、遇到了什么问题、什么时候发生的”这些关键信息？传统做法是让客服手动填写工单，或者写一堆正则表达式去匹配电话号码和订单号——前者效率低，后者维护成本高得吓人。而如今，借助像 Dify 这样的开源 AI 应用开发平台，我们只需要点几下鼠标，就能构建一个自动解析用户消息、精准抽取结构化数据的智能系统。

这背后的核心能力之一，就是基于大语言模型（LLM）的内置实体识别。它不是靠训练专用 NER 模型，也不依赖复杂的代码逻辑，而是通过提示工程与可视化流程编排，把信息抽取变成一种“可配置”的标准操作。这种模式正在重新定义企业级 AI 应用的构建方式。

实体识别的新范式：从规则到语义理解

过去做实体识别，基本逃不开两种路径：一是写正则，二是训模型。前者面对“我付款失败了”、“支付没成功”、“钱扣了但没下单”这类多样表达束手无策；后者虽然准确率高，但需要大量标注数据、长时间训练和专业算法团队支持，中小团队根本玩不转。

Dify 换了个思路：既然现在的 LLM 已经能读懂人类语言，为什么不直接让它来“读这段话，然后告诉我客户姓名、电话和问题类型”？

这就是它的核心机制——Prompt + Schema 引导生成。你不需要告诉模型怎么分析语法、怎么找命名实体，只需要清晰地描述任务，并规定输出格式。比如：

请从以下文本中提取客户姓名、联系电话和问题类型，按如下 JSON 格式返回：

json { "customer_name": "", "phone_number": "", "issue_type": "" }

听起来简单，但这套方法之所以有效，是因为现代大模型本身就具备强大的上下文学习（In-context Learning）能力。只要提示词设计得当，哪怕从未见过这个字段，也能完成抽取。换句话说，这是一种真正意义上的零样本（Zero-shot）信息抽取方案。

更妙的是，整个过程完全可以通过图形界面完成配置。你在 Dify 的工作流里拖一个“LLM 节点”，填入预设的提示模板，再定义好输出结构，保存发布——搞定。连 Python 都不用打开。

# 实际上，Dify 后台可能就是这样构造 Prompt 的 def build_extraction_prompt(text, schema): return f""" 请从以下文本中提取指定信息，并严格以JSON格式输出： 【输入文本】 {text} 【提取要求】 {json.dumps(schema, ensure_ascii=False, indent=2)} 【输出格式】 ```json {{"customer_name": "...", "phone_number": "...", "issue_type": "..."}}

”“”

这段代码模拟了 Dify 内部如何将业务需求转化为模型可理解的指令。关键是那个 `schema`——它不仅定义了字段名，还能约束类型、枚举值、是否必填等。例如，“问题类型”只能是“账号异常”、“支付失败”或“物流查询”之一。这样一来，即使模型有点“自由发挥”，也会被拉回预定轨道。 而且一旦业务变化，比如新增一个“是否紧急”的字段，怎么办？传统方案要改代码、重训练、重新部署；而在 Dify 上，只需在界面上添加一行配置，立即生效。这才是真正的敏捷响应。 --- ## 可视化编排：让非技术人员也能搭建 AI 流程 如果说 Prompt 是“大脑”，那流程编排就是“神经系统”。Dify 的另一个杀手锏，就是它的图形化工作流引擎。 想象你要做一个智能客服系统，流程大概是这样：收到用户消息 → 判断是否售后问题 → 如果是，提取客户信息和问题类型 → 存入数据库 → 发通知给处理人。以前这得写一堆服务、接口、状态机；现在，在 Dify 里只需要拖几个节点连起来就行。 每个节点代表一个功能模块： - **输入节点**：接收 API 请求或表单提交； - **LLM 节点**：调用大模型执行文本理解或生成； - **条件分支**：根据模型输出决定下一步走向； - **知识检索节点（RAG）**：从外部库查资料辅助判断； - **函数节点**：执行简单计算或数据转换； - **输出节点**：返回结果或触发下游系统。 这些节点组成一个有向无环图（DAG），平台会按照连接顺序依次执行。你可以实时查看每一步的中间输出，调试起来非常直观。更重要的是，产品经理、运营人员也可以参与流程设计，不再全靠工程师翻译需求。 我还见过一家电商公司在 Dify 上三天搭出了一个退货原因分类系统：前端接客服聊天记录，后端连 RAG 查历史案例，中间用 LLM 抽取“问题类型”，最后自动打标签入库。整个过程没人写一行代码，全是拖拽完成的。 --- ## RAG 加持：让模糊表达也能被准确理解 当然，光靠 Prompt 并不能解决所有问题。当用户说“东西不对”、“发错了”、“不是我要的那个”时，你怎么确保模型每次都归类为“发错货”而不是“质量问题”？ 这时候就得引入 RAG（Retrieval-Augmented Generation）机制了。 RAG 的本质是“先查再答”。Dify 支持将企业内部的知识文档、历史工单、产品目录等上传并建立向量索引。当新请求进来时，系统会先在知识库中搜索语义最接近的片段，然后把这些参考内容一并传给大模型。 举个例子： > 用户说：“衣服颜色发错了。” > 系统检索发现，过去类似表述都被归类为“发错货”，且属于“可换货不可退款”政策范围。 > 于是 Prompt 变成： > > ``` > 请根据以下上下文提取问题类型： > > 【用户输入】 > 衣服颜色发错了 > > 【参考知识】 > - “颜色不对” → 问题类型：“发错货” > - “尺寸不合适” → 问题类型：“尺码问题” > - “有破损” → 问题类型：“商品损坏” > > 输出格式：{"issue_type": "..."} > ``` 有了这些上下文线索，模型几乎不会出错。而且随着知识库不断积累，系统的判断也会越来越准。 Dify 原生支持主流向量数据库（如 Milvus、Pinecone、FAISS），并且能自动完成文本分块、嵌入生成和索引管理。你只需要上传 PDF 或 Excel 文件，剩下的交给平台就好。 --- ## 实战场景：智能工单自动生成系统 来看一个真实落地的应用案例。 某电商平台每天收到数千条客服对话，人工录入工单耗时费力。他们用 Dify 搭建了一个全自动工单生成系统，架构如下：

+----------------------+
| 用户输入层 | ← 微信客服消息 / APP 内反馈
+----------------------+
↓
+----------------------+
| 流程编排层（Dify） | ← 输入→RAG检索→LLM抽取→输出
+----------------------+
↓
+-----------------------------+
| 外部资源层 |
| - 向量数据库：存储历史工单 |
| - 大模型API：通义千问 |
| - MySQL：存储新工单 |
+-----------------------------+
↓
+----------------------------+
| 输出与集成层 |
| - 写入CRM |
| - 企业微信告警 |
| - 触发仓储换货流程 |
+----------------------------+
```

具体流程也很清晰：

1. 用户发送：“我叫李娜，手机号13900001111，订单号20240405A，衣服收到但颜色发错了。”
2. Dify 接收消息，启动流程：
   - 先走 RAG 检索，“颜色发错”命中“发错货”类别；
   - 构造 Prompt，要求提取姓名、电话、订单号、问题类型；
   - 调用通义千问，返回标准 JSON；
   - 将结果写入数据库，并推送告警给售后专员。

全程不到两秒，准确率超过 95%。上线一个月就节省了约 600 小时的人工处理时间。

他们在实践中总结了几条经验：

• Prompt 要足够具体：不要只写“提取信息”，而是明确字段含义，必要时加示例；
• 设置重试机制：LLM API 偶尔超时，Dify 中应配置最多三次重试；
• 增加后处理校验：即使用了 Schema，也要检查关键字段是否为空；
• 敏感信息脱敏：手机号、身份证等字段在日志中需掩码显示；
• 开启运行日志：方便追踪异常案例，持续优化提示词。

为什么这种方式正在成为主流？

Dify 的这套实体识别方案，本质上是一种“低代码 + 大模型”的工程实践创新。它解决了几个长期困扰企业的痛点：

• 开发门槛太高？不再需要 NLP 工程师写模型、调参数，普通开发者甚至业务人员都能上手。
• 响应速度太慢？字段变更无需发版，修改即生效，适应快速迭代的业务节奏。
• 语义理解不准？LLM 比规则更能应对口语化、多义性表达，配合 RAG 还能动态增强上下文。
• 系统难以集成？Dify 支持一键发布为 API 或 Web 应用，轻松对接现有系统。

更重要的是，它把开发者从繁琐的技术实现中解放出来，专注于定义问题本身：我们要提取哪些信息？依据什么规则分类？后续如何使用？这才是创造价值的核心。

未来，随着更多企业将大模型融入日常运营，类似 Dify 这种集成了 Prompt 工程、流程编排、RAG 和可观测性的平台，将成为 AI 落地的基础设施。它们不一定取代传统的机器学习流水线，但在中小规模、高频变化的信息处理场景中，无疑提供了更高效、更灵活的选择。

这种高度集成的设计思路，正引领着企业智能化进程向更可靠、更高效的方向演进。