做生成式AI应用最怕什么我最怕模型一本正经地胡说八道。明明知识库里没有这个答案它也能给你编出一段逻辑通顺的话你以为它在总结文档结果它在文档之外补充了几个不存在的细节。这类问题在业内叫幻觉在业务里叫事故。为了解决这个问题我最近一直在用一套基于Hugging Face生态整理的幻觉检测评估套件它解决的核心问题很简单用统一、可复现的方式告诉我哪个模型更容易编造哪类提示词更容易诱发编造修改完之后有没有真的变好。这套东西适合谁适合做文档问答、企业知识库、智能客服、长文档摘要的开发和产品同学。你不用自己发明一套评估理论只需要准备一批有标准答案或参考文档的测试样本剩下的生成、判定、打分会由套件自动跑完。下面这些内容是我实际搭建和调试过程中的记录代码量不大但坑和取舍不少我尽量把每一步背后的原因讲透。1. 为什么我把“幻觉率”当作生成式AI的第一指标幻觉不是一个小概率偶发问题它几乎是所有LLM应用从Demo走向生产时绕不过去的一堵墙。我见过很多团队的评估表里只写了“回答准确率”但一问具体怎么算发现是让实习生看二十条回答然后拍脑袋打分。这种评估方式在小规模验证阶段勉强能用一旦模型迭代、知识库更新、提示词调整整个评估就失效了因为没有一个稳定的测量基准。1.1 幻觉到底是什么幻觉通常可以分成三类事实性幻觉、忠实性幻觉和逻辑一致性幻觉。事实性幻觉是说模型生成的内容和客观事实不一致比如某产品实际是2021年发布的模型却说成2023年。忠实性幻觉是说模型没有忠实于你给的资料比如你给了一段产品文档模型在摘要里编出一个接口名称。逻辑一致性幻觉则常见于多轮对话模型前面说支持三种权限后面又说只有两种。幻觉类型典型表现示例场景事实性幻觉与真实世界事实冲突产品参数、日期、人名错误忠实性幻觉与给定上下文冲突摘要里加入原文没有的细节逻辑一致性幻觉前后矛盾、推理断裂多轮对话中改变立场或结论做评估前先给幻觉分类是有用的因为不同业务对幻觉的容忍度完全不一样。金融报表、医疗问答这些场景里事实性幻觉是红线客服问答更看重忠实性答案不能跳出知识库长报告生成则是事实性和逻辑性的叠加。你后面选判定模型、定阈值都在依赖这个初始分类。1.2 人工评估撑不住规模化我最早也用过Excel表格人工标注每条回答手动写“正确”或“错误”。30条样本花了两个多小时中间还遇到一个更尴尬的问题我和另一个同事对同一条回答的判断不一致一个认为是幻觉一个认为只是措辞不同。后来把样本量加到200条人力成本直接翻了五倍而且不同人的标注尺子很难统一。规模上来之后人工评估的核心问题不只是慢而是不可复现。模型版本升级一次你重新测一遍换个人标注结果可能完全不同。幻觉检测评估套件至少能给出一个稳定的相对排序A模型比B模型幻觉率低5个百分点这个结论用同一套判定逻辑跑出来是可复现的也是能对外解释的。对团队决策来说这个相对排序比绝对分数重要得多。1.3 评估套件衡量哪些维度我在套件里会同时看四个维度事实一致性、可验证性、答案相关性和统计指标。事实一致性用NLI模型判断上下文能不能推出生成内容可验证性看生成句子是否能在给定文档里找到支撑句答案相关性用来排除那种“答非所问但逻辑自洽”的输出统计指标则是把前三个维度汇总成可对比的数字。评估维度判定方式关注点事实一致性上下文与生成句的蕴含关系输出是否被资料支持可验证性在文档中检索支撑句输出是否有据可查答案相关性与输入主题的语义匹配是否答非所问统计指标幻觉率、中立率、覆盖率横向可对比不要只看一个数字entailment、neutral、contradiction三个标签要分开看。一个模型如果contradiction很低但neutral很高说明它更保守、不爱编但也更可能答不出关键信息这在业务上可能是另一种不可接受。2. 基于Hugging Face生态的套件设计与工作流整套套件说起来并不神秘它就是一条流水线准备样本、让模型生成答案、用判定器判断是否幻觉、汇总报告。但设计上有一个容易被忽略的原则就是每个环节之间要解耦。生成结果和判定结果分开存模型换了不需要重新跑全部生成判定模型升级了也不需要重新花接口费用。2.1 整体链路我的工作流固定是五步。第一步准备JSONL格式的评估样本集第二步封装模型推理层既支持本地模型也支持远程API第三步批量调用生成接口并保存原始输出第四步用判定模型对输出做幻觉标注第五步生成带样本明细的报告。准备样本集JSONL格式每条包含指令、上下文、标准答案。封装推理层统一输入输出格式隐藏模型差异。批量生成固定参数输出缓存到本地文件。幻觉判定NLI模型或证据检索逐句标注。汇总报告输出幻觉率、中立率、抽检结果。在这个链路里我用的核心工具基本都是Hugging Face生态里的datasets处理数据transformers跑模型推理evaluate做指标汇总。套件本身就是对这一堆工具做编排让评估流程从一次性脚本变成可重复执行的任务。2.2 自动判定幻觉的两种技术路线自动判定幻觉主流上有两条路线。一条是基于NLI自然语言推理拿一个蕴含判定模型去判断“上下文能否推出模型输出”如果判定为contradiction或neutral就把它当成候选幻觉。另一条是基于自一致性或证据检索也就是对同一个问题采样多次看答案差异或者把生成的句子拿去知识库检索找不到支撑证据就判定为无依据。两种路线各有取舍。NLI路线最直观输出带“蕴含/中立/矛盾”标签方便定位是哪句话出了问题但长文本场景容易失准需要拆句后逐条判定。证据检索路线不依赖额外的NLI标注但计算成本高而且检索本身也会漏答案。我通常的做法是第一版先用NLI跑全局第二版在长文本摘要场景加一个证据检索兜底两种路线的结果互相印证。2.3 评估样本的数据结构样本数据结构我推荐用JSONL一行一个样本字段尽量自包含。下面是我常用的结构{ id: eval_001, type: factoid, instruction: 请根据以下资料回答问题不要添加资料外的内容。, context: 某产品的正式发布时间为2023年11月首批仅提供三个版本。, reference: 2023年11月, requires_grounding: true }type字段很重要后面可以按类型分组统计reference字段用于人工抽检时对照也用于在自动标注出现分歧时快速回溯requires_grounding标记这条样本是否强制要求答案必须来自上下文如果这个字段为false那模型自由发挥的空间就会大很多评估时要把两类样本分开。数据结构定清楚后面所有环节都会省事。2.4 套件的模块划分我把套件分成data、generation、judgement、report四个模块。data目录放原始样本和输出缓存generation目录放不同模型的封装和提示词模板judgement目录放NLI判定、证据检索判定report目录生成最终汇总报告。模块分离不是为了炫技而是因为模型和判定器迭代太快。判定的NLI模型换版本只影响judgement模块生成结果不需要重新跑prompt模板更新了只需要重跑generation判定和报告流程不用动。我见过很多人把脚本写成一个大文件改一个参数全局都要返工那种结构撑不过三次迭代。3. 从零搭建直接可落地的实操过程这一节是重点。我按真实操作顺序写你可以照着把套件跑起来。先说结论评估结果的质量不取决于指标算法有多花哨而取决于样本设计、参数固定和判定口径是否统一。3.1 准备评估样本集样本集是整套评估的地基。基础版本我建议准备三类单轮事实问答、带上下文的多轮问答、长文档摘要。单轮事实问答用来测模型的基础事实能力带上下文的多轮问答用来测上下文忠实性长文档摘要用来测综合能力。但数量不是越多越好。横向对比模型时30条就能看出趋势但要作为回归门禁至少准备50条超过200条边际收益递减因为自动指标稳定后差异主要来自样本构成而不是样本量。更重要的是样本里必须有“答案不在上下文中”的干扰样本如果所有问题都能在上下文里直接找到答案模型只是在做信息提取根本不是在做真实生成评测会严重失真。注意评估样本绝对不能来自模型的训练集。模型如果见过这些题目你测出来的是背诵能力不是事实准确性。我第一次做样本库时没注意来源管理后来发现某模型表现异常好一查才知道样本早被爬进训练数据了。3.2 控制变量跑模型生成跑生成之前先把参数口径定死。温度固定为0至少不超过0.1max_new_tokens固定短问答和长摘要分别设置提示词模板只换模型名不调整措辞。这个环节最容易被忽视很多团队让A模型用高温跑创意输出、B模型用低温跑保守输出然后拿结果说B更准这种对比没有意义。def run_generation(ds, generate_fn, output_path): records [] for item in ds: prompt build_prompt(item) answer generate_fn(prompt) records.append({**item, model_output: answer, prompt_version: v1}) write_jsonl(records, output_path) return records生成结果务必保存到本地文件建议把prompt_version、模型版本、参数配置一起存进去。这些元数据在后期排查时非常关键你总不想在两周后面对一堆输出却想不起来是哪版模型、哪版提示词跑的。3.3 用NLI模型做幻觉标注NLI判定的核心是把模型输出拆成句子逐个判断每个句子和上下文的关系。整段做判定很容易被长文本“带偏”因为模型可能看到大部分内容能对上就忽略了某个矛盾句。拆成句子之后每个句子的判定结果更稳定也能直接定位到具体的幻觉表述。def judge_sentence(context_parts, sentence, nli_pipeline): best_label neutral for part in context_parts: result nli_pipeline({text: part, text_pair: sentence})[0] if result[label] entailment: return entailment if result[label] contradiction: best_label contradiction return best_label这个逻辑是“只要有一个上下文片段能推出这句话就给entailment”。这样做是为了避免因为资料里某个段落覆盖不到位把本来有依据的句子误判成幻觉。如果所有片段都判不出蕴含退而求其次返回contradiction或neutral。contradiction代表这句话和上下文直接冲突是最高优先级的幻觉候选neutral未必是幻觉也可能是资料缺失导致无法判断。所以报告里三种标签要分开列不要一刀切把neutral都算成错误。3.4 计算幻觉率并生成报告我习惯同时计算两个幻觉率。句子级幻觉率是contradiction句子数除以全部输出句子数衡量整体输出质量样本级幻觉率是“至少包含一句contradiction的样本数”除以总样本数衡量有多少回答是不可信的。长摘要场景我会重点看样本级幻觉率因为一句话出错可能整篇都不能用。模型样本数输出句数contradiction句占比含幻觉样本占比neutral句占比模型A504122.7%18%11%模型B503888.5%42%16%表面上看模型A优于模型B但还要看neutral占的11%意味着什么。如果这些neutral都发生在关键信息上说明模型A经常给不出完整答案这在业务上同样不可接受。评估报告如果只展示一个幻觉率数字复盘时一定会被追问“那它是不是什么都没说”。3.5 抽检与结果解释自动标注跑完不代表评估完成。按我的习惯随机抽20%的样本把模型输出、判定标签、上下文打印出来人工复核。复核的重点不是重新打分而是检查判定模型有没有被上下文里的某个片段误导。比如一段资料里同时存在相互矛盾的说法模型引用了其中一句NLI可能判entailment也可能因为另一句判contradiction这种边界情况只能靠人工定性。提示自动评估是初筛不是金标准。报告里一定要带样本id和原始输出只给一个汇总指标后续没法回溯也没法定位问题。4. 常见问题与排查技巧实录这一节是我实际踩坑记录的整理很多问题不是看文档能提前避开的归类在一起方便你遇到类似现象时快速定位。4.1 全部被判定为entailment或者neutral怎么办如果所有输出都判定为entailment大概率是样本太简单上下文直接包含答案模型做的基本是信息抽取而不是真实生成。解决办法是增加“答案不在上下文中”的样本强制模型在已有信息基础上做推理或总结。如果输出全是neutral或contradiction很可能NLI模型本身太弱对中文、长句或领域术语理解不够。可以先跑几条测试句子验证判定器不行就换针对中文训练的NLI模型不要急着改业务样本。4.2 错误集中在长文本摘要长文本摘要的评估最容易失真。整段输入NLI模型模型只能抓住整体语义很难捕捉到某个细节被篡改或新增。我的做法是把模型摘要按句子切分然后逐句去原始文档里找支撑证据。如果每句话都能找到出处但整体漏掉了关键信息这不是幻觉是摘要不完整应该单独看关键点覆盖率不要和幻觉率混在一起。评估套件里最好单独加一个“missing key content”标签把两类问题分开统计。4.3 自动标注与人工判断对不上自动标注和人工判断的一致率能做到70%到80%就已经算不错了不要指望完美对齐。不一致不代表自动标注没有价值把它当成初筛工具把高风险样本筛出来交给人工效率远高于人工从头看完全量。真正上线之前自动评估也不能替代一小批专家样本的红线测试。我见过不止一个项目把自动指标当成金标准直接上线结果在真实用户场景中翻车原因就是自动指标漏掉了上下文中的隐含假设。4.4 评估结果不稳定跑两次不一样同一个模型跑两遍结果不一样先看温度是否固定再看采样种子、模型精度和推理环境是否有差异。fp16和bf16在某些模型上长文本生成的输出会有细微差别。建议把随机种子、参数配置、推理框架版本都写进记录至少保证同一环境下的结果可比。另外如果模型每次都采样多次再合并答案评估结果也会抖多采样取平均是可以的但成本会跟着涨需要权衡。4.5 模型“甩锅”给提示词怎么办如果同一模型在不同prompt下幻觉率差异巨大先别急着把锅完全甩给模型。提示词里的“根据资料回答”和“可以自由发挥”能拉开好几个百分点的差距所以prompt模板必须纳入版本管理。我推荐在评估记录里增加prompt_version字段每次对比都保证同一个模板。否则后期复盘时你说“这版模型有问题”我说“是你提示词改了”谁也说不服谁。把prompt固定住模型表现才有可比性。5. 从评测报告到业务改进评估套件不是跑完出个报告就结束的它的真正价值是驱动改进。同样一套东西有人拿它做模型选型有人拿它做回归门禁有人拿它做提示词优化。下面几个方向是我实践下来最有产出感的用法。5.1 用同一套件横向比较模型最有价值的产出不是某个模型的幻觉率绝对值而是同一个套件下多个模型的相对排序。选型时我不会只看幻觉率还会同时记录延迟、成本、上下文长度限制。有时一个模型幻觉率低5%价格却贵两倍业务不一定接受。评估套件跑完输出一张对比表Leader做决策时就不用靠感觉而是拿同一批样本、同一个判定标准说话。5.2 把误差分析拆到prompt、检索、生成三个环节一次回答不准确原因可能来自三个层面检索没召回正确文档、prompt没约束住模型、模型本身编造。评估套件在跑的时候可以把检索到的候选段落一并存进evidence字段。如果答案错了但证据里有正确内容问题大概率出在生成阶段或prompt设计如果证据里压根没有相关内容问题在检索阶段。这样分锅之后改方向才精准而不是盲目换模型或者乱调prompt。5.3 建立回归基线防止劣化模型版本升级、知识库结构调整、提示词微调任何一个变更都可能影响幻觉率。我的做法是固定一套基准样本每次变更后重跑同一套评估把幻觉率和上一次对比如果上升超过1个百分点先暂停上线。这个门禁初期手动跑也行等样本集稳定后再接到CI里自动化跑。我见过太多项目上线前临时测一下之后再也不测模型一升级就静默劣化用户反馈越来越多才回头查。5.4 自动化把套件接进CI流程如果团队有CI系统可以把评估套件做成一个可调度的任务拉取最新代码、跑评估样本、输出报告、把结果追加到历史表里。不要每次commit都跑全量样本成本扛不住建议在PR合入前跑小样本集做快速筛查夜间再跑全量样本做回归对比。自动化的意义在于让评估成为常规动作而不是上线前的临时仪式。最后分享一个我自己实践中的经验。我第一版评估套件过于依赖自动指标后来发现某次模型幻觉率确实降了但仔细一看是因为模型回答变得更短更保守该给的信息不愿意给了。从那以后我把平均输出长度、neutral比例、关键点覆盖率一起放进报告才没有被单一指标骗到。如果你正准备搭自己的评估套件也记住这句话指标是地图不是终点任何时候都要回到真实样本上看一眼。