RAG 知识库实战：基于 LangChain 与 Milvus 构建本地检索系统

现在所有基础模型使用的是 Transformer 的 AI 架构。它将大量原始数据转换为其基本结构的压缩表示形式。这种原始的表示基础模型可以适应各种任务，并对标记的、特定于领域的知识进行一些额外的微调。

不过仅靠微调很少能为模型提供在不断变化的环境中回答高度具体问题所需的全部知识，并且微调的时间周期还比较长。所以科学家们提出了 RAG，让 LLM 能够访问训练数据之外的信息。RAG 允许 LLM 建立在专门的知识体系之上，以更准确的回答问题，减低幻觉的产生。

下面我将介绍如何使用 LangChain + Milvus 向量数据库创建你的本地知识库。

安装 LangChain

使用下面的命令可以快速安装 LangChain 相关的依赖：

pip install langchain
pip install langchain-community # 默认安装
pip install langchain-core # 默认安装
pip install langchain-cli # LangChain 命令行界面
pip install --upgrade --quiet pypdf # 安装 pdf 加载器的依赖

文档加载器 PDF

在这篇文章中我们使用 PDF 作为我们的知识库文档。

加载文档的过程一般需要下面的步骤：

1. 解析文档（txt、pdf、html、url、xml、markdown、json 等等）为字符串（LangChain 已经分装了几十种文档加载器，感兴趣的可以去参考官网）。
2. 将字符串拆分为适合模型的对话窗口的大小，称为 Chunk。Chunk 的大小需要依据模型的会话窗口设定。
3. 保存拆分好的文档保存到向量数据库中。
4. 设计向量数据库的数据库、集合、字段，索引等信息。
5. 从向量数据库中检索需要的数据。

这些步骤 LangChain 已经结合自己的工具连做好了封装，所以我们直接使用 LangChain 来构建 RAG。

from langchain_text_splitters import CharacterTextSplitter
from langchain_community.document_loaders import PyPDFLoader

file_path = 'CodeGeeX 模型 API.pdf'

# 初始化 pdf 文档加载器
loader = PyPDFLoader(file_path=file_path)
# 将 pdf 中的文档解析为 langchain 的 document 对象
documents = loader.load()
# 将文档拆分为合适的大小
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
docs = text_splitter.split_documents(documents)

上面有两个参数需要注意下：

chunk_size=1000

表示拆分的文档的大小，也就是上面所说的要设置为多少合适取决于所使用 LLM 的窗口大小。

• 如果设置小了，那么我们一次查询的数据的信息量就会少，势必会导致信息的缺失。
• 如果设置大了，一次检索出来的数据就会比较大，LLM 产生的 token 就会多，费用贵，信息不聚焦等问题。

chunk_overlap=100

这个参数表示每个拆分好的文档重复多少个字符串。

为什么要重复：如果拆分后的 Chunk 没有重复，很有可能会产生语义错误。

比如这样一段文本：....小米汽车的续航里程为 700 公里....如果文本正好从 700 的哪里拆分开的话，那给人展示的时候就会产生究竟是 700m 还是 700 公里才歧义。

chunk_overlap 如果设置比较大的值也不合适。这样每个文档的重复度就会很大，导致有用的信息就会减少，从而 LLM 回复的内容有可能缺少关键的信息。

Milvus 向量数据库

关于 Milvus 可以参考官方文档。下面我们安装 pymilvus 库：

pip install --upgrade --quiet pymilvus

如果你使用的不是 Milvus 数据库，那也没关系，LangChain 已经给我们分装了几十种向量数据库，你选择你需要的数据库即可。本文中我们是系列教程中一篇，所以我们使用 Milvus 向量库。

Embedding Model

这里需要明确的两个功能是：

• Embedding Model 所做的工作就是将 Image、Document、Audio 等信息向量化。
• VectorDB 负责保存多维向量。

我这里使用 AzureOpenAIEmbeddings 是个收费的模型。有开源的 Embedding Model 可以部署在本地使用，如果你的机器性能足够好。如果要本地部署可以参考 Docker 部署 Llama2 模型。

这里我使用 AzureOpenAIEmbeddings，相关配置我放到了 .env 文件中，并使用 dotenv 加载。

# AZURE config
AZURE_OPENAI_ENDPOINT=''
AZURE_OPENAI_API_KEY=''
OPENAI_API_VERSION=2024-03-01-preview
AZURE_DEPLOYMENT_NAME_GPT35 = "gpt-35-turbo"
AZURE_DEPLOYMENT_NAME_GPT4 = "gpt-4"
AZURE_EMBEDDING_TEXT_MODEL = "text-embedding-ada-002"

这里各位可以依据自己的情况设定即可。

向量化 + 存储

上面已经说明了向量库以及 Embedding Model 的关系。我们直接使用 LangChain 提供的工具来完成 Embedding 和 Store。

# 初始化 embedding model
from langchain_openai import AzureOpenAIEmbeddings
embeddings = AzureOpenAIEmbeddings()

from langchain_community.vectorstores import Milvus
vector = Milvus.from_documents(
    documents=documents, # 设置保存的文档
    embedding=embeddings, # 设置 embedding model
    collection_name="book", # 设置 集合名称
    drop_old=True,
    connection_args={"host": "127.0.0.1", "port": "19530"}, # Milvus 连接配置
)

执行完成上面的代码，我们就将 PDF 中文档内容保存到 vector_db 中。

字段 vector 就是保存的多维向量。

Milvus Search

虽然现在我们还没有使用 LLM 的任何能力，但是我们已经可以使用 Vector 的搜索功能了。

query = "CodeGeeX 模型 API 参数有那些？"
docs = vector.similarity_search(query)
print(docs)

# 带 score 搜索
query = "CodeGeeX 模型 API 参数有那些？"
docs = vector.similarity_search_with_score(query, k=2)
print(docs)

similarity_search 与 similarity_search_with_score 的区别就是 similarity_search_with_score 搜索出来会带有一个 score 分值的字段，某些情况下这个 score 很有用。

LangChain 不仅仅提供了基础的搜索能力，还有其他的搜索方法，感兴趣的可以去研究下。

RAG Chat

准备工作我们已经就绪，接下来我们使用 LangChain 构建我们的 Chat。

既然是聊天也就是我们跟模型的一问一答的形式来体现。这两年 LLM 的出现，关于 LLM 的知识里面我们估计最熟悉就是角色设定了。

角色设定

什么是角色设定：下面 OpenAI 给出的回答:

在大型语言模型 (LLM) 中，角色设定指的是为 AI 助手创建一个特定的人格或身份。这个设定包括 AI 助手的说话风格、知识领域、价值观、行为方式等各个方面。通过这些设定，AI 助手可以扮演不同的角色，比如专业的客服、风趣幽默的聊天对象，或是特定领域的专家顾问。

角色设定可以让 AI 助手的回答更加符合特定的场景和用户的期望。比如一个扮演医生的 AI 助手，会用专业术语解释病情，给出严谨的建议；而一个扮演朋友的 AI 助手，会用轻松的语气聊天，给出生活化的提示。

此外，角色设定还可以帮助限定 AI 助手的行为边界，避免其做出不恰当或有害的回应。设定明确的角色定位，有助于 AI 助手更好地理解自己的身份和职责，从而提供更加合适和有帮助的回答。

总的来说，角色设定让 AI 助手的对话更加自然和人性化，让用户获得更好的使用体验。同时它也是引导 AI 助手行为、确保其安全可控的重要手段。

在 Chat 中我们同样也需要一个简单的 Prompt：

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.

Question: {question}

Context: {context}

Answer:
"""

这个 Prompt 中很明显我们设定了两个变量 question, context。

• question：这个会在后面被替换为用户的输入，也就是用户的问题。
• context：这个变量我们在后面会替换为向量检索出来的内容。

请思考下：我们最后提供给 LLM 的内容只是用户的问题呢还是问题连带内容一起给到 LLM？

Chat Chain

基于上面的内容我们基本的工作已经完成，下面就是我们基于 LangChain 构建 Chat。

import os
from langchain_core.prompts import ChatPromptTemplate
prompt = ChatPromptTemplate.from_template(template)
print(prompt)

# 加载 chat model
from langchain_openai import AzureChatOpenAI
from langchain_core.runnables import RunnableParallel, RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser
llm = AzureChatOpenAI(
    azure_deployment=os.environ.get('AZURE_DEPLOYMENT_NAME_GPT35')
)

retriever = vector.as_retriever()

chain = (
    RunnableParallel({"context": retriever, "question": RunnablePassthrough()})
    | prompt
    | llm
    | StrOutputParser()
)

对于初学者可能有个问题就是：为什么这里有个 AzureChatOpenAI() 的实例 llm。 这是个好问题，对于初学者会被各种 LLM 搞晕。

• AzureOpenAIEmbeddings() 这是一个负责将文本向量化化的 Model。
• AzureChatOpenAI() 是一个 Chat 模型。负责聊天的 Model。

基于 LangChain 的链式调用构建 Chat：

chain = (
    RunnableParallel({"context": retriever, "question": RunnablePassthrough()})
    | prompt
    | llm
    | StrOutputParser()
)

这里看到 Prompt 中的两个变量 context, question 会被替换。

为什么我们要写变量在 Prompt 中？

• 工程化：我们在做 LLM 相关的工作最重要的就是 Prompt 工程。这也是个重要的话题后面再说。
• 灵活：便于动态调整输入内容，无需修改代码逻辑。

测试

示例一

question = "CodeGeeX 模型 API 参数有那些？"
answer = chain.invoke(question)
print(answer)

输出：

CodeGeeX 模型 API 的参数包括：
- prompt：用户输入的提示词
- max_tokens：模型输出最大 tokens
- temperature：采样温度，控制输出的随机性
- top_p：另一种采样方法，模型考虑具有 top_p 概率质量 tokens 的结果
- stream：用于同步调用时，控制模型生成内容的返回方式，可以设置为 false 或 true

示例二

question = "请给一个 chat 模型非流式请求示例"
answer = chain.invoke(question)
print(answer)

输出：

流式请求示例:
curl --location 'http://{ip}/prod/model/api/infillingStreaming' \
--header 'Content-Type: application/json' \
--data '{
    "model": "codegeex",
    "prompt": "package problem1;\nclass Solution{\n    public int \nremoveDuplicates(int[] nums){\n        int cnt = 1;\n        for (int i = 1; \ni < nums.length; ++i)\n            if (nums[i] != nums[i - 1]) {\n             \n   nums[cnt] = nums[i];\n                ++cnt;\n            }\n        return \ncnt;\n    }\n}",
    "max_tokens": 1024,
    "temperature": 0.2,
    "top_p": 0.95,
    "stream": true
}'

对比 PDF 中的内容，很明显这个结果就是对的。

总结与最佳实践

本文主要是 Milvus 向量数据库实战总结。

• LLM 痛点以及解决方案
• RAG 是什么，为什么选用 RAG
• LangChain 文档加载器，Embedding Model，Chat Model
• 文档拆分的注意点，Embedding Model，Chat Model 区别
• Chat 示例代码

最佳实践建议

在实际生产环境中，除了上述基础流程外，还需注意以下几点：

1. 向量数据库选型：Milvus 适合大规模数据和高并发场景，但对于小规模测试，Chroma 或 FAISS 可能更轻量。
2. 混合检索：单纯依靠向量相似度可能不够精准，建议结合关键词检索（BM25）进行混合排序，提高召回率。
3. 缓存机制：对于高频问题，可以在应用层增加 Redis 缓存，减少向量检索和 LLM 调用的延迟。
4. 监控与日志：记录每次检索的 Context 和最终生成的 Answer，便于后续分析模型表现和优化 Prompt。
5. 安全性：确保向量数据库的连接配置安全，避免敏感数据泄露，特别是在云环境部署时。

通过上述步骤，你可以成功构建一个基于 LangChain 和 Milvus 的本地 RAG 知识库系统，有效解决大模型知识滞后和幻觉问题。