Angus

最近大半年时间都在做RAG的工作，分享一点个人探索的方向。和提升的方案。文章中会分享是如何做的，以及对应的效果。

随着大模型的火热，RAG也重出江湖，成为AI产品中最火热的成员之一。特别是2024年到现在，越来越多的RAG产品出现在gitlib 上。 世人皆知RAG，唯独不知RAG的能力边界。 RAG用一句话：入门（demo跑通整个流程）像1一样容易，出神入化（能够达到生产级别的要求）真的还挺难。 RAG相关的工作，做了一年又余。随着时间变化，愈来愈觉得，RAG需要特别多的知识才能真的把它做好。而我在不断的补这些知识，这是一条挺难的路。（我自己把它单做“蜀道难”的登山路）

本文探讨了在RAG中进行搜索时的难度级别及其解决方法。对于容易级别，主要涉及解决搜索问题，而对于困难级别，则需要考虑上下文和复杂性。文中根据斯坦福论文提出了解决这些问题的方法，包括从段落中获取总结性问题的答案，以及利用树形结构组织数据来解决上下文关联问题。

本文介绍了query改写。介绍了七种利用LLM进行query改写方式。包含了10余篇论文，论文有的出自微软、谷歌等大厂之手，还有北大，人大等高校。质量有所保障，对比了不同的query改写的效果。

论文原文这里我先说一下自己的感受，这篇论文整体看下来，没有太多惊艳的地方。核心就是利用知识图谱，通过模型对文档抽取实体和关系。然后基于此来构建查询。核心问题还是在解决知识之间的连接问题。

本文介绍了召回系统的两种评估方式：离线评估和在线评估。离线评估基于标注数据，通过准确率、召回率、F1-Score 等指标衡量模型效果，适合开发初期的算法调试。在线评估则依赖用户行为，如点击率、转化率和停留时长等指标，能够更真实地反映模型在实际环境中的表现。文章详细探讨了各类评估指标的定义、适用场景及其优缺点，并指出最佳实践是先通过离线评估优化模型，再通过在线评估验证其实际效果。

最近的一部分工作，有在做RAG的benchmark。年初三四月份（2024）的时候，调研已有的测试方案的时候，相关工作很少，只有一篇论文。最近再看相关的测试数据集又多了一些。我们虽然也有构建数据集，但是还是相对少一些。今天分享一篇论文，RAG关于法律领域的测试数据集。通常这种数据集需要一些领域知识，才能更好的更充分的构建出来这个数据集。实际上，评估RAG的能力，使用通用数据集是远远不够的。专门的领域测试数据集更权威和合理一些，更能够真实的反应RAG在实际使用场景中的能力。

第一次对索引进行查询时，如果预加载的文件（如 .vec、.vem、.vex 文件）尚未被加载到内存中，Elasticsearch 需要从磁盘读取这些文件，并将它们加载到内存中。占用的是服务器的内存。对于es条件，相同的条件会命中缓存，在测试过程中，应该通过替换检索条件的内容，来避免查询缓存的影响。当新的段文件生成（例如在写入数据或合并段时），这些新的段文件同样需要在首次访问时加载到内存中，这也可能导致第一次查询变慢。经过排查发现，检索的过程中，只用knn检索，耗时短，加上ANN检索后，耗时变长。

RAG中的文档解析需求：需要的是文档的完整段落，标题，图片，表格。我们希望删除的是md格式，或者josn格式。MinerU 和 maker恰好。都是能够满足此需求的开源工具。这篇文章分享一下对两者的对比。

这篇论文，给我很强的割裂感和冲击感。非常值得阅读。我是做RAG相关研究工作的 ，过去一年在做传统的RAG，就是标准的文档解析，chunk，召回，排序，模型生成答案这条路。深谙RAG的复杂，中间要优化的环节太多了。中间要翻的大山太多了，其中文档解析，文件理解，再到去定义M+1个召回策略，很复杂。这篇论文直击痛点，让我觉得很哇塞。这篇论文给很大的冲击感，颠覆了传统的路线，让我觉得如沐春风。论文提出使用依靠多模态模型，来做RAG，这样只需要使用文档的截图就可以了。

毫不夸张的说PDF解析工具MinerU是照进RAG黑暗中的一道光——这是我对它的评价。我测过太多了文档解析工具！ 最近在做文档解析的工作。看了很多的开源的文档解析的工具，版面分析的工具，其中包括paddelpaddel这样30k+star的明星工具。但是效果都觉得不好。MinerU是一个最近开源的文档解析工具，可以把PDF转成json结构，还可以转成md格式。可以解析得到其中的图片，表格，可以得到段落，可以得到标题，这是很哇塞的事情。因为最近RAG特别火热，这些都是RAG非常需要的。

最近有一个新开源的版面分析的模型，做PDF版面分析效果非常好。而且对公式的解析效果比较好。虽然现在star数量不高，但是绝对会涨起来的。我们调研对比过很多开源的工具，效果都强差人意，这个是我看到的最满意的一个。甚至要比我们生产环境的都要好一些。这里分享一下详细的安装过程。 github上的的教程太粗糙了。我把遇到的问题和解决方法都写了出来。 这篇文章分享的是在windows10下安装的案例。且以cpu启动。最终可以成功启动。

过去四年时间，都在处理结构化数据的存储优化相关的工作。最近一段时间在做RAG相关的工作。非结构数据的存储与检索，接触的也越来越多。这篇文章聊聊最近一段时间关于文档理解方面的一些心得。

如果说，rerank能够让RAG的效果实现百尺竿头更进一步，那么LLM微调应该是RAG效果提升的最后一步。把召回的数据，经过粗排，重排序后，送给模型，由模型最后总结答案。LLM的确已经是RAG的最后一步了。这里还是会遇到一个问题，召回的正确的答案，但是答案藏在比较长的上下文中。例如 top10的数据，又或者是top20的数据中。这非常考验模型的能力。看到一篇论文，非常好，在分享如何微调LLM，来做好这最后一步。

相关性模型主要关注的是query和doc的相关性。例如给定query，和1000个doc，找到哪个doc是好query最相关的。

这篇文章分享给做AI搜索的朋友们。少走一些重复的路把。希望这些结果能够帮到大家。这里再分享一些心得。其实我们也在想，为什么现在已经有的AI搜素，他们的联网查询为何这么快？为什么这么稳定？像国内AI搜索做的比较好的，kimi，秘塔，360ai搜索。其中秘塔是被猎豹控股的（猎豹本身就是做搜索引擎的），360浏览器本身也是做搜索引擎的。他们的联网搜索并不是走的爬取网页的方式。前段时间分析过kimi的联网查询，大概率是bing的接口。不过现在就不一定了。

文本检索任务可以定义为: 给定一个文档集合，用户输入一个query来表达信息检索需求，借助于一个文本检索系统返回相关文档给用户。日常生活中，我们几乎天天都在用文本检索系统，比如谷歌、百度搜索，淘宝电商搜索，搜索系统已经成为用户获取信息的一个重要入口。对于文本检索任务，抽象出来的核心目标就是怎么去计算用户输入的 query和文档集合中每个doc的文本相似度。

参考官方文档来操作，基本没太大的问题。一些细节，我在本篇文章中补充了出来。这篇文章主要讲以源码的方式启动后端服务，前端服务使用容器启动。Dify 本地源码部署文档（有本地源码部署，我们才能在源码上继续做修改）先知道要花费多少资源这里docker 容器，占用了8个G的内存！# 创建名为 dify 的 Python 3.10 环境# 切换至 dify Python 环境可以进入到自己的代码常用目录，再拉取代码进入到dify目录可以看到请记住web 和 api的路径，后边会用到。

众所周知，运维领域本身很多的行业特点，比如存在时序指标、日志、调用等多模态数据，对实时数据的要求比较高，数据之间的依赖关系复杂。例如，下图左下角是一个电商系统的样例，可以看到它的节点依赖情况。另外，还存在着领域知识以及多样化的下游场景。所以，当我们真正去做智能运维的时候就会有很多的小模型，需要解决很多的问题，也面临了很多的挑战。但是，大模型出现之后给智能运维带来了一些新的不同和新的变化。应用举例：对根因定位工具进行输入输出增强第一个特点是。

开源的RAG本地知识库检索的有不少。最近比较火热的就是 QAnything 和 RAGflow。其中Qanything 是相对比较早的。并且它是网易开源的，各种都相对更正规一些。安装部署文档也都比较齐全。dify 是开源做工作流的，其中也有RAG的部分。但是做的很粗糙。如果想做自己的本地知识库开发，可以在Qanything上做。我看过QAnything 和 RAGflow dify的源码，也对比了他们的效果，最终评估使用Qanything 打底。做一个全新的RAG搜索。

我的环境是mac m2 32G ，没办法用GPU。这是X inference的安装教程。这里是mac部署2B的教程。还有测试推理的效果，速度

开源RAG和workflow技术中，大家各有特色，个有千秋。这里是我的深度调研的感受总结。

我自己就是做RAG工作的，但是还是想关注一下开源的技术做到了什么程度。所以调研了很长时间，也体验了一下。这里写一篇文章来分享一下结果。我用五一的假期时间，来做调研，看代码，做测试，写文章。为大家贡献资料。这里先说一下自己的感受吧：这些开源的技术，还是各有所长的。应该结合融合到一起，才能更好的完成我们的生产需求。但是开源的文档解析最多能做到60%的效果。

23款 mac pro M232G内存注意，花内存比较多一些。参数规模越大，需要的内存越多。我部署了一个7B的qwen就花了16G的内存空间我使用Xinference来部署模型。这里是Xinference的安装文档。

想要在Mac M2 上部署一个本地的模型。看到了这个工具Xorbits Inference（Xinference）是一个性能强大且功能全面的分布式推理框架。可用于大语言模型（LLM），语音识别模型，多模态模型等各种模型的推理。通过 Xorbits Inference，你可以轻松地一键部署你自己的模型或内置的前沿开源模型。无论你是研究者，开发者，或是数据科学家，都可以通过 Xorbits Inference 与最前沿的 AI 模型，发掘更多可能。本地部署参考了这两个文档部署文档部署文档。

最近看到了一篇关于text2sql的文章，以及一些论文。对使用模型做text2sql给了一些不错的建议。

我也是做RAG相关工作的。周末抽了一些时间，来看看开源的RAG技术能够做到什么程度。其实我重点关注的是以下几点（以下几个点是RAG提升的关键点）：这些开源技术他们是怎么做文档解析的（有哪些我们可以借鉴的，哪些是我不知道的）如何做切分的不同的场景数据又是如何制定不同的策略的还有如何做召回的，召回策略是什么？以及如何选用embedding模型，rerank模型效果怎么样，本地快速部署效果是否方便？

最近在做RAG的雕花工作。想要在PDF解析上，能够有一定的突破。上上周调研了一周的PDF解析的组件。但是还是没有一个开源的解析的很不错的组件。这篇文章，一起来看看是否能从PDF文件的底层数据结构上入手，来进行解析。PDF（Portable Document Format，可移植文档格式）是一种广泛使用的文件格式，用于呈现文档，包括文本、图像和多媒体内容。PDF文件的存储原理和结构设计得非常复杂，以确保跨平台的一致性和高效的文件传输。

在数字化时代，PDF文档已成为信息共享的主要格式之一。然而，要从PDF中提取有价值的知识并不容易，因为PDF设计为一种用于阅读和打印的静态格式，而不是为了内容的动态提取和分析。尽管如此，随着技术的进步，我们现在有能力从PDF文档中提取比以往任何时候都更多的内容和知识。以下是一篇关于从PDF文档中提取知识的全面指南，包括可以挖掘的数据类型和一些实用的方法。

对于我要做RAG应用，我应该使用两者中的哪一个。或者说还是都使用？在人工智能领域，检索增强生成（RAG）应用正变得越来越受欢迎，因为它们能够结合大型语言模型（LLMs）的自然语言处理能力和私有或专有数据源的丰富信息。在构建RAG应用时，开发者面临的一个重要选择是选择合适的工具或框架。本文将探讨两个流行的工具：LangChain和LlamaIndex，并提供决策指南。

PDF解析是极其复杂的问题。不可能靠一个工具解决全部问题，尤其是五花八门，格式不统一的PDF文件。除非有钞能力。如果没有那就看看可以分为哪些问题。 提取文本内容，提取表格内容，提取图片。我认为这些应该是分开做的事情。python有一些组件，是有专长的。 问题分解以后，最重要的一个事情是，版面分析。怎么确定边界，就是哪一块是什么内容？是正文，还是表格，还是图片？文本、图片及形状涵盖了常见的PDF元素，本文介绍利用PyMuPDF提取这些页面元素，及其基本数据结构。

说点真实的感受：网上看啥组件都好，实际测，啥组件都不行。效果好的不开源收费，开源的效果不好。测试下来，发现把组件融合起来，还是能不花钱解决问题的，都是麻烦折腾一些。 这里分享了目前网上能够看到的资料。很多资料都是反复重复的，且效果不好的。目前网上基本没有太好用的工具，也没有太好的方案资料。剩下的就是收费效果好的。

挑选了可以解析PDF中表格的组件，进行了测试。主要测试了pdfplumber 和camelot整体的感受是：网上看啥组件都好，实际测，啥组件都不行。效果好的不开源收费，开源的效果不好。测试下来，发现把组件融合起来，还是能不花钱解决问题的，都是麻烦折腾一些。

一、Paddle-structure是目前我们能找到的可以做中英文版面分析较好的一个基础模型，其开源版可以识别十类页面元素。这篇文章介绍演示如何使用。pdf的解析大体上有两条路，一条是基于规则，一条是基于AI。所谓基于规则就是根据文档的组织特点去“算”每部分的样式和内容。笔者认为这种方式很不通用，因为pdf的类型、排版实在太多了，没办法穷举。一、Paddle-structure。

想要在PDF文件中，解析获取全部的标题，是一件比较麻烦的事情。正是因为PDF文件中的内容可能是五花八门的格式。但是获取标题信息，又是一件非常重要的事情。标题中往往蕴含着非常多的概括性信息。本文将介绍一种较为准确的提取标题的方式。使用python组件+LLM。本文会给出调试后的可运行代码，以及prompt，还有运行结果。

query改写其实理解起来很简单，就是把原始的query经历一系列的操作，然后变成另外一个query，从而达到提升召回率和准确率的效果。query改写的过程中，这一系列的操作，其实是围绕两个方面展开的。第一是在原始query中添加一些有用的内容（可以理解为query扩展），把本该召回却没有召回的内容给召回，提高topK的召回率。第二是在原始query中去掉一些杂质内容（可以理解为蒸馏），对于长尾的query，很可能存在很多的干扰项。特别是在Bm25相关性召回下，对query条件进行蒸馏，会有一定的收益。

通常用户的query是无法预测的。给定一个候选集，直接命中和query最相关的文档是一件困难的事情。这篇论文中，提出了HyDE，也就是根据query，利用LLM去生成假设性回答。然后将给出的假设性回答，去做文本的embedding，然后做向量检索召回。论文中证明，HyDE这种方式相比较BM25可以。

本文介绍了一篇典型的 PRF （Pseudo-relevance feedback）思路的论文，用于利用LLM来做query改写，提升召回率，召回效果。为大家介绍PRF的主要流程，PRF的提升效果。PRF的弊端。 以及不同规模的LLM对改写的效果的影响。

（伪相关反馈）为了解决模型的幻觉问题，在改写前，先拿原始query去进行一次query，然后将召回的数据作为参考内容，送给模型，根据这些内容重新生成query。优势：可以一定程度上解决模型幻觉问题，有效解决解决词汇表不匹配问题。毕竟是根据query召回的内容去生成query的。劣势：这将会很依赖首次的检索，如果召回的数据质量很差，就GG了。(生成相关反馈)最近关于生成相关性反馈（GRF）的研究表明，使用从大型语言模型生成的文本的查询扩展模型可以改进稀疏检索，而不依赖于第一次检索的有效性。

不同检索方式说明最近在做搜索召回提升相关的研究工作。对比了稀疏检索和稠密向量检索的效果。其中使用的搜索引擎为elasticsearch8.x版本。稀疏检索包括BM25的检索方式，以及es官方在8.8之后版本提供的稀疏向量模型的方式。稠密向量检索，是指借助机器学习的模型做文本嵌入，然后用es8.x以后版本提供的向量检索。测试数据说明测试数据包括了中文和英文，涉及了法律和新闻数据。