前阵子在给一个生成式系统做输出质量治理的时候我翻到内部代码仓库里躺着一个熟悉的名字——Harvey LAB-AA。这个项目从 v1.0 走到 v1.1核心变化只有一个引入了幻觉门控评分机制。听起来像是个小改动但实际把整个生成链路的质量水位往上拉了一大截。这篇文章就围绕“幻觉门控评分”这个主题把版本迭代前后的设计思路、实现细节、踩坑记录全部拆开给同样在折腾生成内容可控性的朋友一个完整参考。这个机制解决了一个非常现实的问题大模型生成的内容好不好不能光靠“人看两眼”来定而是要在一个可量化、可拦截、可回溯的框架里做实时评估。Harvey LAB-AA v1.1 做的事情简单说就是给每一条生成结果打一个“幻觉风险分”分数不达标就直接拦在业务外面不进入下游展示链路。这套东西适合谁适合正在做 AI 客服、智能写作、知识库问答、报告生成这类场景的开发者凡是“模型胡说八道会造成真金白银损失”的业务都能从这里拿到可以直接落地的思路。1. 整体设计与思路拆解1.1 为什么需要一套“幻觉门控”先说说为什么会有这个版本。v1.0 时代整个系统对生成内容的质量控制基本靠两种方式一种是 Pure Prompt 工程在提示词里反复强调“请基于给定资料回答不要编造”另一种是人工抽检定期拉一批日志逐条看。前者的问题是模型并不总能遵守指令尤其当上下文里给了大量资料、用户又追问得比较刁钻时模型很容易在“找不到答案”和“硬编一个答案”之间选择后者。后者的问题更明显——抽检覆盖率低线上真正出问题的那几条恰恰不在抽检样本里。做 v1.1 的时候我们达成了一个共识幻觉不可能被完全消灭但可以被拦住。这个“拦住”的动作如果交给规则、交给人工都不够可靠因为幻觉的表现形式太灵活了。有的幻觉是张冠李戴把 A 产品的参数安到 B 产品上有的幻觉是无中生有直接编出一个不存在的功能还有一种是逻辑跳跃资料里根本没提的信息模型根据“常识”自行补齐。规则很难覆盖所有这些形态人工又跟不上实时请求的节奏。所以方向从一开始就很明确做一个独立的评分层插在生成模块和输出模块中间。生成完成之后、返回给用户之前让评分层对内容做一次全面的可靠性评估给出一个可解释的分数业务方根据自己对风险的容忍程度设置阈值低于阈值就触发兜底策略。这套机制的核心价值不在于“把分数算出来”而在于把质量判断这件事从“感觉”变成了“工程”。1.2 为什么选择“评分”而不是“分类”设计过程中团队内部争论过一个关键问题到底是要一个“好/坏”二分类器还是一套评分机制如果只是做分类实现起来更简单但在真实业务里完全不实用。原因在于不同场景对幻觉的容忍度天差地别。内部知识库问答里偶尔夹带一句不太准确的话可能只是影响体验但面向客户的合同条款问答要是出现幻觉那就是事故。评分机制天然自带“阈值可调”的属性。同一个评分模型在低风险场景可以把阈值设到 60在高风险场景可以设到 90不需要重新训练一套模型。业务方可以根据自己的风险偏好来调这种灵活性在工程落地时太重要了。另外一个被很多人忽略的好处是评分天然支持排序和筛选。当系统同时生成多个候选结果时可以用同一套分数来做取舍而不是简单地把两条结果都扔给人工去选。从技术实现的角度看分类器的训练需要大量“好/坏”标注数据而且“坏”的样本分布非常分散。评分模型的训练目标更平滑哪怕标注的分数带有一定主观性模型学到的映射关系也比硬分类要稳。实际跑下来后这个选择被验证是对的——评分模型的区间稳定性明显好于早期试过的分类方案。1.3 方案整体架构在哪个环节插入门控Harvey LAB-AA v1.1 的整体结构可以概括为“生成-评分-决策”三段式。生成阶段保持原有逻辑不变模型按照原有的提示词和上下文输出完整结果。评分阶段是新增的独立模块拿到生成结果后并结合输入上下文和知识库检索片段产出一组风险指标。决策阶段由一个轻量级路由配置驱动根据评分结果决定放行、重写、拦截还是转人工。这个设计最核心的一个决策是评分层绝对不参与生成过程只做评估。一开始有同事提议让评分模型直接输出修正建议和生成的文本一起返回。把评估和修正耦合在一起会让评分结果的可解释性大幅下降而且一旦修正逻辑出了问题你很难分清楚是生成模型的问题还是评分模型的问题。职责单一化之后每一层的工程质量都可以单独做评测和优化。为了不让评分模块成为整个系统的延迟瓶颈架构上做了并行化处理。生成结果一落地评分请求立即发出同时主流程开始做基础的输出格式化、敏感词过滤等轻量操作等评分返回后再做最终决策。这样净增加时间大概能控制在一次模型调用的范围内对于大多数异步业务场景完全够用。2. 核心机制解析幻觉门控评分是怎么工作的2.1 评分维度的拆解Harvey LAB-AA v1.1 的评分并非一个黑盒输出而是由多个可解释的子分综合而成。每个子分都有明确的定义和独立的计算方法最终得分是这些子分的加权融合。这个设计的好处是当一条内容被拦截后审核人员能清楚看到它到底是因为哪一项不过关而不是面对一个干巴巴的数字无从下手。v1.1 设定了四个核心维度。第一个维度是事实一致性主要衡量生成内容中的关键实体、数字、关系是否与上下文或知识库检索片段吻合。第二个维度是指令遵循度判断生成结果有没有偏离用户原始需求比如用户问的是对比方案模型却只介绍了单边情况。第三个维度是逻辑连贯性主要检查内容内部是否存在因果矛盾、前后冲突。第四个维度是知识边界意识衡量模型在缺乏充分依据时是如实承认不知道还是强行编造了一个答案。前三个维度相对好理解第四个维度是最有意思的。知识边界意识评估的是模型对“自己不知道”这件事的感知能力。实际测试中我们会专门构造一些超出知识库范围的问题观察模型的反应。做得好模型会明确回答“以下内容仅供参考我未找到相关资料”做得差则会用看似合理的语气编出一段内容。把这种现象作为评分维度单列出来向上管理和业务侧解释时都很有说服力。最终得分采用加权求和的方式公式为final_score w1 * fact_score w2 * instruction_score w3 * logic_score w4 * boundary_score权重的默认配置是 0.5、0.2、0.15、0.15但在实际项目中这个配置不是固定的。有一个偏金融问答的场景事实一致性权重被调到了 0.7有一个面向创意写作的场景逻辑连贯性权重被降到了 0.1。权重配置接口化哪个场景权重不同就直接在配置中心下发不用改代码。2.2 评分模型的选型与训练方式评分模型的选型是项目里最有争议的部分。一道选择题摆在我们面前直接用一个大模型做评分还是训练一个轻量的专用评分模型。大模型做评分的好处是理解能力强能处理复杂的语义关系坏处也一样明显——贵、慢、不透明。专用评分模型的好处是快、便宜、可控制坏处是需要足够的标注数据。v1.1 最终采用的是混合架构。用一个大模型和一个小模型的组合大模型负责部分复杂的、需要强语义理解的维度小模型负责分类明确、特征确定的任务。具体分配策略是事实一致性里关于实体、数字、日期这类硬指标交给规则和训练小模型来处理而指令遵循度和知识边界意识这种需要深层语义理解的走大模型的推理链路。这个组合方案在成本上做了一个很巧妙的折中。以实际调用量来看如果有 100 条生成内容需要评分其中大概 70 条是能通过快速规则和小模型直接得出结论的只有剩下 30 条会真正走到大模型推理那一步。相比全部走大模型评分成本下降了大概 60%而延迟也从平均两秒压缩到了 800 毫秒左右。这个差距在实时业务里感受非常明显。那 30% 的比重其实会随业务变化。比如内容越专业、实体越密集的领域快速规则能覆盖的比例就越低更多请求会进入大模型路径。所以在架构设计上没有把两条路径做成“固定的主备关系”而是设计成了可动态调优的流量分发策略。基于线上日志分析不断调整分流比例这是一个持续打磨的过程。2.3 基准库与动态阈值的配合评分模型只能给结果打一个分数但“多少分算及格”这个问题其实比想象中复杂得多。如果全局统一用一条阈值线在跨场景应用的时候就会出现严重的误判问题同一段内容在内部知识库场景里可能被放行放到严肃的公文生成场景里就该被判为不合格。所以 v1.1 在评分之外还引入了一个基准库机制。基准库里沉淀了一批典型的“高危输入”和对应的优质参考输出以及一批典型的“高危输出”和对应的解释。每周都会有专人从线上拦截日志里抽选典型案例补充到基准库里新模型在发布前都会先在基准库上跑一遍回归测试确保新模型不会把原本拦得住的问题放过去。动态阈值的概念更加实用。上线初期团队每天分析评分分布与人工复核结果之间的关系画出一条校准曲线。通过校准曲线可以直接看到某个分数下真实误判的概率是多少。例如某天调低了阈值从 75 降到 70虽然放行数量增加了 8%但经过人工抽检发现新增放行内容里的质量问题率整体可控因此这个调低就是合理的。这本校准曲线就是“动态”的决策依据。严格说这不是自动调整阈值而是人工根据数据持续校准阈值的过程。对系统稳定性要求不高的团队可以固定阈值跑到底但对于质量敏感的业务我强烈建议把“校准阈值”做成一个每周固定动作它比频繁更新评分模型要快得多也便宜得多。3. 实操过程与核心环节实现3.1 快速接入的基本流程Harvey LAB-AA v1.1 接入现有系统的过程我已经在几个不同的项目里完整跑过。整体接入步骤经过模块化设计大部分业务系统都可以在两三天内完成改造。下面给出一套比较标准、可以“抄作业”的接入流程。第一步审视现有生成链路的位置。幻觉门控评分应该插在生成结果返回之前同时能拿到三份输入原始用户指令、返回给用户的生成结果、产生结果时使用的知识库检索片段。如果发现链路里拿不到知识库片段就需要先做链路改造这个改造优先级最高。没有这部分输入评分模型的依据就不完整不完整的事实性判断有时比不判断还危险。第二步配置接入参数和风险策略。初始化时需要根据自己的业务场景设置阈值和兜底策略。兜底策略常见的有四个选项拦下不回复、转人工、让模型重新生成一次、放行并附带“内容可能不准确”的免责提示。不是因为“越高越好”而是因为风险偏好是业务决定的不是技术决定的。第三步小流量灰度。灰度过程建议从 1% 流量开始观察两个核心指标门控触发率不同业务通常在 3%-20% 之间不等和用户反馈率变化。不是所有被拦截的内容都是错的初期的误杀率普遍偏高大概有三分之一的拦截结果是人工复核后认为“其实还可以”。这个阶段目的就是摸清自己的基准状态别急着调阈值收集数据才是重点。第四步关注线上日志和评分数据。每次评分都应固化成一条结构化日志每条日志包含子分数、触发规则、所依据的检索片段 ID 等这样才能后续做质量问题回溯和参数优化。格式化日志没做好的话后续一切分析都无法开展。这一步最容易被忽略但也是最值得投资的事情。3.2 核心参数配置剖析接入时不改代码、只调配置核心参数就四项触发阈值、子分权重、快速规则开关、大模型评分兜底比例。在实际项目里我对这四个参数做过很多组实验可以给出一些有参考价值的基准经验值。触发阈值是全局的准入门槛60-65 是低风险基准适合闲聊、辅助写作、信息整理类场景70-75 是中等级别适合内部知识库问答、一般客服场景80 以上是高风险基准适合合同问答、医疗建议、投研分析等。需要特别提醒的是一个业务如果同时存在多种风险等级的产品建议按产品线拆成多个评分实例分别设阈值而不是用一个混合阈值否则要么过松要么过紧。子分权重的调整原则是“高权重维度优先看子分不只看总分”。例如金融场景事实一致性子分即使总分到了 80如果事实分单项低于 60仍然建议强制拦截因为那个场景下事实错误是致命问题。在代码设置上也提供了“单项最低分”这个独立配置我建议高风险业务务必备上。快速规则开关用于控制是否启用实体比对、日期校验、数字一致性检查、引用完整性检查这几类轻型规则。这些规则主要用的是上下文或检索片段里的关键词与生成结果做交叉核对逻辑简单、响应快。但规则存在一定的误伤风险比如模型用同义词替换了实体名称明明内容是对的规则却判定不一致。因此快速规则在严肃场景中只做“必须且容易误伤的少部分检查”在低风险场景中可以做大量筛选。大模型评分兜底比例直接决定成本与覆盖面的平衡。正常情况 20%-30% 够用。如果业务对质量要求极为严格宁可接受更高延迟也绝不放过幻觉比例可以调到 100%但这时候必须接受成本上升同时建议开启缓存策略对相似请求做评分结果复用。3.3 离线验证把评分机制当作文档再说一个很多人忽视的操作不要让评分机制只活在线上系统里要定期跑离线验证。v1.1 这套体系最大的好处是它有基准库这就天然构成了一个回归测试集。每次业务升级后或者评测模型版本更新时把基准库里的几百条测试样本跑一遍看一看各维度的分数分布是否发生漂移比上线后被动看日志要可靠得多。我在一次版本升级后遇到过一种情况整体分数平均值涨了一点但具体到子项边界意识维度分数出现下滑。如果只看平均总分很容易误判为新版本效果好错过边界意识弱化这个隐患。通过离线验证把子维度拆出来就能精准定位到是哪个维度退步了——很久以后复盘时发现是因为模型参数更新后对特定表述的敏感性下降了。这种问题不打分拆维度根本发现不了。离线验证建议做每周自动化。把基准库跑完生成对比报告自动比对分数误差超过 5% 的样本标黄交给人工判断。完全不用重新训练模型就靠这个验证体系就能让系统长期保持稳定运行。这个机制说实话比刚开始做评分模型本身带来的收益还要大。3.4 可观测性与日志规范接入这套系统之后可观测性成了日常运维最重要的抓手。v1.1 从一开始就设计了比较完备的日志规范每条评分记录都会输出为 JSON 格式的结构化日志建议的字段包括请求 ID、生成模型 ID、评分模型 ID、触发路径快速规则/小模型/大模型、子分结果、最终得分、命中阈值、兜底动作、耗时。有了这份日志查询问题时可以做到“三个定位”。定位到是哪条用户请求触发了问题定位到是哪条生成内容没过关定位到是哪个维度的问题导致它没过关。这三个定位做完这个问题的闭环就基本完成了。如果没有好的日志结构这三个定位里的任何一个都很难快速做到问题排查时间至少会多出三倍以上。日志本身对系统优化的价值远超预期。有一次线上反馈某类问题明显增多通过拉了最近一小时的日志看发现被拦内容的 boundary_score边界意识分出现了系统性下降。顺着日志往下查发现问题不是模型变笨了而是上游检索模块返回了一段新的知识源这段知识和旧知识源在时间维度上发生了冲突。日志帮你精准定位到这种“模型没变但数据变了”的情况简直不要太爽。4. 常见问题与排查技巧实录4.1 误杀率过高正常内容被频繁拦截这是接入后第一个遇到的典型问题几乎每个团队都会踩一遍。表现是评分很低的内容在人工看来没什么大问题用户也反馈正常内容被莫名拦截很影响体验。排查思路的第一件事是拆分子分数不要盯总分。把拦截日志按月拉出来分析子分分布很多情况下会发现高频罪魁祸首就是那一个维度。比如事实一致性维度权重若设得过高模型内容用了一个不太精确但可以理解的同义表述这个维度就会疯狂扣分把总整体分拉低。处理方式通常有三种组合拳。第一是降低快速规则中词面精确匹配的比重增加语义相似度匹配毕竟模型很擅长换着说法表达同一个意思。第二是调整权重事实一致性权重降一些给逻辑和连贯性维度多留空间。第三是单独为“高风险误杀类型”补充基准库样本让评分模型学习到这类内容其实可以放行。这三步走下来误杀率通常能降一半以上。还有一个很少人注意到的点有时候误杀不是评分模型的问题而是提示词的问题。如果生成端的提示词要求过于严苛让模型产生很多防御性表达或者系统性使用“大概率”“可能”这样的模糊词评分模型也会倾向于给低分。这种情况下不要只调评分侧配合优化生成端的提示词效果会更好。4.2 阈值调低后漏网幻觉反而变多很多团队在初期为了追求“少拦正常内容”会把阈值调得很低。比如从 75 调到 65结果发现拦截量少了很多但漏掉的幻觉数量也在上升。这里的关键问题是分数这个标尺本身可能对某些类型的幻觉不敏感。我排查过一类典型案例一条生成内容从整体上看句式流畅、逻辑勉强能通但实际上在前半段使用了正确的信息后半段却悄悄滑向没有依据的自说自话。这种“先对后错”的问题全局打分时很容易被前半段的正确信息拉高总分从而通过阈值。问题就出在它是“局部幻觉”是评分模型的弱点。解决这类问题的有效做法是引入滑动窗口评分。把生成内容按句切分对每个句段单独算一次分再把“各句段的最低分”作为一个独立指标和全局分一起决策。实际落地下来这个“局部最低分”指标能捞回大概 70% 的漏网幻觉效果非常明显。不要只依赖总分要设定关于子项得分的否决条件。另一种隐蔽的漏网是幻觉内容恰好来自检索片段本身知识源就有误导信息。评分模型拿检索片段作为事实依据比对时发现生成内容是“一致”的自然打了高分。这种情况的处理方式就不再是评分层能单独解决的了需要对知识源本身也做一套质量评级低质量知识源检索到的内容即使生成侧分数高也要强制降级或转人工。4.3 评分模型跑得慢影响整体链路性能接入初期评分模块耗时较高尤其在走大模型评分的路径上。如果原业务要求接口返回时间在 1.5 秒以内评分流程占掉 800 毫秒甚至一秒那整体改造基本就不可能推进。这个问题在资源不足的团队里尤其致命。我找到的有效解法有三条路径。第一条是前面提过的流量分层策略尽可能让更多请求走快速规则和小模型。快速规则基本是内存内的计算毫秒级完成在面对大量简单请求时能够节约大量时间。第二条是增加缓存层很多用户的问题高度相似生成结果也有很高的相似度直接在缓存里把评分结果复用等于白赚的性能。第三条是在模型层面做量化把评分小模型用轻量化方式部署大模型评分路径则用更小尺寸的模型尽量替换。这三条路不走完直接上大模型系统肯定慢得没法用。另外要说一个很容易被轻视的因素网络调度。评分模块和生成模块部署在不同服务实例上时跨服务调用本身会带来额外耗时。如果条件允许尽量把评分模块和生成模块放在同一个可用区内网络延迟能压到仅剩 1 毫秒级别。有一个项目就是把这个调度优化做了之后整体耗时一下子下降了 20%。4.4 评分结果与人工判断之间的信任问题最后聊一个综合性问题。评分模块上线一段时间后另一个难题出现了团队内部的人包括业务、审核、甚至开发对评分结果没有建立起信任。表现就是每次系统只要拦了一条内容都要先人工再查一遍才能确认“评分结果仅供参考最后还是靠人”的思潮开始蔓延。这其实代表系统性工程没有得到充分验证和解释。建立信任靠三件事解释、统计和平反机制。解释是指每条拦截结果都附带原因子分和依据片段让人去看一眼就能懂为什么拦。不要只给一个分数让人觉得是黑盒。统计是指每周做一次抽样复核定期公布“评分模型拦截正确率”。当数据稳定在一周 95% 以上的时候团队内部的信任感会逐渐建立起来。平反机制是如果某条内容被拦截但人工复核后认为没毛病允许一键反馈反馈样本沉淀下来进入基准库再训练评分模型。这条反馈链路是系统“成长”的关键它让人和系统之间的关系从对立变成互相校准。这几个问题其实都是系统上线必经的阶段。没有哪个系统第一天就达到完全可靠关键是形成一个“数据-调参-校准-再验证”的闭环持续改进比一开始追求完美更重要。5. 版本演进方向与实际应用场景5.1 从“门控”走向“引导”v1.2 的前瞻思考幻觉门控评分在 v1.1 的角色更像一个质检员内容出来了先检查一遍不合格就挡住。这个角色定位在当下业务中很有价值但它本质上是被动的。你想一想与其让模型生成一条有幻觉风险的答案再把答案拦掉不如在生成的时候就引导模型往不容易犯错的方向走。主动引导显然效率更高。所以在 v1.2 的规划里评分信号不只是作为门控判断依据还会反向输入给生成环节。当评分系统识别到某个内容存在边界意识不足的风险时会把这个信号反馈给生成端的前置处理模块引导模型在生成时更早地引用依据、更谨慎地表达不确定信息。远期计划中评分端还会在有多个候选结果时直接按质量排序挑选分数最高的结果优先生成而不是把所有候选都返回再由上层去尽职调查。这部分的思路已经比较成熟实际落地会在下一轮迭代推进。v1.1 的稳定表现让我对这个方向有充足的信心——至少评分已经不是副业而是主流程中的一部分了。“质检员”工作做扎实后“插班生辅导员”的方向也就顺理成章了。5.2 幻觉门控评分在产品化能力之外的价值回看这个项目的整体价值与其说它是让生成系统的答案变得更加可靠不如说它是让“可靠性”成为了一项可被持续工程质量改进的能力。v1.1 给了团队一种办法把质量判断从一种隐性的手艺变成一种显性的工程能力。工程师可以说出“这条内容因为边界意识分低被拦了而那一条因为事实分高而放行了”质量不再是一团迷雾而是一串可以被管理的数字。这套能力对产品化的帮助也非常明显。在对外输出能力时有一个稳定的“质量闸门”放在系统前面客户沟通会顺畅很多。有客户在做测试的时候主动要求看评分日志和基准测试报告当我们把评分维度和子分数据展现出来后客户能很直观地感受到这个系统的严谨性信任成本大幅降低。这是纯靠生成质量本身很难做到的事。从运营视角看幻觉门控评分的意义还在于它让质量问题和数据打通起来了。每次拦截实际上都是一次“数据打标”本质上就是不断在发现模型能力边界。长此以往团队积累的不仅是一个系统更是一套关于自己业务数据的知识库。真实的业务样本比任何公开数据集都有价值。我会持续往这个方向深耕后续进展也会继续更新出来。