LLMs面试八股——RAG - LH的个人博客

1 什么是RAG

1.1 初识RAG

RAG（Retrieval Augmented Generation）为生成式模型提供了与外部世界互动的很有前景的解决方案

RAG主要作用类似于搜索引擎，找到和用户提问最相关的知识或者对话历史，结合原始提问（查询），创造信息丰富的prompt，指导模型生成准确输出。

本质上是In-Context learning的原理

RAG可以减少模型的幻觉

简单来说，RAG = 检索技术+LLM提示

1.2 RAG特点

依赖大模型进行强化信息检索和输出

能与外部数据集有效集成

数据隐私和安全保障

表现效果因多方面因素而异常

2 RAG技术体系的总体思路

RAG可分为5个基本流程：知识文档的准备；嵌入模型嵌入模型（embedding model）；向量数据库；查询检索和生产回答。下面会对每个环节进行详细描述：

2.1 知识文档的准备

在构建一个高效的RAG系统时，首要步骤是准备知识文档。现实场景中，我们面对的知识源可能包括多种格式，如Word文档、TXT文件、CSV数据表、Excel表格，甚至是PDF文件、图片和视频等。因此，第一步需要使用专门的文档加载器（例如PDF提取器）或多模态模型（如OCR技术），将这些丰富的知识源转换为大语言模型可理解的纯文本数据。例如，处理PDF文件时，可以利用PDF提取器抽取文本内容；对于图片和视频，OCR技术能够识别并转换其中的文字信息。此外，鉴于文档可能存在过长的问题，我们还需执行一项关键步骤：文档切片。我们需要将长篇文档分割成多个文本块，以便更高效地处理和检索信息。这不仅有助于减轻模型的负担，还能提高信息检索的准确性。我们将在后文中详细讨论文档切片和其背后的逻辑。

2.2 嵌入模型

嵌入模型的核心任务是将文本转换为向量形式，我们使用的日常语言中充满歧义和对表达词意无用的助词，而向量表示则更加密集、精确，能够捕捉到句子的上下文关系和核心含义。这种转换使得我们能够通过简单计算向量之间的差异来识别语义上相似的句子。

嵌入模型可以是Word2Vec，还可以是高级的BERT、GPT等，它们通过更复杂的网络结构捕捉更深层次的语义关系。总之嵌入模型是连接用户查询和知识库的桥梁，确保了系统回答的准确性和相关性。

2.3 向量数据库

顾名思义，向量数据库是专门设计用于存储和检索向量数据的数据库系统。在RAG系统中，通过嵌入模型生成的所有向量都会被存储在这样的数据库中。这种数据库优化了处理和存储大规模向量数据的效率，使得在面对海量知识向量时，我们能够迅速检索出与用户查询最相关的信息。

2.4 查询检索

再经过上述几个步骤的准备后，我们就可以开始进行处理用户查询了。首先，用户的问题会被输入到嵌入模型中进行向量化处理。然后，系统会在向量数据库中搜索与该问题向量语义上相似的知识文本或历史对话记录并返回。

2.5 生成回答

最终将用户提问和上一步中检索到的信息结合，构建出一个提示模版，输入到大语言模型中，静待模型输出答案即可。

3 如何评价RAG项目效果好坏

3.1 检索环节的评估

MRR平均倒数排名：查询的排名的倒数。比如，查询完之后，第一个相关的结果在用户查询的相应里排名为2，则得分为1/2

MRR值越高，表示系统对用户的响应越好，因为第一个相关结果更可能出现在较高的排名位置。

MRR衡量的是相关结果在查询结果中首次出现的位置，适用于多结果排序任务

Hits Rate命中率：前k项中，包含正确信息的数目占比
NDCG

两个思想：

高关联度的结果比一般关联度的结果更影响最终的指标得分

有高关联度的结果出现在更靠前的位置的时候，指标会越高

计算方式：

相关性评分：

真实评分（ground truth relevance）：[3, 2, 3, 0, 1, 2]
系统返回的排序索引顺序为：[2, 0, 1, 5, 4, 3]
→ 也就是输出的顺序是：[3, 3, 2, 2, 1, 0]

计算DCG：

\[\mathrm{DCG}p=rel_1+\sum i=2^p\frac{rel_i}{\log_2(i+1)}\]即

\[\mathrm{DCG}_6=3+\frac{3}{\log_2(3)}+\frac{2}{\log_2(4)}+\frac{2}{\log_2(5)}+\frac{1}{\log_2(6)}+\frac{0}{\log_2(7)}\]

计算IDCG（ideal DCG）

这是“理想情况下的 DCG”——也就是我们把相关性分最高的项放在最前面所得到的 DCG。对真实分数排序得到：[3, 3, 2, 2, 1, 0]，然后用同样方式计算IDCG

计算NDCG：

\[\mathrm{NDCG}=\frac{\mathrm{DCG}}{\mathrm{IDCG}}\]

范围是[0, 1]，1代表完美输出结果排序，越高说明检索的结果越准确。

3.2 生成环节的评估

非量化：完整性、正确性、相关性
量化：Rouge-L，是一种用于评价文本生成质量的指标，通常在自动摘要，机器翻译和文本生成任务中使用，通过最长公共子序列来测量生成文本和参考文本之间的相似性

4 RAG优化策略

4.1 知识文档阶段

4.1.1 数据清洗

高性能RAG系统依赖于准确且清洁的原始知识数据。一方面为了保证数据的准确性，我们需要优化文档读取器和多模态模型。特别是处理如CSV表格等文件时，单纯的文本转换可能会丢失表格原有的结构。因此，我们需引入额外的机制以在文本中恢复表格结构，比如使用分号或其他符号来区分数据。另一方面我们也需要对知识文档做一些基本数据清洗其中可以包括：

基本文本清理：规范文本格式，去除特殊字符和不相关信息。除重复文档或冗余信息。
实体解析：消除实体和术语的歧义以实现一致的引用。例如，将“LLM”、“大语言模型”和“大模型”标准化为通用术语。
文档划分：合理地划分不同主题的文档，不同主题是集中在一处还是分散在多处？如果作为人类都不能轻松地判断出需要查阅哪个文档才能来回答常见的提问，那么检索系统也无法做到。
数据增强：使用同义词、释义甚至其他语言的翻译来增加语料库的多样性。
用户反馈循环：基于现实世界用户的反馈不断更新数据库，标记它们的真实性。
时间敏感数据：对于经常更新的主题，实施一种机制来使过时的文档失效或更新。

4.1.2 分块处理

在RAG系统中，文档需要分割成多个文本块再进行向量嵌入。

在不考虑大模型输入长度限制和成本问题情况下，其目的是在保持语义上的连贯性的同时，尽可能减少嵌入内容中的噪声，从而更有效地找到与用户查询最相关的文档部分。

如果分块太大，可能包含太多不相关的信息，从而降低了检索的准确性。相反，分块太小可能会丢失必要的上下文信息，导致生成的回应缺乏连贯性或深度。

在RAG系统中实施合适的文档分块策略，旨在找到这种平衡，确保信息的完整性和相关性。一般来说，理想的文本块应当在没有周围上下文的情况下对人类来说仍然有意义，这样对语言模型来说也是有意义的

固定大小的分块

这是最简单和直接的方法，我们直接设定块中的字数，并选择块之间是否重复内容。通常，我们会保持块之间的一些重叠，以确保语义上下文不会在块之间丢失。与其他形式的分块相比，固定大小分块简单易用且不需要很多计算资源。

内容分块

顾名思义，根据文档的具体内容进行分块，例如根据标点符号（如句号）分割。或者直接使用更高级的NLTK或者spaCy库提供的句子分割功能。

递归分块（常用）

在大多数情况下推荐的方法。其通过重复地应用分块规则来递归地分解文本。

例如，在langchain中会先通过段落换行符（`\n\n`）进行分割。然后，检查这些块的大小。如果大小不超过一定阈值，则该块被保留。对于大小超过标准的块，使用单换行符（`\n`）再次分割。以此类推，不断根据块大小更新更小的分块规则（如空格，句号）。这种方法可以灵活地调整块的大小。例如，对于文本中的密集信息部分，可能需要更细的分割来捕捉细节；而对于信息较少的部分，则可以使用更大的块。而它的挑战在于，需要制定精细的规则来决定何时和如何分割文本。

从小到大分块

既然小的分块和大的分块各有各的优势，一种更为直接的解决方案是把同一文档进行从大到小所有尺寸的分割，然后把不同大小的分块全部存进向量数据库，并保存每个分块的上下级关系，进行递归搜索。但可想而知，因为我们要存储大量重复的内容，这种方案的缺点就是需要更大的储存空间。

特殊结构分块

针对特定结构化内容的专门分割器。这些分割器特别设计来处理这些类型的文档，以确保正确地保留和理解其结构。langchain提供的特殊分割器包括：Markdown文件，Latex文件，以及各种主流代码语言分割器。

分块大小的选择

上述方法中无一例外最终都需要设定一个参数——块的大小，那么我们如何选择呢？

首先不同的嵌入模型有其最佳输入大小。比如Openai的text-embedding-ada-002的模型在256 或 512大小的块上效果更好。其次，文档的类型和用户查询的长度及复杂性也是决定分块大小的重要因素。处理长篇文章或书籍时，较大的分块有助于保留更多的上下文和主题连贯性；而对于社交媒体帖子，较小的分块可能更适合捕捉每个帖子的精确语义。如果用户的查询通常是简短和具体的，较小的分块可能更为合适；相反，如果查询较为复杂，可能需要更大的分块。

实际场景中，我们可能还是需要不断实验调整，在一些测试中，128大小的分块往往是最佳选择，在无从下手时，可以从这个大小作为起点进行测试。

4.2 嵌入模型阶段

我们提到过嵌入模型能帮助我们把文本转换成向量，显然不同的嵌入模型带来的效果也不尽相同，例如，我们之前讨论的Word2Vec模型，尽管功能强大，但存在一个重要的局限性：其生成的词向量是静态的。一旦模型训练完成，每个词的向量表示就固定不变，这在处理一词多义的情况时可能导致问题。

比如， “我买了一张光盘”，这里“光盘”指的是具体的圆形盘片，而在“光盘行动”中，“光盘”则指的是把餐盘里的食物吃光，是一种倡导节约的行为。语义完全不一样的词向量却是固定的。相比之下，引入自注意力机制的模型，如BERT，能够提供动态的词义理解。这意味着它可以根据上下文动态地调整词义，使得同一个词在不同语境下有不同的向量表示。在之前的例子中，“光盘”这个词在两个句子中会有不同的向量，从而更准确地捕捉其语义。

有些项目为了让模型对特定垂直领域的词汇有更好的理解，会嵌入模型进行微调。但在这里我们并不推荐这种方法，一方面其对训练数据的质量有较高要求，另一方面也需要较多的人力物力投入，且效果未必理想，最终得不偿失。在这种情况下，对于具体应该如何选择嵌入模型，我们推荐参考Hugging Face推出的嵌入模型排行榜MTEB。这个排行榜提供了多种模型的性能比较，能帮助我们做出更明智的选择。同时，要注意并非所有嵌入模型都支持中文，因此在选择时应查阅模型说明。

4.3 向量数据库阶段

4.3.1 元数据

当在向量数据库中存储向量数据时，某些数据库支持将向量与元数据（即非向量化的数据）一同存储。为向量添加元数据标注是一种提高检索效率的有效策略，它在处理搜索结果时发挥着重要作用。

例如，日期就是一种常见的元数据标签。它能够帮助我们根据时间顺序进行筛选。设想一下，如果我们正在开发一款允许用户查询他们电子邮件历史记录的应用程序。在这种情况下，日期最近的电子邮件可能与用户的查询更相关。然而，从嵌入的角度来看，我们无法直接判断这些邮件与用户查询的相似度。通过将每封电子邮件的日期作为元数据附加到其嵌入中，我们可以在检索过程中优先考虑最近日期的邮件，从而提高搜索结果的相关性。

此外，我们还可以添加诸如章节或小节的引用，文本的关键信息、小节标题或关键词等作为元数据。这些元数据不仅有助于改进知识检索的准确性，还能为最终用户提供更加丰富和精确的搜索体验。

4.4 查询索引阶段（检索找回、重排）

4.4.1 多级索引（如何制作索引）

元数据无法充分区分不同上下文类型的情况下，我们可以考虑进一步尝试多重索引技术。多重索引技术的核心思想是将庞大的数据和信息需求按类别划分，并在不同层级中组织，以实现更有效的管理和检索。这意味着系统不仅依赖于单一索引，而是建立了多个针对不同数据类型和查询需求的索引。例如，可能有一个索引专门处理摘要类问题，另一个专门应对直接寻求具体答案的问题，还有一个专门针对需要考虑时间因素的问题。这种多重索引策略使RAG系统能够根据查询的性质和上下文，选择最合适的索引进行数据检索，从而提升检索质量和响应速度。但为了引入多重索引技术，我们还需配套加入多级路由机制。

多级路由机制确保每个查询被高效引导至最合适的索引。查询根据其特点（如复杂性、所需信息类型等）被路由至一个或多个特定索引。这不仅提升了处理效率，还优化了资源分配和使用，确保了对各类查询的精确匹配。

例如，对于查询“最新上映的科幻电影推荐”，RAG系统可能首先将其路由至专门处理当前热点话题的索引，然后利用专注于娱乐和影视内容的索引来生成相关推荐。

总的来说，多级索引和路由技术可以进一步帮助我们对大规模数据进行高效处理和精准信息提取，从而提升用户体验和系统的整体性能。

4.4.2 索引/查询算法（如何制作索引）

我们可以利用索引筛选数据，但说到底我们还是要从筛选后的数据中检索出相关的文本向量。由于向量数据量庞大且复杂，寻找绝对的最优解变得计算成本极高，有时甚至是不可行的。加之，大模型本质上并不是完全确定性的系统，这些模型在搜索时追求的是语义上的相似性——一种合理的匹配即可。从应用的角度来看，这种方法是合理的。

例如，在推荐系统中，用户不太可能察觉到或关心是否每个推荐的项目都是绝对的最佳匹配；
他们更关心的是推荐是否总体上与他们的兴趣相符。因此查找与查询向量完全相同的项通常不是目标，而是要找到“足够接近”或“相似”的项，这便是最近邻搜索（Approximate Nearest Neighbor Search，ANNS）。
这样做不仅能满足需求，还为检索优化提供了巨大的优化潜力。下面我们会介绍一些常见的向量搜索算法以便大家在具体使用场景中进行取舍。

4.4.2.1 聚类

当我们在网上购物时，通常不会在所有商品中盲目搜索，而是会选择进入特定的商品分类，比如“电子产品”或“服饰”，在一个更加细分的范畴内寻找心仪的商品。这个能帮我们大大缩小搜索范围。同样这种思路，聚类算法可以帮我们实现这个范围的划定。就比如说我们可以用K-mean算法把向量分为数个簇，当用户进行查询的时候，我们只需找到距离查询向量最近的簇，然后再这个簇中进行搜索。当然聚类的方法并不保证一定正确，如下图，查询距离黄色簇的中心点更近，但实际上距离查询向量最近的，即最相似的点在紫色类。

4.4.2.2 位置敏感哈希

沿着缩小搜索范围的思路，位置敏感哈希算法是另外一种实现的策略。

在传统的哈希算法中，我们通常希望每个输入对应一个唯一的输出值，并努力减少输出值的重复。

然而，在位置敏感哈希算法中，我们的目标恰恰相反，我们需要增加输出值碰撞的概率。

这种碰撞正是分组的关键，哈希值相同的向量将被分配到同一个组中，也就是同一个“桶”里。

此外，这种哈希函数还需满足另一个条件：空间上距离较近的向量更有可能被分入同一个桶。这样在进行搜索时，只需获取目标向量的哈希值，找到相应的桶，并在该桶内进行搜索即可。

4.4.2.3 量化乘积

上面我们介绍了两种牺牲搜索质量来提高搜索速度的方法，但除了搜索速度外，内存开销也是一个巨大挑战。在实际应用场景中，每个向量往往都有上千个维度，数据数量可达上亿。每条数据都对应着一个实际的的信息，因此不可能删除数据来减少内存开销，那唯一的选择只能是把每个数据本身大小缩减。有一种乘积量化的方法可以帮我们完成这点。图像有一种有损压缩的方法是把一个像素周围的几个像素合并，来减少需要储存的信息。同样我们可以在聚类的方法之上改进一下，用每个簇的中心点来代替簇中的数据点。虽然这样我们会丢失向量的具体值信息，但考虑到聚类中心点和簇中向量相关程度，再加上可以不断增加簇的数量来减少信息损失，所以很大程度上我们可以保留原始点的信息。而这样做带来的好处是十分可观的。如果我们给这些中心点编码，我们就可以用单个数字储存一个向量来减少存储的空间。而我们把每个中心向量值和他的编码值记录下来形成一个码本，这样每次使用某个向量的时候，我们只需用他的编码值通过码本找到对应的的中心向量的具体值，虽然这个向量已经不再是当初的样子了，但就像上面所说，问题不大。而这个把向量用其所在的簇中心点表示的过程就是量化。

4.4.2.4 分层导航小世界

从客户的角度来看，内存开销可能并不是最重要的考量因素。他们更加关注的是应用的最终效果，也就是回答用户问题的速度和质量。导航小世界（NSW）算法正是这样一种用内存换取更快速度和更高质量的实现方式。这个算法的思路和“六度分割理论”类似——你和任何一个陌生人之间最多只隔六个人，也就是说，最多通过六个人你就能够认识任何一个陌生人。我们可以将人比作向量点，把搜索过程看作是从一个人找到另一个人的过程。在查询时，我们从一个选定的起始点A开始，然后找到与A相邻且最接近查询向量的点B，导航到B点，再次进行类似的判断，如此反复，直到找到一个点C，其所有相邻节点都没有比它更接近目标。最终这个点C便是我们要找的最相似的向量。

4.4.3 查询轮换（改写用户查询）

在RAG系统中，用户的查询问题被转化为向量，然后在向量数据库中进行匹配。不难想象，查询的措辞会直接影响搜索结果。如果搜索结果不理想，可以尝试以下几种方法对问题进行重写，以提升召回效果：

结合历史对话的重新表述

在向量空间中，对人类来说看似相同的两个问题其向量大小并不一定很相似。我们可以直接利用LLM 重新表述问题来进行尝试。此外，在进行多轮对话时，用户的提问中的某个词可能会指代上文中的部分信息，因此可以将历史信息和用户提问一并交给LLM重新表述

假设文档嵌入

HyDE的核心思想是接收用户提问后，先让LLM在没有外部知识的情况下生成一个假设性的回复。然后，将这个假设性回复和原始查询一起用于向量检索。假设回复可能包含虚假信息，但蕴含着LLM认为相关的信息和文档模式，有助于在知识库中寻找类似的文档。

退后提示（Step Back Prompting）

如果果原始查询太复杂或返回的信息太广泛，我们可以选择生成一个抽象层次更高的“退后”问题，与原始问题一起用于检索，以增加返回结果的数量。例如，原问题是“张三在1954年8-1954年11在哪上学？”，这类比较困难的问题对于LLMs来说很容易答错，而退后问题可能是关于他的“教育历史”。这种更高层次的问题可能更容易找到答案。

多查询检索/多路召回（Multi Query Retrieval）

使用LLM生成多个搜索查询，特别适用于一个问题可能需要依赖多个子问题的情况。

通过这些方法，RAG系统能够更精准地处理和响应复杂的用户查询，从而提升整体的搜索效率和准确性。

4.4.4 高级检索策略（找到相匹配的向量之后，应该返回什么，不应该直接返回直接找到的向量？）

这一块是当找到相匹配的向量之后，怎么返回。

a. 上下文压缩

我们提到过当文档文块过大时，可能包含太多不相关的信息，传递这样的整个文档可能导致更昂贵的LLM调用和更差的响应。上下文压缩的思想就是通过LLM的帮助根据上下文对单个文档内容进行压缩，或者对返回结果进行一定程度的过滤仅返回相关信息。

b. 句子窗口搜索

相反，文档文块太小会导致上下文的缺失。其中一种解决方案就是窗口搜索，该方法的核心思想是当提问匹配好分块后，将该分块周围的块作为上下文一并交给LLM进行输出，来增加LLM对文档上下文的理解。

c. 父文档搜索

无独有偶，父文档搜索也是一种很相似的解决方案，父文档搜索先将文档分为尺寸更大的主文档，再把主文档分割为更短的子文档两个层级，用户问题会与子文档匹配，然后将该子文档所属的主文档和用户提问发送给LLM。

d. 自动合并

自动合并是在父文档搜索上更进一步的复杂解决方案。同样地，我们先对文档进行结构切割，比如将文档按三层树状结构进行切割，顶层节点的块大小为1024，中间层的块大小为512，底层的叶子节点的块大小为128。而在检索时只拿叶子节点和问题进行匹配，当某个父节点下的多数叶子节点都与问题匹配上则将该父节点作为结果返回。

可以看出，bcd的思路都是如何找到搜索到的子文档想上扩展到父文档

e. 多向量检索

多向量检索同样会给一个知识文档转化成多个向量存入数据库，就是对一段文本生成多个表示向量（embeddings），用它们分别参与检索。不同的是，这些向量不仅包括文档在不同大小下的分块，还可以包括该文档的摘要，用户可能提出的问题等等有助于检索的信息。在使用多向量查询的情况下，每个向量可能代表了文档的不同方面，使得系统能够更全面地考虑文档内容，并在回答复杂或多方面的查询时提供更精确的结果。例如，如果查询与文档的某个具体部分或摘要更相关，那么相应的向量就可以帮助提高这部分内容的检索排名。

f. 多代理检索

多代理检索，简而言之就是选取我们提及的12大优化策略中的部分交给一个智能代理合并使用。就比如使用子问题查询，多级索引和多向量查询结合，先让子问题查询代理把用户提问拆解为多个小问题，再让文档代理对每个字问题进行多向量或多索引检索，最后排名代理将所有检索的文档总结再交给LLM。这样做的好处是可以取长补短，比如，子问题查询引擎在探索每个子查询时可能会缺乏深度，尤其是在相互关联或关系数据中。相反，文档代理递归检索在深入研究特定文档和检索详细答案方面表现出色，以此来综合多种方法解决问题。需要注意的是现在网络上存在不同结构的多代理检索，具体在多代理选取哪些优化步骤尚未有确切定论，我们可以结合使用场景进行探索。

g. Self-RAG

自反思搜索增强是一个全新RAG框架

其与传统RAG最大的区别在于通过检索评分（令牌）和反思评分（令牌）来提高质量。

它主要分为三个步骤：检索、生成和批评。

Self-RAG首先用检索评分来评估用户提问是否需要检索，如果需要检索，LLM将调用外部检索模块查找相关文档。
接着，LLM分别为每个检索到的知识块生成答案，
然后为每个答案生成反思评分来评估检索到的各个文档是否相关，将得分最好的答案，当作用户的提问，再输入到Self-RAG里，重复之前步骤，直到模型说可以不用检索了再停止循环，最后将评分高的先前生成的内容结合用户提问一并交给LLM，生成最终答案。

4.4.5 重排策略（找到结果之后重新排序）

在完成语义搜索的优化步骤后，我们能够检索到语义上最相似的文档，但不知你是否注意到一个关键问题：语义最相似是否总代表最相关？答案是不一定。例如，当用户查询“最新上映的科幻电影推荐”时，可能得到的结果是“科幻电影的历史演变”，虽然从语义上这与科幻电影相关，但并未直接回应用户关于最新电影的查询。

重排模型可以帮助我们缓解这个问题，重排模型通过对初始检索结果进行更深入的相关性评估和排序，确保最终展示给用户的结果更加符合其查询意图。这一过程通常由深度学习模型实现，如Cohere模型。这些模型会考虑更多的特征，如查询意图、词汇的多重语义、用户的历史行为和上下文信息等。

举个例子，对于查询“最新上映的科幻电影推荐”，在首次检索阶段，系统可能基于关键词返回包括科幻电影的历史文章、科幻小说介绍、最新电影的新闻等结果。然后，在重排阶段，模型会对这些结果进行深入分析，并将最相关、最符合用户查询意图的结果（如最新上映的科幻电影列表、评论或推荐）排在前面，同时将那些关于科幻电影历史或不太相关的内容排在后面。这样，重排模型就能有效提升检索结果的相关性和准确性，更好地满足用户的需求。

在实践中，使用RAG构建系统时都应考虑尝试重排方法，以评估其是否能够提高系统性能。

4.5 生成回答阶段

4.5.1 提示词

大型语言模型的解码器部分通常基于给定输入来预测下一个词。这意味着设计提示词或问题的方式将直接影响模型预测下一个词的概率。这也给了我们一些启示：通过改变提示词的形式，可以有效地影响模型对不同类型问题的接受程度和回答方式，比如修改提示语，让LLM知道它在做什么工作，是十分有帮助的。

为了减少模型产生主观回答和幻觉的概率，一般情况下，RAG系统中的提示词中应明确指出回答仅基于搜索结果，不要添加任何其他信息例如，可以设置提示词如：

“你是一名智能客服。你的目标是提供准确的信息，并尽可能帮助提问者解决问题。你应保持友善，但不要过于啰嗦。请根据提供的上下文信息，在不考虑已有知识的情况下，回答相关查询。”

当然你也可以根据场景需要，也可以适当让模型的回答融入一些主观性或其对知识的理解。此外，使用少量样本（few-shot）的方法，将想要的问答例子加入提示词中，指导LLM如何利用检索到的知识，也是提升LLM生成内容质量的有效方法。这种方法不仅使模型的回答更加精准，也提高了其在特定情境下的实用性。

4.5.2 大语言模型

终于我们来到最后一步——LLM生成回答。LLM是生成响应的核心组件。与嵌入模型类似，可以根据自己的需求选择LLM，例如开放模型与专有模型、推理成本、上下文长度等。此外，可以使用一些LLM开发框架来搭建RAG系统，比如，LlamaIndex或LangChain。这两个框架都拥有比较好用的debugging工具，可以让我们定义回调函数，查看使用了哪些上下文，检查检索结果来自哪个文档等等。