网站设计公司市场容量百度seo收费

概述

RAG，Retrieval-Augmented Generation，检索增强生成。RAG诞生自2020年Patrick Lewis等人的论文。

通用的基础大模型基本无法满足实际业务需求，主要有以下几方面原因：

• 知识局限：模型自身的知识完全源于它的训练数据，而现有主流大模型的训练集基本都是构建于网络公开的数据，对于一些实时性的、非公开的或离线的数据是无法获取到的，这部分知识也就无从具备；
• 幻觉问题：所有的AI模型的底层原理都是基于数学概率，其模型输出实质上是一系列数值运算，大模型也不例外，所以它有时候会一本正经地胡说八道，尤其是在大模型自身不具备某一方面的知识或不擅长的场景。而这种幻觉问题的区分是比较困难的，因为它要求使用者自身具备相应领域的知识；
• 数据安全：对于企业来说，数据安全至关重要，没有企业愿意承担数据泄露的风险，将自身的私域数据上传第三方平台进行训练。这也导致完全依赖通用大模型自身能力的应用方案不得不在数据安全和效果方面进行取舍。

RAG的核心思想：将传统的信息检索（IR，Information Retrieval）技术与现代的生成式大模型结合起来。

RAG模型在生成答案之前，会首先从一个大型的文档库或知识库中检索到若干条相关的文档片段。再将这些检索到的片段作为额外的上下文信息，输入到生成模型中，从而生成更为准确和信息丰富的文本。

RAG工作步骤：

• 接收请求：首先系统接收到用户的请求；
• 信息检索®：系统从一个大型文档库中检索出与查询最相关的文档片段。这一步的目标是找到那些可能包含答案或相关信息的文档；
• 生成增强(A)：将检索到的文档片段与原始查询一起输入到大模型中，注意使用合适的提示词，比如原始的问题是XXX，检索到的信息是YYY，给大模型的输入应类似于：请基于YYY回答XXX；
• 输出生成(G)：大模型基于输入的查询和检索到的文档片段生成最终的文本答案，并返回给用户。

RAG应用流程主要包含两个阶段：

• 准备数据阶段：数据提取—>文本分割—>向量化（embedding）—>数据入库；
• 投入应用阶段：用户提问—>数据检索（召回）—>注入Prompt—>LLM生成答案。

RAG系统核心组件

• 嵌入模型：将文本转换为向量表示
• 生成模型：负责最终的内容生成
• 重排序模型：优化检索结果的相关性
• 向量数据库：存储和检索向量化的内容
• 提示模板：规范化的查询处理模板
• AI Agent：智能决策和任务协调

应用场景，包括但不限于：

• 问答系统
• 文章摘要
• 翻译
• 聊天机器人
• 电商推荐

未来发展方向

• 更高级的检索技术：通过引入Transformer等最新技术，RAG可以更高效地检索到相关性更高的信息，让生成的内容更精准；
• 多模态RAG的崛起：未来RAG可能会整合图像、音频、视频等多种数据类型，生成更丰富、更具表现力的内容；
• 个性化定制：根据用户的偏好和情境，提供更个性化的信息，提升用户体验，让AI更懂你；
• 自我提问型RAG：系统可以自动分解复杂问题，实现更深层次的学习和理解，让AI变得更聪明；
• 自适应检索：根据查询类型的不同，调整检索策略。比如，事实类问题和创造性任务可以采用不同的检索方式；
• 混合检索：结合关键词匹配和语义搜索等多种检索方法，避免单一检索方式可能遗漏的相关信息。

文本分块

也叫文本分割，chunk，chunking，其目的是提高效率、相关性和上下文保持。分块能减少计算开销，增加检索相关信息的可能性，同时保持信息完整性。但也存在风险，如上下文丢失、冗余和不一致性。选择策略需考虑文档类型（结构化和非结构化）、查询复杂性、资源可用性和期望结果（速度、准确性、上下文）。

主要考虑两个因素：

• embedding模型的Tokens限制情况；
• 语义完整性对整体的检索效果的影响。

常见的文本分块方式：

• 句分割：以句子的粒度进行切分，保留一个句子的完整语义。常见切分符包括：句号、感叹号、问号、换行符等；
• 固定长度分割：根据embedding模型的token长度限制，将文本分割为固定长度（字符数、单词数或Token数），会损失很多语义信息，一般通过在头尾增加一定冗余量（重叠比）来缓解；
• 语义分块：根据有意义的单元对文档进行分段；持续将单元添加到现有块中，直到余弦相似度显著下降；一旦下降明显，就开始新的分块。与固定大小分块不同，能够保持语言的自然流畅性。
  
• 递归分块：基于内在分隔符（如段落或章节）进行分块；如果某个块的大小超过限制，则将其进一步分割为更小的块。
  

13种分块策略的对比，仅供参考

策略名称	描述	优点	缺点	实施建议
固定长度分块	将文本按预定义长度(如基于令牌或字符)分割，适合简单文档或快速处理	简单性、统一性、效率	上下文丢失、相关性问题、潜在信息丢失	选择合适大小，考虑使用重叠窗口以保持上下文
基于句子的分块	按句子边界分割，确保每个块是完整的思想，适合短响应如客户查询	保持上下文、易于实现、更好的可读性	块大小不一致、不适合长句、控制力弱	使用NLP库检测句子，必要时合并短司
段落分块	将文档按段落分割，每个段落通常包含完整想法或主题，适合结构化文档	更丰富的上下文、逻辑分割	大小不一致、可能超出令牌限制	监控块大小，必要时分割大段落以保持上下文
文档分块	将整个文档视为一个块或最小分割，保持完整结构和上下文，适合法律或医学文档	保持完整上下文、还合结构化文本、简单	可扩展性问题、效率低、缺乏细节提取	适用于不希望分割影响流程的场景
滑动窗口分块	通过滑动窗口创建重叠块，确保相邻块共享内容，适合需保持跨部分上下文的文档	上下文连续性、提高检索效果	冗余、计算成本高	优化窗口大小和重叠，使用去重技术处理冗余
语义分块	使用嵌入或机器学习模型按语义意义分割，确保每个块主题连贯	上下文相关性、灵活性、提高检索准确性	复杂性、处理时间长、计算成本高、值调整	利用预训练模型，平衡成本和粒度
递归分块	使用层次分隔符或多个分隔符逐步分割为小块，适合大型结构化文档	层次上下文、可扩展性、意义块、细粒度控制	实现复杂、可能丢失上下文、复杂性高、计算开销大	使用文档结构标识层次，存储块位置元数据
上下文增强分块	为每个块添加周国块的摘要或元数据，保持序列间的上下文，适合长文档	增强上下文、提高连贯性	复杂性、存储开销大	生成简洁摘要，考虑用关键术语或概念作为元数据
模式特定分块	按内容类型(如文本、表格、图像)分别处理，每个类型按其性质分块	定制方法、提高准确性	实现复杂、集成困难	使用OCR处理图像，将表格转为结构化数据，保持索引一致
代理分块	使用AI(如大型语言模型)按内容结构和语义建议块边界，或按代理角色任务组织	任务导向效率、聚焦相关数据、灵活性、智能分割	复杂设置、计算密集、成本高、可能过分专业化、丢失全局上下文	选择性使用，优化LLM提示，明确代理角色和任务规则
子文档分块	总结整个文档或大节并将摘要作为元数据附加到单个块，适合大型文档集	层次检索、上下文深度	额外处理、元数据管理复杂	自动化摘要生成，高效存储摘要
混合分块	结合多种分块策略，动态适应不同查询类型或文档结构，适合多用途系统	灵活性、优化性能	逻辑复杂、维护难度大	制定选择策略的标准，广泛测试以确保可靠性
基于令牌的分块	按预定义令牌数(如单词或子词)分割，确保块在模型令牌限制内	优化语言模型、精确控制块大小、一致性	上下文碎片化，忽略语义结构，灵活性有限	确保块在模型令牌限制内

选择策略时需考虑以下因素：

• 文档类型：结构化（如报告）适合段落分块，非结构化（如聊天记录）适合语义分块；
• 查询复杂性：复杂查询需语义或代理分块，简单查询可用固定长度分块；
• 资源可用性：计算资源有限时，优先固定长度或基于句子的分块；
• 期望结果：速度优先选固定长度，准确性优先选语义分块，上下文优先选滑动窗口。

数据检索

常见的数据检索方法包括：相似检索、全文检索等，根据检索效果，一般可以选择多种检索方式融合，提升召回率。

• 相似检索：即计算查询向量与所有存储向量的相似性得分，返回得分高的记录。包括：余弦相似性、欧氏距离、曼哈顿距离等；
• 全文检索：在数据存入时，通过关键词构建倒排索引；在检索时，通过关键词进行全文检索，找到对应记录。

技术：

• BM25：ES使用的传统检索方法，基于TF-IDF原理对文档进行排序。在关键词匹配方面表现优异，但在语义理解上存在局限；
• DPR：采用双编码器架构，将查询和文档映射至高维向量空间，通过语义相似度进行匹配，在开放域问答中展现出优异性能；
• REALM：创新地将检索过程融入语言模型训练，实现检索器与生成器的协同优化。通过同步更新机制，该方法在知识密集型任务中展现出优势。

多模态

体现：

• 文本：最为成熟，以BERT和T5为代表的Transformer架构为核心，通过注意力机制增强文本理解能力，推动多种实际应用的发展；
• 音频：借助Wav2Vec 2.0等预训练模型进行特征表示，为语音识别等应用提供支持；
• 视频：通过I3D TimeSformer等技术捕捉时空特征，实现视觉与文本信息的融合，提升视频理解和字幕生成等任务的效果；
• 跨模态：整合多种数据形式，如Flamingo模型实现文本、图像和视频的统一处理。检索即生成方法通过利用大规模配对数据集，实现高效的跨模态信息检索与生成。

应用与分类

图片来源。

评估

RAG系统的产出成果，主要涉及以下几点：

• 检索器组件检索的相关文档：context；
• 生成器组件产出的最终答案：answer；
• 最初的用户问题：question。

因此RAG评估应将question、context、answer三者一起评估，这三者也叫RAG三元组。通过检测三元组之间两两元素的相关度，来评估RAG效果：

• Context Relevance：衡量召回的Context能够支持Query的程度，即相关性；
• Groundedness：衡量LLM的Response遵从召回的Context的程度。得分低，幻觉大；
• Answer Relevance：衡量最终的Response回答对Query提问的相关度。

RagAs

RAGAs(RAG Assessment)，用于评估RAG的开源框架，可通过pip安装：pip install ragas

官网：https://www.ragas.io/

Ragas需要以下信息：

• question：用户问题；
• answer：RAG生成的答案(由LLM给出)；
• contexts：根据用户的问题从外部知识源检索的上下文即与问题相关的文档；
• ground_truths：人类提供的基于问题的真实(正确)答案。唯一需要人类提供的信息。

Ragas提供五种评估指标包括：

• faithfulness：忠实度，衡量答案与给定上下文的事实一致性。根据answer和检索到的context计算得出，并将计算结果缩放到(0,1)范围，且越高越好。
  如果答案中提出的所有基本事实(claims)都可以从给定的上下文中推断出来，则生成的答案被认为是忠实的。计算过程，首先从生成的答案中识别一组claims。然后，将这些claims中的每一项与给定的context进行交叉检查，以确定是否可以从给定的context中推断出它。公式：
  
• Answer relevancy：答案相关性，评估答案与问题之间相关程度。不完整或包含冗余信息的答案将获得较低分数。通过计算question和answer获得的，取值在0到1之间，分数越高，相关性越好。
  对答案相关性的评估不考虑真实情况，而是对答案缺乏完整性或包含冗余细节的情况进行惩罚。LLM会被提示多次为生成的答案生成适当的问题，并测量这些生成的问题与原始问题之间的平均余弦相似度。基本思想，如果生成的答案准确地解决最初的问题，LLM应该能够从答案中生成与原始问题相符的问题。
• Context Precision：上下文精度，评估所有在上下文(contexts)中呈现的与基本事实(ground-truth)相关的条目是否排名较高。理想情况下，所有相关文档块(chunks)必须出现在顶层。该指标使用question和计算contexts，值范围在0到1之间，其中分数越高表示精度越高。
  
• Context Recall：上下文召回率，衡量上下文与人类提供的真实答案(ground truth)的一致程度。根据ground truth和检索到的Context计算出来的，取值在0到1之间，值越高表示性能越好。
  为了根据真实答案(ground truth)估算上下文召回率(Context recall)，分析真实答案中的每个句子以确定它是否可以归因于检索到的Context。 在理想情况下，真实答案中的所有句子都应归因于检索到的Context。
  
• Context Relevancy：上下文相关性，根据用户问题和上下文计算得到，并且取值范围在(0,1)之间，值越高表示相关性越好。理想情况下，检索到的Context应只包含解答question的信息。首先通过识别检索到的Context中与回答question相关的句子数量来估计|S|的值。公式：
  
  入门案例：

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (faithfulness,answer_relevancy,context_recall,context_precision,
)questions = ["问题1","问题2"    
]ground_truths = ["事实1","事实2"
]answers = []
contexts = []# Inference
for query in questions:answers.append(chain.invoke({"question": query}))contexts.append([docs.page_content for docs in retriever.get_relevant_documents(query)])# To dict
data = {"user_input": questions,"response": answers,"retrieved_contexts": contexts,"reference": ground_truths
}# Convert dict to dataset
dataset = Dataset.from_dict(data)
result = evaluate(dataset = dataset, metrics=[context_precision,context_recall,faithfulness,answer_relevancy,],embeddings=embeddings
)
df = result.to_pandas()

开发框架

如：LangChain、LlamaIndex。

LangChain，核心功能：

• 模块化设计：支持将模型、提示模板、索引、工具等组件链式组合，构建复杂工作流，如多步骤对话代理或自动化任务；
• 广泛集成：可连接数据库、API、文件系统等数据源，并集成多种LLM，适合需要动态交互的应用场景；
• 记忆管理：支持记录对话历史，实现上下文感知的交互，例如聊天机器人能根据前文回答后续问题。

适用场景：

• 需结合外部工具的多模态应用（如实时数据查询+生成报告）；
• 复杂对话系统（如客服中台）、自动化任务链。

LlamaIndex，核心功能：

• 高效索引与检索：提供向量索引、树状索引、关键词表索引等多种数据结构，优化大规模数据的快速查询，尤其擅长语义相似性搜索；
• 简化RAG流程：从数据加载、分块到索引生成一体化，开发者仅需几行代码即可搭建基于私有数据的问答系统；
• 可扩展性：支持分布式索引，轻松应对TB级数据，适合企业级知识库或实时分析场景。

适用场景：

• 文档问答、知识库搜索（如内部Wiki查询）
• 需快速响应的实时系统（如金融数据分析）。

维度	LangChain	LlamaIndex
核心定位	通用型框架，支持复杂工作流	专注于数据索引与检索
灵活性	高（可自定义链、代理）	中（优化检索性能，功能更垂直）
学习曲线	较陡峭（需掌握组件交互）	较平缓（开箱即用）
数据处理	支持多源异构数据，但检索效率一般	专精高效检索，尤其适合大规模数据
典型用例	聊天机器人、任务自动化	文档搜索引擎、实时推荐系统

总结：

• LangChain需手动组合数据加载、分割、索引和生成模块，适合需要定制化流程的项目；
• LlamaIndex提供一站式索引构建，如VectorStoreIndex.from_documents()即可完成核心步骤。

如何选择？

• 选LangChain：若项目需整合多种工具（如数据库+API）、构建多步骤逻辑（如先检索再生成报表），或需要长期维护复杂对话状态。
• 选LlamaIndex：若核心需求是快速搭建基于私有数据的问答系统，或处理海量数据的高效检索（如企业知识库）。
  混合使用建议：

用LlamaIndex快速实现RAG原型，后期引入LangChain扩展为支持多工具的智能代理。

问题与挑战

RAG存在多个待解决的关键问题：

• 系统性能：
  • 面对海量数据时的扩展性受限
  • 实时处理和资源受限环境下的部署困难
  • 检索效率与计算资源消耗的平衡问题
• 质量控制：
  • 检索内容的相关性和时效性难以保证
  • 长文本生成时的检索精确度有待提升
  • 检索知识与生成内容的连贯性存在缺陷
• 社会影响：
  • 数据集固有偏见可能被系统放大
  • 模型决策过程缺乏透明度和可解释性
  • 系统公平性与伦理问题需要关注

从RAG组件角度，其挑战是：检索、生成和整个RAG系统。

• 检索
  • 动态和广泛的知识库：潜在知识库的动态性和广泛性，这要求评估指标能够有效地衡量检索文档的精确度、召回率和相关性；
  • 时间敏感性：信息的相关性和准确性会随时间变化，增加评估过程的复杂性；
  • 信息源的多样性：需要考虑信息源的多样性，和检索到误导性或低质量信息的可能性。
• 生成
  • 忠实度和准确性：生成组件的评估重点在于生成内容对输入数据的忠实度和准确性，这不仅涉及事实正确性，还包括对原始查询的相关性和生成文本的连贯性。
  • 主观性：某些任务（如创意内容生成或开放式问题回答）的主观性增加评估的复杂性，因为它们引入关于“正确”或“高质量”响应的变异性。
• RAG系统
  • 检索与生成的相互作用：整个RAG系统的评估引入额外的复杂性，因为检索和生成组件之间的相互作用意味着不能仅通过独立评估每个组件来完全理解整个系统的性能。
  • 实际考虑：评估系统的整体有效性和可用性时，还需要考虑响应延迟、对错误信息的鲁棒性以及处理模糊或复杂查询的能力。

进阶

向量数据库

缓存

缓存能显著降低延迟和模型调用成本，RAG中最常见的缓存技术：提示缓存（Prompt Cache)、精确缓存（Exact Cache）、语义缓存（Semantic Cache）。

Prompt Cache

对系统提示的缓存，最常见的是System Prompt。若没有提示缓存，模型需要在每次查询时都处理系统提示；而设置提示缓存，则只需要在第一次查询时处理一次系统提示。在提示缓存中系统提示部分的缓存内容，实际上是经过Decoder处理后的隐藏状态（hidden states），类似于KV Cache原理。

提示缓存对涉及长文档的查询也很有用。比如你应用程序的很多用户查询都与同一个长文档（如一本小说和一个代码库）相关，这个长文档可以被缓存以供多个查询重用。但与系统提示的缓存不同，对长文档的缓存，缓存的是文档内容本身（上下文），而不是向量化后的结果。

Exact Cache

相比于Prompt Cache，精确缓存则更加通用和直接。系统会存储已处理的内容，以便在请求相同内容时重复使用，精确缓存使用基于规则的标准化匹配。

精确缓存也用于基于嵌入的检索，以避免重复的向量搜索。如果传入的查询已经在向量搜索缓存中，就获取缓存的搜索结果；如果不在，就执行该查询的向量搜索并缓存结果。对于需要多个步骤（例如思维链）和/或耗时操作（例如检索、SQL 执行或网络搜索）的查询来说，缓存特别有用。

精确缓存可使用内存来实现，以实现快速检索。但内存有限，缓存也可使用Redis或分层存储等数据库来实现，以平衡速度和容量。

使用分类器预测是否缓存，输入特征可能包括：

• 查询的通用性程度
• 历史查询频率
• 数据更新频率
• 用户相关性
• 时效性要求

输出：是否应该缓存该查询。

Semantic Cache

与精确缓存不同，语义缓存不要求传入的查询与任何已缓存的查询完全相同。语义缓存允许重用相似的查询，是基于向量相似度的模糊搜索。

语义缓存只有在已有可靠方法，能确定两个查询在语义上是否相似时才能工作。一种常见的方法是基于嵌入的相似度：

• 对每个查询，使用Embedding模型生成嵌入向量；
• 使用向量搜索找到与当前查询嵌入最接近的缓存嵌入，假设这个相似度分数是X；
• 若X超过已设置的相似度阈值，则认为缓存的查询与当前查询相同，返回缓存的结果。若没有，则处理当前查询，并将其与其嵌入和结果一起缓存。

此方法需要一个向量数据库来存储缓存查询的嵌入。

潜在问题：

• 语义缓存的成功依赖高质量的嵌入、向量搜索的有效性和可靠性，以及可信的相似度度量；
• 设置合理的相似度阈值比较难，依赖大量的试错。如果系统错误地将传入查询判断为与另一个查询相似，从缓存中获取的响应将是不正确的；
• 此外，由于涉及向量搜索，语义缓存耗时且计算密集。这种向量搜索的速度与成本取决于缓存嵌入数据库的大小。

如果缓存命中率很高，即大部分查询都能通过利用缓存结果有效回答，可以考虑使用语义缓存。但一定要注意在引入语义缓存前，评估与之相关的效率、成本与性能风险。

拓展

RAG发展迅速，各种新方法不断被提出：

算法	特点	优点	缺点
Simple RAG	基于用户查询检索相关文档，并使用LLM生成响应的基本方法	- 适用于广泛的任务和数据 - 计算成本低，处理速度快 - 所需数据量少 - 实现相对容易	不适用于复杂查询或高级推理
Active RAG	根据用户反馈迭代改进查询，以提高相关性的方法	通过用户反馈提高输出的质量、准确性和可靠性	- 需要收集和处理用户反馈 - 计算成本高于Simple RAG
Corrective RAG	对生成的输出进行修正或交叉检查，以确保事实准确性的方法	- 保证事实的准确性 - 获得可靠的输出	- 计算成本高于Simple RAG - 修正处理的实现复杂
Self RAG	通过自我反省或自我批评来提高RAG结果质量的方法。LLM会对每个回答进行批评，判断其是否与查询相关。如果无关，则使用外部资源；如果相关，则检查幻觉和准确性	- 通过自我反思提高输出质量 - 抑制幻觉的产生	- 计算成本高于Simple RAG和Corrective RAG - 实现复杂
Speculative RAG	针对特定查询生成多个响应，并利用检索模型提供相关信息的方法。这些响应通过评分系统进行评估，选择最准确且上下文合适的响应	能够处理模糊查询或具有多种解释的查询	- 计算成本高于Self RAG - 实现复杂
Multimodal RAG	结合文本、图像、视频等多种数据类型，生成更丰富响应的方法	结合多种数据类型，生成基于更全面理解的输出	- 需要处理多种数据类型的前处理 - 计算成本高
Advanced RAG	使用高密度检索或Transformer等先进检索技术，实现高性能检索的方法	通过高级搜索技术提高输出质量	- 计算成本高 - 高级搜索技术的实现复杂
Knowledge-intensive RAG	专注于专业或领域特定信息的方法	提高特定领域输出的质量和准确性	- 需要构建专业知识库 - 适用范围有限
Memory RAG	通过记忆过去的交互，提高未来响应的质量、连续性和个性化的方法	记忆过去的交互，生成个性化的输出	- 需要内存管理机制 - 需要考虑隐私问题
Meta-learning RAG	通过少样本学习或零样本学习功能，快速适应新任务的方法	快速适应新任务和数据	- 学习数据的选择至关重要 - 计算成本高
HtmlRAG	直接使用HTML，保留标题、表格等有价值的信息结构，而不是使用纯文本。通过清理和修剪技术处理HTML中的额外噪音和大小	保留标题和表格等信息结构	需要处理HTML中的噪声
FastRAG	使用模式和脚本学习高效处理数据，不完全依赖AI模型的方法。结合文本检索和知识图谱查询，提高精度，减少90%的处理时间和85%的成本	大幅减少处理时间和成本	模式和脚本学习的适用范围有限
Auto-RAG	使用LLM细化查询，通过多轮对话规划检索，直到收集到足够信息的自主方法。该系统会根据问题难度自适应调整，并用自然语言解释其过程	对问题难度的适应性高	- 需要多轮对话处理 - 实现复杂
CORAG	考虑块间相关性，使用蒙特卡洛树搜索(MCTS)框架处理添加块的单调效用问题。还使用设置代理适应各种查询类型	考虑块之间的相关性	蒙特卡洛树搜索的实现复杂
MemoRAG	采用具有长期记忆的双系统方法。轻量级LLM创建数据库的全局记忆并生成回答草稿以指导检索工具，而更强大的LLM使用检索到的数据生成最终回答	通过轻量级强大LLM的组合实现高效处理	需要构建双系统
RAG-Thief	旨在揭示RAG系统中私有知识库与LLM集成的隐私风险。通过从对抗性查询开始，从响应中学习并生成更有效的查询，自动提取私有数据（成功率超过70%）	有效分析隐私风险	实现需要专业知识
AssistRAG	在LLM中嵌入智能助手以管理工具、记忆和计划的方法。通过两阶段训练过程（课程助手学习和增强偏好优化）增强信息检索和决策能力	能够管理工具、内存和计划	实现复杂
LaB-RAG	结合图像标签、RAG和LLM生成图像描述的方法。使用简单分类器将X射线图像转换为文本标签，这些标签帮助预训练LLM生成详细的放射报告，而无需直接使用图像数据	- 专注于图像字幕生成 - 轻量且具有高性价比	依赖于图像分类器的精度
Video-RAG	无需大量微调即可增强模型对长视频的理解，是一种轻量且经济高效的解决方案。采用即插即用方式，使用开源工具从视频中提取对齐信息，并将此数据作为辅助文本与LVLM集成	- 深入理解长视频内容 - 轻量且具有高性价比	需要视频数据的前处理
Retrieval-Augmented Forecasting (RAF)	增强Chronos等时间序列基础模型(TSFM)，通过动态检索相关时间序列示例来改进预测的方法。应对时间序列数据的事件驱动和进化特性	提高时间序列数据的预测精度	专注于时间序列数据
RuAG	使用LLM的常识定义谓词，并通过蒙特卡洛树搜索高效探索数据，将大规模数据集转换为可解释的逻辑规则。这些逻辑规则随后转换为自然语言并集成到LLM提示中，增强推理能力	将数据转换为可解释的逻辑规则	蒙特卡洛树搜索的实现复杂
MMed-RAG	旨在提高医疗视觉语言模型在诊断和报告生成等任务中的事实准确性。通过自适应上下文选择和偏好微调，解决幻觉和错位等问题	专注于医疗领域的图像和语言处理	专注于医疗数据
Path-RAG	通过改进PathVQA-Open任务中的病理图像分析，增强癌症诊断的框架。使用HistoCartography从图像中提取知识，选择关键补丁以整合专家见解，将准确率从38%提高到47%，并改善长文本问答	专注于癌症诊断等病理图像分析	专注于病理图像分析

长上下文

随着Gemini-1.5和GPT-4等支持长上下文的模型出现，RAG也相应演进：

• Self-Route：实现RAG与长上下文处理的动态调度
• SFR-RAG：提供轻量高效的外部信息整合方案
• LA-RAG：专注于提升语音识别能力
• HyPA-RAG：通过参数自适应优化法律文本处理
• MemoRAG：创新地采用双系统架构处理非结构化知识
• NLLB-E5：突破多语言检索的限制

其他：

• Graph RAG：利用图数据库增强知识连接，可更好地理解文档间的关系；
• Hybrid RAG：结合多种技术优势，包含图结构和传统检索方法；
• Agentic RAG Router：使用AI Agent来路由和处理查询，可选择最适合的处理路径；
• Agentic RAG Multi-Agent：使用多个专门AI Agent协同工作，可调用不同工具，如向量搜索、网页搜索、Slack、Gmail等；

数据集

基准测试，benchmark，包括数据集和工具。

数据集：

• NQ：Natural Questions，从Wikipedia里挑选，既有长篇大论，也有简短精悍。主要考验模型在问答任务中的表现，尤其是它能不能从一堆文档中找到相关信息，然后生成准确、靠谱的答案。
• MS MARCO：Microsoft Machine Reading Comprehension，Bing搜索引擎的真实记录，里面包含真实的搜索查询和对应的文档、答案。主要用来测试RAG在文档检索和段落排序上的能力，看看它能不能找到最相关的信息，并生成高质量、连贯的回答。简单来说，就是看模型能不能像搜索引擎一样聪明。
• TriviaQA：包含各种问题和对应的正确答案。主要用来测试RAG在获取事实信息方面的能力，能不能从海量文档中找到相关的知识点，并生成准确的回答。尤其是那些冷知识或常识性问题，特别适合用来考验模型。
• FEVER：Fact Extraction and Verification，提供一些主张，要求模型去找到相关的证据来验证这些主张的真实性。它主要用来测试RAG在事实检索和验证方面的能力，看看它能不能找到靠谱的证据，并生成有根有据的回答。

工作类型

四类：

• Query-based RAG：基于查询的RAG，也称为提示增强。它将用户的查询与从文件中检索到的信息直接整合到语言模型输入的初始阶段。这种模式是RAG应用中广泛采用的方法。一旦检索到文档，它们的内容就会与用户的原始查询合并，创建一个组合输入序列。这个增强序列随后被输入到预先训练好的语言模型中，以生成回复。
• Latent Representation-based RAG：在基于隐式表示的RAG框架中，检索到的对象作为隐式表示融入生成模型，从而提高模型的理解能力和生成内容的质量。生成模型与检索对象的潜在表征相互作用，提高生成内容的准确性。这种方法在处理代码、结构化知识和多模态数据方面显示出巨大的潜力和适应性。特别是在代码相关的领域，如EDITSUM、BASHEXPLAINER和RetrieveNEdit等技术，采用FiD方法，通过编码器处理的融合来促进整合。Re2Com和RACE等方法也采用为不同类型输入设计多个编码器的设计。
• Logit-based RAG：在基于对数似然的RAG中，生成模型在解码过程中通过对数融合检索信息。通常，对数通过模型求和或组合，以产生逐步生成的概率。在代码到文本转换任务中，Rencos并行生成检索代码的多个摘要候选，然后使用编辑距离进行规范化，计算最终概率以选择最匹配原始代码的摘要输出。在代码摘要任务中，EDITSUM通过在概率级别整合原型摘要来提高摘要生成质量。对于文本到代码任务，kNN-TRANX模型结合信心网络和元知识来合并检索到的代码片段。它利用seq2tree结构生成与输入查询紧密匹配的目标代码，提高代码生成的准确性和相关性。这种方法特别适合序列生成任务。侧重于生成器训练，并且可以设计出新颖的方法，有效地利用获取的概率分布，以适应后续任务。
• Speculative RAG：推测式RAG，旨在通过利用检索而非纯生成来节省资源并加快响应速度。REST技术通过用检索替代推测解码中的小型模型，实现草稿生成。GPTCache通过构建语义缓存来存储LLM的响应，解决使用LLM API时的高延迟问题。推测式RAG目前主要适用于序列数据。它解耦生成器和检索器，使得预训练模型可以直接作为组件使用。在这个范式下，可探索更广泛的策略，有效利用检索到的内容。

优化方案

参考

• https://www.gptsecurity.info/2024/05/26/RAG/
• https://luxiangdong.com/2023/09/25/ragone/
• https://zhuanlan.zhihu.com/p/668082024
• 企业级RAG组件：缓存