尽管基础模型已有改进，但真正推动其可靠投入生产的，是严谨规范的评估实践。
精心设计的评估能帮助产品经理、AI 治理负责人和 CTO 安全、规模化地部署 AI 智能体，使 AI 从孤立的试验工具转化为竞争优势。
这种信心来自根据真实用户查询、边缘案例和反映实际业务环境的特定领域场景评估 AI 智能体的行为，而不是依赖某项公共基准声称“这个模型最好”。
目标是用可衡量的结果证明这种信心有据可依。成功意味着以具体、可衡量的方式定义何为“良好”，并与业务需求和风险承受能力保持一致，无论关注的是事实准确性、语气得当、速度还是成本效益。
将评估嵌入整个系统（插桩、日志记录、A/B 测试和护栏），并兼顾严谨性与效率，团队便能更快、更稳健地部署。
大多数企业都能接受员工试用 ChatGPT 或 Gemini。但在高风险工作流或场景中实际采用 LLM 的情况仍不普遍。
这通常有充分理由：质量表现不一致，而幻觉或不当行为的风险超过了该技术可能带来的收益。
过去一年，这种风险与回报的平衡已发生显著变化。其中一部分可归因于基础模型性能提升，但很大程度上也得益于评估（即“eval”）日益规范。评估让我们及客户有信心在数周内部署大规模、面向客户的智能体。
本指南将介绍评估的基础要素，以及如何针对生产用例设计、实施和运行评估。
评估的目的不是寻找完美模型，而是建立有理有据的信心，确认模型行为符合业务需求、用户预期和组织的风险承受能力。
任何评估策略都始于一个简单的问题：怎样才算“良好”？答案应当具体明确。对某个组织而言，“良好”可能意味着事实准确性严格达标；对另一个组织而言，则可能更看重速度、成本效益或独特的表达风格。从可使用的数据到适用的监管义务，运营中面临的每项约束都会影响这一定义。
关键在于，“良好”必须由真正可衡量的要素构成。如果成功意味着提供有用的财务指导，那么“有用”就需要体现为具体属性：事实正确、免责声明得当、推理个性化且边界安全。以可衡量的方式定义“良好”后，下一个问题便是如何分析和解读结果。只有根据这些结果采取行动，评估才能成为一种方法，而不只是主观判断。
每条评估管线都建立在三个相互关联的支柱之上：
输入/基准：使用具有代表性的现实示例评估通用性能，并以精心整理的内部数据集检验领域适用性。
模型行为：模型的调用方式（检索增强生成、摘要、结构化信息检索、工具使用）。
指标：衡量和解读性能的方式。
输入必须能代表系统在现实中将遇到的情况。最有价值的洞见来自真实示例，例如客户查询、财务场景或行业特定案例。只有用这些示例进行测试，才能了解模型是否真正理解用户所需的细微差别，并满足业务需求。
模型的行为与模型本身同样重要，包括如何向其提供提示、如何编排检索或工具使用，以及如何传入上下文。两个完全相同的模型可能因部署方式不同而表现迥异。因此，评估设计必须涵盖这一层。
最后是指标。数字本身很少能说明全貌，但合理选择的指标可以让系统行为变得可解读。延迟、准确性、安全性、连贯性、偏差、成本和用户满意度共同构成生产系统的多维画像。关键在于选择与项目或业务 KPI 一致、并能揭示用户最重视特质的指标。较简单的指标通常更准确、成本更低，而不当的指标选择可能误导团队。选择指标时可从以下角度考虑：
合理的指标选择示例：
客服聊天机器人：首次联系解决率（用户的问题是否在无需升级处理的情况下解决？）、平均处理时间、用户满意度评分、升级至人工智能体的比例
金融研究工具：引用准确率（有适当来源支持的陈述占比）、依据真实标准验证的事实精确度、检索相关性（是否找到正确文档？）、由领域专家评分的推理连贯性
代码生成助手：语法正确性、测试通过率、安全漏洞数量、得到可用解决方案所需时间
不当的指标选择示例：
仅以回复长度作为质量的替代指标（越长不等于越好）
只衡量速度，不考虑准确性方面的取舍
跟踪模型置信度分数，却不根据实际正确性进行验证
仅依赖模型内部困惑度，不进行面向用户的验证
应避免的常见指标陷阱：
指标冲突：同时优化速度和全面性，却忽视两者之间的取舍
对基准过拟合：测试集得分达到 95%，但由于真实用户的行为不同，系统在生产环境中仍会失效
对一家受到严格监管的金融服务客户而言，其深度研究解决方案的准确性至关重要。我们结合专家编制的问答数据集与工具生成的数据集，从而评估精确度，以及系统选择正确工具和检索正确信息的能力，全面考察准确性与推理质量。关键是衡量多个维度：事实准确性（专家验证）、检索质量（相关文档的精确率/召回率）和推理连贯性（对逻辑流程的结构化评估）。
何时使用 LLM 充当评审来评估细致的质量维度
LLM 评审使用另一个 AI 模型进行评估，以减少人工审核，换取可扩展的自动化质量评分。当更简单的指标足以达到所需准确性时，LLM 评审往往会被滥用。当确定性检查无法衡量质量时，它会很有用。例如，指标涉及语义层面（有用性、有据性、推理质量、语气、政策解读），无法进行确定性评分。您可能需要针对众多提示/模型变体获取可扩展的反馈，并定义清晰的评分标准和结构化输出模式。要让它发挥作用，请遵循以下步骤：
明确定义评分标准的各个维度：正确性、有据性、政策合规性、可操作性和语气。
评审回复采用结构化输出（JSON 模式）。
同时记录二元门控分数和诊断文本，以便分析故障。
每个发布周期都要用人工标注样本校准评审输出。
在高风险领域采用双评审或定期共识检查。
持续跟踪评审漂移和意见分歧率。
基准数据集是一组固定、精心整理且答案已知的测试示例，用于以一致方式评估模型，并公平比较不同版本的结果。它通常包括输入（如用户查询）、预期输出或参考判断，以及用于评分的评估标准/标签。公共基准测试用于比较前沿模型的性能。在设计系统之初，可参考其结果来判断哪些模型可能适合采用。
但对于自己的系统，不能用这些基准替代业务环境中的性能评估，因为它们存在一些已知问题：
污染：模型可能已使用基准数据训练；再用同一数据集评估，就像拿着答案参加考试。
饱和：顶尖模型的分数均已接近上限，因此性能升降仅有几个百分点，而且通常处于测试结果的自然波动范围内。
范围狭窄：基准数据经过高度筛选和清理，无法反映您的实际任务。有些数据甚至由 LLM 生成，无法体现实际数据中的复杂性和边缘案例（错别字、罕见表达、噪声图像）。
学生请求应用帮助解决数学应用题。
可采用的公共基准示例：GSM8K（小学数学推理）
可选的更高难度数据集：MATH。
该基准的用途：
快速比较哪个模型更擅长通用数学推理，
在投入全面的产品评估前进行有效的初步筛选。
为何仍需自有数据集：
您的应用有一些 GSM8K 未涵盖的要求：
课程使用的措辞和主题顺序，
适合目标年龄段的讲解风格，
如何处理含义模糊或错别字很多的学生问题，
政策规则（如何时提供提示、何时给出完整答案）。
有效验证的关键在于创建应用专属评估基准。这些数据集应来自真实交互、典型边缘案例和可能出现的故障模式。实施新产品或新流程时，这可能是一项艰巨任务。不过，大多数情况下都能从现有产品中收集数据，或尽早开始收集，哪怕是在初始测试阶段。应用开发完成后，这些基准应随产品一起演进，逐渐变得更丰富、更具代表性。
案例研究：为零售银行助手构建自定义基准
银行聊天机器人负责回答有关预算、支出和交易的问题。公共问答基准/文本转 SQL 测试无法涵盖 SQL 注入、数据泄露或多轮上下文延续等核心银行风险。我们构建了一个能够反映该产品智能体管线的自定义基准。
此代码库中的自定义基准组件：
恶意提示红队测试套件，涵盖 SQL 注入、PII 提取、提示覆盖和跨会话泄露
安全问题零容忍：必须拒绝任何 SQL 注入、PII 提取或跨会话泄露企图。
上下文延续准确性：改写后的查询必须保留用户意图和实体。
要点：将基准构建视为一项产品功能。当前执行框架证明端到端评估已接通，但必须扩大覆盖范围和样本量，才能反映真实的银行风险（多意图攻击、绕过护栏和依赖上下文的查询）。基准应随新智能体和护栏一起扩展。
应用专属基准与模型选择之间的关联至关重要。基准不仅能揭示解决方案是否有效，还能确定哪种模型规模与后训练技术组合可用最高的成本效益实现所需性能。预训练模型最显著的改进（ChatGPT 中的“PT”）并非来自重新训练，而是“后训练”方法。
这些方法侧重于调整模型可访问的信息、信息的组织方式，以及在推理时引导和编排模型的方式。后训练技术包括：
思维链提示和动态算力分配（遇到较难问题时进行更多思考）
自洽性：生成多个输出并从中选择最佳结果
上下文构建与编排，例如检索增强生成（RAG）、少样本示例和智能体工作流
工具使用和外部知识访问，使模型能够执行超越其内部参数的操作
知识表示与存储策略，旨在高效检索结构化和非结构化数据并对其进行推理
这些后训练技术虽能显著提升系统性能，但也会带来取舍。每增加一层编排、检索或推理，都会提高系统复杂度、推理时间和运营成本。不过，合理组合后训练技术，通常可以使用更小、更快、更便宜的模型，同时仍满足性能要求。无需扩大模型规模，而是通过优化系统设计来提升性能。
这种平衡因应用而异，应依靠应用专属评估确定最佳技术组合。这些评估可帮助您找出增加编排不再带来显著收益的临界点，让团队选择达到目标性能所需的最低后训练复杂度。
AI 解决方案必须被视为一个完整系统，包括数据库、API、用户界面、编排层、监控基础设施等。因此，评估必须覆盖整个技术栈。应监控系统的关键部分，以掌握潜在问题并负责任地加快推进。
监控系统关键部分意味着：
为管线插桩，以获取可衡量的结果。
记录试验，以了解每次调整造成的影响。
部署重大变更前，先通过简单的 A/B 对比测试潜在回归。
数据驱动的迭代既能避免盲区，也能缩短从原型到生产的路径。日志记录和监控对于了解应用的实际使用情况同样重要。以下是确保可观测性的示例：
第 1 步：用户请求进入系统，携带 request_id、user_segment 和 intent。
第 2 步：跟踪日志记录模型版本、提示版本、检索文档和工具调用。
第 3 步：LLM 评审对回复评分（正确性、有据性、policy_risk）。
第 4 步：规则引擎评估阈值。
第 5 步：如违反阈值，则触发警报，并转至备用方案/人工审核。
第 6 步：将故障加入分诊队列，随后纳入基准待办列表。
真实用户很少会完全按照设计者的预期行事。有些用户会误解说明。另一些用户会故意探测薄弱环节。这些边缘案例并非异常，而是极有价值的信号。实施得当的评估管线会捕获并分析这些案例，再将其纳入后续测试。只有将评估内置于系统，而不是在开发完成后再附加，才能在不留盲区的情况下快速迭代。
我们建议从第一天起就嵌入护栏和监控：
使用应用专属基准，定期跟踪模型指标和回归。
捕获并审核边缘案例或对抗性输入（并将其加入应用专属基准数据集）。
确保这些评估指标与核心 KPI 保持一致。
定期检验数据集和基准，确保没有忽略新风险或受到偏差影响。
针对指标下降实施自动警报（例如准确率降至 85% 以下时触发审核）。
对高风险决策（法律建议、医疗指导、金融交易）保留人工审核流程。
每次运行基准都会消耗算力和能源。每项重复试验都会增加成本。负责任的评估应兼顾严谨性与效率。
可以采取以下切实措施，防止能源消耗和成本失控：
尽可能使用较小的模型，先用成本更低的模型开展初步试验，验证方法后再扩大规模。
缓存提示和 API 调用。
采用能源感知型调度（批处理、竞价实例、灵活优先级）。
在跟踪性能的同时跟踪算力使用情况。
同样，也要密切关注新出台的 AI 法规。即使没有专门法律，现有框架和必要措施仍然适用，例如：
数据保护：
确保基准数据集未经适当同意不包含个人身份信息（PII）
针对日志中记录的查询实施数据保留政策
提供处理数据删除请求的机制
平等与偏差：
测试不同人口群体中的性能
创建基准时纳入多元化代表
人权与透明度：
向用户清楚说明模型的局限性
为高风险决策提供解释
确保关键应用支持人工监督
评估不是一次性活动，而是一个持续演进的系统。在快速发展的领域，优势取决于测试、学习和适应的速度，这样才能更有效地部署模型和新解决方案。
将评估作为工程和产品管理的核心活动，团队便能更快、更安全地创新。首先，根据 AI 应用的具体情境定义何为良好，搭建评估平台并持续完善，形成应用专属基准，从而在每次迭代时都有信心确认产品已具备生产就绪度。