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

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

大语言模型要如何评估

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 再看会更好。

我不知道啊， 听编辑的得

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