大模型之Dify之踩坑集锦

Dify 文档提取器支持自建OCR服务

取好一个名字：test1 之后，添加“文档提取器”，大模型没有办法直接处理文档，因此添加一个“文档提取器”的节点。文档提取器 --> 输入变量（input），为开始节点设置的变量。最后添加一个结束节点，一条工作流就完成了。开始节点 -> 选择"单文件"作为输入。创建工作流：文档总结规划。

好了，智能文档助手也介绍的差不多了，不过需要注意的是，这个demo只是一个比价简单的应用，需要根据你们的详细业务逻辑进行强化，对简单逻辑进行加强，复杂化。开始节点后，我们要去判断这一次对话是否有文件上传，如果有文件就前往下一个节点，如果没有问题，则提示“请上传文件后继续！首先我们创建开始节点，这块我们就作为文件输入的节点就行，如果需要一些限定条件的，可以添加字段来做处理。LLM根据用户输入的内容和前置文档提取器节点输出的内容以及图片数组，进行分析解答。以及我们上传一张图片，让LLM帮我们解析图片内容。

Dify学习笔记-入门学习，包括基础介绍和安装

你现在可以打开deepseek和模型对话了吧，但TA老是介绍自己是深度求索公司巴拉巴拉一大推，这个Dify就是用来二次开发AI应用的脚手架，来训练它的！可以让TA成为你的法律助手，代码助手，儿童医生，心理咨询师、甚至还可以是虚拟男友、地理先生、周易大师等。那为啥要本地部署Dify呢？？？现在我们要创建个公司秘书助手，训练出来的秘书肯定是内部的事都知道，所以要部署在私服上哦！

利用 LLM 从自然语言推理并提取结构化参数，用于后置的工具调用或 HTTP 请求。Dify 工作流内提供了丰富的工具选择，其中大多数工具的输入为结构化参数，参数提取器可以将用户的自然语言转换为工具可识别的参数，方便工具调用。工作流内的部分节点有特定的数据格式传入要求，如迭代节点的输入要求为数组格式，参数提取器可以方便的实现结构化参数的转换。

官方文档：https://docs.dify.ai/zh-hans开源地址：https://github.com/langgenius/dify.git这是一个LLM大模型应用开发平台，实际上就是结合后端和企业快速构建生产式AI，入门的门槛较低，支持大量不同模型，并且提供对应的API，提示词编排，检索增强搜索引擎，和Agent框架。工作流：Dify 提供了一个可视化的画布来构建和测试强大的 AI 工作流。此功能使用户能够利用 Dify 的全部功能，包括模型集成和提示词设计。全面的模型支持。

将Dify文档中的CSV数据提取并用ECharts可视化工具开发指南

在前一篇文章RAG 项目对比之后，确定 Dify 目前最合适的 RAG 框架。本次就尝试在本地 GPU 设备上部署 Dify 服务。Dify 是将模型的加载独立出去的，因此需要选择合适的模型加载框架。调研一番之后选择了Xinference支持多种类型的模型，包括 LLM，Embedding, Rerank, Audio 等多种业务场景的模型需求，一个框架全搞定；方便的模型管理能力，提供可视化页面快速部署模型支持直接从 ModelScope 下载模型，避免 huggingface 被墙的问题；

解决Dify1.3.1安装Ollama后无法成功添加大语言模型DeepSeek，导致无法使用大语言模型问题

上一篇大语言模型推理服务框架—Ollama介绍了Ollama，Ollama以出色的设计一行命令完成推理框架部署，一行命令完成大模型部署，模型的下载不依赖梯子，速度非常快，大幅提升模型部署效率，同时，当有多卡GPU时，Ollama可以自动将模型分片到各个GPU上，博主使用V100显卡（单卡32G显存）部署llama3 70B（预计需要40G显存），自动完成了显存分配。记得带http://否则会报错。启动模型，包含语言模型、图片模型、语音模型、自定义模型，提供了模型搜索框，基本主流模型都已经收录。

使用 Dify 创建自然语言生成 Word 文档的应用（详细指南）

前两天看到一位国外博主发的看完非常有启发，所以分享给大家一起学习。这种形式可以让大家可以更直观的理解相关概念！（前提是大家需要对Transformer基础概念有一定的理解）解码器是负责将编码后的输入和之前生成的标记转换为上下文感知输出的“大脑”。想象一下，它就像是一位艺术家，根据草图绘制出最终的画面。解码器首先会将需要处理的序列进行嵌入，将原始数据转换成它能够理解的格式。由于Transformer不像旧模型那样依赖序列顺序，因此它使用位置编码。

本期文章我们在原有的单张发票识别基础上实现多种发票识别的dify基于工作流的智能体。下面我们首先介绍一下整体功能。这里面主要功能：用户上传一个发票图片（目前我们这工作流支持6种发票），发票会经过文档提取器。文档提取器提取用户上传的发票传递给llm多模态模型，这个模型的作用是判断这发票是哪个类型的发票，接下来我们会根据条件分支来判断走哪个多模态发票提取的llm大语言模型。其中这6个大语言模型区别就在于他们的系统提示词不一样，主要就是每个发票票面信息不一样。

本文介绍了dify中文本分割的几种方式。并对这几种方式的实现进行了分析和比较。文本分割是，RAG框架实现中比较关键的一环，分割质量的好坏直接影响RAG回答的效果。dify中考虑到了文本的长度和语义的连贯性，会对小的分块进行合并，而且又会保证了文本有一定的重叠，保证了语义的连贯性。 另外，在其他的RAG框架中也可以使用tiktoken包来对文本块进行token化，然后再对token进行分割。这种方式相对比较简介，在后续文章中会继续分析这种实现方式的原理。