如果你正在尝试让大语言模型LLM回答你公司内部文档、产品手册或私有知识库里的问题大概率会得到两种令人沮丧的结果要么是“根据我的训练数据我无法回答这个问题”要么是它开始一本正经地“胡说八道”幻觉。这背后的核心矛盾在于LLM 的强大能力源于其海量的通用预训练数据但它无法“记住”或“理解”你私有的、最新的、非公开的信息。解决这个矛盾正是 RAG检索增强生成技术爆火的原因。它承诺让 LLM 拥有“外挂大脑”通过检索外部知识来生成更准确、更相关的回答。然而当你真正开始动手搭建一个 RAG 系统时往往会发现事情没那么简单Embedding 模型怎么选文本切分Chunking到底多长合适向量数据库那么多哪个适合我这些看似独立的组件如何协同工作才能让整个系统真正可用而不是一个“玩具”本文将从零开始为你拆解 RAG 的完整技术栈。我们不会停留在概念层面而是聚焦于实战如何将一份 PDF 文档通过 Embedding、Chunking、向量存储与检索最终构建一个能精准回答问题的问答系统。我们将使用当前主流且易于上手的工具链如 Sentence Transformers、ChromaDB并提供每一步的完整代码和配置确保你能亲手复现。无论你是想快速搭建一个原型还是为生产环境做技术选型这篇文章都将提供清晰的路径和关键的避坑指南。1. RAG 要解决的核心问题为什么不是微调在深入技术细节前我们必须先回答一个根本问题为什么是 RAG而不是微调Fine-tuning很多开发者的第一反应是既然模型不知道我的数据那我用我的数据去训练微调它不就行了这个想法很自然但在实践中RAG 和微调解决的是不同维度的问题而 RAG 在大多数知识增强场景下成本更低、更灵活、风险更小。微调的本质是“改变模型的行为和知识”。你通过大量数据让模型学习新的模式或知识并将其“固化”到模型的权重中。这适用于风格迁移让模型学会用某种特定的口吻如客服、法律文书写作。任务适配让一个通用模型在特定任务如代码生成、医疗诊断上表现更好。学习私有数据中的深层模式当你的数据蕴含着复杂的、非显性的规律时。但微调有几个显著的挑战成本高昂需要准备高质量的标注数据计算资源消耗大尤其是对大模型。知识更新困难每次知识库更新都需要重新微调并部署新模型流程冗长。灾难性遗忘在注入新知识的同时可能导致模型遗忘原有的通用能力。可解释性差模型回答的依据是什么很难追溯存在“黑箱”风险。RAG 的本质是“为模型提供临时的上下文参考”。它不改变模型本身而是在模型生成答案前先从外部知识库中检索出最相关的文档片段并将其作为“提示词”的一部分交给模型。这相当于在考试时允许模型开卷查阅指定的资料。RAG 的优势恰恰对应了微调的劣势低成本、快迭代知识库更新只需重新处理文档并存入向量数据库无需动模型。知识可追溯模型给出的答案通常基于检索到的文档来源清晰便于验证和审计。缓解幻觉通过提供事实依据约束模型的生成减少编造。模块化检索器Retriever、向量数据库、LLM 可以独立升级和替换。因此对于绝大多数“基于私有文档的智能问答”场景RAG 是更务实、更高效的起点。它让你能快速验证想法构建原型并以较低的成本维护一个动态更新的知识系统。2. 核心组件拆解Embedding, Chunking, 向量数据库一个典型的 RAG 系统工作流程可以概括为“索引”和“查询”两个阶段涉及四个核心组件原始文档 -- [文本加载与分割 Chunking] -- 文本块 -- [向量化 Embedding] -- 向量 -- [向量数据库存储] | v 用户问题 -- [向量化 Embedding] -- 问题向量 -- [向量数据库检索] -- 相关文本块 -- [LLM 生成答案]下面我们逐一拆解每个组件的职责、技术选型和关键决策点。2.1 Chunking如何把文档“切”得恰到好处Chunking分块是 RAG 流水线的第一步也是最容易被低估的一步。切分的好坏直接决定了检索的精度。切得太碎上下文信息丢失切得太大会引入无关噪声且超出 LLM 的上下文窗口。核心策略固定大小分块最简单的方法按字符或 token 数切分如每块 500 字符。优点是简单缺点是不顾语义边界可能把一句话或一个概念拦腰截断。基于分隔符分块利用自然段落标记如\n\n、标题#、句号等进行切分。更符合阅读习惯但块大小可能不均。语义分块使用嵌入模型或小型模型计算句子间的相似度在语义变化处切分。这是更高级的方法能更好地保持语义单元完整但计算开销稍大。递归分块先按大分隔符如章节切如果块太大再按小分隔符如段落递归切分。这是 LangChain、LlamaIndex 等框架常用的稳健策略。滑动窗口分块在固定大小分块的基础上让块之间有一定重叠如 50 字符。这能确保关键信息出现在块边界时依然能被检索到是提升召回率的有效技巧。实战建议从递归分块滑动窗口开始这是平衡效果和复杂度的最佳起点。例如先按\n\n分段落对超过 500 字符的段落再按句子分隔符.切分并设置 10% 的重叠。块大小需要实验没有银弹。对于技术文档256-512 token 可能合适对于长篇小说1024 token 的块可能更好。一个重要的原则是你的块大小应该与你期望模型用来生成答案的上下文长度相匹配。保留元数据切分时务必记录每个块的来源文件名、页码、章节标题。这在后续溯源时至关重要。2.2 Embedding把文字变成机器能“理解”的数字Embedding嵌入是将文本词、句、段落映射为一个固定长度的稠密向量一列数字的过程。这个向量在高维空间中代表了文本的语义。语义相似的文本其向量在空间中的距离如余弦相似度也更近。关键概念嵌入模型执行向量化的模型如text-embedding-ada-002(OpenAI)、BGE-M3(智源)、multilingual-e5-large(微软)。向量维度向量的长度如 768、1024、1536。维度越高通常表征能力越强但存储和计算成本也越高。相似度度量余弦相似度、点积、欧氏距离。最常用的是余弦相似度它关注向量的方向而非大小对文本相似度任务更鲁棒。模型选型考量语言你的文档主要是中文、英文还是多语言BGE-M3和multilingual-e5-large在多语言上表现优异。领域通用模型 vs. 领域模型如医学、法律。通常先从强大的通用模型开始。性能与开销模型越大效果可能越好但编码速度越慢。需要在延迟和精度间权衡。上下文长度模型能处理的最大文本长度。BGE-M3支持 8192 token适合长文档。一个重要趋势Embedding 与 Rerank 分离。为了平衡检索速度和精度先进的做法是第一轮检索召回使用一个速度快、容量大的嵌入模型如BGE-M3从向量数据库中召回 Top K如 20个相关块。第二轮重排序精排使用一个更精准但稍慢的重排序模型Reranker如BGE-Reranker对召回的 20 个块进行重新打分和排序选出最相关的 Top N如 3-5个块送给 LLM。 这种方式用较小的计算代价显著提升了最终上下文的质量。2.3 向量数据库海量向量的“管家”向量数据库专门为高效存储、索引和检索高维向量而设计。当你有百万甚至千万级的文档块时简单的线性扫描计算问题与所有块的相似度是不可行的。向量数据库的核心是近似最近邻搜索算法它用精度换速度快速找到最相似的向量。主流开源选型对比数据库主要特点适用场景上手难度ChromaDB轻量、易用、Python/JS 原生友好内置 Embedding 功能。原型开发、中小规模项目、学习入门。★☆☆☆☆Milvus功能全面、性能强劲、云原生设计支持标量过滤、动态 Schema。大规模生产环境、需要复杂查询和超高吞吐。★★★☆☆QdrantRust 编写性能优异API 设计清晰支持多种数据类型和过滤。对性能和资源效率要求高的生产环境。★★☆☆☆Weaviate更像一个“向量化”的图数据库支持 GraphQL内置模块化设计。需要结合向量搜索和对象关系查询的场景。★★☆☆☆PGVectorPostgreSQL 的扩展直接在关系数据库中处理向量。已有 PostgreSQL 生态希望简化技术栈。★★☆☆☆如何选择快速验证想法ChromaDB是不二之选。它几乎零配置几行代码就能跑起来非常适合学习和构建 MVP最小可行产品。准备上生产需要评估数据规模、查询 QPS、团队技术栈。Milvus和Qdrant是强有力的竞争者。本文实战选择为了聚焦 RAG 核心逻辑降低环境复杂度我们将使用ChromaDB。它的简单性让我们能更清晰地展示从文档到问答的完整链路。3. 环境准备构建可复现的 Python 环境在开始编码前我们需要一个干净的 Python 环境。强烈建议使用 Conda 或 venv 创建虚拟环境。# 1. 创建并激活虚拟环境 (以 conda 为例) conda create -n rag_demo python3.10 conda activate rag_demo # 2. 安装核心库 pip install chromadb sentence-transformers pypdf2 langchain # 可选安装 tiktoken 用于精确的 token 计数如果你使用 OpenAI 模型 # pip install tiktoken # 3. 验证安装 python -c import chromadb; import sentence_transformers; print(环境准备OK)库说明chromadb: 轻量级向量数据库。sentence-transformers: 一个非常流行的框架方便地使用各种 Sentence Embedding 模型我们用它来加载 BGE 等开源模型。pypdf2: 用于解析 PDF 文档提取文本。langchain: 一个流行的 LLM 应用开发框架。这里我们主要借用其优秀的文本分割器你也可以用其他方法替代。4. 实战第一步文档加载与智能分块 (Chunking)假设我们有一份名为product_manual.pdf的产品手册。第一步是读取它并将其切分成有意义的文本块。# file: doc_processor.py import PyPDF2 from langchain.text_splitter import RecursiveCharacterTextSplitter from typing import List, Dict import hashlib def load_pdf_text(pdf_path: str) - str: 从PDF文件中提取纯文本 text try: with open(pdf_path, rb) as file: reader PyPDF2.PdfReader(file) for page_num in range(len(reader.pages)): page reader.pages[page_num] text page.extract_text() f\n[Page {page_num 1}]\n except Exception as e: print(f读取PDF文件失败: {e}) raise return text def chunk_text(text: str, chunk_size: int 500, chunk_overlap: int 50) - List[Dict]: 使用递归字符分割器对文本进行分块。 返回一个字典列表每个字典包含文本块内容和元数据。 # 初始化分割器 text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, # 每个块的最大字符数 chunk_overlapchunk_overlap, # 块之间的重叠字符数 length_functionlen, # 计算长度的方法 separators[\n\n, \n, 。, , , , , , ] # 分隔符优先级 ) # 生成文本块 chunks text_splitter.split_text(text) # 为每个块生成唯一ID并附加元数据 documents [] for i, chunk in enumerate(chunks): # 生成一个基于内容的简单ID (实际生产环境可能需要更稳健的方法) chunk_id hashlib.md5(chunk.encode()).hexdigest()[:16] doc { id: fchunk_{i}_{chunk_id}, text: chunk, metadata: { chunk_index: i, char_count: len(chunk), # 注意这里简化了实际应该从原文中解析出更精确的页码/章节 source: product_manual.pdf } } documents.append(doc) print(f原始文本被分割成 {len(documents)} 个块。) print(f示例块 (前200字符): {documents[0][text][:200]}...) return documents if __name__ __main__: # 测试代码 pdf_text load_pdf_text(product_manual.pdf) # 请确保该文件存在 chunks chunk_text(pdf_text)关键点解析RecursiveCharacterTextSplitter这是 LangChain 提供的一个稳健的分割器。它会按separators列表的顺序尝试分割。例如先尝试用双换行\n\n分如果分出来的块还是太大就用单换行\n分以此类推直到满足大小要求。chunk_overlap设置重叠是为了防止一个完整的句子或概念被切到两个块的边缘导致检索时丢失关键信息。10% 左右的重叠是一个不错的起点。元数据我们为每个块附加了metadata。在生产系统中你需要在解析 PDF 时更精细地记录页码、章节标题等信息这对于答案溯源至关重要。块大小这里用了 500 字符。你需要根据你的文档类型和后续使用的 LLM 上下文窗口来调整。例如如果使用 GPT-4 的 128K 窗口你可以用更大的块如 2000 字符来保留更多上下文。5. 实战第二步文本向量化与存储 (Embedding ChromaDB)有了文本块接下来就是用 Embedding 模型将它们转化为向量并存入 ChromaDB。# file: vector_store.py import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer import time from typing import List class VectorStore: def __init__(self, embedding_model_name: str BAAI/bge-small-zh-v1.5, persist_directory: str ./chroma_db): 初始化向量存储。 :param embedding_model_name: 使用的嵌入模型名称 :param persist_directory: ChromaDB 数据持久化目录 # 1. 初始化嵌入模型 print(f正在加载嵌入模型: {embedding_model_name}...) self.embed_model SentenceTransformer(embedding_model_name) print(嵌入模型加载完毕。) # 2. 初始化 ChromaDB 客户端 (持久化模式) self.client chromadb.PersistentClient(pathpersist_directory) # 3. 获取或创建集合Collection。集合类似于数据库中的表。 # 我们指定使用余弦相似度进行搜索。 self.collection self.client.get_or_create_collection( nameproduct_manual, metadata{hnsw:space: cosine} # 使用余弦相似度 ) print(f向量数据库集合 product_manual 已就绪。) def generate_embeddings(self, texts: List[str]) - List[List[float]]: 为文本列表生成嵌入向量 # SentenceTransformer 的 encode 方法直接返回向量列表 embeddings self.embed_model.encode( texts, normalize_embeddingsTrue, # 归一化向量便于使用余弦相似度 show_progress_barTrue ).tolist() # 转换为 Python list return embeddings def add_documents(self, documents: List[Dict]): 将文档块添加到向量数据库。 :param documents: 由 doc_processor.chunk_text 生成的文档字典列表 if not documents: print(没有文档可添加。) return # 准备数据 ids [doc[id] for doc in documents] texts [doc[text] for doc in documents] metadatas [doc[metadata] for doc in documents] print(f正在为 {len(texts)} 个文档块生成嵌入向量...) start_time time.time() embeddings self.generate_embeddings(texts) elapsed time.time() - start_time print(f嵌入向量生成完成耗时 {elapsed:.2f} 秒。) # 添加到集合 print(正在将向量存入数据库...) self.collection.add( embeddingsembeddings, documentstexts, metadatasmetadatas, idsids ) print(f成功添加 {len(ids)} 个文档块到向量数据库。) def search_similar(self, query: str, top_k: int 5) - List[Dict]: 根据查询文本检索最相似的文档块。 :param query: 查询文本 :param top_k: 返回最相似的结果数量 :return: 包含文档内容和元数据的字典列表 # 1. 将查询文本向量化 query_embedding self.embed_model.encode( query, normalize_embeddingsTrue ).tolist() # 2. 在集合中搜索 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k, include[documents, metadatas, distances] # 返回文档、元数据和相似度距离 ) # 3. 格式化结果 retrieved_docs [] if results[documents]: for i in range(len(results[documents][0])): doc_info { content: results[documents][0][i], metadata: results[metadatas][0][i], score: 1 - results[distances][0][i] # 将距离转换为相似度分数 (余弦) } retrieved_docs.append(doc_info) return retrieved_docs if __name__ __main__: # 测试假设我们已经有了 chunks from doc_processor import chunk_text, load_pdf_text pdf_text load_pdf_text(product_manual.pdf) chunks chunk_text(pdf_text) # 初始化向量存储并添加文档 vs VectorStore() vs.add_documents(chunks) # 测试检索 test_query 这款产品的主要特性是什么 print(f\n测试查询: {test_query}) search_results vs.search_similar(test_query, top_k3) for i, res in enumerate(search_results): print(f\n--- 结果 {i1} (相似度: {res[score]:.4f}) ---) print(f内容: {res[content][:150]}...) print(f元数据: {res[metadata]})关键点解析嵌入模型选择我们使用了BAAI/bge-small-zh-v1.5这是一个优秀的中英文双语小模型速度快效果不错非常适合演示和中小规模应用。你可以根据需要替换为BAAI/bge-large-zh-v1.5效果更好但更慢或其他模型。normalize_embeddingsTrue这是关键一步它将向量归一化为单位长度。此时向量间的点积就等于余弦相似度。ChromaDB 的cosine空间需要配合归一化的向量才能正确工作。持久化PersistentClient会将数据保存在本地./chroma_db目录下次运行程序时数据依然存在无需重新处理文档。搜索返回collection.query返回的结果包含了原始文档、元数据和距离。余弦距离的范围是 [0, 2]0 表示完全相同2 表示完全相反。我们将其转换为相似度分数1 - distance使其范围在 [-1, 1] 之间分数越高越相似。6. 实战第三步组装 RAG 链调用 LLM 生成答案现在我们有了一个可以检索相关文档的“大脑”。最后一步是将检索到的文档作为上下文与用户问题一起提交给 LLM让它生成最终答案。# file: rag_pipeline.py import os from vector_store import VectorStore from doc_processor import load_pdf_text, chunk_text # 这里我们使用 OpenAI API 作为 LLM 示例。你也可以替换为其他 API 或本地模型。 from openai import OpenAI # 请确保设置了环境变量 OPENAI_API_KEY # export OPENAI_API_KEYyour-api-key class RAGPipeline: def __init__(self, vector_store: VectorStore, llm_model: str gpt-3.5-turbo): self.vs vector_store self.llm_client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.llm_model llm_model def _build_prompt(self, query: str, contexts: List[Dict]) - str: 构建给 LLM 的提示词 context_str \n\n.join([f[出处 {i1}]: {ctx[content]} for i, ctx in enumerate(contexts)]) prompt f请你基于以下提供的上下文信息回答用户的问题。如果上下文信息不足以回答问题请直接说“根据提供的信息我无法回答这个问题”不要编造信息。 上下文信息 {context_str} 用户问题{query} 请用中文给出清晰、准确的答案并尽量引用上下文中的具体信息。如果答案涉及多个要点请分条列出。 return prompt def ask(self, query: str, top_k: int 5) - Dict: 执行完整的 RAG 流程检索 - 构建提示 - LLM生成。 :return: 包含答案、参考来源和原始检索结果的字典 # 1. 检索相关文档 retrieved_docs self.vs.search_similar(query, top_ktop_k) if not retrieved_docs: return { answer: 未检索到相关文档信息。, sources: [], retrieved_docs: [] } # 2. 构建提示词 prompt self._build_prompt(query, retrieved_docs) # 3. 调用 LLM 生成答案 try: response self.llm_client.chat.completions.create( modelself.llm_model, messages[ {role: system, content: 你是一个专业的助手严格根据提供的上下文信息回答问题。}, {role: user, content: prompt} ], temperature0.1, # 低温度使输出更确定更贴近上下文 max_tokens1000 ) answer response.choices[0].message.content.strip() except Exception as e: answer f调用语言模型时出错: {e} # 4. 整理来源信息 sources [{content: doc[content][:200], metadata: doc[metadata], score: doc[score]} for doc in retrieved_docs] return { answer: answer, sources: sources, retrieved_docs: retrieved_docs # 保留完整检索结果用于调试 } def build_and_query(): 完整的构建索引和查询示例 # Step 1: 处理文档并构建向量索引 (如果尚未构建) print( 步骤1: 处理文档并构建向量索引 ) pdf_text load_pdf_text(product_manual.pdf) chunks chunk_text(pdf_text) vs VectorStore(persist_directory./chroma_db) # 注意在实际应用中应先检查集合是否已有数据避免重复添加。 # 这里为了演示我们假设每次都是新的。 # 你可以通过 vs.collection.count() 来判断。 if vs.collection.count() 0: vs.add_documents(chunks) else: print(向量数据库中已有数据跳过添加。) # Step 2: 初始化 RAG 管道 print(\n 步骤2: 初始化 RAG 管道 ) rag RAGPipeline(vs) # Step 3: 进行问答 print(\n 步骤3: 开始问答 ) questions [ 这款产品支持哪些操作系统, 如何重置设备到出厂设置, 产品的保修期是多久 ] for q in questions: print(f\n用户问题: {q}) result rag.ask(q, top_k3) print(fAI 答案: {result[answer]}) print(参考来源:) for i, src in enumerate(result[sources]): print(f [{i1}] 相似度 {src[score]:.3f}: {src[content]}...) print(- * 50) if __name__ __main__: # 确保已设置 OPENAI_API_KEY 环境变量 if not os.getenv(OPENAI_API_KEY): print(错误: 请设置 OPENAI_API_KEY 环境变量。) # 作为演示如果没有 API KEY我们可以只运行到检索步骤 print(将仅演示文档处理和检索步骤跳过 LLM 生成。) from vector_store import VectorStore from doc_processor import load_pdf_text, chunk_text pdf_text load_pdf_text(product_manual.pdf) chunks chunk_text(pdf_text) vs VectorStore() vs.add_documents(chunks) test_results vs.search_similar(产品特性, top_k2) for res in test_results: print(res[content][:200]) else: build_and_query()关键点解析提示词工程_build_prompt方法构建了给 LLM 的指令。它明确要求模型“基于上下文”并指示在无法回答时如实告知。这是控制幻觉的关键。提示词的设计是 RAG 效果优化的核心环节之一。上下文管理我们将检索到的多个文档块合并成一个上下文字符串。需要确保总长度不超过 LLM 的上下文窗口限制。top_k参数和块大小共同决定了上下文的总长度。LLM 调用参数temperature0.1设置了一个较低的“温度”使模型输出更确定、更少随机性这对于基于事实的问答很重要。答案溯源返回结果中包含了sources其中列出了用于生成答案的文档片段及其相似度分数和元数据。这提供了可解释性让用户知道答案的依据是什么。模块化设计RAGPipeline类与特定的向量存储和 LLM 解耦。你可以轻松地将OpenAI替换为ChatGLM、Qwen的 API 或本地部署的Llama.cpp。7. 运行、验证与效果评估7.1 如何运行整个项目准备文档将你的product_manual.pdf文件放在项目根目录。设置环境变量如果使用 OpenAIexport OPENAI_API_KEYyour-api-key-here运行主流程python rag_pipeline.py预期输出你会看到文档被加载、分割、向量化并存储。然后程序会针对预设的问题进行检索和回答并打印出答案和参考来源。7.2 如何验证系统工作正常检查向量数据库运行后会生成一个./chroma_db文件夹里面存储了所有向量和元数据。独立测试检索你可以修改rag_pipeline.py中的测试问题或者单独运行vector_store.py的测试代码观察检索到的文档是否与问题相关。评估答案质量相关性答案是否直接回答了问题忠实性答案是否严格基于提供的上下文有没有“幻觉”出上下文没有的信息完整性答案是否涵盖了上下文中的所有相关要点可读性答案是否通顺、清晰7.3 如果效果不理想第一步查哪里RAG 系统效果不佳通常不是 LLM 的错问题往往出在前面的环节。请按以下顺序排查检索质量这是问题的根源。首先检查检索到的文档是否真的包含了问题的答案。检查检索结果在RAGPipeline.ask方法中打印出retrieved_docs看内容是否相关。调整top_k增加top_k值例如从 3 到 10看看是否能召回正确答案所在的块。分块策略答案可能因为不恰当的分块而被切断或稀释。调整块大小和重叠尝试更大的chunk_size或更大的chunk_overlap。尝试语义分块如果固定长度分块效果差可以考虑使用更高级的语义分块库。嵌入模型模型是否适合你的文本语言和领域更换模型如果主要是中文尝试BAAI/bge-large-zh-v1.5。如果是多语言尝试intfloat/multilingual-e5-large。检查向量归一化确保生成和查询嵌入时都设置了normalize_embeddingsTrue。提示词LLM 是否理解了你的指令优化提示词让指令更明确例如“请严格根据以下上下文用列表形式总结...”。提供少样本示例在提示词中给出一两个问答示例引导模型输出你期望的格式。8. 进阶优化与生产环境最佳实践一个能跑的 RAG 原型和一个健壮的生产系统之间还有很长的路要走。以下是一些关键的优化方向和实践建议8.1 优化检索效果混合检索结合稠密向量检索本文所用和稀疏检索如 BM25。向量检索擅长语义匹配BM25 擅长关键词匹配两者结合可以提升召回率。LangChain 等框架有现成的实现。重排序如前所述使用专门的Reranker 模型如BGE-Reranker对初步检索到的结果进行精排可以显著提升 Top 1 或 Top 3 的精度。元数据过滤在检索时加入过滤条件。例如当用户问“第三章的内容”你可以先过滤metadata中chapter字段为3的文档块再进行向量相似度搜索。ChromaDB、Milvus 都支持元数据过滤。8.2 优化分块策略分层索引创建多级索引。例如小块如段落用于精准答案检索大块如整节用于需要更多上下文的概括性问题。查询时可以先在小块中找答案如果需要更多背景再引用对应的大块。基于内容的动态分块对于结构清晰的文档如 Markdown可以根据标题层级H1, H2, H3进行分块并将标题作为元数据。8.3 工程化与部署异步处理文档解析、向量化都是计算密集型任务应使用异步队列如 Celery, Dramatiq处理避免阻塞 Web 服务。增量更新设计文档的增量更新机制识别新增、修改或删除的文档只更新受影响的部分而不是全量重建索引。监控与日志记录每次查询的检索结果、LLM 输入输出、耗时、Token 消耗等用于效果分析和成本核算。缓存对常见问题或高频查询的结果进行缓存可以大幅降低延迟和成本。评估体系建立离线评估数据集定期评估系统的回答准确率、幻觉率等指标指导迭代优化。8.4 安全与权限输入检查对用户查询进行基本的清洗和检查防止 Prompt 注入攻击。输出审查对于关键业务可以考虑对 LLM 的输出进行二次审查或过滤。数据隔离在多租户场景下确保向量数据库中的数据有严格的权限隔离。从 PDF 文档到智能问答我们走通了一个完整 RAG 系统的最小闭环。这个流程的核心价值在于其清晰的模块化思想Chunking、Embedding、Vector Storage、Retrieval、Generation每个环节都可以独立优化和替换。选择 ChromaDB 和 BGE 嵌入模型是为了用最低的复杂度演示核心逻辑。当你需要应对更大规模、更高并发的生产需求时将向量数据库替换为 Milvus 或 Qdrant将分块策略升级为语义分块引入 Reranker 模型都是平滑的演进路径。RAG 不是一个“设置好就一劳永逸”的系统而是一个需要持续调优的工程。最重要的调优杠杆往往在数据预处理分块和检索环节而不是盲目更换更大的 LLM。建议你从一个小而具体的文档集开始按照本文的步骤搭建基线系统然后有目的地进行 A/B 测试观察不同分块大小、不同嵌入模型、不同top_k参数对最终答案质量的影响。只有通过这种实验驱动的迭代你才能构建出真正解决业务问题的、健壮的 RAG 应用。 从零构建RAG问答系统：基于私有文档的智能检索增强生成实战
如果你正在尝试让大语言模型LLM回答你公司内部文档、产品手册或私有知识库里的问题大概率会得到两种令人沮丧的结果要么是“根据我的训练数据我无法回答这个问题”要么是它开始一本正经地“胡说八道”幻觉。这背后的核心矛盾在于LLM 的强大能力源于其海量的通用预训练数据但它无法“记住”或“理解”你私有的、最新的、非公开的信息。解决这个矛盾正是 RAG检索增强生成技术爆火的原因。它承诺让 LLM 拥有“外挂大脑”通过检索外部知识来生成更准确、更相关的回答。然而当你真正开始动手搭建一个 RAG 系统时往往会发现事情没那么简单Embedding 模型怎么选文本切分Chunking到底多长合适向量数据库那么多哪个适合我这些看似独立的组件如何协同工作才能让整个系统真正可用而不是一个“玩具”本文将从零开始为你拆解 RAG 的完整技术栈。我们不会停留在概念层面而是聚焦于实战如何将一份 PDF 文档通过 Embedding、Chunking、向量存储与检索最终构建一个能精准回答问题的问答系统。我们将使用当前主流且易于上手的工具链如 Sentence Transformers、ChromaDB并提供每一步的完整代码和配置确保你能亲手复现。无论你是想快速搭建一个原型还是为生产环境做技术选型这篇文章都将提供清晰的路径和关键的避坑指南。1. RAG 要解决的核心问题为什么不是微调在深入技术细节前我们必须先回答一个根本问题为什么是 RAG而不是微调Fine-tuning很多开发者的第一反应是既然模型不知道我的数据那我用我的数据去训练微调它不就行了这个想法很自然但在实践中RAG 和微调解决的是不同维度的问题而 RAG 在大多数知识增强场景下成本更低、更灵活、风险更小。微调的本质是“改变模型的行为和知识”。你通过大量数据让模型学习新的模式或知识并将其“固化”到模型的权重中。这适用于风格迁移让模型学会用某种特定的口吻如客服、法律文书写作。任务适配让一个通用模型在特定任务如代码生成、医疗诊断上表现更好。学习私有数据中的深层模式当你的数据蕴含着复杂的、非显性的规律时。但微调有几个显著的挑战成本高昂需要准备高质量的标注数据计算资源消耗大尤其是对大模型。知识更新困难每次知识库更新都需要重新微调并部署新模型流程冗长。灾难性遗忘在注入新知识的同时可能导致模型遗忘原有的通用能力。可解释性差模型回答的依据是什么很难追溯存在“黑箱”风险。RAG 的本质是“为模型提供临时的上下文参考”。它不改变模型本身而是在模型生成答案前先从外部知识库中检索出最相关的文档片段并将其作为“提示词”的一部分交给模型。这相当于在考试时允许模型开卷查阅指定的资料。RAG 的优势恰恰对应了微调的劣势低成本、快迭代知识库更新只需重新处理文档并存入向量数据库无需动模型。知识可追溯模型给出的答案通常基于检索到的文档来源清晰便于验证和审计。缓解幻觉通过提供事实依据约束模型的生成减少编造。模块化检索器Retriever、向量数据库、LLM 可以独立升级和替换。因此对于绝大多数“基于私有文档的智能问答”场景RAG 是更务实、更高效的起点。它让你能快速验证想法构建原型并以较低的成本维护一个动态更新的知识系统。2. 核心组件拆解Embedding, Chunking, 向量数据库一个典型的 RAG 系统工作流程可以概括为“索引”和“查询”两个阶段涉及四个核心组件原始文档 -- [文本加载与分割 Chunking] -- 文本块 -- [向量化 Embedding] -- 向量 -- [向量数据库存储] | v 用户问题 -- [向量化 Embedding] -- 问题向量 -- [向量数据库检索] -- 相关文本块 -- [LLM 生成答案]下面我们逐一拆解每个组件的职责、技术选型和关键决策点。2.1 Chunking如何把文档“切”得恰到好处Chunking分块是 RAG 流水线的第一步也是最容易被低估的一步。切分的好坏直接决定了检索的精度。切得太碎上下文信息丢失切得太大会引入无关噪声且超出 LLM 的上下文窗口。核心策略固定大小分块最简单的方法按字符或 token 数切分如每块 500 字符。优点是简单缺点是不顾语义边界可能把一句话或一个概念拦腰截断。基于分隔符分块利用自然段落标记如\n\n、标题#、句号等进行切分。更符合阅读习惯但块大小可能不均。语义分块使用嵌入模型或小型模型计算句子间的相似度在语义变化处切分。这是更高级的方法能更好地保持语义单元完整但计算开销稍大。递归分块先按大分隔符如章节切如果块太大再按小分隔符如段落递归切分。这是 LangChain、LlamaIndex 等框架常用的稳健策略。滑动窗口分块在固定大小分块的基础上让块之间有一定重叠如 50 字符。这能确保关键信息出现在块边界时依然能被检索到是提升召回率的有效技巧。实战建议从递归分块滑动窗口开始这是平衡效果和复杂度的最佳起点。例如先按\n\n分段落对超过 500 字符的段落再按句子分隔符.切分并设置 10% 的重叠。块大小需要实验没有银弹。对于技术文档256-512 token 可能合适对于长篇小说1024 token 的块可能更好。一个重要的原则是你的块大小应该与你期望模型用来生成答案的上下文长度相匹配。保留元数据切分时务必记录每个块的来源文件名、页码、章节标题。这在后续溯源时至关重要。2.2 Embedding把文字变成机器能“理解”的数字Embedding嵌入是将文本词、句、段落映射为一个固定长度的稠密向量一列数字的过程。这个向量在高维空间中代表了文本的语义。语义相似的文本其向量在空间中的距离如余弦相似度也更近。关键概念嵌入模型执行向量化的模型如text-embedding-ada-002(OpenAI)、BGE-M3(智源)、multilingual-e5-large(微软)。向量维度向量的长度如 768、1024、1536。维度越高通常表征能力越强但存储和计算成本也越高。相似度度量余弦相似度、点积、欧氏距离。最常用的是余弦相似度它关注向量的方向而非大小对文本相似度任务更鲁棒。模型选型考量语言你的文档主要是中文、英文还是多语言BGE-M3和multilingual-e5-large在多语言上表现优异。领域通用模型 vs. 领域模型如医学、法律。通常先从强大的通用模型开始。性能与开销模型越大效果可能越好但编码速度越慢。需要在延迟和精度间权衡。上下文长度模型能处理的最大文本长度。BGE-M3支持 8192 token适合长文档。一个重要趋势Embedding 与 Rerank 分离。为了平衡检索速度和精度先进的做法是第一轮检索召回使用一个速度快、容量大的嵌入模型如BGE-M3从向量数据库中召回 Top K如 20个相关块。第二轮重排序精排使用一个更精准但稍慢的重排序模型Reranker如BGE-Reranker对召回的 20 个块进行重新打分和排序选出最相关的 Top N如 3-5个块送给 LLM。 这种方式用较小的计算代价显著提升了最终上下文的质量。2.3 向量数据库海量向量的“管家”向量数据库专门为高效存储、索引和检索高维向量而设计。当你有百万甚至千万级的文档块时简单的线性扫描计算问题与所有块的相似度是不可行的。向量数据库的核心是近似最近邻搜索算法它用精度换速度快速找到最相似的向量。主流开源选型对比数据库主要特点适用场景上手难度ChromaDB轻量、易用、Python/JS 原生友好内置 Embedding 功能。原型开发、中小规模项目、学习入门。★☆☆☆☆Milvus功能全面、性能强劲、云原生设计支持标量过滤、动态 Schema。大规模生产环境、需要复杂查询和超高吞吐。★★★☆☆QdrantRust 编写性能优异API 设计清晰支持多种数据类型和过滤。对性能和资源效率要求高的生产环境。★★☆☆☆Weaviate更像一个“向量化”的图数据库支持 GraphQL内置模块化设计。需要结合向量搜索和对象关系查询的场景。★★☆☆☆PGVectorPostgreSQL 的扩展直接在关系数据库中处理向量。已有 PostgreSQL 生态希望简化技术栈。★★☆☆☆如何选择快速验证想法ChromaDB是不二之选。它几乎零配置几行代码就能跑起来非常适合学习和构建 MVP最小可行产品。准备上生产需要评估数据规模、查询 QPS、团队技术栈。Milvus和Qdrant是强有力的竞争者。本文实战选择为了聚焦 RAG 核心逻辑降低环境复杂度我们将使用ChromaDB。它的简单性让我们能更清晰地展示从文档到问答的完整链路。3. 环境准备构建可复现的 Python 环境在开始编码前我们需要一个干净的 Python 环境。强烈建议使用 Conda 或 venv 创建虚拟环境。# 1. 创建并激活虚拟环境 (以 conda 为例) conda create -n rag_demo python3.10 conda activate rag_demo # 2. 安装核心库 pip install chromadb sentence-transformers pypdf2 langchain # 可选安装 tiktoken 用于精确的 token 计数如果你使用 OpenAI 模型 # pip install tiktoken # 3. 验证安装 python -c import chromadb; import sentence_transformers; print(环境准备OK)库说明chromadb: 轻量级向量数据库。sentence-transformers: 一个非常流行的框架方便地使用各种 Sentence Embedding 模型我们用它来加载 BGE 等开源模型。pypdf2: 用于解析 PDF 文档提取文本。langchain: 一个流行的 LLM 应用开发框架。这里我们主要借用其优秀的文本分割器你也可以用其他方法替代。4. 实战第一步文档加载与智能分块 (Chunking)假设我们有一份名为product_manual.pdf的产品手册。第一步是读取它并将其切分成有意义的文本块。# file: doc_processor.py import PyPDF2 from langchain.text_splitter import RecursiveCharacterTextSplitter from typing import List, Dict import hashlib def load_pdf_text(pdf_path: str) - str: 从PDF文件中提取纯文本 text try: with open(pdf_path, rb) as file: reader PyPDF2.PdfReader(file) for page_num in range(len(reader.pages)): page reader.pages[page_num] text page.extract_text() f\n[Page {page_num 1}]\n except Exception as e: print(f读取PDF文件失败: {e}) raise return text def chunk_text(text: str, chunk_size: int 500, chunk_overlap: int 50) - List[Dict]: 使用递归字符分割器对文本进行分块。 返回一个字典列表每个字典包含文本块内容和元数据。 # 初始化分割器 text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, # 每个块的最大字符数 chunk_overlapchunk_overlap, # 块之间的重叠字符数 length_functionlen, # 计算长度的方法 separators[\n\n, \n, 。, , , , , , ] # 分隔符优先级 ) # 生成文本块 chunks text_splitter.split_text(text) # 为每个块生成唯一ID并附加元数据 documents [] for i, chunk in enumerate(chunks): # 生成一个基于内容的简单ID (实际生产环境可能需要更稳健的方法) chunk_id hashlib.md5(chunk.encode()).hexdigest()[:16] doc { id: fchunk_{i}_{chunk_id}, text: chunk, metadata: { chunk_index: i, char_count: len(chunk), # 注意这里简化了实际应该从原文中解析出更精确的页码/章节 source: product_manual.pdf } } documents.append(doc) print(f原始文本被分割成 {len(documents)} 个块。) print(f示例块 (前200字符): {documents[0][text][:200]}...) return documents if __name__ __main__: # 测试代码 pdf_text load_pdf_text(product_manual.pdf) # 请确保该文件存在 chunks chunk_text(pdf_text)关键点解析RecursiveCharacterTextSplitter这是 LangChain 提供的一个稳健的分割器。它会按separators列表的顺序尝试分割。例如先尝试用双换行\n\n分如果分出来的块还是太大就用单换行\n分以此类推直到满足大小要求。chunk_overlap设置重叠是为了防止一个完整的句子或概念被切到两个块的边缘导致检索时丢失关键信息。10% 左右的重叠是一个不错的起点。元数据我们为每个块附加了metadata。在生产系统中你需要在解析 PDF 时更精细地记录页码、章节标题等信息这对于答案溯源至关重要。块大小这里用了 500 字符。你需要根据你的文档类型和后续使用的 LLM 上下文窗口来调整。例如如果使用 GPT-4 的 128K 窗口你可以用更大的块如 2000 字符来保留更多上下文。5. 实战第二步文本向量化与存储 (Embedding ChromaDB)有了文本块接下来就是用 Embedding 模型将它们转化为向量并存入 ChromaDB。# file: vector_store.py import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer import time from typing import List class VectorStore: def __init__(self, embedding_model_name: str BAAI/bge-small-zh-v1.5, persist_directory: str ./chroma_db): 初始化向量存储。 :param embedding_model_name: 使用的嵌入模型名称 :param persist_directory: ChromaDB 数据持久化目录 # 1. 初始化嵌入模型 print(f正在加载嵌入模型: {embedding_model_name}...) self.embed_model SentenceTransformer(embedding_model_name) print(嵌入模型加载完毕。) # 2. 初始化 ChromaDB 客户端 (持久化模式) self.client chromadb.PersistentClient(pathpersist_directory) # 3. 获取或创建集合Collection。集合类似于数据库中的表。 # 我们指定使用余弦相似度进行搜索。 self.collection self.client.get_or_create_collection( nameproduct_manual, metadata{hnsw:space: cosine} # 使用余弦相似度 ) print(f向量数据库集合 product_manual 已就绪。) def generate_embeddings(self, texts: List[str]) - List[List[float]]: 为文本列表生成嵌入向量 # SentenceTransformer 的 encode 方法直接返回向量列表 embeddings self.embed_model.encode( texts, normalize_embeddingsTrue, # 归一化向量便于使用余弦相似度 show_progress_barTrue ).tolist() # 转换为 Python list return embeddings def add_documents(self, documents: List[Dict]): 将文档块添加到向量数据库。 :param documents: 由 doc_processor.chunk_text 生成的文档字典列表 if not documents: print(没有文档可添加。) return # 准备数据 ids [doc[id] for doc in documents] texts [doc[text] for doc in documents] metadatas [doc[metadata] for doc in documents] print(f正在为 {len(texts)} 个文档块生成嵌入向量...) start_time time.time() embeddings self.generate_embeddings(texts) elapsed time.time() - start_time print(f嵌入向量生成完成耗时 {elapsed:.2f} 秒。) # 添加到集合 print(正在将向量存入数据库...) self.collection.add( embeddingsembeddings, documentstexts, metadatasmetadatas, idsids ) print(f成功添加 {len(ids)} 个文档块到向量数据库。) def search_similar(self, query: str, top_k: int 5) - List[Dict]: 根据查询文本检索最相似的文档块。 :param query: 查询文本 :param top_k: 返回最相似的结果数量 :return: 包含文档内容和元数据的字典列表 # 1. 将查询文本向量化 query_embedding self.embed_model.encode( query, normalize_embeddingsTrue ).tolist() # 2. 在集合中搜索 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k, include[documents, metadatas, distances] # 返回文档、元数据和相似度距离 ) # 3. 格式化结果 retrieved_docs [] if results[documents]: for i in range(len(results[documents][0])): doc_info { content: results[documents][0][i], metadata: results[metadatas][0][i], score: 1 - results[distances][0][i] # 将距离转换为相似度分数 (余弦) } retrieved_docs.append(doc_info) return retrieved_docs if __name__ __main__: # 测试假设我们已经有了 chunks from doc_processor import chunk_text, load_pdf_text pdf_text load_pdf_text(product_manual.pdf) chunks chunk_text(pdf_text) # 初始化向量存储并添加文档 vs VectorStore() vs.add_documents(chunks) # 测试检索 test_query 这款产品的主要特性是什么 print(f\n测试查询: {test_query}) search_results vs.search_similar(test_query, top_k3) for i, res in enumerate(search_results): print(f\n--- 结果 {i1} (相似度: {res[score]:.4f}) ---) print(f内容: {res[content][:150]}...) print(f元数据: {res[metadata]})关键点解析嵌入模型选择我们使用了BAAI/bge-small-zh-v1.5这是一个优秀的中英文双语小模型速度快效果不错非常适合演示和中小规模应用。你可以根据需要替换为BAAI/bge-large-zh-v1.5效果更好但更慢或其他模型。normalize_embeddingsTrue这是关键一步它将向量归一化为单位长度。此时向量间的点积就等于余弦相似度。ChromaDB 的cosine空间需要配合归一化的向量才能正确工作。持久化PersistentClient会将数据保存在本地./chroma_db目录下次运行程序时数据依然存在无需重新处理文档。搜索返回collection.query返回的结果包含了原始文档、元数据和距离。余弦距离的范围是 [0, 2]0 表示完全相同2 表示完全相反。我们将其转换为相似度分数1 - distance使其范围在 [-1, 1] 之间分数越高越相似。6. 实战第三步组装 RAG 链调用 LLM 生成答案现在我们有了一个可以检索相关文档的“大脑”。最后一步是将检索到的文档作为上下文与用户问题一起提交给 LLM让它生成最终答案。# file: rag_pipeline.py import os from vector_store import VectorStore from doc_processor import load_pdf_text, chunk_text # 这里我们使用 OpenAI API 作为 LLM 示例。你也可以替换为其他 API 或本地模型。 from openai import OpenAI # 请确保设置了环境变量 OPENAI_API_KEY # export OPENAI_API_KEYyour-api-key class RAGPipeline: def __init__(self, vector_store: VectorStore, llm_model: str gpt-3.5-turbo): self.vs vector_store self.llm_client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.llm_model llm_model def _build_prompt(self, query: str, contexts: List[Dict]) - str: 构建给 LLM 的提示词 context_str \n\n.join([f[出处 {i1}]: {ctx[content]} for i, ctx in enumerate(contexts)]) prompt f请你基于以下提供的上下文信息回答用户的问题。如果上下文信息不足以回答问题请直接说“根据提供的信息我无法回答这个问题”不要编造信息。 上下文信息 {context_str} 用户问题{query} 请用中文给出清晰、准确的答案并尽量引用上下文中的具体信息。如果答案涉及多个要点请分条列出。 return prompt def ask(self, query: str, top_k: int 5) - Dict: 执行完整的 RAG 流程检索 - 构建提示 - LLM生成。 :return: 包含答案、参考来源和原始检索结果的字典 # 1. 检索相关文档 retrieved_docs self.vs.search_similar(query, top_ktop_k) if not retrieved_docs: return { answer: 未检索到相关文档信息。, sources: [], retrieved_docs: [] } # 2. 构建提示词 prompt self._build_prompt(query, retrieved_docs) # 3. 调用 LLM 生成答案 try: response self.llm_client.chat.completions.create( modelself.llm_model, messages[ {role: system, content: 你是一个专业的助手严格根据提供的上下文信息回答问题。}, {role: user, content: prompt} ], temperature0.1, # 低温度使输出更确定更贴近上下文 max_tokens1000 ) answer response.choices[0].message.content.strip() except Exception as e: answer f调用语言模型时出错: {e} # 4. 整理来源信息 sources [{content: doc[content][:200], metadata: doc[metadata], score: doc[score]} for doc in retrieved_docs] return { answer: answer, sources: sources, retrieved_docs: retrieved_docs # 保留完整检索结果用于调试 } def build_and_query(): 完整的构建索引和查询示例 # Step 1: 处理文档并构建向量索引 (如果尚未构建) print( 步骤1: 处理文档并构建向量索引 ) pdf_text load_pdf_text(product_manual.pdf) chunks chunk_text(pdf_text) vs VectorStore(persist_directory./chroma_db) # 注意在实际应用中应先检查集合是否已有数据避免重复添加。 # 这里为了演示我们假设每次都是新的。 # 你可以通过 vs.collection.count() 来判断。 if vs.collection.count() 0: vs.add_documents(chunks) else: print(向量数据库中已有数据跳过添加。) # Step 2: 初始化 RAG 管道 print(\n 步骤2: 初始化 RAG 管道 ) rag RAGPipeline(vs) # Step 3: 进行问答 print(\n 步骤3: 开始问答 ) questions [ 这款产品支持哪些操作系统, 如何重置设备到出厂设置, 产品的保修期是多久 ] for q in questions: print(f\n用户问题: {q}) result rag.ask(q, top_k3) print(fAI 答案: {result[answer]}) print(参考来源:) for i, src in enumerate(result[sources]): print(f [{i1}] 相似度 {src[score]:.3f}: {src[content]}...) print(- * 50) if __name__ __main__: # 确保已设置 OPENAI_API_KEY 环境变量 if not os.getenv(OPENAI_API_KEY): print(错误: 请设置 OPENAI_API_KEY 环境变量。) # 作为演示如果没有 API KEY我们可以只运行到检索步骤 print(将仅演示文档处理和检索步骤跳过 LLM 生成。) from vector_store import VectorStore from doc_processor import load_pdf_text, chunk_text pdf_text load_pdf_text(product_manual.pdf) chunks chunk_text(pdf_text) vs VectorStore() vs.add_documents(chunks) test_results vs.search_similar(产品特性, top_k2) for res in test_results: print(res[content][:200]) else: build_and_query()关键点解析提示词工程_build_prompt方法构建了给 LLM 的指令。它明确要求模型“基于上下文”并指示在无法回答时如实告知。这是控制幻觉的关键。提示词的设计是 RAG 效果优化的核心环节之一。上下文管理我们将检索到的多个文档块合并成一个上下文字符串。需要确保总长度不超过 LLM 的上下文窗口限制。top_k参数和块大小共同决定了上下文的总长度。LLM 调用参数temperature0.1设置了一个较低的“温度”使模型输出更确定、更少随机性这对于基于事实的问答很重要。答案溯源返回结果中包含了sources其中列出了用于生成答案的文档片段及其相似度分数和元数据。这提供了可解释性让用户知道答案的依据是什么。模块化设计RAGPipeline类与特定的向量存储和 LLM 解耦。你可以轻松地将OpenAI替换为ChatGLM、Qwen的 API 或本地部署的Llama.cpp。7. 运行、验证与效果评估7.1 如何运行整个项目准备文档将你的product_manual.pdf文件放在项目根目录。设置环境变量如果使用 OpenAIexport OPENAI_API_KEYyour-api-key-here运行主流程python rag_pipeline.py预期输出你会看到文档被加载、分割、向量化并存储。然后程序会针对预设的问题进行检索和回答并打印出答案和参考来源。7.2 如何验证系统工作正常检查向量数据库运行后会生成一个./chroma_db文件夹里面存储了所有向量和元数据。独立测试检索你可以修改rag_pipeline.py中的测试问题或者单独运行vector_store.py的测试代码观察检索到的文档是否与问题相关。评估答案质量相关性答案是否直接回答了问题忠实性答案是否严格基于提供的上下文有没有“幻觉”出上下文没有的信息完整性答案是否涵盖了上下文中的所有相关要点可读性答案是否通顺、清晰7.3 如果效果不理想第一步查哪里RAG 系统效果不佳通常不是 LLM 的错问题往往出在前面的环节。请按以下顺序排查检索质量这是问题的根源。首先检查检索到的文档是否真的包含了问题的答案。检查检索结果在RAGPipeline.ask方法中打印出retrieved_docs看内容是否相关。调整top_k增加top_k值例如从 3 到 10看看是否能召回正确答案所在的块。分块策略答案可能因为不恰当的分块而被切断或稀释。调整块大小和重叠尝试更大的chunk_size或更大的chunk_overlap。尝试语义分块如果固定长度分块效果差可以考虑使用更高级的语义分块库。嵌入模型模型是否适合你的文本语言和领域更换模型如果主要是中文尝试BAAI/bge-large-zh-v1.5。如果是多语言尝试intfloat/multilingual-e5-large。检查向量归一化确保生成和查询嵌入时都设置了normalize_embeddingsTrue。提示词LLM 是否理解了你的指令优化提示词让指令更明确例如“请严格根据以下上下文用列表形式总结...”。提供少样本示例在提示词中给出一两个问答示例引导模型输出你期望的格式。8. 进阶优化与生产环境最佳实践一个能跑的 RAG 原型和一个健壮的生产系统之间还有很长的路要走。以下是一些关键的优化方向和实践建议8.1 优化检索效果混合检索结合稠密向量检索本文所用和稀疏检索如 BM25。向量检索擅长语义匹配BM25 擅长关键词匹配两者结合可以提升召回率。LangChain 等框架有现成的实现。重排序如前所述使用专门的Reranker 模型如BGE-Reranker对初步检索到的结果进行精排可以显著提升 Top 1 或 Top 3 的精度。元数据过滤在检索时加入过滤条件。例如当用户问“第三章的内容”你可以先过滤metadata中chapter字段为3的文档块再进行向量相似度搜索。ChromaDB、Milvus 都支持元数据过滤。8.2 优化分块策略分层索引创建多级索引。例如小块如段落用于精准答案检索大块如整节用于需要更多上下文的概括性问题。查询时可以先在小块中找答案如果需要更多背景再引用对应的大块。基于内容的动态分块对于结构清晰的文档如 Markdown可以根据标题层级H1, H2, H3进行分块并将标题作为元数据。8.3 工程化与部署异步处理文档解析、向量化都是计算密集型任务应使用异步队列如 Celery, Dramatiq处理避免阻塞 Web 服务。增量更新设计文档的增量更新机制识别新增、修改或删除的文档只更新受影响的部分而不是全量重建索引。监控与日志记录每次查询的检索结果、LLM 输入输出、耗时、Token 消耗等用于效果分析和成本核算。缓存对常见问题或高频查询的结果进行缓存可以大幅降低延迟和成本。评估体系建立离线评估数据集定期评估系统的回答准确率、幻觉率等指标指导迭代优化。8.4 安全与权限输入检查对用户查询进行基本的清洗和检查防止 Prompt 注入攻击。输出审查对于关键业务可以考虑对 LLM 的输出进行二次审查或过滤。数据隔离在多租户场景下确保向量数据库中的数据有严格的权限隔离。从 PDF 文档到智能问答我们走通了一个完整 RAG 系统的最小闭环。这个流程的核心价值在于其清晰的模块化思想Chunking、Embedding、Vector Storage、Retrieval、Generation每个环节都可以独立优化和替换。选择 ChromaDB 和 BGE 嵌入模型是为了用最低的复杂度演示核心逻辑。当你需要应对更大规模、更高并发的生产需求时将向量数据库替换为 Milvus 或 Qdrant将分块策略升级为语义分块引入 Reranker 模型都是平滑的演进路径。RAG 不是一个“设置好就一劳永逸”的系统而是一个需要持续调优的工程。最重要的调优杠杆往往在数据预处理分块和检索环节而不是盲目更换更大的 LLM。建议你从一个小而具体的文档集开始按照本文的步骤搭建基线系统然后有目的地进行 A/B 测试观察不同分块大小、不同嵌入模型、不同top_k参数对最终答案质量的影响。只有通过这种实验驱动的迭代你才能构建出真正解决业务问题的、健壮的 RAG 应用。