1. 什么是RAG

RAG的概念最先在2020年由Facebook的研究人员在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出来。在这篇论文中他们提出了两种记忆类型：

基于预训练模型（当时LLM的概念不像现在这么如日中天，但LLM也可以被归类为预训练模型）的参数型记忆；
基于向量的非参数型记忆。

RAG技术将这两种记忆类型进行了整合，最终，在知识密集型的NLP任务上，比如QA，比单独使用上述两种类型的记忆获得了更好的效果。接下来将具体介绍RAG如何来补充LLM的一些短板，以及在两种记忆的具体体现，并使用LangChain来实现基本RAG流程。

2. LLM面临的挑战和RAG带来的好处

目前来看，LLM是几乎是解决各个任务的最佳解决方案。在通用聊天这一领域，很多大模型都能够实现接近人类的水平表现。但它的表现也不是完美，也存在着诸多不足：

在没有答案的情况下提供虚假的信息（幻觉）；
在专业领域表现不足，无法给出回答，这和大模型使用的训练数据息息相关，很多领域的数据是相对粉封闭的；
对于同样的问题可能会产生不同的回答，这在对问题答案稳定性要求高的领域是不能接受的；
无法感知不断变化的知识。

可以把大模型比做一个刚毕业找到工作的大学生，他具备了很多通识性的知识，但对组织内部的专业知识知之甚少，因此需要尽快掌握组织内部的领域知识，可以让资深员工手把手的传输知识，也可以通过阅读组织内的文档吸收知识。与此类似，RAG通过问题匹配知识，并将知识带给大模型，再利用大模型出色的生成能力来回答问题，这样大模型这个"新人"就能变得专业，也能感知到不断变化的外部信息。

3. LangChain的RAG实践

在本节，我们将重点利用LangChain框架来进行RAG实践

3.1 RAG架构

典型的RAG架构与搜索引擎的架构类型，分为离线和在线部分，其中离线部分是对数据进行索引，这里的索引和传统的搜索引擎的倒排索引不同，这里的索引是对数据的向量化，如图（来自LangChain官网）

从图中我们可以清晰的看到，在离线索引阶段，总共有4个主要的步骤：

加载内容，非结构化数据通常需要提取内容，比如从word文档、pdf文档中提取文本内容；
内容分块，将提取的内容进一步切分为小块（chunk），这样在匹配问题时可以将上下文缩减到很小；
对于每个分块的内容获取其向量（embedding），这个获取向量的过程可以借助大模型本身的能力来实现，例如，gpt就提供了embedding的接口；
存储向量，将获取的向量通过向量数据库存储起来，方便查询。

这里最终存储的结果就是论文中提出的基于向量的非参数化的记忆。接下来我们再来看在线（检索和生成）的部分，如图（来自LangChain官网）

在Question到大模型这条链路中，增加了Retrieve这个步骤。用户的问题被embedding后，会在向量库中匹配出最佳的内容，并和用户的问题一起，构成Prompt交给大模型，大模型根据这个Prompt再生成对应的答案返回给用户。除了第二节中提到的RAG带来的好处，这里还有一个工程层面的优势，通过Retrieve找到与问题最相关的知识，从而减少了上下文，压缩了Prompt的token数量。

上面两部分构成了RAG的基本架构，下面我们将使用LangChain来完整的实现一个RAG原型。

3.2 基于LangChain的RAG实现

为了方便我们对比效果，我们首先先实现一个直接将问题抛给大模型的流程，代码如下：

ini 复制代码

from langchain_community.llms import LlamaCpp
# 加载本地模型文件地址，使用mixtral-8*7B的大模型
model_home = "～/models/mixtral-8x7b-instruct-v0.1.Q8_0.gguf"
# 使用llm_model作为加载框架
llm_model = LlamaCpp(model_path=model_home)
prompt = "孙悟空几打白骨精？"
print(llm_model.invoke(prompt))

这里，我使用的是本地的大模型mixtral-8X7B-instruct 8位量化的版本，通过LlamaCpp框架进行加载。模型输出的答案为

erlang 复制代码

孙悟空与白骨精的第一次较量是在《西游记》第六回中发生的，这是在孙悟空带着猪八戒、沙和尚前来拜访时，白骨精就偷偷地上前来欺诈孙悟空和他的同伴们。当时，白骨精就利用孙悟空和他的同伴们对于自己还不知道的身份感到的好奇心进行了诱饵计 stratagem.

当时，孙悟空和他的同伴们都没有想到白骨精会是一个女妖的存在，所以他们都被白骨精诱饵计 seduction stratagem给骗了过来，而在此期间，孙悟空和他的同伴们都没有意识到到底是谁在利用他们的

可以看到，模型给出的答案，并不尽如人意。首先，"三打白骨精"这个故事并不是在原文第六回发生的，其次，给的答案并没有准确的回复"几打"这个问题。即便是ChatGPT 3.5 也无法回答这样的问题。

我们尝试用RAG来解决这个问题。基于RAG的流程和架构，我们除了依赖大模型，还需要依赖一个用于向量存储和查询的引擎，为了方便，直接follow官方的样例，使用Chroma。

对于非参数化记忆，我先后选择了目录、《三打白骨精》这章内容和《三打白骨精》概要。

下面的代码实现了RAG的离线过程：

ini 复制代码

from langchain_community.document_loaders import DirectoryLoader
from langchain_community.embeddings import LlamaCppEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma

# 使用DirectoryLoader 加载文件，作为外部知识
loader = DirectoryLoader('/Users/trent/dev/data/rag', glob="**/*.txt")
docs = loader.load()
text_splitter = RecursiveCharacterTextSplitter(chunk_size=256, chunk_overlap=200)
splits = text_splitter.split_documents(docs)
embeddings = LlamaCppEmbeddings(model_path=model_home)
vectorstore = Chroma.from_documents(documents=splits, embedding=embeddings)

下面的代码实现了RAG的在线过程：

python 复制代码

import os
from langchain import hub
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

# 可以在LangSimth生成一个API key用于整个RAG链路的追踪
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "langSimth_api_key"

# 将向量存储作为retriever
retriever = vectorstore.as_retriever()
# 从[LangSmith Hub](https://smith.langchain.com/hub)拉取promt的模版
prompt = hub.pull("rlm/rag-prompt")

def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm_model
    | StrOutputParser()
)

我们以RAG的形式再次进行提问：

arduino 复制代码

rag_chain.invoke("孙悟空几打白骨精?")

非参数化记忆的不同，得到的答案也不尽相同，对于这个问题，概要作为非参数化记忆，得到的答案最为准确。下面是LangSmith中对利用三个外部文件进行试验的结果。

这里要推荐一下LangSmith这个可观测性组件，可以清晰的追踪到RAG的流程，以下图为例，既可以看到一次Q&A的全过程，又可以观测到Retriever的输入输出。

以上就是用LangChain实现的一个简单RAG流程。

Retriever这个组件的引入可以有效的增强LLM的能力，但也会带来新的挑战：

外部的知识如何选择，不同的外部知识会带来不一样的效果表现，这就要具体问题具体分析了；
外部的知识如何进行处理，chunk如何切分，chunk size如何设置等等；
提问的模板如何设置，好的提问模板可以充分利用LLM的能力，从工程上来讲，Context的长度也需要尽可能的精简。

这些问题，需要在具体的场景中进行具体的分析，同时也需要有合适的机制通过不断的反馈来积累最佳实践。