发布时间:2024-05-22 13:01
前一篇文章(博客质量分计算(一)_ccat的博客-CSDN博客),我们重点讨论了标题质量分,标题质量分的计算相对来说更简单,也更容易深入,但是标题的质量显然不能决定一篇文章的质量,对于文章内容的质量平局,我们也做了一些尝试。
博文内容评估仍然是一个比较难定量的问题,一篇博文,可能可以命中很多“高阶”的词汇,但仍然是一篇很差的文章,甚至可能是不符合自然语言的词语堆砌,仅仅是符合词法语法的机器判定。而一篇好的入门文章,可能仅仅包含某个领域的一些基本概念。但是我们仍然可以通过一些手段,评估一篇文章的结构是否对读者“友善”,是否便于阅读。这是当前重点解决的问题,特别是提取一些常见的 bad case。
总体来说,质量分计算是一个多项式,它由一组指标项的加权求和,再乘一组因子项,求得的结果做归一化处理来实现。
其中函数 f(x) 是归一化处理的工具函数,主要是为了将计算结果约束在一个有限的区间内,便于比较。
因子项p是指以乘法作用于质量分的那些指标项,它们通常都在(0, 1]区间。从这个式子可以看出,每一个低分的因子会明显的降低最终的质量分,这些因子也基本都是一些降权机制。
目前我们重点关注的指标有:
技术文章的阅读有其特殊性,我们鼓励那些有针对性,目标清晰的文章,所以太长或太短的文章,会被降低分数。通常来说一篇技术文章,哪怕讲解一个很基本的问题,也很难在一两百字说清楚,这是比较容易理解的。但是从实际经验来讲,其实过长的文章也是非常不友善的。不仅仅会因为长文档的传输问题,造成比较糟糕的阅读体验,而且过长的文章也不利于读者消化吸收其中的知识,这一点上,技术博客和论坛,与书籍是非常不一样的。实际上一本技术书,也总是要分出章节,一篇博客,更接近于一章甚至一节。读者阅读一个连载系列,远比阅读一篇几万字几十万字的长文体验要更好的多。我们鼓励有长篇内容需要撰写的读者,充分利用博客的功能,将其组织成有关联的系列,例如一个特定的专栏,或者用标签分类。
特别是针对一些有很多段,也有很多字,但是每段只有几个字,明显不是技术文章问题的病态结构,我们的质量分算法会尽量予以识别。需要注意的是,这种结构在正常的书写博客的过程中不太可能出现,但是一些作者会在某一个平台上写作后,复制到自己在其他博客平台上的账户发表,此时又可能因为编辑器(对方或者我们的)的问题,造成不正常的段落结构(比如一个平台的软换行在另一个平台复制为分段)。我自己也有若干个不同的博客,有时候会遇到这种困扰,需要具体问题具体处理。
HTML超文本是博客的基本载体,一篇技术文章,如果其中超链接比例过高,显然是不正常的,这样的文章我们会予以降权。当然目前我们对这种情况设定的阈值非常的高,作者们可以放心,正常情况下一篇长文章带有内部目录,或者常见的包含引用资料等链接的文章,不会触发这个规则,它主要针对的是那种仅仅包含链接文本,或几乎都是链接文本的文章。
类似问题还有图片引用,无效图片会给读者带来很不好的体验,但是由于互联网的特殊性,图片的访问问题并不总是确定的。有时候可能作者自己阅读文章时,图片访问正常,但是由于图床的限制,一部分网络环境中的读者并不能看到图片。我们也在研究如何更好的识别图片来源无效或不稳定的情况,这不仅仅是能够为读者筛选阅读体验更好的内容,也能帮助文章作者更好的发现和解决问题。
同样,一篇好的技术文章,图片、代码等超文本、多媒体内容的比例,会在一个合理的范围,可能没有(这种情况其实也不典型),但不会过高。因此我们也会对图片比例过高的文章进行降权。
一种常见的 bad case 是因为文章编辑过程中的一些问题,造成代码块格式混乱,或者行号串位,其中一部分我们通过技术手段识别出来,并对其降权,使这种明显不利于阅读的文章尽量不出现在推荐榜上。
同样由于超文本的复杂性,这类内容的识别会是一个长期过程,相信作者们也希望自己的作品以整洁的面貌出现在读者面前,这部分算法,在将来应该能更直接的服务于各位作者。
这里我本想找几个 bad case ,不过现在历史存档的大数据集我还没有构建完善,简单举个例子吧,例如这位朋友的遭遇:博客页面显示问题:代码排版混乱!-CSDN论坛博客页面显示问题:代码排版混乱!https://bbs.csdn.net/topics/392404771
当然如果问题来自CSDN的编辑器,我们可以尽快解决,有时候排版错位来自外部编辑,就比较难处理了,理论上说我们可能会遇到任意多种代码排版方式,覆盖全部可能是是一件不可能的事。但是这件事仍然值得坚持做下去。希望我们的算法在将来也能提供一些帮助。
代码复杂度其实并不能决定一篇文章的质量,但是作为一个非关键性因素,我们尝试识别文章代码中包含的信息复杂程度,甄别出认真写作的作者,和一些可能存在的对抗行为。因此,简单的在文章中包含一些无意义的代码,或者简单粗暴的复制粘贴代码内容来“注水”,很可能不会得到更高的质量分。
虽然这个指标并不是决定性的,但是它的评估算法仍然值得长期改进和发展。我们在将来会更深入的识别不同编程语言(至少是常见编程语言)的特征结构,以期帮助读者找到更优质的内容。
这里举个例子,业内有一个笑话,说有团队按代码行数计算工作量,于是就有程序员把循环展开写,例如下面这段代码
for i in range(1, 10):
print(i)
就可以展开成
print(1)
print(2)
print(3)
print(4)
print(5)
print(6)
print(7)
print(8)
print(9)
print(10)
这两段代码在输入输出上是等效的,如果单纯按代码行数,第二段应该分数更高,但是在信息复杂度上,其实第一段比第二段更复杂,它描述了一个有边界条件的循环,而第二段是简单的重复。在我们的代码质量分计算中,第一段质量更高。
当然无谓的提高信息复杂度并不难,比如把前面那段代码再套上函数定义,或者定义成一个class,叠床架屋,把简单的事情办复杂,总是容易的。即使现代的 IDE,也未必能准确的发现可精简的代码结构,但是也应该看到,这样做是非常不值得的,关键在于代码质量分是加法项x中的一个指标,并不会决定性的提升最终的质量分,如果为了贪图这一项的高分,填入了过多冗余的内容,最终不会得到很高的质量分,我们的最终目的仍然是希望将优质的内容筛选出来,推荐给有需要的读者,不能因果倒置。
这并不是IT技术问题决定的,而是在基本的文字写作技术角度,一篇利于阅读的技术文章,段落结构往往是比较均衡的,不会有病态的长段——这种长段往往来自复制粘贴或转载过程中的段落信息丢失。
因此,我们也鼓励在结构上均衡,不会有过多极短段落,也不会有非常长的长段落的文章。合理的段落结构,能够更好的表达文章内容,读者的阅读体验更为友好。
目前通过与业务部门的合作,我们也梳理出一些很具体的坏结构,它们不一定代表了更本质和广泛的规律,但是(至少在一段时间内)足以对作者和读者造成困扰,例如一些无法访问的网盘链接,一些典型的无意义的推广软文(它们往往没有实质的技术写作,而是单纯的转载或洗文,再加上引流的链接、二维码)等等。就像反病毒系统的特征识别,此类典型的特征结构,我们也在质量分的发展中不断充实,并尝试梳理出一个高效的响应机制。
对文章的质量进行自动化的量化评估,是一件很有争议的事情,哪怕是仅仅评估文章的形式质量,也很难做到精准明确。但是这是一件非常有意义的事情,这个算法不仅仅是一个裁判,去给出文章向读者进行推荐的建议,也应该是作者们的助手,帮助大家创作内容,促进知识的传播。最终我们希望它除了提供给推荐系统作为一个参考依据,还能够为技术编辑和作者提供服务,帮助作者创作出优质的内容。
我个人的技术写作经历,至今也有超过二十年,甚至可以说CSDN推出博客服务,直接促进了我在二十多年前成为一个博客作者,并进一步开始写作和翻译技术内容。希望我们AI团队的研发工作,和自身的写作经验,都能够为这个平台上的所有作者、读者做出贡献。