1. 项目背景一次“验收翻车”引发的思考先交代一下事情的起因。我手上这个药企知识库项目目标是帮一线医学部和市场部的同事快速查产品资料、临床指南和合规条款。项目做到验收阶段我按惯例搭了一套自动化评测集用几百道题跑了一遍RAG链路第一轮结果出来多选题准确率给了95分。当时现场气氛其实挺轻松大家都觉得效果不错马上就能上线了。但我总觉得哪里不对劲。95分这个数字是在“宽松评分”下算出来的——只要AI生成的答案里包含正确选项不管多选是否漏选、错选都算对。后来我手动调成“严格评分”正确答案和生成结果必须完全一致多选题一组选项一个都不能少一个都不能多。同样一批题、同一个RAG系统结果直接掉到85分。10分的差距暴露的不是“分数波动”而是整个RAG链路里一个特别容易被人忽略的问题——你的验收指标是不是真的在考核你关心的能力。这10分的背后藏着文档解析、分块、检索、重排、生成各个环节可能存在的真实损耗。这篇文章就把这个实测过程完整拆开来讲包括我后面怎么重新设计RAG验收方案以及现在踩过坑之后我对“RAG能不能用”这件事的判断标准。顺便说一句不是只有药企语料会这样。金融、法律、制造等领域的知识库只要语料里专业术语密集、答案以条例或条款为主、多选题和填空题占比高都会撞上同一堵墙。2. 为什么药企语料最容易暴露RAG的短板2.1 药企语料的三重麻烦先说说这批语料的构成不然你很难理解后面那些坑是怎么踩出来的。药企知识库里的内容大概有三类每一类都有它独特的“杀伤力”。第一类是产品资料与医学文献。这类文档术语密度极高一个句子里面可能同时出现“适应症”“不良反应”“药代动力学参数”这种非常精确的表述。更麻烦的是缩写和同义词“OS”在肿瘤领域指总生存期Overall Survival但如果在免疫领域语境里也可能是别的含义。检索系统如果只做字面匹配很容易把不相干的段落召回来。第二类是临床指南与专家共识。这种文档属于典型的“信息冗余少但逻辑嵌套深”很多结论都藏在“推荐等级”“证据等级”“特殊人群调整”这种分层结构里。内容本身是对的但你要让RAG在生成长回答时保持这种分层逻辑就非常考验上下文窗口的利用能力。第三类是内部制度与合规条款。这里面的语言是另一套体系大量使用“应当”“原则上”“不得”“除非”一句话里带着多个前提条件。对RAG来说最怕的就是这种带有“条件”或“例外”的描述——检索回来的片段如果被截断少了半句话全文意思就可能反过来。这三类语料放到一起等于给RAG出了三套不同的考题术语精度、逻辑结构、条件约束。这也是为什么药企项目用“多选题”当评测主题型特别合适——它能把这三类问题都暴露出来。2.2 多选题作为评测题的天然优势我在实际项目里选择多选题作为RAG评测的主力题型不是随便定的原因有下面几个。一是多选题天然需要多段落联合推理。单选只要检索到包含正确答案的那一段话就够了但多选题的多个正确选项往往分散在文档不同位置甚至需要跨文档拼接。这正好能考到RAG的“召回覆盖率”而不仅仅是“单点命中”。二是多选题有天然的“部分正确”属性这个特性特别适合暴露生成环节的“带偏”问题。AI可能选对了两个选项漏掉一个又额外加了一个错误选项——这在宽松评分下可能还能拿个不错的分数但严格评分下直接就判错。三是多选题的判分规则非常清晰方便做自动化评测。我给题目设计了两种规则宽松规则AI生成的选项集合与正确答案集合有交集就算对严格规则AI生成的选项集合与正确答案集合完全相等才算对。正是这两套规则把同一个RAG系统测出了95分和85分的差异。2.3 别把“指标差异”当“系统波动”很多人遇到这种情况第一反应是“这套系统不稳定”然后开始反复调参数试图把分数刷回95分。但我的经验是当两种评分规则下的分数差异超过5个百分点时你面对的已经不是一个参数能解决的问题了而是链路中某个环节的系统性失真。宽松评分就像一个开卷考试学生AI只要翻到任意一页写点沾边的答案就能得分而严格评分才更像闭卷阅卷你得完整知道每个选项为什么对、为什么错才能拿满分。如果你只用宽松评分验收就等于默认“AI只要把内容带到就行准不准无所谓”——那RAG也就不叫“检索增强生成”只能叫“检索搬运工”了。那10分的差距我后面一条一条链路排查最终找到四个主要贡献者文档解析丢字、分块把答案切断、检索排序把关键段落挤到后面、生成阶段没管住模型“胡添选项”。下面这部分就是完整的排查记录和分析过程。3. 顺着RAG链路找丢分的真相3.1 根因一文档解析阶段丢信息排查第一步先看文档有没有被原样“读”进来。药企语料里有大量格式化的文本比如PDF里的两栏排版、表格里的“剂量—体重—适应症”对照这些结构在转成纯文本的过程中特别容易出问题。我实测中遇到的一个典型case是一个产品说明里写着“每日最大剂量为8 mg但对于肝功能不全患者最大剂量调整为4 mg”。这条内容在表格里是“一表两行”解析的时候列错位转出来的文本就变成了“每日最大剂量为8 mg或4 mg肝功能不全患者调整为8 mg”。就这么一句话正确答案从“肝功能不全患者4 mg”变成了“8 mg”多选题下来必错。解析阶段的问题之所以要放在第一位排查是因为它是不可逆的。分块做得不好还能调参数重跑检索召回不足还能优化索引但原始文档如果从第一步就丢了信息后面所有的优化都是在废墟上盖楼。实操建议验收之前先抽20个文档做“解析还原度抽检”把原文和解析结果逐段对比。重点关注表格、脚注、分栏排版、公式、药品名称大小写。这一步花半天时间后面能省好几天排查时间。3.2 根因二分块策略切断了上下文分块是整个RAG链路里最容易被低估的环节。一般人用固定长度切分比如每块400字符、50字符重叠跑完发现分数还行就再也不管了。但药企语料恰恰是固定长度切分的重灾区因为很多主题被切断的位置正好是术语密度最高的位置。举个例子当时有个问题问“某药物在重度肝功能不全患者中的推荐剂量是多少”正确答案出自一个2000字的段落那段信息分散在文档三个位置第一个位置是剂量表开头第二个位置是肝损害人群的说明第三个位置是“注意事项”里的附加限制。我在做固定长度分块时这三处信息被切进了三个不同的块检索时哪怕Top-K设置了5也只有两个块被召回来第三个块由于相关性排序不够靠前直接被截断了。于是AI看到的信息是不完整的多选题自然漏选了关键选项。后来我把分块策略改成了“父子分块”parent-child chunking——用小chunk做检索用大chunk父chunk做生成。简单说就是索引阶段用小粒度片段去匹配问题召回后关联回它所属的完整章节让AI在生成时能看到完整的上下文。这个改动单独贡献了约4-5分的严格评分提升。实操建议不要相信“一个固定chunk大小走天下”的教程。先用手头语料跑统计看文档里答案的“有效上下文跨度”中位数是多少把chunk大小调成这个跨度的1.2倍左右重叠部分设置在10%-20%之间既防断裂又不至于太多冗余。3.3 根因三检索阶段“召回了但排不上队”检索阶段的隐性问题是系统不是没检索到正确答案所在的段落而是正确答案被“挤”到了后面生成阶段没让它参与决策。我当时用了一套很常规的方案向量检索Top-K取20再走一个重排序模型reranker取前5作为上下文。问题就出在这个“前5”上面——重排模型把大量“看起来相关但并非直接答案”的段落排到了前面比如“药品说明书概述”“试验数据背景”这些整段都在讲相关药物内容的文本。它们跟问题确实相关但都不直接包含“推荐剂量是多少”这一问题的答案。解决这个问题的思路是不要把重排当成一个黑盒。我把每次重排后的Top-5结果打印出来看一眼才发现很多高相关度的段落其实是“低信息密度”的——它们包含关键词但信息是泛泛的介绍不是精确的数据。后来我在重排阶段加了一个规则如果Top-5里同时有“背景描述”和“具体数据”优先保证具体数据段进入上下文哪怕它排在第7、第8位。这个改动听起来简单实际做起来需要一整套评测集支撑你得能定位到“标准答案对应的原文位置”再回看它是否进入了生成上下文。没有这层对照你连“检索到了还是没检索到”“检索到了但没用上”都分不清。3.4 根因四生成阶段“多选变错选”最后一个丢分点在生成阶段。这部分的功劳完全靠“严格评分”暴露出来——宽松评分下AI选了2个正确选项得满分严格评分下一看它多写了一个距离正确答案“擦边”的干扰项直接按错判处理。我把这些出错样本收集起来后发现了一个规律AI倾向于“补充”而非“删除”。比如正确答案是“A、B、D”AI输出了“A、B、D、E”其中E是一个“在文档里确实出现过但跟这道题无关”的选项。为什么因为检索回来的上下文里包含了E相关的一段内容模型没有能力精确判断“E虽然出现了但跟这个问题没有关系”它倾向于把相关的内容都选进来宁可多选也不漏选。这个问题单靠提示词很难完全解决。我当时试过在prompt里加“仅根据问题选择直接相关的选项不要选择虽然出现但与问题无关的选项”有一定效果但没办法根治。真正帮我稳住生成准确率的是两件事第一把召回上下文里“与问题无关但与上下文相关”的噪声内容删掉让AI尽量只面对“与问题强相关”的内容第二在评测集里专门建了一组“干扰项题”把这种“选项在文档中出现、但与题干问题无关”的场景单独拿出来测用这批题目专门盯生成环节是否具备“排除无关项”的能力。4. RAG验收不只看一个指标我现在的四层评估体系经历过这次“95分到85分”事件之后我把RAG验收方案彻底重做了一遍。现在我验收任何一个RAG项目不会再只盯一个端到端准确率而是拆成四个层次的指标看。这四层指标各有侧重缺一个都容易在某个环节埋雷。4.1 第一层检索层指标测的是“能不能找到”第一层看检索质量。没有好的检索后面的生成再好也无米下锅。常用的指标包括指标含义我常用的目标值RecallK正确答案所在的上下文片段是否被召回到Top-K里初始Top-K20时Recall20应≥90%PrecisionKTop-K里有多少是“有效上下文”而不是噪声Top-20的Precision应≥0.5重排Top-5后Precision应≥0.8有效上下文覆盖率答案涉及的所有段落有多少进入了最终生成上下文目标≥80%低于这个值先别调prompt这一步的关键是你得有一套“题目—标准答案原文位置”的映射标注。没有这套标注检索指标就是空中楼阁。我的做法是每道题在标注答案时同时记录“这道题的正确答案出自哪几个片段、分别在哪个文档里”。这样就能准确地算出来召回到底够不够。4.2 第二层生成准确性指标测的是“能不能答对”第二层回到端到端但不只看一个分数。我现在的做法是按三种题型分别统计准确率单选题看“精准命中率”AI的回答必须与正确答案完全一致多选题看“完全匹配率”选项集合要完全一致同时单独统计“漏选率”和“错选率”分别反映生成阶段的健忘问题和幻觉问题简答题/填空题看关键词覆盖率提前把得分点标成关键词AI回答里必须包含全部关键词才给分。这一层就是我前面提到的“严格评分”真正发挥作用的层级。如果你只关心“它有没有答对”那宽松评分就够了但如果你关心“它能不能稳定地只答对不加戏”严格评分是唯一能给你真相的规则。4.3 第三层人工抽审测的是“机器分数靠不靠谱”第三层是我后来新增的也是我认为最关键的一层——人工抽审。再自动化、再精准的评测指标也只能反映“你出过的题”上的表现。但真实使用场景里的问题一定比评测集更刁钻。我现在的做法是每轮验收前从评测集里随机抽50道题让一个不参与系统搭建的人最好是实际的业务使用者来做盲评——只给问题和AI回答不给正确答案按“可接受/不可接受”两档打分。这50个样本的“不可接受率”超过10%即便机器分数再高我都不会同意上线。这个动作看起来很笨但它能弥补所有自动指标的死角。比如AI回答了一段话从关键词覆盖率看是满分但业务同事一看“这个说法在临床语境里是错的指标方向搞反了”——这种错误任何关键词匹配算法都发现不了。4.4 第四层业务可用性指标测的是“实际用不用得起来”第四层是我认为从“技术验收”跨到“业务验收”的分界线。RAG系统光在评测集上答对还不够还得回答一个问题真实用户拿它去干活能用得起来吗我从药企场景里总结了这个层面的几个“灵魂指标”首次回答可用率用户提问后不修改、不追问、不澄清直接采用AI回答作为参考的比例。这个比例低于50%说明系统的回答质量参差不齐用户用起来会很累追问成功率用户第一轮回答不满意继续追问“为什么”“依据是什么”“有没有例外情况”系统能否准确追踪上文并提供补充信息。这部分最能反映RAG系统对多轮上下文和语料深度的理解能力引用完整率回答里的关键结论有没有对应的文档出处出处是否能被追溯到。药企场景里引用缺失几乎等于不可用。业务层指标不追求百分之百但它们的趋势更重要。我习惯在验收期内把同一批业务指标连续测两周观察是稳定持平、忽高忽低还是逐步上升。一个RAG系统如果业务可用率忽高忽低背后大概率有检索排序不稳的问题这种系统即使评测分数再高上线后也会被用户骂。5. 用搜索热词反观知识图谱和结构化知识库能解决什么排查过程中我也在想一个问题如果当时接入的是一套结构化的知识图谱那10分差距会不会不存在这个话题近期热度很高我就结合这个项目的体会说几句。5.1 知识图谱和RAG的定位差异RAG和知识图谱不是替代关系它们在这个项目里解决的问题其实完全不同维度RAG向量知识库知识图谱KG擅长场景开放域问答、语义匹配、长文本理解结构化关系查询、多跳推理、实体关系分析信息表达以自然语言段落为载体语义丰富但结构松散以实体和关系为骨架精准但对自然语言表达要求高维护成本相对简单文档入库即可没有复杂建模过程需要建模、实体识别、关系抽取维护成本高典型问题“某某药的适应症是什么”答得全、答得准“哪些药物同时作用于A和B两个靶点”适合多跳推理药企语料里的问题大部分其实是“语义密集的开放域问题”比如“某药物的推荐剂量”“在肾功能不全患者中的注意事项”这类问题用RAG天然合适因为答案就是一段文本RAG能直接把它捞出来。而“某药物与另一药物是否有相互作用机制是什么”如果知识图谱里正好建模了药物相互作用关系它用一条边就能回答RAG反而需要跨好几段文档拼接。5.2 什么时候必须考虑“图谱向量”混合方案现在业内讨论比较多的是RAG与KG的混合方案不是非此即彼。我的项目虽然最后还是以向量RAG为主的方案上线但后续在扩展“药物相互作用查询”这类需求时我已经在规划引入一个轻量级的关系层。混合方案怎么落地我建议按问题类型分流实体级查询“xx药物的不良反应有哪些”→ 走向量RAG靠语义召回文本段落关系级查询“xx药物和xx药物联用有什么禁忌”→ 走知识图谱查询用结构化的三元组回答综合查询“比较两种药物的适应症差异并给出注意事项”→ 先图谱精准定位关键实体和关系再RAG补全上下文两轮结果拼成最终答案。这种混合方案在落地时的核心难点不在于技术框架在于“领域实体和关系的梳理”。药企场景里的实体不只有“药物”“适应证”“不良反应”还有“临床试验阶段”“药物警戒信号”“医保报销限制”这些专业关系。建模的颗粒度怎么定直接决定图谱有没有用。这也是为什么在药企知识库项目里图谱方案总是听起来美好、做起来工作量大的主要原因。6. 常见问题与排错实录最后一part分享几个我实测过程中反复遇到、也最容易被忽略的问题。这些坑不解决你的RAG验收就永远只能拿“宽松分”自欺欺人。6.1 相关度分数高但答案就是错的这是RAG开发里最诡异的现象之一。打开检索日志召回片段的相关度打分在0.9以上看着非常漂亮但AI给出的答案完全偏了。我排查下来遇到最多的情况有两种。一是片段与问题“语义相关”但“信息不直接”。比如问“禁用于哪些患者”召回了大段描述“药物作用机制”的内容文本里的词或多或小跟问题沾边但通篇没有写禁用人群。向量检索模型擅长的是“语义相近”它无法区分“话题相关”和“信息直接”。这种情况靠重排器也很难解决最好在你对检索结果看的足够多之后在重排阶段加规则约束。二是片段本身有信息但被解析过程搞丢了格式。表格转文本丢列、脚注里的信息体丢失、数字后面的单位变成了乱码。这些都是我在药企语料里亲眼见到的。建议遇到“相关度很高但答案为错”的样本时第一件事不是调检索参数而是打开原始文档看一眼模型实际看到的文本到底长什么样。6.2 多选漏选模型“丢”了一个正确选项为什么会漏不是模型不会而是上下文里压根没有这个选项对应的内容。我在排查漏选问题时发现了一个非常典型的模式正确选项分散在多个段落中其中一段在Top-K召回里出现了但重排后排在后面的位置被截断了。模型只看到了前面的信息自然就漏选了。后来加了“父子分块”之后这个现象大幅减少。还有一种漏选原因选项内容在语料里是“反着”写的。比如题目问“以下哪项不是该药物的适应证”AI看到的是正面写出的适应症清单要它从里面挑出“不属于”的项它的推理能力就跟不上了。这种情况不是RAG的问题而是题目类型本身对模型推理能力要求高。我的处理办法是在评测集里给这类“否定式问题”单独打标记并严格控制比例不要把它们的分数混进主评测集里。6.3 术语漂移模型“自以为是”地改写药企语料评测中我见过频率最高的一类生成错误就是“术语漂移”——AI回答的意思没错但它把一个关键术语改写成了另一个说法。比如原文写“肝功能Child-Pugh B级患者”AI生成了“中度肝功能不全患者”。从自然语言角度看这算“大致正确”但在严谨的药学语境里指南里明确写了“Child-Pugh B级”的用药建议不能直接套用“中度肝功能不全”的定义。宽松评分不关心这个关键词覆盖评分因为词对不上也不给分事实上两种指标都没能准确描述“错得有多严重”。这类问题的答案不在评测规则里而是在语料治理里。我现在要求药企语料入库时对专业术语做一次同义词归一化给“Child-Pugh B级”“中度肝功能不全”“中重度肝功能损害”这类表达建立统一的实体别名表检索时做同义扩展生成时强制模型优先采用原文术语。这个改动在严格评分下又贡献了2-3分。6.4 换一批新语料分数掉得飞快这种问题最让人头疼评测集上稳定在90分以上一换新一批文档分数立刻掉到75分甚至更低。本质上不是“系统变弱了”而是你的评测集没有覆盖语料分布的全貌。药企的知识库是持续更新的新增的治疗指南、刚获批的适应症、旧版条款的修订这些都会引入新的表达方式和结构。我建议把RAG验收拆成“存量语料回归”和“新增语料专项”两类存量语料回归用固定的评测集每周跑一遍看分数是否稳定防止某次新文档入库把旧文档的表现挤掉了新增语料专项每次有新语料入库单独从新语料里生成一批临时题目跑专项评测确认新语料没有系统性拉低检索质量。这也是RAG项目长期维护里最容易忽略的一块——它是运维工作不是开发工作。7. 一个值得参考的验收自查清单如果你也计划做一个RAG知识库项目或者正在验收一个已经开发到一半的系统我给你一个可以直接拿来用的自查清单。它按验收顺序排列每一条背后都是我这轮实测踩出来的坑第一检查文档解析还原度。抽20个文档重点看表格、脚注、分栏、剂量单位确认原始信息没有被破坏第二检查“题目—答案原文位置”映射是否完整。没有这个映射你无法区分“没检索到”和“检索到但没用上”第三分宽松评分和严格评分两套规则分别跑分比较差距。两套分数差异在5个百分点以内属于正常超过5个百分点说明链路里有系统性失真不要在参数层面反复磨蹭第四检索层指标RecallK和PrecisionK与生成层指标分开看。生成差时候找生成的问题检索差时候找索引和分块的问题不要混在一起猜第五人工抽审不可跳过。自动指标只能保证“你出过的题”的表现人工抽审才能代表真实用户接触到的内容质量第六留出一周做业务可用率观察。RAG能不能上线最终不取决于评测分数而取决于真实使用者愿不愿意持续用。我个人的体会是RAG验收本质上不是在验收“模型聪明不聪明”而是在验收“你的知识库基建是否扛得住真实检索压力”。95分和85分之间隔着的不是打分宽严的小事而是你对自己系统有多了解的大事。如果只看一个指标就决定上线总有一天会被真实的业务场景教训。