还未发布过话题
  • 好的,我尝试回复下,可能存在错误,还请批评指正:
    1、传统测试与大模型业务测试本质上没有太大的区别,而测试大模型业务需要转换思考问题的方式,传统测试是代码逻辑比较固定,而测试结果大多数只有通过/不通过,大模型业务测试本身存在随机性,动态性,要结合业务特点制定通过标准,比如,同样得问题不同的人问,返回的结果不一样,那么要去考虑如何降低幻觉等问题。

    传统测试与大模型测试的核心差异可归纳为:
    从 “确定性” 到 “概率性” :接受生成结果的合理波动,但需量化控制风险边界。
    从 “功能验证” 到 “内容治理” :不仅要确保功能正确,更要防范生成内容的安全与合规风险。
    从 “单点工具” 到 “全栈工具链” :需整合模型微调、评估、监控的一体化平台,而非孤立工具。
    需在思维、技能、工具链三个层面同步升级

    2、我了解到的一些信息为,业务本身的模型所使用的数据来源大致为:模型本身数据、业务私有化数据、向量数据。我们可以先暂时不考虑模型本身的数据,我们侧重于业务数据和对应向量数据,可以理解为 A 数据集。测试数据应依赖于业务数据和向量数据去制造相反测试数据集 a。a 数据集里存在金标准用例,即通过用例,存在相反数据是检验业务本身处理异常数据和噪声数据的能力。分类可以分为:【金标准类】此类下用例要全部通过,为业务数据。【95% 类】此类型下用例通过率达到 95 以上。【敏感类】此类包含敏感信息、犯罪、暴力等信息。【噪声类】基于金标准类用例衍生出噪声用例,完美预期是通过率为 0。【基本常识类】业务本身的一些常识,例如金融类专业属于是否能够理解、行业常识是否能够回答等。基于多个数据集下的测试结果和制定通过标准公式算出通过率。例如,通过率低于 60%,此功能是不是可以认定为测试不通过。
    3、数据来源补充:可以根据业务需要什么数据,爬对应数据,但要遵守法律法规 (保命语句)

  • 我的一些拙见,如果需要测大模型应用,建议学习一些大模型基本知识,可以参考下高飞总的博客:https://testerhome.com/articles/38557

  • 这个可以明确下获取大模型的途径,如果是调用官方接口,那么需要考虑到接口异常后业务侧的展示等,如果是公司内集群部署,需要考虑集群异常和故障自恢复能力。需要对大模型应用入口稳定性关注。底层文档性关注后,那么则对业务尽场景可能测试异常场景。

  • 除了关注产品文档上那一点黑盒的东西外,还应该关注研发处理提问用户词的逻辑。还有根据词抽取数据(模型数据/私有化数据/向量数据)的正确性(抽取数据是否符合预期)和数据展示安全性(敏感数据/歧视性数据是否能够拒绝回答,和敏感字段的脱敏展示策略)。总的来说,除了大模型本身的能力外,需要重点关注业务层结合模型处理的业务逻辑的处理规则。

  • 听了下,真不错👏

  • 👍 👍 👍

  • 依靠 Bug 数量衡量?