Dify 中获取所有会话记录方法

已于 2024-11-17 17:02:45 修改
阅读量4.1k 收藏 16
点赞数 14
分类专栏： # 第3部分 Dify聊天助手-工作流编排 文章标签： dify chatflow
于 2024-11-15 23:56:23 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ssw_1990/article/details/143810167
版权

一.通过日志页面查看所有会话记录

点击"日志与标注"，在日志页面，日志记录了应用的运行情况，包括用户的输入和 AI 的回复。如下所示：

1.chat-conversations 接口

实际调用接口，如下所示：

http://localhost:5001/console/api/apps/81dfcbc5-20be-4b8b-b5e9-c1289de39bdf/chat-conversations

2.接口源码位置

源码位置：dify\api\controllers\console\app\conversation.py

二.chat-conversations 接口源码分析

1.get(self, app_model)源码注释

该接口实现用于从数据库中查询 Conversation 表的数据。它支持多种过滤条件，如关键词搜索、时间范围、标注状态、消息数量、排序等。查询结果经过分页处理，并根据请求参数返回符合条件的对话记录。

def get(self, app_model):
    # 检查当前用户是否为editor，若不是则抛出 Forbidden 异常
    if not current_user.is_editor:
        raise Forbidden()

    # 创建请求参数解析器
    parser = reqparse.RequestParser()

    # 添加请求参数（包括类型、位置等）
    parser.add_argument("keyword", type=str, location="args")  # 关键词参数，用于搜索
    parser.add_argument("start", type=DatetimeString("%Y-%m-%d %H:%M"), location="args")  # 起始时间
    parser.add_argument("end", type=DatetimeString("%Y-%m-%d %H:%M"), location="args")  # 结束时间
    parser.add_argument(
        "annotation_status", 
        type=str, 
        choices=["annotated", "not_annotated", "all"], 
        default="all", 
        location="args"
    )  # 标注状态参数，默认为all
    parser.add_argument("message_count_gte", type=int_range(1, 99999), required=False, location="args")  # 消息数量大于等于此值
    parser.add_argument("page", type=int_range(1, 99999), required=False, default=1, location="args")  # 页码，默认为1
    parser.add_argument("limit", type=int_range(1, 100), required=False, default=20, location="args")  # 每页条数，默认为20
    parser.add_argument(
        "sort_by",
        type=str,
        choices=["created_at", "-created_at", "updated_at", "-updated_at"],
        required=False,
        default="-updated_at",
        location="args",
    )  # 排序方式，默认按更新日期降序
    # 解析请求参数
    args = parser.parse_args()

    # 创建一个子查询，连接 Conversation 表和 EndUser 表，获取 Conversation 的 id 和 EndUser 的 session_id
    subquery = (
        db.session.query(
            Conversation.id.label("conversation_id"), EndUser.session_id.label("from_end_user_session_id")
        )
        .outerjoin(EndUser, Conversation.from_end_user_id == EndUser.id)  # 外连接 EndUser 表
        .subquery()  # 将查询结果作为子查询
    )

    # 创建查询对象，查询 Conversation 表，条件是 app_id 匹配
    query = db.select(Conversation).where(Conversation.app_id == app_model.id)

    # 如果有关键词，进行关键词搜索
    if args["keyword"]:
        keyword_filter = "%{}%".format(args["keyword"])  # 使用 LIKE 进行模糊搜索
        query = (
            query.join(
                Message,
                Message.conversation_id == Conversation.id,  # 连接 Message 表
            )
            .join(subquery, subquery.c.conversation_id == Conversation.id)  # 连接子查询
            .filter(
                or_(
                    Message.query.ilike(keyword_filter),
                    Message.answer.ilike(keyword_filter),
                    Conversation.name.ilike(keyword_filter),
                    Conversation.introduction.ilike(keyword_filter),
                    subquery.c.from_end_user_session_id.ilike(keyword_filter),
                ),
            )
            .group_by(Conversation.id)  # 按 Conversation.id 分组
        )

    # 获取当前用户信息
    account = current_user
    timezone = pytz.timezone(account.timezone)  # 获取当前用户的时区
    utc_timezone = pytz.utc  # UTC 时区

    # 如果有开始时间参数，转换并过滤相应的日期范围
    if args["start"]:
        start_datetime = datetime.strptime(args["start"], "%Y-%m-%d %H:%M")  # 将字符串转换为日期时间对象
        start_datetime = start_datetime.replace(second=0)  # 去除秒数部分

        start_datetime_timezone = timezone.localize(start_datetime)  # 转换为用户本地时区时间
        start_datetime_utc = start_datetime_timezone.astimezone(utc_timezone)  # 转换为 UTC 时区

        match args["sort_by"]:
            case "updated_at" | "-updated_at":
                query = query.where(Conversation.updated_at >= start_datetime_utc)  # 过滤更新时间大于等于开始时间的记录
            case "created_at" | "-created_at" | _:
                query = query.where(Conversation.created_at >= start_datetime_utc)  # 过滤创建时间大于等于开始时间的记录

    # 如果有结束时间参数，转换并过滤相应的日期范围
    if args["end"]:
        end_datetime = datetime.strptime(args["end"], "%Y-%m-%d %H:%M")  # 将字符串转换为日期时间对象
        end_datetime = end_datetime.replace(second=59)  # 设置为最后一秒

        end_datetime_timezone = timezone.localize(end_datetime)  # 转换为用户本地时区时间
        end_datetime_utc = end_datetime_timezone.astimezone(utc_timezone)  # 转换为 UTC 时区

        match args["sort_by"]:
            case "updated_at" | "-updated_at":
                query = query.where(Conversation.updated_at <= end_datetime_utc)  # 过滤更新时间小于等于结束时间的记录
            case "created_at" | "-created_at" | _:
                query = query.where(Conversation.created_at <= end_datetime_utc)  # 过滤创建时间小于等于结束时间的记录

    # 根据标注状态进行筛选
    if args["annotation_status"] == "annotated":
        query = query.options(joinedload(Conversation.message_annotations)).join(
            MessageAnnotation, MessageAnnotation.conversation_id == Conversation.id  # 加载 MessageAnnotation 表
        )
    elif args["annotation_status"] == "not_annotated":
        query = (
            query.outerjoin(MessageAnnotation, MessageAnnotation.conversation_id == Conversation.id)  # 外连接 MessageAnnotation 表
            .group_by(Conversation.id)
            .having(func.count(MessageAnnotation.id) == 0)  # 仅包含没有标注的对话
        )

    # 根据消息数量筛选
    if args["message_count_gte"] and args["message_count_gte"] >= 1:
        query = (
            query.options(joinedload(Conversation.messages))  # 加载 Conversation 中的消息
            .join(Message, Message.conversation_id == Conversation.id)  # 连接 Message 表
            .group_by(Conversation.id)
            .having(func.count(Message.id) >= args["message_count_gte"])  # 仅包含消息数量大于等于 message_count_gte 的对话
        )

    # 如果应用模式是高级聊天，则过滤掉调试模式的对话
    if app_model.mode == AppMode.ADVANCED_CHAT.value:
        query = query.where(Conversation.invoke_from != InvokeFrom.DEBUGGER.value)

    # 根据排序字段对查询结果进行排序
    match args["sort_by"]:
        case "created_at":
            query = query.order_by(Conversation.created_at.asc())  # 按创建时间升序排序
        case "-created_at":
            query = query.order_by(Conversation.created_at.desc())  # 按创建时间降序排序
        case "updated_at":
            query = query.order_by(Conversation.updated_at.asc())  # 按更新时间升序排序
        case "-updated_at":
            query = query.order_by(Conversation.updated_at.desc())  # 按更新时间降序排序
        case _:
            query = query.order_by(Conversation.created_at.desc())  # 默认按创建时间降序排序

    # 使用分页查询返回结果
    conversations = db.paginate(query, page=args["page"], per_page=args["limit"], error_out=False)

    # 返回分页查询的结果
    return conversations

2.子查询

这个查询从 Conversation 和 EndUser 表中选取相关数据，并通过左外连接来确保即使某些 Conversation 记录没有对应的 EndUser 记录，仍然能返回数据。最终，查询返回的字段包括 Conversation 的 id（重命名为 conversation_id）和 EndUser 的 session_id（重命名为 from_end_user_session_id）。

subquery = (
    db.session.query(
        Conversation.id.label("conversation_id"), EndUser.session_id.label("from_end_user_session_id")
    )
    .outerjoin(EndUser, Conversation.from_end_user_id == EndUser.id)
    .subquery()
)

（1）创建子查询 (subquery)：首先定义了一个子查询。这个子查询从数据库中选择了 Conversation 表的 id 字段，并将其重命名为 conversation_id，以及从 EndUser 表选择了 session_id 字段，并将其重命名为 from_end_user_session_id。

（2）连接操作 (outerjoin)：查询通过 outerjoin 将 Conversation 表与 EndUser 表连接在一起，连接条件是 Conversation.from_end_user_id 等于 EndUser.id。这意味着，如果 Conversation 中的 from_end_user_id 和 EndUser.id 匹配，则将这两表的数据组合起来。如果没有匹配的记录，EndUser 表中的字段会以 NULL 填充。

（3）生成子查询：通过 .subquery() 方法，将查询转换为一个子查询，这样查询结果不会直接返回，而是可以在其它查询中使用。

3.关键词筛选

这个查询通过 keyword 进行模糊搜索，查找与关键字匹配的消息、会话以及与会话相关的用户信息。它将 Message 表与 Conversation 表连接，并使用子查询中的 EndUser 会话 ID 字段进行联合查询。通过 or_() 函数实现多个字段的模糊匹配，返回所有符合条件的记录。最后，查询通过 group_by 确保按会话（Conversation.id）分组结果。

if args["keyword"]:
    keyword_filter = "%{}%".format(args["keyword"])
    query = (
        query.join(
            Message,
            Message.conversation_id == Conversation.id,
        )
        .join(subquery, subquery.c.conversation_id == Conversation.id)
        .filter(
            or_(
                Message.query.ilike(keyword_filter),
                Message.answer.ilike(keyword_filter),
                Conversation.name.ilike(keyword_filter),
                Conversation.introduction.ilike(keyword_filter),
                subquery.c.from_end_user_session_id.ilike(keyword_filter),
            ),
        )
        .group_by(Conversation.id)
    )

（1）检查 args["keyword"]

  • 首先代码检查 args 字典中的 keyword 是否存在。如果存在，则创建一个名为 keyword_filter 的变量，它将 keyword 进行格式化处理，形成一个带有通配符的字符串（例如 %keyword%）。这样可以在 SQL 查询中进行模糊匹配。

（2）查询构造 (query.join)

然后查询通过 .join() 方法与 Message 表和之前定义的子查询 subquery 进行连接。

  • 连接 Message 表：查询将 Message 表和 Conversation 表连接，连接条件是 Message.conversation_id == Conversation.id，也就是通过 Conversation 表的 id 与 Message 表中的 conversation_id 字段建立关系。
  • 连接子查询 (subquery)：查询还将子查询 subquery 与 Conversation 表连接，连接条件是 subquery.c.conversation_id == Conversation.id，也就是说通过 Conversation.id 与子查询中的 conversation_id 进行关联。

（3）过滤条件 (filter)

  • 连接操作完成后，查询的下一步是通过 .filter() 来添加过滤条件。这里使用了 SQLAlchemy 的 or_() 函数来设置多个条件，只要其中一个条件满足，记录就会被选中。

  • 具体的过滤条件规则

    • Message.query.ilike(keyword_filter)：如果 Message 表中的 query 字段（假设是消息内容）与 keyword_filter 匹配，则返回该记录。ilike 用于不区分大小写的模糊匹配。
    • Message.answer.ilike(keyword_filter)：如果 Message 表中的 answer 字段（假设是回答内容）与 keyword_filter 匹配，则返回该记录。
    • Conversation.name.ilike(keyword_filter)：如果 Conversation 表中的 name 字段（假设是会话的名字）与 keyword_filter 匹配，则返回该记录。
    • Conversation.introduction.ilike(keyword_filter)：如果 Conversation 表中的 introduction 字段（开场白）与 keyword_filter 匹配，则返回该记录。
    • subquery.c.from_end_user_session_id.ilike(keyword_filter)：如果子查询中的 from_end_user_session_id 字段（即 EndUser.session_id）与 keyword_filter 匹配，则返回该记录。

    这样，查询会返回那些 Message 或 Conversation 表中的相关字段，或者子查询中与用户会话 ID 相关的字段与 keyword 模糊匹配的记录。

（4）分组 (group_by)

  • 在所有的连接和过滤条件都应用后，查询通过 .group_by(Conversation.id) 进行分组，按 Conversation.id 分组，以便对每个会话进行聚合操作。这样可以确保每个 Conversation 只返回一次。

说明：因为 Conversation.id 在 conversations 数据表中作为主键，通常情况是唯一的，除非异常情况下会出现重复。

4.时间范围筛选

主要包括今天，过去 7 天，过去 4 周，过去 3 月，过去 12 月，本月至今，本季度至今，本年至今和所有时间这 9 种情况。如下所示：

if args["start"]:
    start_datetime = datetime.strptime(args["start"], "%Y-%m-%d %H:%M")
    start_datetime = start_datetime.replace(second=0)

    start_datetime_timezone = timezone.localize(start_datetime)
    start_datetime_utc = start_datetime_timezone.astimezone(utc_timezone)

    match args["sort_by"]:
        case "updated_at" | "-updated_at":
            query = query.where(Conversation.updated_at >= start_datetime_utc)
        case "created_at" | "-created_at" | _:
            query = query.where(Conversation.created_at >= start_datetime_utc)

if args["end"]:
    end_datetime = datetime.strptime(args["end"], "%Y-%m-%d %H:%M")
    end_datetime = end_datetime.replace(second=59)

    end_datetime_timezone = timezone.localize(end_datetime)
    end_datetime_utc = end_datetime_timezone.astimezone(utc_timezone)

    match args["sort_by"]:
        case "updated_at" | "-updated_at":
            query = query.where(Conversation.updated_at <= end_datetime_utc)
        case "created_at" | "-created_at" | _:
            query = query.where(Conversation.created_at <= end_datetime_utc)

5.标注状态筛选

主要包括全部，已标注改进和未标注这 3 种情况。如下所示：

if args["annotation_status"] == "annotated":
    query = query.options(joinedload(Conversation.message_annotations)).join(
        MessageAnnotation, MessageAnnotation.conversation_id == Conversation.id
    )
elif args["annotation_status"] == "not_annotated":
    query = (
        query.outerjoin(MessageAnnotation, MessageAnnotation.conversation_id == Conversation.id)
        .group_by(Conversation.id)
        .having(func.count(MessageAnnotation.id) == 0)
    )

如果 args["annotation_status"] == "annotated"，查询将执行以下操作：

（1）加载关联数据 (joinedload)

使用 query.options(joinedload(Conversation.message_annotations)) 来指定 SQLAlchemy 在查询 Conversation 表时，自动加载与 Conversation 表相关联的 message_annotations 表的数据。joinedload 是一种优化方法，它会在执行查询时一次性加载所有相关的数据，避免后续的额外查询（即避免 N+1 查询问题）。

（2）连接 (join)MessageAnnotation 表

使用 .join(MessageAnnotation, MessageAnnotation.conversation_id == Conversation.id) 连接 MessageAnnotation 表和 Conversation 表，连接条件是 MessageAnnotation.conversation_id == Conversation.id。这样每个 Conversation 记录将与其对应的 MessageAnnotation 记录关联。

（3）这个部分的查询返回所有已标注 (annotated) 的会话记录（即有对应 MessageAnnotation 记录的会话）。

说明：join 默认执行 内连接，它只返回两个表中都有匹配记录的行。

如果 args["annotation_status"] == "not_annotated"，查询将执行以下操作：

（1）外连接 (outerjoin) MessageAnnotation 表

  • 使用 .outerjoin(MessageAnnotation, MessageAnnotation.conversation_id == Conversation.id) 来外连接 MessageAnnotation 表与 Conversation 表。外连接会返回所有 Conversation 记录，即使没有与之关联的 MessageAnnotation 记录。在没有标注的情况下，MessageAnnotation 中的字段会是 NULL。

（2）分组 (group_by) Conversation.id

  • 使用 .group_by(Conversation.id) 对查询结果按 Conversation.id 进行分组。这样，每个 Conversation 记录只会出现在查询结果中一次。

（3）条件过滤 (having)

  • 使用 .having(func.count(MessageAnnotation.id) == 0) 来过滤那些没有任何 MessageAnnotation 记录的 Conversation。func.count(MessageAnnotation.id) 计算每个 Conversation 与之相关联的 MessageAnnotation 记录数。having 子句确保只有 MessageAnnotation 记录数为零的 Conversation 被返回，即那些没有标注的会话。

说明：outerjoin 在 SQLAlchemy 中执行的是 外连接，通常是 左外连接（LEFT OUTER JOIN）。

6.消息数量筛选

message_count_gte 参数用于过滤对话，确保返回的对话中消息的数量大于或等于指定的值。它通过在查询中添加一个条件来实现这一点，该条件检查每个对话中的消息数量是否满足要求。

if args["message_count_gte"] and args["message_count_gte"] >= 1:
    query = (
        query.options(joinedload(Conversation.messages))
        .join(Message, Message.conversation_id == Conversation.id)
        .group_by(Conversation.id)
        .having(func.count(Message.id) >= args["message_count_gte"])
    )

7.排序字段筛选

match args["sort_by"]:
    case "created_at":
        query = query.order_by(Conversation.created_at.asc())
    case "-created_at":
        query = query.order_by(Conversation.created_at.desc())
    case "updated_at":
        query = query.order_by(Conversation.updated_at.asc())
    case "-updated_at":
        query = query.order_by(Conversation.updated_at.desc())
    case _:
        query = query.order_by(Conversation.created_at.desc())

8.设置分页查询

db.paginate(query, page=args["page"], per_page=args["limit"], error_out=False) 是 SQLAlchemy 中用于进行 分页查询 的一个方法。该方法会对数据库查询结果进行分页，返回的是当前页的数据，而不会返回所有数据。

conversations = db.paginate(query, page=args["page"], per_page=args["limit"], error_out=False)

（1）query

  • query 变量是一个已经构建好的 SQLAlchemy 查询对象，包含了所有的查询条件、连接、过滤器等。它代表了最终要执行的 SQL 查询。

（2）page=args["page"]

  • args["page"] 指定了当前请求的页码（page number），即用户希望返回哪一页的数据。在分页查询中，页码是从 1 开始的。
  • 如果 args["page"] 为 1，表示返回第一页的数据；如果为 2，则表示返回第二页的数据，依此类推。

（3）per_page=args["limit"]

  • args["limit"] 指定了每页返回的记录数，即每页显示多少条数据。例如，如果 args["limit"] 为 10，每页将显示 10 条记录。
  • 通过设置 per_page，可以控制每页返回的最大记录数，这对于控制分页查询的结果集大小非常重要。

（4）error_out=False

  • error_out=False 是一个可选参数，用于控制当请求的 page 超过总页数时的行为。如果 error_out=True（默认值），当请求的页码超出了总页数时，SQLAlchemy 会抛出一个 404 错误。
  • 如果设置为 False，当请求的页码超出范围时，查询不会抛出错误，而是返回空的结果集。这对于处理分页请求超出范围的情况非常有用，通常会返回一个空的页面而不是抛出错误。

（5）分页过程

  • 当调用 db.paginate() 方法时，SQLAlchemy 会执行以下几个步骤：
    • 计算分页的偏移量（offset）：偏移量是从结果集中跳过多少条记录。例如，假设每页 10 条记录，page=3，那么偏移量为 (3-1) * 10 = 20。即跳过前 20 条记录，获取从第 21 条到第 30 条的数据。
    • 限制查询的记录数（limit）：查询结果将只返回当前页的数据。通过 per_page 参数限制返回的最大记录数。例如，如果 per_page=10，那么查询只会返回最多 10 条记录。
    • 执行查询：基于计算出的偏移量和限制记录数，SQLAlchemy 会生成相应的 SQL 查询并执行。这通常会转换为类似的 SQL 语句 SELECT * FROM conversation LIMIT 10 OFFSET 20; 这条查询将返回 Conversation 表中的第 21 到第 30 条记录。
    • 返回分页结果：db.paginate() 会返回一个分页对象，这个对象包含了当前页的结果集、总记录数、总页数、当前页码等信息。

9.SQL 查询实现（有待验证）

将上述 Python 代码逻辑转换为 SQL 查询语句，可依据代码中的查询条件、连接、过滤、排序以及分页逻辑来进行转化。如下所示：

SELECT * FROM conversation
JOIN message ON message.conversation_id = conversation.id
JOIN (SELECT conversation_id, from_end_user_session_id FROM end_user) AS subquery
    ON subquery.conversation_id = conversation.id
LEFT JOIN message_annotation ON message_annotation.conversation_id = conversation.id
WHERE conversation.app_id = <app_model.id>
AND (message.query LIKE '%<keyword>%' OR
     message.answer LIKE '%<keyword>%' OR
     conversation.name LIKE '%<keyword>%' OR
     conversation.introduction LIKE '%<keyword>%' OR
     subquery.from_end_user_session_id LIKE '%<keyword>%')
AND conversation.updated_at >= '<start_datetime_utc>'
AND conversation.created_at <= '<end_datetime_utc>'
AND conversation.invoke_from != <InvokeFrom.DEBUGGER.value>
GROUP BY conversation.id
HAVING COUNT(message_annotation.id) = 0
AND COUNT(message.id) >= <message_count_gte>
ORDER BY conversation.created_at DESC
LIMIT 20 OFFSET 0;

参考文献

[1] SQLAlchemy 官方网站：https://www.sqlalchemy.org/

[2] SQLAlchemy GitHub：https://github.com/sqlalchemy/sqlalchemy

[3] Flask-SQLAlchemy 官方网站：https://flask-sqlalchemy.readthedocs.io/en/stable/

[4] Flask-SQLAlchemy GitHub：https://github.com/pallets-eco/flask-sqlalchemy

dify 常见问题总结 2025 持续更新
深入一点你会更加快乐
01-11 1万+
根据官方文档，会话变量主要面向多轮对话场景，而 Workflow 类型应用的交互是线性和独立的，因此它们不会有多次对话交互的情况。但实际上，会话变量是可写的，在 Workflow 中同样可以使用会话变量。在 Dify 中，它支持在多轮对话中共享和复用临时信息，比如用户偏好、上下文或对话过程中上传的文件。A： 在功能测试中，使用不同的数据集和场景来验证模型的效果，同时记录切换过程中出现的问题并进行相应调整。A： 可以通过在 API 中增加用户验证逻辑，确保在调用过程中正确管理和关联两个表中的用户信息。
【Dify(v1.x) 核心源码深入解析】Agent 模块
04-15 623
Agent 模块是 Dify 中负责处理用户请求的核心组件。接收用户输入并解析请求。根据请求内容调用合适的工具或模型。生成响应并返回给用户。管理整个交互流程，包括工具调用、消息处理和状态管理。通过本文的详细解析，我们深入了解了 Dify 的 Agent 模块的架构设计和实现细节。Agent 模块通过灵活的策略、丰富的工具、高效的消息处理和状态管理，为开发者提供了一个强大的 AI 应用开发平台。希望本文能帮助你更好地理解和使用 Dify 的 Agent 模块。更智能的策略。
Dify 中获取应用（Chatflow）的对话记录
NLP工程化
11-15 8063
本文使用 Dify v0.11.1 版本，主要介绍 Dify 中获取应用（Chatflow）对话记录的过程和原理。
webapp 修改功能实现
qq_74910062的博客
04-15 550
Override@Overrideuserdao@Override@OverrideJDBCutilUser.xml= 0 and id!= null">
基于Compose的Dify进阶操作
m0_56363537的博客
03-14 1714
本教程适用于Compose搭建的Dify，完成后期的一些进阶操作，例如修改知识库上传文件大小限制、自定义前端界面样式、增加工作空间等操作
Linux上 Dify部署问题记录（已解决）
csl136520054的博客
03-06 1244
*
访问不到webapp
weixin_45996607的博客
09-08 329
maven 构建web项目访问不到weapp
webapp:webapp 实例
05-18
webapp 项目（使用工具：Grunt yeamon）
Dify学习笔记-手册（三）
热门推荐
大数据知识梳理
01-23 3万+
Dify学习笔记-手册
Web开发Dify通过Iframe嵌入实现用户会话隔离与个性化聊天窗口设计：基于用户ID的Token传递和会话管理
最新发布
05-25
内容概要：本文档主要介绍了如何通过iframe嵌入方式将Dify聊天窗口集成到网页中，并通过用户ID进行会话隔离，解决原生Dify无法传递用户ID导致的历史记录丢失问题。具体实现步骤包括：在myChat/index.html中配置Dify...
AI Agent开发第65课-DIFY和企业现有系统结合实现高可配置的智能零售AI Agent(下)
打造全国最全的AI Agent开发知识领域的博客
05-13 451
本篇深入介绍了使用DDD领域驱动设计来设计企业核心业务系统和DIFY以及LLM是如何有机的集成在一起从而变成一个高度解耦、低代码、可配置、高性能的基于自建数据库的零售商品导购AI Agent。
无缝融入，即刻智能[二]：Dify-LLM平台(聊天智能助手、AI工作流)快速使用指南，42K+星标见证专属智能方案
丨汀、的博客
08-17 2904
无缝融入，即刻智能[二]：Dify-LLM平台(聊天智能助手、AI工作流)快速使用指南，42K+星标见证专属智能方案
【Dify(v1.x) 核心源码深入解析】Apps 模块
04-22 357
Dify 的 Apps 模块通过工作流和任务管道实现了复杂业务逻辑的处理。它通过事件驱动的方式协调任务的执行，支持流式输出和阻塞模式。通过合理的数据库连接管理和任务优化，可以确保系统的高性能和高可用性。希望本文能帮助你深入理解 Dify 的 Apps 模块，并在实际项目中灵活应用。如果你有任何疑问或建议，欢迎随时与我们交流！
【Dify基础实战】跟网页对话
sinat_29950703的博客
11-19 3694
Dify跟网页对话 1.开始：输入 问题 和 网页网址 2.解析网页 3.代码处理网页 4.LLM跟网页对话 5.结束
轻松解锁原生AI应用：Dify WebApp介绍
进击的Blazor
12-02 1564
本文介绍了Dify平台提供的Dify WebApp及其模板，旨在为用户提供创建和部署原生AI应用的无缝灵活解决方案。Dify WebApp能让用户快速构建并部署托管于Dify云平台的应用，其包含对话式和文本生成两类应用，分别适用于不同场景。Dify WebApp模板是开源的脚手架，支持多种部署方式和定制开发，有助于构建一个开放协作的生态系统，推动原生AI应用的创新发展。
dify智能体：日志管理与标注功能详解
zyx_bx的博客
05-13 536
日志管理与标注功能是优化聊天助手、Agent、文本生成应用、Chatflow 和工作流等工具交互体验的关键。日志管理允许用户查看、修改和标注日志，帮助回顾和优化交互内容。用户可以通过点击👍或👎按钮快速标注满意度，标注后的日志可用于后续优化和分析。标注功能则支持用户对交互内容进行标记和调整，以提升模型输出质量。此外，用户还可以调整界面语言和时区设置，确保在熟悉的环境中操作。这些功能共同作用，显著提升了交互体验和模型性能。
Dify教程（配置文件，附知识库上传15MB限制解决方案）
wal1314520的博客
02-28 6065
之前写创建知识库的时候，在文章内写了，我也在文章着重提到了会在后面讲如何调整，但是写知识库的时候写到最后我把这事儿忘了，然后写工具的时候准备带上这块内容，也是因为有事耽误了，导致没有把这部分提上去。其实这块很简单，修改配置文件即可，只是的配置文件还是很多参数的，具体调整哪儿可能不仔细研究还不一定知道，我就想着那就讲一讲配置文件吧，这样除了解除15MB上传文件的限制，其余的一些配置项大家也能够了解了，遇到需要调整的时候，也知道怎么去操作了！我先讲一下在讲之前提一句，我的Dify目前是最新版本。
如何在dify中设置类似rasa的对话管理
03-15
<think>好的，我现在需要回答用户的问题：如何在Dify中实现类似Rasa的对话管理功能，并需要配置教程。首先，我要理解用户的需求。Rasa是一个开源的对话式AI框架，强调对话管理和上下文处理，用户可能希望Dify能够具备类似的对话流程控制、意图识别和上下文管理能力。 接下来，我需要回忆Dify的相关知识。Dify是一个低代码的AI应用开发平台，支持大模型集成和可视化编排。但Dify本身可能没有内置的对话管理模块，所以需要通过其他方式实现类似功能。 首先，用户提到的引用中提到了在Dify中配置DeepSeek R1，这可能涉及到集成外部模型或API。或许可以利用Dify的工作流功能，将对话的不同环节连接起来，比如意图识别、状态管理、上下文跟踪等。 然后，分步骤思考如何实现： 1. **意图识别和实体抽取**：Rasa的NLU组件负责识别用户意图和实体。在Dify中，可能需要调用预训练的模型或API，比如使用Dify的文本分类模型或集成第三方NLP服务，如腾讯云NLP或阿里云的语言处理服务。用户需要在Dify中创建分类模型，或者通过API节点调用外部服务。 2. **对话状态管理**：Rasa使用对话策略来管理状态。Dify中可能需要用变量来跟踪状态，比如使用全局变量或数据库存储当前对话的上下文。例如，在对话流程中设置变量来记录用户当前所处的步骤，或者保存已获取的信息。 3. **多轮对话流程**：在Dify的工作流中，通过条件分支和循环结构来实现多轮对话的逻辑。例如，根据用户的不同意图跳转到不同的处理节点，或者根据上下文决定下一步询问的内容。 4. **上下文关联**：Dify的上下文记忆功能可以用来保存历史对话信息。每次对话时，将之前的对话记录作为上下文传入模型，帮助模型理解当前对话的背景。这可能需要在API请求中设置上下文参数，或者在提示词设计中包含历史信息。 5. **集成外部服务**：如果需要复杂的逻辑处理，可能需要通过Dify的HTTP请求节点连接外部服务器，比如自建的对话管理服务，处理状态转换和业务逻辑，然后将结果返回Dify。 接下来，我需要验证这些步骤是否可行。例如，在Dify中创建工作流时，是否支持变量存储和条件判断。查阅Dify文档后，确认Dify的工作流支持变量和条件分支，允许根据不同的条件执行不同的路径。此外，Dify支持通过API调用外部服务，这为集成外部对话管理模块提供了可能。 可能的配置教程步骤： 1. **创建意图分类模型**：在Dify的数据集中标注不同意图的样本，训练一个分类模型，或者使用预训练模型。 2. **设计对话工作流**：使用Dify的可视化工作流编辑器，添加意图识别节点，然后根据意图分支到不同的处理节点。每个处理节点可以更新对话状态变量，并生成响应。 3. **设置上下文存储**：在每次对话交互中，将必要的信息（如用户已提供的参数）保存到上下文或数据库中，以便后续步骤使用。 4. **测试和优化**：通过测试对话流程，调整条件分支和提示词，确保对话逻辑正确，上下文处理无误。 需要注意的挑战包括如何有效管理复杂的对话状态，以及如何处理多轮对话中的上下文依赖。可能需要结合Dify的功能和外部服务来实现更复杂的逻辑。 最后，需要引用用户提供的参考内容中的信息，关于在Dify中配置DeepSeek R1，这可能涉及到具体的模型集成步骤，可以作为实现对话管理的一部分，例如利用DeepSeek的模型来处理意图识别或生成响应。</think>在Dify中实现类似Rasa的对话管理功能，需结合其可视化工作流和上下文管理能力，以下是具体方法和配置步骤： --- ### 一、核心功能对比与实现思路 1. **意图识别** Rasa通过NLU模型实现，Dify可集成文本分类模型（如训练自定义模型或调用第三方API）判断用户意图。例如，在Dify的“知识库”中标注意图样本，或通过API节点调用腾讯云NLP的意图识别接口[^1]。 2. **对话状态管理** - 使用**全局变量**（如`current_step`、`user_intent`）记录对话进度。 - 通过**数据库集成**（如MySQL/Redis）持久化复杂会话状态，例如用户填写的表单信息。 3. **多轮对话流程** 在Dify工作流中，通过**条件分支**和**循环节点**控制流程： ```python # 伪代码逻辑示例 if intent == "预约餐厅": ask_cuisine_type() update_state("waiting_for_cuisine") elif current_state == "waiting_for_cuisine": save_cuisine_type() ask_time() ``` --- ### 二、配置教程（分步实现） #### 步骤1：配置意图识别 1. **方法一：内置分类模型** - 进入Dify“数据集” → 创建“意图分类”数据集，上传标注数据（示例：`{"text":"我想订位","label":"book_restaurant"}`）。 - 训练模型后，在工作流中添加“分类模型”节点，选择该模型。 2. **方法二：外部API集成** - 添加“HTTP请求”节点，调用第三方NLP服务（示例配置）： ```yaml URL: https://api.nlp-service.com/intent Headers: {Authorization: "Bearer {API_KEY}"} Body: {"text": "{{input}}"} ``` - 解析返回的意图字段（如`result.intent`）。 #### 步骤2：构建对话工作流 1. **创建初始触发节点** - 添加“用户输入”节点，接收用户消息。 2. **添加状态分支逻辑** - 使用“条件判断”节点，根据意图或全局变量跳转： ```python # 条件表达式示例 {{ variables.intent == "book_restaurant" and variables.step == "start" }} ``` 3. **设计多轮交互节点** - 对需要多次询问的场景，使用“循环”节点并设置退出条件（如`variables.required_info_collected == true`）。 #### 步骤3：实现上下文关联 1. **短期上下文** 在提示词中插入历史对话（需开启“上下文记忆”功能）： ``` 历史对话： {{#history}} - {{role}}: {{content}} {{/history}} 当前问题：{{input}} ``` 2. **长期上下文** 集成数据库保存跨会话信息： - 添加“SQL执行”节点，操作示例： ```sql INSERT INTO user_profiles (user_id, preferred_cuisine) VALUES ('{{user_id}}', '{{cuisine_type}}') ON CONFLICT UPDATE SET preferred_cuisine = excluded.preferred_cuisine ``` --- ### 三、优化建议 1. **添加澄清确认逻辑** 在关键节点插入“确认询问”分支（如“您想预约的是意大利菜对吗？”），通过条件判断处理用户确认/否认。 2. **超时机制实现** 使用定时任务（如Celery）监测`last_active_time`字段，若超时则重置对话状态。 3. **异常处理** 在工作流末尾添加“兜底响应”节点，使用模糊匹配模型处理未识别意图。 ---
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

NLP工程化

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值