刚做完整套企业级RAG系统趁着热乎劲儿把全流程拆开揉碎了讲一遍。这篇文章不是给那种跑个向量数据库demo就觉得自己懂RAG的人看的而是要奔着生产环境去的那种实战级别。从数据清洗到检索调优从提示词工程到监控评估每一环都对应到真实项目里会踩的坑和实际的解法尽量把为什么这么做也讲清楚这样你拿到别的问题时也能举一反三。1. 为什么demo级RAG和企业级RAG之间隔着一道天堑先聊点实际的。绝大多数人第一次做RAG是在某个开源框架里改了改prompt接了个向量库然后传几篇PDF进去发现效果还不错于是觉得自己已经掌握了RAG。但这个还不错是有很大水分的——本地demo里那几篇文档跟真实企业里动辄几十万份合同、上万页技术手册、随时在更新的数据库记录根本不是一个量级的问题。我在项目里接手过一个早期原型当时的做法就是把一堆Word文档切块后丢进向量库召回时用embedding相似度取top-k直接灌给大模型。结果一到准生产环境问题一窝蜂冒出来重复内容多导致检索结果高度冗余、术语变体匹配不了、文档版本新旧混杂导致答案自相矛盾、单次请求延迟忽高忽低。最后我花了两周时间重构整个链路才意识到企业级RAG根本不是向量检索大模型这么简单它至少要同时解决数据治理、切分策略、混合召回、重排序、上下文压缩、推理链路优化、评估与观测这七件事。所以这篇文章的路线就是按照企业落地顺序来的。你先有一个全局地图知道每一环是干什么的然后再看每一环里的关键决策是怎么做的。这样哪怕用的技术栈跟我完全不一样整体的推进节奏和思路也是通用的。还有一个经常被忽略的问题RAG和微调的关系。很多团队一上来就问要不要微调模型我的建议是能靠RAG解决的现阶段一律不要微调。原因很直接微调是把你已知的知识固化进模型参数里可企业知识库的变更频率是按周甚至是按天计算的你不可能每次更新几十条FAQ就去重训一次模型。RAG的本质是把知识外置到模型之外随时可增、可删、可改这是它对企业场景最大的价值。只有当你的场景是模型说话风格和格式必须固定或者需要学习特定领域的推理模式时微调才是更合适的工具。2. 第一部分企业级RAG的数据接入与索引构建2.1 肮脏数据才是企业里的大多数你可能觉得数据接入没什么好讲的不就是读文件、转文本、切开、入库吗但真实企业文档的复杂程度远超一般人的想象。举几个我在实际项目中遇到的真实情况有几十个GB的扫描版PDF本质上是图片必须过OCR而且OCR出来的错字率直接决定了后续检索效果的下限有Excel里的单元格数据横竖结构跟自然语言完全不同直接转成文本切块语义就碎了有版本不断更新的合同模板同一份编号在不同目录里装了新旧两个版本召回时你不知道抽到的是哪一版还有大量带公司内部专用缩写的技术文档比如PRD和产品需求文档在业务里是同一个概念但embedding模型的词典里不一定理解这种等价关系。这些问题的本质是embedding模型在向量空间里对文本的语义理解跟企业领域内的事实正确性是两回事。模型可以把两句话表面写得很像的文本判定为相似却不一定能把同一个意思但表述完全不同的文本关联起来。这也是为什么企业级RAG的第一个重点不在算法而在数据治理管道上。所以我在做数据接入时的建议是能做文本提取的绝不做OCR原生PDF导出的电子文本精度高、成本低OCR只留给扫描件。OCR之后必须做纠错后处理像0和O、中文标点混用、断行粘连这些都要有专门的后置处理逻辑。文档必须打元数据标签来源、部门、创建日期、版本号、权限级别、最后更新时间这些是后续做过滤和权限控制的基础。知识更新要有版本管理同一个知识点的多版本内容要么只允许最新版进入索引要么在检索时强制按版本号过滤。这里有一个容易被忽略的细节元数据不只是检索过滤用的它还是引用溯源的基础。用户问一个答案时如果你只能告诉他某个PDF里有他大概率还是不敢直接采信。但如果你能精确到答案来自某部门2025年3月版的管理制度第42页第3条信任度就完全不一样了。所以从数据入库那一刻起每个切块都要带着完整的来源链。2.2 切分策略的决策逻辑从小而多到大而少文本切分这件事听起来是所有环节里最简单的但实际上它对检索质量的影响比很多人想的大得多。同样的文档你按256个字切和按1024个字切同样的提问召回结果和答案质量可能完全不同。切的太小问题就来了语义被割裂。比如有一个段落讲系统安全性设计包含数据加密、权限控制、审计日志三部分其中数据加密又分为传输加密和存储加密如果按256字硬切很可能把传输加密和存储加密切到下一个块里导致用户问存储加密怎么做时召回的上文里根本没有这个关键信息。切的太大问题同样严重一个块里塞了太多不同的主题embedding时整个块的向量会被平均化掉变成一个四不像的语义检索时相似度分数虽然可能过线但真正命中的关键词占比不高大模型拿到的上下文噪点太多答案质量照样上不去。那标准是什么呢我的经验是切分策略要跟着文档结构走而不是跟着固定字数走。Markdown标题、PDF章节结构、Word大纲层级这些天然就是文档的语义边界。所以我的推荐不是某个固定数字而是一个决策路径优先按文档的结构化标题切保持每个章节的完整性。章节太长超过模型上下文窗口的合理占比比如超过1000~1500字才做二次切分。二次切分时用滑动窗口加重叠的方式重叠区长度取整个窗口的10%到15%保证语义衔接不出现硬断层。所有块在入库时必须带两个指针指向它的父级章节指向它的子级内容。这个父子结构是后面做上下文扩展和检索优化的关键。我见过很多团队在切分上反复调整参数但效果一直不稳定本质原因是他们忽略了切分粒度必须与文档本身的叙事结构对齐这个原则。文档本身就是按章节组织的算法层面的切分应该去顺应它而不是用固定长度去破坏它。2.3 Embedding选型从通用模型到领域微调Embedding模型的选择是企业级RAG里最容易被忽视的长期决策。通用embedding模型在一般场景下表现尚可但当你处理的文档行业属性很重时差距就变得很明显了。医学文档里的造影剂和增强扫描之间的关联度通用模型不一定会算得很高法律文书里的对价和合同履行这种隐含逻辑关系通用模型大概率也是弱关联。用这种embedding去建索引检索层的天花板从一开始就非常低后面不管你怎么调重排序、怎么写提示词都补不回来。解决这个问题的路径有两条。第一条是选一个在垂直领域上有优势的开源embedding模型比如针对中文法律、医疗、金融场景专门训练过的模型先用领域内的语料做召回测试看效果。第二条是拿企业自己的问答对和文档段落做embedding微调这种路线通常是调用开源模型然后用自己的领域数据去训练成本可控但需要花时间做数据准备。就我个人的建议如果你的企业文档术语密度很高不要跳过验证直接上手一定要先做一轮领域召回测试。怎么测抽50到100个真实业务提问从知识库里标出正确的召回段落然后看你选的embedding模型能不能把这些段落排到前10名里去。如果排不进去换模型或者做微调这个动作越早做越好。还有一个细节embedding模型和生成模型不要混为一谈。很多人以为用了同一个模型厂商的产品就更配但实际上embedding模型解决的问题是哪些文本语义接近生成模型解决的是给定上下文怎么组织回答两个问题完全独立。你完全可以用一个垂直领域embedding模型配一个通用生成模型效果反而更好。3. 第二部分检索层设计不只是向量相似度3.1 向量检索兜底关键词检索兜准确性纯向量检索有一个天生的缺陷它是在语义空间里做近似匹配而不是在文本空间里做精确匹配。用户问2024年Q3营收是多少如果你的文档里表述是三季度总收入或者第三季度营业收入向量检索大概率能匹配到但如果用户问的是这家公司的代码是多少而文档里写的是证券代码600xxx这种精确的键值对关系向量检索的表现反而不如一个简单的关键词匹配。这里的关键词检索指的就是传统稀疏检索基本算法是BM25那一类。它的优势在于对专有名词、编号、代码、日期这类精确信息非常敏感而且速度快、可解释性强。真正企业级RAG的检索层几乎都采用混合检索的路线向量召回负责找语义上相关的段落关键词召回负责做精确匹配然后把两路结果合并。合并的方式也有讲究。简单的做法是两路结果直接拼接、取top-k但这样容易造成重复内容过多或排序混乱。更稳妥的做法是用**RRFReciprocal Rank Fusion**这种融合算法把两路排序中每个文档的排名倒数相加得到一个融合分数再按融合分数排序。这样做的好处是它不依赖两个检索通道的分数尺度对齐因为一个是余弦相似度一个是BM25权重两个分数本来就没有可比性直接相加没有意义。我自己常用的检索链路大致是这样向量检索取top 50为后续重排序留出足够候选空间。关键词检索结合业务场景决定是否加权比如用户输入包含编号或精确术语时提高权重。合并用RRF融合。过滤把元数据过滤条件如日期范围、权限级别、文档类型在融合前就加上减少无效候选。重排序对融合后的top-n再用一个更强的排序模型精排。3.2 重排序把近似相关变成真正有用从向量检索和关键词检索出来的前50个候选里真正对生成答案有用的可能只有三五个。如果不做重排序直接把前5个灌给大模型大概率有一半是又臭又长的边缘内容轻则干扰模型重则让答案直接偏掉。重排序模型Reranker的作用是拿用户的问题和每一段候选文本做一次深度交互计算重新评估这个段落对这个问题的真实价值。注意它和embedding模型的区别——embedding模型是把问题和文档分别编码成向量再算相似度这里面有一个信息压缩的损失而重排序模型是把用户问题和文档拼接起来用深度模型去判断它们之间的匹配程度计算更精细效果也更强。所以在企业级RAG里重排序不是可选项而是生产环境的基本配置。具体的工程做法是向量检索和关键词检索这两步只负责海选把候选从几万里缩到几十条然后重排序负责精选从几十条里排出真正有用的三五条。这样既能控制延迟又能保证质量。这里有一个很实用的经验尽量选那种能输出分数、或者至少能输出排序位置的重排序模型这样你可以根据分数分布设置阈值把低分段落直接过滤掉。比如我实测下来低于某个分数阈值的段落灌进上下文后要么被模型忽略、要么产生误导信息效果基本都是负的不如直接丢弃。3.3 上下文组装把时间花在塞什么上检索层拿到重排序后的段落之后下一个关键动作就是组装上下文。很多人的做法是把前5个段落原样拼在一起中间加个换行符就丢给大模型了。这个做法的问题在于你把主动权完全交给了大模型去判断哪些段落有用、哪些没用。在今天的大模型对长上下文的理解能力来看这种一股脑全塞进去的做法经常会导致注意力分散核心答案被边缘信息压住。我的建议是在组装时做三件事按重排序分数和段落来源去冗余同一个文档里多个段落都在讲同一件事时只保留分数最高的一段或两段。为每段内容添加一个前置说明比如文档《数据安全管理制度》第3章第2节存储加密要求内容。这样大模型在阅读时是带背景地读而不是读一堆裸文本。做上下文压缩如果候选段落中有大段的表格、日志、代码块而这些内容跟当前问题的相关性很低可以直接截断或只保留关键行。这个动作能显著减少大模型被无关噪声带偏的概率。上下文组装的质量实际上决定了生成层的上限。检索再好组装得乱七八糟大模型也发挥不出来。这是一个在直觉上很容易被低估、但实际上性价比极高的优化点。4. 第三部分生成层调优与幻觉治理4.1 提示词工程基础设施让约束落在机制里关于提示词很多人以为就是写一段文字告诉模型请基于以下文段回答。这句话没说错但企业级RAG的提示词工程远不是写一段话那么简单。它应该是一个结构化的、可配置的基础设施至少要包含以下几个模块系统角色定义告诉模型它是谁、它回答问题的边界是什么、什么情况要拒绝回答。检索上下文插入区规定上下文的展示格式和顺序。输出约束区明确回答的格式、是否需要引用来源、引用格式是什么。兜底策略区当检索为空或置信度过低时模型应该怎么表现是承认自己不知道还是给出一个模糊的推测。我在实际项目里遇到过一种典型场景用户问一个知识库里根本没有答案的问题大模型因为答不上来显得不专业自动开始编造而且编得还挺像回事。这个问题在提示词层面是有解法的你在提示词里明确写如果提供的上下文中没有用户问题的相关信息请直接回答根据当前知识库无法回答此问题并建议用户联系相关业务部门。这句话看着简单但能有效压住大模型硬答的冲动。另外提示词本身要作为代码来维护要有版本号、要有评审记录、要支持A/B测试。很多团队改提示词是直接在生产环境的大模型对话界面里动手改完也不知道效果变好还是变坏全靠手感这种玩法在企业级系统里是不能接受的。4.2 RAG的幻觉分两种治理策略完全不同幻觉是RAG系统里最让人头疼的问题但仔细拆开来看它至少分两种成因和治理逻辑都不一样。一种是上下文冲突型幻觉检索结果里面有多段内容一部分支持答案A一部分支持答案B两方都出现在上下文里模型裁断不了于是开始自由发挥取了一个看似合理的折中答案但其实是错的。治理这类幻觉靠的是检索和组装阶段把冲突内容过滤掉或者当检测到冲突时把两种可能性并列输出来让用户自己去判断。另一种是推理外溢型幻觉上下文里的信息本身是对的但模型在做推理时用自己参数里固有的世界知识补了上下文里没有的细节补出来的部分就是幻觉。比如文档里写该药品每日服用三次模型在回答时自己加了一句建议饭后服用这个饭后服用完全是从参数里带出来的不是文档说的。治理这类幻觉提示词能起到一定作用比如强调只能基于上下文陈述不得补入个人知识但更根本的手段是在生成之后加一道验证步骤。4.3 生成后验证把幻觉挡在最后一公里之外我在生产环境里最看重的一道防线是生成后的自动验证。具体做法是把用户的提问、检索到的上下文、模型生成的回答三部分合在一起用一个专门的验证模块去判断回答中的关键陈述是否都能在上下文中找到依据有没有超出上下文范围的表述。这种验证可以做成三种粒度粗粒度判断整段回答和上下文之间的一致性分数低于阈值则触发重答或拒答。中等粒度把回答按句切开逐句确认哪句有上下文依据哪句没有把没有依据的句子直接剔除或标注为模型推测。细粒度用另一个模型把回答里的关键实体和数值提取出来到上下文里做精确匹配。比如回答里出现了2024年营收3.2亿元就去上下文里查有没有这组文本如果没有基本可以判定这是一处幻觉。细粒度验证的成本是最高的但它在你处理金融数据、医疗建议、法律条款这类对准确性要求极高的场景时几乎是刚需。我一般建议在系统上线初期先用粗粒度和中等粒度等积累了一定量的badcase之后再针对高频出错类型上细粒度验证。4.4 引用溯源让用户自己二次验证企业级RAG和普通QA工具最大的一个不同是它需要支持用户对答案的二次验证。不管你的生成质量调得多好总会有漏网之鱼。所以系统必须在每个答案后面附上引用的来源信息来自哪个文档、哪个章节、原文是什么、甚至给出原文的链接或下载路径。如何实现引用溯源其实和前面讲的元数据标记是一套机制。在数据进入索引时每个切块都带着自身的来源链在组装上下文时哪段内容最终被模型用来生成了答案就把那段内容的来源链作为引用输出。不用等模型生成完毕再去做归因那样又慢又不可靠。有了引用溯源至少有三类反面价值用户看到来源后自己就能判断答案可信度减少了客服或业务人员的二次确认负担当系统出错时你可以从引用链路出发快速复盘是哪一段检索或组装环节出了问题当用户反馈回答说错了时你可以立刻看出来到底是引用错了、检索错了还是生成错了而不是像黑盒一样无从下手。5. 第四部分企业级RAG的工程化落地与运维5.1 RAG评估体系没有度量就没有优化你一定会遇到这种问题怎么知道系统效果变好了还是变坏了或者我改了重排序怎么评估是不是真的有效如果回答不上来说明你的RAG系统还停留在实验室阶段。企业级RAG必须有一套自动化的评估体系。现在开源社区已经有不少成熟的评估框架用生成式模型来给检索和生成两个阶段分别打分。核心评估维度如下检索召回率Recall正确答案对应的文档是否被检索结果覆盖到。检索精确率Precision检索结果里真正跟问题相关的比例。答案忠实度Faithfulness生成答案中的信息是否都能在上下文里找到依据。答案相关性Relevance答案是不是真正回答了用户的问题。答案完整性Completeness答案有没有漏掉用户问的关键点。这里我想强调一个经验不要让评估框架仅凭大模型打一个分就完事一定要配上一批固定的人工标注的测试集。大模型打分在粗筛比如识别明显错误的答案上很好用但在精细判断上比如这个回答是不是比另一个回答更好还是不够稳定。一套靠谱的评估体系应该是由几十到上百条带标注的黄金测试集兜底加上大模型自动评分为辅助再定期补充线上badcase的机制。测试集怎么建不用一上来就追求数量。先找业务方收集真实的用户问题挑出覆盖不同业务场景和不同难度的50条手工为每条标注正确的答案和对应的文档段落这就够第一版评估了。后面每两周根据线上日志的badcase做一次扩充。5.2 缓存策略别让每次提问都从头跑一遍企业级RAG在生产环境里的一个很现实的成本问题是用户问的问题重复度其实很高尤其是售后、客服、HR这种场景翻来覆去就那些高频问题。如果每次提问都走一遍embedding检索重排序大模型推理的全链路成本和延迟都吃不消。所以缓存那层至关重要。我的做法是把缓存拆成两级语义缓存用户新问题先算embedding和过去一段时间内的问题向量做相似度比对如果相似度超过阈值比如0.95直接返回那个问题当时的结果不再走完整链路。这个方案对同一个意思换不同说法特别有效。精确缓存用户问题完全相同包括标点、英文字母大小写归一化后完全相同直接命中结果。缓存技术层面的实现不难难在缓存失效策略上。知识库内容更新后缓存的结果可能已经过期了这时候需要按知识来源做定向清理哪些缓存结果是用到了这个被更新过的文档的把这些缓存全部失效。这个引用级缓存失效机制听着麻烦但在真实环境里能避免很多尴尬场面。5.3 知识更新的节奏感异步做海量更新同步做高频增量企业知识库的更新方式有两种典型场景。一种是批量更新比如每个月把最新的规章制度、产品手册一次性导入系统这种场景下要做的是离线重建索引、提前跑质量验证、确认无误后切换线上索引。另一种是增量更新比如某个业务字段每天在变、某些FAQ每周在加这种场景要求系统具备实时或准实时的增量索引能力。我见过有团队把每次新增文档都触发全量索引重建几十万条向量的索引重建动辄几十分钟期间线上检索还用着旧索引新文档的检索体验就会延迟很久。正确的做法是增量更新走增量通道比如每天凌晨批量入索引只有发生变更的数据子集才做局部重新向量化和替换。遇到巨量历史数据首次导入时就走全量重建加双索引切换的流程。双索引切换这个操作的本质就是先建好一套新索引配置好验证通过然后原子地把检索请求切换到新索引上过程中不走停顿也不影响线上用户。5.4 权限与安全设计你的知识库不是所有人的知识库聊到权限控制很多RAG系统在demo阶段完全不做这个设计所有人都查所有文档。但企业场景里权限隔离是一个绕不开的硬需求。比如合同库里的客户敏感信息、薪酬文档里的内部数据、还在走审批流程的未公开产品方案这些如果被一个统一检索接口暴露出去就不是效果问题了是合规和事故问题。权限与RAG的结合点在数据索引阶段就要想清楚每个切块上都带着元数据标签标签里包含文档的可见范围、需要的权限级别、密级标记。在检索阶段先根据当前用户的身份做过滤把没有权限访问的文档从候选集里直接剔除然后再做召回。这个先过滤后召回的顺序非常重要它保证了权限控制不会因为向量检索的模糊性而产生漏网情况如果你先跑召回再按权限过滤一旦某段敏感内容分数略高被灌进上下文之后再过滤就已经晚了。5.5 日志与可观测性RAG排障的核心抓手RAG系统排障难难在它是一个多阶段的请求链路每个阶段都有可能出问题。用户只看到最终答案不对但你不知道是检索没召回相关段落还是召回了但重排序把它压下去了还是排序对了但组装上下文时截断了关键内容还是模型生成时没有忠实于上下文。所以在生产环境里每一个RAG请求的完整链路日志都必须被记录成结构化数据。至少要包含用户原始问题、改写后的问题如果你做了查询改写、检索到的候文档ID列表、每份候选的重排序分数、最终进入上下文的段落列表、组装后的完整提示词、模型生成的结果、引用来源列表。有了这串记录当线上出现了一条badcase你可以把整条链路拉出来复盘精准定位到问题发生在哪一环而不是靠猜。这块我踩过最大的坑是早期没有对链路日志做采样存储只存了最终答案。后来某天客户反馈系统回答错误还给出了一个完全不存在的引用来源我翻遍日志也看不到具体是哪份文档哪一段被用进了上下文排查进度卡了一整天。从那之后我上了全链路日志前后端一对照十秒钟就能定位问题。这个经验我觉得做生产级RAG的人都应该早点遇到不要像我一样等到栽了跟头才补齐。6. 第五部分性能调优与成本控制的实操经验6.1 延迟预算与优化顺序企业级RAG系统上线后延迟是第一个被业务方拿放大镜盯着的指标。一次RAG请求的链路大概是用户问题进入系统、embedding计算、向量索引查询、关键词索引查询、融合排序、重排序模型推理、组装上下文、大模型生成、生成后验证。每一个环节都拖几毫秒到几百毫秒加起来就非常可观了。一个核心的认知是RAG系统里的延迟瓶颈通常在大模型生成这几百毫秒到几秒而不是在检索通常只有几十毫秒。所以优化检索端到极致效果也很有限。真正能大幅降低端到端延迟的地方全在生成环节。我的优化顺序一般是这样的第一步上下文按需裁剪。把提示词中的不必要的系统描述、背景信息、前几轮的对话历史适量缩减上下文短则生成快这是最直接有效的。第二步引入语义缓存。重复问题不再走完整链路延迟直接从秒级降到几十毫秒。第三步模型推理层面优化。比如开启流式输出、用更小的模型处理某些简单场景、启用服务端的批处理推理模式。最后才考虑换更快但更贵的推理服务。不要一上来就上最强的算力先看看上下文压缩和缓存能不能解决大部分问题成本差异不是一个量级。6.2 算力成本控制不是每类问题都需要最强的模型成本控制的核心思路是不要把所有问题都喂给同一个天花板配置的模型。企业里的问题天然是分层的有的问题需要很强的推理和综合能力比如这批合同里哪些条款跟新政策不一致请给出一份对比报告有的问题则非常简单比如年假政策是几天。后一类问题用一个小参数的模型就能答得很好完全没必要用最强模型。所以我推荐在生产环境里配置一个分级路由策略在检索完成后、生成前判断当前问题的复杂度检索结果相关性均值很高、候选段落之间无冲突、历史同类问题在低配模型上的回归测试表现良好就路由到中低配模型发现检索结果分散、存在冲突、需要跨多个段落推理才把请求交给高配模型。这种做法在保证回答质量不降的前提下最多能节省一半以上的推理成本。还有一种做法是先小模型后验证先用一个小模型生成一个候选答案再用验证模块检查答案质量如果验证显示候选答案在忠实度和相关性上达标就直接返回如果验证发现质量不足再升级到高配模型重新生成。这种try small then fallback的思路在业务上很多场景是适用的尤其适合高频低难度的问答。6.3 高频链路的批处理与并发设计在并发层面企业级RAG要注意的是不要让单次请求独占整个链路资源。几个实用经验Embedding计算可以按批处理一次算多个问题吞吐量和单线程并发启动的开销差距明显。向量索引和关键词索引可以并行查询两个通道合并结果前谁先返回谁等待整体延迟取决于慢的那个所以在设计时要在重排序前做并行控制的等待策略。大模型推理层要关注服务的并发上限和排队机制宁可设置一个较短的排队超时比如5秒并快速失败也不要让用户无限等待失败后前端引导用户重试或提供降级回复。并发设计这块的核心原则是把检索阶段做成无状态的一等公民让每个请求都在几十毫秒内完成检索然后进入可控的生成队列。检索层的水平扩容很简单但生成层的并发控制一旦设计不好服务一旦被压垮所有请求排在一起全部超时事故波及面会非常大。7. 第六部分从原型到生产我踩过的几个最深的坑7.1 依赖默认配置忽略了领域适配我接手过的一套早期RAG系统用了默认文本切分器、默认embedding模型、默认top-k设置几乎所有的配置都是开箱即用的。在真实业务文档上效果非常差但一开始没人知道为什么因为没有任何一层暴露了量化指标。后面我逐步把每一层都跑了单独的评估才发现问题出在一开始就在默认配置下执行。这件事给我的教训是RAG系统的每一层都必须能在脱离其他层的情况下独立评估。检索层只测检索生成层只测生成哪一层出了问题一测便知。不要拿着端到端的结果去猜是哪一层的锅。7.2 忽略query理解和问题改写我发现很多RAG系统线上badcase的根源其实不在检索和生成而在用户问题的表述方式上。企业知识库的问题往往带着口语化表达、拼写错误、指代模糊等比如用户问那个新出的报销规定怎么说这里那个新出的是一个时间指示性表达直接拿完整原文去检索效果很差。更好的做法是在接入检索之前多加一层查询理解和改写利用小模型或轻量规则判断用户问句中是否有指代表达、是否需要补充上下文或明确时间范围然后把它改写成一个更规范的检索式查询。这一层不复杂但在真实场景下提升效果非常显著。比如把那个新出的报销规定改写成近期发布的新版报销管理制度检索质量立刻就不一样了。7.3 上下文长度不是越大越好早前我做RAG时有一个误区能塞多少上下文就塞多少总觉得信息越多越好反正模型能处理。后来赚了大量的badcase教训才发现当上下文里塞入过多不相关内容时模型反而会被噪声带偏出现更大规模的幻觉。现在我的原则是上下文宁可少而精不要多而杂。经过混合检索和重排序之后真正和当前问题强相关的段落通常不会超过三五个强行塞进去的第六、第七段内容如果相关度不够效果只会扣分。所以组装的底线是给大模型的内容每一条都应该有充分的理由说明它和当前问题是强相关的否则宁可不要。7.4 没有预留拒答通道在早期做交互设计时我把所有注意力都放在如何让系统答得更好上完全没考虑系统不应该答哪些问题。后来业务方提了一个特别实际的需求如果用户问的问题是知识库里完全没有的不要硬答不要猜。因为对于企业内部场景来说系统给出一个内容详实但错误的答案比干脆承认不知道要危险得多用户会把错的信息当成事实去执行风险不可控。于是我在系统里加了一条拒答通道检索结果整体相关度低于阈值、重排序最高分也低于阈值、或者生成后的验证无法在上下文中找到任何支撑内容时系统直接返回知识库中没有查询到相关信息建议您咨询某业务部门。这个通道的存在让系统的可信度和安全性有了质的提升。7.5 上线只是开始持续运营才是主战场RAG系统的上线永远不是终点。企业知识库在持续变化用户的问题在不断翻新业务方对回答的要求也在逐步提高。一个不做持续运营的RAG系统上线三个月后大概率会从还挺好用退化到怎么越来越蠢。持续运营的核心动作就是高频地抓badcase每周从线上日志里抽样最近用户提问人工标注哪些回答质量不合格把它们归成两类——检索没找对还是生成没答好。然后针对高频类型做定向优化检索类的去调切分或测试检索模型生成类的去改提示词结构或换重排序模型。这样一轮一轮迭代下去系统才会一点点逼近真的好用。有人会问这一整套做下来要花多少时间。我的经验是第一版跑通大概一两周但真正跑成生产可用、评估体系齐备、知识更新和安全机制完备之后前后大概需要两个月到三个月。这还是在团队里有人对每个环节都比较熟的情况下。如果你从零开始踩坑时间还会更长。希望这篇文章能帮你把时间线压缩短一点把那些我不该踩的坑提前绕开。如果看完还有哪一块想深入聊比如你们的文档类型特别怪、切分始终调不好、检索效果一直不如预期都可以在评论区把具体情况发出来我按实际场景给出更具体的思路。
