项目背景
笔者曾在2019-2021年供职于某在线教育平台研发项目组，担任产品经理，负责课程内容产品的全流程开发和用户体验优化工作。在上两篇文章中，从转化情况和使用体验两方面对产品优化空间进行了挖掘，得出两个结论：
- 渠道、运营的优化确实可以提升一部分数据表现，但产品的健康成长和可持续发展主要还是靠稳定的活跃用户。为了在留住这批用户的同时还能拉新，应该不断优化核心用户体验。
- 在解决了普遍的可用性问题之后，我们将面临的问题是【标准化的内容V.S差异化的用户】。如何为不同的用户匹配最适合他们的内容（此处主要指课程难度），需要策略化的解决方案。
解决方案
- 阶段一：搭建题库系统。（题库系统是一切相关功能的载体，有了容器才能往里面添加内容和数据）
- 阶段二：为题库中的题目建立一套自适应难度调整策略，同时也可以用同样的方法为用户建立一套自适应级别调整策略。通过不断增加的用户答题数据，让题目难度和用户级别能够自动回归至无限趋近真值。
- 阶段三：基于回归后的题目难度和用户级别数据，开发测评功能。
其中，笔者独立负责了自适应难度调整策略的设计。以下将从问题背景、设计思路和设计验证3个方面逐一展开。
问题背景
当教研人员设计出一道题目并录入题库时，需要给题目标上难度等级。于是问题来了，要如何确定一道题目的难度等级呢？如果我们仅按照级别L1~L5来给题目标难度，这种颗粒度显然是不能满足实际使用的。而且随着题库里的题目数量增加，由经验判断人工标注的难度等级还可能会越来越不可信。
而用户级别的准确判定，依赖于答题的结果。如果题目的难度无法被准确标定，用户的水平也无法被准确定级。
换言之，这两个问题是需要被同时解决的。
设计思路
既然人工标注不靠谱，那么能不能让题目自己移动到合适的难度等级上去呢？
首先想到的是一种类似排行榜的概念。假设有一道题（尚未标注难度等级），由10个L5（初步定级）的用户答题的结果是10个人全对，那么我们基本可以判断这道题的难度不会超过L5。如果再让10个L4用户答题，也是10人全对，那么这道题还需要从排行榜上往下移，移到L4以下的位置。再让10个L3用户答题……一直到让10个L1用户答题时，出现了10个人全部答错的情况，于是我们推断这道题的难度应该在L1靠近L2的区域。也就是L1级别里相对较难的题目。
这里出现了3个问题：
①“L1靠近L2的区域”是一个非常模糊的描述，在实际应用中几乎毫无意义。
②实际不太可能出现10个人全部答对、或者全部答错的情况，更有可能出现的是N人答对M人答错（N+M=10）的情况，并且他们的答题结果受到【实际水平】和【随机概率】两方面的影响。
③从上例中来看，一道题需要获得50个人的答题结果才能得出一个难度级别结果（并且还是模糊的），效率实在太低。
那么可不可以设计一种算法，它既可以让题目通过答题数据在难度等级刻度尺上自行移动，而且满足以下特点呢？
- 每次都能移动到一个具体而颗粒度较小的难度等级位置上
- 前期只需要少量的答题数据就可以快速定位
此处想到的做法用一个三位数的数字【难度值】来表示一个具体的难度等级，并且开头的数字是对应的级别数字。例如【450】就代表这道题的难度属于L4级别中等难度，而【460】是L4级别中中等稍偏难一点的题目，【455】的难度又介于它们之间。这样一来，颗粒度不够细、难度定位不够精确的问题就解决了。以级别数字开头的好处是可以一目了然地看出这道题属于哪个级别。
基于此，我们也可以用一种比较讨巧的方式来解决前期无法快速定位的问题了。教研人员在录入题目时，可以根据教学大纲先给每道题标注一个【初始难度值】例如【400】，表示只知道这道题的难度属于L4级别，更具体的难度不知（当然，也可以是其他4开头的三位数例如489）。那么这道题就会优先被拿去让L4级别的用户来做。当该级别用户答题数据积累到某个样本size（例如10）时，可以根据这个样本size内的答题情况来对【初始难度值】进行一次修正，获得一个新的【迭代后难度值】。之后只要又增加了新的用户答题数据，都可以用最新的10次答题数据来继续对【迭代后难度值】进行修正。那么可以预见的是，随着答题人数越来越多，题目难度等级的波动会越来越平稳。而且答题人数的增加还有一个好处，就是前面提到的，答题结果受到【随机概率】的影响可以被逐渐抵消掉。
以上，就是算法设计的基本思路了。具体设计如图所示：
而类似的算法也可以应用于学生定级的操作，此处不再赘述。
设计验证
算法设计完成后，为了看看是否行得通，简单验证如下：
补充说明一下，为什么当题目的正确率在50%时，此时【迭代后难度值】最接近真值。这是因为：
- 被试能力值高于习题难度值时，被试有较大概率答对该题，极端情况正确率为100%
- 被试能力值低于习题难度值时，被试有较小概率答对该题，极端情况正确率为0%
- 当被试的能力值与习题的难度值大致相等时，被试答对该项目的概率为50%左右
至此，可以看到该算法基本能够满足需求，具有一定的可行性。由于笔者并非专业的开发人员，此处仅进行最基本的算法验证以证实可行性，具体的功能设计还需要配合开发人员完成。
