在用户之间分配协同投票算法

Mil*_*kov 6 algorithm distribution collaborative-filtering

我的应用程序的用户(实际上是游戏)回答问题以获得积分.问题由其他用户提供.由于音量,我无法自己查看所有内容,所以我决定将过滤过程挤出给用户(玩家).规则很简单:

  • 每个用户都会显示一个问题,评价为好/坏/不确定
  • 当问题被评为"坏"5次时,它将从池中删除
  • 当问题被评为"好"的5倍时,它将从民意调查中删除,并被标记为由其他没有看过它的玩家播放

如果每个人都能看到一切,那就很容易了.但是,在游戏阶段的后期,用户不应该得到他们已经看过的问题.这意味着用户不应该看到所有问题,并且他们没有看到的正是那些他们可以在游戏后期玩(回答).

问题总数远远大于玩家数量,每天都会添加新问题,而新玩家总是来,所以我不能提前分发.

我正在寻找一些算法,可以最大化所有玩家的评级可玩(即看不见)问题的数量.

我试图谷歌,但我甚至不确定在搜索框中放入哪些条款,并使用"分发","投票","协作过滤"等内容给出了非常有趣但无法使用的结果.

好与坏问题的比例是1:3,即.25%的问题评为良好.已提交的未评级问题数超过10000个.有投票权的活跃用户数约为150.

我目前正在考虑将问题池和用户群分成两部分.用户群的一部分将检查另一部分的问题,反之亦然.拆分问题很容易(甚至比较奇怪).但是,我仍然不确定如何划分用户群.我想在"顶级问题检查器"列表中使用奇数/偶数位置,但是在检查新问题时,列表上的位置每天都会更改.

更新:我刚刚问了这个问题续集 - 我需要定期从池中删除一定数量的问题.

mac*_*mac 4

我不知道是否有一个特定的、众所周知的算法。但这是我的想法:

  1. “最大化所有玩家评分的可玩(即未见过)问题的数量”意味着最大化+5的问题数量和每个玩家未见过的问题的数量。
  2. 无论算法是什么,其有效性都与贡献者提交的问题的质量以及其他玩家评分的意愿相关(除非您强迫他们对问题进行评分)。
  3. 你的系统的目标不应该是让所有玩家都有相同数量的“看不见的问题”[这实际上是无关紧要的],而是始终为每个玩家保留一个“储备”的看不见的问题,让他能够/她以正常游戏速率进行游戏。例如:假设您有两个用户 A 和 B,他们经常在您的网站上玩游戏。A 通常每天回答 80 个测验,而 B 只回答 40 个。如果您的系统平均每天收到 100 个新批准的问题,原则上您希望玩家 A 每天看到的问题不会超过 20 个,而玩家 B 可以安全地看到 60 个其中。
  4. 提交的问题和批准的问题之间的比例也很重要:如果每秒提交的问题都不好,那么上面的用户 A 和 B 每天可以对 40 和 120 个问题进行评分。

所以我的最终算法的方法是:

  1. 跟踪以下内容:
    • 每天提交的新问题数(F = 流量)
    • 好问题与提交问题总数的比率(Q = 质量)
    • 每个玩家每天使用的问题数量(用于玩游戏,而不是用于评分)(GR = 游戏率)
    • 每位玩家在特定日期评分的问题数(RC = 评论计数器)
  2. 建立要评分的问题的优先级队列。这里的目标是尽快批准问题。给予两者奖励优先权:
    • 已收集赞成票的问题
    • 由具有已被接受的其他问题历史记录的用户提交的问题。
  3. 当玩家参与评分时,向他/她显示队列中的第一个问题。
  4. 根据需要重复步骤 3,确保永远不会满足此条件:Q * (F - RC) < GR

[考虑到当用户首次注册时,网站上已经存在一系列已批准但未见过的问题,因此可以进一步调整上述内容]

当然,你可以通过奖励有功的活动来严重影响用户的行为(SO 上的徽章和声誉点就是一个不言自明的例子)。


编辑/附录:评论中的讨论澄清了GR是固定的,并且每天一个问题。此外,OP 指出系统中每 24 小时至少会有 1 个新的已批准问题。这意味着可以以两种形式之一简化上述算法:

如果用户只能在回答每日问题后投票:

如果系统中至少有一个已批准的、未见过的问题,则让用户随意投票。

如果用户甚至可以在回答日常问题之前投票:

如果系统中至少有两个已批准的、未见过的问题,则让用户随意投票。

这样一来,如果用户在系统上对所有可投票的问题进行投票,然后23:59 回答每日的一个问题,那么在 00:00 时仍然有一个问题可供回答,加上系统获取投票的 24 小时时间。第二天的新问题。

哈!