1. 项目概述从“玩具”到“生产力”的RAG进阶之路如果你最近在折腾大语言模型应用那“RAG”这个词肯定已经听得耳朵起茧了。检索增强生成听起来挺高大上但很多人的初体验可能是搭了个简单的Demo把PDF扔进去问几个问题回答得好像还行但总感觉差点意思——要么答非所问要么关键信息缺失要么干脆开始胡编乱造。这感觉就像你花大价钱买了台顶级咖啡机结果做出来的咖啡还不如速溶的香问题出在哪其实RAG远不止是“向量检索LLM”的简单拼接它是一个系统工程。从文档处理、检索精度、到提示工程和答案生成每一个环节都有大量细节决定成败。这篇指南就是把我从搭建第一个RAG“玩具”到将其应用于真实生产环境中所踩过的坑、总结的最佳实践和调优“黑话”一次性讲透。无论你是想提升个人知识库的问答质量还是在为企业构建智能客服、知识中枢这里面的经验都能让你少走几个月弯路。2. RAG系统核心组件深度拆解与设计哲学在开始调优之前我们必须像拆解一台精密仪器一样彻底理解RAG的每个核心组件及其相互作用。很多人把RAG的瓶颈简单归咎于“向量模型不够好”或“大模型不够聪明”这其实是片面的。一个高效的RAG系统是数据流、信息流和控制流精心编排的结果。2.1 检索器不只是向量搜索那么简单检索是RAG的“眼睛”和“手”它的任务是从海量知识中精准抓取相关片段。但“相关”的定义本身就非常复杂。2.1.1 混合检索策略让“关键词”和“语义”联手纯粹的向量语义搜索在应对专业术语、特定名称如产品型号、内部代码时容易失灵因为它们的语义在通用语料中训练不足。而纯粹的关键词搜索如BM25又无法理解同义词和上下文意图。因此生产级系统必须采用混合检索。 我的经验是采用“向量搜索为主关键词搜索为辅”的加权融合策略。具体操作上可以并行执行两种检索然后对结果进行重排序。例如使用向量数据库如Chroma、Weaviate进行相似度检索同时用Elasticsearch的BM25进行关键词检索。然后设计一个打分函数综合分数 向量相似度得分 * α 关键词匹配得分 * (1-α)。参数α需要根据你的语料特性进行调优对于法律、金融等专业术语强的领域α可以设低一些如0.3-0.5更依赖关键词对于创意、咨询等需要理解概念的领域α可以设高一些如0.7-0.9。2.1.2 查询理解与改写先听懂问题再找答案用户的问题往往是模糊、简短或包含指代的。直接拿原始问题去检索效果大打折扣。这里必须引入“查询理解”层。查询扩展自动为问题添加同义词或相关术语。例如用户问“苹果最新手机”系统可以自动扩展为“苹果 iPhone 15 Pro 最新型号”。查询重写利用一个小型的LLM如GPT-3.5-turbo将口语化、不完整的问题重写成更适合检索的陈述句。例如“上次开会说的那个预算方案咋样了”可以重写为“关于[某项目]预算方案的会议讨论结果与当前状态”。意图识别判断用户是想进行事实问答、概念解释、列表汇总还是比较分析。不同的意图对应不同的检索策略和后续提示词模板。实操心得不要小看查询改写这是提升检索召回率性价比最高的方法之一。我通常会准备一个专门的提示词模板给LLM指令如“你是一个专业的搜索查询优化助手。请将以下用户问题改写成一句完整、清晰、包含核心实体的陈述句用于文档检索。只输出改写后的句子。”2.2 文本分割与向量化知识“切片”的艺术文档处理是RAG的“地基”地基不牢后面全倒。核心矛盾在于切片太大会引入无关噪声切片太小会丢失关键上下文。2.2.1 超越简单重叠基于语义和结构的智能分块常见的按固定字符数滑动窗口分割的方法非常粗糙。更好的做法是优先按自然边界分割先利用标点句号、问号、换行符以及Markdown/PDF的标题# ##进行粗分。递归分割对于仍然过长的段落如超过500字再按语义进行二次分割。可以使用句子转换器模型计算句子间的相似度在语义转折处进行切割。保留上下文重叠在块与块之间保留一小部分重叠文本如100-150个字符这能有效防止一个完整的答案被生硬地切在两块中间。但重叠不是简单的字符重复最好是在语义完整的句子边界处开始重叠。2.2.2 向量模型选型与微调让模型听懂你的“行话”通用模型如text-embedding-ada-002bge-large-zh是很好的起点但对于垂直领域医疗、法律、金融它们对专业术语的编码能力可能不足。领域模型优先首先寻找是否有开源的领域专用嵌入模型比如针对生物医学的BioBERT针对法律的LawBERT。微调嵌入模型如果找不到合适的且你有足够的领域文本对数据问题-相关段落对可以对开源嵌入模型进行微调。这能显著提升模型对你领域内术语和表述方式的“理解”能力。微调的目标是让相关文本对的向量在空间中被“拉近”不相关的被“推远”。向量维度与归一化注意不同模型的输出维度不同384 768 1024等。存入向量数据库前务必对向量进行归一化处理即转化为单位向量。这样相似度计算通常用余弦相似度会更加高效和准确。大多数向量数据库客户端库都提供归一化函数。2.3 生成器与大模型提示工程从“复读机”到“分析师”检索到相关片段后如何让大模型生成高质量答案这完全取决于你如何“指挥”它。2.3.1 上下文编排与指令设计不要简单地把检索到的文本块拼接起来扔给LLM。你需要设计一个结构化的提示词模板通常包含以下几个部分系统角色指令明确告诉模型它应该扮演的角色和回答风格。“你是一个严谨的金融分析师基于提供的资料回答问题。资料中未提及的信息严禁编造。”任务指令清晰说明任务。“请根据以下提供的背景资料回答用户的问题。”上下文资料以清晰的方式呈现检索结果。建议使用分隔符如---并标注来源序号例如[资料1]...内容...。这有助于模型区分不同来源。用户问题重复或明确用户的问题。输出格式要求如果需要特定格式如要点列表、JSON、包含引用的段落必须明确指定。2.3.2 引用与溯源让答案可信、可验证对于知识类应用让模型在答案中注明引用来源至关重要。这不仅能增加可信度也方便用户追溯和核实。 在提示词中明确要求“请在答案中为每一个关键事实或陈述标注其所依据的资料编号例如‘...根据[资料1]和[资料3]显示...’。如果资料中找不到相关信息请直接回答‘根据现有资料无法找到相关信息’不要自行推断。”3. RAG全链路调优实战指南理解了核心组件我们就可以进入实战调优环节。调优是一个迭代和评估的过程需要建立量化指标。3.1 评估体系搭建如何衡量RAG的“好”在盲目调整参数前必须先定义什么是“好”。我建议从以下几个维度建立评估集检索相关性检索到的Top-K个文档片段有多少是真正与问题相关的可以人工标注或利用GPT-4作为裁判进行评分。答案忠实度模型生成的答案是否严格基于提供的上下文有没有“幻觉”编造信息这是RAG最核心的指标。答案相关性生成的答案是否正面、完整地回答了用户的问题答案流畅度答案是否通顺、符合语言习惯你可以准备一个包含约100-200个“问题-标准答案-相关文档”的测试集。每次系统迭代后用这个测试集进行自动化或半自动化评估记录指标变化。3.2 分阶段调优策略第一阶段优化检索召回率优先目标确保所有相关文档片段都能被检索到。调整文本分块大小和重叠度尝试不同组合如块大小256/512/1024字符重叠50/100字符观察召回率变化。强化查询改写完善你的查询改写提示词并测试不同的小模型如ChatGLM3-6B, Qwen-7B的改写效果。启用混合检索引入关键词检索调整混合权重α。增加检索数量暂时提高Top-K的值如从3提高到10确保不漏检。第二阶段优化排序精确率优先目标让最相关的文档片段排在前面。引入重排序模型在初步检索出较多结果如Top-20后使用一个更精细的交叉编码器模型如bge-reranker-large对结果进行重排序。交叉编码器同时编码问题和文档计算相关性得分比单纯的向量点积更准确但计算代价更高因此只适合对少量候选进行精排。优化元数据过滤如果你的文档有来源、日期、类型等元数据在检索时加入过滤条件可以大幅提升前排结果的精确性。第三阶段优化生成质量与可控性目标生成忠实、流畅、有用的答案。迭代提示词模板这是成本最低、效果最明显的调优手段。针对测试集中回答不好的案例分析是模型误解了指令还是上下文编排混乱然后针对性修改提示词。A/B测试不同版本的提示词。控制上下文长度不是把所有检索到的片段都塞给模型。根据重排序后的得分只选取Top-N如3-5个最相关的片段并确保总长度不超过模型上下文窗口的70%为模型思考和生成留出空间。调整生成参数对于开源模型可以调整temperature降低以减少随机性、top_p等参数使生成结果更稳定。对于事实性问答通常使用较低的temperature如0.1-0.3。3.3 高级模式与技巧3.3.1 递归检索与问答链对于复杂、多步骤的问题可以采用“分而治之”的策略。首先让LLM根据原始问题拆解成几个子问题。然后针对每个子问题独立进行检索和获取答案。最后将所有子答案汇总再让LLM综合成最终答案。 这种方式能更深入地回答复杂问题例如“对比A产品和B产品在价格、性能和生态上的优劣”。3.3.2 智能路由何时检索何时直接回答并非所有问题都需要检索。对于一些通用知识、问候语或系统指令可以直接让LLM回答这样响应更快。 可以训练一个简单的分类器或使用小LLM判断根据用户问题决定路径通用对话 - 直接生成涉及专有知识 - 启动RAG流程。4. 常见“坑点”排查与性能优化实录即使按照最佳实践搭建在实际运行中还是会遇到各种问题。下面是我遇到的一些典型问题及解决方案。4.1 答案中出现“幻觉”或编造信息这是最致命的问题。排查1检查检索结果。首先确认你提供给模型的上下文资料里是否真的包含答案。很可能检索本身就没找到相关信息。你需要回到第一阶段优化检索召回率。排查2强化指令。在系统提示词中用更严厉、更明确的语言限制模型。例如“你必须且只能使用以下提供的背景资料来回答问题。资料中没有的信息即使你知道也绝对不允许在答案中出现。如果资料不足以回答问题请明确说明‘根据已知信息无法回答’。”排查3降低模型“创造力”。将生成参数temperature调至0或使用更保守的模型某些模型在事实性上表现更好。4.2 检索结果看似相关但答案质量不高排查1上下文噪声过大。可能是文本分块不合理一个块里包含了多个不相关主题。尝试减小分块尺寸或采用更智能的语义分割。排查2关键信息被截断。答案所需的信息恰好落在两个块的边缘。增加块之间的重叠度。排查3模型未能理解指令。尝试简化你的提示词用更直白的语言告诉模型“先引用资料再总结”。可以使用思维链提示例如“请按以下步骤思考1. 从资料中找到与问题相关的内容。2. 引用这些内容。3. 基于引用内容组织答案。”4.3 系统响应速度慢瓶颈定位使用性能分析工具确定是检索慢向量数据库查询、还是生成慢LLM API调用、还是预处理慢文本分割嵌入。优化检索对向量索引使用HNSW或IVF等近似搜索算法在精度和速度间取得平衡。为频繁查询的问题建立缓存。使用元数据过滤提前缩小搜索范围。优化生成考虑使用更快的模型如从GPT-4降级到GPT-3.5-Turbo或使用更快的开源模型。如果答案较长可以尝试使用流式输出让用户边看边等。4.4 处理长文档或复杂格式文档如PDF、PPT效果差预处理是关键不要直接用简单的文本提取工具。使用专门的库如pymupdffor PDF,python-pptxfor PPT来提取文本并尽力保留结构信息标题、列表、表格。表格处理表格是信息密集区但提取后容易乱。可以尝试将表格转换为Markdown格式或描述性文本如“下表显示了2023年各季度营收Q1: 100万 Q2: 150万...”再存入向量库。分章节处理对于长文档如书籍、手册可以按章节或目录进行分割并将章节标题作为元数据存入检索时可以利用这些元数据进行过滤。RAG系统的调优是一个永无止境的过程它高度依赖于你的具体数据、领域和用户需求。没有放之四海而皆准的“银弹”参数。最好的方法就是建立评估基线然后进行小步快跑式的迭代实验每次只改变一个变量比如分块大小、提示词、重排序模型观察评估指标的变化找到最适合你自己场景的那个“甜蜜点”。记住目标是构建一个可靠、可信的知识助手而不是一个炫技的模型玩具。从最影响核心体验的“答案忠实度”和“检索相关性”入手你的RAG系统就能一步步从“能用”变得“好用”最终成为真正的生产力工具。
1. 项目概述从“玩具”到“生产力”的RAG进阶之路如果你最近在折腾大语言模型应用那“RAG”这个词肯定已经听得耳朵起茧了。检索增强生成听起来挺高大上但很多人的初体验可能是搭了个简单的Demo把PDF扔进去问几个问题回答得好像还行但总感觉差点意思——要么答非所问要么关键信息缺失要么干脆开始胡编乱造。这感觉就像你花大价钱买了台顶级咖啡机结果做出来的咖啡还不如速溶的香问题出在哪其实RAG远不止是“向量检索LLM”的简单拼接它是一个系统工程。从文档处理、检索精度、到提示工程和答案生成每一个环节都有大量细节决定成败。这篇指南就是把我从搭建第一个RAG“玩具”到将其应用于真实生产环境中所踩过的坑、总结的最佳实践和调优“黑话”一次性讲透。无论你是想提升个人知识库的问答质量还是在为企业构建智能客服、知识中枢这里面的经验都能让你少走几个月弯路。2. RAG系统核心组件深度拆解与设计哲学在开始调优之前我们必须像拆解一台精密仪器一样彻底理解RAG的每个核心组件及其相互作用。很多人把RAG的瓶颈简单归咎于“向量模型不够好”或“大模型不够聪明”这其实是片面的。一个高效的RAG系统是数据流、信息流和控制流精心编排的结果。2.1 检索器不只是向量搜索那么简单检索是RAG的“眼睛”和“手”它的任务是从海量知识中精准抓取相关片段。但“相关”的定义本身就非常复杂。2.1.1 混合检索策略让“关键词”和“语义”联手纯粹的向量语义搜索在应对专业术语、特定名称如产品型号、内部代码时容易失灵因为它们的语义在通用语料中训练不足。而纯粹的关键词搜索如BM25又无法理解同义词和上下文意图。因此生产级系统必须采用混合检索。 我的经验是采用“向量搜索为主关键词搜索为辅”的加权融合策略。具体操作上可以并行执行两种检索然后对结果进行重排序。例如使用向量数据库如Chroma、Weaviate进行相似度检索同时用Elasticsearch的BM25进行关键词检索。然后设计一个打分函数综合分数 向量相似度得分 * α 关键词匹配得分 * (1-α)。参数α需要根据你的语料特性进行调优对于法律、金融等专业术语强的领域α可以设低一些如0.3-0.5更依赖关键词对于创意、咨询等需要理解概念的领域α可以设高一些如0.7-0.9。2.1.2 查询理解与改写先听懂问题再找答案用户的问题往往是模糊、简短或包含指代的。直接拿原始问题去检索效果大打折扣。这里必须引入“查询理解”层。查询扩展自动为问题添加同义词或相关术语。例如用户问“苹果最新手机”系统可以自动扩展为“苹果 iPhone 15 Pro 最新型号”。查询重写利用一个小型的LLM如GPT-3.5-turbo将口语化、不完整的问题重写成更适合检索的陈述句。例如“上次开会说的那个预算方案咋样了”可以重写为“关于[某项目]预算方案的会议讨论结果与当前状态”。意图识别判断用户是想进行事实问答、概念解释、列表汇总还是比较分析。不同的意图对应不同的检索策略和后续提示词模板。实操心得不要小看查询改写这是提升检索召回率性价比最高的方法之一。我通常会准备一个专门的提示词模板给LLM指令如“你是一个专业的搜索查询优化助手。请将以下用户问题改写成一句完整、清晰、包含核心实体的陈述句用于文档检索。只输出改写后的句子。”2.2 文本分割与向量化知识“切片”的艺术文档处理是RAG的“地基”地基不牢后面全倒。核心矛盾在于切片太大会引入无关噪声切片太小会丢失关键上下文。2.2.1 超越简单重叠基于语义和结构的智能分块常见的按固定字符数滑动窗口分割的方法非常粗糙。更好的做法是优先按自然边界分割先利用标点句号、问号、换行符以及Markdown/PDF的标题# ##进行粗分。递归分割对于仍然过长的段落如超过500字再按语义进行二次分割。可以使用句子转换器模型计算句子间的相似度在语义转折处进行切割。保留上下文重叠在块与块之间保留一小部分重叠文本如100-150个字符这能有效防止一个完整的答案被生硬地切在两块中间。但重叠不是简单的字符重复最好是在语义完整的句子边界处开始重叠。2.2.2 向量模型选型与微调让模型听懂你的“行话”通用模型如text-embedding-ada-002bge-large-zh是很好的起点但对于垂直领域医疗、法律、金融它们对专业术语的编码能力可能不足。领域模型优先首先寻找是否有开源的领域专用嵌入模型比如针对生物医学的BioBERT针对法律的LawBERT。微调嵌入模型如果找不到合适的且你有足够的领域文本对数据问题-相关段落对可以对开源嵌入模型进行微调。这能显著提升模型对你领域内术语和表述方式的“理解”能力。微调的目标是让相关文本对的向量在空间中被“拉近”不相关的被“推远”。向量维度与归一化注意不同模型的输出维度不同384 768 1024等。存入向量数据库前务必对向量进行归一化处理即转化为单位向量。这样相似度计算通常用余弦相似度会更加高效和准确。大多数向量数据库客户端库都提供归一化函数。2.3 生成器与大模型提示工程从“复读机”到“分析师”检索到相关片段后如何让大模型生成高质量答案这完全取决于你如何“指挥”它。2.3.1 上下文编排与指令设计不要简单地把检索到的文本块拼接起来扔给LLM。你需要设计一个结构化的提示词模板通常包含以下几个部分系统角色指令明确告诉模型它应该扮演的角色和回答风格。“你是一个严谨的金融分析师基于提供的资料回答问题。资料中未提及的信息严禁编造。”任务指令清晰说明任务。“请根据以下提供的背景资料回答用户的问题。”上下文资料以清晰的方式呈现检索结果。建议使用分隔符如---并标注来源序号例如[资料1]...内容...。这有助于模型区分不同来源。用户问题重复或明确用户的问题。输出格式要求如果需要特定格式如要点列表、JSON、包含引用的段落必须明确指定。2.3.2 引用与溯源让答案可信、可验证对于知识类应用让模型在答案中注明引用来源至关重要。这不仅能增加可信度也方便用户追溯和核实。 在提示词中明确要求“请在答案中为每一个关键事实或陈述标注其所依据的资料编号例如‘...根据[资料1]和[资料3]显示...’。如果资料中找不到相关信息请直接回答‘根据现有资料无法找到相关信息’不要自行推断。”3. RAG全链路调优实战指南理解了核心组件我们就可以进入实战调优环节。调优是一个迭代和评估的过程需要建立量化指标。3.1 评估体系搭建如何衡量RAG的“好”在盲目调整参数前必须先定义什么是“好”。我建议从以下几个维度建立评估集检索相关性检索到的Top-K个文档片段有多少是真正与问题相关的可以人工标注或利用GPT-4作为裁判进行评分。答案忠实度模型生成的答案是否严格基于提供的上下文有没有“幻觉”编造信息这是RAG最核心的指标。答案相关性生成的答案是否正面、完整地回答了用户的问题答案流畅度答案是否通顺、符合语言习惯你可以准备一个包含约100-200个“问题-标准答案-相关文档”的测试集。每次系统迭代后用这个测试集进行自动化或半自动化评估记录指标变化。3.2 分阶段调优策略第一阶段优化检索召回率优先目标确保所有相关文档片段都能被检索到。调整文本分块大小和重叠度尝试不同组合如块大小256/512/1024字符重叠50/100字符观察召回率变化。强化查询改写完善你的查询改写提示词并测试不同的小模型如ChatGLM3-6B, Qwen-7B的改写效果。启用混合检索引入关键词检索调整混合权重α。增加检索数量暂时提高Top-K的值如从3提高到10确保不漏检。第二阶段优化排序精确率优先目标让最相关的文档片段排在前面。引入重排序模型在初步检索出较多结果如Top-20后使用一个更精细的交叉编码器模型如bge-reranker-large对结果进行重排序。交叉编码器同时编码问题和文档计算相关性得分比单纯的向量点积更准确但计算代价更高因此只适合对少量候选进行精排。优化元数据过滤如果你的文档有来源、日期、类型等元数据在检索时加入过滤条件可以大幅提升前排结果的精确性。第三阶段优化生成质量与可控性目标生成忠实、流畅、有用的答案。迭代提示词模板这是成本最低、效果最明显的调优手段。针对测试集中回答不好的案例分析是模型误解了指令还是上下文编排混乱然后针对性修改提示词。A/B测试不同版本的提示词。控制上下文长度不是把所有检索到的片段都塞给模型。根据重排序后的得分只选取Top-N如3-5个最相关的片段并确保总长度不超过模型上下文窗口的70%为模型思考和生成留出空间。调整生成参数对于开源模型可以调整temperature降低以减少随机性、top_p等参数使生成结果更稳定。对于事实性问答通常使用较低的temperature如0.1-0.3。3.3 高级模式与技巧3.3.1 递归检索与问答链对于复杂、多步骤的问题可以采用“分而治之”的策略。首先让LLM根据原始问题拆解成几个子问题。然后针对每个子问题独立进行检索和获取答案。最后将所有子答案汇总再让LLM综合成最终答案。 这种方式能更深入地回答复杂问题例如“对比A产品和B产品在价格、性能和生态上的优劣”。3.3.2 智能路由何时检索何时直接回答并非所有问题都需要检索。对于一些通用知识、问候语或系统指令可以直接让LLM回答这样响应更快。 可以训练一个简单的分类器或使用小LLM判断根据用户问题决定路径通用对话 - 直接生成涉及专有知识 - 启动RAG流程。4. 常见“坑点”排查与性能优化实录即使按照最佳实践搭建在实际运行中还是会遇到各种问题。下面是我遇到的一些典型问题及解决方案。4.1 答案中出现“幻觉”或编造信息这是最致命的问题。排查1检查检索结果。首先确认你提供给模型的上下文资料里是否真的包含答案。很可能检索本身就没找到相关信息。你需要回到第一阶段优化检索召回率。排查2强化指令。在系统提示词中用更严厉、更明确的语言限制模型。例如“你必须且只能使用以下提供的背景资料来回答问题。资料中没有的信息即使你知道也绝对不允许在答案中出现。如果资料不足以回答问题请明确说明‘根据已知信息无法回答’。”排查3降低模型“创造力”。将生成参数temperature调至0或使用更保守的模型某些模型在事实性上表现更好。4.2 检索结果看似相关但答案质量不高排查1上下文噪声过大。可能是文本分块不合理一个块里包含了多个不相关主题。尝试减小分块尺寸或采用更智能的语义分割。排查2关键信息被截断。答案所需的信息恰好落在两个块的边缘。增加块之间的重叠度。排查3模型未能理解指令。尝试简化你的提示词用更直白的语言告诉模型“先引用资料再总结”。可以使用思维链提示例如“请按以下步骤思考1. 从资料中找到与问题相关的内容。2. 引用这些内容。3. 基于引用内容组织答案。”4.3 系统响应速度慢瓶颈定位使用性能分析工具确定是检索慢向量数据库查询、还是生成慢LLM API调用、还是预处理慢文本分割嵌入。优化检索对向量索引使用HNSW或IVF等近似搜索算法在精度和速度间取得平衡。为频繁查询的问题建立缓存。使用元数据过滤提前缩小搜索范围。优化生成考虑使用更快的模型如从GPT-4降级到GPT-3.5-Turbo或使用更快的开源模型。如果答案较长可以尝试使用流式输出让用户边看边等。4.4 处理长文档或复杂格式文档如PDF、PPT效果差预处理是关键不要直接用简单的文本提取工具。使用专门的库如pymupdffor PDF,python-pptxfor PPT来提取文本并尽力保留结构信息标题、列表、表格。表格处理表格是信息密集区但提取后容易乱。可以尝试将表格转换为Markdown格式或描述性文本如“下表显示了2023年各季度营收Q1: 100万 Q2: 150万...”再存入向量库。分章节处理对于长文档如书籍、手册可以按章节或目录进行分割并将章节标题作为元数据存入检索时可以利用这些元数据进行过滤。RAG系统的调优是一个永无止境的过程它高度依赖于你的具体数据、领域和用户需求。没有放之四海而皆准的“银弹”参数。最好的方法就是建立评估基线然后进行小步快跑式的迭代实验每次只改变一个变量比如分块大小、提示词、重排序模型观察评估指标的变化找到最适合你自己场景的那个“甜蜜点”。记住目标是构建一个可靠、可信的知识助手而不是一个炫技的模型玩具。从最影响核心体验的“答案忠实度”和“检索相关性”入手你的RAG系统就能一步步从“能用”变得“好用”最终成为真正的生产力工具。
