赞
踩
传统软件应用的输出会遵循程序员编写的代码逻辑,对确定的输入能生成与之对应的确定输出。然而这个规律在基于LLM的应用中却不那么成立,当我们输入提示给到LLM应用时,它结合上下文提示语及概率参数设置,最终输出就并不是那么可预知的。
LLM应用相较于传统应用不那么具有可测性的原因主要有下面几点:
而且从技术上看LLM应用的正常输出也未必就是准确或者合适的。对于这种非结构化、更多关注用户主观感受的产品,它们的质量如何度量呢?
这里区分一下LLM模型的质量和LLM应用的质量:
本文说明的对象是LLM应用,因此这里的质量指的是LLM应用的质量,而不特是LLM模型本身。而LLM应用作为一种软件,它的质量策略跟传统软件的测试策略也有可以沿用的部分,虽然LLM应用跟传统软件在测试方面有很大的不同。
首先,LLM应用作为软件产品,它的质量同传统软件质量的定义是一致的,包括功能性、可靠性、性能效率、易用性、可维护性、可移植性、兼容性、安全性等等。因此针对LLM应用的一般测试执行也包括:
其次,LLM应用与传统应用的测试毕竟存在不同。与传统软件在功能测试上主要进行输入和预期输出的比对上,LLM应用的功能测试除了关注功能特点之外,还需要关注:
输出一致性:大模型针对同一问题的不同陈述形式的prompt,输出的结果要保持一致性。
道德问题:大模型除了技术上实现了功能,针对它的输出还需要考虑道德问题、偏见问题。比如不能输出带有歧视的内容,不能输出不符合法律法规或社会公序良俗的内容。
幻觉测试:大模型会产生幻觉,即生成明显不合常理的内容,即便它的功能正常。
最后,LLM应用测试需要大量的数据投喂,需要大算力的支持,因此它的测试成本往往比传统软件要高出许多。
从各大厂家公布的LLM模型卡片上,我们可以看到各种数据集下的评估指标。从质量工作上来说,我们需要这么一套标准,通过它来度量LLM应用的“好”与“坏”,让开发者或用户获得如下的收益:
测试人员应该根据自己LLM应用的用户场景,挑选相关的评估数据集进行跑分测试。
在模型评估达标后,集成到LLM应用系统后需要进行功能测试。
建立用户场景的输入输出,确认功能可用。维护测试用例集进行单元测试和回归测试。
LLM测试的场景比传统软件应用多出许多,人力的成本是一个不可忽视的变量。可以将目前的一些标杆LLM应用作为参考,比如chatGPT或llama这些的输出来比对自己产品的输出,计算输出的相似度来判断用例是否通过。
LLM自动化测试解决了效率问题,但欠缺人工测试的权威性,毕竟一款LLM产品好不好,作为终端用户的人才最有发言权。产品设计上可以建立用户反馈机制,部署A/B测试来评估质量。
直接反馈:在输出结果界面提供用户“赞”和“踢”之类的按钮,使得用户可以对输出结果投票。
间接反馈:页面插桩来分析用户行为,推理用户是否认同输出结果来进行评估。
LLM应用有其与传统软件性能测试关注指标不同的地方,比如:
可以参考OWASP的LLM top10漏洞说明,进行安全风险评估和验证,进行必要的安全扫描,条件允许情况下最好能进行红队模拟攻击。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。