Dify智能体多功能 RAG 与视觉问答助手

🧠 simple-kimi (多功能 RAG 与视觉问答助手)

这是一个功能极其强大的高级聊天应用，模拟了类似 Kimi Chat 的核心能力。它集成了网页搜索（RAG）、文档问答（RAG）、图片理解（多模态） 和纯聊天等多种模式于一体，并通过复杂的条件分支逻辑，根据用户的输入类型（是否开启搜索、是否上传文件）自动切换到最合适的工作模式。

第一阶段：用户输入与智能路由

• 开始 (Start): 工作流开始时，为用户提供了两个可选项：
  • web搜索: 一个下拉菜单，可以选择“开启”或“关闭”实时联网搜索功能。
  • 角色定义: 一个文本框，允许用户自定义AI的专家人设或背景。
  • 同时，应用还能接收用户在聊天中输入的文本问题 (sys.query) 和上传的文件 (sys.files)。
• 条件分支 1: 这是工作流的第一个总调度中心。它会检查用户是否开启了web搜索，并根据结果将对话引导至两个主要分支之一。

分支 A：网页搜索 RAG 模式 (当“web搜索”为“开启”)

此分支负责执行联网搜索并综合信息来回答问题。

1. 即时反馈与搜索: 系统会先发送一条“开始搜索…”的中间消息给用户，然后立刻使用DuckDuckGo搜索引擎根据用户的问题进行搜索。
2. 并行信息处理: 这是该分支最高效的部分。工作流会获取搜索结果的前4个链接，并同时对这4个网页启动4条完全一样的子流程进行并行处理：
   • 提取与抓取: 从搜索结果中提取出网页的URL和标题，然后使用“网页爬虫”工具抓取该页面的全文内容。
   • 内容清洗: 使用代码节点对抓取到的HTML进行初步清洗，提取出正文文本。
   • 独立分析: 一个LLM节点会仅根据这一个网页的内容，生成一个“候选回答”。
3. 最终答案合成 (LLM_Final): 在4条子流程都完成后，一个扮演“总编辑”角色的最终LLM会被唤醒。它会接收到用户最初的问题以及前面生成的所有4个“候选回答”。它的任务是“综合上面的内容，或者筛选最靠谱的回答作为最终的回答”，并附上参考链接。
4. 输出: 将这个经过综合与提炼的、最高质量的答案呈现给用户。

分支 B：本地知识与文件处理模式 (当“web搜索”为“关闭”)

此分支负责处理不联网的场景，并根据用户是否上传文件再次进行细分。

• 条件分支 2: 这是分支B内部的第二个调度中心，它会检查用户是否上传了文件。
  • 路径 1: 无文件上传 (纯聊天):
    • 如果用户没有上传任何文件，工作流会直接调用一个LLM，让它根据用户设定的角色定义和自身的知识库来回答问题。
  • 路径 2: 上传了图片 (视觉问答):
    • 如果检测到用户上传的是图片文件，工作流会激活一个支持视觉能力的LLM。该LLM会同时接收到用户的文本问题和上传的图片，并给出图文结合的回答。
  • 路径 3: 上传了文档 (文档问答):
    • 如果检测到用户上传的是文档文件（如PDF, TXT等），工作流会使用“文档提取器”读取文件内容，然后将文档内容作为上下文提供给LLM，让AI根据文档内容来精准地回答用户的问题。

主要特点

• 多模态与多路径处理: 通过精巧的条件分支，实现了对文本、网页、文档、图像四种不同信息源的自动识别和适配处理，功能非常全面。
• 并行RAG架构: 网页搜索分支采用了先进的并行处理模式，同时分析多个信息源并最后进行综合，相比传统的串行读取，速度更快，答案质量也可能更高。
• 高度用户可配置: 提供了“Web搜索开关”和“自定义角色”等选项，让用户可以根据自己的需求灵活调整应用的行为模式。
• 清晰的用户交互: 在执行耗时较长的Web搜索任务前，会主动告知用户“开始搜索…”，优化了用户等待体验。

重要提示

• 这是一个高度复杂的工作流，展示了Dify平台在流程控制（If/Else）、并行处理和多模态输入方面的顶尖能力。
• 该工作流配置了多个不同的LLM服务（包括Bedrock和Ollama），并且Web搜索分支会产生大量的LLM调用（至少5次），因此对模型服务的性能和Token消耗有较高要求。
• 网页抓取后的文本清洗逻辑较为基础（截取前8192个字符），对于某些结构复杂的网站，信息提取效果可能有限。