外贸网站需要多少个语言培训课程设计

3.检索增强生成 (Retrieval-Augmented Generation (RAG))

LLM 的大规模应用很快导致人们向它们提问，并期望得到符合实际的答案。虽然这些模型可以正确回答一些问题，但它们也自信地回答了许多错误的问题。为了纠正这种行为，业界转而采用的主要方法是 RAG，该方法在论文 “针对知识密集型 NLP 任务的检索-增强生成”（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks）（2020 年）1 中有所描述，如图 8-24 所示。

图 8-24. 一个基本的 RAG 流水线由搜索步骤和基础生成步骤组成，在基础生成步骤中，LLM 会收到提示词和从搜索步骤中检索到的信息的融合信息

RAG 系统除了生成功能外，还具有搜索功能。它们可以被看作是对生成系统的改进，因为它们减少了生成系统的幻觉，提高了生成系统的真实性。它们还支持 “与我的数据聊天 ”的使用案例，消费者和公司可以利用这些案例将 LLM 建立在公司内部数据或感兴趣的特定数据源上（例如，与一本书聊天）。

这也延伸到了搜索系统。越来越多的搜索引擎开始采用 LLM 来总结搜索结果或回答提交给搜索引擎的问题。例如 Perplexity、微软必应人工智能和谷歌双子星。

从搜索到 RAG

现在，让我们把搜索系统变成一个 RAG 系统。为此，我们在搜索管道的末端添加了一个 LLM。我们向 LLM 提出问题和检索到的热门文档，并要求它根据搜索结果提供的上下文回答问题。我们可以从图 8-25 中看到一个例子。

这个生成步骤被称为 “有基础的生成”（grounded generation），因为我们向 LLM 提供的检索到的相关信息建立了一定的上下文，使 LLM 在我们感兴趣的领域内有了基础。如果我们继续前面的嵌入式搜索示例，图 8-26 显示了搜索后如何进行基础内容生成。

图 8-25. 生成式搜索在搜索管道的末端生成答案和摘要，同时注明其来源（由搜索系统的前几个步骤返回）

图 8-26. 通过比较嵌入之间的相似性，找出与输入提示最相关的信息。最相关的信息会被添加到提示中，然后再交给 LLM

示例： 使用 LLM 应用程序API进行基础生成

让我们来看看如何在搜索结果后添加一个基础生成步骤，以创建我们的第一个 RAG 系统。在本例中，我们将使用 Cohere 的托管 LLM，它建立在本章前面介绍的搜索系统基础之上。我们将使用嵌入式搜索来检索热门文档，然后将这些文档和问题一起传递给 co.chat 端点，以提供一个基础生成的答案：

query = "income generated"
# 1- Retrieval
# We'll use embedding search. But ideally we'd do hybrid
results = search(query)
# 2- Grounded Generation
docs_dict = [{'text': text} for text in results['texts']]
response = co.chat(message = query,documents=docs_dict
)
print(response.text)

The film generated a worldwide gross of over $677 million, or
$773 million with subsequent re-releases.

我们突出显示部分文本，是因为模型显示这些文本的来源是我们传入的第一个文档：

citations=[ChatCitation(start=21, end=36, text='worldwide gross', document_ids=['doc_0']), ChatCitation(start=40, end=57,text='over $677 million', document_ids=['doc_0']), ChatCitation(start=62, end=103, text='$773 million with subsequent re-releases.', document_ids=['doc_0'])]documents=[{'id': 'doc_0', 'text': 'The film had a worldwide gross over $677 million (and $773 million with subsequent rereleases), making it the tenth-highest grossing film of 2014'}]

示例： 基于本地模型的 RAG

现在让我们用本地模型来复制这一基本功能。我们将失去进行跨度引用的能力，而且较小的本地模型也不会像较大的托管模型那样好用，但这对演示流程很有用。我们先下载一个量化模型。

加载生成模型

我们先现在一个生成模型：

!wget https://huggingface.co/microsoft/Phi-3-mini-4k-instructgguf/
resolve/main/Phi-3-mini-4k-instruct-fp16.gguf

使用llama.cpp, llama-cpp-python，和LangChain来加载文本生成模型：

from langchain import LlamaCpp
# Make sure the model path is correct for your system!
llm = LlamaCpp(model_path="Phi-3-mini-4k-instruct-fp16.gguf",n_gpu_layers=-1,max_tokens=500,n_ctx=2048,seed=42,verbose=False
)

加载嵌入模型（embedding model）

现在让我们加载一个嵌入语言模型（embedding language model）。在本例中，我们将选择 BAAI/bge-small-en-v1.5 模型。在撰写本文时，它在嵌入式模型的 MTEB 排行榜上名列前茅，而且体积相对较小：

from langchain.embeddings.huggingface import HuggingFaceEmbeddings# Embedding model for converting text to numerical
representations
embedding_model = HuggingFaceEmbeddings(model_name='thenlper/gte-small'
)

现在，我们可以使用嵌入模型来建立向量数据库：

from langchain.vectorstores import FAISS
# Create a local vector database
db = FAISS.from_texts(texts, embedding_model)

RAG提示词（The RAG prompt）

提示模板在 RAG 流程中起着至关重要的作用。它是我们向 LLM 传递相关文档的核心场所。为此，我们将创建一个名为 context 的额外输入变量，用于向 LLM 提供检索到的文档：

from langchain import PromptTemplate# Create a prompt template
template = """<|user|>
Relevant information:
{context}
Provide a concise answer the following question using the
relevant information provided above:
{question}<|end|>
<|assistant|>"""prompt = PromptTemplate(template=template,input_variables=["context", "question"]
)from langchain.chains import RetrievalQA# RAG pipeline
rag = RetrievalQA.from_chain_type(llm=llm,chain_type='stuff',retriever=db.as_retriever(),chain_type_kwargs={"prompt": prompt},verbose=True
)

现在我们准备调用模型，并问它问题：

rag.invoke('Income generated')

输出结果：

The Income generated by the film in 2014 was over $677 million worldwide. This made it the tenth-highest grossing film of that year. It should be noted, however, this figure includes both initial ticket sales as well as any subsequent re-releases.

With these additional releases, total earnings surged to approximately $773 million. The release format transitioned from traditional film stock projection in theaters to digital projectors once it was expanded to various venues in the United States. This shift might have contributed to wider audience reach and potentially higher grossing figures over time.

However, specific data on how this affected total earnings isn’t provided in the information above.

和之前一样，我们可以调整提示来控制模型的生成（例如，答案长度和语气（answer length and tone)））。

高级 RAG 技术

还有几种技术可以提高 RAG 系统的性能。在此介绍其中一些。

查询重写（Query rewriting）

如果 RAG 系统是一个聊天机器人，那么如果问题过于冗长，或者需要参考对话中先前信息的上下文，前面的简单 RAG 实现在搜索步骤中可能会很吃力。这就是为什么使用 LLM 将查询重写为有助于检索步骤获得正确信息的查询是个好主意。下面的信息就是一个例子：

User Question: “We have an essay due tomorrow. We have to write about some animal. I love penguins. I could write about them. But I could also write about dolphins. Are they animals? Maybe. Let’s do dolphins. Where do they live for example?”

用户问题： “我们明天要交一篇作文。我们必须写一些动物。我喜欢企鹅。我可以写企鹅。但我也可以写海豚。它们是动物吗？也许吧 那就写海豚吧。比如说，它们生活在哪里？”

实际上，这句话应该改写成这样的疑问句：

Query: “Where do dolphins live”

查询：“海豚生活在哪里？”

这种重写行为可以通过提示（或 API 调用）完成。例如，Cohere 的 API 就为 co.chat 提供了专门的查询重写模式。

多查询 RAG（Multi-query RAG）

我们可以引入的下一个改进是扩展查询重写，以便在需要多个查询来回答特定问题时，能够搜索多个查询。举个例子：

User Question: “Compare the financial results of Nvidia in 2020 vs. 2023”

用户提问：“比较 2020 年与 2023 年 Nvidia 的财务业绩”

我们可能会找到一个包含两年结果的文档，但更有可能的是，我们最好进行两次搜索查询：

Query 1: “Nvidia 2020 financial results”
Query 2: “Nvidia 2023 financial results”

查询 1：“Nvidia 2020 财报”

查询 2："Nvidia 2023 财报”

然后，我们将这两个查询的顶层结果（top results）提交给模型，以便生成有依据的答案。这里还有一个小改进，就是：让查询重写器（query rewriter）可以决定是否不需要搜索，以及是否可以不搜索直接生成有把握的答案。

多跳 RAG（Multi-hop RAG）

更高级的问题可能需要一系列连续查询。举个例子：

User Question: “Who are the largest car manufacturers in 2023? Do they each make EVs or not?”

用户问题： “2023年最大的汽车制造商是谁？他们是否都生产电动汽车？”

要回答这个问题，系统必须首先搜索：

Step 1, Query 1: “largest car manufacturers 2023”

步骤 1，查询 1：“2023 年最大的汽车制造商”

然后在获得这些信息后（结果是丰田、大众和现代），系统应提出后续问题：

第 2 步，查询 1：“丰田汽车公司电动汽车”

第 2 步，查询 2：“大众汽车公司电动汽车”

第 2 步，查询 3：“现代汽车公司电动汽车”。

查询路由（Query routing）

另一项改进是：赋予模型搜索多个数据源的能力。例如，我们可以为模型指定，如果它收到有关人力资源的问题，它应该搜索公司的人力资源信息系统（如 Notion），但如果问题是有关客户数据的，它应该搜索客户关系管理（CRM）（如 Salesforce）。

智能体RAG（Agentic RAG）

现在，您可能已经看到，以前的增强功能列表慢慢地将越来越多的责任交给了 LLM，以解决越来越复杂的问题。这有赖于 LLM 衡量所需信息需求的能力以及利用多种数据源的能力。LLM 的这种新特性开始变得越来越接近于一个作用于世界的智能体。数据源现在也可以抽象为工具。例如，我们看到我们可以搜索 Notion，但同样，我们也应该能够向 Notion 发布信息。

并非所有 LLM 都具备这里提到的 RAG 功能。在撰写本文时，可能只有最大的托管模型才能尝试这种行为。值得庆幸的是，Cohere 的 Command R+ 在这些任务中表现出色，而且还可以作为开放权重模型使用。

RAG评估（RAG Evaluation）

在如何评估 RAG 模型方面仍在不断发展。关于这一主题的一篇优秀论文是《评估生成式搜索引擎的可验证性》（2023 年），该论文对不同的生成式搜索系统进行了人工评估：

它根据四个方面来评估结果：

• 流畅性

  生成的文本是否流畅、连贯。

• 感知效用（Perceived utility）

  生成的答案是否有用，是否能提供信息。

• 引文召回率（Citation recall）

  生成的关于外部世界的陈述中完全得到引文支持的比例。

• 引文精确度（Citation precision）

  生成的引文中支持其相关陈述的比例。

虽然人工评估始终是首选，但也有一些方法试图通过让有能力的 LLM 担任评委（称为 LLM-as-a-judge），并沿着不同的轴对不同的世代进行评分，从而实现这些评估的自动化。Ragas 软件库正是这样做的。它还能对一些额外的有用指标进行评分，例如

• 忠实性

  答案是否与所提供的上下文一致

• 答案相关性

  答案与问题的相关性如何

Ragas文档网站提供了有关实际计算这些指标的公式的更多详细信息。

4. 总结

在本章中，我们探讨了使用语言模型改进现有搜索系统，甚至成为更强大的新搜索系统核心的不同方法。这些方法包括

• 密集检索，它依赖于文本嵌入的相似性。这些系统会嵌入搜索查询，并检索与查询嵌入最接近的文档。
• 重排系统（如：monoBERT），它可以查看查询和候选结果，并对每个文档与该查询的相关性进行评分。然后利用这些相关性得分，根据与查询的相关性对入围结果进行排序，通常会产生更好的结果排名。
• RAG，即搜索系统在管道末端有一个生成式 LLM，根据检索到的文档制定答案，同时引用来源。

我们还研究了评估搜索系统的一种可能方法。平均精确度允许我们对搜索系统进行评分，以便能够在一套测试查询及其与测试查询的已知相关性之间进行比较。不过，评估 RAG 系统需要多个维度，如忠实度、流畅度等，这些维度可以由人工或 LLM 即评委来评估。

在下一章中，我们将探讨如何使语言模型具有多模态性，不仅能对文本进行推理，还能对图像进行推理。

参考资料

1. Patrick Lewis et al. “Retrieval-augmented generation for knowledge-intensive NLP tasks.” Advances in Neural Information Processing Systems 33 (2020): 9459–9474.
2. Nelson F. Liu, Tianyi Zhang, and Percy Liang. “Evaluating verifiability in generative search engines.” arXiv preprint arXiv:2304.09848 (2023).