一个例子说明 RAG 8项优化策略

RAG即检索增强生成是知识库问答中常见的技术方案。它的基本流程是用户提出问题后系统先从知识库中检索相关资料再把资料交给大模型生成答案。RAG 的价值在于它可以让模型基于企业内部制度、产品手册、合同文档、技术资料等内容回答问题而不是完全依赖模型自身记忆。但在实际落地中RAG 并不是“文档入库 大模型生成”这么简单。很多系统会出现搜不到、搜不准、答不全、引用错误、模型胡编等问题。因此RAG 优化要从知识库质量、文档切分、检索、重排序、上下文控制、模型选择和生成约束等多个环节一起考虑。下面以一个企业“差旅制度问答助手”为例说明。假设用户问“我下周去上海出差住宿费最多能报多少”这个问题看似简单实际上包含多个条件用户属于哪个部门上海属于什么城市等级当前制度是哪一版是否有特殊岗位补充规定出差目的是否为客户拜访如果系统只是检索“上海、出差、住宿费”很可能给出片面的答案。首先要优化知识库数据质量。假设企业知识库中可能同时存在《2022 年差旅报销制度》《2024 年差旅报销制度》《销售部差旅补充规定》《财务报销流程说明》等文件。如果没有标注版本、生效时间、适用部门和是否废止系统可能把旧制度当成新制度使用。例如《2022 年制度》写上海住宿标准为 500 元/天《2024 年制度》更新为 600 元/天如果系统召回旧文件就会直接答错。因此文档入库前要做数据治理。每份文件应标注来源、时间、版本、适用范围、是否有效。例如《2024 年差旅报销制度》标注为“当前有效适用于全体员工”《销售部差旅补充规定》标注为“仅适用于销售部客户拜访场景”。这些元数据可以帮助系统在检索时优先使用正确资料。其次要优化文档切分。不能简单按固定字数切分文档。差旅制度通常包含住宿标准、交通标准、餐补标准、审批流程、报销材料等内容。如果切分太大大模型会收到大量无关信息如果切分太小又可能把“适用条件”和“金额标准”拆开。更好的方式是按文档结构切分例如“差旅制度 住宿标准”“差旅制度 交通标准”“销售部补充规定 客户拜访住宿标准”“财务流程 住宿费报销材料”这样用户问住宿费时系统可以精准定位住宿标准而不是混入高铁票、餐补、审批流程等无关内容。第三要优化检索策略。RAG 常用向量检索因为它能理解语义相似。例如用户说“住宿费最多能报多少”文档里写的是“酒店费用报销上限”二者词不完全一样但语义相近向量检索可以找到相关内容。不过单靠向量检索不够。像“上海”“销售部”“2024 年”“错误码 E102”这类明确词语需要关键词精确命中。因此实际系统中常使用混合检索把向量检索和关键词检索结合起来。向量检索解决“意思相近”关键词检索解决“关键条件必须命中”。第四可以加入查询改写。用户的问题往往是口语化的、不完整的。如果系统知道该用户属于销售部就可以把问题改写为“销售部员工前往上海出差的住宿报销上限是多少”如果上一轮对话中用户还提到“这次是去拜访客户”则可以进一步改写为“销售部员工因客户拜访前往上海出差时住宿费报销上限是多少”改写后的问题比原问题更适合检索因为它补全了部门、地点、场景等关键条件。第五重排序非常关键。检索阶段通常会先召回一批候选片段比如 20 条或 50 条。这些片段都可能相关但相关程度不同。重排序的作用就是对这些候选片段重新打分把最能回答问题的内容排到最前面。例如初步检索返回《2024 年差旅报销制度》上海住宿标准为 600 元/天。《2022 年差旅报销制度》上海住宿标准为 500 元/天。《销售部差旅补充规定》销售人员客户拜访期间上海住宿标准可上浮至 700 元/天。《财务报销流程》住宿费报销需提交酒店发票。《交通费报销规定》高铁二等座可报销。《一线城市名单》北京、上海、广州、深圳属于一线城市。如果没有重排序系统可能只因为第一条包含“上海、住宿、标准”就把它放在最前面然后回答“600 元/天”。这个答案在通用场景下没错但如果用户是销售部员工并且出差目的是客户拜访就不够准确。真正关键的依据是第三条即“可上浮至 700 元/天”。重排序不是简单看关键词多少而是判断内容是否真正回答了问题。《财务报销流程》虽然提到住宿费但回答的是“怎么报销”不是“最多报多少”《交通费报销规定》属于差旅制度但和住宿无关《2022 年制度》虽然有金额但版本过旧应降低优先级《销售部差旅补充规定》虽然适用范围更窄但如果用户身份和场景匹配就应排在最前面。因此重排序后的合理顺序应是《销售部差旅补充规定》客户拜访场景可上浮至 700 元/天。《2024 年差旅报销制度》上海普通住宿标准为 600 元/天。《财务报销流程》住宿费报销需提交酒店发票。《一线城市名单》上海属于一线城市。《2022 年差旅报销制度》旧版标准为 500 元/天。《交通费报销规定》与住宿问题无关。可以说召回解决的是“有没有找出来”重排序解决的是“有没有把最该看的内容放到最前面”。第六要关注模型参数量对 RAG 的影响。模型参数量越大通常理解能力、推理能力、总结能力越强。在 RAG 中大参数模型更擅长处理复杂上下文。例如当检索结果中同时出现“通用制度 600 元/天”和“销售部特殊场景 700 元/天”时大模型更容易理解二者不是矛盾而是适用条件不同。它能生成更完整的答案“普通情况为 600 元/天销售部客户拜访场景可按 700 元/天。”大参数模型还更擅长处理多段资料的归纳。例如模型需要同时看“上海属于一线城市”“一线城市住宿标准为 600 元/天”“销售部客户拜访可上浮 100 元”三段内容才能推导出最高 700 元/天。小模型可能只抓住其中一段回答不完整大模型更容易把多个证据组合起来。但是模型参数量变大并不代表 RAG 一定更准。因为 RAG 的准确性首先取决于检索资料是否正确。如果检索阶段把《2022 年旧制度》排在前面即使使用大模型也可能基于错误资料生成错误答案。大模型甚至可能因为语言能力更强把错误答案说得更自然、更自信。此外大模型成本更高、响应更慢。对于简单问题比如“报销需要发票吗”小模型配合准确检索就能回答没有必要每次都调用大模型。而对于复杂问题比如“销售部员工去上海拜访客户住宿费上限是多少和普通员工有什么区别”则更适合交给大模型处理。因此模型参数量对 RAG 的影响主要体现在三个方面第一影响对问题和上下文的理解深度第二影响多段资料的综合推理能力第三影响回答表达的完整性和稳定性。但它不能替代高质量检索。好的实践是简单问题用小模型复杂问题用大模型检索和重排序先尽量做好再让模型生成答案。第七要控制上下文质量。很多人以为给模型的资料越多越好其实不一定。上下文太长会稀释重点也会增加模型混淆概率。比如用户只问住宿费上限如果把整份差旅制度、交通制度、审批制度都塞进去模型可能把餐补、交通补贴甚至旧版标准混入答案。更好的做法是只保留最相关的片段。例如最终给模型的上下文包括上海普通住宿标准为 600 元/天销售部客户拜访场景可上浮至 700 元/天住宿费报销需提交酒店发票和出差审批单。这样既完整又减少干扰。第八要约束模型生成。RAG 不是让模型自由发挥而是让模型基于证据回答。提示词中应要求只根据提供资料回答资料不足时说明无法判断涉及金额、日期、制度条款时给出依据如果通用规则和特殊规则并存要说明适用条件。最终一个较好的回答应是“如果你是销售部员工并且本次上海出差属于客户拜访场景根据《销售部差旅补充规定》住宿费最高可按 700 元/天报销如果不属于该场景则按照《2024 年差旅报销制度》上海住宿标准为 600 元/天。报销时需要提交酒店发票和出差审批单。”这个答案比简单回答“600 元/天”更好因为它区分了不同条件也给出了制度依据。总的来说RAG 优化是一个全链路工程。知识库要干净文档要合理切分检索要兼顾语义和关键词重排序要把真正相关的内容放到前面上下文要精简准确模型生成要受到约束。模型参数量会影响理解、推理和表达能力但不能单独决定 RAG 效果。真正稳定的 RAG 系统是“高质量知识库 准确检索 有效重排序 合适模型 受控生成”的组合。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】