Dify平台内置实体识别抽取关键信息-洪萨配资

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 搭建了一个全自动工单生成系统，架构如下：

具体流程也很清晰：

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

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

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