在AI内容生成日益普及的当下，“一本正经地胡说八道”已成为产品人必须直面的新问题。本文深度解析AI幻觉的成因与提示工程的优化路径，帮助内容从业者构建更可信、更可控的生成机制，推动AI协作从“能说”走向“说对”。

虽然我们现在面临的是AI时代的到来，但目前来说AI还并不能解决所有问题，例如AI会出现乱编乱造的现象，即AI幻觉。

因此，如何系统化地评估和改进AI应用，已成为行业的新共识，这一技能的重要性已被行业顶尖机构证实。Anthropic和OpenAI的首席产品官均指出，评估正成为产品构建者必须掌握的最重要的新技能。

一、什么是AI评估？

AI评估是一种系统化地衡量和改进AI应用程序的方法，其核心就是对大语言模型应用程序进行系统化审视数据，并创建自己所需的相关执行指标，以此来衡量AI应用程序当下的运作，不断协助整体迭代、实验和改进的一种人为干预。

简单来说，就是了解自己的AI应用有没有按照自己想要的方式去进行工作，例如，在与用户进行对话交互时，AI应用是否出现胡编乱造的答案，或者有没有去正确调用软件的相关功能来服务用户。

再比如，上面是一个房地产物业管理的AI助手，当一个用户询问了是否带有书房的房间，AI的回答是没有而且回答是“祝你有美好的一天”。

这种看似没问题，但如果产品目标是让AI积极协助开发潜在客户避免流失，那么很明显它并不符合我们想要的程序工作方式，因此，这也是需要进行AI评估的其中一种形式。

二、怎么构建评估？

那么，如何为自己的AI应用构建评估体系来解决幻觉等问题呢？其实并不需要特别高深的技术，核心是遵循一个从理解问题到自动化监控的流程。

第一步：错误分析

这个环节的目的就是助于我们初步了解自己的AI应用在实际运作中具体做错了什么。

这时只需要使用任何可观测性的工具，去查看大量的用户与AI的交互记录，像做定性研究一样，为每一条有问题的追踪记录写下简短的笔记，描述哪里出错了，术语上叫做开放式编码。

在这个过程可能会面对已经出现的大量AI与用户的交互日志，这时也无需追求从头开始，只要所见即所得将这些错误的交互日志记录下来即可。

不过在这些记录的笔记内容需要尽可能详细，而不是去笼统地写着执行错误。例如在一个公寓物业管理AI助手存在的问题时，那么记录内容如下：

1）由于文本消息，对话流程变得不稳定

2）AI未确认用户的信息的全部内容审核就转接给人工后台

3）AI在回复中向用户提到了不存在的虚拟导览服务

那么这个既然要自己亲手手动记录，在面对这么多的交互记录，要查看多少条合适？

这个就涉及到’理论饱和’这么一个概念，简单理解就是主要不再发现有新的类型错误内容出现时，那么就可以停止。

若非要一个数字参考的话，建议从100条开始。这个数字的意义在于破除起步的畏惧心理——你会发现，通常远未达到100条时，你就已经掌握了核心问题。

有些只要抽样20条都有可能发现存在的问题，这里倒是需要一点个人的专业直觉，直觉这块的话自然会随着自己可能记录了20条、40条、60条后然后就可以慢慢出来，所以在这块只要执行就是了。

别小看这部分看似麻烦和被大量数据给吓退，这是最有高回报的投资。若跳过错误分析直接写评估是在闭门造车。

最后关于在错误分析笔记分类这一块，这里会有一个常见的执行陷阱，为了避免团队在分类上陷入无休止的争论，这完全是没必要的。

这里只需指定一位对应领域专家，即懂行懂业务的人员或团队产品经理来负责初期的错误分类。这能极大地提高效率，也可以防止评估过程变得昂贵而无法执行。

第二步：归类与量化

这一步的核心就是将散乱的错误笔记归纳、聚类成几个高级别的失败模式类别，术语叫轴向编码。

因为这时候我们可能已经有了上百条错误的内容记录或以上，这时候我们可以使用ChatGPT或Claude将这些上面记录的笔记进行整合归类，让AI帮助我们进行轴向编码，例如让其归纳出3-5个核心失败模式类型。

虽然这个步骤可以获得Ai的协助，但是仍然不要完全相信AI的分类结果，还要再亲自审查这些AI工具的分类结果，目的使其更具体、更可操作，例如可以人工手动额外增加一个“以上都不是”的选项来捕捉未被覆盖的新问题。

最后一个就是分类量化的问题，毕竟我们的问题分类总有排行的，那么使用数据透视表等简单工具，统计每种失败模式出现的频率。

所以，我们就可以从数据中得到了一个清晰的“问题排行榜”，然后进行重点优先选择处理的问题对象。

完成这一步后，就可以对我们的AI应用有个基本的了解，这也能帮我们避免不必要的评估工作。

例如一些输出格式的错误，可能只是开发人员忘记了在系统提示词里面说明规则，这种只要直接修改提示词即可修复，而无需编写复杂的评估代码。

这也是为什么评估前需要进行上面的两个环节，而不是一上来就进入评估阶段。

第三步：构建自动化评估器

好的，假如我们现在已经在一个公寓物业管理AI助手里面的日志已经完成错误分析和问题归类后，我们会发现有些问题的判定非常主观。

例如这个关于移交的问题处理，其判定涉及复杂的语义理解和主观判断，不适合用简单的代码规则解决，同时也没有一个显而易见的提示词修改方案。

这时，我们就需要构建一种更复杂的自动化评估器，即让另一个AI大语言模型来充当评判者，根据当前的语义自动判断前面的AI的表现是否合格，也就是让AI监控AI。

这种方法的核心优势在于规模化。一旦构建成功，我们就可以让它自动运行在成千上万的用户交互数据上，从而持续、高效地监控特定问题的发生频率，无需再人工逐一审查。

不过，也不能绝对相信这评判者，也就是第二个AI。在投入使用前，我们必须对其可靠性进行验证。

具体方法就是在一个已经由人类标注好的样本数据集上运行该评估器，然后通过混淆矩阵 来分析其判断与人类判断的一致性。

通过反复迭代和优化给评判者的提示词，来校准其判断标准，直到它与人类的判断达成高度一致。

最终，这个经过验证的、可靠的评估器就可以部署到生产环境中，对真实的用户交互数据进行在线监控，实现日度或周度的产品质量跟踪，让我们能快速发现并响应产品中的问题。

三、关于“评估”争论

当前网络上对“评估”的反对声音，主要源于两种普遍的误解：一是对评估范畴的狭隘化理解，二是曾被不成熟的评估方法所伤害。

首先，最常见的误解是将“评估”简单等同于“单元测试”。实际上，二者有本质区别。评估是衡量AI沟通质量的一整套方法论体系，而单元测试只是其中用于验证确定性功能的一种工具。

单元测试适用于检查那些“非黑即白”的要求，例如“是否调用了正确的功能”或“输出是否为标准JSON格式”；

而大模型应用本质上是随机且面向开放领域的，评估的真正价值在于应对不确定性，例如：处理模糊的用户意图、适应未知的数据分布、以及评判整体的对话流畅度与有用性。

其次，许多反对声音来自于被错误实践伤害的经历。例如，使用模糊的Likert量表（如1-7分）让大模型进行评分，其结果往往难以解释且不可靠，这直接导致团队对“评估”本身失去信任。然而，这并非是评估本身的失败，而是具体执行方式的错误。

事实上，一个被广泛忽视的真相是：所有成功的AI产品背后，都在进行着严格且系统化的评估。

无论是像OpenAI、Anthropic这样的顶级实验室通过内部工具进行的大规模测试，还是产品团队通过数据分析进行的持续监控，评估都是他们迭代和保证产品质量的基石。公开场合下“我们只靠直觉”的言论，往往掩盖了其内部严密的数据驱动文化。

写在最后

当然，关于AI评估存在其他诸多细节，例如成本优化、自定义工具开发等探索，本文仅呈现的是关于AI评估的核心框架。

所以，当我们进行AI评估时，目标是改进我们的AI产品，而非拥有完美的评估技巧，评估只是手段，而不是目的。如果发现一个明显的问题能立即修复，那就直接去修复它就行了。

另一个点就是AI评估也可以让产品开发者从依靠感觉检查到数据驱动行为方式发生改变。

不过在错误分析和构建模型作为评判者的时候，人类的领域知识和产品直觉是关键，这点目前这部分来说，又发现了AI暂时还未能替代的活干，对不？