等这周从上海回来, 下周看看总结写一下。 最近太忙了, 都没什么功夫
好像可以有哎,我想想要不要写个帖子
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 再看会更好。
我不知道啊, 听编辑的得
已经出版了,链接写到帖子里了哈