【软件开发的周期:、需求分析、设计、实现、测试、安装部署、运行维护】 【软件测试的周期:、需求分析,测试计划,测试设计/测试开发,测试执行,测试评估】 软件测试v模型 (v模型是瀑布模型的变种) 优点:后期的测试阶段和前期的阶段可以一一对应起来,清楚的标注每一个测试阶段的依据 缺点:不利于项目前期风险的及时发现 软件测试W模型(双V模型) 特点:测试在项目前期介入,对需求,系统设计等都会进行验证 ,测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进行的 优点:测试介入早,有利于全面得发现系统前期的风险,同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,显著减少总体测试时间 ,加快项目进度 缺点:阶段性比较强,需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作不可逆,所以无法适应敏捷开发。
大模型幻觉测试本方法为企业级可落地的全流程幻觉测试体系,融合学术界权威基准与工业界工程实践,覆盖从口径定义、用例设计、自动化执行、量化打分到归因优化的完整闭环。 4.边界压力测试:拒答能力与边界幻觉测试目标:检测模型在知识边界外是否会硬编答案,验证“知之为知之,不知为不知”的能力。 :TruthfulQA官方基准落地参考值:通用大模型≥70%为良好,垂直领域模型≥85%为良好业务落地补充指标整体幻觉率:出现幻觉的用例占总测试用例的比例幻觉率=幻觉用例数/总用例数分类幻觉占比:事实/ temperature=0.1,top_p=0.9),确保结果可复现通过API或CLI批量调用被测大模型,全量保存输入输出日志(问题、回答、模型版本、调用时间)单用例调用失败自动重试2次,排除接口波动导致的误判步骤 自动化流水线:拆解:用大模型将回答拆分为原子事实断言检索:从业务知识库/权威百科检索对应证据判定:用判别模型逐句判断证据是否支持断言打分:汇总计算FactScore与各维度幻觉率步骤4:人工复核与归因(
Langchain架构 LangChain工具 组件:大模型包装器、聊天模型包装器、数据增强工具和接口链: 提供了标准接口,和数据平台和实际应用工具紧密集成 LangChain六大模块 模块 核心作用 Fake LLM,用于测试 缓存的支持,比如 in-mem(内存)、SQLite、Redis、SQL 用量记录 支持流模式(就是一个字一个字的返回,类似打字效果) Prompt管理,支持各种自定义模板 Agent作为高级模块,可调用其他所有模块功能 大模型接入 接入示例 云服务和私有化大模型优劣对比 维度 开发成本 算力成本 运维成本 数据安全 云厂商大模型 较低,开箱即用 算力资源充足,大模型性能好 &吞吐量较高 较低,提供云平台监控 安全性低 私有化大模型 较高,自建大模型网关、服务鉴权、可用性等 算力硬件投入成本高,大模型性能较差低&吞吐量较低 较高,需要专业运维团队介入 安全性高,保密性强 小结: - 研发&测试环境:为了方便部署和测试,使用云服务 - 大客户生产环境:安全审核严格,大多数采用自建大模型的方式 总结 LangChain 是什么?
更严峻的是——大模型测试本身正成为性能瓶颈:单次Prompt-Response耗时数百毫秒至数秒,批量评估动辄数小时;RAG流水线需反复调用嵌入模型+向量检索+重排序+生成模型,端到端延迟陡增;而A/B 如何让测试‘跑得快、判得准、控得住’?本文从工程化视角,为测试专家梳理大模型测试性能优化的四大核心路径。 三、轻量化评估代理:用小模型替代大模型做质检 让GPT-4或Qwen-Max为每个response打分,经济与效率双输。 四、测试即代码(TaaC):编排优化与资源感知调度 大模型测试不再是‘点一下Run’的黑盒操作。 结语 大模型测试的性能优化,本质是测试思维的升维:从‘验证输出是否正确’走向‘验证系统是否可持续交付高质量输出’。
随着大模型的发展,尤其是近来各种开源大模型的发布,如何对各种模型进行充分并且准确的评估变得越来越重要。其中一个越来越受到认可的方向就是利用人类考题来检验模型,从而可以测试模型的知识及推理能力。 这样的测试基准对于促进模型的发展起着至关重要的作用,然而对于多语言 / 多模态大模型,相应的评测依然是一片空白。 .pdf 数据 & 代码:https://github.com/DAMO-NLP-SG/M3Exam 背景 传统的 NLP 任务已经越来越难充分测试大语言模型的真正效果,在这样的背景下,利用人类考题来检验模型已经逐渐成为了测试大模型的一个常见做法 例如 MMLU 数据集涵盖了多个学科,被广泛用来测试各种模型,GPT-4 也将其作为一个重要的测试基准。 我们同样可以看到,来自于各个国家本土的问题更加充分地测试出了模型的多语言能力。例如 GPT-4 的 report 里将 MMLU 翻译成了多个语言,在不同语言的翻译试题上取得了较好的结果。
LangSmith是评估大模型能力好坏的评估工具,能够量化评估基于大模型的系统的效果。LangSmith通过记录langchain构建的大模型应用的中间过程,从而能够更好的调整提示词等中间过程做优化。 为了测试我们依托讯飞星火大模型创建一个继承LangChain的CustomLLMSparkLLM的类(代码在6.2.1章节),依托对应的类我创建了如下的测试代码。 #! router_chain, destination_chains=chain_map, default_chain=default_chain, verbose=True ) # 测试 在项目下的列表中,我们多次执行LangChain构建的大模型的应用也可以做横向对比。 每一次的处理和反馈的Trace都可以展示响应时间和使用的Token数。 LangSmith完成了跟踪LangChain构建应用的所有的中间过程,这也为验收或者测试LangChain构建的基于大模型的应用提供了有力的手段。
随着人工智能技术的不断发展,谷歌最近发布了一款名为Gemini的AI模型,该模型被认为是目前最强大的AI模型之一。 本文将从技术角度对Gemini进行解读。 首先,让我们简要了解一下Gemini。 与传统的语言模型相比,Gemini具有更高的参数数量和更先进的技术,这使得它在处理复杂语言任务时更加高效和准确。 那么,Gemini有哪些特点呢? 首先,Gemini采用了更大的模型架构。 在多项自然语言处理基准测试中,Gemini都展现出了卓越的性能。例如,在GLUE和SQuAD等测试中,Gemini分别达到了94.1%和93.3%的准确率,这比之前的模型有了显著提升。 因此,未来的研究将需要进一步探索自监督学习、知识蒸馏等技术的进一步发展,以提高模型的泛化能力。 最后,作为一款预训练语言模型,Gemini需要大量的高质量语料数据进行训练。 因此,未来的研究将需要探索如何有效地收集、整理和处理各种领域和场景的数据,以提高模型的泛化能力和表现。
从我的实践经验来说,如果无法对系统和业务有足够的了解,没有较为精准的性能测试三大模型,则性能测试的结果无法对线上容量规划起到明显的参考价值。 今天这篇文章算是性能测试知识的科普内容,我会聊聊在实际工作中开展性能测试,前期最核心的工作。即业务模型、流量模型和数据模型这三大模型,该如何评估和建立。 为了便于大家理解三大模型,我会以电商业务下单的场景来举例说明,如下图: 业务模型 大家可以将业务模型看作功能测试中的业务场景。 ; 构建流量模型 下面是之前我实际工作中一次双11大促时的流量模型构建案例,仅供参考。 预估大促时的支付转化率为60%,则可得:大促峰值订单支付QPS为(200/40%)*60%*(200W/50W)=1200QPS。
与此同时,传统软件测试范式——基于明确输入/输出断言、覆盖路径与边界值的方法——在大模型面前频频失效。 这些案例揭示一个现实:大模型测试不是‘加个Prompt跑几轮’,而是一场融合认知科学、统计推断、对抗攻防与领域知识的系统工程。 一、为何传统测试方法在大模型面前失灵? 二、大模型测试的四维技术框架 业界领先实践已形成可落地的四维测试体系: ✅ 1. 这类测试需构建端到端仿真环境,注入噪声数据、延迟网络、异常token流,观测系统级SLO(如‘95%请求在2s内返回可信答案’)。 ✅ 4. 三、实战案例:某省级政务大模型的测试攻坚 该模型需支撑12345热线智能分派与政策解读。
《目标检测第2步-数据准备》,链接:https://www.jianshu.com/p/3d9436b4cb66 《目标检测第3步-模型训练》,链接:https://www.jianshu.com/p 下载测试数据 下载链接: https://pan.baidu.com/s/1NksESNqBX--YqMJ4zptGdw 提取码: 6p3u 压缩文件n01440764.tar下载完成后,复制到桌面的文件夹目标检测中 image.png 4.下载并运行测试代码 链接: https://pan.baidu.com/s/1Ym1cYFCnsj1JAYFACHFj_Q 提取码: i3wn 代码文件fish_detection.ipynb 文件夹n01440764中共有1300张图片,测试图片是随机选的10张图片。 本文作者展示测试效果较好的2张图片。 ? image.png ? 2.时间主要花费在用最少的代码文件完成模型导出和模型测试的效果。 3.目标检测给物体画方框,方框线条的粗细和字体大小是一个需要花时间去学习的点。
TRIDENT:金融、医疗和法律领域的大语言模型安全基准测试随着大语言模型(LLMs)在法律、金融和医疗等高风险领域的部署日益增多,系统评估其领域特定安全性和合规性变得至关重要。 为填补这一空白,研究首先基于某机构医学伦理原则、某机构专业行为示范规则和某机构道德准则,定义了大语言模型的领域特定安全原则。 在此基础上,推出了Trident-Bench基准测试,专门针对法律、金融和医疗领域的LLM安全性进行评估。 研究在Trident-Bench上评估了19个通用型和领域专用模型,结果表明该基准能有效揭示关键安全漏洞:强大的通用模型(如某中心GPT、某中心Gemini)能够满足基本要求,而领域专用模型往往难以处理细微的伦理差异 代码和基准测试将在以下网址发布:https://github.com/xxx
MINIGPT-4: ENHANCING VISION-LANGUAGE UNDERSTANDING WITH ADVANCED LARGE LANGUAGE MODELS在GPT4未开源的情况下,作者认为其表现优越是因为采用了最为先进的 LLM模型,因此,作者在BLIP2的基础上,将LLM模型替换为了Vicuna,同样也是通过一个线性映射层将图像表征映射为LLM的输入。 开源代码:https://minigpt-4.github.io/一、预训练方法预训练方法几乎和BLIP2模型一致,可以参考:【大模型学习 | BLIP2原理】-腾讯云开发者社区-腾讯云1.1 Q-Former ; MINI-GPT4表现比BLIP2要强上许多? ① MiniGPT-4 使用的是 Vicuna(基于 LLaMA 的开源 ChatGPT 对话模型),具有更强的自然语言表达和指令理解能力;而BLIP-2 使用的 LLM 主要是 Flan-T5 或 OPT
简直了,有人居然给大模型测了一波MBTI。 兴许是MBTI这波人格测试太火(官方免费测试链接可在文末自取),加上大模型有时真的很像个人。 作者便产生了一个“大胆的想法”: 不同的大模型是不是也有不同的个性? 现在网上主要根据首字母将人分为“i人”和“e人”两大阵营。) 说干就干,他们首先选定了一波待测试模型(共计6个),所有都按照原始论文中的参数进行训练。 以下是各模型最终得分: 可以看到,不同模型人格确实不同——GPT-4属于INTJ,ChatGPT属于ENTJ,而70亿参数的Bloom为ISTJ…… 而从下图我们能清晰的看到,不同模型在四大维度的具体表现并不一致 因此,它也可以作为评估大模型的一种粗略的指标。 其次,在MBTI的四个维度之中,前俩参考意义不大,主要是T/F和J/P。 这是鉴于GPT-4和ChatGPT表现出比其他模型高得多的T值和J值。
大语言模型基准测试框架解析某研究者近日在代码托管平台发布了针对大语言模型的新基准测试框架。 该框架包含从实际与大语言模型对话记录中提取的近100项测试,涵盖以下技术场景:将Python函数转换为等效但更快的C函数解释压缩后的JavaScript代码功能识别数据编码格式(如uuencode编码) :LLMRun:向语言模型发送提示词ExtractCode:从模型输出提取代码块CRun/PythonRun:在隔离环境中执行代码SubstringEvaluator:验证输出包含预期字符串复杂测试场景框架支持多步骤交互测试 test_if_question_is_solved),(LLMRun() >> PyFunc(extract_cmd) >> TerminalRun() >> PyFunc(extract_output)),max_iters=4) :在自定义汇编语言编写和解释器实现方面表现较差设计理念与传统学术基准不同,该框架专注于:实用性问题:测试实际使用中遇到的真实场景简单提示:避免复杂的提示工程,测试原始问题解决能力可扩展性:允许用户轻松添加自定义测试用例结论该基准测试框架为实践者提供了评估大语言模型实用能力的工具
引言:当大模型从实验室走向生产,性能不再是‘能跑就行’ 随着LLaMA-3、Qwen2、GLM-4等开源大模型迭代加速,越来越多企业将大模型集成至客服系统、智能文档分析、代码辅助等核心业务场景。 本文基于我们在金融、政务、制造领域的真实测试案例,系统拆解大模型性能优化的测试方法论与实战路径,聚焦‘可测、可调、可证’三原则,拒绝空谈架构,直击工程落地痛点。 结语:性能优化是测试工程师的新护城河 大模型时代的性能测试,早已超越LoadRunner脚本编写。 在啄木鸟近期认证的‘大模型性能测试工程师’中,73%来自原SRE/算法工程岗——这印证了一个趋势:谁掌握性能验证闭环能力,谁就掌握大模型落地的最终话语权。 下一期,我们将发布《大模型可靠性测试白皮书V2.0》,涵盖混沌工程注入、对抗样本压力测试等前沿实践,敬请关注。
引言:当大模型从实验室走向产线,测试不再是‘锦上添花’,而是‘安全底线’。 更值得关注的是,头部企业正悄然转向开源测试工具链——不是因为预算限制,而是因其透明性、可审计性与快速迭代能力,恰好匹配大模型‘黑盒深、行为动态、场景泛化’的测试挑战。 一、为什么传统测试方法在大模型面前集体失灵? 二、四大开源利器:构建可落地的大模型测试流水线 1. 三、实战案例:用开源栈完成一次端到端大模型测试 以某电商客服大模型升级为例: - 步骤1:用`Promptfoo`构建测试集——导入历史工单对话(500条),标注‘意图类别+预期响应类型+合规关键词’;
引言:当大模型从实验室走向产线,测试不再是‘验证功能’,而是‘守护智能边界’ 2024年,国内超73%的头部科技企业已将大模型集成至核心业务系统——客服对话引擎、金融风控决策链、医疗报告生成平台……然而 这些并非算法缺陷,而是测试体系与大模型特性严重错配的结果。本文基于啄木鸟软件测试团队服务12家AIGC企业的实战沉淀,系统拆解大模型测试从‘不可测’到‘可度量、可追溯、可治理’的落地路径。 一、为什么传统测试范式在大模型面前集体失灵? 传统测试依赖确定性输入->确定性输出的契约,而大模型本质是概率性生成系统。我们曾协助某银行测试其信贷问答大模型,发现:同一问题‘逾期会影响征信吗?’ 结语:测试不是给大模型戴枷锁,而是为其装上‘质量导航仪’ 大模型测试的终极目标,不是消灭所有不确定性(这违背其本质),而是将不确定性控制在可解释、可接受、可追溯的风险区间内。 当测试从质量终点站前移到价值创造链路,它就真正成为了大模型规模化落地的‘信任基建’。下一站,我们将探索‘测试即文档’——让每次测试用例自动生成模型能力说明书,让业务方读懂AI的边界与善意。
而随着大语言模型(LLM)深度融入产品架构——从智能客服、代码补全到AI原生应用(AI-Native Apps),测试的边界正被彻底重构。 2023年Gartner报告指出,67%的头部科技企业已设立专门的大模型质量保障(ML-QA)小组;2024年微软Azure AI团队披露,其LLM服务上线前的测试周期中,传统功能测试占比不足30%,而提示鲁棒性验证 这背后不是测试工作的缩减,而是测试范式的升维——从验证‘是否正确实现’,转向保障‘是否安全、可信、可控地涌现价值’。 一、为什么传统测试方法论在大模型面前集体失灵? 某政务大模型测试中,AI自动生成的‘惠民政策解读’虽语法完美,但将‘阶段性补贴’误读为‘永久性福利’,此类隐性逻辑谬误需领域专家交叉验证。 结语:测试的终极使命从未改变 大模型没有颠覆测试的本质,反而将其升华。测试从来不只是关于‘发现错误’,而是关于‘建立信任’——对技术边界的清醒认知,对用户期待的精准回应,对社会价值的坚定守护。
这两年,测试工程师接触的大模型,大多都在“写”:写用例、写脚本、写日志总结、写缺陷分析。Kev这类模型反过来。它不负责组织一段看起来很有道理的话,而是给你一份状态和几个固定问题,返回每个选项的概率。 比如一条测试执行记录,你可以问它:这个失败是不是环境波动?该归给前端、服务端还是测试数据?问题影响属于什么等级?它不会写一大段解释,直接给出结构化结果。 1.先理解:它不是聊天接口,而是类型化决策接口普通大模型接口返回的是文本。你要么让人读,要么再找一个模型读,很容易变成“模型评模型”。 true的概率,必须在0~1之间choice故障归属、工单路由、缺陷类别候选项集合不能丢,概率和应接近1score风险等级、严重程度、规则满足度分数对应有序等级,不能把它当成天然的1~5分这也是它和“让大模型评价一句话好不好 4.第三步:先写接口契约测试,别一上来只看HTTP200很多AI服务的冒烟测试止步于status_code==200。对决策模型不够。
引言 随着ChatGLM、Qwen、DeepSeek及Llama系列大语言模型在金融、政务、医疗等关键场景加速落地,模型测试已远超传统‘功能是否正确’的范畴——性能成为决定能否上线的核心瓶颈。 这些并非个例,而是大模型测试进入深水区的典型信号:性能不是附加项,而是可信AI的第一道防线。 一、明确性能基线:拒绝‘拍脑袋’指标 大模型性能测试首要误区是套用小模型标准。 某车企实测发现,量化后INT4模型虽降低显存42%,但因解码器访存激增,实际能效比反降19%——这正是基线驱动测试的价值:用数据替代经验判断。 二、分层注入式压测:从单卡到集群的穿透验证 传统压力测试常止步于API层,而大模型性能瓶颈常藏于框架底层。 结语 大模型性能测试的本质,是构建‘可测量、可归因、可演进’的效能反馈闭环。