在实际企业级 AI 应用开发中直接使用大模型处理私有、实时或细粒度知识时常常会遇到模型幻觉、知识滞后和上下文窗口限制等问题。检索增强生成Retrieval-Augmented Generation, RAG技术通过将外部知识库与大型语言模型LLM相结合成为解决这些痛点的核心方案。它让模型能够基于检索到的相关文档片段生成更准确、更具事实依据的答案。本文将手把手带你构建一个完整的企业级 RAG 系统。我们将从 RAG 的核心原理出发逐步完成文档加载、文本分割、向量化表示、向量数据库存储、混合检索策略以及最终的生成环节并结合一个模拟的企业知识库项目进行全流程实战。无论你是希望将内部文档、产品手册还是行业资料转化为可查询的知识库本文提供的路径都能为你提供清晰的工程实现参考。1. 理解 RAG 系统的工作原理与核心价值RAG 的核心思想并不复杂在让大模型回答问题之前先从一个外部的、可控的知识库中查找与问题最相关的信息然后将这些信息作为上下文连同问题一起交给模型从而引导模型生成基于这些事实的答案。1.1 RAG 的基本工作流程一个典型的 RAG 系统包含以下关键步骤文档预处理与索引构建离线阶段文档加载从各种来源如 PDF、Word、TXT、网页、数据库加载原始文档。文本分割将长文档切分成大小适宜的文本片段Chunks。这是关键一步块的大小和重叠度直接影响检索质量。向量化使用文本嵌入模型将每个文本块转换为一个高维向量Embedding。这个向量在数学上表征了文本的语义信息。存储将文本块及其对应的向量存储到向量数据库中建立索引。检索与生成在线阶段查询向量化当用户提出问题时使用同样的嵌入模型将问题转换为一个查询向量。语义检索在向量数据库中通过计算相似度如余弦相似度快速找到与查询向量最相似的 K 个文本块。上下文增强将检索到的 Top K 个文本块组合成提示词的上下文部分。答案生成将“上下文 用户问题”构成的增强提示词发送给大模型让模型基于给定的上下文生成最终答案。1.2 为什么 RAG 对企业应用至关重要相比于直接询问大模型RAG 带来了几个决定性的优势减少模型幻觉模型被要求严格依据提供的事实生成答案大大降低了“胡编乱造”的可能性。知识实时更新更新知识库只需更新向量数据库中的文档无需耗时耗力地重新训练或微调大模型。保护隐私与知识产权敏感数据和内部知识无需上传至公开的模型服务可以完全在私有环境中运行。溯源与可信度系统可以返回答案所依据的源文档片段方便用户验证答案的准确性增强可信度。成本效益通常比微调大模型成本更低实现更快尤其适合知识频繁变动的场景。2. 环境准备与工具选型在开始编码之前我们需要搭建开发环境并选择合适的技术组件。以下是本次实战项目的技术栈它们构成了当前构建 RAG 系统的主流选择。2.1 技术栈与组件介绍编程语言Python 3.8文档加载与处理LangChain - 一个强大的 LLM 应用开发框架提供了丰富的文档加载器、文本分割器和集成接口。文本嵌入模型BAAI/bge-small-zh-v1.5- 一个优秀的中文文本嵌入模型我们将通过 Hugging Face 的sentence-transformers库使用它。向量数据库Chroma - 一个轻量级、易用且功能强大的开源向量数据库非常适合原型开发和中小型项目。大语言模型我们将使用两种方式接入 LLM本地部署通过 Ollama 在本地运行开源模型如 Qwen、Llama 等。API 调用调用 OpenAI API 或国内兼容 OpenAI 协议的 API如 DeepSeek、智谱 AI 等。2.2 环境配置与依赖安装首先确保你的 Python 环境版本在 3.8 及以上。然后使用 pip 安装所需的库。# 安装核心库 pip install langchain langchain-community langchain-chroma # 安装文本嵌入模型所需库 pip install sentence-transformers # 安装 Chroma 向量数据库持久化支持 pip install chromadb # 如果需要使用 OpenAI API pip install openai # 如果需要处理 PDF 等文档 pip install pypdf注意依赖版本兼容性是项目成功运行的关键。如果遇到问题可以尝试使用pip freeze requirements.txt导出你成功环境中的版本号。2.3 项目结构规划一个清晰的目录结构有助于项目管理。建议创建如下结构rag_project/ ├── docs/ # 存放原始知识文档PDF, TXT等 ├── data/ # 用于存放向量数据库持久化文件 ├── src/ │ ├── __init__.py │ ├── build_knowledge_base.py # 构建知识库脚本 │ └── query_rag.py # 查询 RAG 系统脚本 ├── requirements.txt └── README.md3. 构建企业知识库从文档到向量索引现在我们开始实现 RAG 的离线部分。我们将编写一个脚本读取docs/目录下的文档处理它们并存入 Chroma 向量数据库。3.1 文档加载与文本分割创建src/build_knowledge_base.py文件。import os from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter # 设置文档目录 documents_directory ../docs # 支持的文件类型及其对应的加载器 LOADER_MAPPING { .pdf: (PyPDFLoader, {}), .txt: (TextLoader, {encoding: utf-8}), } def load_documents(directory): 加载指定目录下的所有文档 all_documents [] for root, _, files in os.walk(directory): for file_name in files: file_path os.path.join(root, file_name) file_ext os.path.splitext(file_name)[1].lower() if file_ext in LOADER_MAPPING: loader_class, loader_args LOADER_MAPPING[file_ext] try: loader loader_class(file_path, **loader_args) documents loader.load() all_documents.extend(documents) print(f成功加载文档: {file_path}) except Exception as e: print(f加载文档 {file_path} 时出错: {e}) return all_documents # 加载所有文档 raw_docs load_documents(documents_directory) print(f共加载 {len(raw_docs)} 个文档) # 配置文本分割器 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个文本块的大小字符数 chunk_overlap50, # 块之间的重叠字符数保持上下文连贯 length_functionlen, is_separator_regexFalse, ) # 分割文档 split_docs text_splitter.split_documents(raw_docs) print(f文档被分割成 {len(split_docs)} 个文本块)关键参数解释chunk_size这是最重要的参数之一。太小会导致信息碎片化太大会引入噪声。对于通用文档500-1000 是一个常见的起点。chunk_overlap重叠部分有助于避免在分割点时丢失重要上下文。3.2 向量化与向量数据库存储接下来我们使用嵌入模型将文本块转换为向量并存入 Chroma。from langchain_chroma import Chroma from langchain_huggingface import HuggingFaceEmbeddings # 初始化嵌入模型 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, model_kwargs{device: cpu}, # 使用 GPU 可改为 cuda encode_kwargs{normalize_embeddings: True} # 归一化便于计算余弦相似度 ) # 设置向量数据库持久化路径 persist_directory ../data/chroma_db # 创建向量数据库实例 vectordb Chroma.from_documents( documentssplit_docs, embeddingembedding_model, persist_directorypersist_directory ) # 显式持久化到磁盘 vectordb.persist() print(f知识库构建完成向量数据库已保存至: {persist_directory}) print(f知识库中共有 {vectordb._collection.count()} 个向量)运行此脚本后你的data/chroma_db目录下会生成 Chroma 数据库文件。这意味着知识库索引已经构建成功后续查询无需重复此过程除非文档有更新。4. 实现检索与问答链知识库准备好后我们实现在线查询部分。创建src/query_rag.py。4.1 初始化检索器与 LLMfrom langchain_chroma import Chroma from langchain_huggingface import HuggingFaceEmbeddings from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate # 1. 加载之前创建的向量数据库 embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) persist_directory ../data/chroma_db vectordb Chroma(persist_directorypersist_directory, embedding_functionembedding_model) # 2. 配置检索器 retriever vectordb.as_retriever( search_typesimilarity, # 使用相似度搜索 search_kwargs{k: 3} # 检索最相似的 3 个文本块 ) # 3. 初始化 LLM (这里以 Ollama 本地模型为例) from langchain_community.llms import Ollama llm Ollama(modelqwen2:7b) # 请确保已用 ollama pull qwen2:7b 下载模型 # 如果使用 OpenAI API替换为以下代码 # from langchain_openai import ChatOpenAI # llm ChatOpenAI(modelgpt-3.5-turbo, openai_api_keyyour-api-key)4.2 设计提示词模板并创建问答链直接检索后扔给模型可能效果不佳一个精心设计的提示词模板至关重要。# 定义提示词模板指导模型基于上下文回答问题 prompt_template 请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题请直接说根据已知信息无法回答该问题不要编造信息。 上下文 {context} 问题{question} 请根据上下文给出答案 PROMPT PromptTemplate( templateprompt_template, input_variables[context, question] ) # 创建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # stuff 将检索到的所有内容塞入上下文简单有效 retrieverretriever, chain_type_kwargs{prompt: PROMPT}, return_source_documentsTrue # 返回源文档用于溯源 )4.3 执行查询并展示结果# 进行查询 question 我们公司今年的主要战略目标是什么 result qa_chain.invoke({query: question}) print(f问题: {question}) print(--- * 10) print(f答案: {result[result]}) print(--- * 10) print(来源文档:) for i, doc in enumerate(result[source_documents]): print(f[{i1}] {doc.page_content[:200]}...) # 打印源文档片段的前200字符 print(f 来源文件: {doc.metadata.get(source, Unknown)}\n)运行query_rag.py如果一切顺利你将看到模型基于你知识库中的内容生成的答案并附上引用的源文档。5. 高级优化提升 RAG 系统性能基础 RAG 已经能工作但要达到企业级要求还需要考虑以下优化策略。5.1 优化检索策略混合检索单纯基于向量的语义搜索语义检索有时会忽略关键词的重要性。结合传统的关键词搜索如 BM25可以取长补短这就是混合检索。# 示例使用 LangChain 的 BM25 检索器需要安装 rank_bm25 # pip install rank_bm25 from langchain.retrievers import BM25Retriever, EnsembleRetriever from langchain_community.retrievers.bm25_retriever import BM25Retriever as LC_BM25Retriever # 1. 创建 BM25 检索器基于文本内容 bm25_retriever LC_BM25Retriever.from_documents(split_docs) bm25_retriever.k 3 # 2. 获取之前创建的向量检索器 vector_retriever vectordb.as_retriever(search_kwargs{k: 3}) # 3. 组合成混合检索器 ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.5, 0.5] # 调整权重 ) # 4. 在 QA 链中使用混合检索器 qa_chain_hybrid RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverensemble_retriever, chain_type_kwargs{prompt: PROMPT}, return_source_documentsTrue )5.2 优化文本分割策略文本分割是 RAG 的基石。不同的文档类型可能需要不同的分割策略。递归字符分割通用性强如上例所用。按标记分割对于按 Token 计费的 LLM 更精确。语义分割尝试在句子或段落边界进行分割效果更好但更复杂。from langchain_text_splitters import TokenTextSplitter token_splitter TokenTextSplitter( chunk_size200, # 按 Token 数而非字符数 chunk_overlap20 ) # 可用于重新处理文档5.3 评估 RAG 系统质量如何判断你的 RAG 系统是好是坏通常从两个方面评估检索质量检索到的文档是否与问题真正相关可以使用命中率、平均精度等指标。生成质量答案是否准确、相关、流畅这包括忠实度答案是否严格基于检索到的上下文即使上下文是错的模型也不应编造。答案相关性答案是否直接回答了问题可以构建一个包含“问题-标准答案-相关文档”的测试集使用 RAGAS 等框架进行自动化评估。6. 常见问题排查与生产环境建议在实际部署中你会遇到各种问题。以下是典型问题及其解决方案。问题现象可能原因检查与解决方案答案与知识库内容不符幻觉1. 提示词约束力不够。2. 检索到的文档不相关。3. 模型本身幻觉性强。1. 强化提示词如“必须依据上下文”。2. 检查检索环节调整 chunk_size 或使用混合检索。3. 换用指令遵循能力更强的模型。检索不到任何相关内容1. 问题表述与文档差异大。2. 嵌入模型不匹配或性能差。3. 文档未正确加载或分割。1. 尝试对用户问题进行查询重写或扩展。2. 尝试不同的嵌入模型如BAAI/bge-large-zh-v1.5。3. 检查原始文档和分割后的 chunks 内容。回答“根据已知信息无法回答”过于频繁1. 检索阈值设置过高。2. 上下文信息过于碎片化。1. 增加检索数量k。2. 适当增大chunk_size或优化分割点。系统响应速度慢1. 向量数据库检索慢。2. LLM 生成速度慢。3. 网络延迟如果使用远程 API。1. 确保向量数据库有索引。2. 本地部署可尝试更小的模型或使用 GPU。3. 对于 API考虑异步调用或缓存常见问答。生产环境部署建议配置管理将所有配置模型路径、API Key、参数外置到环境变量或配置文件中。日志与监控记录每一次查询的问题、检索结果、生成的答案和源文档便于追踪和优化。权限与安全如果知识库包含敏感信息确保向量数据库和整个应用有适当的访问控制。更新策略制定知识库更新流程。可以是全量重建也可以是增量更新Chroma 支持。可扩展性对于海量文档考虑使用更强大的向量数据库如 Milvus、Pinecone 或 Weaviate。构建一个高性能的 RAG 系统是一个迭代过程。从最小可行产品开始基于真实用户的查询日志不断评估和优化检索、分割、提示词等各个环节才能最终打造出一个可靠的企业级知识问答系统。下一步你可以探索多轮对话、Agent 智能体集成、多模态文档处理等更高级的主题。