DeepSeek与Dify工作流第二期实战指南

在之前的系列文章中，我们探讨了知识库搭建与大模型调用的基本流程。今天，我们将通过一个完整的实战案例，直接演示如何利用工作流高效生成SQL查询语句，将工作效率提升至新高度。整体流程并不复杂，但细节决定成败，尤其在知识库处理与大模型配置环节需要格外注意。

若你尚未阅读过往内容，建议先翻阅以下系列文章作为基础：

• DeepSeek+Dify工作流的使用(一)
• DeepSeek+Dify打造数据库查询专家修正(一)
• DeepSeek+Dify打造数据库查询专家
• Dify个人助理本地搭建快速入门

本期实战分享：借助工作流生成SQL查询的完整演示

整体效果与核心流程说明

1. 整体工作流程如下图所示，清晰展示了从用户输入到SQL生成的完整路径：

2. 查询效果示例：

用户输入查询内容：查询用户名为admin的邮箱

3. 大模型的关键配置参数如下：

实战中可能遇到的典型问题与解决方案

• 输出结果不理想，生成的SQL语句存在错误

无需慌张，这种情况通常源于知识库设置不当。以下是逐步排查与优化方案：

1. 知识库的质量是核心。在前两篇文章（DeepSeek+Dify打造数据库查询专家及其修正版）中，我们详细讲解了处理方法。关键点在于：将数据库表的结构说明拆分为独立的段落，确保每段可以单独检索，这样知识库的匹配与召回精度会大幅提升。
2. 若知识库内容本身无误但效果依旧欠佳，则应从提示词入手，进一步强化关键指令与上下文信息。
3. 建议先使用聊天助手模块独立测试知识库的召回效果，确认其是否能准确返回相关内容。
4. 最终解决方案：更换为更强大的模型（例如DeepSeek-R1-70B），以提升推理与生成质量。

• 生成内容中包含了大量思考过程（如截图所示的多余Thinking内容）

该问题可通过两步策略有效解决：

1. 首先，在提示词中明确要求模型禁止输出思考过程。如果此方法无法彻底压制——因为DeepSeek-R1-70B的thinking内容是强制生成的，要完全去除需修改底层代码——则可采用上一篇文章中介绍的方案，通过编写代码逻辑将其过滤掉。
2. 具体实现：直接向大模型索要一段Python过滤代码，用于去除
   标签内的所有内容。需注意，处理对象为字符串类型，建议在本地Python IDE中验证代码的准确性，因为Dify环境内无法直接调试。

测试用参考代码如下：

{
  "text": "
 
 Thinking... 
嗯，我现在需要帮用户写一个SQL语句来查询用户名为admin的邮箱。首先，我得确定用户的需求是什么。他们有两个表，CHAT_USER和CHAT_MSG。CHAT_USER表里有用户的基本信息，包括邮箱，而CHAT_MSG表主要是聊天信息，应该和邮箱查询关系不大。nn首先，我应该直接从CHAT_USER表中获取数据，因为邮箱字段就在那里。用户只需要邮箱，所以不需要连接到其他表。接下来，我需要找到用户名为admin的记录。CHAT_USER表的USER_NAME字段就是用户名，所以条件应该是USER_NAME = 'admin'。nn然后，我要确保只返回邮箱这一列，所以SELECT语句后面应该是USER_EMAIL。同时，可能有多个用户有相同的用户名，所以可能会返回多行，但用户可能只需要一条，或者不管有多少，都要返回所有符合条件的邮箱。nn另外，是否需要考虑大小写的问题？比如，Admin和admin是否不同，这取决于数据库的配置。如果用户明确是admin，那么直接用='admin'就可以了。nn最后，写出SQL语句：SELECT USER_EMAIL FROM CHAT_USER WHERE USER_NAME = 'admin'; 这样就能直接获取到结果了。n
nnSELECT USER_EMAIL FROM CHAT_USER WHERE USER_NAME = 'admin';",
}

import re
def main(sql_str) -> dict:
    # 使用正则表达式去除
标签及其内容
    pattern = re.compile(r'', re.DOTALL)
    sql = pattern.sub('', sql_str)
    return {
        "result": sql,
    }

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：DeepSeek与Dify工作流第二期实战指南要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题