2

我托管了一些 Source 游戏服务器并运行一个插件，将玩家聊天转储到 MySQL 数据库。我有一段安静的聊天记录，并且正在寻找一些有趣的事情。我想建立一个系统，让我的社区成员确定什么是“可接受的”，什么不是“可接受的”。

我的想法是它会像这样工作：不知何故，我允许我的社区成员查看聊天日志（不识别谁说了什么），他们将日志标记为“可接受”或“不可接受”。我必须弄清楚它是否只会显示某个时间范围内的一段文本，或者只是某个时间范围内的特定用户，或者只是个别行（可能很好......也可能意味着用户完全错过了聊天的上下文）。

这有点像验证码系统，多个用户最终会对同一系列的聊天日志进行评分。从那里，我会得到单词组的值。理论是，它会创建一个阈值，在该阈值中某些事物可以接受，而另一些则不能。在对一定数量的现有日志进行评分后，我将有一种有意义的方式来确定一条消息是否符合我的社区定义的标准。

我的问题是这些——

  1. 你会建议我向我的用户展示正在评分日志的内容吗？我应该向他们展示一组 X 聊天台词吗？我应该每隔 5 分钟显示所有聊天行吗？我是否应该通过在 X 行的时间范围内仅显示 1 个用户的消息来缩小这两个窗口？还是用户应该单独为每行评分？我计划限制特定社区成员每天可以评分的行数/组数。
  2. 设计存储所有这些数据的数据库的合适方法是什么？目前，每个单独的聊天行都作为它自己的行存储在 MySQL 中。每个人都有一个唯一的 ID 以及游戏中发送的聊天消息的全文。我也有收到它的玩家名称和服务器，但我认为这些不是必要的。
  3. 我想以这样的方式创建它，使其变得自给自足/适应社区以及他们认为可以接受的东西。随着时间的推移，更多的行将被分级并添加到阈值/计算中，以确定消息是“好”/“坏”。如果有人建造了这样的东西，你能指出我在建造它时应该避免的陷阱吗？
4

1 回答 1

0

如果可能，我宁愿考虑用户能够实时将消息标记为不适当。普通用户可以做到，而不必找人离线查看。如果您不能或不想采用这种方法：消息可能会在任何其他消息的上下文之外被识别为不合适的，但是查看连续的消息流，按照它们实时出现的顺序可能是有帮助。我可能会去给他们 X 连续的消息。使用实时标记，我会在之前和之后建议一些消息，标记的消息是红色的，或者类似的东西。

当用户查看一定数量的消息时，您可以尝试建立某种奖励系统。如果您允许实时标记消息，则可以奖励查看标记消息以确认标记状态的人。

知道它是哪个播放器可能很有用。如果玩家发布了一些不适当的消息，您可以发出警告或禁令或其他东西。服务器可能不是那么有用，但我完全是为了存储一些额外的信息，您以后可能会发现它们的用途。

我不会真的沉迷于数据库存储。根据您要执行的操作类型，拥有一个包含时间（或只是自动递增 ID，或两者兼有）、播放器、服务器、消息、isInappropriate 列的表应该没问题。

您可以采取的一种方法（一旦您将一些消息标记为不合适）将非常类似于垃圾邮件过滤器（您应该能够找到足够多的材料）。

一般考虑是在标记为不适当时您是要宽松还是严格（您是否希望遗漏一些不适当的消息或标记一些很好的消息）。查看 Precision / Recall 以对此有所了解。

我怀疑在聊天环境中，在大多数情况下，只需查找（并可能尝试自动识别）出现在不适当消息中的特定单词就足够了。

于 2012-10-16T23:30:14.290 回答