Bryan Blog

个人分享 但愿各位看官喜欢

深入源码,洞察迭代 8 年的 html 文本转换库

Dive into the source code and gain insights into the html text conversion library that has been iterating for 8 years

背景介绍 在前面 RAG 项目结构化文件解析方案比较 文章中对常见的 html 解析方案进行了比较,发现 html_text + python-readability 可以实现高质量的 html 内容提取。 在前一篇文章 迭代 14 年的高质量 html 提取方案 中对 python-readability 库进行了介绍,这篇文章就对剩下的 html_text 库进行介绍。 html_t...

深入源码,洞察迭代 14 年的高质量 html 提取方案

Go deep into the source code and gain insight into the high-quality HTML extraction solution that has been iterated for 14 years

背景介绍 在大模型时代,开源项目的生命周期被加速了,往往迭代速度很快,但是热门项目也容易突然就无疾而终了。最近看到一款历经 14 年的开源 html 内容提取项目 python-readability,从最早建立到目前,已经迭代了 14 年。 本文是在实际项目中使用 python-readability 之后,发现一些异常 case,因此深入源码了解其中的技术细节,因此在本文中对这款...

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

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

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

深入 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 现有解析流程进行了适配。 为了保证文件的解析能真正发挥出效果,需要保证预处理中其他环节也遵循前面的结构化方案进行处理,...

来自工业界的开源知识库 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 就是直接按照固定长度对文件进行切分,导致最终检索到的内容都是碎片化的,效果...

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

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

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

深入 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 模型不存在,除了错误信息以外没有其他额...

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

The solution for secondary development based on open source projects

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

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 等多种业务场景的模型需求,一...

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

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

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