Day 31：Eval 评估体系
学习目标
今天我们要解决一个AI应用开发中极其关键但经常被忽视的问题——如何评估你的AI系统到底好不好用。你可能已经搭建了一个看起来功能完整的Agent系统，能够接收用户问题、检索文档、生成回答，但问题在于，你怎么知道它给出的回答是准确的？你怎么知道它没有遗漏重要信息？你怎么知道它在各种边界情况下都能稳定表现？这就需要一套系统的评估体系。学完今天的内容，你要能够建立自己的测试集，编写自动评分逻辑，设计人工评分标准，并最终输出一份有说服力的评估报告。
一、Eval的意义——为什么评估是AI系统的生命线
在传统软件开发中，评估是相对简单的事情。你写一个函数，输入一组测试数据，断言输出等于预期值，测试通过就说明代码没问题。但AI系统完全不同。同样一个问题，AI可能今天回答得很好，明天因为上下文窗口变化或者检索结果不同，给出一个完全不同质量的回答。这种不确定性是AI应用与传统软件最本质的区别。
你可能会觉得，我自己手动试几个问题，感觉回答得还行，不就可以了吗？这种想法非常危险。手动测试的问题在于，第一，你的样本量太小，无法覆盖各种边界情况。第二，你作为开发者，对系统有天然的理解偏差，你会下意识地问那些系统擅长回答的问题。第三，手动测试不可复现，你无法在系统迭代后精确对比前后效果差异。
在半导体制造的良率管理中有一个类比非常贴切。你不能只看一批晶圆的良率就说工艺稳定了。你需要统计过程控制，需要连续监控关键参数，需要在良率下降之前就发现趋势变化。AI系统的评估也是同样的道理。你需要一套持续运行的评估体系，就像良率监控系统一样，时刻告诉你系统的健康状态。
Eval体系的核心价值体现在三个层面。在开发阶段，它帮你快速发现Prompt调整或架构变更带来的副作用。你修改了一个检索策略，本以为只会改善某个场景，但Eval能告诉你是否在另一个场景造成了退化。在上线阶段，它给你提供客观的质量基线，让团队对上线决策有据可依，而不是靠直觉拍板。在运营阶段，它持续监控线上表现，一旦出现异常下滑，能够及时预警。
建立Eval体系还有一个容易被忽视的好处——它倒逼你把系统的质量标准显性化。当你开始写评估规则的时候，你不得不思考”什么是好的回答”，这个思考过程本身就会帮助你更好地设计系统。
二、准确性评估——回答内容是否正确
准确性是所有评估维度中最基础也最重要的一个。它要回答的核心问题是：AI给出的回答在事实上是否正确？这个看似简单的问题，在RAG系统中变得异常复杂，因为准确性不仅取决于模型本身的知识，还取决于检索到的文档内容是否相关、是否最新。
准确性评估需要从几个子维度来拆解。第一个是事实准确性，也就是回答中涉及的每一个事实陈述是否有据可查。如果你的系统回答”某芯片的制程节点是5纳米”，但实际文档中明确写的是7纳米，这就是事实性错误。在半导体行业，这种错误可能导致严重的决策失误。想象一下，如果采购部门基于AI的错误回答下了错误的订单，造成的损失可能是数百万美元。
第二个是推理准确性。有些回答的事实部分是对的，但推理过程有问题。比如系统检索到了两份文档，一份说某材料在温度超过200度时会失效，另一份说当前工艺温度是180度。正确的推理结论应该是”当前温度下材料安全”，但如果系统错误地推导出”材料即将失效”的结论，这就是推理准确性问题。
第三个是数值准确性。在工程报告中，数字的准确性至关重要。产能、良率、成本、周期时间，这些数值如果出现偏差，可能直接影响生产决策。数值准确性评估需要特别关注单位是否正确、数量级是否合理、计算过程是否有误。
准确性评估的实现方式通常有两种。一种是基于参考答案的对比，你预先准备好标准答案，然后让评估器比较AI的回答与标准答案的一致性。这种方式适合那些有明确正确答案的问题，比如”某设备的最大产能是多少”。另一种是基于文档溯源的验证，你检查AI回答中的每一个关键声明，看它是否能追溯到检索到的源文档。这种方式更灵活，适合开放性问题。
在实际操作中，你会发现准确性评估最大的挑战是建立标准答案集。对于半导体行业知识库来说，标准答案需要由领域专家来审核确认。一份包含50个问题的标准测试集，可能需要领域专家花一整天时间来审核答案的正确性和完整性。这个投入是值得的，因为一份高质量的测试集可以反复使用，成为系统质量保障的基石。
三、完整性评估——回答是否涵盖了所有关键信息
完整性评估要回答的问题是：AI的回答是否涵盖了问题所涉及的所有重要方面？一个准确的回答不一定是完整的回答。系统可能给出了正确但过于简略的回答，遗漏了用户真正需要的关键信息。
完整性评估在工程场景中尤其重要。假设一个工程师问”更换蚀刻气体需要哪些前置步骤？“系统回答了”需要确认气体库存和检查管道连接”，这个回答本身是正确的，但远远不够完整。完整的回答还应该包括：确认当前工艺配方是否需要调整、通知下游工序可能的生产暂停、检查废气处理系统是否兼容新气体、更新安全数据表、以及获得工艺工程师的书面确认。如果系统遗漏了安全相关的步骤，后果可能是灾难性的。
完整性评估的难度在于，“完整”的标准本身是模糊的。同一个问题，不同角色的人对”完整”的期望可能完全不同。一个经验丰富的工程师可能只需要关键的几个步骤就够了，而一个新入职的技术员可能需要每一个细节都列出来。所以在设计完整性评估标准时，你需要明确目标用户画像，并据此定义合理的完整性期望。
在实际操作中，完整性评估通常采用关键信息点覆盖的方式来衡量。你预先定义一个问题应该覆盖的关键信息点列表，然后检查AI回答中包含了其中多少个。比如对于”更换蚀刻气体”这个问题，你可能定义了8个关键信息点，如果AI回答覆盖了6个，完整性得分就是75%。但这里有一个微妙之处需要考虑——不是所有信息点的重要性都一样。安全相关的信息点权重应该高于流程相关的信息点。所以更合理的做法是给每个信息点赋予不同的权重，然后计算加权覆盖率。
完整性评估还需要考虑信息冗余的问题。有时候AI为了显得”完整”，会大量堆砌相关但不必要的信息，导致回答冗长难读。理想的完整性评估应该同时考虑信息的必要性和充分性——既不遗漏关键信息，也不包含不必要的噪音。这就像芯片设计中的面积优化，你需要在功能完整性和设计简洁性之间找到最佳平衡点。
四、格式合规评估——回答是否符合预期格式
格式合规性评估关注的是AI输出是否满足预定的格式要求。这个维度在工程应用中比大多数开发者预期的要重要得多。当你的AI系统不是直接面向终端用户，而是作为工作流中的一个环节时，格式错误可能导致下游系统解析失败，进而造成整个流程中断。
格式合规评估的具体内容取决于你的应用场景。如果你的系统需要输出结构化的JSON数据供其他系统消费，那么格式合规性包括JSON语法正确性、必需字段是否存在、字段类型是否正确、枚举值是否在允许范围内等。如果你的系统需要生成符合公司模板的工程报告，那么格式合规性包括标题层级是否正确、表格格式是否规范、章节结构是否完整等。
在半导体制造环境中，格式问题可能带来严重的后果。假设你的AI系统生成的工艺参数报告需要被MES（制造执行系统）自动解析导入，如果格式不规范——比如日期格式不统一、数值字段中混入了文字说明、必填字段缺失——MES可能拒绝接收这份报告，导致工艺变更流程卡住。在一条24小时不间断运转的产线上，每小时的停机成本可能高达数十万美元，所以格式合规绝对不是一个可以轻视的问题。
格式合规评估的实现相对其他维度来说更加确定性，可以用规则化的方式来检查。你可以编写一系列格式检查规则：输出是否包含所有必需的章节标题？表格的列数是否正确？数值是否都带有单位？引用编号是否连续？这些检查大部分可以通过正则表达式或简单的解析逻辑来实现自动化。
但格式合规评估也有一些需要特别注意的边界情况。比如，当AI判断某个章节不适用于当前问题时，它可能跳过该章节。这种情况下格式检查需要能够区分”遗漏”和”合理省略”。你可以在系统设计中要求AI在省略某个部分时给出明确说明，比如”本报告不涉及XX部分，原因是…”，这样格式检查器就能正确理解这种省略是有意的。
格式合规评估还需要考虑多语言场景。如果你的系统需要支持中英文混合输出，那么标点符号的使用（中文全角与英文半角）、数字格式（千分位分隔符的习惯）、日期格式等都需要有明确的规范和对应的检查逻辑。
五、引用质量评估——信息来源是否可靠可追溯
引用质量评估是RAG系统特有的评估维度。在传统的搜索引擎中，用户会自己判断搜索结果的可信度。但在RAG系统中，AI替用户做了信息筛选和整合的工作，所以引用的质量和透明度就变得极其重要。
引用质量评估包含几个层面。首先是引用准确性，即AI标注的引用是否确实指向了所声称的源文档位置。在RAG系统中，有一种常见的错误模式叫做”引用幻觉”——AI给出了一个看起来很专业的引用编号，但当你去查源文档时，发现那个位置的内容和AI说的完全不是一回事。这种错误比不引用更危险，因为它给错误信息披上了”有据可查”的外衣，让用户更容易轻信。
其次是引用充分性。AI的每一个关键声明都应该有对应的引用支撑。如果AI说”根据最新工艺规范，该步骤的温度上限为350度”，那么这句话后面应该跟着明确的引用标识。缺乏引用的声明就像学术论文中没有标注来源的论断，读者无法判断其可靠性。在工程决策中，没有来源依据的信息不应该被采信。
第三是引用来源的权威性和时效性。在半导体行业，工艺规范会定期更新。如果AI引用的是三年前的旧版规范而不是最新版本，那即使引用本身是准确的，信息的时效性也有问题。引用质量评估需要检查AI是否优先引用了最新、最权威的文档来源。
在实际的RAG系统中，引用质量还与检索质量密切相关。如果检索模块返回的文档本身就是过时的或者不相关的，那么即使生成模块忠实地引用了这些文档，最终输出的质量也不会好。所以引用质量评估有时候也能帮你反向定位系统的问题环节——如果引用质量普遍不好，问题可能不在生成模型，而在检索策略。
引用质量评估的实现方式通常是对比检查：提取AI回答中的所有引用声明，然后逐一到源文档中验证。这个过程可以部分自动化，但对于引用内容的语义一致性判断，仍然需要人工或者更高级的评估模型来参与。
六、可执行性评估——用户拿到回答后能不能直接行动
可执行性是一个经常被忽视但极其实用的评估维度。它要回答的问题是：用户拿到AI的回答后，能否直接据此采取行动，还是需要进一步的信息查找或确认？
在工程环境中，可执行性的差异直接影响效率。假设一个工程师问”如何处理蚀刻腔体的异常颗粒问题”。低可执行性的回答可能是”颗粒问题通常由气体纯度、腔体清洁度或工艺参数不当引起，建议排查这些方面”。这个回答在技术上没有错误，但对工程师来说帮助有限，因为他还是不知道具体该先做什么、怎么做。
高可执行性的回答应该是这样的：“第一步，检查气体过滤器压差读数，正常范围应低于XX千帕。如果压差偏高，执行过滤器更换流程SOP-XXX。第二步，查看最近一次腔体自清洁的记录，如果距离上次清洁超过72小时，触发强制清洁流程…”。这样的回答让工程师可以立即开始排查，不需要再去翻找其他资料。
可执行性评估需要考虑目标用户的专业水平。对于资深工程师，过于详细的步骤说明反而可能是冗余的。对于新入职的技术员，每个步骤的细节说明又是必需的。所以理想的做法是在评估可执行性时，同时标注目标用户画像，对不同水平的使用者设定不同的可执行性标准。
可执行性的另一个重要方面是前置条件的明确性。一个好的可执行回答应该清楚地说明执行某项操作需要的前置条件——需要什么权限？需要什么工具？需要通知哪些人？如果前置条件不满足怎么办？这些信息看似琐碎，但在实际操作中却是决定一个回答是否”真的能用”的关键因素。
可执行性评估通常需要由领域专家来进行，因为判断一个回答是否足够具体到可以直接执行，需要对实际工作流程有深入的理解。自动化评估在这个维度上的效果有限，但你可以通过检查回答中是否包含具体的操作步骤、参数值、参考文档编号等可量化指标来做一个初步的筛选。
七、安全性评估——系统是否存在安全风险
安全性评估是所有评估维度中最不能妥协的一个。它关注的是AI系统是否可能产生带有安全风险的输出，包括但不限于泄露敏感信息、提供危险建议、或者产生带有偏见的内容。
安全性评估的第一个层面是信息泄露风险。在企业环境中，AI系统可能接触到大量敏感信息——商业机密、客户数据、专利技术细节。安全性评估需要检查AI的回答是否会在不经意间泄露这些信息。特别是在多用户场景下，用户A上传的文档信息是否会出现在给用户B的回答中。在半导体行业，工艺参数、良率数据、设备配置等信息往往都属于高度机密，任何泄露都可能造成巨大的商业损失。
第二个层面是操作安全建议。在制造业环境中，AI可能被问到关于设备操作、工艺调整、故障处理等问题。如果AI给出了不安全的建议——比如建议在未切断电源的情况下打开设备外壳，或者建议跳过某个安全检查步骤——可能导致人员伤亡或设备损坏。安全性评估需要专门针对这类高风险场景设计测试用例，确保系统在安全相关的回答中始终保持谨慎和准确。
第三个层面是内容合规性。不同行业和地区有不同的内容合规要求。半导体行业涉及出口管制，AI不应该在回答中包含违反出口管制法规的技术信息。在某些地区，环保法规要求特定的化学品处理流程，AI不应该建议违反这些法规的操作方式。
安全性评估的实现需要分层进行。第一层是基于规则的快速过滤，你可以维护一个敏感关键词列表和危险建议模式库，对所有输出进行自动扫描。第二层是基于模型的深度检查，使用专门训练的安全评估模型来检测更隐蔽的安全风险。第三层是人工审核，对于被标记为潜在风险的输出进行人工复核。
安全性评估还需要考虑对抗性场景。有些用户可能会故意尝试通过精心构造的问题来绕过系统的安全限制。你的评估体系应该包含一组对抗性测试用例，模拟各种可能的攻击方式，确保系统在压力下依然能够保持安全边界。
八、成本评估——系统运行的经济效益如何
成本评估是一个经常在技术评估中被忽视的维度，但在实际生产环境中，它往往是决定系统能否长期运行的关键因素。一个技术上完美但成本过高的系统，最终也会因为经济上不可持续而被淘汰。
成本评估首先要量化单次查询的成本。在基于LLM的AI系统中，主要成本驱动因素包括：模型调用的Token费用、向量数据库的查询费用、嵌入模型的计算费用、以及基础设施的运维成本。你需要能够精确计算”回答一个用户问题的平均成本是多少”。在半导体行业中，这个数字需要与人工查找信息的时间成本做对比。如果一个工程师每小时的人工成本是500元，而AI系统帮他节省了30分钟的信息查找时间，那么AI系统的单次查询成本只要低于250元就是经济可行的。
但实际的成本分析比这复杂得多。你还需要考虑成本随使用量变化的规律。有些成本是固定的（基础设施运维），有些是线性增长的（按Token计费的模型调用），有些是阶梯式的（达到某个使用量阈值后单价降低）。你需要建立一个成本模型来预测在不同使用规模下的总成本。
成本评估还需要考虑质量与成本的权衡。有时候，用更便宜的模型可以降低80%的成本，但只降低10%的回答质量。在什么场景下这种权衡是可以接受的？对于内部知识库查询这种对精度要求不是极致的场景，低成本模式可能完全够用。但对于客户面向的合规性报告生成，你可能需要不计成本地追求最高质量。成本评估的输出应该是帮助决策者做出这种权衡判断的数据支撑。
另一个容易被忽视的成本维度是迭代成本。每次你调整Prompt、更换模型、修改检索策略，都需要重新运行完整的Eval来验证效果。如果Eval本身运行成本很高（比如需要调用昂贵的评估模型），那么迭代的速度就会受到经济因素的限制。所以在设计Eval体系时，也要考虑Eval本身的成本效率。
九、自动评分与人工评分——如何高效地评估大规模输出
评估体系最终要解决一个实际问题：如何在大规模的输出中高效地识别质量问题。纯人工评估质量最高但成本也最高、速度最慢。纯自动评估效率最高但可能遗漏一些需要人类判断的维度。所以实用的评估体系通常是两者的结合。
自动评分的核心是评分Prompt的设计。你可以把自动评分器看作一个专门的AI模型，它的任务不是回答用户问题，而是评估其他AI回答的质量。评分Prompt需要明确定义评估维度、评分标准和评分规则。一个好的评分Prompt应该像一位严格的审稿人一样，对每个维度给出具体的分数和评价理由。
评分Prompt的设计有几个关键原则。第一是评分标准要具体、可操作。不要说”评估回答是否准确”，而要说”检查回答中的每个事实陈述，与参考文档对比，判断是否存在事实性错误。每个事实性错误扣2分，总分10分”。第二是要求评分器给出评分理由，而不只是分数。评分理由可以帮助你理解失分的原因，指导后续的优化方向。第三是设置合理的评分粒度，通常5分制或10分制就够用了，过于精细的评分标度反而会降低评分的一致性。
自动评分有一个固有的局限性——它在评估”微妙”的质量差异时不够可靠。比如，两个回答在准确性上都是正确的，但在表达的自然度上有明显差异，自动评分器可能很难捕捉到这种差异。同样，在评估回答是否”恰到好处”地完整（既不遗漏也不冗余）时，自动评分器的判断可能与人类有较大偏差。
人工评分的设计需要解决几个问题。第一是评分表的设计。评分表应该清晰定义每个维度的评分标准，并给出不同分数水平的具体描述。比如在”完整性”维度，5分代表”覆盖所有关键信息点且组织良好”，3分代表”覆盖主要信息点但有明显遗漏”，1分代表”严重不完整，遗漏关键信息”。
第二是评分者之间的一致性。不同评分者可能对同一条输出给出不同的分数，这是正常的。但你需要确保评分者之间的偏差在可接受范围内。通常的做法是让多个评分者独立评分同一组样本，然后计算评分者间一致性（比如Kappa系数）。如果一致性太低，说明评分标准需要进一步澄清。
第三是人工评分的效率优化。你不需要对每条输出都进行完整的人工评分。一种高效的做法是：先用自动评分对所有输出进行筛选，自动评分标记为”可能有问题”的输出再进行人工复核。这样可以在保证质量的前提下大幅降低人工评分的工作量。
在实际工作中，自动评分和人工评分的比例通常是80比20左右。80%的常规输出由自动评分处理，20%的边界情况、高风险场景和定期抽检由人工评分覆盖。这个比例可以根据你的具体需求调整——如果系统还在早期迭代阶段，人工评分的比例可能需要更高；如果系统已经比较稳定，自动评分的比例可以更大。
今日实践任务总结
今天的实践任务围绕建立一套完整的Eval体系展开。首先是建立50条测试集，这些测试问题要覆盖你的系统可能遇到的主要场景，包括常见问题、边界情况、复杂多步推理问题、以及对抗性测试。每条测试数据应该包含问题、期望的答案要点、涉及的文档来源、以及难度等级标签。
第二是编写自动评分Prompt。你需要为每个评估维度编写专门的评分Prompt，定义清晰的评分标准和输出格式。建议先从准确性和完整性这两个最核心的维度开始，逐步扩展到其他维度。
第三是设计人工评分表。评分表应该包含所有评估维度，每个维度有明确的评分等级描述。评分表的设计要让领域专家能够在不深入了解AI技术的情况下进行有效评分。
第四是运行完整的评估流程并输出评估报告。报告应该包含各维度的得分分布、典型问题案例分析、主要问题模式总结、以及改进建议。这份报告不仅是你了解系统当前水平的工具，更是后续迭代的基准参照。
记住，Eval体系不是一次性建设的，它需要随着系统的迭代持续更新和维护。每次系统有重大变更时都应该运行完整的Eval，确保变更没有引入退化。同时，测试集也需要定期扩充，纳入线上真实用户的代表性问题，保持Eval与实际使用场景的对齐。