ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

RAG系统验收实录:宽松评分95与严格评分85背后的可靠性博弈

RAG系统验收实录:宽松评分95与严格评分85背后的可靠性博弈 1. 实测结果宽松评分95分严格评分85分1.1 测试集是怎么搭出来的帮一家制药企业做RAG知识库验收是我最近最有感触的一个项目。客户内部已经积累了一套相当完整的产品知识体系包括药品说明书、注册批件、培训材料、一线客服问答记录甚至还有一部分老旧的PDF扫描件。我们要做的事情很朴素把这些散落的资料整理成一个能让业务人员快速查询的问答系统也就是目前最常见的检索增强生成RAG架构。项目前期的技术链路搭建其实不算难embedding模型、向量库、rerank、prompt模板都很快跑通了真正麻烦的恰恰是“验收”这两个字——怎么向客户证明这个系统的回答是可靠的而不是碰巧像那么回事。我们建了一套300道题的评估集。题目不是研发拍脑袋编出来的而是让药企的医学信息专员、客服负责人、注册事务同事各自从真实咨询记录里挑问题。整理之后其中120道是多选题180道是问答题按业务场景又可以分成用药相关信息、常规产品知识、内部流程和政策三类。这样设计的初衷很明确既要测选择题式的精确匹配也要测开放式问题的归纳能力既要有高风险的安全类问题也要有低风险的流程类问题。第一轮评估的时候我们用的是比较常见的宽松规则多选题只要模型给出的选项里包含标准答案中任意一个正确选项并且没有明显错误表述就判对问答题只要关键词基本覆盖、语义方向正确也判对。跑下来综合正确率是95分其中多选题部分也是95分问答部分94分。我一度觉得这个项目差不多可以收尾了。但客户那边的医学顾问和法务不认可这个分数。他们的理由很直接药企场景里“包含部分正确”不等于“安全可用”。一个答案即使写了85%的正确信息剩下15%如果被业务人员直接采纳也可能引发后续风险。于是我们重新定了一套严格口径多选题必须是选项集合与标准答案完全一致才得分多选、漏选、错选一律不得分问答题要求所有关键点完整命中、不允许出现与标准答案冲突或扩大的表述、必须给出正确的引用来源。换成这套规则重跑一遍综合得分直接掉到85分。单看多选题的话更难看直接掉到81分。1.2 两种评分的判定规则到底差在哪为了讲清楚这10分差在哪里我们把两套规则整理成了对照规则宽松口径严格口径多选题计分包含标准答案任意正确选项且无重大错误选项集合与标准答案完全一致多选漏选错选均不得分问答题计分关键概念出现方向正确所有关键点完整、表述无扩大或冲突引用溯源不强制要求必须指出原文片段且引用必须正确支撑结论对“不确定”表述不扣分视为未达标准不得分这张表后面藏着真实的语义判断差异。举一个我们实际遇到的多选题例子题干问某药品的禁忌人群标准答案是“孕妇、哺乳期女性、儿童、肝肾功能严重不全者”四个选项。模型给出的选项漏掉了“儿童”但把其他三个都选对了。宽松口径下因为“包含了正确的三个”得分严格口径下漏选一个就是不得分。还有一类更隐蔽的情况模型选了一个“范围扩大”的选项比如把“部分肝病患者”表述成“所有肝病患者”。在宽松规则下关键词“肝病”命中给分严格规则下这是典型的知识性错误必须判错。1.3 95分和85分分别代表什么能力95分和85分的差距本质上是“这个问题看起来回答得对不对”和“这个问题真正能不能直接用于业务”之间的差距。宽松评分衡量的是RAG系统的“相关性”严格评分衡量的是“可靠性”和“安全性”。当一个答案包含正确信息但不完整时宽松口径会奖励它严格口径会惩罚它。药企业务对这种差异极度敏感因为文档里的一句话可能直接影响一线人员的判断。我后来跟团队复盘时打了个比方宽松评分像是让阅卷老师确认“考生没有交白卷写的内容沾边”严格评分像是让审稿人确认“每一条结论都有出处且没有过度宣称”。RAG系统在demo阶段很容易达到前者但真正要投入业务使用后者才是硬门槛。这也是为什么我强烈建议任何RAG项目验收都不要只看一种指标尤其不要只看一个“综合准确率”。那个数字太光滑了光滑到可能掩盖系统最致命的短板。2. 药企真实语料为什么比通用测试集更考验RAG2.1 文档结构里的坑分块把表格和条款切碎了做药企语料RAG最容易踩的第一个坑就是文档分块。药企的原始语料和网上随便抓取的通用网页不一样里面大量内容是结构化程度极高的表格、条目、多级条款。比如药品说明书里的“不良反应”通常是按发生率分层排列的列表“用法用量”经常是一个完整表格包含不同剂型、不同年龄段的差异。如果按固定字符数硬切比如512个token一刀切一张表格会被拦腰砍成两段后面的检索召回时可能只拿到半张表模型基于这半张表生成答案自然会漏掉后半部分信息。我们后来把分块策略调整成“结构优先”先用规则识别文档里的标题、表格边界和列表层级尽量让每个chunk对齐一个完整的语义块表格行只要不跨页就整块保留对于特别长的表格单独做“表格chunk”不和其他正文混在一起。这个改动看起来只是工程细节但对问答题的召回率影响非常明显。严格评分下原来的错误里有一类典型表现是“结论对了但漏了限定条件”比如回答“每日三次”却没说“仅限成人”这就是表格被切掉一列造成的。2.2 事实型查询别硬塞给RAGRAG和KG的分工还有一个容易被忽略的问题不是所有问题都适合用RAG回答。药企业务里大量问题属于“事实查询”例如某个药品的批准文号是什么、某药是否在医保目录里、某个规格的包装数量是多少。这类问题本质上是查一条结构化记录而不是从文本里归纳一段话。RAG从文档里检索再生成反而会引入不必要的“自由发挥”空间。与之相对知识图谱或结构化接口能给出精确字段答案稳定且可溯源。我们在验收时特意把测试集按问题类型拆成了两类一类是文本归纳题比如“说明书里列了哪些不良反应”适合RAG另一类是事实查询题比如“某药最新的注册批件号是什么”。最终我们是通过外挂一个知识图谱接口来回答事实查询RAG只负责把图谱返回的结果包装成自然语言。这样混合架构上线以后严格评分里事实类题目的得分几乎拉满整体分数才真正有了提升空间。如果一开始就强行把所有问题都塞给一个纯向量库RAG95到85的落差可能还会更大。很多团队在规划RAG项目时会默认“把文档扔进向量库就完事了”但药企这类强结构化领域RAG和知识库本身的边界必须先划清楚。2.3 评测题目来源业务人员出题和研发出题是两回事评测集的质量直接决定“95分”和“85分”哪一个更接近真实水平。我发现如果题目由研发人员自己构造很容易无意识地避开模型的弱点。研发会下意识选择那些“在文档里能直接找到、没有歧义”的句子当标准答案这样评测出来的分数自然偏高。而一线业务人员出题时脑子里想的全是真实用户会怎么问随口就是“这个药和那个药能不能一起吃”“感冒了还能不能打这个针”这些口语化、跨文档组合的问题恰恰是RAG最容易失分的。所以RAG评估集一定要由业务方主导出题研发只负责去重、规范格式、补充标准答案。像这次300道题的集子就是从药企各部门真实咨询记录里抽出来的里面不乏相似药品的干扰项。评测得分也因此变得更“难看”但也更可信。如果测试集本身是“温室花朵”那么95分根本说明不了问题反而会放纵系统带病上线。3. 多选题为什么是严格评分下的重灾区3.1 选项集合匹配对RAG是硬约束这次实测里最值得单独拿出来说的题型是多选题。宽松口径下多选部分95分严格口径下直接掉到81分跌幅明显大于问答题的94到87。原因在于多选题的计分方式对“完全一致”的要求极度苛刻。宽松口径下“包含任一正确选项就给分”几乎是个人都能拿高分因为模型只要对一个选项就行严格口径下则要求“集合完全一致”漏选算错多选也算错错选更算错。这相当于把评估尺子从“相关性”直接换成了“精确匹配”容错率瞬间归零。模型在做多选题时倾向于“贪多”因为生成式模型在不确定时会倾向多覆盖一些可能选项。这种策略在宽松评分下不会受伤反正选对了就拿分但在严格评分下多选一个错误选项和漏选一个正确选项都是同样的结果——整题零分。于是那些在问答题里可能只算“轻微瑕疵”的问题在多选题里会被放大成“整题错误”。这也是为什么多选题分数降幅最大它不是模型能力断崖式下降而是评分口径放大了容错率的差异。3.2 相似选项和兄弟药品是RAG的无形陷阱药企语料里最防不胜防的干扰来自相似药品和相似适应症。我们测试集里专门设计了一批“同品类产品对比”题效果立竿见影。比如某个多选题目四个候选选项里有两个描述来自同一家企业的兄弟产品说明书文本结构、用词、句式几乎一模一样只有适应症范围不同。模型在检索阶段会同时召回两份说明书如果没有额外的实体对齐逻辑它很可能把两个产品的信息混到同一个答案里。这种错误在宽松评分下非常容易被放过因为错误选项里混着正确关键词但严格评分下多选一个“看着很像”的选项整道题就废了。我们后来在检索阶段加了一步药品名实体过滤先从问题中识别出明确的药品名称只保留包含该名称的chunk参与生成。这一步看似简单却让多选类题目的严格得分一下提升了6个百分点。换句话说RAG在做多选题时很多时候不是“不懂”而是“被相似信息带偏了”必须在链路层面把干扰源先屏蔽掉。3.3 多选题的自动评分怎么定才不容易扯皮多选自动评分的prompt设计比问答题更需要结构化。我们最初给LLM裁判的指令太简单就是一句“请判断模型答案是否正确”结果裁判频繁出现“觉得方向对就给分”的问题。后来改成分三步第一步让裁判先列出模型给出的选项符号第二步列出标准答案选项符号第三步再比较两个集合是否完全相等。只有当集合完全相等时才输出“正确”。这个结构的目的是强迫裁判不再做语义联想只做集合比对。这里还有一个细节值得提醒不同LLM裁判对同一个多选题的判定可能不一致尤其是当选项文字有细微差异时。所以多选评分不要依赖单个模型最好用两条独立的大模型链路分别评分不一致时再让人工介入。药企这种场景里多选题判分口径必须清楚到“选项集合完全相同”这种机械化程度否则95分和85分之间的争论会一直存在。4. 别只盯准确率RAG验收应该看一整张指标表4.1 准确率之外最该关注的是忠实度和引用正确率很多人验收RAG只看一个准确率85分就觉得系统不行95分就觉得系统成了。实际上准确率只是一个汇总结果它掩盖了错误类型。药企场景里我更推荐至少同时跟踪四个指标答案准确率、忠实度Faithfulness、引用正确率、检索召回率。忠实度简单说就是“答案里的每一句话是不是都能在检索到的上下文里找到依据”。RAG最大的风险在于生成模型可能基于检索片段进行“合理发挥”加一句原文里根本没有的细节。如果只按答案与标准答案比对这种发挥有时会撞对有时会撞错但忠实度能直接把它标出来。引用正确率则专门看模型给出的引用来源是不是真的能支撑那句话。我们在严格评分阶段遇到过这种情况模型答对了结论但引用了一份同一药品另一版本的说明书结论碰巧一致严格规则下引用错误仍然判错这是对的因为下游业务人员需要靠引用去复核。4.2 单一指标为什么会骗人只看一个合计准确率还会掩盖另一种极端系统可能用“回避式回答”刷高分数。比如模型检测到检索结果置信度不高时干脆回答“文档中未找到相关信息”在大多数语义近似评分里这会被判定为“未回答”扣分但如果你用某些“可辩护拒绝”策略打分这种回答反而会拿到忠实度满分因为每个字都有依据。单一指标无法区分“答非所问但依据充分”和“答得非常完整但引用错了”。这就是为什么必须把指标表拉出来一起看。我们用一个比较简单的多指标汇总方法每个测试题目记录五个字段分别是严格正确性、宽松正确性、忠实度评分、引用来源ID、检索是否命中正确文档。最后统计时按题分桶先看“检索是否命中正确文档”再看“忠实度是否达标”最后才是“答案是否准确”。这个顺序其实就是RAG全链路的排查顺序检索都没召回正确文档生成再漂亮也没用召回对了但生成不忠实就得调生成策略都达标了仍然答错才需要考虑是不是模型知识冲突或评分规则本身有歧义。4.3 阈值指标别统一用一把尺子网上很多RAG教程会建议一个统一的相似度阈值比如向量检索分数低于0.7就不返回结果。实际上在药企项目里阈值必须按场景风险和文档置信度来设。我们当时把问题分成了三档安全性问题比如禁忌、不良反应、禁忌人群相似度阈值必须拉高检索不到高分片段时直接拒绝回答而不是给一个模糊答案常规产品知识比如剂型、储存条件阈值适中内部流程类问题比如培训、报销流程阈值可以更低一些。评估的及格线也完全不一样。核心安全类题目要求在严格口径下接近满分常规产品信息可以接受90%流程类问题85%就算过关。分数不是越高越好关键看它对应什么风险等级。5. 85分背后的错误长什么样一次bad-case复盘5.1 错误归类四类问题的分布严格评分的85分意味着15%的题目错了这个比例并不低。我们把这些错题全部捞出来按链路节点分成了四类检索环节没召回到正确文档、上下文分块导致信息残缺、生成环节出现与原文不一致的“幻觉”、以及评分规则本身存在歧义。从数量上看信息残缺和生成幻觉占了大多数。信息残缺的典型表现是模型把检索到的半张表格当成完整信息漏掉尾行生成幻觉的典型表现是模型为了把句子补完整自己“脑补”了一个发生率或措辞。这两类问题在宽松评分下都可能被放过因为“主关键词都出现了”在严格评分下就会原形毕露。我们的错题分布大概是信息残缺38%生成幻觉30%检索未被正确召回17%评分歧义15%。这个占比提醒我们RAG的优化不能只盯model层也不能只盯检索层而是要先通过bad-case把真正的瓶颈分层出来。如果一上来就盲目换embedding模型可能只解决了17%的问题另外38%的信息残缺依然存在。5.2 多选干扰项看着对其实错我再详细拆一个典型案例。测试集里有一题给四个候选选项标准答案是A和D。模型给出的答案是A、C、D。为什么模型选了C因为C描述的内容确实出现在检索到的文档片段里但它属于“其他药品的适应症”。模型把相似文档里的句子张冠李戴到目标药品上。宽松评分下因为A和D都选中了这道题判对。严格评分下多选了C整题不得分。这种错误是RAG在“相似语料”场景下最典型的翻车点。药企的产品线有不少相似适应症、相似成分的药品说明书模板也高度相近向量检索很容易把两份说明书的片段同时召回。如果生成阶段没有指定“必须依据主问题锁定的药品ID来过滤候选chunk”模型就可能把兄弟产品的信息拼进答案。后来我们在检索阶段加入了一个药品名实体对齐过滤步骤先用规则识别问题中的药品名只保留包含该药品名的chunk再进入生成。这个改动让多选类题目的严格得分直接提升了6个百分点。5.3 从错误反推系统瓶颈用trace日志定位环节做bad-case复盘最忌讳的就是只看答案对不对不看链路中间发生了什么。我们在每次评估时都会记录完整的trace最终答案、模型实际读取的chunk列表、每个chunk的相似度得分、生成时的完整prompt。每个严格判错的题目我都会先把trace调出来确认三件事检索结果里有没有正确答案对应的chunk有的话它排在第几位生成时模型到底参考了哪几个chunk如果参考的是错误chunk是检索排错还是之后rerank没把相关文档排上去这样一层层往下问85分的错题才能变成真正有用的改进素材。比如我们通过trace发现有将近一半的“引用错误”问题其实是检索时把“药品说明书中老年人群用法”和“儿童人群用法”两个chunk同时召回了模型选了后者作为主要依据。这表面上是生成问题实际上是检索排序的缺陷。后来我们给关键字段增加了rerank权重对问题中的“老年人”与chunk中的“老年患者”这类同义表达做二次打分引用错误明显减少。这种定位方式比拿到一堆分数后盲目调参要高效得多。6. 验收前先定三件事口径、风险分级、人工抽检6.1 评分口径必须让业务方签字确认这次95到85的“事故”最初的分歧就在于双方对“对”的定义不一致。我们以为“覆盖了主要点”就是正确业务方认为“必须可用于业务审核”才叫正确。这个教训说明RAG验收开始之前评分标准不能只由技术团队内部定而是要拉着医学信息、法务、客服一线坐在一起把“正确”两个字写成可操作的细则并且让业务负责人签字确认。多选怎么算对问答题允许什么程度的措辞调整引用是不是强制要求这些都要落到纸面上。我们后来拟了一份评分细则大概五六页。里面甚至规定了术语写法比如“适应证”和“适应症”哪个是官方用法“禁用”和“不推荐”在什么场景下可以互换。这种细节如果不在验收前确认事后就会变成无穷无尽的扯皮。尤其是RAG这种自动生成式系统同一个问题换个问法答案就会变化如果没有明确口径任何分数都缺乏公信力。6.2 按风险等级分层设分数线而不是一刀切药企RAG不可能所有题目都要求100分因为有一些低风险场景比如“内部报销流程”答对85%已经足够但涉及安全的问题任何一个错误都是不可接受的。我们按问题类型划了三档评测子集安全性问题、产品常规信息、内部流程政策。安全性问题单独跑严格评分必须接近满分才能进下一步产品常规信息允许有少量可修正的瑕疵内部流程政策只要不误导员工就算通过。不同档位对应的测试题数也可以不同安全类多设一些多选和判断题因为这类题型最容易出现“多选一个错误项”的隐患。有条件的话建议把这三档做成三个独立的评测集分别计算分数而不是混在一个“综合准确率”里。只有分档之后你才知道85分到底是因为安全类题目掉链子还是流程类问题拉低了平均值。否则一个“平均85”很容易让研发误以为系统整体还可以实际上高风险部分可能已经不及格了。6.3 LLM裁判也会误判人工抽检不能省自动评分虽然快但LLM裁判本身有偏差。我们这次严格评分的85分里人工复核后发现有两三道题其实是被裁判“误杀”的。比如有一道问答题标准答案没有写引用来源严格规则要求必须引用裁判就判了错但实际上这道题本来就属于“无法引用结构化字段”的事实查询不应该套用同一套引用规则。这种情况在自动评估里很常见。所以建议自动评估之后至少抽10%到20%的样本做人工复核特别是那些“边界模糊”的样本。把人工复核结果再反哺到评分prompt里评估系统本身也在迭代。人工抽检不是走形式。抽检时重点关注两类题一类是严格评分判错的边界题需要确认是系统错还是裁判错另一类是分数变化最大的题目类别比如多选和问答题的分差它们往往藏着系统能力变化的信号。抽检完成后把判例更新到评分标准里下一次评估会稳定很多。7. 沉淀下来的几个实操细节第一多选题的自动评分prompt不要只给一句“判断是否与标准答案一致”要分三步走先让LLM列举模型选的选项再列举标准答案选项最后逐个比较选项集合。这样能减少裁判漏判多选选项的情况。如果想让分数更贴近业务就直接用“集合完全一致”作为得分条件别给“包含”留余地。第二问答题打分层级评分。第一步判断答案里有没有“原文中不存在的陈述”有就直接标记为忠实度不达标第二步逐个核对关键点是否完整第三步再判断引用来源是否可支撑。把这三个分数拆开记录后续调优时能清楚知道是“检索没召回”还是“生成乱发挥”还是“引用对不上”。我推荐把这三步做成一个结构化的评分模板每个题目都输出JSON结构的评分明细。第三测试集一定要版本化。第一次评测完把300道题、标准答案、评分规则、trace日志全部存档。之后每改一次分块策略、调一次prompt、换一次模型都必须跑同一套基线集做回归。否则你无法判断分数提升到底来自哪个改动也可能把已有能力改坏而不自知。我们后来把基线集版本号直接写进CI流程RAG配置变更必须触发回归这一步对长期项目尤其重要。第四也是我最想强调的一点分数只是验收的入口不是出口。95分和85分的差距并不代表“差10分”这个绝对值而代表评测尺度是否匹配业务风险。做药企RAG宁可要一个严格口径下“看着难看”的85分再花时间把错题一个个消掉也不要一个宽松口径下“虚胖”的95分上线后让业务人员在真实场景里去踩坑。我个人的工作习惯是接手任何RAG项目时第一件事就是和客户确认你们打算用什么标尺来衡量“答对了”如果对方只会说“差不多就行”那我就会主动要求把评分口径收紧先让系统在严格规则下把分数跑出来再一步步放宽到业务可接受的程度。这种工作方式在药企项目里尤其管用因为它逼着团队在验收前就把“什么是对的”这个问题彻底想清楚。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进