感谢大家的支持， 星球已经加入了 20 多个人了

估计得有 2,3 个月吧。

嗯， 怎么说呢。 如果是以前的我， 那还是很较真的，我会跟领导说清楚并且尝试反抗一下。 但后来我慢慢知道了，有时候想改变领导的想法是不太现实的。 所以呢， 你可以考虑把问题反向抛给领导。 比如你觉得工作量更多了， 那就直接体现在排期上。 原来 3 天能做完， 你就排 4 天或者 5 天。 因为你确定要调整自动化。 测试周期拉长了自然就有人桶到领导那，领导自然就会查是什么原因，到时候你如实说就行了。 感受到了排期压力，慢慢的领导也就不坚持做这个事情了。

就是别试图靠打嘴炮说服领导。 要用事实告诉他，这样就是不行。

我还真没做过这种测试。 一般索引优化了是为了性能吧。 你直接做性能测试不行么

我经常会串， 而且会导致我每个语言的语法都记不熟。 有时候都要现查。

兄弟对匿名是不是有啥误解。。。。。。

是啊， 这不是显示的匿名用户么

额， 这个为啥要匿名啊

我不了解你们的业务，不太好下判断。 但如果是效果类的评估， 那门方法都是一样的，不管是底层还是上层。 就看你们的业务把模型的计算结果转换成了什么形式。 效果的自动化测试流程很简单， 收集数据，给数据打标注， 把数据输入模型， 然后把计算结果和预先的标注结果对比。

这个年头真的没什么好的建议， 只能祝愿楼主早日找到新工作。

收集用户行为么？ 应该都是埋点做的吧。

1. 嗯， 会说的。 但我可能不会分的那么清楚，因为在我们这里都是测试来做的。
2. 我也没有很详细的对比数据， 翻译场景我们一般都是用 meteor 或者 rouge， 生成式模型里， 我一般用 bert。

个人建议，如果想在未来有更好的职业发展。还是尽量避免外包岗位

等这周从上海回来， 下周看看总结写一下。 最近太忙了， 都没什么功夫

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

大语言模型要如何评估

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

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

或者 C-Eval：

多谢支持哈

多谢支持哈

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

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

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

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

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

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

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

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

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

我不知道啊， 听编辑的得

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

书已经出版了

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

多谢支持哈