- 博客(55)
- 收藏
- 关注
RSS订阅原创 来自工业界的知识库 RAG 服务(七)，RagFlow 知识图谱实践与优化方案探索
在2024年，我曾撰写过RagFlow 源码全流程深度解析，对 RagFlow 的完整 RAG 流程进行了深入剖析。自那时起，RagFlow 经历了多轮迭代演进，不仅增强了 Agent 能力，更是在知识图谱支持方面取得了显著进展。最近，RagFlow 公众号发布了RAGFlow 0.16.0 特性总览，详细介绍了 RagFlow 对知识图谱机制的优化。本文将对 RagFlow 的知识图谱实现流程与机制进行深入分析，帮助读者更好地理解其实现细节，从而更有效地利用 RagFlow 的相关功能。
2025-04-03 16:12:50
514
原创 为 AI 应用打造安全屏障：基于 Dify 的完整实践
2025 年是大模型应用爆发的一年。从年初的 DeepSeek 吸引大量开发者部署大模型产品，到 Manus 和 MCP 等 Agent 方案持续引发关注，行业内掀起了一股打造爆款大模型应用的热潮。然而，在这股热潮中，大模型的安全性问题往往被忽视。事实上，AI 应用的安全性是实现完整大模型应用的关键环节。2024 年的一篇文章中，曾介绍过大模型应用的完整架构：其中，安全模块主要包括输入围栏(Input guardrails)和输出围栏(Output guardrails)。
2025-03-26 12:39:04
879
原创 祛魅 Manus ，从 0 到 1 开源实现
Manus 是最近一个现象级的大模型 Agent 工具，自从发布以来，被传出各种神乎其神的故事，自媒体又开始炒作人类大量失业的鬼故事，Manus 体验码也被炒作为 10w 的高价。之后又出现反转，被爆出实际体验效果不佳，存在造假的问题，Manus在X平台的账号被冻结。沟通之后，3月8日，Manus官方X账号又被解冻。Manus 的故事一波三折，开源社区也没有闲着，MetaGPT 团队在 Manus 发布后 3 小时就开源了OpenManus。
2025-03-09 19:21:58
820
原创 $200 劝退，无缘 Deep Research，可以试试 AutoSurvey
最近各种新的大模型辅助科研工具持续出现，在之前的文章中就介绍过NVIDIA 的结构化报告生成方案，最近 OpenAI 也推出了类似的产品，叫做。Deep Research 可以根据需要进行深度的调研与信息整理，但是只有 Pro 用户才能享受到，$200 的价格直接劝退。在调研后发现了开源项目AutoSurvey，相对之前的 NVIDIA 的方案更加完整，不仅包含了完整的报告生成，还能自动生成文献列表。AutoSurvey 是一个基于大语言模型的自动综述生成工具。它的整体流程如下所示：大纲生成；
2025-02-12 12:27:44
916
原创 NVIDIA 结构化报告生成方案详解
最近被2024年底的大量RAG总结的论文列表轰炸了一番，密集阅读大量论文时，真切感受到深入了解一个领域论文对精力的消耗是巨大的。刚好注意到来自NVIDIA的结构化报告生成方案，如果真的可行，是否可以使用大模型一次性阅读大量的论文，并生成脉络清晰的报告，基于报告选择合适的论文进行阅读，是否可以大大减少阅读论文的时间。因此深入研究了NVIDIA的方案，希望后续在此基础上进行二次改良，实现自己的论文阅读助手，真正减少探索单个领域论文消耗的大量精力。
2025-01-20 10:30:15
694
原创 来自工业界的知识库 RAG 方案（一）：多轮会话优化
在RAG 最佳实践中，我介绍了 RAG 的各个核心模块的最佳实践方案，包括文件解析、分片、向量化、检索、重排序等。据此已经得到一个具备良好效果的 RAG 应用，但是如果想生成一个具体良好体验的 RAG 服务，还有一些问题需要优化。从目前客户的反馈来看，多轮会话的优化是用户最关心的点之一。我们人类进行交流时，往往都是你来我往的多轮沟通，因此对大模型应用的用户而言，很自然会带入日常的交流习惯，比如：在医疗场景下，用户向大模型提供症状描述后，大模型往往会给出诊断建议。之后用户往往会追问那应该怎么治疗呢？或者。
2024-12-10 17:31:05
1390
原创 RAG 最佳实践
最近刚刚结束 CCF 的基于运营商文本数据的知识库检索，截止目前成绩还算不错，A榜和B榜排名都比较靠前。因为在比赛中实际是从 0 迭代最终的策略，因此耗时较长。最近在考虑 RAG 是否存在一些最佳实践，在不同的数据集或通用场景下都能取得不错的效果，这样就可以避免从头开始构建策略。刚好注意到近期有一些相对靠谱的行业进展，AutoRAG就尝试基于数据集构造 QA 问答对，之后利用定义的指标，寻找最佳的 RAG 策略组合。
2024-11-25 12:51:17
1058
1
原创 AIOps RAG 比赛获奖项目 EasyRAG 深度解读
最近抽空参与 CCF 的 RAG 比赛，系统性对 RAG 检索中多种多样的检索优化方案进行了测试和对比，也发现了不少之前没有注意到的优化细节。从目前的实践来看，比赛确实是一个绝佳策略测试场所，很公平地对不同的优化方案进行了客观比较。实践中不时会发现直观感觉很有效的策略不生效，有些看起来平平无奇的策略反而效果绝佳。根据结果反向分析策略，更容易理解不同策略背后的适用场景和优劣，也可以帮助认识自己技能的盲区。最近几天刚好看到 AIOps RAG 比赛的获奖方案EasyRAG。
2024-10-29 11:11:25
1370
原创 RAG 分块检索难，Late Chunking 值得试试
实际线上部署使用过 RAG （Retrieval Augmented Generation）服务的研发同学或多或少都会发现，按照常规的 RAG 方案进行文本切片并向量化之后，部分文本切片可能难以检索命中。这个往往是因为对应的分片缺失可供检索的信息。以医疗领域的病例检索为例，单个病例文件中病情描述（现病史）一般在文档最上面，相关的诊断结论在文档最下面，而病例的诊断结论中一般没有任何相关的病例描述。按照常规的 RAG 方式进行分片后，病情描述与诊断结论完全分离了。
2024-10-09 13:42:12
1110
原创 开箱即用的大模型应用跟踪与批量测试方案
最近抽空参加了一个讯飞的 RAG 比赛，耗时两周终于在最后一天冲上了榜首。整体的框架是基于 RAG 能力有点弱弱的 Dify 实现。在比赛调优的过程中，经常需要批量提交几百个问题至 Dify 获取回答，并需要跟踪多轮调优的效果差异。借助 Langfuse 可以通过网页跟踪结果，相对比较方便了很多。但是现有版本的 Langfuse 不支持提交文件构建数据集，私有化部署的版本也不支持自动化评估，多版本的比较很麻烦。在比赛期间断断续续实现了一些自动化脚本进行辅助，比赛结束后感觉确实很实用，因此就有了这个项目。
2024-09-27 19:43:51
1047
原创 你的大模型应用表现真的好吗？借助 Dify + Langfuse 一探究竟
众所周知，大模型应用的输出存在着一些不确定性，往往需要迭代多轮才能得到较为稳定的输出结果，因此开发者往往需要关注大模型应用的实际表现，并进行有针对性的优化。然而常规 Web 服务的监控机制往往无法满足大模型应用的监控需求，因为大模型应用往往关注的不仅仅是响应延迟、吞吐量等基础指标，而是需要关注大模型应用输出的语义正确性。因此，本文将介绍如何借助 Dify 和 Langfuse 工具，展示如何为大模型应用必要监控，方便进行有定向优化。Dify。
2024-09-15 09:22:16
1623
2
原创 给大模型加上“记忆”，深入探索 Mem0 项目
在之前的软件应用中，我们总会在应用中保留大量的用户历史操作记录，方便用户下次使用时可以快速查看和复用，甚至基于这些用户记录可以为用户提供个性化的服务。而这些记录往往都保存在传统的结构化或非结构化数据库中。在大模型的应用，特别是助手类的大模型应用中，我们往往需要处理大量语义化的文本或多模态的信息，方便后续快速匹配，从而提供个性化的服务。为了支持这种语义检索的需求，往往会将数据保存至向量数据库中。向量数据库执行语义检索相对方便，但是包含语义内容的文本管理比较困难，特别是涉及到相关内容的更新和替换。
2024-09-03 17:03:54
1531
2
原创 FATE Board 执行流程探索
FATE Board 是 FATE 提供的一个工程，用于给 FATE 提供可视化能力，方便在联邦学习训练中实时查看执行状态，更好地定位执行中遇到的问题。查看 FATE 架构可以看到 FATE Board 是建立在 MySQL 和 FATE Flow Server 的基础上的，看起来数据来源是来自于这两者。FATE Flow Server 在之前的文章中已经介绍过，FATE 中隐私计算的主要调度流程都是实现在这个服务中。FATE Board 代码仓库地址。
2024-08-29 21:41:40
1298
原创 来自工业界的知识库 RAG（六），独特的 RAG 框架 dsRAG 核心亮点解读
在前面介绍了较多的开源 RAG 框架，比如主打 Rerank 的QAnything, 主打精细文件解析的RagFlow, 主打模块化灵活组合的GoMate。这些库的设计除了少量的独特之处外，相似的部分很多。最近有注意到一款另类的 RAG 框架dsRAG，使用了较多独特的 RAG 优化方案，因此花了一些时间对其核心亮点进行了考察，整理相关内容在这边。
2024-08-29 18:10:37
1523
2
原创 深入源码，洞察迭代 8 年的 html 文本转换库
在前面RAG 项目结构化文件解析方案比较文章中对常见的 html 解析方案进行了比较，发现 html_text + python-readability 可以实现高质量的 html 内容提取。在前一篇文章迭代 14 年的高质量 html 提取方案中对 python-readability 库进行了介绍，这篇文章就对剩下的html_text库进行介绍。忽略内联样式、javascript、注释和其他用户通常不可见的文本；空白内容标准化，在内联元素周围添加空格分隔内容；
2024-08-26 09:19:25
897
原创 深入源码，洞察迭代 14 年的高质量 html 提取方案
在大模型时代，开源项目的生命周期被加速了，往往迭代速度很快，但是热门项目也容易突然就无疾而终了。最近看到一款历经 14 年的开源 html 内容提取项目，从最早建立到目前，已经迭代了 14 年。本文是在实际项目中使用 python-readability 之后，发现一些异常 case，因此深入源码了解其中的技术细节，因此在本文中对这款跨越 14 年的开源项目的技术细节进行了解读。在之前的RAG 项目结构化文件解析方案比较。
2024-08-26 07:39:20
920
原创 Dify框架增强：RAG 能力提升探索与实践
在之前的文章来自工业界的开源知识库 RAG 项目最全细节对比中介绍过，现有 RAG 开源项目中，Dify 的生态良好，但是一个明显的短板就是 RAG 检索能力偏弱。因此一直期望能补全这个短板，从而让 Dify 能真正好用起来。在基于开源项目二次开发建议方案探索了 Dify 的增强策略。实际选择了文章中提到的中策，基于模块化增强 Dify。Dify 的 RAG 已经支持了大量的 RAG 基础能力与可视化页面，如果通过额外的插件拓展支持，那么现有的 RAG 基础流程无法复用，开发的工作量太大。
2024-08-14 15:12:56
3512
1
原创 深入 Dify 源码，洞察 Dify RAG 切片机制实现细节
最近测试时发现 Dify 的 RAG 分片效果一般，不管是使用之前深入 Dify 源码，洞察 Dify RAG 核心机制中有调研过的默认解析还是 Unstructured 解析。因此调研比较了大量的开源框架实现了特定格式的结构化解析方案，并与 Dify 现有解析流程进行了适配。为了保证文件的解析能真正发挥出效果，需要保证预处理中其他环节也遵循前面的结构化方案进行处理，其中重要的一块就是文本的分片机制。深入了解 Dify 的实现细节后整理相关内容在这边，方便对 Dify RAG 实现机制感兴趣的同学。
2024-08-06 16:26:01
3400
原创 来自工业界的开源知识库 RAG 项目结构化文件解析方案比较
在过去实践 RAG 的过程中，深刻体会到RAGFlow提出的, 只有高质量的文件处理才能获得良好的 RAG 效果。RAG 的第一步是对文件进行解析，由于 Embedding 和 LLM 模型的长度限制，往往需要将解析后的文件进行切片。原始的 RAG 就是直接按照固定长度对文件进行切分，导致最终检索到的内容都是碎片化的，效果往往不佳。因此后续的改进期望能按照文件的结构进行切分，保证分块信息的完整性，这就是所谓的。
2024-08-01 15:59:01
1646
原创 FATE Flow 源码解析 - 日志输出机制
在之前的文章中介绍了 FATE 的作业处理流程，在实际的使用过程中，为了查找执行中的异常，需要借助运行生成的日志，但是 FATE-Flow 包含的流程比较复杂，对应的日志也很多，而且分散在不同的文件中，在这篇文章中就对 FATE-Flow 的日志机制进行梳理，帮助大家了解 Python 服务中实现一个更加灵活的日志机制。
2024-07-17 20:39:04
1137
原创 深入 Dify 源码，洞察 Dify RAG 核心机制
之前深入源码对 Dify 的完整流程进行了解读，基本上梳理了 Dify 的实现流程与主要组件。但是在实际部署之后，发现 Dify 现有的 RAG 检索效果没有那么理想。因此个人结合前端页面，配置信息与实现流程，深入查看了私有化部署的 Dify 的技术细节。将核心内容整理在这边，方便大家根据实际的业务场景调整 Dify 知识库的配置，或者根据需要进行二次开发调优。
2024-07-17 18:14:04
10364
3
原创 FATE Flow 源码解析 - 资源分配流程
在上一篇文章中介绍了 FATE 的作业处理流程，对于资源管理没有深入介绍，本篇文章就是来补充相关细节。众所周知，FATE 是一个联邦学习框架，涉及了多个参与方（FATE 中叫站点）进行模型的训练，而各个参与方的训练过程都需要使用 CPU 资源和内存资源，因此在作业执行前需要提前先申请好必要的资源，才能避免在执行中避免因为资源不足而导致执行失败。而 FATE 中单个作业会包含多个任务，每个任务需要独立使用一定量的资源，因此任务会有独立的资源申请与释放资源的流程。
2024-07-15 20:43:22
883
原创 深入 Dify 源码，定位知识库检索的大模型调用异常
之前在 GPU 服务器上部署了Dify 服务，使用的是 Dify 与 Xinference 组合，Xinference 部署的大模型是。基于本地部署的服务构建了知识库，并利用首页提供的任务流模板创建了一个 RAG 工作流知识库检索环节预期不需要调用大模型，实际却调用了大模型；本地没有配置 GPT3.5, 为什么会选择 GPT3.5 模型；这篇文章就从问题出发，借助源码与对应的服务 API 请求信息，定位问题的根本原因。从本轮的追踪来看，知识库检索选择N选1召回。
2024-07-15 07:53:23
4833
4
原创 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
600
原创 基于开源项目二次开发建议方案
一般情况下我们不需要进行开源项目的二次开发，因为开源项目往往会提供良好的封装，可以通过依赖包或 API 服务的形式引入项目中。如果开源项目存在一些问题，我们往往可以通过给开源项目提供 PR 来解决，这样就可以尽可能减少二次开发开源项目的问题。但是某些情况下可能会需要基于开源项目开发自己的服务，需要一个相对长周期二次开发。不需要开源项目后续的更新，这种情况比较简单，直接拉取代码进行开发就好，当然要注意开源项目的版权信息；
2024-07-12 13:13:19
1754
原创 基于 cookiecutter 的 python 项目模板
使用 Python 这种动态语言进行 web 开发，团队中经常会遇到的问题就是代码的质量比较难控制。Python 语言本身灵活性比较高，不加控制的情况下代码质量可能最后很难维护。而且代码的各方面的标准，比如提示的 lint，代码格式化等等如果不加规范，不同开发者的协作也会比较困难。因此从公司角度来看，一个统一的代码规范是很有必要的。在 Python 的开发过程中，可以选择公司希望遵循的 Python 开发相关的规范，那么如何更好地将这些规范组织起来呢？
2024-07-11 21:50:48
988
原创 Dify 与 Xinference 最佳组合 GPU 环境部署全流程
在前一篇文章RAG 项目对比之后，确定 Dify 目前最合适的 RAG 框架。本次就尝试在本地 GPU 设备上部署 Dify 服务。Dify 是将模型的加载独立出去的，因此需要选择合适的模型加载框架。调研一番之后选择了Xinference支持多种类型的模型，包括 LLM，Embedding, Rerank, Audio 等多种业务场景的模型需求，一个框架全搞定；方便的模型管理能力，提供可视化页面快速部署模型支持直接从 ModelScope 下载模型，避免 huggingface 被墙的问题；
2024-07-11 20:46:38
5395
原创 深入探索联邦学习框架 Flower
通过上面的内容，将 Flower 框架的动手实践以及对应的实现细节都介绍到了，主要涉及到 Flower 三大核心组件中的 Strategy 与 FL loop，而 ClientManager 目前没有过多展开，这部分主要用于管理客户端的连接，有兴趣的可以自行去探索下。从目前来看，Flower 基本上是一个最精简的横向联邦学习的实现方案了，通过必要的抽象简化，Flower 将横向联邦用简单易用的方式进行了封装，对于了解横向联邦学习有很大的帮助。
2024-07-09 20:40:19
2573
原创 来自工业界的开源知识库 RAG 项目最全细节对比
有道 QAnythingRAGFlow中科院 GoMateDifyFastGPT群里一直看到有小伙伴询问在实际的业务需求中如何选择合适的 RAG 项目，本文就详细对比一下这些 RAG 项目。考虑到目前实际发展程度，GoMate 目前的可靠性还不适合在生产环境使用。因此主要对比其他几个更成熟的热门开源项目。如果只关心技术选项结论，可以直接跳到最后。项目Star 数量持续维护性社区活跃度代码质量版权信息QAnything10.6k⭐️⭐️⭐️⭐️⭐️⭐️Apache-2.0RAGFlow。
2024-07-09 13:56:57
11717
1
原创 官方技术文档查询大模型：快速搭建与实践记录
在过去使用大模型的过程中，感受到大模型能力的持续提升。但是作为程序员，在基于不熟悉的框架开发新功能时，依旧需要持续查询官方文档。而大模型对特定框架的使用细节所知甚少，因此可能给出的回答不够准确。比如之前在快速搭建量化交易平台时因为不熟悉相关框架就需要反复查看Dash和backtrader的官方文档寻找解决方案，这部分工作需要花费不少时间。事实上单个项目的技术框架选型完成后就会稳定下来，因此是否可以直接基于框架的官方文档进行知识库问答。这样就可以避免重复的查询文档，节省时间。
2024-07-08 11:09:27
1605
原创 一款纯 js 实现的大模型应用服务 FastGPT 解读
最近被不同的人安利了FastGPT项目，实际上手体验了一下，使用流程类似之前调研过的Dify, 包含的功能主要是：任务流的编排，知识库管理，另外还有一些外部工具的调用能力。使用页面如下所示：实际去看了下项目的代码分布，结果发现如下所示：难道后端 Python 只需要如此少的代码量就可以实现一个大模型应用了？深入了解了 FastGPT 的实现，发现其 Python 为测试代码，完整的项目实现都是基于前端语言 ts 和 js 实现。这篇文章就主要介绍下 FastGPT 知识库 RAG 设计的实现细节。
2024-07-05 10:10:36
2404
原创 Github 上 Star 数最多的大模型应用基础服务 Dify 深度解读（一）
接触过大模型应用开发的研发同学应该都或多或少地听过 Dify 这个大模型应用基础服务，这个项目自从 2023 年上线以来，截止目前（2024-6）已经获得了 35k 多的 star，是目前大模型应用基础服务中最热门的项目之一。这篇文章对 Dify 中核心的基础模块 RAG 服务进行深入解读，后续可能会更新其他模块的内容。Dify 是一个LLMOps服务, 涵盖了大语言模型（如GPT系列）开发、部署、维护和优化的一整套实践和流程。可以大幅简化大模型应用的开发。
2024-07-01 14:07:27
7857
原创 来自工业界的知识库 RAG 服务(五)，模块化知识库 GoMate 实现方案详解
很早以前就看过一篇介绍 RAG 的综述性文章, 其中介绍了 RAG 的模块化架构：但是一直没有看到对应的实现方案，以前也没有理解此框架的优势之处。随着在相关领域的持续实践，逐渐理解到模块化 RAG 的优势。模块化 RAG 可以方便地进行服务的迭代升级，另外模块可以自由组合，灵活性更好。最近注意到来自中科院的 RAG 服务GoMate开源了，核心亮点就是模块化 RAG 设计，本文就深入介绍来 GoMate 的框架设计与实现细节。
2024-06-24 23:50:53
1703
2
原创 从 0 打造私有知识库 RAG Benchmark 完整实践
最近从 0 构建了一个大模型知识库 RAG 服务的自动化 Benchmark 评估服务，可以基于私有知识库对 RAG 服务进行批量自动化测试与评估。本文是对这个过程的详细记录。本文实际构建的是医疗行业知识库，基于高质量的医学指南和专家共识进行构建。而实际的问答对也基础知识库已有文档生成，避免参考源不存在导致的大模型幻觉，可以更加客观反映 RAG 服务的能力。当然整体的构建流程是与行业无关的，可以参考构建其他的测评知识库。
2024-06-19 13:11:56
1118
原创 来自工业界的知识库 RAG 服务(四)，FinGLM 竞赛冠军项目详解
在前一篇文章中介绍过智谱组织的一个金融大模型 RAG 比赛FinGLM以及 ChatGLM反卷总局 团队的项目，这篇文章继续介绍下获得冠军的馒头科技的技术方案。建议不了解比赛背景信息的可以先查看来自工业界的知识库 RAG 服务(三)，FinGLM 竞赛获奖项目详解，方便更好地理解技术方案的设计。本文主要整理了 FinGLM 获得冠军的团队提供的方案，从处理流程来看，亮点不是特别突出，最终表现良好与其精细的问题分类以及有针对性的微调模型应该有不少的关系。
2024-06-17 13:00:55
1407
原创 来自工业界的知识库 RAG 服务(三)，FinGLM 竞赛获奖项目详解
前面介绍过工业界的 RAG 服务QAnything和RagFlow的详细设计，也介绍过来自学术界的一些优化手段。前一阵子刚好看到智谱组织的一个金融大模型比赛FinGLM，主要做就是 RAG 服务的竞赛，深入研究了其中的几个获奖作品，感觉还是有不少亮点。整理一些获奖项目的设计方案，希望对大家有所启发。FinGLM是基于一定数量的上市公司财报构建知识库，使用 ChatGLM-6B 作为大模型完成知识库问答。
2024-06-06 14:50:05
1209
原创 来自学术界的知识库 RAG 调优方案实践（一)
在之前的文章详细梳理过工业界的 RAG 方案QAnything和RagFlow，这次主要整理下来自学术界的一系列 RAG 优化方案。主要关注优化方案对应的设计思想以及相关的实现，希望可以对大家的 RAG 服务效果提升有所帮助。在综述论文Native RAG: 原始 RAG 架构，对应最原始的 RAG 流程，和之前搭建离线私有大模型知识库介绍的流程基本一致；Advanced RAG：高级 RAG 架构，在原始 RAG 上增加了一些优化手段，之前实践过的RAG Rerank。
2024-05-28 17:44:42
1966
原创 基于 Pre-commit 的 Python项目代码风格统一实践
Pre commit是 git 提供的预提交机制，可以在创建 commit 之前执行预定义的钩子程序，从而方便执行必要的代码检查。而在实践中可能会需要执行大量的钩子程序，如果来管理这些钩子程序呢，Pre-commit就是其中一个应用较多的框架，通过这个框架可以比较方便地管理大量的预提交钩子程序，这样简化了维护成本。如何来使用 Pre-commit 框架呢？安装 Pre-commit框架，一般情况下 pip 安装下即可；在工程中添加文件，需要安装的钩子程序都是维护在这个配置文件中的；通过。
2024-05-27 21:17:33
1290
原创 从《红楼梦》的视角看大模型知识库 RAG 服务的 Rerank 调优
在之前的文章有道 QAnything 源码解读中介绍了有道 RAG 的一个主要亮点在于对 Rerank 机制的重视。从目前来看，Rerank 确实逐渐成为 RAG 的一个重要模块，在这篇文章中就希望能讲清楚为什么 RAG 服务需要 Rerank 机制，以及如何选择最合适的 Rerank 模型。最终以完整的《红楼梦》知识库进行实践。至于为什么要用红楼梦，答案就是作为读了很多遍《红楼梦》的忠实粉丝，问题的答案是不是靠谱一眼就能判断，问题相关的片段也能快速定位，就像定位 bug 一样快。
2024-05-25 17:44:53
3063
原创 深入了解 Python 生成器与协程机制
在 Python 中由于 GIL 锁的存在，多线程的并发效率不高。为了比较高效地实现并发，在 Python 中一般的方案是采用多进程 + 协程的方案。协程也被称为纤线程，是一种程序级别的并发控制，多个协程会执行在同一线程中。协程的思想是由程序自身指定中断点，在 IO 操作时，程序可以自行中断，主动放弃 CPU，此时调度另外的协程继续运行。当 IO 就绪后，再调度此程序从中断点继续向下执行。Python 中的协程是基于生成器实现的，在 Python 3 的版本演化中，生成器与协程的概念反复纠缠。
2024-05-25 10:41:13
411
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人