易迟的博客 | Bryan Blog

Dify框架增强：知识库检索能力提升探索与实践

Enhancement of Dify framework: exploration and practice of improving the retrieval ability of knowledge base

背景介绍在之前的文章来自工业界的开源知识库 RAG 项目最全细节对比中介绍过，现有 RAG 开源项目中，Dify 的生态良好，但是一个明显的短板就是 RAG 检索能力偏弱。因此一直期望能补全这个短板，从而让 Dify 能真正好用起来。在基于开源项目二次开发建议方案探索了 Dify 的增强策略。实际选择了文章中提到的中策，基于模块化增强 Dify。做出这个选择的主要原因如下： ...

Posted by Bryan on August 14, 2024

深入 Dify 源码，洞察 Dify RAG 切片机制实现细节

Go deep into the Dify source code and gain insight into the implementation details of the Dify RAG slicing mechanism

背景介绍最近测试时发现 Dify 的 RAG 分片效果一般，不管是使用之前深入 Dify 源码，洞察 Dify RAG 核心机制中有调研过的默认解析还是 Unstructured 解析。因此调研比较了大量的开源框架实现了特定格式的结构化解析方案，并与 Dify 现有解析流程进行了适配。为了保证文件的解析能真正发挥出效果，需要保证预处理中其他环节也遵循前面的结构化方案进行处理，...

Posted by Bryan on August 6, 2024

来自工业界的开源知识库 RAG 项目结构化文件解析方案比较

Comparison of structured file parsing solutions from open source RAG projects in the industry

背景介绍在过去实践 RAG 的过程中，深刻体会到 RAGFlow 提出的 "Quality in, quality out", 只有高质量的文件处理才能获得良好的 RAG 效果。 RAG 的第一步是对文件进行解析，由于 Embedding 和 LLM 模型的长度限制，往往需要将解析后的文件进行切片。原始的 RAG 就是直接按照固定长度对文件进行切分，导致最终检索到的内容都是碎片化的，效果...

Posted by Bryan on July 31, 2024

深入 Dify 源码，洞察 Dify RAG 默认机制

Dive into the Dify source code and gain insight into the Dify RAG default mechanism

背景介绍之前深入源码对 Dify 的完整流程进行了解读，基本上梳理了 Dify 的实现流程与主要组件。但是在实际部署之后，发现 Dify 现有的 RAG 检索效果没有那么理想。因此个人结合前端页面，配置信息与实现流程，深入查看了私有化部署的 Dify 的技术细节。将核心内容整理在这边，方便大家根据实际的业务场景调整 Dify 知识库的配置，或者根据需要进行二次开发调优。技...

Posted by Bryan on July 17, 2024

深入 Dify 源码，定位知识库检索的大模型调用异常

Go deep into the Dify source code and locate large model call anomalies in knowledge base retrieval

背景介绍之前在 GPU 服务器上部署了 Dify 服务，使用的是 Dify 与 Xinference 组合，Xinference 部署的大模型是 THUDM/glm-4-9b-chat。基于本地部署的服务构建了知识库，并利用首页提供的任务流模板创建了一个 RAG 工作流实际运行此应用聊天时发现，知识库检索节点执行时会报错 GPT3.5 模型不存在，除了错误信息以外没有其他额...

Posted by Bryan on July 14, 2024

基于开源项目二次开发可行方案

The solution for secondary development based on open source projects

背景介绍一般情况下我们不需要进行开源项目的二次开发，因为开源项目往往会提供良好的封装，可以通过依赖包或 API 服务的形式引入项目中。如果开源项目存在一些问题，我们往往可以通过给开源项目提供 PR 来解决，这样就可以尽可能减少二次开发开源项目的问题。但是某些情况下可能会需要基于开源项目开发自己的服务，需要一个相对长周期二次开发。而且因为定位不同，代码很难直接合并至开源项目，这种情况下就...

Posted by Bryan on July 12, 2024

Dify 与 Xinference 最佳组合 GPU 环境部署全流程

The whole process of deploying the combination of Dify and Xinference in GPU environment

背景介绍在前一篇文章 RAG 项目对比之后，确定 Dify 目前最合适的 RAG 框架。本次就尝试在本地 GPU 设备上部署 Dify 服务。 Dify 是将模型的加载独立出去的，因此需要选择合适的模型加载框架。调研一番之后选择了 Xinference，理由如下：支持多种类型的模型，包括 LLM，Embedding, Rerank, Audio 等多种业务场景的模型需求，一...

Posted by Bryan on July 11, 2024

来自工业界的开源知识库 RAG 项目最全细节对比

The most complete comparison of open source RAG projects from the industry

背景介绍之前详细整理过来自工业界的不少开源 RAG 项目：有道 QAnything RAGFlow langchain-chatchat 中科院 GoMate Dify FastGPT 群里一直看到有小伙伴询问在实际的业务需求中如何选择合适的 RAG 项目，本文就详细对比一下这些 RAG 项目。考虑到目前实际发展程度，GoMate 目前的可靠性还不适合在生...

Posted by Bryan on July 8, 2024

官方技术文档查询大模型：快速搭建与实践记录

Official technical document query large model: rapid construction and practice records

背景介绍在过去使用大模型的过程中，感受到大模型能力的持续提升。但是作为程序员，在基于不熟悉的框架开发新功能时，依旧需要持续查询官方文档。而大模型对特定框架的使用细节所知甚少，因此可能给出的回答不够准确。比如之前在快速搭建量化交易平台时因为不熟悉相关框架就需要反复查看 Dash 和 backtrader 的官方文档寻找解决方案，这部分工作需要花费不少时间。事实上单个项目的技术框...