将你的LLM应用程序原型转变为生产就绪解决方案的17种高级RAG技术

前言

如今，人们迅速成为生成式AI_（GenAI）_专家的速度令人惊叹。他们每个人都宣称，GenAI将带来下一次工业革命。

这是一个很大的承诺，但我同意，我认为这次是真的。AI将彻底改变我们的工作和生活方式。我无法想象会再次进入AI寒冬。

大型语言模型_（LLM）_和多模态模型实在是太有用了，并且“相对”容易实现到现有的流程中。一个向量数据库，几行代码处理原始数据，再加上一些API调用。

就是这样。——至少在理论上是这样。

虽然听起来相当简单，但这个行业的真正进展可能更好地由Matt Turck最近在LinkedIn上的一篇帖子来描述：

2023年：“希望生成式AI不会杀死我们所有人！”

2024年：“希望生成式AI能在我公司的概念验证实验中转变为小规模生产部署，能够在未来12-18个月内读取PDF文件！”

——Matt Turck

构建一个原型很容易。将其转变为生产就绪的解决方案则很难。

接下来的文章适用于那些在过去一个月里构建了他们第一个LLM应用并开始产品化它的人。我们将探讨17种技术，你应该尝试这些技术以减轻RAG过程中的一些陷阱，并逐步将你的应用程序开发成一个强大且持久的解决方案。

为了了解我们在标准RAG流程中有哪些改进的机会，我将简要回顾创建一个简单RAG应用程序所需的组件。你可以随时跳过这一部分，直接进入“高级”技术部分。

我们需要什么来获得一个生产就绪的解决方案？

LLM变得越来越强大是一方面，但如果我们彼此坦诚，提高RAG性能的更大杠杆仍然是那些不那么花哨的东西：

数据质量 — 数据准备 — 数据处理。

在应用程序运行期间或准备原始数据时，我们处理数据，分类数据并从数据中获得见解，以引导结果朝正确的方向发展。

简单地等待越来越大的模型来解决我们所有的问题，而我们自己却不去处理数据和流程，这是不现实的。

也许有一天，我们将所有糟糕的原始数据输入到一个模型中，而它却能从中生成有用的东西。但即使我们达到了那一点，我也怀疑从成本和性能的角度来看这是否有意义。

RAG的概念已经深入人心。

在Sequoia Capital的AI Ascent演讲中，Andrew Ng展示了如何通过使用基于代理的方法，GPT-3.5能够击败更强大的模型。下图比较了GPT-4_（零样本提示）_与GPT-3.5 + 代理工作流程的准确性。

编码基准(HumanEval) -图片由作者提供(数据来自[Andre Ng, 2024])

随着大规模Transformer模型为我们带来了所有这些能力，AGI_（人工通用智能）_不再只是科幻电影中的东西。

与此同时，我怀疑我们是否会通过一个全知AI模型达到AGI水平。Andrew Ng将“AGI-like”程序描述为一个整体系统，将LLM和多模态模型与合适的组件和工具结合在一起。[Andrew Ng, 2024]

如果情况如此，那么我们所有人都可以踏上AGI之旅。我们可以填补大型模型和现实世界应用之间的空白，并逐步使这种系统变得更加智能和强大。

在本文中，我将向你展示这段旅程中的一些工具。所描述的技术将帮助我们提高系统的鲁棒性和性能。

它们将帮助我们回答以下问题：

• 我的系统如何找到“真正”相关的内容？

• 我如何准备和处理数据以便LLM能够处理？

• 我可以串联连接LLM吗？通过不同组件路由请求？

在深入探讨高级技术之前，我们先来谈谈Naive RAG——最基础的RAG系统，并在此基础上构建。

我承诺简要说明，但如果你对标准RAG系统已经非常熟悉，可以随时跳过这一部分。

Naive RAG——简要回顾

在RAG中，我们在巨人的基础上进行构建，利用现有的概念和技术并以合适的方式将它们结合起来。

很多技术都源于搜索引擎领域。目标是围绕LLM构建一个流程，为模型提供正确的数据，以便做出决策或总结信息。

下图显示了我们在构建此类系统时使用的一些技术。

除了Transformer模型，我们还使用了一些技术，例如：

• 语义搜索技术

• 准备和处理文本数据的技术

• 知识图谱、小型分类/回归/NLP模型等

这些技术已经存在多年了。向量搜索库FAISS发布于2019年。此外，文本向量化并不是什么新鲜事。[Ilin, 2024]

RAG只是将这些组件连接起来，解决特定问题。

例如，Bing搜索将其传统的“BING”网页搜索与LLM的能力结合起来。这使得他们的聊天机器人能够回答关于“真实”生活数据的问题，例如：

“谷歌今天的股价是多少？”

下图显示了标准RAG流程。当用户提出问题时，Naive RAG直接将用户的问题与我们向量数据库中的任何内容进行比较。

我们感兴趣的是找到相似的内容。相似内容是指在我们的向量空间中彼此接近的内容。距离通过例如计算余弦相似度来衡量。

示例：

问题：“Tom Brady打过什么位置？”

假设我们的向量数据库中有两个主要数据源：

1. Tom Brady的维基百科文章。

2. 来自一本食谱的文章。

在下例中，维基百科的内容应该更相关，因此更接近用户的问题。

但是，“接近”到什么程度才算“够接近”呢？

我们无法为相似度分数设置一个阈值，以区分相关和不相关的内容。你可以自己尝试，但你可能会发现这并不实用。

找到内容了吗？让我们构建提示

现在我们找到了与用户问题相似的内容，我们需要将它们打包成一个有意义的提示。我们得到一个至少有3个构建块的提示。

1.系统提示，告诉LLM如何表现

2.用户的问题

3.上下文，即执行相似性搜索后找到的相关文档

一个合适的提示模板可能如下：

系统提示部分中的“…仅使用提供的信息”将LLM变成一个处理和解释信息的系统。在这种情况下，我们不直接利用模型的知识来回答问题。

就是这样。——就是这么简单。一个向量存储，一个嵌入模型，一个LLM，几行Python代码——当然还有一些文档。

当我们扩展这些系统并将它们从原型转变为生产就绪的解决方案时，我们回到了现实。

我们很可能在过程中遇到各种陷阱，例如：

• _（有价值的内容 vs. 干扰项）_我们的最近邻搜索总能找到相关内容，但这些内容有多相关？我们称那些对回答用户问题没有帮助的数据点为干扰项。

• _（分块优化）_单个内容片段的大小应该是多少，以便既足够具体又包含足够的上下文？

• _（监控/评估）_我们如何在操作中监控我们的解决方案？（LLMOps）

• _（代理/多重提示）_我们如何处理无法用一个提示解决的复杂查询？

如何处理RAG的潜在陷阱？

如上所述，我们有不同的组件相互作用。这为我们提供了多种方法来改进整体系统的性能。

基本上我们可以尝试改进以下5个流程步骤：

1. 检索前：将嵌入信息导入向量存储

2. 检索：查找相关内容

3. 检索后：在将结果发送到LLM之前进行预处理

4. 生成：使用提供的上下文解决用户的问题

5. 路由：请求的整体路由，例如代理方法将问题分解并在模型之间来回传递

如果我们仔细观察它们，我们会得到以下图景。

让我们逐一看一下。

我们从最明显和最简单的方法开始——数据质量。对于大多数RAG用例来说，数据通常是文本数据，例如一些维基百科文章。

1.原始数据创建/准备

我们并不总是需要仅处理现有的数据。我们通常可以影响文档的创建过程。

通过LLM和RAG应用程序，我们突然被迫去结构化我们的知识库。在Naive RAG中，我们搜索与用户问题某种程度上相似的信息片段。

这种方式下，模型永远不会看到整个wiki上下文，而只能看到个别的文本片段。这是一个问题，当文档包含：

• 领域特定或文档特定的缩写

• 链接到wiki其他部分的文本段落

如果一个没有背景知识的人都难以理解文本片段的全部意义，那么LLM也会碰壁。

在文章的后面部分，你会找到一些在检索步骤之后或过程中尝试解决这些问题的技术。

在理想的世界中，我们不需要这些技术。

我们wiki中的每一部分都应该尽可能容易理解，这也使我们人类更容易。这种方式下，我们既提高了wiki的可读性，又提高了RAG应用程序的性能。双赢。

以下示例展示了如何通过正确设置内容来让我们的RAG应用程序更轻松。

(1) 准备数据使文本块具有自解释性

在下图中，你可以看到一个类似于你在教程和技术文档中经常看到的示例。如果我们没有一个纯粹的LLM和不是一个多模态模型，LLM将难以完全理解左侧版本1中的内容。版本2至少给了它更好的机会去理解。

RAG过程的下一步是以有意义的方式分块数据，将其转换为嵌入并进行索引。

2.索引/分块—分块优化

Transformer模型有固定的输入序列长度。因此，我们在发送到LLM和嵌入模型的提示中的令牌大小是有限的。

但在我看来，这并不是一个限制。

考虑文本片段和提示的最佳长度是有意义的，因为这对性能有重大影响，例如：

• 响应时间_（+成本）_

• 相似性搜索的准确性

• ETC

有各种文本分割器可用于分块文本。

(2) 分块优化—滑动窗口，递归结构感知分割，结构感知分割，内容感知分割

块的大小是需要考虑的一个参数——它取决于你使用的嵌入模型及其令牌容量，基于BERT的句子Transformer模型最多可处理512个令牌，一些嵌入模型能够处理更长的序列，8191个令牌及更多。

但更大并不总是更好。我宁愿在一本书中找到包含两个最重要信息的两个句子，也不愿找到包含答案但也有很多其他内容的五页。

这里的妥协是：

为LLM提供足够的上下文进行推理，以足够具体的文本嵌入，以便有效地执行搜索

有不同的方法可以解决这些块大小选择问题。在LlamaIndex中，NodeParser类提供了一些高级选项，例如定义你自己的文本分割器、元数据、节点/块关系等。

通过将整个文本严格划分为多个部分，确保正确捕获所有信息，并且不会忽略任何部分，最简单的方法是使用滑动窗口。

很简单，文本部分重叠——就是这样。

除此之外，还有很多其他的分块技术可以尝试，以改善分块过程，例如：

• 递归结构感知分割

• 结构感知分割_（按句子、段落）_

• 内容感知分割_（Markdown、LaTeX、HTML）_

• 使用NLP进行分块：跟踪主题变化

(3) 提高数据质量——缩写，技术术语，链接

数据清理技术删除无关信息或将文本段落放入上下文中以使其更易理解。

有时，如果你知道书的上下文，在长文本中特定段落的意义就会变得很清楚。如果上下文缺失，这就变得困难。

缩写、特定技术术语或公司内部术语使得模型难以理解全部意义。

下图展示了一些示例。

• 如果你对篮球一无所知，你将永远不会将MJ与“迈克尔·乔丹”联系起来。

• 如果你不知道句子描述的是供应链背景中的某些内容，你可能会认为PO是“邮局”或任何以P和O开头的词组。

为解决这一问题，我们可以在处理数据时尝试引入必要的额外上下文，例如使用缩写翻译表将缩写替换为全称。

在处理文本到SQL的用例时，你肯定需要这个。许多数据库中的字段名称通常很奇怪。通常只有开发人员和上帝知道特定字段名称背后的意义。

SAP_（企业资源计划解决方案）_经常使用德文词语的缩写来标记其字段。字段“WERKS”是德文词语“Werkstoff”的缩写，描述了一个部件的原材料。

当然，这可能对定义数据库结构的团队有意义。其他人，包括我们的模型，将会很困难。

(4) 添加元数据

你可以在所有向量数据库中向向量数据添加元数据。元数据可以在执行向量搜索之前帮助_（预）_过滤整个向量数据库。

假设我们向量存储中的一半数据针对欧洲用户，另一半针对美国用户。如果我们知道用户的位置，我们不想搜索整个数据库，而是希望能够直接搜索相关的部分。如果我们有此信息作为元数据字段，大多数向量存储允许我们在执行相似性搜索之前预过滤数据库。

(5) 优化索引结构——全搜索与近似最近邻，HNSW与IVFPQ

我不认为相似性搜索是大多数RAG系统的弱点——至少在我们看响应时间时不是——但我仍然想提一下。

大多数向量存储中的相似性搜索速度如此之快，即使我们有数百万条目，因为它使用近似最近邻技术——例如FAISS、NMSLIB、ANNOY……

FAISS、NMSLIB或ANNOY，使用一些近似最近邻使之成为可能。

对于只有几千个条目的用例来说，这通常是过度设计。如果我们执行ANN或完整的最近邻搜索，只会略微影响我们RAG系统的响应时间。

然而，如果你想建立一个可扩展的系统，你肯定可以加快速度。

(6) 选择正确的嵌入模型

要嵌入文本块有各种选项。如果你不确定使用哪些模型，可以查看用于衡量文本嵌入模型性能的现有基准，例如MTEB_（大规模文本嵌入基准）_。

在嵌入方面，我们通常需要决定嵌入的维度数。更高的维度让你可以捕获和存储句子的更多语义方面，另一方面，它需要更多的存储空间和计算时间。

我们将所有内容翻译为嵌入并将其添加到我们的向量数据库中。现在有来自不同提供商的几种模型可用。如果你想了解可以使用哪些模型，可以查看langchain.embeddings模块支持的模型。在该模块的源代码中，你会找到一个相当长的支持模型列表：

__all__ = [
    "OpenAIEmbeddings",
    "AzureOpenAIEmbeddings",
    "CacheBackedEmbeddings",
    "ClarifaiEmbeddings",
    "CohereEmbeddings",
   ...
    "QianfanEmbeddingsEndpoint",
    "JohnSnowLabsEmbeddings",
    "VoyageEmbeddings",
    "BookendEmbeddings"
]

3.检索优化——查询翻译/查询重写/查询扩展

查询扩展、查询重写或查询翻译都需要修改原始查询以适应大型语言模型_（LLM）_。

基本上，我们使用LLM的强大功能来增强和改进发送到向量搜索的查询。

有几种不同的方法，例如：

1. 通过生成LLM文档来扩展用户的查询。

2. 或者，我们可以使用LLM稍微改写用户的查询，并发送不同的提示到模型，然后解释来自模型的不同反馈。

让我们从第一种方法开始。

(7)使用生成答案进行查询扩展——HyDE等

在进行相似性搜索之前，我们使用LLM生成一个答案。如果这是一个只能使用我们的内部知识回答的问题，我们间接要求模型生成一个“幻觉”答案，并使用该答案来搜索与之相似的内容，而不是直接使用用户的查询。

有几种技术，如HyDE_（假设文档嵌入）_、重写-检索-阅读、Step-Back提示、Query2Doc、ITER-RETGEN等。

在HyDE中，我们首先让LLM在没有上下文的情况下创建一个答案，然后使用这个答案在我们的矢量数据库中搜索相关信息。

与HyDE等方法不同，我们还可以通过使用多个系统提示来扩展用户的查询。

(8)多系统提示

这个想法很简单：我们生成例如4个不同的提示，这将提供4个不同的响应。

你可以发挥创意。提示之间的差异可以是任何方面的。

• 如果我们有一个长文本并想总结它，我们可以通过使用不同的提示来查找文本中的某些方面，并在最终答案中总结这些发现。

• 或者，我们可以使用相同上下文的4个基本相同的提示，只是系统提示略有不同。这样我们可以4次以稍微不同的方式告诉LLM该做什么或如何表达答案。

这个想法在数据科学中无处不在。在Boosting算法中，我们通常有简单的模型，每个模型略有不同，做出一个小决定。最终我们以某种方式合并结果。这个概念非常强大。

在这里我们也这样做，只是再次使用模型来整合不同的预测。当然，缺点是计算时间和/或响应时间更长。

(9)查询路由

在查询路由中，我们使用LLM的决策能力来决定下一步该做什么。

假设我们在向量存储中有来自不同领域的数据。为了更有针对性地搜索相关内容，让模型首先决定应该使用哪个数据池来回答问题是有意义的。

下图中的示例向量存储包含来自世界各地的新闻。有关体育和足球的新闻、烹饪趋势和政治新闻。当用户查询我们的聊天机器人时，我们不希望混淆这些数据。

国家之间的体育竞争不应该与政治混在一起。如果用户正在寻找有关政治的新闻，烹饪内容可能没有帮助。

通过这种方式，我们可以显著提高性能。我们还可以为最终用户提供选择用来回答问题的主题的选项。

(10)混合搜索

基本上，RAG管道的检索步骤无非就是一个搜索引擎。可能是我们RAG系统中最重要的部分。

当我们想要改进相似性搜索时，值得一看搜索领域。一个例子是混合搜索方法。我们进行向量搜索以及词汇_（关键词）_搜索，并以某种方式将这些结果结合起来。

在机器学习中，这是一个常见的方法。使用不同的技术，不同的模型，预测相同的输出，并总结结果。这个想法总是一样的。

一群专家试图找到解决方案并做出妥协，比一个独立的专家做出更好的决定。

4.检索后：如何改进检索步骤？

上下文丰富化——例如，句子窗口检索

通常，我们尝试保持文本块较小，以便我们实际找到我们正在寻找的内容并保持搜索质量高。

另一方面，看到不仅仅是最佳匹配句子，还看到其周围的上下文，往往更容易给出正确答案。

让我们看看下图中的示例：

我们有一堆文本块，来自一篇关于德国足球俱乐部拜仁慕尼黑的维基百科文章。我没有测试过，但我可以想象第一个文本片段带来了最高的相似性得分。

尽管如此，第二块中的信息可能更相关。我们也希望捕捉到这一点。这就是上下文丰富化的用武之地。

有各种方法可以丰富上下文，以下我将简要描述其中的两种：

1. 句子窗口检索

2. 自动合并检索

(11)句子窗口检索

具有最高相似性得分的文本块代表找到的最佳匹配内容。在将内容发送到LLM之前，我们添加找到的文本块前后的k个句子。这是有意义的，因为这些信息很可能与中间部分有关，也许中间文本块中的信息并不完整。

自动合并检索以类似的方式进行，只是这次，每个块都有一定的“父”块附加到它上面，不一定是找到的块的前后块。

(12)自动合并检索（也称为父文档检索）

自动合并检索以类似的方式进行，只是这次每个小文本块都分配了一些“父”块，这些“父”块不一定是找到的文本块的前后块。

你可以发挥所有创造力来定义和识别文本块之间的相关关系。

例如，当我们查看技术文档或法律合同时，段落或部分通常会引用合同的其他部分。挑战在于使用其他段落中的相关信息来丰富段落。因此，我们需要能够识别文本中的链接，这些链接引用文档的其他部分。

我们可以在这个概念的基础上建立一个完整的层次结构，比如一个具有不同级别父节点、子节点和叶节点的决策树。我们可以例如有3个级别，每个级别具有不同的块大小_（https://docs.llamaindex.ai/en/stable/examples/retrievers/auto_merging_retriever/）_：

• 第一级：块大小2048

• 第二级：块大小512

• 第三级：块大小128_（叶节点）_

当我们索引数据并执行相似性搜索时，我们使用最小的块，即叶节点。此步骤之后，我们找到与叶节点匹配的父节点。

在检索步骤之后，我们必须解释找到的内容并使用它来解决用户查询。为此，我们使用大型语言模型（LLM）。但哪个模型适合我们的用例呢？

5.生成/代理

(13)选择合适的LLM和提供商——开源与闭源，服务与自托管，小模型与大模型

为你的应用选择合适的模型并不像你想象的那么容易。这取决于具体的应用及其流程。

有些人会说，最明显的解决方案是：

只需使用最强大的那个

然而，使用较小、较便宜和较快的模型有一些不可否认的优势。

在RAG过程的某些部分，准确性可以稍微低一些，但响应时间应该很快，例如：当我们使用基于代理的方法时，我们需要沿管道不断做出简单的决定。

此外，如果较小模型的响应和决策能力足够强大，就没有必要使用最强大的模型。你将减少解决方案的运营成本，用户将感谢你的系统响应时间的提高。

但是我们如何选择模型？

有几个基准，比较了不同角度的LLM。但最终，我们只需要为我们的RAG解决方案尝试它们。

(14)代理

代理结合了一些组件，并根据某些规则迭代执行它们。

代理使用所谓的“连锁推理”概念，这描述了以下迭代过程：

1. 发送请求

2. 使用LLM解释响应

3. 决定下一步

4. 再次行动

下图中的问题显示了一个通常太复杂而无法一次回答的示例，因为答案可能没有写在任何地方。

我们人类会将其分解为可以回答的更简单的子问题，然后计算我们正在寻找的答案。在这种情况下，代理也会这样做。

通过基于代理的方法，我们可以显著提高准确性。当然，总是有权衡。与一次性提示相比，我们增加了所需的计算能力和响应时间，但提高了准确性。

尽管如此，通过这种方法，我们可以用较小、较快的模型超越较大模型的准确性。最终，这可能是你的解决方案的更好方法。

这始终取决于你的具体用例——当我们为纯信息检索构建一个机器人时，我们总是在与搜索引擎的超短响应时间竞争。

响应时间是关键。

等待几秒钟甚至几分钟才能得到结果很糟糕。

6.评估——评估我们的RAG系统

基于RAG的系统的性能在很大程度上取决于所提供的数据和LLM提取有用信息的能力。要做到这一点，我们需要几个组件，一起发挥作用。当我们想要评估整个系统时，我们通常不仅要跟踪整体性能，还要了解各个组件如何完成它们应该做的工作。

像以前一样，我们可以将其拆分为对检索组件和生成器组件的评估。

我们可以使用典型的搜索指标_(如DCG和nDCG)来评估搜索部分，这些指标可评估排名质量。它们检查真正相关的内容是否在相似度搜索中被分类。（https://www.evidentlyai.com/ranking-metrics/ndcg-metric#:~:text=DCG%20measures%20the%20total%20item,ranking%20quality%20in%20the%20dataset.）（https://towardsdatascience.com/evaluating-rag-applications-with-ragas-81d67b0ee31a）_

评估模型本身的反应是棘手的。

我们如何评估反应?语言是有歧义的，所以我们怎样才能给出类似于评级的输出呢?

最简单的方法是问很多人他们是否认为这个答案有用——假设我们有1000个人给LLM的答案打分。这样你就能很好地了解它是如何工作的。但对于一个有效的解决方案来说，这是相当不切实际的。

每次稍微改变RAG过程，都会影响结果。我知道说服领域专家测试你的解决方案有多难。我们可以这样做一两次，但不是每次我们在管道中更改某些内容时都这样做。

所以我们需要想出一个更好的方法。一种方法是，我们不使用人类，而是使用其他LLM来评估结果——所以我们使用模型“作为评判者”的方法。

(15)LLM-作为评判者

生成部分可以使用LLM作为评判方法进行评估。这个概念很简单。

1. 我们生成一个估数据集

2. 然后用我们想要评估的合适标准定义一个所谓的批判代理，

3. 最后建立一个测试管道，根据定义的标准自动评估LLM的响应

步骤(1)-生成合成评估数据集

通常是一组(1)上下文，(2)问题，(3)答案。我们不一定有一个完整的数据集。我们可以自己创建它，为LLM提供上下文，让它猜测问题可能是什么。一步一步建立一个合成数据集。

步骤(2)-设置一个所谓的评论代理

批判代理是另一个LLM_(通常很强大)_，我们用它来评估基于一些标准的系统响应，例如：

• 专业性:如果答案是用专业的语气写的

一个指标定义的例子如下：

definition=(
    "Professionalism refers to the use of a formal, respectful, and appropriate style of communication that is "
    "tailored to the context and audience. It often involves avoiding overly casual language, slang, or "
    "colloquialisms, and instead using clear, concise, and respectful language."
),
grading_prompt=(
    "Professionalism: If the answer is written using a professional tone, below are the details for different scores: "
    "- Score 1: Language is extremely casual, informal, and may include slang or colloquialisms. Not suitable for "
    "professional contexts."
    "- Score 2: Language is casual but generally respectful and avoids strong informality or slang. Acceptable in "
    "some informal professional settings."
    "- Score 3: Language is overall formal but still have casual words/phrases. Borderline for professional contexts."
    "- Score 4: Language is balanced and avoids extreme informality or formality. Suitable for most professional contexts. "
    "- Score 5: Language is noticeably formal, respectful, and avoids casual elements. Appropriate for formal "
    "business or academic settings. "
),

步骤(3)-测试RAG系统:使用刚刚创建的评估数据集测试系统

对于我们想要测试的每个度量/标准，我们定义一个详细的描述_(例如，在1-5的范围内)_，并让模型决定。这不是一门精确的科学，模型的答案会有所不同，但它可以让我们了解系统的运行情况。

你可以在Prometheus的提示模板_（__https://huggingface.co/prometheus-eval/prometheus-13b-v1.0）_或Databricks的MLFlow教程中找到一些关于这个评分提示的例子。

(16)RAGAs

RAGAs(检索-增强生成评估)是一个框架，它允许你评估RAG系统的每个组件。

其中一个核心概念是“LLM-as-a-judge”/“LLM-assisted evaluation”背后的理念。但Ragas提供了更多。不同的工具和技术使你能够继续学习你的RAG应用程序。

值得一提的一个核心概念是“组件评估”。Ragas提供了预定义的指标来单独评估RAG管道的每个组件，例如（https://docs.ragas.io/en/stable/concepts/metrics/index.html#ragas-metrics）:

一代：

• 忠实度:生成的答案在事实上有多准确?

• 答案相关性:生成的答案与问题的相关性如何?

检索：

• 上下文精度:检索上下文的信噪比

• 上下文回忆:它能否检索到回答问题所需的所有相关信息

其他指标侧重于评估RAG管道的入口到端，例如：

• 回答语义相似度

• 答案的正确性

(17)继续从app和用户处收集数据

收集数据是明确识别和填补流程空白的关键。通常是你提供给系统的知识库中的数据本身不够好。为了意识到这一点，我们需要引入一些方法，让用户尽可能容易地提供反馈。

其他有趣的指标包括：

• 时间戳，RAG管道沿线上每一步的响应时间_(矢量化，相似度搜索，LLM响应等)_

• 使用的提示模板

• 相关文件发现，文件版本

• LLM响应

• …

RAG系统是一个不同步骤的概念。为了优化性能和响应时间，我们需要知道瓶颈在哪里。这就是为什么我们监控这些步骤，这样我们就可以发挥最大的作用。

总结

没有明确的道路可走。这是一个反复试验的过程。与任何其他数据科学用例一样，我们有一组特定的工具，我们可以使用它们来尝试找到解决我们特定问题的方法。

这就是这些项目的乐趣所在。如果有一本静态的指南可以遵循，那不是很无聊吗?

最后的最后

感谢你们的阅读和喜欢，我收藏了很多技术干货，可以共享给喜欢我文章的朋友们，如果你肯花时间沉下心去学习，它们一定能帮到你。

因为这个行业不同于其他行业，知识体系实在是过于庞大，知识更新也非常快。作为一个普通人，无法全部学完，所以我们在提升技术的时候，首先需要明确一个目标，然后制定好完整的计划，同时找到好的学习方法，这样才能更快的提升自己。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

大模型知识脑图

为了成为更好的 AI大模型 开发者，这里为大家提供了总的路线图。它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

经典书籍阅读

阅读AI大模型经典书籍可以帮助读者提高技术水平，开拓视野，掌握核心技术，提高解决问题的能力，同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说，阅读经典书籍是非常有必要的。

实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

面试资料

我们学习AI大模型必然是想找到高薪的工作，下面这些面试题都是总结当前最新、最热、最高频的面试题，并且每道题都有详细的答案，面试前刷完这套面试题资料，小小offer，不在话下

640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】