做药企RAG检索增强生成知识库验收的人应该都有过这种时刻拿着精心标注的多选题集跑一遍宽松评分95分领导很高兴换一套严格评分标准分掉到85开始怀疑系统是不是不行。我和团队在真实药企语料上就踩过这一脚。今天不聊模型参数不聊框架选型就聊RAG验收里最容易被忽略的一件事——评分口径。你看到的分数可能不是系统的真实水平。多选95分和严格85分之间藏着的才是RAG系统真正要交付的能力。1. 一场验收风波从95分到85分的背后1.1 这个多选评测集是怎么设计的先说背景。我们手里是一套药企内部知识库语料来源主要是药品说明书、临床用药指南、内部SOP、不良反应报告模板这类文档。评测集有50道题全部是单选题和多选题金标准由一位有临床背景的同事逐题核对过。多选题大概占30道覆盖适应症、禁忌、药物相互作用、不良反应处理等典型查询场景。最初的评测脚本是“宽松匹配”把模型输出里的选项字母和内容抽取出来跟标准答案做集合交集只要模型输出的选项能覆盖标准答案的80%以上同时没有出现严重错误就算对。这套口径跑下来LLMRAG的整体正确率95%表现很漂亮。但业务同事提了一个要求能不能用更严格的方式再验一遍——必须是全对才算对少选一个、多选一个、选错一个统统不得分。换口径之后分数掉到85。第一次看到这个数我第一反应是“评测脚本写错了”。后来逐条核对错题才发现这10分的差距不是bug而是此前被宽松评分掩盖的真实问题。1.2 宽松评分和严格评分到底差在哪宽松评分本质上是“部分正确即认可”。它很像考试中的按点给分只要考生答对了大部分关键点就给相应的分。RAG场景里最常见的宽松做法包括计算模型输出与标准答案的语义相似度超过阈值就算过检查模型输出的关键词、选项字母是否覆盖标准答案中的大多数元素用向量embedding的余弦相似度替代人工判断允许模型输出中包含少量错误信息只要主要答案正确就不扣分。严格评分则是“全对才算对”的二元判断。多选题必须完全等于标准答案集合多选、漏选、错选均为0分。这种评分背后的逻辑在药企场景尤其合理一份用药建议多写了一个禁忌情形或者少了一个相互作用提示系统层面可能是“小瑕疵”但落到真实场景就是不可接受的误导。举个例子。金标准答案是A、B、C模型输出A、B、C宽松和严格都给满分。模型输出A、B宽松可能给80分严格直接0分。模型输出A、B、C、D宽松可能因为覆盖了正确选项给90分严格还是0分。宽松指标把“答得不全”和“答得全但多选”都包装成了“还行”严格指标把这些全部打回原型。评分方式判定逻辑金标准A/B/C时模型输出A/B金标准A/B/C时模型输出A/B/C/D宽松评分覆盖大部分正确要点允许少量缺失或多余80分90分严格评分与标准答案集合完全一致0分0分1.3 这10分为什么值得紧张如果换到单选题场景这10分的差距大概率不是大问题。单选题答案空间小模型通常不会多做无用功宽松和严格的口径结果相差不大。多选题不一样正确答案的组合空间是指数级增长的稍有检索遗漏或生成偏差就可能从“全对”掉到“不全对”。药企语料又极其容易出现这种偏差。说明书里“禁忌”往往列成多条RAG检索时可能只拿到了其中两条模型自然只输出两条。再加上同义表述多标准答案写“严重肝损伤”文档里写“肝功能严重不全”关键词匹配口径能放过严格人工审核就未必了。所以我后来跟同事说95分不是假分数它代表的是“在宽容的验收标准下系统可用”85分也不是坏分数它代表的是“在严格的业务口径下系统还有明确短板”。验收RAG最怕的就是只盯一个分数然后基于这个分数做上不上线的决策。2. RAG评估不能只看“答对没有”2.1 拆开RAG这条链路检索、生成、忠实RAG系统的核心链路是“检索一段文本让LLM基于这段文本生成答案”。任何一个环节出问题最终答案都可能不对。只对着最终答案打分相当于只看了汽车的仪表盘不检查发动机和轮胎——反正车速上不去但不知道为什么上不去。所以我把RAG验收拆成三层来看。第一层是检索层。指标包括召回率RecallK、命中率、重排序效果等。药企场景里检索层最常见的问题是文档切得不合理导致正确答案被拆碎召回不完整或者语义检索被同义术语干扰比如“药品不良反应”和“ADR”匹配不到一起。第二层是生成层。指标包括答案准确率、完整性、格式规范性、是否严格遵循了“只输出选项编号”这类约束。生成层的问题通常来自prompt约束不够或者模型对长上下文的注意力分配不均匀。第三层是忠实度。忠实度指生成的答案是否严格基于检索到的上下文有没有编造上下文里不存在的信息。RAG评测里常说的faithfulness指标就是干这个的。药企场景对忠实度的要求极高因为药物相互作用、禁忌症这些内容一旦被模型自由发挥后果很严重。刚才说的95分和85分其实都是在“生成层”打分。但如果检索层已经漏了生成层再怎么努力也白搭。所以后面我们每次验收都会同时记录“检索到的上下文是否包含金标准答案”这个前置指标。2.2 药企场景要多看的几个关键指标只回答“对了没有”不足以支撑药企场景的验收结论我建议至少看以下四类指标。指标名称看什么药企场景关注点检索召回率RecallK正确答案所需的信息是否在前K个检索结果里多选漏选大概率是召回不全答案准确率生成答案与金标准是否一致分为宽松和严格两档分别统计忠实度Faithfulness生成内容是否被检索上下文支持防止模型编造药品相互作用、禁忌信息回答相关性生成内容是否真正回答了用户问题防止模型答非所问或开放闲聊这四类指标分开看能快速定位问题在哪一环。比如检索召回率低说明问题在切分或embedding召回率正常但准确率低说明问题在生成层或prompt准确率正常但忠实度低说明模型在“自由发挥”这是最危险的。RAGAS评测框架里的context_precision、context_recall、faithfulness、answer_relevancy本质也是围绕这几层来设计的。但我不建议直接把某个框架的指标默认值当成真理更合理的做法是理解指标含义后根据语料和业务风险自定义评测集。2.3 单指标陷阱是怎么骗过人的宽松评分虚高是单指标陷阱里最常见的一种。我在一次评测中发现模型输出了一堆选项字母比如标准答案是A、B模型输出A、B、C、D。宽松评分因为覆盖了所有正确答案给的是满分。但仔细看检索上下文C和D根本不在上下文里这就是典型的模型幻觉。如果用严格评分这种答案直接0分幻觉立刻暴露。但如果你只看单项宽松分数还会觉得模型“很稳”。另一种陷阱是“用模型评模型”时的自欺欺人。现在很多自动评测脚本会用LLM当裁判给模型输出打分。LLM裁判本身有偏好往往对内容详尽、格式好看的答案更宽容。药企场景里“详尽”并不等于“正确”。我在验收时会让LLM裁判输出详细的判定理由然后人工抽检理由是否站得住脚。单一指标还有一个问题忽略错误分布。95分和85分都只是平均值。如果错误集中在某个特定主题——比如“不良反应处理”——单看平均分根本发现不了。后面我们会把错误分主题交叉分析这是验收中性价比最高的一步。3. 真实语料里多选题为什么会翻车3.1 药企语料的结构化与非结构化很多知识库项目默认把文档丢进切分器按固定字符数切成chunk再存进向量库。这个做法在通用百科类语料上还行但在药企语料上非常容易出问题。药品说明书里大量内容以列表形式存在适应症可能是一句话禁忌项却是好几条并列不良反应可能分成“常见”“少见”“罕见”多段药物相互作用往往是一张表。直接把这类文本按500字硬切很容易把一条完整的禁忌列表从中间切断。检索时若只命中了后半段模型看到的信息就不全多选题自然漏选。我当时在处理一份化疗辅助用药的说明书时就遇到过“严重不良事件”列表被切到两个chunk里的情况。检索召回Top5里只能找到其中一部分答案必然不完整。更好的做法是先识别文档结构标题、段落、表格、列表项分别处理。列表项尽量不要切断表格可以按行为单位转成文本。这个预处理工作当时占了项目一半时间但它是多选题正确率的基础。3.2 标准答案在文档里可能分散在多处药企知识库的另一个特点是答案信息经常跨文档存在。比如一道题问“哪些患者禁用该药”说明书里可能列了三点指南的补充说明里又写了两种特殊情况。RAG要把这些分散信息都找出来并在生成时合并成完整答案。这时候如果只用向量检索很容易只召回其中一段。因为embedding相似度通常会优先返回与问题字面最接近的内容而不会自动帮你做跨文档的信息聚合。我试过在纯向量检索下召回率只有70%出头。后来改成“BM25关键词检索向量检索”双通道再补充一个重排模型把两路结果混合排序召回完整答案的概率才显著提升。多选场景尤其考验这种“信息合并能力”。模型必须把所有相关片段都放进上下文才有机会输出完整选项。如果上下文窗口本来就只有一部分答案那不管prompt怎么写都不可能全对。严格评分表面在惩罚生成层根源往往在检索层。3.3 缺选、多选、错选错误模式要分类看把85分的问题逐一分析之后我总结了几个典型错误模式。后续只要一看到这些形态就能快速定位原因。错误模式表现常见原因典型案例缺选标准答案有3项模型只输出2项检索召回不完整信息没有被合并禁忌列表被切分只召回一部分多选标准答案2项模型输出3项以上模型过度生成把相关但不正确的项也列进来相互作用里把“可能影响”当成“禁忌”错选选出的选项与标准答案不一致同义术语被模型误解或知识混淆把“轻度肝功能不全慎用”理解为“禁用”格式错误模型输出解释性文字没有给出清晰选项prompt约束不足输出解析失败输出整段文字选项字母混在句子里缺选通常指向检索层多选通常是生成层对相关性判断不严错选可能是语义理解和prompt问题格式错误则纯粹是后处理代码不健壮。分开记录后调优才有的放矢。4. 实操从评测集到调优的完整闭环4.1 构建一套能“暴露问题”的评测集有价值的评测集不是把文档里的句子改个问法就完事那样做极容易造成数据泄漏——模型答案直接来自文档原句测不出真正的泛化能力。我的做法是三步。第一步梳理真实用户问题。把业务同事日常会问的高频问题收集起来比如“这个药和降压药能一起吃吗”“肾功能不全患者需要注意什么”。这些问题往往是口语化的和文档里的书面表述不完全一致能真实暴露RAG系统的检索能力。第二步做成“改写题”而不是“原句题”。同一知识点换成不同问法看模型是否还能答对。比如文档里写“服药期间避免饮用葡萄柚汁”题目可以改成“患者喝了一杯西柚汁是否需要担心”。考察的是语义理解不是字面复制粘贴。第三步优先级排序。多选、禁忌、相互作用、特殊人群用药这些高风险内容的题目数量要尽量多一些无关痛痒的事实题可以少放。这样平均分才不会被易答问题抬高。评测集规模不是越大越好。我当时第一版60道题人工标注金标准用了一天多。关键是覆盖度和难度分布合理而不是盲目追求题量。4.2 评测脚本宽松、严格双轨并行我不建议一上来就只跑严格评分那样会打击信心且不好定位问题。更实际的做法是双轨并行每个问题同时计算宽松分和严格分分开记录再对比差异。宽松评分我用的是集合覆盖逻辑计算模型输出的选项集合与标准答案集合的交集大小用F1值或Jaccard相似度作为分数。严格评分直接用两个集合是否完全相等。具体实现时要注意模型输出往往不是干净的“A、B、C”需要先写解析函数把选项字母和对应内容提取出来。解析错误会被算成格式错误这也是一个独立的问题维度。打分细节上我强烈建议同时输出一篇“评测明细表”。每一行包括题目、标准答案、模型输出、检索到的Top5上下文、宽松分、严格分、错误类型、人工备注。这样不只是看一个数字而是能针对每一题分析“为什么错了”。我试过用LangChain或者RAGAS框架跑整体评测但框架给的总分实在不好用。更好的是自己写一套几十行的评测循环把中间结果全部落盘然后用表格工具逐行看。这比任何花哨的评测报告都有用。4.3 从错误分析到RAG参数调优当严格评分稳定在85分时我开始盯错误明细把错误归因后又做了一轮参数调优。主要动了五个地方。第一个是文档切分。固定500字切分的方案被改成按段落和表格语义切分尽量保证一条完整语义单元不被拆散。切分后的chunk长度从300到800字不等。第二个是检索策略。从纯向量检索改成“BM25向量双路召回”TopK从5改成10再添加一个重排模型把最相关的结果放到最前面。第三个是prompt约束。在系统提示里明确写“只根据上下文内容回答”“多选题如果上下文未提及不要自行补充”“输出格式严格为选项字母不要添加解释”。这一改动直接减少了多选和错选问题。第四个是后处理解析。增加了一个容错函数能从“答案A C D”这类不规整输出里提取选项字母避免格式问题干扰评分。第五个是少量示例。在prompt里放一两个“上下文多选正确输出”的示例模型模仿格式的能力明显提升。做完这一轮再跑严格评分分数从85分涨到90分以上而宽松评分从95只微涨到96分。如果不是双轨并行我根本看不出严格口径下提升了多少。调优项调整前调整后严格分变化文档切分固定500字语义段落切分3分左右检索策略纯向量TopK5BM25向量双路召回重排TopK102分左右Prompt约束无明确格式要求明确只输出选项字母1分左右后处理解析简单正则容错提取选项字母消除格式失分少样本示例无加2个多选示例1分左右4.4 调优后的再验证不能省调优完成后不要急着报喜。我建议再用另外一组评测题做交叉验证防止模型过拟合当前评测集。因为prompt和切分参数的调整有一定概率是专门针对评测集特征去优化的。交叉验证时把两道相近但不同表述的题目都放进去比如“禁忌人群”和“慎用人群”区别开考察模型能不能区分“禁用”和“慎用”。这两个词在药企场景里差别极大很多RAG系统在语义上容易混淆。我当时就发现调优后在原始评测集上严格分91分换到交叉验证集只有86分。重新检查发现模型把“慎用”也当成了“禁用”在选择题里多选了。这说明语义边界还不够清晰需要再在prompt里强调“慎用不等于禁用”的上下文含义。这种问题是单靠总体分数完全看不出来的。5. 避坑清单与验收经验速查5.1 常见问题与排查思路做RAG验收这段时间我把踩过的坑整理成一张速查表。只要测评结果不对劲先对着表排查。现象可能原因处理方式宽松分很高严格分很低评分口径太松掩盖缺选/多选双轨评分对比差异分析错误模式检索上下文里根本没有标准答案chunk切分不合理或召回策略不足检查切分结果加BM25提高TopK模型输出“可能”“大概”等模糊词上下文信息不足或prompt未强制增加检索召回prompt中要求明确作答同一问题换一种问法就答错语义泛化不足评测集太单一改写题交叉验证扩充评测集模型答案看起来很完整但实际是编的忠实度不足模型自由发挥增加忠实度评估强制只根据上下文作答格式解析经常失败模型输出不规整后处理脆弱强化prompt格式约束写容错解析函数分数很高但不代表业务可用评测题太容易错误集中在高风险主题增加高风险主题的题量分主题看错误分布5.2 验收报告怎么写才能让业务信服一个只写“准确率95%”的验收报告对业务决策几乎没用。现在我的报告固定包含几个部分宽口径和严口径的成绩对比、检索召回统计、忠实度抽检结果、典型错误案例、风险清单。典型错误案例我通常附上原文截图或模型输出的复制文本旁边标注“标准答案是什么”“模型答错在哪里”“可能造成什么影响”。比如“模型漏选了‘肝功能严重不全患者禁用’这个禁忌项如果真实场景下据此推荐用药存在安全风险”。这种描述比任何指标都更能让业务方理解为什么要继续调优。风险清单里会区分“已解决”和“仍存在”。已解决的问题是这轮改了什么参数、提升了多少分仍存在的问题是哪些场景还没有覆盖、哪些错误类型未完全消除。报告的价值不在于判决“能不能上线”而在于让所有人知道“在什么条件下可以使用”。5.3 我踩过的坑和最后的小建议最后说几个印象深刻的坑。第一个是用单选题评测集验收多选能力。最初评测集里单选和多选混在一起但单选占多数平均分被拉高多选的严重问题被稀释了。后来拆开统计才发现多选严格分比单选低了接近20个百分点。第二个坑是直接照搬开源教材里的RAG默认参数。药企说明书和问答对的字段结构完全不同默认切分器根本不懂表格和列表。必须结合语料做定制化预处理这一步没有捷径。第三个坑是只调prompt不调检索。一开始我以为是模型不会“选”花了很多时间调prompt严格分始终上不去。后来看了检索上下文才发现模型根本没拿到完整候选信息。prompt再怎么写也没用。所以排查顺序一定是先看检索再看生成最后看评分。我的体会是在药企这种高容错率低场景里宁可严格评分85分也不要宽松评分95分。宽松高分容易让团队飘严格低分反而会逼着大家去解决真正的问题。RAG验收本质上不是给系统贴一个“好”或“坏”的标签而是把系统在具体业务约束下的短板暴露出来再用一轮轮评测推动它变好。如果有一天你也在验收RAG建议先把“宽松95分、严格85分”这种落差当成线索顺着它往下挖你会比只看一个数字的人看到更多。