1. 项目概述：为什么RAG是当前AI应用落地的关键拼图

最近和不少做AI应用的朋友聊天，发现一个挺有意思的现象：大家不再只盯着大模型的参数规模或者榜单排名了，讨论的焦点越来越集中在“怎么让模型别胡说八道”、“怎么把公司内部的知识用起来”这些实际问题上。这背后，一个绕不开的技术就是RAG，也就是检索增强生成。你可能在各种地方听过这个词，感觉它很火，但又有点雾里看水。简单来说，RAG就是给大语言模型（LLM）配了一个“超级外挂大脑”——一个可以实时查询、检索外部知识库的系统。当模型需要回答问题时，它不再仅仅依赖自己训练时“记住”的那些可能已经过时或者不全面的知识，而是先去这个外挂大脑里搜一搜最新的、相关的资料，然后结合这些资料来生成答案。

这解决了大模型应用中最头疼的几个问题：幻觉（一本正经地胡说八道）、知识更新滞后（模型训练完，世界又变了）以及数据隐私和安全（不可能把公司机密数据拿去训练一个公开模型）。想象一下，你想让AI帮你分析一份刚签的合同，或者回答一个关于公司内部产品架构的细节问题，RAG就能让模型精准地引用你上传的合同文本或技术文档来回答，而不是凭空编造。这也是为什么从OpenAI的GPTs到国内各大平台的AI助手，再到各种企业级AI应用，RAG几乎成了标配能力。

我之所以想写这个“完全指南”，是因为发现网上很多资料要么过于学术化，讲一堆数学公式；要么就是某个框架（比如LangChain）的简单教程，缺了全局视角和工程落地的细节。这次，我会结合最新的实践，特别是像DeepSeek这类高性能、高性价比模型兴起后的新玩法，从头到尾拆解如何构建一个健壮、可用的RAG系统。无论你是想快速上手做个demo，还是正在为公司规划一个正式的AI知识库项目，相信这些从一线踩坑总结出来的经验都能帮到你。

2. RAG的核心架构与工作流程拆解

要理解RAG，不能只把它看作一个黑盒。一个完整的RAG系统，其实是一条精心设计的流水线，每个环节的优劣都直接影响最终答案的质量。我们可以把它拆解成四个核心阶段：文档处理、检索、增强和生成。

2.1 从原始文档到向量：知识库的构建

这是所有RAG系统的地基，但也是最容易被轻视的环节。很多人以为就是简单地把PDF或TXT文件切一切，扔进向量数据库就完事了。实际上，这里的门道很深。

文档加载与解析：第一步是让机器能“读懂”各种格式的文件。除了常见的.txt,.pdf,.docx，还有网页、Markdown、甚至数据库表。你需要一个强大的解析器（Parser）。例如，解析PDF时，PyPDF2或pdfplumber可以提取文本，但对于复杂的版式（如多栏、表格、图表），unstructured或docling这类库效果更好，它们能保留一定的语义结构。一个常见的坑是直接从PDF复制文本会丢失换行和空格，导致句子破碎，所以必须用专门的库。

文本分块（Chunking）：这是决定检索精度的关键一步。分块不是简单按字数切割。想象一下，如果你把一本小说的每一页都切成256个字符的片段，那么检索“主角在第三章做了什么”时，系统可能只返回包含“主角”和“第三章”几个字但不连贯的碎片，丢失了完整的上下文。

• 固定大小分块：最简单，比如每块500字符，重叠100字符。适合格式规整的文档。工具如LangChain的RecursiveCharacterTextSplitter。
• 基于语义的分块：更高级，利用句子边界、标点、甚至小模型来识别自然段落。例如，semantic-text-splitter库会尝试在完整的句子或段落末尾进行切割，保证块的语义完整性。
• 分层分块：对于长文档（如手册、论文），可以采用多级分块。先按章节分大块，大块内再按段落分小块。检索时可以先定位到大章节，再精确定位到具体段落，兼顾召回率和精度。

实操心得：分块大小没有银弹。对于事实性问答，小块（200-400字）精度高；对于需要推理总结的任务，大块（800-1000字）能提供更丰富的上下文。我通常的做法是准备两种分块策略，在测试集上对比效果。重叠（Overlap）设置很重要，通常10%-20%的重叠能有效防止关键信息被切碎。

向量化（Embedding）：这是将文本转化为机器能理解的“数学指纹”的过程。选择一个好的嵌入模型（Embedding Model）至关重要。它决定了语义相似的文本在向量空间里是否真的“靠近”。

• 模型选择：OpenAI的text-embedding-3系列效果很好但需付费。开源方面，BGE（BAAI）、text2vec、M3E都是中文社区表现优异的模型。BGE系列对中文语义理解尤其出色，且提供了不同尺寸的版本，平衡效果与速度。
• 维度：维度越高，通常表征能力越强，但计算和存储开销也越大。BGE的bge-large-zh是1024维，而text-embedding-3-small是1536维。对于千万级以下的文档库，1024维通常足够。
• 本地部署 vs. API调用：如果数据敏感或要求低延迟，建议本地部署嵌入模型。使用SentenceTransformers库可以轻松加载Hugging Face上的模型。计算一下，用CPU编码百万级文本可能很慢，但用一张消费级GPU（如RTX 4090）就能获得极快的速度。

向量数据库入库：生成向量后，需要存入专门的数据库以便快速检索。这不是传统的关系型数据库擅长的。主流选择有：

• Pinecone / Weaviate (云服务)：开箱即用，管理方便，适合快速原型和中小规模项目。
• Chroma (本地/轻量)：简单易用，纯Python，适合学习和中小型项目，但生产环境稳定性待考。
• Qdrant / Milvus (自托管/高性能)：为大规模向量搜索设计，支持分布式部署，性能强劲，是生产环境的常见选择。Qdrant的Rust底层效率很高，Milvus生态更庞大。
• PGVector (基于PostgreSQL)：如果你的技术栈里已经有PostgreSQL，这是一个非常自然的选择。它把向量作为一种数据类型，可以直接用SQL进行查询和与其他业务数据关联，管理起来非常统一。

我个人的倾向是，对于严肃的生产系统，如果数据规模大、要求高性能，选Qdrant或Milvus；如果想和现有业务数据库深度集成，用PGVector。初期验证用Chroma最快。

2.2 检索（Retrieval）：不仅仅是相似度匹配

当用户提问时，系统需要从海量文档块中找出最相关的几个。最简单的就是计算问题向量和所有文档块向量的余弦相似度，取Top-K。但这远远不够。

基础语义检索：即上述的向量相似度搜索。这是核心，但存在“词汇鸿沟”问题：问题表述和文档表述不同，但语义相同，可能检索不到。

混合检索（Hybrid Search）：结合语义检索和关键词检索（如BM25）。BM25擅长精确匹配关键词，能抓住“命名实体”、“特定术语”，弥补纯向量检索有时过于“模糊”的缺点。例如，问题“DeepSeek-V4 Flash模型有什么特点？”，BM25能确保检索到包含“DeepSeek-V4 Flash”这个精确词组的文档块。Qdrant、Elasticsearch都支持混合检索。

重排序（Reranking）：初步检索可能返回10-20个相关块，但其中可能有几个只是“沾边”。用一个更精细但更耗时的“交叉编码器”模型对这批候选文档进行重新打分和排序，能显著提升Top结果的相关性。BGE-Reranker、Cohere Rerank都是常用的重排序模型。这是一个“召回后再精排”的策略，用少量计算成本换取答案质量的显著提升。

查询转换（Query Transformation）：用户的原始问题可能很模糊。我们可以对查询进行优化：

• 查询扩展：利用LLM生成问题的多个同义或相关问法，用这些扩展查询一起去检索，提高召回率。例如，“怎么部署RAG？”可以扩展为“RAG系统部署步骤”、“搭建检索增强生成环境的方法”。
• 查询压缩/改写：对于冗长的问题，提取核心意图。例如，“我昨天看了篇博客，讲的是用LangChain和Chroma做RAG，但步骤里好像没提怎么处理PDF表格，你能告诉我具体怎么做吗？”可以压缩为“如何处理PDF表格中的文本用于RAG”。
• 逐步分解（Step-back）：让LLM先根据问题推导出更本质、更通用的“元问题”进行检索，获取背景知识，再结合原问题生成答案。这适合需要多步推理的复杂问题。

2.3 增强（Augmentation）与生成（Generation）

检索到相关文档块后，并不是直接扔给LLM就完事了。如何“呈现”这些上下文，极大影响最终答案的质量。

上下文构造与提示工程：把检索到的文档块，按照相关性排序，拼接成一个长的“上下文”，然后和用户问题一起，构成给LLM的最终提示词（Prompt）。这里的关键是格式和指令。

一个经典的Prompt模板如下：

你是一个专业的助手，请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题，请直接说“根据提供的信息，我无法回答这个问题”，不要编造信息。 上下文信息： {context_document_1} {context_document_2} ... {context_document_k} 问题：{user_question} 请根据上述上下文回答：

• 指令清晰：明确要求模型“基于上下文”，并设置“不知道”的边界，这是抑制幻觉的第一道防线。
• 上下文标记：清晰地区分上下文和问题，避免模型混淆。
• 相关性排序：把最相关的文档放在上下文靠前的位置，因为有些模型对上下文长度有限制，可能会忽略后面的内容。

生成模型（LLM）的选择与调用：这是RAG的“大脑”。选择很多：

• GPT-4 / Claude-3：效果顶尖，但API成本高，数据需出境。
• DeepSeek系列：近期炙手可热。特别是DeepSeek-V3和最新的V4系列，在性能上逼近第一梯队，但价格极具竞争力（甚至免费额度很高），API响应也快，成为很多开发者的新宠。它的长上下文能力（128K/1M）对于需要注入大量上下文的RAG场景非常友好。
• 国内大厂模型：通义千问、文心一言、智谱GLM等，API易得，符合数据合规要求。
• 本地模型：Llama 3、Qwen 2.5、Yi等开源模型，用Ollama、vLLM、LMDeploy等工具本地部署，数据完全私有，但需要GPU资源和技术栈。

注意事项：模型的选择不仅是效果和成本的权衡，更要考虑上下文窗口长度。如果你检索并拼接了10个每个1000字的文档块，那么上下文就长达1万字。许多模型的上下文窗口是4K、8K或16K，你需要确保“问题+上下文+回答”的总长度不超过限制。DeepSeek的128K甚至1M上下文在这里就是巨大优势。

3. 构建生产级RAG系统的关键技术与工程实践

了解了流程，我们来看看如何把它从玩具变成真正可靠的生产系统。这里涉及到架构设计、性能优化和效果评估。

3.1 高级检索模式：让搜索更智能

基础的向量检索在很多场景下已经不够用了，我们需要更精细的控制。

元数据过滤：向量数据库中的每个文档块，除了向量和文本，还可以存储元数据，比如来源文件、作者、创建日期、章节标题等。检索时，可以结合语义相似度和元数据过滤。例如：“仅从2024年的产品手册中查找相关信息”。这能极大提升检索的精准度。在Chroma、Qdrant中，这通常通过where过滤器实现。

多向量检索：一个文档块可能包含多种信息。我们可以为同一个文本块生成多个向量表示：一个基于整体内容，一个基于摘要，一个基于提取的关键词。检索时，综合这些不同视角的向量进行搜索，能获得更全面的结果。

图检索（Graph RAG）：这是更前沿的方向。传统的RAG把文档视为独立的“碎片”，丢失了碎片之间的关联（比如“A概念在B章节被定义，在C章节被应用”）。图检索先构建一个知识图谱，提取文档中的实体（人、地点、概念）和关系，检索时不仅找相似的文本块，还沿着图谱寻找相关联的实体和子图，将更结构化的知识送入LLM。这对于回答涉及多步骤推理、因果关系的问题特别有效。LlamaIndex对Graph RAG有较好的支持。

智能路由（Query Routing）：系统可以根据问题的类型，决定走不同的检索路径。例如，通过一个分类器判断：

• 如果是事实性问答 -> 走标准向量检索。
• 如果是需要数值计算或精确匹配 -> 走传统数据库查询或关键词检索。
• 如果是需要多文档汇总 -> 走更复杂的、检索多个子问题并合成的路径。 这需要在前端设计一个“路由智能体”。

3.2 RAG的评估体系：如何知道你的系统好不好？

“感觉回答得还行”是远远不够的。我们需要可量化的指标。RAG的评估通常分为“检索质量”和“生成质量”两部分。

检索质量评估：

• 命中率（Hit Rate）：在Top-K个检索结果中，至少包含一个能回答问题的真实相关文档的概率。这是最基础的指标。
• 平均排序倒数（MRR）：计算第一个相关文档出现位置的倒数，然后对所有问题取平均。它衡量系统把相关文档排在前面的能力。
• 归一化折损累计增益（NDCG）：不仅考虑相关文档是否被检索到，还考虑它们被排在第几位，以及相关程度（可以人工标注相关性分数）。这是更精细的指标。

生成质量评估：

• 忠实度（Faithfulness）：生成的答案是否严格基于提供的上下文？有没有捏造上下文里没有的信息？这是对抗“幻觉”的核心指标。可以用一个小的LLM（如GPT-3.5）来判断答案中的每一条陈述是否都能从上下文中找到依据。
• 答案相关性（Answer Relevance）：生成的答案是否直接回答了原始问题？有没有答非所问或包含冗余信息？
• 上下文利用率（Context Utilization）：模型是否有效地利用了提供的上下文？还是基本忽略了上下文，只凭自己的知识回答？

这些评估可以人工进行，但成本高。现在有一些自动化框架，如RAGAS、TruLens、ARES，它们利用LLM本身作为裁判，来对答案进行上述维度的评分，虽然不完全准确，但对于快速迭代和对比不同方案非常有用。

构建测试集：这是评估的基石。你需要从真实业务场景中收集一批“问题-标准答案”对，并且知道每个标准答案对应支撑它的“文档片段”（Ground Truth）。用这个测试集去跑你的RAG流水线，计算各项指标。

3.3 性能优化与成本控制

当文档库达到百万、千万级时，性能和成本就成为必须考虑的问题。

向量索引优化：暴力计算问题向量和所有文档向量的相似度（暴力搜索）是不可行的。向量数据库使用近似最近邻搜索算法来加速，如HNSW（分层可导航小世界）、IVF（倒排文件）。这些算法通过建立索引，用少量精度换取巨大速度提升。在初始化向量数据库时，需要根据数据规模和查询延迟要求来调整索引参数（如HNSW的ef_construction和M参数）。

分层检索与缓存：

• 分层检索：先用一个快速的、粗略的检索器（如基于较小嵌入模型的检索）召回大量候选（比如100个），再用一个精确但慢的检索器（如大嵌入模型+重排序）从这100个里精选出Top-5。
• 缓存：对于高频、热点问题，可以将“问题-检索结果”甚至“问题-最终答案”缓存起来，下次直接返回，极大降低检索和生成开销。可以用Redis等内存数据库实现。

嵌入模型蒸馏与量化：BGE-large模型效果好但体积大、推理慢。可以考虑使用其蒸馏版（如BGE-small）或对模型进行量化（将FP32精度转换为INT8/INT4），在几乎不损失效果的情况下大幅提升编码速度和减少内存占用。

LLM调用优化：

• 流式输出：对于长答案，使用流式接口（Streaming）可以提升用户体验，实现“打字机”效果。
• 合理设置参数：不要盲目使用低temperature（可能导致回答呆板）或高max_tokens（造成浪费）。对于事实性回答，temperature=0.1左右比较合适。
• 并发与批处理：如果需要处理大量问题，可以利用异步调用或批处理API来提高吞吐。

4. 基于主流框架的RAG实战：以LangChain和LlamaIndex为例

理论说再多，不如动手搭一个。这里我用两个最流行的框架——LangChain和LlamaIndex，分别展示一个最简单的RAG流水线如何构建。我会以处理一份技术PDF文档并问答为例。

4.1 使用LangChain构建RAG流水线

LangChain是一个将LLM与各种工具、数据源连接起来的框架，其设计哲学是“链”（Chain），非常适合快速组装原型。

环境准备：

pip install langchain langchain-community langchain-chroma pypdf openai tiktoken

假设我们使用OpenAI的嵌入和生成模型（实际中可替换为DeepSeek等）。

步骤一：文档加载与分割

from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载PDF loader = PyPDFLoader("path/to/your/technical_manual.pdf") documents = loader.load() # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每个块的大小 chunk_overlap=50, # 块之间的重叠 length_function=len, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] # 中文优先按句分割 ) chunks = text_splitter.split_documents(documents) print(f"将文档切分为 {len(chunks)} 个块。")

步骤二：向量化与存储

from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma # 使用OpenAI的嵌入模型（可替换为本地模型，如HuggingFaceEmbeddings） embeddings = OpenAIEmbeddings(model="text-embedding-3-small", openai_api_key="your_key") # 创建向量数据库并存储 vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db" # 指定持久化目录 ) # 之后加载可以直接用 Chroma(persist_directory="./chroma_db", embedding_function=embeddings)

步骤三：构建检索链

from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate # 1. 定义提示词模板 prompt_template = """你是一个技术文档助手。请仅根据以下上下文来回答问题。如果上下文没有提供足够信息，请说“根据已知信息无法回答”，不要编造。 上下文： {context} 问题：{question} 请根据上下文给出准确、简洁的答案：""" PROMPT = PromptTemplate( template=prompt_template, input_variables=["context", "question"] ) # 2. 初始化LLM（这里替换为DeepSeek） # 假设有LangChain集成的DeepSeek接口，或使用通用的ChatOpenAI兼容接口 # 例如，如果DeepSeek API兼容OpenAI格式： llm = ChatOpenAI( model="deepseek-chat", # 或具体模型名 openai_api_base="https://api.deepseek.com/v1", openai_api_key="your_deepseek_key", temperature=0.1 ) # 3. 创建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # 最简单的方式，将所有上下文塞进prompt retriever=vectorstore.as_retriever(search_kwargs={"k": 4}), # 检索4个最相关块 chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True # 返回源文档，便于调试 ) # 4. 进行问答 result = qa_chain.invoke({"query": "本文档中提到的核心架构是什么？"}) print("答案：", result["result"]) print("\n来源：") for doc in result["source_documents"]: print(f"- {doc.metadata.get('source', 'N/A')} (页码: {doc.metadata.get('page', 'N/A')})")

踩坑记录：LangChain的RecursiveCharacterTextSplitter默认按字符数分割，对中文可能在不该断句的地方切断。务必调整separators参数，优先按中文句号、换行等分割。另外，Chroma的持久化有时在频繁写入后加载会出问题，生产环境建议用更稳定的Qdrant或PGVector。

4.2 使用LlamaIndex构建RAG流水线

LlamaIndex（原名GPT Index）更专注于数据索引和检索，提供了更精细的索引结构和查询接口，对复杂查询支持更好。

环境准备：

pip install llama-index llama-index-embeddings-openai llama-index-vector-stores-chroma pypdf

步骤一：文档加载与索引创建

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext from llama_index.vector_stores.chroma import ChromaVectorStore from llama_index.embeddings.openai import OpenAIEmbedding import chromadb # 1. 加载文档 documents = SimpleDirectoryReader(input_dir="./data").load_data() # 假设PDF在./data目录 # 2. 初始化嵌入模型和向量存储 embed_model = OpenAIEmbedding(model="text-embedding-3-small") chroma_client = chromadb.PersistentClient(path="./chroma_db_llama") chroma_collection = chroma_client.get_or_create_collection("tech_docs") vector_store = ChromaVectorStore(chroma_collection=chroma_collection) storage_context = StorageContext.from_defaults(vector_store=vector_store) # 3. 创建索引 index = VectorStoreIndex.from_documents( documents, embed_model=embed_model, storage_context=storage_context, show_progress=True )

步骤二：配置查询引擎并提问LlamaIndex的强大之处在于其灵活的查询引擎。

from llama_index.core import Settings from llama_index.llms.openai import OpenAI # 配置全局LLM和Embedding（这里LLM换成DeepSeek兼容接口示例） # 注意：需要确保有兼容OpenAI的DeepSeek LLM类，或使用`llama_index.llms.openai_like.OpenAILike` from llama_index.llms.openai_like import OpenAILike llm = OpenAILike( model="deepseek-chat", api_base="https://api.deepseek.com/v1", api_key="your_key", is_chat_model=True, temperature=0.1 ) Settings.llm = llm Settings.embed_model = embed_model # 创建基础查询引擎 query_engine = index.as_query_engine( similarity_top_k=5, # 检索5个块 response_mode="compact" # 生成模式：“compact”会尽量压缩上下文，“refine”会迭代精炼 ) # 进行查询 response = query_engine.query("请总结一下文档中提到的安全注意事项。") print(response.response) print("\n=== 来源节点 ===") for node in response.source_nodes: print(f"文本片段: {node.text[:200]}...") print(f"相似度得分: {node.score:.4f}") print("---")

步骤三：实现高级查询——带重排序和元数据过滤

from llama_index.core.postprocessor import SentenceTransformerRerank from llama_index.core.vector_stores import MetadataFilter, FilterCondition # 1. 创建重排序器 rerank = SentenceTransformerRerank(model="BAAI/bge-reranker-large", top_n=3) # 从top-10中重排选出top-3 # 2. 创建带过滤的检索器 from llama_index.core import VectorStoreIndex index = VectorStoreIndex.from_vector_store(vector_store) # 从已有存储加载 # 假设我们的文档块有 metadata={"category": "safety"} from llama_index.core.vector_stores import MetadataFilters, ExactMatchFilter filters = MetadataFilters( filters=[ ExactMatchFilter(key="category", value="safety") # 只检索category为safety的文档 ] ) # 3. 组装高级查询引擎 query_engine = index.as_query_engine( similarity_top_k=10, node_postprocessors=[rerank], # 应用重排序 filters=filters, # 应用元数据过滤 verbose=True # 打印详细过程 ) response = query_engine.query("安全注意事项里关于密码管理的具体规定是什么？")

LlamaIndex将检索、后处理、生成等模块解耦得很清晰，方便你像搭积木一样组合高级功能，比如上面就组合了元数据过滤和重排序。

5. RAG系统常见问题排查与效果调优指南

即使搭建好了流水线，你可能会发现答案质量不尽如人意。别急，RAG的调优是一个系统工程。我们可以按照“检索-增强-生成”的链路来逐一排查。

5.1 检索阶段的问题与优化

问题1：检索不到相关文档（低召回率）

• 可能原因1：分块策略不当。块太大，包含无关信息稀释了核心语义；块太小，关键信息被切碎。
  • 排查：检查检索到的Top-K个块，看它们是否真的与问题相关。可以人工标注一批问题-相关文档对作为测试集。
  • 优化：尝试不同的分块大小和重叠。对于结构化工件（API文档、手册），尝试按标题/章节分块。使用语义分块工具。
• 可能原因2：嵌入模型不匹配。使用的嵌入模型对特定领域（如医疗、法律）或语言（如专业中文术语）理解不佳。
  • 排查：用一些同义词或相关术语测试，看模型是否能将它们映射到相近的向量。例如，“深度学习”和“深度神经网络”在向量空间是否接近。
  • 优化：换用领域适配的嵌入模型。在中文场景，BGE-large-zh或M3E通常比通用英文模型好。对于极专业领域，可以考虑用领域数据对开源嵌入模型进行微调。
• 可能原因3：查询表述与文档表述差异大。
  • 优化：实施查询扩展。用LLM生成3-5个问题的不同问法，一起用于检索。或者使用HyDE技术，让LLM先根据问题生成一个假设性答案，然后用这个假设答案的向量去检索，有时能更好地匹配文档语言风格。

问题2：检索到的文档不精准（低准确率）

• 可能原因1：缺少元数据过滤。检索到了相关但来源不对的文档（例如，从旧版本手册中检索到了信息）。
  • 优化：在存入向量数据库时，尽可能丰富元数据（文件来源、更新时间、章节、类型等）。检索时结合元数据过滤。
• 可能原因2：单纯向量检索的局限性。
  • 优化：引入混合检索。结合BM25等关键词检索方法。在Qdrant中，可以设置sparse_vector并配置混合搜索权重。
• 可能原因3：返回的Top-K中混入了不相关文档。
  • 优化：引入重排序。用交叉编码器模型对初步检索结果进行精排。虽然增加了一点延迟，但对最终答案质量提升显著。可以将similarity_top_k设大一点（如20），然后用重排序模型选出最相关的3-5个。

5.2 生成阶段的问题与优化

问题3：答案出现幻觉，编造了上下文没有的信息

• 可能原因1：Prompt指令不够强硬。模型忽略了“仅根据上下文”的指令。
  • 优化：强化Prompt。使用更严厉的措辞，例如：“你必须且只能使用以下上下文中的信息。上下文未提及的内容，一律回答‘我不知道’。” 可以在Prompt中提供遵循指令和违反指令的示例（少样本学习）。
• 可能原因2：上下文信息过多或噪声大。LLM的注意力被不相关的信息干扰。
  • 优化：优化检索，确保Top-K的文档高度相关。在构造上下文时，可以只取每个检索文档块中最相关的几个句子，而不是整个块。或者使用Map-Reduce等链式方法，先让LLM分别总结每个文档块，再基于总结生成最终答案。
• 可能原因3：LLM本身幻觉倾向强。
  • 优化：换用已知幻觉较少的模型。目前，Claude系列和GPT-4在遵循指令和减少幻觉方面表现较好。DeepSeek在指令遵循上也做了大量优化。也可以尝试降低temperature参数（如0.1），让输出更确定性。

问题4：答案未能有效利用上下文，像在自说自话

• 可能原因：模型没有“注意到”上下文中的关键信息。
  • 优化：在Prompt中显式要求“引用”。例如：“请根据上下文回答，并在答案中引用上下文的具体描述（例如‘根据第一段…’）”。或者使用引用提示技术，在拼接上下文时，在每个文档块前加上明显的引用标识，如[1],[2]，并要求模型在答案中标注引用来源。

问题5：答案冗长或格式不符合要求

• 可能原因：Prompt中对答案格式和长度没有明确约束。
  • 优化：在Prompt中指定格式。例如：“请用不超过三句话的要点形式总结。”“请以表格形式列出…”“请先给出是或否的判断，再解释原因。”

5.3 系统性评估与迭代

调优不是盲目的，需要建立一个评估-迭代的循环。

1. 构建黄金测试集：收集50-100个真实用户可能问的问题，并人工标注标准答案和对应的支撑文档（Ground Truth）。
2. 建立自动化评估流水线：使用RAGAS或类似框架，针对忠实度、答案相关性等指标，对每个RAG系统版本进行批量测试和打分。
3. A/B测试：如果你有线上系统，可以将不同优化方案（如新的分块策略、新的嵌入模型）部署为不同版本，将一小部分流量导过去，对比关键业务指标（如用户满意度、问题解决率）。
4. 监控与反馈：在生产环境，记录用户的每次提问、检索到的文档、生成的答案。设计用户反馈机制（如“答案是否有用？”按钮）。这些数据是持续优化最宝贵的资源。

RAG系统的构建是一个持续迭代的过程，没有一劳永逸的“最佳配置”。核心在于建立一套从数据准备、检索优化、提示工程到效果评估的完整方法论，并能根据实际反馈和数据不断调整每个环节的参数与策略。从简单的文档问答出发，逐步扩展到支持多轮对话、复杂推理、多模态检索的智能知识系统，这才是RAG技术真正的魅力所在。