评测即业务：大模型应用开发的生存法则

大模型应用开发，我们真的准备好了吗？我们是否还停留在过去「只要功能正常运行就好」的阶段？

在软件过程发展的过去几十年里，软件工程一直在通过各种各样的手段，来降低系统整体的风险和不确定性。我们设计了大量的方案和框架，来帮助业务快速发展：TDD、BDD、DDD，不同的名词和对应的工具，都在引导我们通过各种各样的手段，来降低项目工程的不确定性，确保系统的整体稳定性。但，大模型的到来，过去稳定的软件工程带来了新的预期—— 可能也不是所有事情都是稳定的。

大模型自身的复杂度和特性，决定了其并不如我们过去软件工程通过代码来完成的逻辑那么的稳定和明确。对于一段代码，在设计良好的情况下，我们可以认为其 Input 确定的情况下， Output 也是确定的。但对于大模型来说，至少此刻，我们还没有那么的笃定我们相同的输入一定可以获得相同的输出。这使得过去的软件工程的常规手段出现了裂痕 —— 虽然你的逻辑一切都很清晰和明确，但系统自身的输出依然随机的。而这些随机，为项目自身的稳定性带来了隐患。

也正是因为这些随机问题，使得大模型应用时代的开发，和过去我们熟悉的应用开发开始略有不同 —— 我们需要开始关注模型层面的评测。评测从一个边缘指标，只有算法需要关注的指标，成为如今每一个大模型应用开发者需要关注的指标。如果要下一个论断，那便是 —— 评测即业务。

我们为什么要做测评？

作为一个传统工程出身的同学，我很擅长基于对于业务的理解，建设出一个业务系统，帮助业务解决的问题。我曾经和团队一起开发了一款AI文档生成工具，起初只关注功能是否能跑，直到Leader问我「业务效果如何？准召指标如何？」，我一脸懵，在那一时刻我才知道何为评测，让评测进入到我的项目流程中。

是的，那个时候的我，脑海中完全没有评测的概念，所以也没有做评测的意识，只知道业务在稳定的跑，我们可以拿到正向的用户反馈，但对于业务的效果到底如何？其实我并没有概念。也是在那一次，我开始恶补评测相关的知识，懂得应该如何进一步去做评测，也才有了写这篇文章，告诉你不要犯和我一样的错误。

为什么过去不需要评测？

评测并非大模型的出现时才有的话题，只是在过去，我们大部分时候调用的是一些稳定的服务，比如数据库或者是第三方的 API，他们的行为是可预测的，所以我们只需要关心功能本身。而大模型则不同，大模型本身就是不确定性的来源。

实际上，在传统搜索领域、机器学习领域，评测也是早已有之的概念，只不过这些功能过去往往是作为一个单独的模块存在，所以在工程上使用相关能力的时候，默认假设是相关的模块是可信的，模块内部的准召指标由模块内部的工程和算法同学来完成。业务工程团队更多关注的是工程实现层面的功能是否可用，而非关注效果指标 —— 比如设计的功能是否正常运转，相关的功能模块是否可见、可用。

而大模型应用的时代，大模型不再是作为一个额外的业务模块被调用，而是嵌入在我们的业务系统之中，这种从「外部」到「内部」的转变，意味着我们必须将评测融入到开发的每一个环节，而不是把它看作一个独立的模块。相比于传统的测试和评测只关注功能是否可用，我们开始需要关注模型的性能、数据的质量、用户体验等多哦个不同的模块。其占比也有了巨大的提升。在过去，我们的产研测的配比往往是 1:(5～10):1，但如今随着评测的重要性不断提升，一个更加合理的比例可能是 1：(5～10): 2，这里多出来的1 个人，就是服务于大模型所带来的不确定性的变化所导致的 —— 我们需要有更多的人来保障模型的效果。

我们应该怎么做好评测？

如果你认可前面的逻辑，那么就意味着我们拥有了共识：大模型是不那么稳定的，我们需要支付额外的成本，来保障大模型在我们业务系统当中的保持稳定。而基于这个共识，我们就可以开始设计我们的评测系统和方案了：

以终为始：定义业务指标和技术指标

进行评测的第一步，便是定义业务指标的含义和价值，明确模型的输入和输出。评测即业务的含义也在于此，如果你在第一步完成的足够好，其实评测的 80% 的价值便已经拿到手。业务指标因为和业务强相关，不具备太强的通用性，这里就按下不表，我们把精力放在更加通用的技术指标上。

如果你的业务系统当中接入了大模型，则应该关注下面这些指标：

生成质量指标：评估大模型生成内容的质量。这部分有一些可以参考的评测方式（比如Bilingual Evaluation Understudy、 Recall-Oriented Understudy for Gisting Evaluation 等），不过更加靠谱的还是依赖人工进行打标，毕竟最终是需要由人来评估生成的内容是否符合要求。在人工打标的时候，一般而言，大家会关注生成的内容的有效性、流畅度、连贯性、相关性等指标。
模型效率指标：评估大模型的推理速度、吞吐量、计算资源消耗等。如果你使用的是云端的大模型 API，则可以重点关注模型推理速度和吞吐量，这些可能会直接影响到你的业务系统体验和业务模式涉及（让用户等待还是直接做成异步的任务模式）。而如果你使用的是本地的模型进行运算，则还需要进一步关注到模型大小、内存占用和计算资源消耗，这些指标可能会影响到你的业务系统选型和成本计算。
模型安全指标：评估大模型针对一些恶意请求的处理能力。这部分则可以重点关注模型是否会生成出有害、不当或歧视的内容；是否会出现敏感信息泄露的等。大模型在落地的过程中，会遇到一些不友好的用户请求，如果没有相对应的处理能力，可能会直接让你的应用遭遇滑铁卢，因为安全审核没做好直接被举报挂掉。

如果你的系统在接入大模型的基础之上，还做了相应的数据库系统，来实现 RAG，那么还要额外关注：

准确率：评估在所有召回的文档中，真正与用户相关文档的性能占比有多少，可以帮助你衡量召回结果的效果，减少给大模型的噪音和无关信息，提升生成的准确率。准确率低通常是因为检索模型召回了太多不相关的文档，此时应该提高相似度阈值或优化检索模型使其更严格；
召回率：评估在所有用户意图相关文档中，被召回的文档占据所有用户意图相关的文档的占比，可以帮助你确保检索结果的完整性，确保不遗漏重要的信息。召回率低通常是因为检索模型漏掉了很多相关的文档，此时应该降低相似度阈值或优化模型使其更宽松。
命中率：评估在用户的多次意图查找中，能命中至少一个文档的比率，可以帮助你判断当前知识库内容的是否可以覆盖用户的意图。如果命中率低，可能意味着你需要去补充知识库当中的内容，或者是去优化查询的 Query。

而如果你的业务系统是诸如生成代码之类的场景，可能还需要观测代码执行成功率、代码执行成功率等一系列指标。

上述的这些指标，只能作为一个初步的导览，到了具体的业务当中，肯定还要和业务结合做一些调整。但总的来说，当你想清楚你要观测哪些指标，要进行何等的评测时，其实你的业务已经想的大差不差了，剩下的只不过是通过评测选择出合适的模型和 Prompt，并用工程手段将其串联起来。

清洗数据：高质量评测的关键

定义出了指标，下一步要做的事情，是清晰出高质量的数据，参与到评测，这里就需要你有高质量的数据，能够辅助你的业务进行评测。不同的评测目标对应着不同的数据，因此，也需要维护多组不同的数据集，用于进行不同目标的评测。

随着业务的不同，你所选择的数据集很有可能是无法使用公开数据集覆盖的，则就需要考虑自己去准备数据集，这部分数据可能来自于线上的数据，也可能是人工便携的数据，或对于现有的数据进行标注，从而清洗出高质量的数据参与评测。

获得第一步数据后，下一步则需要对拿到的数据进行清洗。上一环节拿到的数据很有可能存在噪声，或者是数据的不规范，因此，你需要对这些数据进行清洗，移除数据中的错误、重复和不完整的信息，并对格式进行统一，去除无用的数据，规范化数据。如果你的数据可能涉及到一些敏感数据，还要进行数据的脱敏处理，以保护用户的隐私。

在数据的清洗这部分，你会耗费大量的时间和精力，因此，要提前规划数据的收集和清洗，以降低后续的压力。同时，也要提前准备相关的人力，来支持数据集的建设。

除了上述的问题，还要关注到数据集的质量（代表性、准确性、多样性和完整性）、规模、数据偏差等。确保数据集本身不会出现偏见和问题，而将模型导向一个错误的方向。

当你准备好上述的这些数据，接下来要做的事情就相对简单 —— 维护好数据，定期更新，以适配业务，并持续性的对系统和模型进行评测和指标观测，确保各项指标没有出现问题。

持续评测：常态化过程

评测不是一个一次性的事情，大模型的发展很快，特别是使用云 API 的场景，模型厂商很有可能在后台帮你升级模型，你的线上数据分布也可能发生变化，因此你更需要持续、不断的迭代你的评测。定期（比如每周、每月、每个大版本迭代后）化，常态化（将评测融入到项目的开发迭代流程中）进行评测，从而帮助你及时发现问题，快速迭代。持续评测不是可有可无的选项，而是大模型应用时代不可或缺的必要环节。