前言
在大语言模型(LLM)飞速发展的今天,LLMs 正不断地充实和改进我们周边的各种工具和应用。如果说现在基于 LLM 最火热的应用技术是什么,检索增强生成(RAG,Retrieval Augmented Generation)技术必占据重要的一席。RAG 最初是为了解决 LLM 的各类问题的产生的,但后面大家发现在现阶段的很多企业痛点上,使用 RAG 好像是更好的解决方案。在介绍 RAG 之前,我们先来看一下现在 LLM 存在的问题。
LLM 的问题
尽管 LLM 拥有令人印象深刻的能力,但是它们还面临着一些问题和挑战:
- 幻觉问题:大模型的底层原理是基于概率,在没有答案的情况下经常会胡说八道,提供虚假信息。这会导致用户信任度下降,甚至在医疗、法律等严谨领域造成严重后果。
- 时效性问题:规模越大(参数越多、tokens 越多),大模型训练的成本越高。类似 ChatGPT3.5,起初训练数据是截止到 2021 年的,对于之后的事情就不知道了。而且对于一些高时效性的事情,大模型更加无能为力,比如帮我看看今天晚上有什么电影值得去看?这种任务是需要去淘票票、猫眼等网站先去获取最新电影信息的,大模型本身无法完成这个任务。
- 数据安全:OpenAI 已经遭到过几次隐私数据的投诉,而对于企业来说,如果把自己的经营数据、合同文件等机密文件和数据上传到互联网上的大模型,那想想都可怕。既要保证安全,又要借助 AI 能力,那么最好的方式就是把数据全部放在本地,企业数据的业务计算全部在本地完成。而在线的大模型仅仅完成一个归纳的功能,甚至,LLM 都可以完全本地化部署。
解决这些挑战对于 LLMs 在各个领域的有效利用至关重要。一个有效的解决方案是集成检索增强生成(RAG)技术,该技术通过获取外部数据来响应查询来补充模型,从而确保更准确和最新的输出。主要表现方面如下:
- 有效避免幻觉问题:虽然无法 100% 解决大模型的幻觉问题,但通过 RAG 技术能够有效的降低幻觉,在软件系统中结合大模型提供幂等的 API 接口就可以发挥大模型的重大作用。
- 经济高效的处理知识&开箱即用:只需要借助信息检索和向量技术,将用户的问题和知识库进行相关性搜索结合,就能高效的提供大模型不知道的知识,同时具有权威性。
- 数据安全:企业的数据可以得到有效的保护,通过私有化部署基于 RAG 系统开发的 AI 产品,能够在体验 AI 带来的便利性的同时,又能避免企业隐私数据的泄漏。
上图展示了 RAG 如何使 ChatGPT 能够提供超出其初始训练数据的精确答案。
什么是 RAG
说了这么多,下面我们来介绍一下什么是 RAG。
RAG 是检索增强生成(Retrieval Augmented Generation)的简称,它为大语言模型 (LLMs) 提供了从数据源检索信息的能力,并以此为基础生成回答。简而言之,RAG 结合了信息检索技术和大语言模型的提示功能,即模型根据搜索算法找到的信息作为上下文来查询回答问题。无论是查询还是检索的上下文,都会被整合到发给大语言模型的提示中。
RAG 的架构如图中所示。它既不是一个特定的开源代码库,也不是某个特定的应用,是一个开发框架。
完整的 RAG 应用流程主要包含两个阶段:
- 数据准备阶段:(A)数据提取–> (B)分块(Chunking)–> (C)向量化(embedding)–> (D)数据入库
- 检索生成阶段:(1)问题向量化–> (2)根据问题查询匹配数据–> (3)获取索引数据 --> (4)将数据注入 Prompt–> (5)LLM 生成答案
下面让我们展开介绍一下这两个阶段的关键环节。
数据准备阶段
数据准备一般是一个离线的过程,主要是将私有数据向量化后构建索引并存入数据库的过程。主要包括:数据提取、文本分割、向量化、数据入库等环节。
1、数据提取:将 PDF、word、markdown、数据库和 API 等多种格式的数据,进行过滤、压缩、格式化等处理为同一个范式。这一步需要处理不同文档的编码问题,去除无关的页眉页脚或乱码。
2、分块(Chunking):将初始文档分割成一定大小的块,尽量不要失去语义含义。将文本分割成句子或段落,而不是将单个句子分成多部分。有多种文本分割器实现能够完成此任务。比如根据换行、句号、问号、感叹号等切分文本,或者以其他的合适大小的 chunk 为原则进行分割。最终将语料分割成 chunk 块,在检索时会取相关性最高的 top_n。
分块策略的重要性:
- 固定大小分块:简单直接,但可能切断语义。例如按字符数切割,可能导致一句话被截断。
- 递归字符分块:LangChain 提供的
RecursiveCharacterTextSplitter 会尝试按更大的单位(如段落、标题)先切分,再按字符切分,能更好地保留上下文。
- 重叠(Overlap):设置 chunk_overlap 可以保留相邻块之间的重复内容,防止关键信息在边界处丢失。
应用阶段
在应用阶段,根据用户的提问,将提问问题向量化处理,然后通过高效的检索方法,从向量数据库中召回与提问最相关的知识,并融入 Prompt;大模型参考当前提问和相关知识,生成相应的答案。关键环节包括:数据检索、注入 Prompt 等。
1、数据检索
常见的数据检索方法包括:相似性检索、全文检索等。以及可以结合多种检索方式,提升召回率。
- 相似性检索:即计算查询向量与所有存储向量的相似性得分,返回得分高的记录。常见的相似性计算方法包括:余弦相似性、欧氏距离、曼哈顿距离等。余弦相似度是最常用的指标,因为它衡量的是方向而非长度。
- 全文检索:全文检索是一种比较经典的检索方式,在数据存入时,通过关键词构建倒排索引;在检索时,通过关键词进行全文检索,找到对应的记录。BM25 算法是其中一种经典实现。
RAG 文本检索环节中的主流方法是相似性检索(向量检索),即语义相关度匹配的方式。为了进一步提升效果,可以采用混合检索(Hybrid Search),结合向量检索的语义能力和全文检索的精确匹配能力。
2、注入 Prompt
Prompt 作为大模型的直接输入,是影响模型输出准确率的关键因素之一。在 RAG 场景中,Prompt 一般包括任务描述、背景知识(检索得到)、任务指令(一般是用户提问)等,根据任务场景和大模型性能,也可以在 Prompt 中适当加入其他指令优化大模型的输出。一个简单知识问答场景的 Prompt 如下所示:
prompt = f"""
Give the answer to the user query delimited by triple backticks ```{query}```\
using the information given in context delimited by triple backticks ```{context}```.\
If there is no relevant information in the provided context, try to answer yourself,
but tell user that you did not have any relevant context to base your answer on.
Be concise and output the answer of size less than 80 tokens.
"""
Prompt 的设计只有方法、没有语法,比较依赖于个人经验,在实际应用过程中,往往需要根据大模型的实际输出进行针对性的 Prompt 调优。建议遵循以下原则:
- 明确角色:告诉模型它是谁(例如:你是专业的客服助手)。
- 提供约束:限制回答的长度、风格或格式。
- Few-Shot 示例:如果可能,提供几个输入输出的例子,帮助模型理解任务模式。
实践示例
那具体 RAG 怎么做呢?我们用一个简单的 LangChain 代码示例来展示 RAG 的使用。
环境准备
安装相关依赖
pip install langchain sentence_transformers chromadb
此外,还需要安装 Python 环境,并确保已配置好虚拟环境以避免包冲突。
本地数据加载
这个例子使用了保罗·格雷厄姆(Paul Graham)的文章 ['What I Worked On'] 文本后,放置到 "./data" 目录下。Langchain 提供了很多文件加载器,包括 word、csv、PDF、GoogleDrive、Youtube 等,使用方法也很简单。这里直接使用 TextLoader 加载 txt 文本。
from langchain.document_loaders import TextLoader
loader = TextLoader("./data/paul_graham_essay.txt")
documents = loader.load()
注意:如果加载 PDF 或 Word 文档,建议使用 PyPDFLoader 或 UnstructuredWordDocumentLoader 以获得更好的解析效果。
文档分割 (split_documents)
文档分割,借助 langchain 的字符分割器。代码中我们指定 chunk_size=500, chunk_overlap=10,这样的意思就是我们每块的文档中是 500 个字符,chunk_overlap 表示字符重复的个数,这样可以避免语义被拆分后不完整。
from langchain.text_splitter import CharacterTextSplitter
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=10)
documents = text_splitter.split_documents(documents)
在实际生产中,建议根据文档的平均段落长度调整 chunk_size。过小的 chunk 会导致上下文缺失,过大的 chunk 会增加检索噪音。
向量化 (embedding)
接下来对分割后的数据进行 embedding,并写入数据库。LangChain 提供了许多嵌入模型的接口,例如 OpenAI、Cohere、Hugging Face、Weaviate 等,请参考 LangChain 官网。这里选用 m3e-base 作为 embedding 模型,这是一个中文效果较好的开源模型,支持本地运行,无需调用 API。
from langchain.embeddings import HuggingFaceBgeEmbeddings
from langchain.vectorstores import Chroma
model_name = "moka-ai/m3e-base"
model_kwargs = {'device': 'cpu'}
encode_kwargs = {'normalize_embeddings': True}
embedding = HuggingFaceBgeEmbeddings(
model_name=model_name,
model_kwargs=model_kwargs,
encode_kwargs=encode_kwargs
)
选择 Embedding 模型时,需考虑维度大小、推理速度、支持的语言以及对特定领域的适配性。
数据入库
将嵌入后的结果存储在 VectorDB 中,常见的 VectorDB 包括 Chroma、weaviate 和 FAISS 等,这里使用 Chroma 来实现。Chroma 与 LangChain 整合得很好,可以直接使用 LangChain 的接口进行操作,且支持持久化存储。
persist_directory = 'db'
db = Chroma.from_documents(documents, embedding, persist_directory=persist_directory)
Chroma 适合轻量级应用和原型开发。对于大规模生产环境,可以考虑 Milvus 或 Pinecone 等分布式向量数据库。
检索 (Retrieve)
向量数据库被填充后,可以将其定义为检索器组件,该组件根据用户查询与嵌入式块之间的语义相似性获取附加上下文。
retriever = db.as_retriever()
可以通过设置 search_kwargs 来控制返回的文档数量(k 值)和搜索类型(similarity vs mmr)。MMR(最大边际相关性)可以在保证相关性的同时增加结果的多样性。
增强 (Augment)
接下来,为了将附加上下文与提示一起使用,需要准备一个提示模板。如下所示,可以轻松地从提示模板自定义提示。
from langchain.prompts import ChatPromptTemplate
template = """You are an assistant for question-answering tasks.
Use the following pieces of retrieved context to answer the question.
If you don't know the answer, just say that you don't know.
Use three sentences maximum and keep the answer concise.
Question: {question}
Context: {context}
Answer:
"""
prompt = ChatPromptTemplate.from_template(template)
生成 (Generate)
最后,可以构建一个 RAG 流水线的链,将检索器、提示模板和 LLM 连接在一起。一旦定义了 RAG 链,就可以调用它。本地通过 ollama 运行的 llama3 来作为 LLM 使用。如果不了解本地 ollama 部署模型的流程,可以参考官方文档。
from langchain_community.chat_models import ChatOllama
from langchain.schema.runnable import RunnablePassthrough
from langchain.schema.output_parser import StrOutputParser
llm = ChatOllama(model='llama3')
rag_chain = (
{"context": retriever, "question": RunnablePassthrough()}
| prompt
| llm
| StrOutputParser()
)
query = "What did the author do growing up?"
response = rag_chain.invoke(query)
print(response)
我这里的本地 llama3 环境下,输出为:
Before college, Paul Graham worked on writing and programming outside of school. He didn
从这个输出中,可以看到已经将我们提供的文本中的相关信息检索出来,并由 LLM 总结回答我们的问题了。
RAG 与微调
上面都是介绍的 RAG,在这里顺便对比一下微调(Fine-tuning)。在大语言模型的优化措施中,RAG 和微调都是一种重要的技术。
可以把 RAG 想象成给模型提供一本参考书,让它根据问题去查找信息然后回答问题。这种方法适用于模型需要解答具体问题或执行特定信息检索任务的情况。但 RAG 并不适合于教会模型理解广泛的领域或学习新的语言、格式或风格。
而微调更像是让学生通过广泛学习来吸收知识。当模型需要模仿特定的结构、风格或格式时,微调就显得非常有用。它可以提高未经微调的模型的表现,使交互更加高效。
微调特别适用于强化模型已有的知识、调整或定制模型的输出,以及给模型下达复杂的指令。然而,微调并不适合于向模型中添加新的知识,或者在需要快速迭代新场景的情况下使用。
RAG 和微调可以相互补充,而非相互排斥,从而在不同层次上增强模型的能力。在特定情况下,结合这两种方法可以达到模型性能的最佳状态。
还有一个形象的对比来介绍 RAG 和微调,RAG 就相当于是开卷考试,考试的时候可以翻书,可以随时翻到某一页来查找对应的知识点去回答。微调相当于你一整个学期的学习,并在考试前进行了重点复习和记忆,考试时,凭借自己巩固的知识去答题。
常见陷阱与优化建议
在实际落地 RAG 项目时,开发者常遇到以下问题:
- 检索不准:如果检索到的内容与问题不相关,生成的答案也会偏离。优化方法包括改进 Embedding 模型、调整 Chunk 大小、引入重排序(Re-ranking)机制。
- 上下文过长:检索到的内容过多会超出 LLM 的 Context Window 限制。应限制返回的 Top-K 数量,或使用摘要技术压缩上下文。
- 延迟问题:向量检索和 LLM 生成都需要时间。可通过缓存常用查询结果、使用更快的向量数据库或模型量化来优化响应速度。
- 评估困难:如何衡量 RAG 系统的效果?可以使用 RAGAS 等框架,从忠实度、答案相关性、上下文相关性等维度进行自动化评估。
总结
本文列举了 LLM 的问题。简单介绍了什么是 RAG,以及 RAG 的流程。最后使用了一个简单的 LangChain 代码示例来展示 RAG 的使用。最后对比了 RAG 和微调的区别,方便大家选型。通过合理设计数据管道和 Prompt 工程,RAG 能够显著提升大模型在企业场景中的实用性和准确性。