一、省流：关键结论速览摘要：功能优势显著但仍需打磨: 从理论层面来看，Dify 相较于简单直接的 Open WebUI 向量知识库更具优势。Dify 不仅功能多样，能在 ChatBot、Agent 等多种场景中发挥作用，然而要实现理想的效果，还需投入大量工作进行优化调整。硬件资源需求明确
结论
功能优势显著但仍需打磨: 从理论层面来看，Dify 相较于简单直接的 Open WebUI 向量知识库更具优势。Dify 不仅功能多样，能在 ChatBot、Agent 等多种场景中发挥作用，然而要实现理想的效果，还需投入大量工作进行优化调整。硬件资源需求明确: 若要部署 Dify，服务器的硬件资源需进行合理分配，专门为 Dify 以及 embedding 模型（用于将文本转换为向量表示的模型）和 rerank 模型（用于对检索结果进行重新排序的模型）预留一部分资源。上下文与硬件要求提升: 引入 Dify 的工作流后，对模型的上下文长度要求大幅提高，这也直接导致对硬件性能的需求急剧上升。若 LLM（大语言模型）服务器的上下文长度不足，工作流中的内容可能会被截断，进而严重影响最终的问答质量。工作流调试功能强大: Dify 的工作流具备全流程输出的特性，这一功能非常实用，便于用户进行问题排查和性能优化。需注意的是，Open WebUI 和 Dify 目前所使用的 embedding 模型不同，这是造成测试结果存在差异的一个重要因素。
测试体验环境
Open WebUI: 测试账号：user1@localhost 123456, admin1@localhost 123456Dify: 测试账号：wgh@localhost/abcd1234二、现状与挑战：Open WebUI 知识库的局限前期，我们基于 Open WebUI 搭建了一个简易的知识库。但由于 Open WebUI 并非专业用于知识问答的平台，其功能较为简陋，难以满足企业级产品的知识问答需求： - 功能单一，无法多库融合：一个机器人无法同时接入多种类型的问题。例如，企业中存在对外的产品介绍知识库、对内的产品需求知识库、产品售后知识库以及新员工入职知识库等，Open WebUI 无法让一个机器人同时处理这些不同类型知识库的问题。 - 缺乏文档处理能力：不支持知识库的文档清洗、召回以及优化调试等功能。公司内的现有文档在格式和内容上差异较大，很多文档在进行 embedding 处理后会产生大量关键字，但实际有用的信息却很少，其中还包含审核人、机密等级、版本历史等无关内容。 - 多模态数据扩展受限：无法处理各种文档中的图片、音频或视频等多模态数据，然而这些数据对于一些文档案例来说可能是关键信息。 - 其他方面的不足：在实际使用中，还存在一些其他无法满足企业需求的问题。
针对以上种种问题，经过与两位领导的初步讨论，我们启动了对 Dify 的预研工作，期望借助 Dify 的工作流机制来解决 Open WebUI 知识库存在的这些问题。
三、Dify 的解决方案：灵活性与强大功能的结合Dify 的强大之处在于其高度的灵活性，主要体现在智能体和工作流两个方面： - 问题分类与多库导向：对于原本需要为每个知识库单独设置机器人的场景，在 Dify 中可以通过在工作流的前置环节添加 “问题分类” 流程，将不同的问题引导至不同的知识库和分支流，实现一个智能体处理多种类型的问题。 - 知识库清洗与优化：针对知识库清洗的常见需求，Dify 提供了多种方式。一方面，用户可以在知识库中手动进行清洗操作，利用自定义工具完成数据清洗、自动或手动分段、向量搜索、全文检索、混合检索等功能，并支持设置 top K（返回前 K 个最相关的结果）、Rerank（重新排序）、Score 阈值（分数阈值）等参数；另一方面，还可以在智能体或工作流中进行二次清理，进一步优化知识库。 - 多模态数据支持：当 Dify 接入的大模型支持多模态时，通过自定义预设工作流的流程，可为多模态数据制定相应的处理流程和规则，使数据更加全面和完整，充分发挥多模态数据的价值。
在对 Dify 的优势进行充分了解后，我们来看看当前的部署进展情况。目前，Dify 的演示环境已经搭建完成，但在使用和优化方面仍有许多工作需要进一步探索。
整个部署过程并非一帆风顺。由于没有实体服务器，我们在 AutoDL 上租用了一台虚拟机进行部署。但由于 AutoDL 虚拟机存在诸多限制，导致我们遇到了不少问题：
Docker 安装受限：Dify 官方强烈推荐使用 Docker 进行安装，这是因为源码安装存在大量的坑，容易出现各种依赖冲突。而在 AutoDL 虚拟机上无法安装 Docker，给部署带来了很大的困难。swap 使用受限：Dify 前端采用的是 NodeJS，而 NodeJS 的编译需要使用 swap 空间，这导致在 AutoDL 服务器上的安装失败。因此，目前我们的部署是分布在几台不同的设备上：
Dify 后端：部署在 AutoDL 服务器上。Dify 前端：安装在一台 IP 为 172.16.129.182 的 Ubuntu 电脑上。LLM 大模型：同样运行在 AutoDL 服务器上，使用的是 QwQ-32B-AWQ 模型。EMBEDDING 模型：部署在我的笔记本电脑上，采用的是近期刚刚发布的 jina-embeddings-v3 模型，据宣称该模型性能优于各种老模型（目前尚未进行实际对比测试）。Rerank 模型：暂未进行部署，目前的召回操作暂时使用权重模型。通过一系列的配置工作，我们实现了这几台设备之间的互联互通。
1、Dify 平台测试地址： 注：该平台目前不支持自主注册，需要邀请码才能进行注册。2、知识库建设与测试 本次对 Dify 的测试，我们沿用了之前在 Open WebUI 上使用的两个知识库：视讯开放平台 RTCSDK、视讯售后案例知识库。 视讯开放平台 RTCSDK：包含视讯开放平台的相关文档，所有文档均为 markdown 格式。视讯售后案例知识库：由售后提供的一些售后案例文档，涵盖了 word、visio、zip、bash/bat 脚本等多种格式（其中 visio 格式不被支持）。 将这两个知识库导入 Dify 后，我们以工作流的形式将它们构建成了 chatflow，并进行了发布。测试使用的智能体为 “视讯全能小助手”。
测试使用：视讯全能小助手
1）第一回合：7.0sp5-防火墙规则怎么设
a. Open WebUI
直接出回复，并且是准确的答案。
b. Dify工作流
未直接给出回复，在三轮后才给出答复，但是第三轮的答复明显知识库的内容被丢失了。
c. 结论：Open WebUI准确回答。Dify答案由于上下文长度原因被截断
Winner: Open WebUI。在这一个测试里，以当前Open WebUI和Dify上的设定而言，Open WebUI上的效果比Dify的效果更好，初步怀疑是跟我设定到Dify工作流上的prompt有关。同时需要注意的是，在问题深入的时候，Open WebUI有可能会出答非所问的情况。 当前Dify工作流中的prompt。
你是视讯售后团队的小助手。 使用以下内容作为你所学习的知识，放在 XML标签内。 {{#context#}} 回答用户时： 如果你不知道，就直说你不知道。如果你在不确定的时候不知道，就寻求澄清。 避免提及你是从上下文中获取的信息。 并根据用户问题的语言来回答。2）第二回合
a. Open WebUI保持不变
b. Dify将prompt里“如果你不知道，就直接说你不知道。如果你在不确定的时候不知道，就寻求澄清。”去掉。
c. Dify正确回答问题
3）第三回合：对通宝利通平台，接收图像卡顿怎么回事？
a. Open WebUI
b. Dify工作流
回答内容简洁，答案正确引用知识库中的案例。
c. 结论：Open WebUI胜出
4）第四回合：krtcsdk是啥 + 支持哪些操作系统
a. Open WebUI
b. Dify工作流
c. 结论：各有槽点
输出的答案各有各的槽点：
Open WebUI混淆了知识库引用（如果top K调小可能结果就错了）。Dify由于prompt限制了，如果不知道就回不知道。所以它也没有自己去总结知识库里的文档内容。3。dify后台模型
回答内容只出来了think思考过程，回复内容由于token数不够，被截断。
1。知识库文档上传的限制
目前知识库文档上传单个文档最大是 15MB，总文档数量限制 100 个。如你本地部署版本需要调整修改该限制，请参考文档。 知识库配置环境变量
UPLOAD_FILE_SIZE_LIMIT #上传文件大小限制，默认 15M。UPLOAD_FILE_BATCH_LIMIT #每次上传文件数上限，默认 5 个。ETL_TYPE # 可使用的枚举类型包括： dify: Dify 自研文件 Extract 方案 Unstructured: 文件 Extract 方案 UNSTRUCTURED_API_URL: Unstructured API 路径，当 ETL_TYPE 为 Unstructured 需要配置。如：上传知识库文档是 Excel，该如何更好地分段？
首行设置表头，后面每行显示内容，不要有其他多余的表头设置，不要设置复杂格式的表格内容。 如下方表格示例，仅需保留第二行的表头，首行（表格1）为多余表头，需删掉。
2。知识库长文本如何切分比较合理？
在一些自然语言处理应用中，通常会将文本按照段落或者句子进行切分，以便更好地处理和理解文本中的语义和结构信息。最小切分单位取决于具体的任务和技术实现。例如：
对于文本分类任务，通常将文本按照句子或者段落进行切分对于机器翻译任务，则需要将整个句子或者段落作为切分单位。最后，还需要进行实验和评估来确定最合适的 embedding 技术和切分单位。可以在测试集上 / 命中测试比较不同技术和切分单位的性能表现，并选择最优的方案。
3。如何增加其他的 Embedding Model？
如果是公网部署，Dify 支持以下作为 Embedding 模型使用，只需在配置框中选择 Embeddings 类型即可。
AzureLocalAIMiniMaxOpenAIReplicateXInference如果是本地私有化部署，ollama的嵌入模型有三种：mxbai-embed-large、nomic-embed-text 、all-minilm。 ollama pull mxbai-embed-large
4。为什么建议 max_tokens 设置小一点？
因为在自然语言处理中，较长的文本输出通常需要更长的计算时间和更多的计算资源。 因此，限制输出文本的长度可以在一定程度上降低计算成本和计算时间。 例如设置： max_tokens=500 ，表示最多只考虑输出文本的前 500 个 token，而超过这个长度的部分将会被丢弃。 这样做的目的是保证输出文本的长度不会超过 LLM 的接受范围，同时还可以充分利用计算资源，提高模型的运行效率。 另一方面，更多的情况是，限制 max_tokens 能够增加 prompt 的长度，如 gpt-3.5-turbo 的限制为 4097 tokens，如果设置 max_tokens=4000，那么 prompt 就只剩下 97 tokens 可用，如果超过就会报错。
5。遇到如下报错提示，该如何解决？
Query or prefix prompt is too long, you can reduce the preix prompt, or shrink the max token, or switch to a llm with a larger token limit size在编排页参数设置里，调小“最大 token”的值即可。
6。多模态模型配置
环境变量：
MULTIMODAL_SEND_IMAGE_FORMAT # 多模态模型输入时，发送图片的格式，默认为 base64，可选 url。 url 模式下，调用的延迟会比 base64 模式下低，一般建议使用兼容更好的 base64 模式。 若配置为 url，则需要将 FILES_URL 配置为外部可访问的地址，以便多模态模型可以访问到图片。UPLOAD_IMAGE_FILE_SIZE_LIMIT # 上传图片文件大小限制，默认 10M。7。报错：Model o1 credentials is not initialized.
先确认你自己部署的大模型支持什么功能？LLM, CHAT, EMBEDDING, RERANK, ASR, TTS等等，有什么功能就用什么功能，并且自行测试一下是否OK，确认OK后再加到dify。
curl http://127.0.0.1:8000/v1/completions \> -H "Content-Type: application/json" \> -d '{> "model": "qwq-32b-awq-jacky",> "prompt": "San Francisco is a",> "max_tokens": 7,> "temperature": 0> }'来源：才思敏捷柳叶fr
