1. 为什么我要做这个RAG进阶实战专栏过去大半年我一直在帮几个团队做RAG项目的落地咨询从最早的“把文档塞进向量库就能跑”的兴奋期到后来被召回率、幻觉、评测、成本这些问题反复按在地上摩擦踩过的坑比写过的代码还多。市面上讲RAG的文章和教程不少但大多数停留在“用LangChain搭一个Demo”的层面真正到了生产环境你会发现Demo和能用的系统之间隔着一条巨大的鸿沟。这个专栏就是想把这条鸿沟填上把我在实际项目里验证过的架构设计、向量库选型、评测方法、MVP搭建路径以及那些只有踩过才知道的坑系统地分享出来。RAG这个词现在热得发烫但很多人对它的理解还停留在“检索增强生成”这六个字的字面意思上。实际上一个完整的RAG系统涉及文档解析、分块策略、向量化模型选择、向量库调优、检索策略、重排序、上下文组装、生成控制、评测体系等多个环节每个环节都有大量的决策点和取舍。这个专栏的目标读者是已经了解RAG基本概念、动手跑过简单Demo、但准备把它用到真实业务场景中的开发者和技术负责人。如果你还在纠结“什么是RAG”那这个专栏可能对你来说节奏偏快但如果你已经遇到过“为什么我的RAG答非所问”“为什么召回率上不去”“怎么评估我的RAG好不好”这类问题那这里的内容应该能帮你省下不少试错时间。专栏的名字叫“进阶实战”重点在“进阶”和“实战”两个词上。进阶意味着我不会花大量篇幅去讲基础概念而是直接切入架构层面的设计取舍和工程实现中的关键细节。实战意味着每一篇都会有可复现的代码、可参考的配置、可落地的方案而不是泛泛而谈的理论。我会尽量用从业者之间交流的口吻来写直接、不绕弯子把“为什么这么选”和“怎么操作”讲清楚。2. 专栏整体架构与内容规划思路2.1 从MVP到生产级专栏的递进式结构设计这个专栏的内容规划遵循一条主线先让读者能快速搭出一个可用的MVP再逐步深入各个核心模块进行优化和加固最后形成一套完整的生产级RAG系统方案。为什么要这样设计因为RAG这个领域最大的陷阱就是“过度设计”。我见过太多团队一上来就想做一套完美的架构结果三个月过去了连一个能跑通的最小闭环都没有。MVP的价值在于快速验证业务假设——你的用户到底会不会用这个功能检索回来的内容到底有没有用生成的结果到底能不能接受这些问题不先回答后面所有的优化都是空中楼阁。所以专栏的第一部分会聚焦MVP框架的搭建。我会给出一个经过多个项目验证的最小可行架构包括文档加载、文本分块、向量化、向量库存储、检索、生成这条完整链路的最简实现。这个MVP不会追求性能极致也不会覆盖所有边界情况但它能让你在一天之内跑通整个流程拿到第一批真实用户的反馈。这部分会包含完整的代码示例和配置说明用Ollama加本地向量库的方式实现零基础也能复制。第二部分进入架构设计层面。当MVP验证了业务价值之后接下来要做的就是把这个原型变成一个能扛住真实流量、能处理复杂文档、能持续迭代的系统。这部分会深入讨论几个关键决策向量库选型到底看哪些指标分块策略怎么根据文档类型调整检索阶段要不要加重排序多路召回怎么融合这些决策没有标准答案但我会给出我的判断框架和实际项目中的取舍逻辑。第三部分聚焦评测体系。这是我认为目前RAG领域最被低估的环节。很多团队做完RAG之后不知道怎么衡量好坏只能靠人工看几个case拍脑袋。这种做法在小规模验证阶段可以但一旦要持续迭代没有量化评测就等于闭着眼睛开车。这部分会详细讲怎么构建评测集、怎么设计评测指标、怎么自动化评测流程包括Agent评测集构建的思路。第四部分回到实战用几个完整的案例把前面讲的内容串起来。包括企业知识库、代码检视辅助、结构化知识库与RAG的结合等场景。每个案例都会从需求分析开始经过架构设计、技术选型、实现细节一直到评测和优化完整走一遍。2.2 核心关键词在专栏中的分布与权重专栏的内容围绕几个核心关键词展开每个关键词在不同章节中的权重不同。RAG是整个专栏的母题贯穿始终。架构设计主要集中在第二部分但第一部分和第四部分也会涉及。向量库作为RAG的核心组件会在第一部分和第二部分重点讨论包括选型对比、索引调优、性能测试等。评测是第三部分的核心但第四部分的案例中也会反复用到评测方法来验证优化效果。MVP框架是第一部分的重点也是整个专栏的起点。除了这些核心关键词专栏还会覆盖一些在实际项目中高频出现但容易被忽视的话题。比如RAG知识库能不能存储图片这个问题看起来简单但背后涉及多模态检索、图文混合分块、跨模态相似度计算等一系列复杂问题。再比如RAG瓶颈到底在哪里是检索精度不够还是生成控制不好不同瓶颈的排查思路和解决方案完全不同。还有结构化知识库和RAG知识库的区别以及各自的应用场景这个问题在知识图谱和RAG结合的场景下特别重要。这些话题都会在专栏中专门讨论。3. 核心模块深度拆解与实操要点3.1 文档解析与分块策略RAG系统的第一道关卡文档解析和分块是RAG系统中最基础但也最容易被轻视的环节。我见过太多项目在这个环节偷懒直接把整篇文档按固定字数切分结果检索出来的内容要么缺头少尾要么把不相关的段落混在一起。分块策略直接决定了检索质量的上限如果分块没做好后面再好的向量模型和检索算法都救不回来。先说文档解析。不同格式的文档需要不同的解析工具。PDF是最常见的格式但也是最麻烦的。普通的PDF文本提取工具对于扫描件、多栏排版、表格、公式基本无能为力。我的经验是对于扫描件必须上OCR对于多栏排版需要做版面分析对于表格需要专门的表格提取工具。Markdown和HTML相对简单但也要注意代码块、表格、列表这些结构化元素的处理。Word文档可以用python-docx提取但要注意样式信息的保留。分块策略方面固定长度分块是最简单的但效果往往最差。我一般会根据文档类型选择不同的策略。对于技术文档和教程类内容按标题层级分块效果最好因为标题天然就是语义边界。对于对话记录和会议纪要按轮次或话题分块更合适。对于法律合同和规章制度按条款分块是必须的。对于没有明显结构的长文本可以用语义分块通过计算相邻句子的语义相似度来确定分块边界。分块大小也需要仔细权衡。块太小检索时可能召回不完整的信息块太大会引入噪声而且浪费上下文窗口。我的经验值是中文文本每块300到500字英文文本每块200到300词。但这个值不是固定的需要根据实际检索效果来调整。一个实用的技巧是在分块时保留一定的重叠区域比如相邻块之间重叠50到100字这样可以避免边界处的信息丢失。注意分块时一定要保留元数据比如来源文档、章节标题、页码等。这些元数据在检索后组装上下文时非常有用可以帮助生成模型更好地理解内容的来源和位置。还有一个容易被忽视的点是特殊内容的处理。代码块、表格、公式这些内容如果被当作普通文本分块检索效果会很差。我的做法是对代码块单独分块并打上类型标签检索时可以根据查询类型决定是否召回代码块。表格最好转换成Markdown格式再分块保留行列结构。公式如果无法解析至少要把公式周围的解释文字分在一起。3.2 向量库选型与索引调优从Demo到生产的必经之路向量库的选择是RAG架构设计中最关键的决策之一。市面上主流的向量库有十几款每款都有自己的定位和适用场景。我在实际项目中用过Milvus、Qdrant、Weaviate、Chroma、FAISS也评估过Pinecone和Pgvector。选型时我主要看几个维度数据规模、查询延迟、过滤能力、运维成本、生态集成。对于数据量在百万级以下、追求快速上手的场景Chroma和FAISS是不错的选择。Chroma的API设计很友好自带持久化适合MVP阶段。FAISS是Facebook开源的库性能很好但需要自己管理索引和元数据。对于千万级到亿级的数据量Milvus和Qdrant更合适。Milvus的分布式架构成熟支持多种索引类型但运维复杂度较高。Qdrant的过滤性能很强支持复杂的payload过滤而且Rust写的资源占用低。Weaviate自带模块化设计支持混合检索但学习曲线稍陡。索引类型的选择也很重要。Flat索引召回率最高但速度最慢适合小数据集。IVF系列索引通过聚类加速查询但会损失一些召回率。HNSW是目前综合表现最好的索引类型查询速度快、召回率高但内存占用较大。我的建议是如果内存充足优先选HNSW如果内存紧张可以考虑IVF加PQ量化。提示向量库的选型不是一锤子买卖。我建议在MVP阶段用最简单的方案快速验证等业务量上来之后再根据实际瓶颈做迁移。迁移成本没有想象中那么高因为大多数向量库都支持标准的数据导入导出格式。索引调优方面有几个参数需要重点关注。以HNSW为例M参数控制每个节点的连接数值越大召回率越高但内存占用也越大一般设置在16到64之间。efConstruction控制建索引时的搜索深度值越大索引质量越好但建索引越慢一般设置在100到500之间。efSearch控制查询时的搜索深度值越大召回率越高但查询越慢这个参数可以在查询时动态调整根据对延迟的要求来权衡。还有一个经常被忽略的点是向量维度和距离度量。不同的嵌入模型输出的向量维度不同常见的有384、768、1024、1536。维度越高表达能力越强但存储和计算成本也越高。距离度量方面余弦相似度适合大多数文本场景欧氏距离适合图像场景内积适合推荐场景。选错了距离度量会导致检索结果完全不可用这个坑我踩过。3.3 检索策略与重排序如何让RAG答得更准检索是RAG系统的核心环节检索质量直接决定了生成质量。基础的向量检索就是拿查询向量去向量库里找最相似的TopK个块但实际项目中这样做的效果往往不够好。问题出在几个方面查询和文档的语义空间不完全对齐、单一向量表示丢失了太多信息、TopK的选择很敏感。解决这些问题的第一招是查询改写。用户的原始查询往往很短、很模糊直接拿去做向量检索效果不好。我通常会用一个小模型对查询进行改写和扩展生成多个查询变体然后分别检索再合并结果。比如用户问“RAG怎么评测”可以改写成“RAG评测方法”“RAG评测指标”“如何评估RAG系统效果”等多个查询。这样做可以显著提高召回率。第二招是混合检索。纯向量检索擅长语义匹配但对关键词匹配不敏感。比如用户搜一个特定的错误码或者产品型号向量检索可能找不到精确匹配的文档。这时候需要结合关键词检索比如BM25做混合检索。混合检索的结果融合可以用RRFReciprocal Rank Fusion算法简单有效不需要调参。第三招是重排序。向量检索召回的TopK个块中真正相关的可能只有前几个后面的都是噪声。重排序模型可以对召回的块进行更精细的相关性打分把真正相关的排到前面。常用的重排序模型有Cohere的Rerank、BGE的Reranker等。重排序的代价是增加延迟所以一般只对Top20到Top50的块做重排序然后取Top3到Top5送给生成模型。注意重排序模型的选择要和嵌入模型匹配。如果嵌入模型是多语言的重排序模型最好也支持多语言。另外重排序的输入是查询和文档的拼接长度有限制太长的文档需要截断。还有一个进阶技巧是上下文压缩。检索回来的块中往往包含很多无关信息直接送给生成模型会浪费上下文窗口还可能引入噪声。上下文压缩的做法是用一个小模型对每个块进行摘要或提取只保留和查询相关的部分。这样可以在有限的上下文窗口里塞进更多有效信息。3.4 生成控制与幻觉抑制让RAG说真话生成环节是RAG系统的最后一公里也是最容易出问题的环节。即使检索到了正确的内容生成模型也可能因为各种原因产生幻觉编造出检索内容中没有的信息。幻觉的根源在于生成模型本质上是一个概率模型它的目标是生成流畅的文本而不是保证事实正确。抑制幻觉的第一道防线是提示词设计。我通常会在系统提示词里明确要求模型只基于提供的上下文回答问题如果上下文里没有相关信息就明确说“根据现有资料无法回答”。这个简单的约束可以过滤掉大部分明显的幻觉。另外提示词里要明确引用格式要求模型在回答中标注信息来源这样既方便用户核实也能在一定程度上约束模型的行为。第二道防线是上下文组装策略。检索回来的块不能一股脑全塞给模型需要按相关性排序把最相关的放在最前面和最后面。研究表明生成模型对上下文开头和结尾的信息更敏感中间部分容易被忽略。所以重要的信息要放在两端。另外块与块之间要有明确的分隔符避免模型把不同块的内容混在一起。第三道防线是生成后的验证。对于关键场景可以在生成之后再加一个验证步骤用另一个模型或者规则来检查生成的内容是否忠实于检索到的上下文。比如可以用NLI模型判断生成内容是否被上下文蕴含。如果验证不通过可以触发重新生成或者降级到模板回复。提示幻觉抑制没有银弹需要根据业务场景的容错率来设计策略。对于法律、医疗等高风险场景宁可拒答也不能瞎答。对于闲聊、推荐等低风险场景可以适当放宽。还有一个实用技巧是温度参数的调整。生成模型的温度参数控制输出的随机性温度越低输出越确定。RAG场景下一般建议用较低的温度比如0.1到0.3这样可以减少模型自由发挥的空间。但温度太低也会导致输出过于死板需要根据实际效果来调。4. 评测体系构建与常见问题排查4.1 RAG评测集构建从人工标注到自动化生成评测是RAG系统持续迭代的基础。没有评测所有的优化都是盲目的。但构建一个高质量的评测集并不容易尤其是对于垂直领域的RAG系统需要领域专家参与标注成本很高。我在多个项目中摸索出一套半自动的评测集构建方法可以大幅降低人工成本。第一步是收集真实查询。从线上日志、用户反馈、客服记录中收集用户实际问过的问题。这些查询是最真实的比人工构造的查询更有代表性。收集到几百到几千条查询后进行去重和分类确保覆盖不同的查询类型和难度级别。第二步是标注标准答案。对于每条查询需要标注两部分内容相关的文档块和期望的回答。相关文档块的标注可以通过人工判断也可以先用检索系统召回一批候选然后人工筛选。期望回答的标注可以只标注关键信息点不需要完整的回答文本。第三步是自动化扩展。有了种子评测集之后可以用大模型生成更多的查询-答案对。具体做法是拿一个文档块让大模型基于这个块生成几个可能的问题然后把这些问答对加入评测集。这样可以从有限的文档中生成大量的评测样本。当然自动生成的样本需要人工抽检确保质量。评测指标方面检索阶段主要看召回率、精确率、MRR、NDCG。生成阶段主要看忠实度、相关性、完整性。忠实度衡量生成内容是否基于检索到的上下文相关性衡量回答是否切题完整性衡量回答是否覆盖了所有关键信息点。这些指标可以用大模型来自动打分虽然不如人工准确但胜在成本低、速度快适合日常迭代。注意评测集要定期更新避免过拟合。我一般会保留一个固定的测试集用于版本对比另外用一个动态更新的开发集用于日常调优。测试集不参与任何调优决策只在版本发布时使用。4.2 RAG常见瓶颈与排查技巧实录在实际项目中RAG系统的瓶颈往往不是单一环节的问题而是多个环节叠加的结果。我整理了一个常见问题速查表按症状、可能原因、排查方法、解决方案四个维度来组织。症状可能原因排查方法解决方案检索不到相关内容分块不合理、嵌入模型不匹配、查询太短检查分块边界、对比不同嵌入模型、查看查询向量调整分块策略、换嵌入模型、查询改写检索到无关内容向量库噪声大、TopK太大、距离度量错误人工检查召回结果、计算相关性分布增加过滤条件、减小TopK、换距离度量回答不完整上下文窗口不够、块太小、生成模型截断检查上下文长度、查看块大小分布增大窗口、调整块大小、上下文压缩回答有幻觉提示词约束不够、温度太高、上下文噪声检查提示词、调整温度、人工验证强化提示词、降低温度、增加验证步骤响应太慢向量库查询慢、重排序耗时、生成模型大分段计时、查看各环节耗时优化索引、减少重排序候选、换小模型成本太高嵌入模型调用频繁、生成token多统计API调用量和token消耗缓存嵌入结果、压缩上下文、批量处理排查RAG问题的核心思路是分段定位。把整个链路拆成检索和生成两段先看检索结果对不对再看生成结果好不好。如果检索结果就是错的那问题在检索环节调生成没用。如果检索结果是对的但生成结果不对那问题在生成环节需要调提示词或换模型。这个思路听起来简单但很多人在排查时容易混淆把生成的问题当成检索的问题来修。还有一个容易被忽视的瓶颈是嵌入模型的领域适配。通用的嵌入模型在垂直领域的效果往往不够好比如医疗、法律、金融这些专业领域。解决方案有两种一是用领域数据对嵌入模型做微调二是用领域数据训练一个适配层。微调的成本较高但效果提升明显。适配层的成本低适合快速验证。提示排查问题时一定要有日志。我建议在检索和生成两个环节都记录详细的日志包括查询、召回结果、相关性分数、生成的回答、耗时等。这些日志在排查问题时非常有用也是构建评测集的数据来源。4.3 结构化知识库与RAG的结合应用结构化知识库和RAG知识库各有优劣在实际项目中往往需要结合使用。结构化知识库适合存储实体、关系、属性这类高度结构化的信息查询精确、推理能力强但构建成本高、覆盖范围有限。RAG知识库适合存储非结构化的文本内容构建成本低、覆盖范围广但查询精度和推理能力较弱。结合的方式有几种。一种是用结构化知识库做路由根据查询类型决定走结构化查询还是RAG检索。比如查询“某产品的价格”走结构化查询查询“某产品的使用说明”走RAG检索。另一种是用结构化知识库增强RAG的检索比如把实体关系作为过滤条件缩小检索范围。还有一种是用RAG来补充结构化知识库的覆盖盲区当结构化查询没有结果时降级到RAG检索。知识图谱和RAG的结合是最近比较热的方向。知识图谱可以提供实体间的显式关系帮助RAG做多跳推理。比如用户问“A公司的CEO毕业于哪所大学”纯RAG可能检索不到直接答案但知识图谱可以通过A公司-CEO-毕业院校这条路径找到答案。实现方式可以是先用知识图谱做推理把推理结果作为上下文送给生成模型。注意结构化知识库和RAG的结合会增加系统复杂度不是所有场景都需要。我的建议是先用纯RAG快速验证等遇到明确的瓶颈时再引入结构化知识库。过早引入结构化知识库会导致项目周期拉长、维护成本增加。5. 实战案例从零搭建一个可用的RAG知识库5.1 环境准备与工具选型这个实战案例的目标是搭建一个本地的RAG知识库支持对Markdown和PDF文档的检索和问答。选择本地部署而不是云服务主要是考虑到数据隐私和成本控制。技术栈方面嵌入模型用BGE-M3向量库用Chroma生成模型用Ollama运行的Qwen2.5编排框架用LangChain。这套组合的好处是全部本地运行不需要API密钥适合快速验证和小规模使用。环境准备方面需要Python 3.10以上版本安装LangChain、Chroma、Ollama的Python客户端以及文档解析相关的库。Ollama需要单独安装并拉取模型。硬件方面建议至少16GB内存如果有GPU更好没有GPU用CPU也能跑只是速度慢一些。pip install langchain langchain-community chromadb ollama pypdf markdown ollama pull qwen2.5:7b ollama pull bge-m3工具选型的逻辑是这样的BGE-M3是目前中文嵌入效果最好的开源模型之一支持多语言和长文本。Chroma轻量易用自带持久化适合本地部署。Qwen2.5在中文生成任务上表现不错7B版本在消费级硬件上可以流畅运行。LangChain提供了完整的RAG组件虽然有些抽象层比较重但胜在生态成熟、文档丰富。5.2 完整实现流程与关键代码解析整个实现流程分为文档加载、分块、向量化、存储、检索、生成六个步骤。下面按步骤说明关键代码和注意事项。文档加载部分需要根据文件类型选择不同的加载器。Markdown用UnstructuredMarkdownLoaderPDF用PyPDFLoader。加载后得到的Document对象包含page_content和metadata两个属性。metadata里要保留来源文件路径和页码方便后续引用。from langchain_community.document_loaders import UnstructuredMarkdownLoader, PyPDFLoader def load_documents(file_path): if file_path.endswith(.md): loader UnstructuredMarkdownLoader(file_path) elif file_path.endswith(.pdf): loader PyPDFLoader(file_path) else: raise ValueError(fUnsupported file type: {file_path}) return loader.load()分块部分用RecursiveCharacterTextSplitter设置chunk_size为500chunk_overlap为100。分隔符按优先级设置为段落、换行、句号、逗号。这样可以在保持语义完整的前提下控制块的大小。from langchain.text_splitter import RecursiveCharacterTextSplitter def split_documents(documents): splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , , , , ] ) return splitter.split_documents(documents)向量化和存储部分用Ollama的嵌入接口调用BGE-M3把分块后的文档转换成向量存入Chroma。Chroma的persist_directory参数指定持久化路径这样重启后数据不会丢失。from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma def create_vectorstore(chunks, persist_dir./chroma_db): embeddings OllamaEmbeddings(modelbge-m3) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directorypersist_dir ) return vectorstore检索和生成部分用向量库的similarity_search_with_score方法检索TopK个块然后把块的内容拼接成上下文加上系统提示词送给Ollama生成回答。系统提示词要明确要求模型只基于上下文回答并标注来源。from langchain_community.llms import Ollama def rag_query(vectorstore, query, top_k5): results vectorstore.similarity_search_with_score(query, ktop_k) context \n\n.join([doc.page_content for doc, score in results]) prompt f基于以下上下文回答问题。如果上下文没有相关信息请说根据现有资料无法回答。 上下文 {context} 问题{query} 回答 llm Ollama(modelqwen2.5:7b, temperature0.2) return llm.invoke(prompt)5.3 效果验证与迭代优化记录搭好基础版本后我用一批测试问题验证了效果。测试问题覆盖了事实查询、对比查询、推理查询三种类型。事实查询比如“BGE-M3的向量维度是多少”对比查询比如“Chroma和Milvus的区别是什么”推理查询比如“如果文档里说A依赖BB依赖C那A依赖C吗”。第一轮测试的结果不太理想。事实查询的准确率还可以大概70%左右。对比查询经常只召回一个方面的信息导致回答不完整。推理查询基本答不对因为检索回来的块不包含完整的推理链。分析原因主要是分块太碎把相关的信息切散了。另外TopK设得太小只召回了5个块覆盖不了对比查询需要的多个方面。针对这些问题做了几轮优化。第一轮优化把chunk_size从500调到800chunk_overlap从100调到150让每个块包含更完整的信息。第二轮优化把TopK从5调到10并且加了重排序用BGE的Reranker对召回的块重新排序取前5个送给生成模型。第三轮优化加了查询改写用Qwen2.5对原始查询生成3个变体分别检索后合并结果。优化后的效果有明显提升。事实查询准确率到了85%以上对比查询的完整性好了很多推理查询虽然还是弱项但至少能给出部分正确的回答。响应时间方面加了重排序和查询改写后单次查询从2秒左右增加到5秒左右对于本地部署来说可以接受。提示迭代优化时一定要有评测数据支撑不能凭感觉调。我建议每轮优化都跑一遍固定的测试集记录各项指标的变化。这样才能知道优化到底有没有效果以及有没有引入新的问题。6. 专栏后续规划与个人经验分享这个专栏目前规划了四个部分但RAG这个领域发展很快新的技术和方法层出不穷。后续我会根据读者的反馈和技术演进持续补充新的内容。比如多模态RAG、Agentic RAG、GraphRAG这些方向都在我的观察列表里。多模态RAG涉及图片、表格、图表的检索和生成比纯文本RAG复杂很多但应用场景也更广。Agentic RAG把RAG和Agent结合起来让系统能自主决定什么时候检索、检索什么、怎么用检索结果灵活性更高但控制难度也更大。GraphRAG用知识图谱来增强RAG的推理能力适合需要多跳推理的场景。我个人在实际操作中的体会是RAG系统的效果上限取决于数据质量下限取决于工程实现。很多团队把大量精力花在调模型、调参数上却忽视了数据清洗和分块策略这些基础工作。我见过一个项目换了三种嵌入模型、试了五种检索策略效果始终上不去最后发现是原始文档里有大量重复和过时的内容检索出来的东西本身就是错的。所以我的建议是在优化RAG之前先把数据质量搞好把分块策略调好这两件事做好了效果自然就上来了。最后再分享一个小技巧。在调试RAG系统时我习惯把检索到的块和生成的回答一起展示出来方便对比。如果检索到的块里有正确答案但生成模型没答对那是生成环节的问题如果检索到的块里就没有正确答案那是检索环节的问题。这个简单的对比能帮你快速定位问题所在比盲目调参高效得多。