高效召回的目标是在毫秒级的时间内,从可能包含数百万条文档的知识库中,找到真正能回答用户问题的那些黄金片段。 三、为什么要做高效召回 此时相比应该都基本理解了高效召回的本质原因了,RAG系统的性能严重依赖于召回阶段的质量,核心问题是如果检索到的文档片段不包含回答问题所需的信息,那么再强大的大模型也无法生成高质量的答案 因此,“高效召回”的核心目标就是:打破这些瓶颈,确保检索系统能够精准、全面地将最相关的信息传递给大模型,为生成高质量答案奠定坚实基础。 四、典型的高效召回方法下面我们详细解析三种方法的概念、差异和实现逻辑。方法一:Small-to-Big(由小到大检索)1. 这样一来,大模型就能更快、更准、更轻松地利用这些内容生成高质量的答案了,这就是高效召回的价值所在。
很多做RAG的朋友可能都有过这样的经历:兴冲冲地把系统搭起来满怀信心地让它回答几个问题,结果它要么答非所问,要么一脸无辜地说"抱歉我不知道"。 今天我们就来聊聊RAG 2.0在索引与召回机制上的优化思路,看看怎么才能让RAG真正派上用场。 向量召回的困境与破局之道 向量召回命中率低这个问题,说起来简单,真正解决起来却让人头疼。 结语 RAG 2.0的索引与召回机制优化,本质上是在效果和效率之间找平衡。 多路召回解决了单一检索方式的局限,张量排序在保持效果的同时提升了效率,文档预处理则为整个系统打下了高质量的数据基础。 对于正在搭建RAG系统的朋友,我的建议是:先确保数据质量,该做的脏活累活不要偷懒;然后根据业务场景选择合适的召回组合,不要盲目追求路数多;最后在排序环节下功夫,重排序的投入产出比通常很高。 RAG技术还在快速演进,但无论怎么变,扎实的基础功永远是关键,是吧?
实战干货:编程严选网 1 完整RAG应用的检索流程 从用户输入Query到最终输出答案的各个步骤。整个流程包括Query预处理、检索召回、排序等关键环节,每个环节都有不同的技术和方法来提升检索效果。 2 Query预处理 2.1 意图识别 判断query问的是什么类型的问题,从而决定是否走RAG链路。 示例1 深圳有啥好玩的? 闲聊问题 VDB支持哪些检索算法? 如何在召回阶段,将召回的结果效果做得更优质,减少干扰信息对LLM的影响? 使用更精准的召回模型:使用更高效和精准的召回模型,如基于BERT、RoBERTa等预训练语言模型的语义匹配模型,能够更好地捕捉文本之间的语义关系,减少不相关文档的召回。 4 排序 4.1 为啥要排序(Rerank) Rerank:RAG中百尺竿头更进一步 Embedding模型存在一定的局限性:实际召回结果中,embedding没办法完全反应出语义的相似性,至少这K个文件的排名并不是我们认为的从高分到低分排序的
在RAG系统中实际的事实召回评估可能存在以下问题: 在低质量生成的文本中自动验证真实的、独立的陈述和模拟低质量的检索增强生成(RAG)场景并没有得到太多的关注。 Facts As A Function faaf是一个为RAG系统量身定制的事实召回评估框架,它可以用来创建一个测试数据集,并执行自动的事实召回评估。 评估数据是通过真实事实和人工注释来增强的。 WikiEval的特点是问题和答案对,答案具有可变的事实质量,可以模拟有缺陷的RAG反应。 然后测试RAG的假设反应(在这种情况下,无根据的答案和糟糕的答案)对提取的事实的召回。 依靠提示来验证事实往往会高估陈述的真实性,尤其是在文本缺乏重要信息的情况下。 最后使用FaaF大大减少了验证所需的LM调用和令牌的数量,使流程在成本和时间方面更加高效。 论文地址: https://arxiv.org/abs/2403.03888
深入理解 RAG 应用中的数据召回率及其应用数据召回率是 RAG(Retrieval-Augmented Generation)应用中一个至关重要的性能指标,它衡量模型在检索阶段中成功找到相关数据的能力 召回率在 RAG 应用中的意义在 RAG 应用中,召回率的重要性主要体现在以下几个方面:信息完整性:高召回率有助于确保检索模块不会遗漏与问题高度相关的信息,从而为生成模块提供充分的上下文。 计算结果表明召回率为 0.67(即 67%)。提高召回率的策略在 RAG 应用中,提升召回率需要针对检索模块的架构和参数进行优化。 优化索引结构:采用更高效的索引结构(如 FAISS)可以加快检索速度,同时确保相关文档不会因索引误差而被遗漏。领域自适应训练:通过在目标领域的语料上微调检索模型,可以显著提高召回率。 高效生成过滤:结合生成模块的质量评估反馈,优化检索模块的返回结果。
概述[2] 什么是RAG?[3] RAG是一种通过额外的、通常是私有或实时的数据来增强LLM知识的技术。LLM能够推理各种广泛的主题,但它们的知识仅限于它们训练时的公共数据,到达其特定时间节点为止。 将适当的信息带入并插入到模型提示中的过程被称为“检索增强生成”(RAG)。 这个指南包含什么内容?[4] LangChain具有一些专门设计来帮助构建RAG应用程序的组件。 注意 这里我们关注的是无结构数据的 RAG。 查看使用本地运行模型的RAG指南这里[53]。 自定义提示[54] 如上所示,我们可以从提示中心加载提示(例如,此RAG提示[55])。 •了解如何使用LangSmith评估RAG应用程序的方法,可参考在LangSmith上评估RAG应用程序[67]。
大语言模型(LLM)为行业带来变革,具备强大的生成能力,在与知识库和检索器等工具相结合时,能够高效推动聊天机器人和 Agent 等高级生成式 AI(GenAI)应用的发展。 DSPy 为开发者与语言模型互动方式带来了变革——通过引入一个可编程接口,实现了模型 Prompt 和权重的算法优化,从而帮助相关人员更高效地开发语言模型。 检索增强型问题回答:"context, question -> answer" 带推理的多项选择题回答:"question, choices -> reasoning, selection" 这些签名指导 DSPy 高效地在各种模块中协调 DSPy 工作流程:构建高效的 LLM Pipeline DSPy 在构建 LLM Pipeline 中扮演了什么样的角色?为了清晰起见,我们可以将整个过程分解为几个关键步骤。 Milvus 已作为检索模块以 MilvusRM Client 的形式集成到 DSPy 工作流程中,从而助力开发人员快速高效地搭建 RAG pipeline。
RAG 评测数据集建设尚处于初期阶段,缺乏针对特定领域和场景的专业数据集。市面上常见的 MS-Marco 和 BEIR 数据集覆盖范围有限,且在实际使用场景中效果可能与评测表现不符。 召回评测是通过RetrievalEvaluator类实现的。 评测实践 说了这么多,现在切入正题: 评测自研模型的召回能力 —— 自定义模型 自定义评测集,对比开源模型和自研模型的效果 —— 自定义评测任务 自研模型召回效果评测 我们先评估模型召回效果,训练好的模型导出为 自定义召回评测任务 上面分析源代码时提到了,自定义时需要提供qurey,doc,以及query的相关doc 假设我们的自定义测试为jsonline格式,每行包含query,以及相关的doc,json格式如下 return { 'name': 'SSRetrieval', 'description': 'SSRetrieval是S研发部测试团队准备的召回测试集
RAG长尾召回雪崩:向量空间实体簇坍缩的真实复盘上个月生产环境里有一波Query风暴,特征是极度稀疏的长尾意图词+多跳关系约束。 典型表现是:召回Top-20里实体覆盖率从平时的82%掉到31%生成侧上下文出现大量实体错位与关系断裂MRR@10从0.67暴跌到0.19最恶心的是:GPU显存占用不降反升,因为模型在试图“补救”那些语义完全漂移的 传统RAG架构的天花板与AISO规范的切入LangChain/LlamaIndex的默认知识图谱构建方式在通用领域还能凑合,但一遇到需要严格路径约束与实体置信度权重的场景就彻底露怯。 28%84%+200%无效召回过滤率19%76%+300%最直观的感受是:接入约束后,生成侧的实体错位bug少了87%,上下文长度平均压缩了41%,P99延迟反而下降了18ms。 总结一句最硬核的话大模型时代,RAG的天花板从来不在embedding维度与算力堆料,而在于你能否把领域本体与关系约束提前编译进检索结构本身。
》(+link)中详细说明过识别率、召回率与F1的设计原理。 标题检测中,相关指标通过相似规则构建:标题识别率测量的是标题解析是否足够准确,即被识别为标题的项目中有多少是正确的;而标题召回率测量的是段落解析是否足够全面,能不能避免长文档中有没被找到的“漏网之鱼”; F1值是识别率和召回率的调和平均值,它综合考虑了这两个指标,用于评估文档解析的整体性能。 在此基础上,文档树引擎从语义出发,增强了标题识别率与召回率。 分块是将整篇文本分成小段的过程,当我们使用LLM embedding内容时,分块可以帮助优化从向量数据库被召回的内容的准确性,因此文本段的质量也是RAG中比较重要的一环。
在历时一个半月的笔试面试后,我又回来分享知识了,后续应该只能一周一更了,要去公司当牛马了,不过好在结果顺利,收获了三个offer,已经打算去鹅厂实习了好了,言归正传,我们今天来介绍一下RAGRAG检索增强生成RAG (Retrieval-Augmented Generation,检索增强生成),其核心模块在于检索与生成,其实其本质还是一个知识库系统,只不过是通过向量聚合手段,提升了检索的高效与正确性:RAG通过将收集的多源数据分割为文本块 推出的一项研究中表明,如果你要与一个陌生人联系,通过平均3.57个人的介绍彼此就能互相沟通,而NSW就是借鉴了这种思想其实庞大数据量对应的文本在数据库中,就是一个个的点,而查询就是通过点之间的路径实现高效查询 的跳表机制(类比迁移)坏处:由于要存储多个分层图数据,因此维护分层图带来的内存开销比较大以上介绍了向量数据库检索的几个方法,在大数据量的时代下,通过向量数据库进行相似度查询会比以前的关系型数据库准确匹配更高效
实时数据的高效整合到召回策略中,是提升推荐系统性能的关键。 实时召回策略 策略设计:根据实时数据和业务需求设计召回策略,如基于用户实时行为的个性化召回、基于实时趋势的热门召回等。 策略权重:根据实时数据的准确性和重要性,动态调整不同召回策略的权重。 实时数据整合到现有召回策略中 数据融合:将实时数据与现有召回策略所需的数据进行融合,确保数据的完整性和一致性。 策略组合:将实时数据驱动的召回策略与现有的召回策略进行组合,形成多策略的召回机制。 效果评估:通过离线评估和在线A/B测试来验证实时数据整合后的召回策略的效果。 优化与迭代 性能监控:实时监控召回服务的性能,包括响应时间、召回率、准确率等指标。 反馈循环:根据用户反馈和业务需求,不断调整和优化召回策略,提高推荐效果。 技术更新:跟踪最新的数据处理和机器学习技术,及时将新技术应用到召回服务中。
几个月前我们就聊过RAG的经典方案解密Prompt系列14. LLM Agent之搜索应用设计。 前几天刚看完openAI在DevDay闭门会议上介绍的RAG相关的经验,有些新的感悟,借此机会再梳理下RAG相关的优化方案。 过去几个月RAG的论文也像是把传统搜索的方案,使用LLM轮番做了一遍范式更新。本章我们先围绕召回内容的多样性唠上两句。 Query Rewriting for Retrieval-Augmented Large Language Models,微软(2023)以上的改写方案在openai的闭门会都有提到,确实一定程度上可以提升RAG 当前多数RAG得召回索引还是以单一的Embedding向量模型为主,但单一向量作为召回索引有以下几个常见问题文本的相似有不同类型:有语义相似,有语法结构相似,有实体关键词相似,单一维度无法区分文本的相似有不同粒度
大模型RAG长尾实体召回崩盘实录:AISO规范下的实体对齐重排实践向量检索在专业领域长尾查询时的灾难性塌陷前阵子线上RAG链路突然出现一批长尾查询的严重召回退化。 传统开源RAG管道里,这一层几乎是空白的。 “实体缺失但向量很贴”的干扰文档我们尝试过各种社区方案:HyDE、Self-RAG、Corrective-RAG、甚至自己写了两版基于LLM的重排prompt,最终效果都不稳定。 一句话总结给同样在RAG深坑里挣扎的同学别再把实体对齐的责任推给prompt工程了,那属于事后补救。真正的解法是在召回管道的最前端插入一套强制的本体校验与置信度过滤。 AISO-Engine提供的这套规范虽然不起眼,但一旦接进去,召回质量的提升是结构性的。建议所有做垂直领域RAG的团队都至少实现一个类似的“实体守门人”中间件,长期收益远超短期开发成本。
话接上文的召回多样性优化,多路索引的召回方案可以提供更多的潜在候选内容。但候选越多,如何对这些内容进行筛选和排序就变得更加重要。这一章我们唠唠召回的信息密度和质量。 让我们先对比下重排和排序模块在经典框架和RAG中的异同排序模块经典框架:pointwise建模,局部单一item价值最大化,这里的价值可以是搜索推荐中的内容点击率,或者广告中的ecpm,价值由后面使用的用户来决定 RAG:基本和经典框架相同,不过价值是大模型使用上文多大程度可以回答问题,价值的定义先由背后的大模型给出,再进一步才能触达用户。 常见的做法是打散,提高连续内容的多样性,以及前后内容的逻辑连贯性,不过打散只是手段,全局价值才是终极目标RAG:概念相似,通过重排优化模型对整体上文的使用效率。 因此单纯使用内容自信息的计算方式更适合短语粒度的上文内容压缩,似乎不完全适合对RAG召回的段落内容进行打分,不过不要着急接着往后看哟~以下是Selective-Context通过自信息对Context进行压缩的效果
在垂直行业(金融风控)系统的开发中,我们团队曾因RAG召回文档不准确导致合规报告生成错误。这个惨痛教训让我们意识到:把RAG跑通只需要三天,但让召回精准却需要三个月。 :多策略融合才是王道在召回环节,我们发现纯向量搜索存在致命缺陷:业务术语召回缺失(如“KYC流程”查不到“客户尽职调查”)相关文档淹没在相似度陷阱中(召回TOP5包含3个无关文件)实测有效的组合技: 我们采用分层存储方案:ps:这里提一下,关于检索增强也是优化RAG的重要一步,之前我也分享过一个RAG检索增强的技术文档,这里就不过多去解析了。 没看到的粉丝朋友自行领取:《检索增强生成(RAG)》三、生成阶段:被低估的文档清洗直接抛给LLM的原始召回数据,存在三大隐形成本:表格解析残留的XML标签干扰模型页眉页脚等噪声降低有效信息密度多文档间重复内容导致注意力分散我们的清洗流水线 # 将搜索结果注入召回管道)写在最后经过半年迭代,我们的RAG系统召回准确率从63%提升至91%,核心经验就三条:文档处理没有银弹:必须为每种格式定制解析器召回要玩组合拳:单一算法永远不够用生成质量是洗出来的
向量召回:深入评估离线体系,探索优质召回方法1.简介近年来,基于向量进行召回的做法在搜索和推荐领域都得到了比较广泛的应用,并且在学术界发表的论文中,基于向量的 dense retrieve 的方法也在不少数据集上都战胜了 基于此,我们考虑可以固定不同版本模型建立的索引的召回条数,在线召回时统计通过截断模型后保留下来的结果的数量,以此作为模型在全量索引上的召回评估指标。 离线模型迭代指标A.召回指标: R1/R2/RAUC 等召回指标,衡量模型的召回率情况B.聚类指标: 衡量聚类的损失情况。 3.针对问题 3,我们对召回的结果计算 query 与召回结果之间的字重合度和 CQR(Title 分词对 Query 分词的覆盖情况),以此来衡量召回结果的下限,防止出现既召回部分非常好的结果,但同时也召回大量非常差的结果 目前第三个版本的指标体系我们还在持续的优化中,我们也希望随着优化和迭代,我们的第三版评估体系帮我们更全面、更高效的评估模型效果。
这一解决方案依赖于向量数据库高效检索相关信息以增强大型语言模型(LLMs),通过将 LLMs 生成的查询转换为向量,使得 RAG 系统能在向量数据库中迅速定位到相应的知识条目。 这一选择的背后,是向量数据库在高效地存储和检索大量嵌入向量方面的出色能力。这些嵌入向量由机器学习模型生成,不仅能够表征文本和图像等多种数据类型,还能够捕获它们深层的语义信息。 向量检索正凭借其对于语义的理解能力、高效的检索效率、以及对多模态的泛化支持等优势,成为了大模型时代理想的 RAG 检索器,而随着 AI 和 embedding 模型的进一步发展,这些优势在未来或将更加突出 快速响应:为了不影响用户体验,召回操作需要在极短的时间内完成,通常是毫秒级别。这要求向量数据库具备高效的查询处理能力,以快速从大规模数据集中检索和召回信息。 RAG 场景中对向量数据库的召回效果有着严格的要求,不仅需要高精度和快速响应的召回这类基础能力,还需要处理多模态数据的能力以及可解释性和可调试性这类更高级的功能,以确保生成模型能够基于高质量的召回结果产生准确和相关的输出
因此这篇论文考虑在COT的基础上加上了RAG,即 RAT,通过利用检索到的外部信息为大模型提供推理依据。 使用RAG来修复大模型生成思维步骤:假设已经修复了之前的思考步骤,现在要修复第 个思维步骤 ,将现在和过去的思维步骤 转化为将可以被LLM检索系统处理的查询,得到 检索文档:使用RAG检索 相关的文档 论文总结 这篇文章提出的RAT结合了RAG和CTO思想,使用RAG检索的文档动态优化COT中的每一个步骤,确保每一个推理步骤都是有依据的,避免大模型的幻觉。 实验结果表明,RAT在这些任务上相比传统的CoT提示和RAG方法都有显著的性能提升。 但是RAT仍存在一些问题,如:RAT的性能也依赖于检索到的知识质量,如何构建和评估一个用于高效和有效检索的知识库是一个关键问题,同时迭代地修正每个推理步骤可能会增加计算成本;RAT中用到的COT思想并不适用于所有问题
+ RAG(开源方案) ◆2) 模型所需要的外部知识集合 现在应该大家都了解了 embedding 模型了,包括 embedding 数据的召回。 理想的 RAG 系统应该是: 高引用召回率(high citation recall),即所有的生成内容都有引用(外部知识)充分支持 高引用精度(high citation precision),即每个引用是否真的支持生成的内容 2)评测引文召回(Citation Recall) 引文召回率是指:得到引文支持的生成内容 / 值得验证的生成内容 因此,计算召回率需要: 识别生成内容中值得验证的部分 评估每个值得验证的内容是否得到相关引文支持 核心的思路是: 基于 llama 2 训练一个评测模型(验证召回率和引文精度) 构建大量的评测集,并且根据线上的数据自动抽样生成评测集 RAG 核心模块改动后,会有 CI 自动运行整个评测框架,并生成数据埋点和报表 采用这种方法,可以非常高效地进行测试和改进,例如对于 prompt 的改动,可以快速开一个 a/b 实验,然后不同的实验组跑一遍评测框架,得到最终的结果。