RAG 实战：利用 Langchain 和 Milvus 构建本地知识库

不过仅靠微调很少能为模型提供在不断变化的环境中回答高度具体问题所需的全部知识，并且微调的时间周期还比较长。所以科学家们提出了 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 等信息向量化。
• Vector DB：负责保存多维向量。

我这里使用 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 的知识里面我们估计最熟悉就是角色设定了。

• 什么是角色设定：在大型语言模型 (LLM) 中，角色设定指的是为 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 中的内容，很明显这个结果就是对的。

进阶优化建议

在实际生产环境中，除了基本的流程实现，还需要关注以下优化点以提升系统性能和用户体验：

1. 分块策略优化

默认的字符切分（CharacterTextSplitter）虽然简单，但在处理复杂文档时可能破坏语义。建议尝试以下策略：

• Semantic Splitter：基于语义完整性进行切分，保持段落逻辑。
• RecursiveCharacterTextSplitter：按字符优先级递归切分，通常比单一字符切分效果更好。
• Metadata 保留：在切分时保留页码、章节标题等元数据，有助于后续溯源。

2. 检索策略增强

• Hybrid Search：结合关键词搜索（BM25）和向量相似度搜索，提高召回率。
• Re-ranking：在检索后引入重排序模型（如 BGE-Reranker），对初步检索结果进行二次打分，提升 Top-K 结果的准确性。
• Query Transformation：对用户查询进行改写（Query Rewriting），将其转化为更适合检索的表述。

3. 评估体系构建

• 人工评估：定期抽样检查回答质量，标注准确率。
• 自动化指标：使用 RAGAS 等框架计算 Faithfulness（忠实度）、Answer Relevance（答案相关性）等指标。
• A/B 测试：对比不同 Embedding 模型或不同 Chunk Size 下的效果差异。

4. 性能与成本

• 缓存机制：对高频问题结果进行缓存，减少 Token 消耗。
• 异步处理：对于长文档处理或高并发场景，采用异步队列处理任务。
• 模型选择：根据预算选择合适的 Embedding 和 LLM 模型，平衡效果与成本。

总结

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

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

通过上述步骤，你可以快速搭建一个基于 Langchain 和 Milvus 的个性化本地知识库系统，有效解决大模型知识滞后和幻觉问题。