深度解读RAG技术发展历程:从基础Naive RAG 到高级Advanced,再到模块化Modular RAG的全面升级

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
简介: 【8月更文挑战第11天】深度解读RAG技术发展历程:从基础Naive RAG 到高级Advanced,再到模块化Modular RAG的全面升级

深度解读RAG技术发展历程:从基础Naive RAG 到高级Advanced,再到模块化Modular RAG的全面升级

1.RAG简介

为了引出什么是 RAG,先看一下 LLM 当前存在的问题:幻觉、过时的知识、不透明无法追踪的推理过程

RAG(Retrieval-Augmented Generation,检索增强生成),是指对大型语言模型输出进行优化,使其能够在生成响应之前引用训练数据来源之外的权威知识库。大型语言模型(LLM)用海量数据进行训练,使用数十亿个参数为回答问题、翻译语言和完成句子等任务生成原始输出。在 LLM 本就强大的功能基础上,RAG 将其扩展为能访问特定领域或组织的内部知识库,所有这些都无需重新训练模型。这是一种经济高效地改进 LLM 输出的方法,让它在各种情境下都能保持相关性、准确性和实用性。

即:RAG 就是可以开卷回复的 LLM。

举个🌰(网上用烂了,但是简洁明了),给 ChatGPT 抛出了一个关于最近被广泛讨论的新闻的问题。鉴于 ChatGPT 对培训前数据的依赖,它最初缺乏提供最新动态的能力。RAG 通过从外部数据库获取和整合知识来弥合这种信息差距。在这种情况下,它收集与用户查询相关的新闻文章。这些文章,结合最初的问题,形成了一个全面的提示,授权 LLMs 生成一个充分知情的答案。

RAG 主要由三个步骤组成:Indexing、Retrieval、Generation。

  • 索引:文档被分割成块,编码成向量,存储在向量数据库中;
  • 检索:基于语义相似度检索与问题最相关的 k 个块(top-k chunks);
  • 生成:将原始问题和检索到的数据块一起输入 LLM,生成最终答案。RAG 发展经历了三个阶段:Naive RAG、 Advanced RAG 和 Modular RAG,下面对三种 RAG 详细阐述。

1.1 Naive RAG

Naive RAG 遵循传统过程 Indexing-Retrieval-Generation,也被称为 “Retrieve-Read” 框架。

  • 索引(Indexing)

索引首先清理和提取各种格式的原始数据,如 PDF、 HTML、 Word 和 Markdown,然后将其转换为统一的纯文本格式。为了适应语言模型的上下文限制,文本被分割成更小的、可消化的块(chunk)。然后使用嵌入模型将块编码成向量表示,并存储在向量数据库中。这一步对于在随后的检索阶段实现高效的相似性搜索至关重要。知识库分割成 chunks,并将 chunks 向量化至向量库中。

  • 检索(Retrieval)

在收到用户查询(Query)后,RAG 系统采用与索引阶段相同的编码模型将查询转换为向量表示,然后计算索引语料库中查询向量与块向量的相似性得分。该系统优先级和检索最高 k (Top-K)块,显示最大的相似性查询。这些块随后被用作 prompt 中的扩展上下文。Query 向量化,匹配向量空间中相近的 chunks。

  • 生成(Generation)

提出的查询(Query)和选定的文档(Chunks)被合成为一个连贯的提示,大语言模型负责生成回复。该模型的答复方法可能因具体任务的标准而异,允许它或者利用其固有的参数知识,或者限制其对所提供文件中所包含的信息的答复。在正在进行的对话中,任何现有的对话历史都可以整合到提示中,使模型能够有效地进行多轮对话交互。

  • Native RAG 存在的问题:
  1. 检索问题:检索阶段经常存在准确率和召回率冲突的问题,最终导致召回不一致或不相关的 chunks,以及关键信息的缺失。
  2. 生成困难:在产生响应时,模型可能面临幻觉的问题,即它产生的内容不被检索到的上下文所支持。这个阶段也可能受到输出不相关,毒性或偏倚的影响,从而影响响应的质量和可靠性。
  3. 增强障碍:将检索到的信息与不同的任务整合在一起,有时会产生不连贯或不连贯的输出。当从多个来源检索相似的信息时,该过程也可能遇到冗余,导致重复响应。面对复杂的问题,基于原始查询的单一检索可能不足以获得足够的上下文信息。
  4. 过度依赖:生成模型可能过度依赖增强的信息,导致输出只是回应检索到的内容,而不添加有见地或合成的信息。

1.2 Advanced RAG

Advanced RAG 提高检索质量,采用了检索前和检索后策略(pre-retrieval and post-retrieval strategies)。为了解决索引问题,Advanced RAG 通过使用滑动窗口方法、细粒度分段和元数据的合并来改进其索引技术。

  • 预检索过程(Pre-retrieval process)

    优化索引结构和原始查询优:

    • 化索引的目标是提高被索引内容的质量。涉及到策略如: 增强数据粒度,优化索引结构,添加元数据,对齐优化,混合检索等。
    • 查询优化的目标是使用户的原始问题更清晰,更适合于检索任务。常见的方法包括:查询重写查询转换,查询扩展等。
  • 后检索过程(Post-Retrieval Process)

将检索到相关的上下文有效地集成到查询中是至关重要的。

检索后处理的主要方法包括重新排序块(rerank chunks)上下文压缩(context compressing)。检索后的工作集中在选择关键信息、强调关键部分和缩短待处理的上下文。

1.3 Modular RAG

Modular RAG 引入多个特定功能模块和替换现有模块, 总体上展示了更大的灵活性。其过程并不局限于顺序检索和生成,包了括迭代和自适应检索等方法。

  • new Modules

    模块化 RAG 框架引入了额外的专门组件,以增强检索和处理能力。

    • Search 模块适应特定的场景,使用 LLM 生成的代码和查询语言,可以直接搜索各种数据源,如搜索引擎、数据库和知识图表。
    • RAG-Fusion 通过采用多查询策略解决传统搜索的局限性,该策略将用户查询扩展到不同的视角,利用并行向量搜索和智能重新排序来发现显性和变革性的知识边缘。
    • Memory 模块利用 LLM 的内存来指导检索,创建一个无界内存池,通过迭代自我提升,使文本与数据分布更紧密地对齐。
    • Routing 模块通过不同的数据源,为查询选择最佳路径,无论是涉及摘要、特定的数据库搜索,还是合并不同的信息流。
    • Predict 模块旨在通过直接通过 LLM 生成上下文来减少冗余和噪声,确保相关性和准确性。
    • Task Adapter 模块将 RAG 适配到各种下游任务,为 zero-shot 输入自动提示进行检索,为 few-shot 查询生成创建特定于任务的检索器。
  • new Patterns

通过允许模块替换或重新配置来解决特定的问题,模块 RAG 提供了显著的适应能力。这超出了 Naive 和 Advanced RAG 的固定结构,其特点是拥有属性简单的 “Retrieve” 和“ Read”机制。此外,模块化 RAG 通过整合新的模块或调整现有模块之间的交互流来扩展这种灵活性,增强其在不同任务之间的适用性。

诸如 Rewrite-Retrieve-Read 模型之类的创新利用了 LLM 的能力,通过重写模块和 llm 反馈机制来更新重写模型来改进检索查询。类似地,Generate-Read 这样的方法用 llm 生成的内容取代了传统的检索,而 Recite-Read 强调从模型权重进行检索,增强了模型处理知识密集型任务的能力。混合检索策略整合了关键字,语义和向量搜索,以满足不同的查询。此外,利用子查询和假设文档嵌入 (HyDE) 试图通过在生成的答案和真实文档之间嵌入相似性来提高检索的相关性。

1.4 RAG、Fing-turning、提示词工程对比

上面象限图表来说明三者外部知识需求、模型适应需求两个维度上的差异:

Prompt 工程利用模型的内在能力,对外部知识和模型适应的必要性最小。RAG 可以类比为信息检索提供一个具有量身定制的教科书的模型,是精确信息检索任务的理想选择。相比之下,FT 相当于学生随着时间的推移内化知识,适用于需要复制特定结构、风格或格式的场景。

RAG 通过提供实时的知识更新和高可解释性的外部知识源的有效利用,在动态环境中表现出色。然而,它带来了更高的延迟和数据检索的道德考虑。另一方面,FT 更为静态,需要对更新后的数据进行再培训,但允许对模型的行为和风格进行深度定制。它需要大量的计算资源来准备和训练数据集,虽然它可以减少幻觉,但它可能面临不熟悉的数据的挑战。

FT 依赖 “再次学习” 形成自身 “内部专业知识” 进行回答,而 RAG 是已有基础知识后进行“开卷考试”。RAG 和 FT 之间的选择取决于应用环境中对数据动态、定制和计算能力的具体需求。RAG 和 FT 并不是相互排斥的,它们可以相互补充,在不同的层次上增强模型的能力。在某些情况下,它们的结合使用可能导致最佳性能。包含 RAG 和 FT 的优化过程可能需要多次迭代才能达到满意的结果。

2.R(检索 - Retrieval)

2.1 检索源(Source)

RAG 依靠外部知识来增强 LLMs,而检索源的类型和检索单元的粒度都会影响最终的生成结果。

  • 数据结构
    • 非结构化数据,如文本,是使用最广泛的检索源,主要是从语料库中收集(或者百科)。
    • 半结构化数据,通常是指包含文本和表格信息组合的数据,如 PDF。
    • 结构化数据,如知识图谱 (KGs),通常经过验证,可以提供更精确的信息。Knowledge pt 生成 KB 搜索查询并将知识存储在个性化的基础上,增强 RAG 模型的知识丰富性。

除了从原始的外部来源进行检索之外,也可以 LLMs 自身产生的内容进行检索和增强。

  • 检索粒度

  • 粗粒度检索单元理论上可以为问题提供更多的相关信息,但它们也可能包含冗余内容,这可能会分散下游任务中检索器和语言模型的注意力;

  • 细粒度检索单元粒度虽然精准划分,但增加了检索的负担,并且不能保证语义完整性和满足所需的知识。

    在推理过程中选择合适的检索粒度是提高密集检索器的检索和下游任务性能的一个简单而有效的策略。

2.2 检索优化(Indexing Optimization)

在索引阶段,文档将被处理,分段,并转换成嵌入,存储在矢量数据库中。索引构造的质量决定了在检索阶段是否能够获得正确的上下文。

  • 分块策略

最常用的方法是将文档按固定数量的 token(例如,100、256、512) 分割成块。更大的块可以捕获更多的上下文,但它们也会产生更多的噪音,需要更长的处理时间和更高的成本。虽然较小的块可能无法完全传达必要的上下文,但它们的噪音确实较小。然而,语块导致句子中的截断,促使递归分割和滑动窗口方法的优化,通过跨多个检索过程合并全局相关信息实现分层检索。尽管如此,这些方法仍然不能在语义完整性和上下文长度之间达到平衡。因此,可以使用 Small2Big 方法,其中句子 (小) 作为检索单元,前面和后面的句子(大)作为 LLMs 的上下文。

  • 元数据附件

chunks 可以丰富元数据信息,如页码,文件名,作者,类别时间戳。检索可以基于这些元数据进行过滤,限制检索范围。在检索过程中为文档时间戳分配不同的权重可以实现时间感知的 RAG,确保知识的新鲜性和避免过时的信息。

除了从原始文档中提取元数据之外,还可以人工构造元数据。例如,添加段落摘要,以及引入假设性问题。这种方法也被称为 Reverse HyDE

tip:使用 LLM 生成可以被知识库文档回答的问题,然后在检索过程中计算原问题与假设问题的相似度,以缩小问题与答案之间的语义差距。

  • 结构检索

    提高信息检索的一个有效方法是为文档建立一个层次结构。通过构建结构,RAG 系统可以加快相关数据的检索和处理。

    • 层次索引:文件是按照父子关系排列的,有链接到它们的块。数据汇总存储在每个节点上,帮助快速遍历数据,帮助 RAG 系统决定提取哪些块。这种方法也可以减轻块提取问题造成的错觉。
    • 知识图谱:利用 KG 构建文档的层次结构有助于保持一致性。它描绘了不同概念和实体之间的联系,显著降低了产生错觉的可能性。另一个优点是将信息检索过程转化为 LLM 可以理解的指令,从而提高知识检索的准确性,并使 LLM 能够产生上下文相关的连贯响应,从而提高 RAG 系统的总体效率。为了捕捉文档内容和结构之间的逻辑关系,KGP 提出了一种使用 KG 在多个文档之间建立索引的方法。该 KG 由节点 (表示文档中的段落或结构,如页面和表格) 和边 (表示段落或文档结构中关系之间的语义 / 词汇相似性) 组成,有效地解决了多文档环境中的知识边缘检索和推理问题。

2.3查询优化(Query Optimization)

Naive RAG 直接依赖用户的原始查询作为检索的基础。制定一个精确而清晰的问题是困难的,有时候,问题本身很复杂,语言也没有很好的组织。同时,语言模型在处理具有多重含义的专门词汇或模糊缩写时经常会遇到困难。例如,他们可能无法辨别 “LLM” 指的是大型语言模型还是法律硕士。

  • 查询扩展

    将单个查询扩展为多个查询,丰富了查询的内容,提供了进一步的上下文,以解决任何缺乏特定细微差别的问题,从而确保生成的答案具有最佳的相关性。

    • 多查询。通过使用提示工程技术通过 LLMs 扩展查询,这些查询可以并行执行。查询的扩展不是随机的,而是精心设计的。
    • 子查询。子问题规划的过程代表了必要的子问题的产生,这些子问题的产生是为了将原始问题与上下文联系起来,并在合并后完全回答原始问题。这个添加相关上下文的过程原则上类似于查询扩展。具体而言,一个复杂的问题可以使用最少到最多的提示方法分解为一系列更简单的子问题。
    • 链式验证 (CoVe)。扩展的查询经过 LLM 的验证,以达到减少幻觉的效果。验证的扩展查询通常表现出更高的可靠性。
  • 查询转换

    核心概念是基于转换后的查询检索对应的 chunks,而不是基于用户的原始查询。

    • Query Rewrite(查询重写)。对于 LLM 检索来说,原始查询并不总是最优的,特别是在现实世界中。因此,我们可以提示 LLM 重写查询。除了使用 LLM 进行查询重写,还有专门的小型语言模型,比如 RRR (Rewrite-retrieve-read)。
    • 使用 Prompt 工程,让 LLM 基于原始查询生成查询。在 RAG 系统中,回退问题和原始查询都被用于检索,并且这两个结果都被用作语言模型答案生成的基础。
  • 查询路由

    基于不同的查询,路由到不同的 RAG 管道,适合多功能的 RAG 系统设计,以适应不同的情况。

    • 元数据路由 / 过滤器。第一步是从查询中提取关键字 (实体) ,然后根据块中的关键字和元数据进行过滤,以缩小搜索范围。
    • Semantic Router,一种利用查询语义信息的路由方法。

2.4嵌入(Embedding)

在 RAG 中,检索是通过计算问题与 chunks 二者 Embedding 之间的相似度 (如余弦距离) 来实现的,而嵌入模型的语义表示能力在其中起着关键作用。这主要包括一个稀疏编码器 (BM25) 和一个密集检索器(BERT 架构预训练语言模型)。

一些突出的嵌入模型,如 AngIE、 Voyage、 BGE 等 ,它们都受益于多任务结构调优。另外,C-MTEB 侧重于中文能力,涵盖 6 个任务和 35 个数据集。对于 “使用哪种嵌入模型” 这个问题,没有一个一刀切的答案然而,一些特定的模型更适合特定的用例。

  • 混合 / 混合检索

稀疏和密集的嵌入方法捕获不同的相关性特征,可以通过利用互补的相关性信息相互受益。例如,稀疏检索模型可以用于为培训密集的检索模型提供初始搜索结果。此外,预训练语言模型 (PLMs) 可以用来学习术语权重,以增强稀疏检索。具体地说,稀疏检索模型可以增强密集检索模型的零点检索能力,协助密集检索器处理包含稀疏实体的查询,从而提高鲁棒性。

  • 微调嵌入模型

在上下文明显偏离培训前语料库的情况下,特别是在高度专业化的学科 (如医疗保健、法律实践和其他充满专有术语的部门) ,微调嵌入模型对于减少此类差异至关重要。

除了补充领域知识,微调的另一个目的是校准检索器和生成器,例如,使用 LLM 的结果作为微调的监督信号,称为 LSR (lm 监督检索器)。PROMPTAGATOR 利用 LLM 作为少镜头查询生成器来创建特定于任务的检索器,解决有监督的微调中的挑战,特别是在数据稀缺的领域。

另一种方法 LLM-Embedder 利用 LLMs 在多个下游任务中产生奖励信号。检索器通过两种类型的监督信号进行微调: 数据集的硬标签和来自 LLMs 的软奖励。这种双信号方法促进了更有效的微调过程,使嵌入模型适应不同的下游应用。REPLUG 利用检索器和 LLM 来计算检索文档的概率分布,然后通过计算 KL 发散来执行监督训练。这种直接有效的训练方法通过使用 LM 作为监督信号来提高检索模型的性能,从而消除了对特定交叉注意机制的需求。此外,受 RLHF (人类反馈强化学习) 的启发,利用基于 lm 的反馈通过强化学习来强化检索器。

2.5适配器(Adapter)

微调模型可能会带来挑战,比如通过 API 进行功能集成,或者解决由于局部计算资源有限而产生的约束。因此,一些方法选择结合外部适配器来帮助对齐。

3.G(生成 - Generation)

检索后,通常不能直接将检索到的所有信息输入 LLM 回答问题,需要对检索到的内容或者模型进行调整。

3.1 上下文扩展(Context Curation)

冗余信息会干扰 LLM 的最终生成,过长的上下文也会导致 LLM 陷入 “中间丢失” 的问题(像人类一样,LLM 倾向于只关注长文本的开头和结尾,而忘记中间部分。)。因此,在 RAG 系统中,我们通常需要进一步处理检索到的内容。

重排(Reranking):

重排从根本上重新排列文档块,首先突出最相关的结果,有效地减少了整个文档池,切断了信息检索的双重目的,既充当增强器又充当过滤器,为更精确的语言模型处理提供精炼的输入。

重新排序可以使用基于规则的方法来执行,这些方法依赖于预定义的度量,如多样性、相关性和 MRR,或者基于模型的方法,如 BERT 系列的 Encoder-Decoder 模型 (如 SpanBERT) ,专门的重新排序模型,如 Cohere 重新排序或 bge-raranker-large,以及一般的大语言模型,如 GPT。

上下文选择 / 压缩

RAG 过程中的一个常见误解是,认为检索尽可能多的相关文档并将它们连接起来形成一个冗长的检索提示符是有益的。然而,过多的上下文会引入更多的噪音,降低 LLM 对关键信息的感知。除了压缩上下文之外,减少文档的数量也有助于提高模型答案的准确性

3.2 微调(LLM Fine-tuning)

基于场景和 LLMs 上的数据特征进行有针对性的微调可以产生更好的结果(这里就是 RAG 结合 FT 的思想)。当 LLM 在特定领域缺乏数据时,可以通过微调向 LLM 提供额外的知识。微调的另一个好处是能够调整模型的输入和输出。例如,它可以使 LLM 适应特定的数据格式,并按照指示以特定的风格生成响应。

4. A(增强 - Augmentation)

在 RAG 领域,标准实践往往涉及一个单一的 (一次) 检索步骤,有时对于需要多步推理的复杂问题通常是不够的,因为单次检索提供的信息范围有限。

除了最常见的一次检索,RAG 还包括三种类型的检索增强过程。

  • 迭代检索涉及检索和生成之间的交替,允许在每个步骤从知识库中获得更丰富和更有针对性的上下文。
  • 递归检索包括逐渐细化用户查询,将问题分解为子问题,然后通过检索和生成不断解决复杂问题。
  • 自适应检索的重点是使 RAG 系统能够自主决定是否需要外部知识检索,以及何时停止检索和生成,通常使用 LLM 生成的特殊令牌进行控制。

5.任务和评价

RAG 模型在自然语言处理领域的快速发展和日益广泛的应用已经将 RAG 模型的评估推向了 LLMs 社区研究的前沿。

5.1 下游任务

RAG 的核心任务仍然是问答 (QA) ,包括传统的单跳 / 多跳 QA、多选择、特定领域的 QA 以及适合 RAG 的长格式场景。除了 QA 之外,RAG 还不断地被扩展到多个下游任务,如信息提取 (IE)、对话生成、代码搜索等。

5.2 评估

RAG 模型的评估强调三个主要质量评分和四个基本能力,它们共同决定了 RAG 模型的两个主要评价指标: 检索和生成。

  • 质量得分

    • 上下文相关性:评估检索上下文的精确性和特异性,确保相关性并最小化与外部内容相关的处理成本。
    • 回答忠实性:确保生成的答案保持真实的检索上下文,保持一致性,避免矛盾。
    • 答案相关性:要求生成的答案与提出的问题直接相关,有效地解决核心问题。
  • 能力评价

    • 噪声鲁棒性:评估模型管理与问题相关但缺乏实质性信息的噪声文档的能力。
    • 否定拒绝:评估模型在检索到的文档不包含回答问题所需的必要知识时拒绝回答的识别能力。
    • 信息集成 (Information Integration):评估模型在综合多个文档信息以解决复杂问题方面的能力。
    • 反事实鲁棒性:评估模型识别和忽略文档中已知的不准确性的能力,即使在指示可能的错误信息时也是如此。

上下文相关性和噪声鲁棒性是评价检索质量的重要指标,而答案忠实度、答案相关性、否定拒绝、信息整合和反事实鲁棒性是评价检索质量的重要指标。

6.讨论和未来前景

6.1 RAG vs Long Context

随着 LLMs 研究不断深入,目前 LLMs 可以直接处理 20 万个标记的上下文。这种能力意味着,以前依赖 RAG 的长文档问答现在可以直接将整个文档整合到提示符中。

事实上,RAG 仍然扮演着不可替代的角色。一方面,同时为 LLMs 提供大量的上下文将显著影响其推理速度,而分块检索和按需输入则可显著提高其运行效率。另一方面,基于 rag 的生成可以快速定位 LLMs 的原始引用,帮助用户验证生成的答案。整个检索和推理过程是可以观察到的,而完全依赖于长上下文的生成仍然是一个黑匣子。在超长上下文处理能力背景下,新 RAG 方法是未来的研究趋势之一。有研究结果表明,包括不相关的文件可以出乎意料地将准确性提高 30% 以上,与质量下降的最初假设相矛盾。这些结果强调了开发专门的策略以将检索与语言生成模型结合起来的重要性,突出了对 RAG 的健壮性进行进一步研究和探索的必要性。

6.2 Hybrid Approaches

将 RAG 与微调相结合正在成为一种领先的策略。确定 RAG 的最佳集成和微调,无论是顺序的,交替的,还是通过端到端的联合训练 - 以及如何利用这两个参数化

6.3 Production-Ready RAG

RAG 的实用性和与工程需求的一致性促进了它的采用。RAG 生态系统的发展在很大程度上受到其技术层次进步的影响。随着 ChatGPT 的出现,LangChain 和 LLamaIndex 等关键工具迅速受到欢迎,它们提供了广泛的 rag 相关 api,并成为 LLMs 领域的必备工具。新兴的技术堆栈,虽然不像 LangChain 和 LLamaIndex 那样功能丰富,但是通过它的专业化产品脱颖而出。例如,Flowise AI 优先考虑低代码的方法,允许用户通过用户友好的拖放界面部署 AI 应用程序,包括 RAG。其他技术如 HayStack、 Meltano 和 Cohere Coral 也因其在这一领域的独特贡献而受到关注。

除了专注于人工智能的供应商,传统的软件和云服务供应商正在扩展他们的产品,包括以 rag 为中心的服务。Weaviate 的 Verba 11 是为个人助理应用程序设计的,而 Amazon 的 Kendra 12 提供智能企业搜索服务,使用户能够使用内置的连接器浏览各种内容存储库。在 RAG 技术的发展过程中,出现了一个明显的趋势,朝着不同的专业化方向发展,例如:

  1. 定制化 - 根据特定需求调整 RAG(Retrieval-Augmented Generation,检索增强生成)。
  2. 简化 - 使 RAG 更易用,以降低初始学习曲线。
  3. 专业化 - 优化 RAG 以更好地服务于生产环境。RAG 生态图如下

6.4 Multi-modal RAG

RAG 已经超越了它最初基于文本的问答范围,包含了各种各样的模态数据。这种扩展催生了创新的多模态模型,将 RAG 概念整合到各个领域: 图像、音视频、Vid2Seq、code。结语随着 LLM 及 RAG 技术的不断发展,Agent 的基础能力愈发强大,如何将底层能力整合,产生一个现象级的产品是当下最直接的诉求。Agent 最终的呈现形态,一直在探索与期待... 随着 Agent 爆发,我们不妨尝试将 RAG 融入到 Agent 设计中,进一步提升其 “智能性” 和“专业性”~

更多优质内容请关注公号:汀丶人工智能;会提供一些相关的资源和优质文章,免费获取阅读。

相关实践学习
阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
通过该实验体验在阿里云百炼中构建企业专属知识库构建及应用全流程。同时体验使用ADB-PG向量检索引擎提供专属安全存储,保障企业数据隐私安全。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
相关文章
|
机器学习/深度学习 存储 人工智能
阿里云机器学习PAI全新推出特征平台 (Feature Store),助力AI建模场景特征数据高效利用
机器学习平台 PAI 推出特征平台(PAI-FeatureStore),在所有需要特征的AI建模场景,用户可通过 Feature Store 轻松地共享和重用特征数据,减少资源和时间成本、提升工作效率。
|
人工智能 API 决策智能
MetaGPT( The Multi-Agent Framework):颠覆AI开发的革命性多智能体元编程框架
MetaGPT( The Multi-Agent Framework):颠覆AI开发的革命性多智能体元编程框架
MetaGPT( The Multi-Agent Framework):颠覆AI开发的革命性多智能体元编程框架
|
3月前
|
存储 人工智能
|
3月前
|
自然语言处理 算法 数据挖掘
模块化RAG技术路线图:从基础Naive RAG 到Modular RAG全方位技术解读
【8月更文挑战第12天】模块化RAG技术路线图:从基础Naive RAG 到Modular RAG全方位技术解读
模块化RAG技术路线图:从基础Naive RAG 到Modular RAG全方位技术解读
|
2月前
|
机器学习/深度学习 人工智能 搜索推荐
如何让你的Uno Platform应用秒变AI大神?从零开始,轻松集成机器学习功能,让应用智能起来,用户惊呼太神奇!
【9月更文挑战第8天】随着技术的发展,人工智能与机器学习已融入日常生活,特别是在移动应用开发中。Uno Platform 是一个强大的框架,支持使用 C# 和 XAML 开发跨平台应用(涵盖 Windows、macOS、iOS、Android 和 Web)。本文探讨如何在 Uno Platform 中集成机器学习功能,通过示例代码展示从模型选择、训练到应用集成的全过程,并介绍如何利用 Onnx Runtime 等库实现在 Uno 平台上的模型运行,最终提升应用智能化水平和用户体验。
49 1
|
3月前
|
人工智能 分布式计算 数据处理
Big Data for AI实践:面向AI大模型开发和应用的大规模数据处理套件
文叙述的 Big Data for AI 最佳实践,基于阿里云人工智能平台PAI、MaxCompute自研分布式计算框架MaxFrame、Data-Juicer等产品和工具,实现了大模型数据采集、清洗、增强及合成大模型数据的全链路,解决企业级大模型开发应用场景的数据处理难题。
|
6月前
|
人工智能 物联网 API
LLM 大模型学习必知必会系列(十三):基于SWIFT的VLLM推理加速与部署实战
LLM 大模型学习必知必会系列(十三):基于SWIFT的VLLM推理加速与部署实战
LLM 大模型学习必知必会系列(十三):基于SWIFT的VLLM推理加速与部署实战
|
6月前
|
人工智能
【AI大模型应用开发】【LangChain系列】实战案例5:用LangChain实现灵活的Agents+RAG,该查时查,不该查时就别查
【AI大模型应用开发】【LangChain系列】实战案例5:用LangChain实现灵活的Agents+RAG,该查时查,不该查时就别查
362 0
|
6月前
|
人工智能 API Python
【AI大模型应用开发】1.1 Prompt Engineering(提示词工程)- 用OpenAI API实战,优化方法论总结
【AI大模型应用开发】1.1 Prompt Engineering(提示词工程)- 用OpenAI API实战,优化方法论总结
304 0
|
6月前
|
人工智能 程序员 API
【AI大模型应用开发】1.0 Prompt Engineering(提示词工程)- 典型构成、原则与技巧,代码中加入Prompt
【AI大模型应用开发】1.0 Prompt Engineering(提示词工程)- 典型构成、原则与技巧,代码中加入Prompt
239 0