问题疑惑：
1、落地基于现有业务落地大模型，测试除了关注产品文档上那一点黑盒的东西，还应该做些什么？

与其说落地了大模型，不如说，对于企业本身，使用 deepseek，具有合规和当前战略性意义。就落地后的效果来说，一言难尽。就如 manus 一样（很多做的离 manus 甚远）

准确来说，应该是大模型应用的测试

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

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

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

感谢解答，目前的测试内容主要是包含几部分：
1、产品文档的实现情况
2、用户提问的实体识别是否准确
3、根据实体召回数据是否正确，召回数据的性能
4、模型生成的 prompt 数据是否正确
5、模型返回的内容是否与 prompt 数据存在相关性
6、模型返回内容的格式是否正确
7、模型的用户提问及返回的敏感词校验
8、模型返回的异常情况验证

以上基本上都是基于黑盒模型的模型应用测试

疑惑点
1、相对传统测试的测试基准变得模糊不清了
2、测试数据的来源、测试数据如何分类等

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

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

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

感谢解答，受益满满，已经明确了需要加强的方向

来参加 MTSC 大会呀，今年我们会分享这部分经验

https://www.qacon.net/