1. 项目概述RAG实战的“瑞士军刀”最近在折腾大语言模型应用落地的朋友估计没少为RAG检索增强生成这件事头疼。理论都懂论文也看了不少但真要把一个能稳定上线的RAG系统从零搭起来中间要踩的坑可太多了。数据怎么清洗、向量模型怎么选、检索策略怎么定、效果怎么评估……每一步都是学问。所以当我看到huangjia2019/rag-in-action这个项目时第一反应是这很可能是一个“实战派”的宝库。它不是一个简单的教程更像是一个汇集了多种RAG实现方案、工具链和最佳实践的“工具箱”或“脚手架”。对于想快速验证想法、对比不同技术路线或者需要一个坚实起点的开发者来说这类项目价值巨大。它跳过了冗长的理论铺垫直接切入“怎么做”和“为什么这么做”这正是我们一线工程师最需要的。这个项目名为“RAG in Action”直译就是“实战中的RAG”。它的核心目标很明确提供一个可运行、可修改、可扩展的RAG系统实现覆盖从数据准备、向量化、检索到生成的全链路。它可能集成了诸如LangChain、LlamaIndex等流行框架也可能封装了Chroma、Milvus等向量数据库甚至提供了对多种开源和闭源大模型的接入支持。更重要的是一个优秀的实战项目通常会包含大量“胶水代码”和“经验之谈”比如如何处理PDF表格、怎么应对长文档的上下文窗口限制、检索结果重排序Re-ranking的实用技巧等这些都是在官方文档里找不到的“硬核干货”。接下来我们就深入这个“工具箱”看看一个成熟的RAG实战项目应该如何设计里面有哪些关键模块以及如何基于它快速构建你自己的智能问答、知识库助手或企业级应用。2. 核心架构与设计思路拆解一个健壮的RAG系统远不止是“向量搜索 LLM”的简单拼接。rag-in-action这类项目通常会采用分层、模块化的设计确保每个环节都可插拔、可观测、可优化。2.1 模块化设计清晰的责任边界典型的架构会分为以下几个核心层数据接入与预处理层这是流水线的起点。需要处理多种格式的原始数据TXT、PDF、Word、PPT、HTML、Markdown等。这一层的挑战在于格式解析的准确性和内容提取的完整性。例如PDF中的图文混排、扫描件OCR、表格数据的结构化提取都是难点。一个好的项目会集成像pymupdf、pdfplumber、unstructured这样的库并针对中文排版做特别优化。文本分割与向量化层预处理后的纯文本需要被切割成适合检索的片段Chunk。这里的设计考量非常多分割策略是按固定长度、按句子、按段落还是按语义分割固定长度简单但可能割裂语义按语义分割如使用sentence-transformers的语义分割模型效果更好但计算开销大。实战项目往往会提供多种策略供选择。Chunk大小与重叠Chunk太大检索精度低且可能超出LLM上下文窗口Chunk太小则可能丢失关键上下文。通常设置一个重叠区Overlap例如前一个Chunk的结尾部分与下一个Chunk的开头部分重复100-200个字符可以保证检索结果的连贯性。向量化模型这是RAG的“心脏”。选择什么样的嵌入模型Embedding Model直接决定了检索质量。项目可能会集成text2vec、BGE、OpenAI text-embedding-ada-002等。关键是要考虑模型的语义理解能力、支持的长度、推理速度以及对中文的适配程度。向量存储与检索层负责存储向量并执行相似性搜索。这一层需要平衡性能、精度和成本。存储选型轻量级如ChromaDB、FAISS本地内存/磁盘需要持久化和分布式可考虑Milvus、Qdrant、Weaviate。项目通常会封装一层统一的接口方便切换底层存储。检索策略最基础的是稠密向量检索Dense Retrieval。进阶玩法包括混合检索Hybrid Search结合关键词BM25和向量检索、多向量检索为同一个Chunk生成多个不同粒度的向量、以及检索后的重排序Re-ranking。重排序模型如bge-reranker虽然会增加少量延迟但能显著提升Top-1结果的准确率是生产级系统的常见配置。大模型生成层将检索到的相关上下文Context与用户问题Query组合成提示词Prompt发送给大模型生成最终答案。这一层的核心是提示词工程和上下文管理。提示词模板如何将检索到的多个Chunk信息清晰、无冲突地组织进Prompt如何设定系统指令System Prompt来约束模型的行为如“仅根据提供的信息回答”项目应提供经过验证的有效模板。上下文窗口管理当检索到的相关文档总长度超过模型上下文限制时如何取舍和压缩这可能涉及更高级的摘要或选择性过滤策略。模型接入应支持主流开源模型如通过Ollama、vLLM本地部署的 Llama、Qwen、GLM系列和云端API如 OpenAI GPT、DeepSeek、通义千问等。评估与反馈层一个容易被忽略但至关重要的部分。如何知道你的RAG系统效果好还是坏项目应集成基本的评估手段例如通过少量标注数据计算“检索命中率”、“答案相关性”等指标或者提供人工评估的界面。更高级的会引入基于LLM的自动评估LLM-as-a-Judge。提示在评估自己搭建的RAG系统时不要只看最终答案的对错。拆解开来分析是检索没找到相关文档还是找到了但Prompt没组织好或者是LLM本身“胡编乱造”幻觉分阶段定位问题效率更高。2.2 配置化与可扩展性一个好的实战项目其价值不仅在于“能用”更在于“好用”和“易改”。它应该通过配置文件如config.yaml或.env来管理所有关键参数模型路径、API密钥、Chunk大小、重叠长度、检索返回数量、温度值等。这样开发者无需修改代码就能进行大量的实验对比。同时每个核心模块如分割器、嵌入模型、向量库、LLM都应定义为接口或抽象类遵循依赖注入原则。当你想把ChromaDB换成Milvus或者把text2vec换成BGE模型时只需要实现对应的接口并在配置中切换核心业务流程代码应保持不动。这种设计极大地提升了项目的工程价值和长期维护性。3. 关键模块深度解析与实操要点让我们聚焦几个最容易出问题也最影响最终效果的核心模块看看在实战中应该如何选择和调优。3.1 文本分割不仅仅是“切豆腐”很多人以为文本分割就是简单按长度切分这是初期效果不佳的常见原因。固定长度分割的陷阱假设你设置chunk_size500。如果一段话在第450个字符处刚好是一个关键概念的定义开始那么它会被残忍地切到下一个Chunk导致前一个Chunk语义不完整检索时可能完全丢失这个关键概念。更优的策略递归字符分割这是LangChain等框架的默认方法。它先尝试按双换行符\n\n分割如果分割后的片段仍然太大再按换行符\n分割还大就按句号.最后再按字符数。这种方法能在一定程度上尊重段落和句子边界。语义分割使用专门的模型如all-MiniLM-L6-v2计算句子间的语义相似度在语义变化较大的地方进行分割。这种方法效果最好但需要额外的模型推理速度较慢适合对质量要求极高的场景。基于标记的分割对于Markdown、LaTeX等有明确结构标记的文档可以按标题#、列表等元素进行分割能更好地保持文档结构。实操建议对于通用文档可以先从“递归字符分割”开始调整chunk_size(如 512-1024) 和chunk_overlap(如 100-200)。务必通过查看分割后的样本来验证效果确保没有把完整的表格、代码块或一句话拆散。3.2 嵌入模型中文场景下的选择嵌入模型是将文本映射到向量空间的关键其质量决定了检索的“天花板”。模型名称特点适用场景注意事项text2vec-large-chinese中文优化开源性能好中文文本相似度计算、检索需本地部署向量维度大1024存储和计算开销稍高BGE (BAAI/bge-large-zh)北京智源出品中文SOTA级别对检索精度要求高的生产环境同样需要本地资源支持中英文有不同尺寸版本可选OpenAI text-embedding-3-small/large云端API简单易用效果稳定快速原型验证、不愿管理模型的服务有API调用成本和网络延迟数据需出境需合规m3e-base/large轻量级中文效果均衡资源受限或对延迟敏感的场景体积小速度快是平衡性能和资源的不错选择选择逻辑数据安全与成本优先选开源模型如BGE或text2vec。开发速度与稳定性优先选云端API如OpenAI。资源与延迟敏感选轻量级模型如m3e。关键步骤向量归一化无论选择哪个模型在将向量存入数据库前务必进行归一化L2 Normalization。这是因为大多数向量数据库如FAISS、Milvus在进行相似性搜索余弦相似度时默认假设向量是归一化的。如果存入未归一化的向量搜索时计算的是内积而非余弦相似度会导致结果不准确。代码上通常就是一行vector vector / np.linalg.norm(vector)。3.3 检索与重排序从“找到一些”到“找到对的”基础向量检索返回的Top-K个结果可能包含一些相关性不高但向量空间距离近的“噪声”。重排序就是为了解决这个问题。混合检索同时使用稀疏检索如BM25和稠密向量检索然后合并结果。BM25对关键词匹配更敏感能捕捉到向量模型可能忽略的精确术语匹配。交叉编码器重排序这是一个计算代价更高但更精准的步骤。它使用一个专门的“重排序模型”如BGE-reranker将用户查询和检索到的每一个候选文档片段进行深度交互计算重新打分。虽然它只处理少量如10个候选文档但能极大提升最终送入LLM的上下文质量。工作流程示例用户查询 - 向量检索 (返回Top-20) - 重排序模型对Top-20重新打分 - 取Top-3 - 组合成Prompt - 发送给LLM这个流程增加了少量延迟约几十到几百毫秒但能显著改善答案质量尤其是在文档库庞大或问题复杂时。4. 从零到一的完整搭建流程假设我们基于rag-in-action项目的思路搭建一个针对本地中文技术文档的问答系统。以下是核心步骤。4.1 环境准备与依赖安装首先创建一个干净的Python环境推荐3.9然后安装核心依赖。一个典型的requirements.txt可能包含# 核心框架 langchain0.1.0 langchain-community0.0.10 # 文档加载与处理 pymupdf # PDF解析 markdown # Markdown解析 unstructured[pdf,docx,pptx] # 多功能解析 # 文本分割与向量化 sentence-transformers # 用于嵌入模型和语义分割 chromadb # 向量数据库轻量级选择 # 或者 pymilvus # 如需更强大的向量库 # 大模型接入 openai # 如需GPT ollama # 如需本地Llama, Qwen等 litellm # 统一API接口 # 工具类 python-dotenv # 管理环境变量 tiktoken # Token计数使用pip install -r requirements.txt安装。建议使用uv或poetry进行更专业的依赖管理。4.2 数据管道构建从原始文档到向量库这是最耗时但也最基础的一步。我们编写一个ingest.py脚本。import os from langchain.document_loaders import DirectoryLoader, PyMuPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma # 1. 加载文档 documents [] data_path ./your_docs for file in os.listdir(data_path): if file.endswith(.pdf): loader PyMuPDFLoader(os.path.join(data_path, file)) documents.extend(loader.load()) # 可以添加更多格式支持如 .md, .docx # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n\n, \n, 。, , , , , 、, , ] ) chunks text_splitter.split_documents(documents) print(f共生成 {len(chunks)} 个文本块。) # 3. 生成嵌入并存入向量库 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, # 选用轻量高效的BGE小模型 model_kwargs{device: cpu}, # 根据情况改为 cuda encode_kwargs{normalize_embeddings: True} # 关键启用归一化 ) # 指定向量库持久化路径 vectorstore_path ./chroma_db vectordb Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directoryvectorstore_path ) vectordb.persist() # 持久化到磁盘 print(f向量库已保存至 {vectorstore_path})关键操作解析RecursiveCharacterTextSplitter的separators参数是针对中文优化的分割符列表按优先级尝试分割。HuggingFaceEmbeddings的encode_kwargs{normalize_embeddings: True}确保了存入向量库的向量是归一化的这是正确检索的关键。Chroma.from_documents方法一次性完成了向量化和存储。对于大规模数据可能需要分批处理以避免内存溢出。4.3 构建检索链与问答接口向量库准备好后我们构建一个query.py来提供问答服务。from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate from langchain_community.llms import OllamaLLM # 假设使用本地Ollama # 或 from langchain_openai import ChatOpenAI # 1. 加载已有的向量库和嵌入模型 embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma(persist_directory./chroma_db, embedding_functionembedding_model) # 2. 定义提示词模板这是控制LLM行为的关键 prompt_template 请严格根据以下提供的上下文信息来回答问题。如果上下文信息中没有明确答案请直接说“根据提供的信息我无法回答这个问题”不要编造信息。 上下文 {context} 问题{question} 请根据上下文给出答案 PROMPT PromptTemplate( templateprompt_template, input_variables[context, question] ) # 3. 初始化大语言模型 llm OllamaLLM(modelqwen2:7b, temperature0.1) # 温度调低减少随机性 # 如果使用OpenAI: llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 4. 创建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 最简单的方式将所有上下文塞进prompt retrievervectordb.as_retriever(search_kwargs{k: 4}), # 检索4个相关块 chain_type_kwargs{prompt: PROMPT}, return_source_documentsTrue # 返回来源文档便于调试 ) # 5. 提问 question 什么是RAG它主要解决什么问题 result qa_chain.invoke({query: question}) print(答案, result[result]) print(\n来源文档) for i, doc in enumerate(result[source_documents]): print(f[{i1}] {doc.page_content[:200]}...) # 打印前200字符代码要点PromptTemplate中的指令非常关键它强制LLM基于上下文回答有效减少了“幻觉”。RetrievalQA的chain_type除了stuff还有map_reduce、refine等用于处理超长上下文但stuff最简单直接。search_kwargs{k: 4}控制了检索返回的文档数量需要根据上下文窗口和问题复杂度调整。return_source_documentsTrue对于调试至关重要你可以看到LLM到底依据了什么材料来生成答案。5. 效果评估与迭代优化系统跑起来只是第一步更重要的是评估和优化。没有评估优化就是盲人摸象。5.1 构建简易评估集创建一个eval_questions.json文件包含一系列问题及其在文档中的标准答案或期望答案。[ { question: RAG的主要优势是什么, reference_answer: RAG通过结合外部知识库增强了LLM的事实性和时效性减少了幻觉并能够处理专业领域知识。, category: 概念理解 }, { question: 在ChromaDB中如何实现过滤检索, reference_answer: 可以使用 where 或 where_document 参数在检索时添加元数据过滤条件。, category: 工具使用 } ]5.2 设计评估指标可以自动化计算的指标检索召回率对于每个问题人工判断检索到的Top-K个文档中是否包含能回答该问题的正确文档。计算比例。答案相关性可用LLM自动评估使用一个更强的LLM如GPT-4作为裁判对比系统生成的答案和参考答案在0-5分之间打分。更实用的方法是人工走查随机抽取一批问题运行系统并仔细检查检索到的文档是否相关检索阶段问题如果文档相关答案是否正确生成阶段问题如果答案错误是文档信息不足还是LLM理解有误或胡编乱造5.3 常见问题排查清单根据人工走查的结果你可以按以下清单定位问题现象可能原因排查方向与优化建议答案完全无关检索失败未找到任何相关文档1. 检查嵌入模型是否适合你的领域尝试换模型。2. 检查文本分割是否合理查看Chunk样本。3. 尝试增大检索数量k。4. 考虑引入混合检索或重排序。答案部分正确部分胡编检索到了部分相关文档但LLM出现了“幻觉”1.强化Prompt指令在Prompt中明确要求“仅根据上下文回答”。2. 检查送入LLM的上下文是否过多、过杂尝试减少k或对检索结果进行摘要。3. 降低LLM的temperature参数如设为0.1。答案冗长或格式不佳LLM行为不受控1. 在系统Prompt中指定回答格式如“请用简洁的列表形式回答”。2. 使用LLM的“系统指令”功能如果支持。回答“无法回答”过于频繁检索阈值过高或Prompt过于严格1. 调整检索的相似度阈值如果向量库支持。2. 微调Prompt将“无法回答”的指令改为“根据上下文我认为...”。处理长文档时答案质量下降上下文窗口限制重要信息被截断1. 尝试chain_typemap_reduce或refine。2. 优化文本分割确保关键信息在单个Chunk内完整。3. 考虑使用能处理更长上下文的模型。5.4 高级优化技巧查询转换在检索前对原始用户问题进行改写或扩展。例如使用LLM将“它怎么用”这样的指代性问题结合对话历史重写为完整的“RAG技术怎么用”。这能显著提升检索效果。元数据过滤在存入向量时为每个Chunk添加元数据如来源文件、章节标题、页码等。检索时可以添加过滤条件如来源文件用户手册.pdf实现更精准的检索。上下文压缩在将检索到的文档送给LLM前先使用一个较小的模型或摘要模型对冗长的文档进行摘要只保留最核心的信息以节省上下文窗口。智能路由对于简单、事实性问题直接走向量检索对于需要推理、总结或多步分析的问题可以走不同的处理流程甚至调用不同的LLM。搭建一个可用的RAG系统可能只需要几天但将其打磨成一个稳定、可靠、高效的生产级系统需要持续的迭代、评估和优化。huangjia2019/rag-in-action这类项目提供的正是这样一个经过实践检验的起点和工具箱。理解其背后的设计原理掌握每个模块的调优方法再结合你自己业务数据的特性进行适配才是从“入门”到“精通”的关键。记住没有放之四海而皆准的最优参数最好的系统永远是那个经过你精心测试和调校的系统。
RAG实战指南：从零搭建检索增强生成系统
发布时间：2026/5/18 20:46:14
1. 项目概述RAG实战的“瑞士军刀”最近在折腾大语言模型应用落地的朋友估计没少为RAG检索增强生成这件事头疼。理论都懂论文也看了不少但真要把一个能稳定上线的RAG系统从零搭起来中间要踩的坑可太多了。数据怎么清洗、向量模型怎么选、检索策略怎么定、效果怎么评估……每一步都是学问。所以当我看到huangjia2019/rag-in-action这个项目时第一反应是这很可能是一个“实战派”的宝库。它不是一个简单的教程更像是一个汇集了多种RAG实现方案、工具链和最佳实践的“工具箱”或“脚手架”。对于想快速验证想法、对比不同技术路线或者需要一个坚实起点的开发者来说这类项目价值巨大。它跳过了冗长的理论铺垫直接切入“怎么做”和“为什么这么做”这正是我们一线工程师最需要的。这个项目名为“RAG in Action”直译就是“实战中的RAG”。它的核心目标很明确提供一个可运行、可修改、可扩展的RAG系统实现覆盖从数据准备、向量化、检索到生成的全链路。它可能集成了诸如LangChain、LlamaIndex等流行框架也可能封装了Chroma、Milvus等向量数据库甚至提供了对多种开源和闭源大模型的接入支持。更重要的是一个优秀的实战项目通常会包含大量“胶水代码”和“经验之谈”比如如何处理PDF表格、怎么应对长文档的上下文窗口限制、检索结果重排序Re-ranking的实用技巧等这些都是在官方文档里找不到的“硬核干货”。接下来我们就深入这个“工具箱”看看一个成熟的RAG实战项目应该如何设计里面有哪些关键模块以及如何基于它快速构建你自己的智能问答、知识库助手或企业级应用。2. 核心架构与设计思路拆解一个健壮的RAG系统远不止是“向量搜索 LLM”的简单拼接。rag-in-action这类项目通常会采用分层、模块化的设计确保每个环节都可插拔、可观测、可优化。2.1 模块化设计清晰的责任边界典型的架构会分为以下几个核心层数据接入与预处理层这是流水线的起点。需要处理多种格式的原始数据TXT、PDF、Word、PPT、HTML、Markdown等。这一层的挑战在于格式解析的准确性和内容提取的完整性。例如PDF中的图文混排、扫描件OCR、表格数据的结构化提取都是难点。一个好的项目会集成像pymupdf、pdfplumber、unstructured这样的库并针对中文排版做特别优化。文本分割与向量化层预处理后的纯文本需要被切割成适合检索的片段Chunk。这里的设计考量非常多分割策略是按固定长度、按句子、按段落还是按语义分割固定长度简单但可能割裂语义按语义分割如使用sentence-transformers的语义分割模型效果更好但计算开销大。实战项目往往会提供多种策略供选择。Chunk大小与重叠Chunk太大检索精度低且可能超出LLM上下文窗口Chunk太小则可能丢失关键上下文。通常设置一个重叠区Overlap例如前一个Chunk的结尾部分与下一个Chunk的开头部分重复100-200个字符可以保证检索结果的连贯性。向量化模型这是RAG的“心脏”。选择什么样的嵌入模型Embedding Model直接决定了检索质量。项目可能会集成text2vec、BGE、OpenAI text-embedding-ada-002等。关键是要考虑模型的语义理解能力、支持的长度、推理速度以及对中文的适配程度。向量存储与检索层负责存储向量并执行相似性搜索。这一层需要平衡性能、精度和成本。存储选型轻量级如ChromaDB、FAISS本地内存/磁盘需要持久化和分布式可考虑Milvus、Qdrant、Weaviate。项目通常会封装一层统一的接口方便切换底层存储。检索策略最基础的是稠密向量检索Dense Retrieval。进阶玩法包括混合检索Hybrid Search结合关键词BM25和向量检索、多向量检索为同一个Chunk生成多个不同粒度的向量、以及检索后的重排序Re-ranking。重排序模型如bge-reranker虽然会增加少量延迟但能显著提升Top-1结果的准确率是生产级系统的常见配置。大模型生成层将检索到的相关上下文Context与用户问题Query组合成提示词Prompt发送给大模型生成最终答案。这一层的核心是提示词工程和上下文管理。提示词模板如何将检索到的多个Chunk信息清晰、无冲突地组织进Prompt如何设定系统指令System Prompt来约束模型的行为如“仅根据提供的信息回答”项目应提供经过验证的有效模板。上下文窗口管理当检索到的相关文档总长度超过模型上下文限制时如何取舍和压缩这可能涉及更高级的摘要或选择性过滤策略。模型接入应支持主流开源模型如通过Ollama、vLLM本地部署的 Llama、Qwen、GLM系列和云端API如 OpenAI GPT、DeepSeek、通义千问等。评估与反馈层一个容易被忽略但至关重要的部分。如何知道你的RAG系统效果好还是坏项目应集成基本的评估手段例如通过少量标注数据计算“检索命中率”、“答案相关性”等指标或者提供人工评估的界面。更高级的会引入基于LLM的自动评估LLM-as-a-Judge。提示在评估自己搭建的RAG系统时不要只看最终答案的对错。拆解开来分析是检索没找到相关文档还是找到了但Prompt没组织好或者是LLM本身“胡编乱造”幻觉分阶段定位问题效率更高。2.2 配置化与可扩展性一个好的实战项目其价值不仅在于“能用”更在于“好用”和“易改”。它应该通过配置文件如config.yaml或.env来管理所有关键参数模型路径、API密钥、Chunk大小、重叠长度、检索返回数量、温度值等。这样开发者无需修改代码就能进行大量的实验对比。同时每个核心模块如分割器、嵌入模型、向量库、LLM都应定义为接口或抽象类遵循依赖注入原则。当你想把ChromaDB换成Milvus或者把text2vec换成BGE模型时只需要实现对应的接口并在配置中切换核心业务流程代码应保持不动。这种设计极大地提升了项目的工程价值和长期维护性。3. 关键模块深度解析与实操要点让我们聚焦几个最容易出问题也最影响最终效果的核心模块看看在实战中应该如何选择和调优。3.1 文本分割不仅仅是“切豆腐”很多人以为文本分割就是简单按长度切分这是初期效果不佳的常见原因。固定长度分割的陷阱假设你设置chunk_size500。如果一段话在第450个字符处刚好是一个关键概念的定义开始那么它会被残忍地切到下一个Chunk导致前一个Chunk语义不完整检索时可能完全丢失这个关键概念。更优的策略递归字符分割这是LangChain等框架的默认方法。它先尝试按双换行符\n\n分割如果分割后的片段仍然太大再按换行符\n分割还大就按句号.最后再按字符数。这种方法能在一定程度上尊重段落和句子边界。语义分割使用专门的模型如all-MiniLM-L6-v2计算句子间的语义相似度在语义变化较大的地方进行分割。这种方法效果最好但需要额外的模型推理速度较慢适合对质量要求极高的场景。基于标记的分割对于Markdown、LaTeX等有明确结构标记的文档可以按标题#、列表等元素进行分割能更好地保持文档结构。实操建议对于通用文档可以先从“递归字符分割”开始调整chunk_size(如 512-1024) 和chunk_overlap(如 100-200)。务必通过查看分割后的样本来验证效果确保没有把完整的表格、代码块或一句话拆散。3.2 嵌入模型中文场景下的选择嵌入模型是将文本映射到向量空间的关键其质量决定了检索的“天花板”。模型名称特点适用场景注意事项text2vec-large-chinese中文优化开源性能好中文文本相似度计算、检索需本地部署向量维度大1024存储和计算开销稍高BGE (BAAI/bge-large-zh)北京智源出品中文SOTA级别对检索精度要求高的生产环境同样需要本地资源支持中英文有不同尺寸版本可选OpenAI text-embedding-3-small/large云端API简单易用效果稳定快速原型验证、不愿管理模型的服务有API调用成本和网络延迟数据需出境需合规m3e-base/large轻量级中文效果均衡资源受限或对延迟敏感的场景体积小速度快是平衡性能和资源的不错选择选择逻辑数据安全与成本优先选开源模型如BGE或text2vec。开发速度与稳定性优先选云端API如OpenAI。资源与延迟敏感选轻量级模型如m3e。关键步骤向量归一化无论选择哪个模型在将向量存入数据库前务必进行归一化L2 Normalization。这是因为大多数向量数据库如FAISS、Milvus在进行相似性搜索余弦相似度时默认假设向量是归一化的。如果存入未归一化的向量搜索时计算的是内积而非余弦相似度会导致结果不准确。代码上通常就是一行vector vector / np.linalg.norm(vector)。3.3 检索与重排序从“找到一些”到“找到对的”基础向量检索返回的Top-K个结果可能包含一些相关性不高但向量空间距离近的“噪声”。重排序就是为了解决这个问题。混合检索同时使用稀疏检索如BM25和稠密向量检索然后合并结果。BM25对关键词匹配更敏感能捕捉到向量模型可能忽略的精确术语匹配。交叉编码器重排序这是一个计算代价更高但更精准的步骤。它使用一个专门的“重排序模型”如BGE-reranker将用户查询和检索到的每一个候选文档片段进行深度交互计算重新打分。虽然它只处理少量如10个候选文档但能极大提升最终送入LLM的上下文质量。工作流程示例用户查询 - 向量检索 (返回Top-20) - 重排序模型对Top-20重新打分 - 取Top-3 - 组合成Prompt - 发送给LLM这个流程增加了少量延迟约几十到几百毫秒但能显著改善答案质量尤其是在文档库庞大或问题复杂时。4. 从零到一的完整搭建流程假设我们基于rag-in-action项目的思路搭建一个针对本地中文技术文档的问答系统。以下是核心步骤。4.1 环境准备与依赖安装首先创建一个干净的Python环境推荐3.9然后安装核心依赖。一个典型的requirements.txt可能包含# 核心框架 langchain0.1.0 langchain-community0.0.10 # 文档加载与处理 pymupdf # PDF解析 markdown # Markdown解析 unstructured[pdf,docx,pptx] # 多功能解析 # 文本分割与向量化 sentence-transformers # 用于嵌入模型和语义分割 chromadb # 向量数据库轻量级选择 # 或者 pymilvus # 如需更强大的向量库 # 大模型接入 openai # 如需GPT ollama # 如需本地Llama, Qwen等 litellm # 统一API接口 # 工具类 python-dotenv # 管理环境变量 tiktoken # Token计数使用pip install -r requirements.txt安装。建议使用uv或poetry进行更专业的依赖管理。4.2 数据管道构建从原始文档到向量库这是最耗时但也最基础的一步。我们编写一个ingest.py脚本。import os from langchain.document_loaders import DirectoryLoader, PyMuPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma # 1. 加载文档 documents [] data_path ./your_docs for file in os.listdir(data_path): if file.endswith(.pdf): loader PyMuPDFLoader(os.path.join(data_path, file)) documents.extend(loader.load()) # 可以添加更多格式支持如 .md, .docx # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n\n, \n, 。, , , , , 、, , ] ) chunks text_splitter.split_documents(documents) print(f共生成 {len(chunks)} 个文本块。) # 3. 生成嵌入并存入向量库 embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, # 选用轻量高效的BGE小模型 model_kwargs{device: cpu}, # 根据情况改为 cuda encode_kwargs{normalize_embeddings: True} # 关键启用归一化 ) # 指定向量库持久化路径 vectorstore_path ./chroma_db vectordb Chroma.from_documents( documentschunks, embeddingembedding_model, persist_directoryvectorstore_path ) vectordb.persist() # 持久化到磁盘 print(f向量库已保存至 {vectorstore_path})关键操作解析RecursiveCharacterTextSplitter的separators参数是针对中文优化的分割符列表按优先级尝试分割。HuggingFaceEmbeddings的encode_kwargs{normalize_embeddings: True}确保了存入向量库的向量是归一化的这是正确检索的关键。Chroma.from_documents方法一次性完成了向量化和存储。对于大规模数据可能需要分批处理以避免内存溢出。4.3 构建检索链与问答接口向量库准备好后我们构建一个query.py来提供问答服务。from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate from langchain_community.llms import OllamaLLM # 假设使用本地Ollama # 或 from langchain_openai import ChatOpenAI # 1. 加载已有的向量库和嵌入模型 embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma(persist_directory./chroma_db, embedding_functionembedding_model) # 2. 定义提示词模板这是控制LLM行为的关键 prompt_template 请严格根据以下提供的上下文信息来回答问题。如果上下文信息中没有明确答案请直接说“根据提供的信息我无法回答这个问题”不要编造信息。 上下文 {context} 问题{question} 请根据上下文给出答案 PROMPT PromptTemplate( templateprompt_template, input_variables[context, question] ) # 3. 初始化大语言模型 llm OllamaLLM(modelqwen2:7b, temperature0.1) # 温度调低减少随机性 # 如果使用OpenAI: llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 4. 创建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 最简单的方式将所有上下文塞进prompt retrievervectordb.as_retriever(search_kwargs{k: 4}), # 检索4个相关块 chain_type_kwargs{prompt: PROMPT}, return_source_documentsTrue # 返回来源文档便于调试 ) # 5. 提问 question 什么是RAG它主要解决什么问题 result qa_chain.invoke({query: question}) print(答案, result[result]) print(\n来源文档) for i, doc in enumerate(result[source_documents]): print(f[{i1}] {doc.page_content[:200]}...) # 打印前200字符代码要点PromptTemplate中的指令非常关键它强制LLM基于上下文回答有效减少了“幻觉”。RetrievalQA的chain_type除了stuff还有map_reduce、refine等用于处理超长上下文但stuff最简单直接。search_kwargs{k: 4}控制了检索返回的文档数量需要根据上下文窗口和问题复杂度调整。return_source_documentsTrue对于调试至关重要你可以看到LLM到底依据了什么材料来生成答案。5. 效果评估与迭代优化系统跑起来只是第一步更重要的是评估和优化。没有评估优化就是盲人摸象。5.1 构建简易评估集创建一个eval_questions.json文件包含一系列问题及其在文档中的标准答案或期望答案。[ { question: RAG的主要优势是什么, reference_answer: RAG通过结合外部知识库增强了LLM的事实性和时效性减少了幻觉并能够处理专业领域知识。, category: 概念理解 }, { question: 在ChromaDB中如何实现过滤检索, reference_answer: 可以使用 where 或 where_document 参数在检索时添加元数据过滤条件。, category: 工具使用 } ]5.2 设计评估指标可以自动化计算的指标检索召回率对于每个问题人工判断检索到的Top-K个文档中是否包含能回答该问题的正确文档。计算比例。答案相关性可用LLM自动评估使用一个更强的LLM如GPT-4作为裁判对比系统生成的答案和参考答案在0-5分之间打分。更实用的方法是人工走查随机抽取一批问题运行系统并仔细检查检索到的文档是否相关检索阶段问题如果文档相关答案是否正确生成阶段问题如果答案错误是文档信息不足还是LLM理解有误或胡编乱造5.3 常见问题排查清单根据人工走查的结果你可以按以下清单定位问题现象可能原因排查方向与优化建议答案完全无关检索失败未找到任何相关文档1. 检查嵌入模型是否适合你的领域尝试换模型。2. 检查文本分割是否合理查看Chunk样本。3. 尝试增大检索数量k。4. 考虑引入混合检索或重排序。答案部分正确部分胡编检索到了部分相关文档但LLM出现了“幻觉”1.强化Prompt指令在Prompt中明确要求“仅根据上下文回答”。2. 检查送入LLM的上下文是否过多、过杂尝试减少k或对检索结果进行摘要。3. 降低LLM的temperature参数如设为0.1。答案冗长或格式不佳LLM行为不受控1. 在系统Prompt中指定回答格式如“请用简洁的列表形式回答”。2. 使用LLM的“系统指令”功能如果支持。回答“无法回答”过于频繁检索阈值过高或Prompt过于严格1. 调整检索的相似度阈值如果向量库支持。2. 微调Prompt将“无法回答”的指令改为“根据上下文我认为...”。处理长文档时答案质量下降上下文窗口限制重要信息被截断1. 尝试chain_typemap_reduce或refine。2. 优化文本分割确保关键信息在单个Chunk内完整。3. 考虑使用能处理更长上下文的模型。5.4 高级优化技巧查询转换在检索前对原始用户问题进行改写或扩展。例如使用LLM将“它怎么用”这样的指代性问题结合对话历史重写为完整的“RAG技术怎么用”。这能显著提升检索效果。元数据过滤在存入向量时为每个Chunk添加元数据如来源文件、章节标题、页码等。检索时可以添加过滤条件如来源文件用户手册.pdf实现更精准的检索。上下文压缩在将检索到的文档送给LLM前先使用一个较小的模型或摘要模型对冗长的文档进行摘要只保留最核心的信息以节省上下文窗口。智能路由对于简单、事实性问题直接走向量检索对于需要推理、总结或多步分析的问题可以走不同的处理流程甚至调用不同的LLM。搭建一个可用的RAG系统可能只需要几天但将其打磨成一个稳定、可靠、高效的生产级系统需要持续的迭代、评估和优化。huangjia2019/rag-in-action这类项目提供的正是这样一个经过实践检验的起点和工具箱。理解其背后的设计原理掌握每个模块的调优方法再结合你自己业务数据的特性进行适配才是从“入门”到“精通”的关键。记住没有放之四海而皆准的最优参数最好的系统永远是那个经过你精心测试和调校的系统。
![题解：洛谷 P14922 [GESP202512 七级] 学习小组](http://pic.xiahunao.cn/yaotu/题解：洛谷 P14922 [GESP202512 七级] 学习小组)
