大家在做大模型应用的时候多少都遇到过这种场景模型一本正经地给出一个答案结构完整、语气笃定结果关键数据是错的或者模型完全没引用你提供的文档内容自顾自地在“发挥”甚至答非所问把文档里根本没提到的细节编得有模有样。这类问题现在有个统一的称呼——大模型幻觉。而围绕幻觉的评估业内讨论最多、也最容易被搞混的两个概念就是忠实性Faithfulness和事实性Factuality。很多人把这两个词当成同义词用觉得“模型输出是不是符合事实”就是幻觉评估的全部。但在真正落地评估体系的时候这两个维度的差异会直接影响你判断问题的方向到底是检索环节出了问题还是模型生成环节出了问题还是知识库本身的内容就是错的。如果口径都没对齐后面做的所有评估都会变成一笔糊涂账。这篇文章我会把这两个概念掰开揉碎地讲包括它们各自的定义边界、评估方法、落地指标、典型误区和实操经验也会聊聊在RAG场景下怎么把这两条线配合起来用。不管你是刚接触大模型评估的新手还是已经在做评测体系搭建的工程师这篇文章应该能帮你省掉不少试错的成本。1. 从“看似合理的胡言乱语”说起为什么要认真评估幻觉先描述一个大多数开发团队都经历过的场景。你做好了一个基于大模型的应用接入了企业知识库测试时发现模型回答问题时非常流畅用户问什么都能接上。但你让业务同事帮忙试用他们提出了一个让你尴尬的问题“它说的这个数据是从哪里来的我查了知识库文档里根本不是这么写的。”这个问题的本质就是模型在生成回答时没有忠实于给定的上下文内容而是依赖自己在预训练阶段学到的知识“脑补”了一段看似合理的答案。这种“脑补”里的错误并不总是显而易见的它可能是一个错误的时间、一个偏差的数据、一个张冠李戴的人名甚至是一个完全虚构的事件。用户如果不仔细核对根本发现不了。幻觉问题之所以让工程团队头疼不只是因为它“错”了而是因为它的错误概率分布在应用的所有环节里。检索召回的文档可能不够准模型可能误解了文档的意思文档本身可能已经过时用户的提问方式可能给了模型“发挥”的空间。这些问题有些出在数据侧有些出在模型侧有些出在交互设计侧。如果不先界定清楚你评估的到底是什么层面的错误你的排查就会变成无头苍蝇。更关键的是幻觉不是一个“全有或全无”的问题。同样一段回答可能前半段严格依据了检索到的文档后半段就开始自由发挥可能核心观点是对的但具体数字是编的可能引用的文档是对的但把文档的角度理解偏了。这种混合状态决定了你没法用“对”或“错”这种二元标准去评估必须引入更细粒度的判断维度。这也是为什么我把忠实性和事实性分开来看。这两个概念分别回答了两个不同的问题模型有没有“照着材料说话”模型说的内容跟真实世界一致吗前一个问题是过程问题后一个问题是结果问题。在实际评估中这两个问题的答案经常出现错位——模型照着材料说话了但材料本身是过时的模型说的内容恰好和事实一致但其实根本没看材料。如果只看结果不看过程或者只看过程不看结果你的评估结论都会失真。所以做幻觉评估的第一步不是急着选指标、调工具而是先把你想评估的东西定义清楚。是评估整个问答系统的输出质量还是仅仅评估生成模块的上下文利用能力是评估单轮回答的正误还是评估多轮对话中的信息一致性这些问题会直接影响你后面的评估方案设计。2. 忠实性与事实性两个被混用了太久的考核维度在正式开始讲评估方法之前必须先把这个最基础的概念差异讲透。因为我在实际和不同团队交流时发现这是被混用得最厉害的一对术语。2.1 忠实性模型有没有“照着材料说话”忠实性衡量的是模型的生成内容是否忠于给定的上下文内容。这个“上下文”可以是用户输入的提示词可以是RAG系统里检索到的文档片段也可以是多轮对话的历史记录。只要模型被提供了参考资料它输出的内容就应该严格建立在参考资料的基础之上不能超出、不能遗漏、不能曲解更不能凭空新增信息。用一个很直白的例子说明。假设知识库里有一份产品说明明确写着“A套餐的月费为199元包含100GB国内流量”。模型在回答“A套餐多少钱”时给出了299元的答案这就是典型的忠实性问题——它没有忠实于给定的材料而是引入了材料之外的信息。材料里怎么说模型就该怎么复述信息粒度可以调整表达方式可以重写但核心内容不能偏离。这里有个容易误解的点很多人以为忠实性问题就是“不引用原文”的问题其实不是。模型哪怕没有逐字引用原文只要它输出的信息全部可以从上下文中推导出来也是忠实的。反过来模型哪怕逐字引用了原文但把关键信息理解偏了同样算不忠实。忠实性的核心在于“信息是否可溯源到给定的上下文”而非“表达形式是否贴近原文”。忠实性的判断对象通常是短粒度的事实陈述而不是整段回答。一段回答中可能包含多个事实点每个事实点是否忠实于上下文要分开判断。这种细粒度的拆解方式和后面要讲的事实性评估是一脉相承的。2.2 事实性模型说的和真实世界一致吗事实性衡量的是模型生成的内容与真实世界事实之间的一致性。所谓“真实世界事实”通常依据的是权威知识库、经过验证的公开信息或者领域内的专业知识。它不关心模型是“从哪里知道”的这个答案只关心答案本身的正确性。还是用例子说明。假设模型在回答“巴黎埃菲尔铁塔的高度”时给出了“324米”这个答案即使完全没有参考用户提供的文档它也是事实正确的因为这是经过验证的公开事实。但如果模型回答“铁塔位于柏林”那就是事实性错误。在纯生成场景下事实性评估考察的是模型“知不知道正确答案”。在RAG场景下事实性评估多了一个考察角度即使模型忠实引用了检索到的文档如果文档内容本身是过时或错误的模型的输出虽然不是“忠实性”问题但客观上仍然不符合事实。这时候评估体系就要能区分错误到底是模型引入的还是数据源引入的。这个区分在工程上非常关键。因为处理方式完全不同。如果错误来自模型对文档的曲解你要优化的是生成模块如果错误来自知识库文档本身的过时信息你要优化的是数据更新流程。如果评估指标不把这两者分开你会以为所有错误都是模型的问题把时间耗在调模型上但问题其实根本不在那个环节。2.3 四个象限忠实性与事实性的组合判断把忠实性和事实性放到一个二维坐标里就会得到四种组合。这个分析框架在实际评估中极其好用值得好好理解和运用。组合含义典型场景问题归属忠实且事实模型忠于上下文且内容符合真实世界检索到正确文档并正确输出无问题忠实但不事实模型忠于上下文但上下文本身错了文档过时、知识库源头错误数据侧问题事实但不忠实模型输出内容正确但没基于给定的上下文模型凭“记忆”回答了问题忽略了上下文生成侧/推理侧问题不忠实且不事实既没照着材料说内容也是错的模型严重幻觉、编造生成侧严重缺陷这里最值得警惕的是“事实但不忠实”这个组合。因为输出内容在事实上是对的人工评估时很容易直接判对从而忽略了模型压根没在执行“基于知识库回答”的任务。这种隐蔽性问题在自动评估里更难发现尤其是当你的评估指标只看最终答案的正确性、不检查信息与上下文的对应关系时。我见过不少团队RAG应用的答案看起来质量不错人工抽查也都能对上事实但模型实际上已经退化成“一个内置了部分知识库内容的大模型”——它不再依赖检索结果来回答而是在用自己的内置知识硬撑。这种情况必须通过忠实性维度才能暴露出来。3. 量化考核适合具体业务场景的评估指标体系说清楚了概念之后接下来要解决的是落地问题怎么把一个抽象概念变成可以量化、可以执行、可以回归的指标。3.1 忠实性指标的拆解方式忠实性评估的常用思路是把模型生成的长回答先拆成原子级别的事实陈述atomic facts再逐条判断每个事实陈述是否可以从给定的上下文中推导出来。这个“拆解”的步骤非常重要因为整段回答的粒度太粗没法做细粒度的判断。举例来说模型回答“A套餐月费199元含100GB流量超出后按5元/GB计费”。拆解出来的陈述可能是以下几条A套餐月费为199元A套餐含100GB流量超出套餐流量后按5元/GB计费。然后逐条去上下文中查找依据。如果上下文中只有前两条信息没有第三条那么第三条就是模型凭空引入的属于不忠实陈述。在这个基础上可以衍生出多个量化指标。忠实性分数Faithfulness Score定义为“可被上下文支持的陈述数”除以“所有陈述数”。上下文利用度则可以反向考察给定上下文有N个可被利用的要点模型实际使用了几个这个指标能反映模型有没有“浪费”检索到的信息。引用覆盖率则是考察模型在回答关键陈述时是否标注了引用来源尤其适合需要用户核实的问答系统。还有个指标值得关注上下文矛盾率。它衡量的是模型输出中有多少条陈述与上下文内容直接冲突。这个指标比单纯的不忠实更严重因为“没说全”和“说反了”是不同等级的错误后者会直接误导用户必须单独跟踪。3.2 事实性指标的拆解方式事实性评估的进入角度与忠实性不同。它要先确立一个“事实基准”——也就是“什么算对”。这个基准可以是公开的权威知识库比如维基数据、领域标准文档、官方统计资料也可以是为评估专门构建的标准答案集。在基准明确之后事实性指标的判断逻辑就变成了比对。实际操作中常用以下三种方案进行比对第一种是构建评测问题集每条问题配标准答案评估时直接看模型输出与标准答案是否一致。这种方式最直观但要求问题集有足够的覆盖面和代表性而且标准答案往往无法覆盖所有合法表达方式灵活度差一些。第二种是利用外部知识源做自动验证也就是拿模型输出的陈述去和知识库比对判断是否与已知事实一致。这种方式适合大规模自动评估但知识库的覆盖度会直接影响判断结果的可靠性。第三种是人工标注由标注员逐条判断每条陈述是否与真实世界事实一致。这种方式精度最高但成本也最高适合用作小规模抽样和基准数据构建。事实性指标需要特别小心的一点是“未知”和“错误”的区分。模型说“A套餐价格未知”和说“A套餐价格是299元”是两种不同的状态。前者只是没答上来后者是答错了。很多团队只记录“错误率”完全忽略了“拒答率”这个同样重要的指标。这就太可惜了。拒答率的飙升虽然看起来不好看但它往往是模型没有足够信息时主动降低了幻觉风险是一种可控的安全行为。过度追求“有问必答”而牺牲的事实正确性才是更大的风险。3.3 指标的组合使用与阈值设定在实际评测中我不推荐只依赖单独某一个指标做决策。更好的做法是同时跟踪忠实性和事实性指标并把它们放到不同业务场景中赋予不同的权重。例如法律、医疗这类对信息准确性要求极高的场景事实性错误是不可接受的那么评估时事实性权重应该远高于忠实性而对于企业内部知识问答这类场景核心目的是“让员工快速找到组织里已有的信息”忠实性就更重要——你不能允许模型绕过检索结果凭空给答案。阈值的设定也需要根据业务容忍度来定。有些团队会设一个“幻觉率红线”比如事实性错误率超过5%就禁止上线。这个数字怎么定取决于错误的代价有多大。给用户推荐一部电影推荐错了损失几乎为零5%的幻觉率完全不是问题但如果模型在给医务人员提供药品剂量建议哪怕千分之一的错误率也无法接受。另外一个容易被忽视的点是用户对幻觉的容忍度并不是恒定的和模型输出的可验证性高度相关。如果模型回答中每一个关键陈述都附带了引用来源用户能快速验证那幻觉的心理接受门槛会降低不少。这也是为什么引用覆盖率这类“软指标”在评估体系里同样值得重视。4. RAG场景下的双线评估忠实性交代答案怎么产出事实性解答内容对不对RAG检索增强生成是目前大模型落地最常见的架构也是幻觉评估问题最集中的场景。因为RAG通常被当作“减少幻觉”的方案来用但实际部署后大家会发现幻觉并没有消失只是发生了转移——从模型自身转移到了“模型与检索系统的配合过程”里。4.1 为什么RAG的幻觉问题更复杂RAG系统的输出质量由三个环节共同决定检索环节拿回来的文档质量、生成环节对文档的理解利用能力、知识库源头的内容时效性与准确性。任何一个环节出问题最终都可能表现为用户看到的“错误回答”。这个时候如果用传统的大模型评估思路只看“回答内容对不对”你只会得到一个笼统的结论“系统有幻觉”。但你不知道幻觉是哪种原因导致的——是检索环节没找到正确的文档还是找到了却没被模型采用还是采用了但理解错了还是文档本身的信息就过时了这就是为什么不把忠实性和事实性分开就无法做好RAG评估的原因。因为RAG系统恰恰需要这两种评估各管一段忠实性负责评估“生成环节是否做好了”事实性负责评估“数据源头是否出了问题、以及最终答案和外部世界是否一致”。4.2 RAG流程中的忠实性评估细节在RAG流程里忠实性评估的核心任务是确认模型生成的回答是否严格建立在被检索到的文档基础之上。如果检索到的文档里有正确信息模型却没正确采用这就是模型的忠实性问题。实际操作中我建议按以下流程来做把用户的提问和检索到的文档打包作为一个“评估单元”模型生成的回答按陈述粒度拆解后把每条陈述逐一和文档内容做比对。每条陈述打上三种标签“supported”文档支持、“contradicted”文档矛盾、“not mentioned”文档未提及。其中“supported”和“contradicted”都说明模型参考了检索文档只是“contradicted”说明模型理解有偏差。最值得注意的是“not mentioned”这个标签——它的意思是模型输出了文档中完全没有的信息。这类信息几乎可以认定是模型在“自由发挥”是距离幻觉最近的一类输出。在实际业务评测中我见过不少团队在RAG场景里犯了同一个错误他们评估RAG时只看“最终回答与标准答案是否一致”完全不看“模型到底有没有利用检索文档”。结果模型的忠实性已经崩了完全在用内置知识硬答但因为内置知识还比较靠谱很多答案在事实上是对的所以评估分数一直很好看。等到换了垂直领域的知识库内置知识覆盖不了分数立刻断崖式下跌。这时候才意识到需要早在评测体系里把“是否利用检索文档”这个行为维度加进去。4.3 检索内容的事实性验证RAG场景里的事实性评估主要针对检索环节和知识库源头。核心要回答的问题是检索到的这些文档其内容本身是否与外部世界的事实一致这一步看起来简单实际操作中却往往最容易出问题。很多企业知识库长期没有更新或者录入时就带有错误信息RAG系统忠实地检索、忠实地引用最后输出一个忠实但不事实的答案。从用户角度答案当然是错的从评估角度问题却要记在知识库头上。因此成熟的RAG评估体系会把“RAG输出的事实验证”分成两个层次第一层是对比“模型答案”与“检索文档”的一致性这是忠实性评估第二层是对比“检索文档”与“外部权威知识源”的一致性这才是事实性评估。两层都过最终答案才真正可靠。这里要特别提醒的是不要假设知识库里的内容天然就是“事实”。尤其是在企业内部场景知识库内容往往来源于历史项目文档、个人经验总结、未经验证的网络资料其本身就需要被当作“待验证的输入”来对待。4.4 用户反馈信号的合理应用除了离线评估指标RAG应用的线上用户反馈也是幻觉评估的重要数据源。点赞、点踩、追问、复制行为这些信号虽然粗糙但在规模化场景下能帮助团队快速定位问题的分布范围。不过使用用户反馈时有个重要原则不要直接拿用户反馈来做“幻觉判定”。用户点踩可能因为答案错误也可能因为答案正确但没有解决他的实际需求、表达方式不好、或者他本来对答案就有预设期待。用户反馈更适合用来圈定排查范围而不是直接当作幻觉标签使用。真正精细的做法是用户点踩后系统自动把该条问答对加入待复核队列由更可靠的评估流程来确认问题性质——属于忠实性错误还是事实性错误然后再分类定向处理。5. 人工评估的落地操作一套可用于团队日常的评估SOP谈完了概念和指标下面说说怎么在团队里真正把人工评估跑起来。因为不管自动评估工具多发达在幻觉评估这个领域人工评估依然是金标准尤其是在盲点和争议样本的处理上更是不可或缺。经过我自己的多轮项目实践一套可复用的评估SOP已经在我手头沉淀成型可以按照以下框架执行。5.1 评测集构建覆盖典型场景的测验题人工评估的前提是有一批高质量的评测样本。最怕的就是团队“随便抽几条线上记录”就开始评样本量不够、覆盖不全、结论没有代表性评估结果根本不适合用来做决策。评测集的构建建议遵循以下几个原则这也是踩过坑之后才彻底想明白的覆盖业务的核心场景。如果产品有三大类典型用户问题评测集就要按比例覆盖这三类不能只集中在一类上。包含边界和疑难样本。要有一些故意设计的“陷阱问题”比如文档里没写但模型容易发挥的开放式问题、需要综合多篇文档才能回答的问题、文档本身存在矛盾的问题。保留“已知幻觉”样本。把历史发现的典型幻觉案例纳入评测集作为回归测试的锚点防止模型优化后旧问题复发。定期更新内容。评测集不是做一次就完事的知识库和模型在变评测集也需要跟着更新。评测集规模方面我自己的经验是作为日常回归100到200条足矣作为发布前全面评估500条以上更稳妥。再大就不好做人工审核了成本会变得难以承受。5.2 标注指南设计把“凭感觉判断”变成“按规则打分”人工幻觉评估最怕的是不同标注员之间口径不一致。同一个回答标注员A觉得“这个模型虽然没引用原文但意思是对的算忠实”标注员B觉得“没有引用原文就不算忠实”。如果标注规则不先定清楚最后统计出来的数据就是噪声毫无参考价值。所以评估SOP里最重要的部分不是打分表而是《标注指南》。一份好的标注指南需要做到以下几件事明确定义。用业务语言把“忠实”“不忠实”“事实正确”“事实错误”讲清楚并配上正例和反例。细化判断维度。每个维度都要有明确的打分标准比如事实性分成正确、部分正确、错误、未知/无法判断这几个档位的边界要清晰。提供边界案例。把最容易产生分歧的情况单独列出来逐条说明该怎么判。比如“文档里写了A但模型说成B算矛盾还是算未提及”这一类边界案例必须先达成团队共识。规定信息溯源方式。标注员在判断事实性时依据什么外部权威源是统一指定的数据源列表还是可以自行搜索这个不统一的话标注结果几乎没有可比性。5.3 双人标注与分歧仲裁流程即使有了标注指南单个标注员依然可能因为理解偏差或注意力不同出现错误。所以在大规模人工标注时建议采用双人标注加分歧仲裁的机制。具体操作流程可以这样设计每一条评测样本分配两位标注员独立标注标注完成后对结果进行对比。如果两人结论一致录入最终结果如果结论不一致进入仲裁环节。仲裁由更资深的评估负责人进行负责人除了做出最终判定还要记录分歧原因——因为分歧原因本身就是改进标注指南的重要素材。有人可能会问“双人标注成本不是翻倍了吗”是的成本确实会翻倍所以这个机制更适合用在基准数据集构建和模型版本发布前的正式评估阶段。日常快速回归可以用单人标注加抽检复核这个折中方案在效率和可靠性之间取得了比较好的平衡。5.4 评估结果的分析与回归人工评估做完之后要输出的不只是一张分数表更重要的是“问题归因”和“变化趋势”两个分析。问题归因是回答“出了幻觉错到底在哪个环节”。这需要把评估结果结合系统日志做关联分析检索到了哪些文档模型实际引用了哪些片段回答中哪些陈述超出了文档范围只有把这些问题逐条拆开才能真正定位到问题环节。这一步如果做得到位比任何一维分数都更有工程价值。变化趋势则用来判断模型迭代是“真的变好了”还是“拆东墙补西墙”。比如新版本模型的事实性分数提升了5%但忠实性分数下降了3%那这次迭代是否值得上线就需要业务方结合场景来权衡。这种有得有失的情况在模型迭代中极其常见只盯单一指标根本看不出来。6. 自动评估工具的能力边界AGREE、FActScore与LLM-as-a-Judge人工评估虽准但没法大规模复用。当评测集从几百条扩展到几千条、上万条或者需要每天跑回归的时候一定要引入自动评估工具。但自动评估工具不是万能的理解它们的工作机制和能力边界能让你避开不少坑。6.1 基于拆解与比对的评估框架目前比较成熟的自动幻觉评估框架基本都遵循同一个思路将生成文本拆解为原子事实陈述再通过与上下文的比对来判断这些陈述的可靠性。这类框架的代表包括RAGAS、FActScore、AGREE等。以FActScore为例它的工作方式是把长文本生成结果拆解成多个独立的事实陈述然后逐条与知识库或维基百科进行对照计算“事实支持率”。这个指标的优点是可以精确定位到具体错误的句子并给出“这句话是错在张冠李戴还是凭空捏造”的标签极大地提升了事实性评估的可解释性。AGREE这个框架则更适合RAG场景因为它评估的重点就是“回答与检索文档的一致性”问题而不是“回答与外部世界的一致性”。它的判断逻辑更接近于忠实性评估能有效识别模型有没有脱离检索内容自由发挥的情况。RAGAS则是一个更完整的RAG评估框架里面同时包含了忠实性、相关性等多个维度的评估维度方便团队直接在框架内完成整体评估。它的好处是不用你自己搭建流程开箱即用但相对的它给你自定义的空间就更少而自定义空间在很多时候恰恰是评估能不能贴合业务的关键。这类基于拆解比对的框架最大的问题是“拆解”这一步本身就依赖大模型来完成。如果拆解的模型能力不足拆分出的原子陈述动不动就有遗漏后续评估的准确度会直接受影响。所以使用这类框架时第一步要做的不是直接跑评测而是先抽样检查拆解结果是否靠谱。6.2 LLM作为评估者的局限与对策用LLM来评估LLM已经成了很多团队的首选方案。LLM-as-a-Judge的核心逻辑就是用一个能力更强的模型比如GPT-4级别的模型或专门微调的评估模型来给目标模型输出打分。这个方案的好处是自动化程度高、速度快、调起来灵活成本也远低于人工评估。但LLM-as-a-Judge并不是万能的它有几个在实际使用中才能感受到的问题评估偏差问题。大模型在打分时可能存在位置偏差更偏好出现在前面的答案、字数偏好更偏好更长的答案、自夸偏差更偏好自己的输出风格等问题。这些偏差如果不清除评估结果会带上隐性噪声。幻觉评估是“找错”而把“找错”交给也会出错的大模型本质上是在用一个不确定的系统去评估另一个不确定的系统。大模型评估“事实性”时同样会依赖它自己的内部知识来判断一旦输出内容超出了模型的知识范围它可能把错误的答案判成正确或者反过来。不是说要因此否定LLM-as-a-Judge这个方案而是说你要清楚它的能力边界。在我自己的实践中LLM-as-a-Judge更适合用作初筛和回归测试的辅助手段最终的裁决还是要依靠更可靠的人工评估和基于规则的硬校验。一个值得推荐的折中方案是“自动初筛人工复核”全部评测样本先用LLM打分把打分结果中“不同样本置信度较高”的判据作为参考然后人工重点复核那些低置信度、边界模糊的样本。这样既控制了成本又保证了关键样本的评估质量。6.3 自动评估的回归价值自动评估工具虽然在单条样本的准确率上达不到人工的水平但它在回归测试上的价值是人工无法替代的。每次模型更新、提示词调整、知识库变更后都可以用同一套评测集快速跑一遍自动评估对比各指标的变化判断改动是正向还是负向。要想让自动回归真正发挥价值这里有一条我的经验心得保持评测集和评估配置的稳定性至少要给自动评估设定一个固定版本。有些团队今天用这个关键词、明天用那个提示词模板导致同一批数据跑出来的结果完全不可比回归测试失去了意义。评估体系本身也值得像代码一样做版本管理每一次评估配置的变更都要被记录这样回看历史指标才有意义。7. 幻觉评估的九个坑每个我都替你踩过最后这部分我整理了一份评估实践中容易犯的错误清单。第一个坑是“不看分母”。只统计模型产生了多少错误陈述却不计算总陈述数量。比如模型老老实实回答了10个陈述错了一个和一个模型就回答了2个陈述错了一个这两个系统的幻觉概率完全不同。不做归一化处理的评估比不评估更糟。第二个坑是“重错轻漏”。只关注“说错了”的内容忽略“该说的没说”的情况。模型面对一个它没有掌握信息的问题如果可以安全地说明“这些信息我无法确认”其实是一种负责任的表现。在医疗、法律等高风险场景这种“不知道就承认”的行为比强行作答更值得保护。第三个坑是“忽略引用覆盖”。在RAG应用中关键陈述就要有引用支撑。如果一条回答没有任何引用来源用户无从验证幻觉风险实际上被放大了。但不少评估体系只检查答案内容本身正确与否完全不看引用情况这会让模型养成“裸答”的坏习惯。第四个坑是“不区分问题层级就盯着同一套指标死看”。开放式提问和闭卷式提问是两种不同场景评估重点完全不同。闭卷问题重点看事实性约束性较强的开放问题则要看忠实性和相关性。如果不用不同指标组合来衡量不同场景最终评估结果会是四不像。第五个坑是“不更新评测集”。模型升级了、知识库扩容了评测集还停留在三个月前的100条问题上。这种情况下跑出来的分数再好看对实际业务也没有多少参考价值。第六个坑是“直接套开源指标不校准业务语境”。学术界的评估指标设计面向的往往是通用场景到了具体业务里可能需要调整才能贴合实际。比如通用事实性指标中不计较一个错别字但在药品名称、产品编码这类强约束信息上一个字符的错误就可能是严重事故。指标的粒度和容错率都要按业务需求重新定义。第七个坑是“样本量太小还强行下结论”。拿二三十条测试样本的评估结果去给模型版本做最终判断这个统计置信度是完全不够的。如果暂时没有更多真实数据哪怕用人工构造的测试数据也好过没有但心里要清楚这些数据的代表性有限。第八个坑是“评估结果不出来就不跟业务对齐”。企业级LLM应用的评估应该是常态化机制不能只在发布前临时跑一次。幻觉问题会随知识库更新、用户问题分布变化而动态变化只有持续追踪才能尽早发现退化。第九个坑是“忽略了提示词/系统设定对幻觉的诱发效应”。有些幻觉是模型本身带的问题有些则是提示词设计在诱导它。比如系统设定里写着“你是无所不知的专家”模型自然倾向给出笃定的回答哪怕它并没有足够的信息支撑。这种因为交互设计导致的幻觉通过调整提示词就能显著改善但如果不把提示词纳入评估范围你会以为问题全出在模型上。在AI应用的评估领域业界一直流传着一句话大意是衡量一个系统靠什么指标往往比衡量系统本身的计算更诚实。这句话放在大模型幻觉评估上尤其贴切。忠实性和事实性两个维度分别对应了“说话的依据”和“内容的正误”它们经常纠缠在一起在真实的系统行为中并没有清晰的边界。但正因为纠缠才更需要我们在评估体系里把它们区分开来你才有机会看清一个所谓的“幻觉”到底是从哪个环节渗进来的。根据我个人的落地经验幻觉评估没有一招鲜的银弹方案。每个团队的知识库质量、用户群体、业务容忍度都不一样适合你们的评估体系必然是在实践中长出来的而不是照搬别人的模板就能直接用的。从认清忠实性与事实性的差异开始搭一套属于你自己的指标体系再定好人工评估的流程和自动工具的边界——这个体系构建起来后后续跟模型相关的每一次迭代和升级你都能用一个相对确定性的框架来审视它们到底带来了什么改变。