构建AI智能体：RAG的高效召回方法论：提升RAG系统召回率的三大策略实践

高效召回的目标是在毫秒级的时间内，从可能包含数百万条文档的知识库中，找到真正能回答用户问题的那些黄金片段。 三、为什么要做高效召回 此时相比应该都基本理解了高效召回的本质原因了，RAG系统的性能严重依赖于召回阶段的质量，核心问题是如果检索到的文档片段不包含回答问题所需的信息，那么再强大的大模型也无法生成高质量的答案 四、典型的高效召回方法下面我们详细解析三种方法的概念、差异和实现逻辑。方法一：Small-to-Big（由小到大检索）1. 这比发送多个重叠的大块或多个不完整的小块更高效，减少了Token消耗和计算开销。灵活性：可以根据文档类型和需求灵活定义“小”和“大”的尺寸，以及它们的重叠策略。4. 这样一来，大模型就能更快、更准、更轻松地利用这些内容生成高质量的答案了，这就是高效召回的价值所在。

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 2.0 的索引与召回机制优化

很多做RAG的朋友可能都有过这样的经历：兴冲冲地把系统搭起来满怀信心地让它回答几个问题，结果它要么答非所问，要么一脸无辜地说"抱歉我不知道"。 今天我们就来聊聊RAG 2.0在索引与召回机制上的优化思路，看看怎么才能让RAG真正派上用场。 向量召回的困境与破局之道 向量召回命中率低这个问题，说起来简单，真正解决起来却让人头疼。 结语 RAG 2.0的索引与召回机制优化，本质上是在效果和效率之间找平衡。 多路召回解决了单一检索方式的局限，张量排序在保持效果的同时提升了效率，文档预处理则为整个系统打下了高质量的数据基础。 对于正在搭建RAG系统的朋友，我的建议是：先确保数据质量，该做的脏活累活不要偷懒；然后根据业务场景选择合适的召回组合，不要盲目追求路数多；最后在排序环节下功夫，重排序的投入产出比通常很高。 RAG技术还在快速演进，但无论怎么变，扎实的基础功永远是关键，是吧？

FaaF:为RAG系统量身定制的事实召回评估框架

在RAG系统中实际的事实召回评估可能存在以下问题: 在低质量生成的文本中自动验证真实的、独立的陈述和模拟低质量的检索增强生成(RAG)场景并没有得到太多的关注。 Facts As A Function faaf是一个为RAG系统量身定制的事实召回评估框架，它可以用来创建一个测试数据集，并执行自动的事实召回评估。 评估数据是通过真实事实和人工注释来增强的。 WikiEval的特点是问题和答案对，答案具有可变的事实质量，可以模拟有缺陷的RAG反应。 然后测试RAG的假设反应(在这种情况下，无根据的答案和糟糕的答案)对提取的事实的召回。 依靠提示来验证事实往往会高估陈述的真实性，尤其是在文本缺乏重要信息的情况下。 最后使用FaaF大大减少了验证所需的LM调用和令牌的数量，使流程在成本和时间方面更加高效。 论文地址： https://arxiv.org/abs/2403.03888

RAG 应用中的数据召回率及其应用的探讨

深入理解 RAG 应用中的数据召回率及其应用数据召回率是 RAG（Retrieval-Augmented Generation）应用中一个至关重要的性能指标，它衡量模型在检索阶段中成功找到相关数据的能力 召回率在 RAG 应用中的意义在 RAG 应用中，召回率的重要性主要体现在以下几个方面：信息完整性：高召回率有助于确保检索模块不会遗漏与问题高度相关的信息，从而为生成模块提供充分的上下文。 from sklearn.metrics import recall_score# 假设知识库中的文档 IDknowledge_base = ["doc1", "doc2", "doc3", "doc4" 优化索引结构：采用更高效的索引结构（如 FAISS）可以加快检索速度，同时确保相关文档不会因索引误差而被遗漏。领域自适应训练：通过在目标领域的语料上微调检索模型，可以显著提高召回率。 高效生成过滤：结合生成模块的质量评估反馈，优化检索模块的返回结果。

langchain中的召回增强生成（RAG）一览

将适当的信息带入并插入到模型提示中的过程被称为“检索增强生成”（RAG）。 这个指南包含什么内容？[4] LangChain具有一些专门设计来帮助构建RAG应用程序的组件。 步骤4.生成 让我们将所有内容汇总到一个链条中，该链条接受一个问题，检索相关文档，构建提示，将其传递给一个模型，并解析输出。 4.人类输入：在某些情况下，可以使用人类输入来协助进行任务分解。人类可以提供他们的专业知识和知识来识别和分解复杂的任务成较小的子任务。 : https://python.langchain.com/docs/use_cases/question_answering/#what-is-rag [4] 直接链接到这个指南的内容: https -84b4-c7befcbc59fe/r) [28] BeautifulSoup文档: https://beautiful-soup-4.readthedocs.io/en/latest/#beautifulsoup

Milvus 集成 DSPy：搭建高效 RAG Pipeline

大语言模型（LLM）为行业带来变革，具备强大的生成能力，在与知识库和检索器等工具相结合时，能够高效推动聊天机器人和 Agent 等高级生成式 AI（GenAI）应用的发展。 此外，即使是相同的 Prompt ，在不同的 LLM（如 GPT-4 和 Gemini）之间也可能因其预训练方法和数据集的不同而产生差异化的结果。 DSPy 为开发者与语言模型互动方式带来了变革——通过引入一个可编程接口，实现了模型 Prompt 和权重的算法优化，从而帮助相关人员更高效地开发语言模型。 AutoGPT 是一个由 GPT-4 和 GPT3.5 驱动的高级 AI Agent。它根据预定义的规则和目标进行决策和行动，强调自主性和决策能力。 Milvus 已作为检索模块以 MilvusRM Client 的形式集成到 DSPy 工作流程中，从而助力开发人员快速高效地搭建 RAG pipeline。

RAG 长尾召回雪崩：向量空间实体簇坍缩的真实复盘

RAG长尾召回雪崩：向量空间实体簇坍缩的真实复盘上个月生产环境里有一波Query风暴，特征是极度稀疏的长尾意图词+多跳关系约束。 日志里反复出现同一类错误：展开代码语言：TXTAI代码解释[ERROR]EntityAlignmentDriftdetected|query_id=QM-9382741matched_entities:4/ 传统RAG架构的天花板与AISO规范的切入LangChain/LlamaIndex的默认知识图谱构建方式在通用领域还能凑合，但一遇到需要严格路径约束与实体置信度权重的场景就彻底露怯。 similarity_top_k=32)self.graph_store=graph_storeself.ontology_validator=OntologyValidator(schema_version="2025-q4" 总结一句最硬核的话大模型时代，RAG的天花板从来不在embedding维度与算力堆料，而在于你能否把领域本体与关系约束提前编译进检索结构本身。

搜索引擎RAG召回效果评测MTEB介绍与使用入门

RAG 评测数据集建设尚处于初期阶段，缺乏针对特定领域和场景的专业数据集。市面上常见的 MS-Marco 和 BEIR 数据集覆盖范围有限，且在实际使用场景中效果可能与评测表现不符。 Research", "reference": "https://www.microsoft.com/en-us/research/uploads/prod/2019/03/nl4se18LinkSO.pdf 召回评测是通过RetrievalEvaluator类实现的。 评测实践 说了这么多，现在切入正题： 评测自研模型的召回能力 —— 自定义模型 自定义评测集，对比开源模型和自研模型的效果 —— 自定义评测任务 自研模型召回效果评测 我们先评估模型召回效果，训练好的模型导出为 自定义召回评测任务 上面分析源代码时提到了，自定义时需要提供qurey，doc，以及query的相关doc 假设我们的自定义测试为jsonline格式，每行包含query，以及相关的doc，json格式如下

TextIn文档树引擎，助力RAG知识库问答检索召回能力提升

》（+link）中详细说明过识别率、召回率与F1的设计原理。 标题检测中，相关指标通过相似规则构建：标题识别率测量的是标题解析是否足够准确，即被识别为标题的项目中有多少是正确的；而标题召回率测量的是段落解析是否足够全面，能不能避免长文档中有没被找到的“漏网之鱼”； F1值是识别率和召回率的调和平均值，它综合考虑了这两个指标，用于评估文档解析的整体性能。 在此基础上，文档树引擎从语义出发，增强了标题识别率与召回率。 分块是将整篇文本分成小段的过程，当我们使用LLM embedding内容时，分块可以帮助优化从向量数据库被召回的内容的准确性，因此文本段的质量也是RAG中比较重要的一环。

langchain4j 之 Advanced RAG

langchain4j 中的 Advanced RAG 涉及到诸多策略，今天和大家聊一聊这里涉及到的一些策略。 二 Query 2.1 Query 包含的内容 在 RAG 流程中，Query 就是用户提出的问题。比如你问"糖醋排骨怎么做？"这就是一个 Query。 4.2.4 其他 其他的还有像 AzureAiSearchContentRetriever 主要负责和 Azure AI 进行交互，Neo4jContentRetriever 则主要负责和 Neo4j with LangChain4j?") with LangChain4j?")

聊聊langchain4j的RAG

序本文主要研究一下langchain4j的RAG概述RAG(Retrieval-Augmented Generation)即检索增强生成，它通过检索来获取相关信息，注入到prompt，然后用增强的prompt 目前langchain4j以向量搜索为主(例如通过Qdrant等向量数据库构建高效检索系统)，后续会扩展支持全文搜索及混合搜索(目前Azure AI Search支持，详细见AzureAiSearchContentRetriever RAG可以分为两步：索引、检索。索引索引阶段可以对文档进行预处理以便在检索阶段实现高效搜索，这一步不同的检索方法有所不同。 RAG Flavors**LangChain4j offers three RAG flavors:* **Easy RAG:** The simplest, quickest way to get LangChain4j 提供了三种RAG（Retrieval-Augmented Generation，检索增强生成）的实现方式：Easy RAG、Naive RAG、Advanced RAG。

你知道RAG？它是如何高效检索向量的？

在历时一个半月的笔试面试后，我又回来分享知识了，后续应该只能一周一更了，要去公司当牛马了，不过好在结果顺利，收获了三个offer，已经打算去鹅厂实习了好了，言归正传，我们今天来介绍一下RAGRAG检索增强生成RAG （Retrieval-Augmented Generation，检索增强生成），其核心模块在于检索与生成，其实其本质还是一个知识库系统，只不过是通过向量聚合手段，提升了检索的高效与正确性：RAG通过将收集的多源数据分割为文本块 推出的一项研究中表明，如果你要与一个陌生人联系，通过平均3.57个人的介绍彼此就能互相沟通，而NSW就是借鉴了这种思想其实庞大数据量对应的文本在数据库中，就是一个个的点，而查询就是通过点之间的路径实现高效查询 的跳表机制(类比迁移)坏处：由于要存储多个分层图数据，因此维护分层图带来的内存开销比较大以上介绍了向量数据库检索的几个方法，在大数据量的时代下，通过向量数据库进行相似度查询会比以前的关系型数据库准确匹配更高效

实时数据如何更高效地整合到召回策略中

实时数据的高效整合到召回策略中，是提升推荐系统性能的关键。 实时召回策略 策略设计：根据实时数据和业务需求设计召回策略，如基于用户实时行为的个性化召回、基于实时趋势的热门召回等。 策略权重：根据实时数据的准确性和重要性，动态调整不同召回策略的权重。 实时数据整合到现有召回策略中 数据融合：将实时数据与现有召回策略所需的数据进行融合，确保数据的完整性和一致性。 策略组合：将实时数据驱动的召回策略与现有的召回策略进行组合，形成多策略的召回机制。 效果评估：通过离线评估和在线A/B测试来验证实时数据整合后的召回策略的效果。 优化与迭代 性能监控：实时监控召回服务的性能，包括响应时间、召回率、准确率等指标。 反馈循环：根据用户反馈和业务需求，不断调整和优化召回策略，提高推荐效果。 技术更新：跟踪最新的数据处理和机器学习技术，及时将新技术应用到召回服务中。

大模型 RAG 长尾实体召回崩盘实录：AISO 规范下的实体对齐重排实践

大模型RAG长尾实体召回崩盘实录：AISO规范下的实体对齐重排实践向量检索在专业领域长尾查询时的灾难性塌陷前阵子线上RAG链路突然出现一批长尾查询的严重召回退化。 传统开源RAG管道里，这一层几乎是空白的。 “实体缺失但向量很贴”的干扰文档我们尝试过各种社区方案：HyDE、Self-RAG、Corrective-RAG、甚至自己写了两版基于LLM的重排prompt，最终效果都不稳定。 一句话总结给同样在RAG深坑里挣扎的同学别再把实体对齐的责任推给prompt工程了，那属于事后补救。真正的解法是在召回管道的最前端插入一套强制的本体校验与置信度过滤。 AISO-Engine提供的这套规范虽然不起眼，但一旦接进去，召回质量的提升是结构性的。建议所有做垂直领域RAG的团队都至少实现一个类似的“实体守门人”中间件，长期收益远超短期开发成本。

LLM Agent 之再谈RAG的召回多样性优化

几个月前我们就聊过RAG的经典方案解密Prompt系列14. LLM Agent之搜索应用设计。 前几天刚看完openAI在DevDay闭门会议上介绍的RAG相关的经验，有些新的感悟，借此机会再梳理下RAG相关的优化方案。 过去几个月RAG的论文也像是把传统搜索的方案，使用LLM轮番做了一遍范式更新。本章我们先围绕召回内容的多样性唠上两句。 论文使用4-shot prompt让LLM先基于query生成一个pseudo-document，然后使用生成的答案来进行相关内容的召回。 当前多数RAG得召回索引还是以单一的Embedding向量模型为主，但单一向量作为召回索引有以下几个常见问题文本的相似有不同类型：有语义相似，有语法结构相似，有实体关键词相似，单一维度无法区分文本的相似有不同粒度

聊聊langchain4j的Naive RAG

序本文主要研究一下langchain4j的Naive RAG示例public class Naive_RAG_Example { /** * This example demonstrates 技术，Easy RAG使用了EmbeddingStoreIngestor来隐藏了文档解析、分割、嵌入、嵌入存储，Naive RAG亦可使用。 EmbeddingStoreContentRetrieverdev/langchain4j/rag/content/retriever/EmbeddingStoreContentRetriever.javapublic 小结langchain4j提供了EmbeddingStoreContentRetriever来开启Naive RAG的功能，EmbeddingStoreContentRetriever.builder( docNaive RAG

langchain4j 学习系列(5)-RAG

继续我们的langchain4j之旅，今天来看看RAG如何实现，“RAG萌宠新手盆友们”建议先看看B站大佬的视频RAG 工作机制详解—哔哩哔哩_bilibili，核心步骤就是下面这3张图： 最简单的RAG 自带的“内存”向量存储（可以很容易替换成其它向量数据库存储） 2、召回验证 @GetMapping(value = "/query/memory", produces = MediaType.APPLICATION_JSON_VALUE "done_reason":"stop","total_duration":1059949995,"prompt_eval_count":21,"eval_count":22} 从日志上看，先做了1次RAG 检索(即：召回)，然后将返回的结果进行了排序，将得分最高的"张三是个程序员"，排到了第1位（即：重排），然后再把用户问题+重排后的结果，拼在一起发给LLM，最终得出了答案（即：增强生成) 文档示例代码： GitHub - yjmyzz/langchain4j-study at day05

聊聊langchain4j的Advanced RAG

序本文主要研究一下langchain4j的Advanced RAG核心流程将UserMessage转换为一个原始的QueryQueryTransformer将原始的Query转换为多个Query每个Query *

* Advanced RAG in LangChain4j is described here: https://github.com/langchain4j/langchain4j DefaultQueryTransformerdev/langchain4j/rag/query/transformer/DefaultQueryTransformer.javapublic class ReRankingContentAggregatordev/langchain4j/rag/content/aggregator/ReRankingContentAggregator.javapublic ContentInjectordev/langchain4j/rag/content/injector/ContentInjector.java@Experimentalpublic interface

LLM Agent之再谈RAG的召回信息密度和质量

话接上文的召回多样性优化，多路索引的召回方案可以提供更多的潜在候选内容。但候选越多，如何对这些内容进行筛选和排序就变得更加重要。这一章我们唠唠召回的信息密度和质量。 RAG：基本和经典框架相同，不过价值是大模型使用上文多大程度可以回答问题,价值的定义先由背后的大模型给出，再进一步才能触达用户。 常见的做法是打散，提高连续内容的多样性，以及前后内容的逻辑连贯性，不过打散只是手段，全局价值才是终极目标RAG：概念相似，通过重排优化模型对整体上文的使用效率。 因此单纯使用内容自信息的计算方式更适合短语粒度的上文内容压缩，似乎不完全适合对RAG召回的段落内容进行打分，不过不要着急接着往后看哟~以下是Selective-Context通过自信息对Context进行压缩的效果 在2倍和4倍的压缩率下LongLLMLingua的效果都是显著最好的，不过可以发现只使用LongLLMLingua进行排序（Retrieval-base Methods）并做重排（Reorder列）的效果其实就已经不差了