易迟-CSDN博客

原创 FATE Flow 源码解析 - 日志输出机制

在之前的文章中介绍了 FATE 的作业处理流程，在实际的使用过程中，为了查找执行中的异常，需要借助运行生成的日志，但是 FATE-Flow 包含的流程比较复杂，对应的日志也很多，而且分散在不同的文件中，在这篇文章中就对 FATE-Flow 的日志机制进行梳理，帮助大家了解 Python 服务中实现一个更加灵活的日志机制。

2024-07-17 20:39:04 963

原创深入 Dify 源码，洞察 Dify RAG 核心机制

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

2024-07-17 18:14:04 1193

在上一篇文章中介绍了 FATE 的作业处理流程，对于资源管理没有深入介绍，本篇文章就是来补充相关细节。众所周知，FATE 是一个联邦学习框架，涉及了多个参与方（FATE 中叫站点）进行模型的训练，而各个参与方的训练过程都需要使用 CPU 资源和内存资源，因此在作业执行前需要提前先申请好必要的资源，才能避免在执行中避免因为资源不足而导致执行失败。而 FATE 中单个作业会包含多个任务，每个任务需要独立使用一定量的资源，因此任务会有独立的资源申请与释放资源的流程。

2024-07-15 20:43:22 755

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

之前在 GPU 服务器上部署了Dify 服务，使用的是 Dify 与 Xinference 组合，Xinference 部署的大模型是。基于本地部署的服务构建了知识库，并利用首页提供的任务流模板创建了一个 RAG 工作流知识库检索环节预期不需要调用大模型，实际却调用了大模型；本地没有配置 GPT3.5, 为什么会选择 GPT3.5 模型；这篇文章就从问题出发，借助源码与对应的服务 API 请求信息，定位问题的根本原因。从本轮的追踪来看，知识库检索选择N选1召回。

2024-07-15 07:53:23 1019

原创 FATE Flow 源码解析 - 作业提交处理流程

FATE 是隐私计算中最有名的开源项目了，从 star 的数量上来看也可以看出来。截止 2023 年 3 月共收获 4.9k 个 star，但是 FATE 一直被认为代码框架复杂，难以理解，作为一个相关的从业者，后续会持续对 FATE 项目的源码进行解析，方便对隐私计算感兴趣的后来者提供一点点帮助。本文主要基于 FATE-Flow 2022 年 12 月发布的版本 v1.10.0，后续的版本可能略有差异。针对 FATE-Flow 的代码，基于 v1.10.0 的做了一个代码注解的仓库，方便查看具体的代码。

2024-07-12 22:16:04 466

原创基于开源项目二次开发建议方案

一般情况下我们不需要进行开源项目的二次开发，因为开源项目往往会提供良好的封装，可以通过依赖包或 API 服务的形式引入项目中。如果开源项目存在一些问题，我们往往可以通过给开源项目提供 PR 来解决，这样就可以尽可能减少二次开发开源项目的问题。但是某些情况下可能会需要基于开源项目开发自己的服务，需要一个相对长周期二次开发。不需要开源项目后续的更新，这种情况比较简单，直接拉取代码进行开发就好，当然要注意开源项目的版权信息；

2024-07-12 13:13:19 522

原创基于 cookiecutter 的 python 项目模板

使用 Python 这种动态语言进行 web 开发，团队中经常会遇到的问题就是代码的质量比较难控制。Python 语言本身灵活性比较高，不加控制的情况下代码质量可能最后很难维护。而且代码的各方面的标准，比如提示的 lint，代码格式化等等如果不加规范，不同开发者的协作也会比较困难。因此从公司角度来看，一个统一的代码规范是很有必要的。在 Python 的开发过程中，可以选择公司希望遵循的 Python 开发相关的规范，那么如何更好地将这些规范组织起来呢？

2024-07-11 21:50:48 800

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

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

2024-07-11 20:46:38 1487

原创深入探索联邦学习框架 Flower

通过上面的内容，将 Flower 框架的动手实践以及对应的实现细节都介绍到了，主要涉及到 Flower 三大核心组件中的 Strategy 与 FL loop，而 ClientManager 目前没有过多展开，这部分主要用于管理客户端的连接，有兴趣的可以自行去探索下。从目前来看，Flower 基本上是一个最精简的横向联邦学习的实现方案了，通过必要的抽象简化，Flower 将横向联邦用简单易用的方式进行了封装，对于了解横向联邦学习有很大的帮助。

2024-07-09 20:40:19 1152

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

有道 QAnythingRAGFlow中科院 GoMateDifyFastGPT群里一直看到有小伙伴询问在实际的业务需求中如何选择合适的 RAG 项目，本文就详细对比一下这些 RAG 项目。考虑到目前实际发展程度，GoMate 目前的可靠性还不适合在生产环境使用。因此主要对比其他几个更成熟的热门开源项目。如果只关心技术选项结论，可以直接跳到最后。项目Star 数量持续维护性社区活跃度代码质量版权信息QAnything10.6k⭐️⭐️⭐️⭐️⭐️⭐️Apache-2.0RAGFlow。

2024-07-09 13:56:57 1440

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

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

2024-07-08 11:09:27 827

原创一款纯 js 实现的大模型应用服务 FastGPT 解读

最近被不同的人安利了FastGPT项目，实际上手体验了一下，使用流程类似之前调研过的Dify, 包含的功能主要是：任务流的编排，知识库管理，另外还有一些外部工具的调用能力。使用页面如下所示：实际去看了下项目的代码分布，结果发现如下所示：难道后端 Python 只需要如此少的代码量就可以实现一个大模型应用了？深入了解了 FastGPT 的实现，发现其 Python 为测试代码，完整的项目实现都是基于前端语言 ts 和 js 实现。这篇文章就主要介绍下 FastGPT 知识库 RAG 设计的实现细节。

2024-07-05 10:10:36 1279

原创 Github 上 Star 数最多的大模型应用基础服务 Dify 深度解读（一）

接触过大模型应用开发的研发同学应该都或多或少地听过 Dify 这个大模型应用基础服务，这个项目自从 2023 年上线以来，截止目前（2024-6）已经获得了 35k 多的 star，是目前大模型应用基础服务中最热门的项目之一。这篇文章对 Dify 中核心的基础模块 RAG 服务进行深入解读，后续可能会更新其他模块的内容。Dify 是一个LLMOps服务, 涵盖了大语言模型（如GPT系列）开发、部署、维护和优化的一整套实践和流程。可以大幅简化大模型应用的开发。

2024-07-01 14:07:27 1055

原创来自工业界的知识库 RAG 服务(五)，模块化知识库 GoMate 实现方案详解

很早以前就看过一篇介绍 RAG 的综述性文章, 其中介绍了 RAG 的模块化架构：但是一直没有看到对应的实现方案，以前也没有理解此框架的优势之处。随着在相关领域的持续实践，逐渐理解到模块化 RAG 的优势。模块化 RAG 可以方便地进行服务的迭代升级，另外模块可以自由组合，灵活性更好。最近注意到来自中科院的 RAG 服务GoMate开源了，核心亮点就是模块化 RAG 设计，本文就深入介绍来 GoMate 的框架设计与实现细节。

2024-06-24 23:50:53 1092 2

原创从 0 打造私有知识库 RAG Benchmark 完整实践

最近从 0 构建了一个大模型知识库 RAG 服务的自动化 Benchmark 评估服务，可以基于私有知识库对 RAG 服务进行批量自动化测试与评估。本文是对这个过程的详细记录。本文实际构建的是医疗行业知识库，基于高质量的医学指南和专家共识进行构建。而实际的问答对也基础知识库已有文档生成，避免参考源不存在导致的大模型幻觉，可以更加客观反映 RAG 服务的能力。当然整体的构建流程是与行业无关的，可以参考构建其他的测评知识库。

2024-06-19 13:11:56 692

原创来自工业界的知识库 RAG 服务(四)，FinGLM 竞赛冠军项目详解

在前一篇文章中介绍过智谱组织的一个金融大模型 RAG 比赛FinGLM以及 ChatGLM反卷总局团队的项目，这篇文章继续介绍下获得冠军的馒头科技的技术方案。建议不了解比赛背景信息的可以先查看来自工业界的知识库 RAG 服务(三)，FinGLM 竞赛获奖项目详解，方便更好地理解技术方案的设计。本文主要整理了 FinGLM 获得冠军的团队提供的方案，从处理流程来看，亮点不是特别突出，最终表现良好与其精细的问题分类以及有针对性的微调模型应该有不少的关系。

2024-06-17 13:00:55 1036

原创来自工业界的知识库 RAG 服务(三)，FinGLM 竞赛获奖项目详解

前面介绍过工业界的 RAG 服务QAnything和RagFlow的详细设计，也介绍过来自学术界的一些优化手段。前一阵子刚好看到智谱组织的一个金融大模型比赛FinGLM，主要做就是 RAG 服务的竞赛，深入研究了其中的几个获奖作品，感觉还是有不少亮点。整理一些获奖项目的设计方案，希望对大家有所启发。FinGLM是基于一定数量的上市公司财报构建知识库，使用 ChatGLM-6B 作为大模型完成知识库问答。

2024-06-06 14:50:05 882

原创来自学术界的知识库 RAG 调优方案实践（一)

在之前的文章详细梳理过工业界的 RAG 方案QAnything和RagFlow，这次主要整理下来自学术界的一系列 RAG 优化方案。主要关注优化方案对应的设计思想以及相关的实现，希望可以对大家的 RAG 服务效果提升有所帮助。在综述论文Native RAG: 原始 RAG 架构，对应最原始的 RAG 流程，和之前搭建离线私有大模型知识库介绍的流程基本一致；Advanced RAG：高级 RAG 架构，在原始 RAG 上增加了一些优化手段，之前实践过的RAG Rerank。

2024-05-28 17:44:42 1112

原创基于 Pre-commit 的 Python项目代码风格统一实践

Pre commit是 git 提供的预提交机制，可以在创建 commit 之前执行预定义的钩子程序，从而方便执行必要的代码检查。而在实践中可能会需要执行大量的钩子程序，如果来管理这些钩子程序呢，Pre-commit就是其中一个应用较多的框架，通过这个框架可以比较方便地管理大量的预提交钩子程序，这样简化了维护成本。如何来使用 Pre-commit 框架呢？安装 Pre-commit框架，一般情况下 pip 安装下即可；在工程中添加文件，需要安装的钩子程序都是维护在这个配置文件中的；通过。

2024-05-27 21:17:33 1132

原创从《红楼梦》的视角看大模型知识库 RAG 服务的 Rerank 调优

在之前的文章有道 QAnything 源码解读中介绍了有道 RAG 的一个主要亮点在于对 Rerank 机制的重视。从目前来看，Rerank 确实逐渐成为 RAG 的一个重要模块，在这篇文章中就希望能讲清楚为什么 RAG 服务需要 Rerank 机制，以及如何选择最合适的 Rerank 模型。最终以完整的《红楼梦》知识库进行实践。至于为什么要用红楼梦，答案就是作为读了很多遍《红楼梦》的忠实粉丝，问题的答案是不是靠谱一眼就能判断，问题相关的片段也能快速定位，就像定位 bug 一样快。

2024-05-25 17:44:53 1797

原创深入了解 Python 生成器与协程机制

在 Python 中由于 GIL 锁的存在，多线程的并发效率不高。为了比较高效地实现并发，在 Python 中一般的方案是采用多进程 + 协程的方案。协程也被称为纤线程，是一种程序级别的并发控制，多个协程会执行在同一线程中。协程的思想是由程序自身指定中断点，在 IO 操作时，程序可以自行中断，主动放弃 CPU，此时调度另外的协程继续运行。当 IO 就绪后，再调度此程序从中断点继续向下执行。Python 中的协程是基于生成器实现的，在 Python 3 的版本演化中，生成器与协程的概念反复纠缠。

2024-05-25 10:41:13 310

原创来自工业界的知识库 RAG 服务(二)，RagFlow 源码全流程深度解析

前面介绍过有道 QAnything 源码解析，通过深入了解工业界的知识库 RAG 服务，得到了不少调优 RAG 服务的新想法。因此本次趁热打铁，额外花费一点时间，深入研究了另一个火热的开源 RAG 服务RagFlow的完整实现流程，希望同样有所收获。首先依旧可以先从框架图入手，与常规的 RAG 架构进行一些比较可以看到右侧知识库被明显放大，同时最右侧详细介绍了文件解析的各种手段，比如OCR等，这些在常规的 RAG 中可能会作为一个不起眼的。

2024-05-24 11:15:16 2702 3

原创 Python 上下文管理

都修改为 raise Exception()，就会发现区别，采用类实现的上下文管理，在出现异常的情况下可以执行清理工作，基于生成器的方式却会直接退出，不会执行清理工作。对于上下文管理，无非是在执行真正的操作前执行预处理，在执行解释后进行清理工作，而且清理工作是必须执行的，即使出现了异常，清理也会执行。在这样的上下文管理下，用户可以打开文件后，可以不用关心的文件的释放，甚至在文件打开成功打开，但是执行出错时，也会正确释放文件资源。对于就可以知道，采用上下文管理的方式，可以大大缩短代码。

2024-05-24 08:47:19 258 1

原创来自工业界的大模型知识库 RAG 服务，有道 QAnything 源码全流程深度解析

之前在做大模型知识库 RAG 优化时，主要参考的都是学术界的论文。最近了解到有道 QAnything 开源了，在线试用之后，效果看起来还不错，燃起了探索其实现细节的兴趣。正好对于 RAG 各个环节的最佳实践存在一些疑问，因此深入查看了有道 QAnything 的完整实现流程，学习下来自工业界大厂有道的实践方案，在这边分享给大家。本文章基于的是 2024-5 月最新的版本v1.4.0，这个项目还在持续迭代中，后续的版本可能会存在差异。首先可以关注下 QAnything 的架构设计，与常规的 RAG 架构。

2024-05-23 10:03:55 1442 1

原创 Oh my zsh 配置与插件

按照oh my zsh 官方的介绍，oh my zsh 是一种你用了其他人就会追着喊着叫你天才的工具，听起来是某种装逼利器，而且效率成倍提升。那么oh my zsh 到底是什么呢？在我看来，可以理解为：装逼的主题皮肤 + 提升效率的插件。可以将你的终端效率成倍提升，简直懒人神器。那还等什么，赶紧用起来。

2024-05-23 08:51:05 887 1

原创 Flask 0.1 源码解析

在flask启动中，需要创建一个Flask对象，然后调用此对象的run()方法启动应用，在run()方法中，会将当前的Flask对象注册为网络请求处理对象，后续的网络请求都会调用当前对象的__call__()方法进行处理，而__call__()实际调用的是wsgi_app()方法进行处理。在处理请求时，会利用请求的信息environ创建单个请求对象，此对象会存储单个请求相关的所有信息，然后将请求对象加入到请求栈中，在处理过程中，可以通过获取本次请求对象。在请求对象中存在。

2024-05-22 08:54:25 1022

原创基于 gRPC interceptors 的请求跟踪探索

整体的实现并不复杂，但是对于 gRPC 的调试效率提升还是蛮多的，后续追踪问题更加方便了。调试 bug 是一个比较费心费力的过程，尽可能通过通用的机制方便自己，才能节省出更多摸鱼的时间呀。

2024-05-22 07:57:05 596

原创程序员的福音，AI 项目生成 GPT Engineer 实践与源码解析

是一个基于需求描述自动生成项目源码的开源项目，主打轻量，灵活生成项目源码，可以在 AI 生成与人工生成之间进行切换，底层是基于 GPT-4 对应的编程能力，目前 Github 上 star 数量已经达到了 50k，算是一个十分火热的 AI 项目。与大热的AutoGPT相比，GPT Engineer 更加轻量，没有使用递归的请求调用，避免陷入反复请求的死循环。同时 GPT Engineer 更加侧重代码生成，因此 prompt 上针对代码生成上做了针对性的优化。

2024-05-21 09:10:59 1107

原创深入了解 Flask 框架中的 Local，localStack，localProxy

可以看到上面的LocalStack实现的代码，内部使用Local进行数据的存储，由于Local内部每个线程使用dict进行数据存储，为了简单实现，LocalStack使用了线程中dict的其中的key进行数据存储，这个key就是’stack’字符串，这个key对应的值就是一个普通的数组，利用数组可以比较容易就实现栈。为了实现线程隔离的数据访问，一种比较显而易见的方式就是构建一个dict，根据每个线程的id去创建独立的数据，当访问数据时，根据当前线程的id进行访问，每个线程访问自己的数据即可。

2024-05-21 07:41:15 758 1

原创人 GPT 协作，两周从 0 手撸一个量化交易回测平台

掌握技能最快的方法就是用技能创造产品，前一阵子对 GPT 辅助编程与项目生成做过较多的调研，但是一直处于试水阶段，没能发挥出 GPT 辅助编程的能力。本次从新领域入手，借助 GPT 的力量，从 0 手撸一个量化交易回测平台，从这个过程看看 GPT 辅助编程到底有多强，能多大程度帮助程序员，是否有可能替代程序员。文章本来是希望介绍量化交易回测工具的从 0 手撸的实现过程，但是实际想想，授人予鱼不如授人予渔，单个量化交易回测工具作用有限，但是如果用好了 GPT 工具，只需要花上一丢丢时间，你也能创造一个。

2024-05-20 08:49:09 1159

易迟的专栏