• 好像可以有哎,我想想要不要写个帖子

  • 大语言模型要如何评估

    NLP 领域的模型评估方法向来都是繁杂和枯燥的, 因为它没有什么可以炫技的地方, 只能一点点按部就班的收集数据并进行评估。由于自然语言的复杂和多样性,这也导致了我们需要
    评估的内容非常多。 所以需要建立起一套或多套的问卷来进行评估。 当然也可以用行业公开的数据集和指标。 比如在语言安全方面(内容审核)可以使用 Safety-Prompts,
    中文安全 prompts,用于评测和提升大模型的安全性,将模型的输出与人类的价值观对齐。

    也可以使用中文通用大模型评测标准 SuperCLUE,23 年 5 月在国内刚推出, 它主要回答的问题是:中文大模型的效果情况,包括但不限于"这些模型不同任务的效果情况"、"相较于国际上的代表性模型做到了什么程度"、 "这些模型与人类的效果对比如何"。
    该标准可通过多个层面,考验市面上主流的中文 GPT 大模型的能力。一是基础能力,包括常见的有代表性的模型能力,如语义理解、对话、逻辑推理、角色模拟、代码、生成与创作等 10 项能力;二是专业能力,包括中学、大学与专业考试,涵盖从数学、物理、地理到社会科学等 50 多项能力;三是中文特性能力,针对有中文特点的任务,包括中文成语、诗歌、文学、字形等 10 项能力。

    或者 C-Eval:

  • 云原生测试是什么样子的 at 2023年11月15日

    多谢支持哈

  • 云原生测试是什么样子的 at 2023年11月15日

    多谢支持哈

  • 看完了帖子和所有人的聊天, 突然想起某位大佬说过的一句话:千万别让理论派做老板,讲道理时简单一句话,实操时千言万语都不足以表达。

    我记得几年前我们那有个 leader 在群里对着手下说:我希望大家对质量是有敬畏态度的,不能觉得把 UI 上的用例跑完了了就足够了,你们需要深入到产品代码里,我要求研发修复的每个 bug fix 你们都要去代码里去分析风险,会不会引起其他的问题。

    这位 leader 说的话对不对?理论上完全没错, 但我们统一管这叫永远不会出错的废话。道理谁都懂, 但是他手下要面对的是什么情况呢, 我们看一下那个产品主要以 go 语言实现, 其中还包含了大数据,机器学习,云计算,边缘计算。 而这些测试人员是什么情况呢, 几个正式带一大堆外包,并且项目全都是倒排,排期压缩到了令人发指的程度。 这个前提下,怎么执行这项命令?

    首先那一堆外包别说 go 语言代码了, 人家能写个 python 脚本就了不起了, 要是代码写的溜人家也不至于来做外包。 你想让他们看懂 go 代码, 得搞内部培训吧。培训怎么排?怎么能在项目倒排的大环境下协调这些测试人员完成培训,还得保质保量的完成培训。 这些培训要花多长时间, 怎么计划培训内容,这都是问题吧。 还有不是会写代码就能看懂人家产品代码逻辑的, 得安排研发来宣讲代码逻辑吧,得培训大数据,机器学习,云计算,边缘计算的各种逻辑吧, 得安排研发和测试做结对吧, 那人家研发凭啥配合你, 人家也是项目倒排。 做 code review 也得有机制吧, 这年头有几个团队正经八本搞 cr 的,谁有那个时间, 都是自己对自己的代码负责, 你怎么改变这个情况, 这不仅是排期的事, 你还要改变工程文化吧。 还有一堆在实操过程中出现的乱七八糟的状况就不多说了。

    所以你看就一个测试人员参与 code review 这事, leader 简单一句话,但要办起来要有多么复杂的工作,要花多长时间。 理论需要有, 但理论不是动动嘴皮子这么简单的, 我们都知道王阳明的知行合一。 光动嘴皮子,说一些永远不会错误的正确的废话是十分容易的。 难的是知行合一,难的是把理论落地。

    这就是为啥说,大道理谁都懂,但大家为什么不这么做? 就好像问你为什么不去清华,你说为啥,那难道还能是因为不喜欢么? 不管左移,右移,cicd,概念早就烂大街了, 就那么几本书大家该看的都看完了。 问个在校学生人家都懂这些理论。 所以提理论是没错的, 但我希望我们做的是把理论落地,而不是空讲理论。

    最后说一句我信奉的哲理: talk is cheap,show me the code

  • 云原生测试是什么样子的 at 2023年10月26日

    想重做一下呢, 之前写的比较零散, 并且因为要写书,所以也荒废了。 现在书写完了,想重开一下, 详细的讲讲, 也包括人工智能方面的。

  • 应该还好, 我是从 docker 基础开始讲的, 不过要是对容器领域是 0 基础的话。 最好还是先补补 docker 的基础知识, 先玩一玩 docker 再看会更好。

  • 我不知道啊, 听编辑的得

  • 已经出版了,链接写到帖子里了哈

  • 书已经出版了

    京东自营链接
    https://item.jd.com/14182314.html
    人邮旗舰店链接
    https://item.jd.com/10086973360931.html

  • 多谢支持哈

  • 容器领域监控都用 prometheus, nmon 已经被淘汰了不知道多少年了

  • 混沌工程 - 从 0-1 初分享 at 2023年09月15日

    k8s 下无脑 chaos-mesh, 非 k8s 可以选 chaos-blade。

  • 参考一下我的桌面:

    所以楼主, 你为啥要 all in 某一种语言。。。。。 难道不是项目用啥你学啥么。。。 研发那边我都没听说谁是只会一种语言的。

  • 据我有限的圈子内得到的反馈是大部分没有落地的, 极少数有落地的地方,业务团队都反馈效果不好。 这也是没办法的事情,精准测试这个东西很多人都把目光聚焦在了调用链分析和 AI 上,聚焦在了用例推荐上。 但很多人都忽略了一个网络段子 -- 人工智能是有多少人工就有多少智能。 这个段子虽然有失偏颇但其实也说明了人工智能是建立在大量的人工作业的基础上。 比如拿精准测试来说,推荐用例的前提是测试团队维护了非常精准的用例库,这些用例会随着研发代码和产品需求的更新而更新。 光是这一点其实 9 成 9 的团队就做不到。 还有就是产品的需求和代码架构非常频繁的变动的,如何建立起一个自动化的自学习(自动拉取最新数据最新代码并进行模型训练,并进行指标更新进而更新模型)也是一个非常大的工程(用人工的方式维护模型是肯定不行的)。并且很困难,比如监督学习的数据是要打 label 的(总结一下就是哪部分代码对应哪条或者哪些测试用例),目前大部分的 AI 团队都要花费很大的成本建立标注团队去人工打 label。 如果这些问题都解决了, 还需要面对人性, 就是这些用例推荐不是 100% 准确的(AI 做不到 100% 的精准与召回),如果推荐错误,导致线上出问题,那么谁来背锅? 目前所有团队的做法是业务测试人员背锅, 那么问题来了,我用你的东西, 你的东西不保证准确,出了问题要我自己来背锅。 那么我为什么要用你的东西?

    所以其实精准很难落地,不是因为大家普遍看到的 AI 和代码分析这样的技术问题。 而是要面对海量用例的维护问题,人工标注数据问题,模型更新问题和人性问题。

    综上所述, 以我有限的圈子得到的结果, 能把精准落地而且业务反馈非常好的团队,我暂时还没见到。

  • 想起来 10 年刚毕业那年, 工作地点在中关村微软双子大厦,我记得那个地铁站是苏州街的下一站(具体站名我忘了),我的房子租在了沙河高教园(当时工资 4000,到手 3400,所以房子只能租在那边,我记得房租是 1100),当时沙河高教园刚刚建成没两年(打听了一下是 08 年开盘的),所以附近什么都没有,一到晚上就黑灯瞎火的,那时候真是除了个小区周边啥都没有。 只有一个公交能到地铁站(2 站地)。 所以那两年基本是,公交->昌平线->西二旗转 13 号线(就是北京三个带西字的出了名的认多的站,号称基本上两脚离地被挤上去)->10 号线->下车步行 15 分钟。 基本上一趟也起码 1.5 个小时,早晚来回 3 个多小时。 当时觉得很痛苦但也没办法,工资到手 3500,去掉房租就剩 2000 来块钱,再算上吃喝拉撒日常开销,根本不剩下什么了。这也是为啥我租了个那么远的房子(还是合租的)。 所以当翅膀硬了以后(学到东西了,有跳槽涨薪的资本了),我立刻就把工作换到西二旗了,这样基本就可以控制在 50 分钟以内。

    我觉得忍受极端通勤的人一定是没办法的, 如果有办法要么就换工作,要么就换房子。 都是向现实妥协的结果。 如果楼主要不要换工作,其实很明显, 有实力就换, 没实力就只能向现实妥协。

  • 感觉好多人是被 PUA 习惯了么。。。。这么主观的问题纠结这么多分析这么多干啥。。。每个领导的风格都不一样,你面对这个领导的时候他认为做事方法是这样的, 面对另一个领导的时候他认为做事方法是那样的。 还在这分析这么多。。。。你们真是。。。。

  • mock server 实践 at 2023年08月29日

    为了把 mock server 注入到目标 pod 用的

  • 感谢恒温和社区的支持

  • 抱歉哈😂 , 提前预热一下

  • 我 87 年的,今年应该 36 岁。 上周一个大我 1 岁的朋友被裁员了。 今天我俩一块吃饭的时候说面试机会确实挺少的。 感觉这波经济下行还是没过去的, 最近大家还是能苟着就苟着吧

  • 菜鸟的成长之路 at 2023年06月27日

    后面有机会就不要错过了~

  • 对于测试行业的护城河这件事,我能在我自身的圈子里感受到的就是我们不再去卷什么 UI 自动化,接口自动化和测试平台这些事了。这些我们基本扔给了外包或者子公司或者职级更低的人来做。 因为讲道理这些东西在当今的测试开发圈子里都是基操了,技术含量有限。 相比于这些基本的通用技能,我们更多的精力都放在了相对门槛较高的垂直方向里,比如有同事专门去做大模型业务的测试, 有同事专门做大数据的, 有同事专门做内容审核的,又比如我更多的精力放在了云和人工智能的测试项目里。 这些领域中的产品无一例外的都是门槛较高的技术型产品,我们老喜欢开玩笑说这些产品里都是不说人话的,因为在这些产品里就算是点点点的门槛都相对较高,因为这里需要相当程度的时间和精力去学习这些产品中的业务和技术,并不是 C 端那种面对普通人的产品,而是面对专业领域工程师的产品。

    我们在这些本身就偏向技术的产品中继续下沉,去研究更深层的技术和测试方案,起码在这个领域里做到大部分同行都做不到的程度,我理解这就算是我们的护城河了。 当然这里的护城河不是说这个事离开我们别人就做不了了,而是能和我们竞争的人已经比较少了,因为在这个赛道里的人本身就少,它的门槛也高,不是谁想进来就能进的来的。 我们当初能进来也有运气的成分,入职了相关业务的团队,有幸学习到了相关的技能。外人想靠自学进入这个赛道确实不容易,通用的自动化测试还可以自己去学习,但是在没有工作环境或者没有人指导的情况下,想靠纯自学去入门这些领域实在过于艰难。 所以跟朋友聊天的时候大家的想法差不都是虽然能去的公司没有特别多(以为做这些领域的公司也确实不多),但竞争对手也很少,所以相对没有感觉工作很难找,而且工资待遇也都还不错,对年龄的歧视也相对较轻一点(其实也没有轻太多)。

    然后最后想说的是,护城河这种东西确实很难的, 就算我上面说的这些也没办法能保护我们整个职业生涯。 到了 40 岁,45 岁的时候我们一样也会很艰难。 所以现在很多人也都会找找后路, 比如我在学习技术以外也在学英语,看看以后能不能进对年龄相对友好的外企。也在积极的参与行业里的活动,锻炼演讲能力,攒攒人脉。 看看以后能不能当当培训老师什么的。 总之就是都找一找可能性,尽量的在年龄歧视的大环境下挣扎一下。

  • 我今年 36,我们这里 30 多的不算少吧。 但是 40 多的确实少。

  • 不在范式了都~~ 我跳槽到腾讯了