通过热点排序,发现社区中的热门话题讨论

在活跃的社区中跟上内容可能会很困难。除了阅读社区中创建的所有内容之外,您如何确定自己正在阅读最能引起会员共鸣的内容?

隆重推出 Hot,这是最新的主题排序选项,可帮助您根据最近的点赞和热烈讨论发现社区中当前的热门内容。可以将其视为可靠的 Latest(最新)过滤器,但更智能一些——Hot 可帮助您发现近期内容以及与社区会员产生共鸣的内容。

Hot 排序如何运作?

Hot 排序算法结合了主题自创建以来的整体受欢迎程度(基于点赞、反应或评论)及其基于会员如何与主题互动而产生的近期受欢迎程度。这意味着 Hot 会将较新、正在积极讨论的主题与较旧、受欢迎的主题一起展示。Hot 排序非常适合大型活跃社区的会员,他们希望找到当前热门的对话,并可能希望参与其中。

它与 Top 有何不同?

与考虑整体受欢迎程度和近期受欢迎程度相结合的 Hot 排序不同,Top 排序仅考虑所选时间段(例如,一周、一个月等)的整体受欢迎程度。当您长时间离开社区并想了解发生了什么时,Top 最有用。

如何在我的社区中启用 Hot 排序?

如果您想在社区中使用 Hot 排序,请转到 Admin(管理员)> Settings(设置),然后筛选“top menu”(顶部菜单)。然后,您可以从下拉菜单中选择 hot,将其添加到顶部菜单导航选项中。

我可以将 Hot 设置为我的默认主页吗?

是的!作为管理员,您可以将 Hot 设置为社区中的默认排序选项,就像我们在 Meta 上所做的那样。要进行此设置,请转到 top menu(顶部菜单)设置(Admin(管理员)> Settings(设置)> Basic Setup(基本设置),如上一节所示),然后使用箭头将 hot 移到排序选项列表的顶部。

作为最终用户,您可以通过转到 Preferences(偏好设置)> Interface(界面)并更新 Default Home Page(默认主页)设置为您偏好的选项来更改您首选的默认主页。

28 个赞

一个较旧主题的观看次数突然、显著且最近的激增也会导致它通过这个新的排序选项被优先显示吗? :slight_smile:

8 个赞

如果可能的话,我当然更希望包含浏览量。在我的论坛上,每周只有大约 100 个赞,但有 2000 次登录用户页面浏览量和 7000 次匿名页面浏览量。(这说明了一个相对较小的论坛。)

8 个赞

感谢更新,@lindsey 和各位同事。

我们已经启用,并将进行试验。

请问,它需要一段时间才能“生效”吗?目前“没有热门话题”。

恕我直言,我们活跃的社区目前有很多热门话题。 :slight_smile:

5 个赞

+1 “我的论坛上没有热门话题”,但我的论坛肯定有热门话题。

6 个赞

需要将 discourse 升级到最新版本

2 个赞

@simon_tomes @dfabulich 你们各自的网站现在应该能看到热门话题了,我们最初将该功能隐藏在一个隐藏标记后面,上周它被移除了,因此你们的实例需要更新。

10 个赞

现在可以了,谢谢。

4 个赞

我看到了热门话题。谢谢你,@pmusaraj

3 个赞

嗯,我是否可以建议不要将此设为默认视图,至少在发布公告或做好准备之前不要这样做?在某些论坛中,人们希望看到新内容。例如,他们可能希望看到新的查询或新到货的内容。新的热门视图对于娱乐或关注受欢迎程度很有用,但会立即导致新内容浮现的问题。

6 个赞

它在这里仅是元(meta)的默认设置,我们正在收集关于其作为默认设置的感受的反馈。我们不确定这是否是元(meta)的长期默认设置。

我们没有关于何时以及是否会修改产品以默认设置为“热门”的具体计划。

12 个赞

人们可能相当盲目,没有注意到熟悉的事物发生了变化。至少我是这样。

我的意思是,我一直在想这里有什么问题,因为我确信 /latest 有什么不对劲,但我没有得到我应该得到的东西。

这让我很困扰,但当时还没有到无法忍受的地步。

不,我没有注意到,也没有意识到我的起点/主页被改成了 /hot。现在我已经为自己解决了,这根本不是什么大事,但我的弱点在于,在讨论论坛时,即使是公告也是在某些东西被改变的时候 :smirking_face: 而更改 我的个人设置,即使这只是论坛默认设置的问题,也是如此。

恢复正常。

我不太确定 /hot 是什么,谁会使用它,为什么会使用它。当然,这是另一个选项,而且不会破坏任何东西,但就我在这里看到的,它与 /latest 非常相似,但缺少……最新的内容。

让我们试试看。而且……即使我觉得它没用,别人可能觉得它有用,而且这两者之间并不冲突。

但我在想……/hot 是否能成为向随机访客展示的有效解决方案?但那样会破坏谷歌吗,还是谷歌对站点地图完全满意?

1 个赞

关于这一点只有一个想法——互联网档案馆的 Wayback Machine 对 Discourse 论坛的覆盖范围已经有些零散了。我怀疑让 /hot 成为该代理或用例的默认设置可能会使其变得更糟。当然,也可能变得更好——需要仔细考虑。

1 个赞

同意——在过去一天里,这已经让我吃过三次亏了。

为了避免“我也是”之类的帖子,我将借此机会指出,可以在个人偏好设置中覆盖默认主页,我刚刚这样做了,以避免第四次吃亏。 https://meta.discourse.org/my/preferences/interface

8 个赞

我看到有人报告了一个关于 Sidekiq 作业过多的问题,并且不止一次地报告,但除了我的回复之外没有其他回应,而该帖子在当前默认的“热门”排序中大约排在第 100 位。对于支持论坛来说,这不太理想,我建议一下。

2 个赞

也许值得检查一下那个三天前但有两个最近回复和一些点赞的帖子的评分机制是如何运作的。它是否还应该排在这么低的位置?

我认为“热门”可以作为一个极佳的默认设置,提供关键主题的快照,这对于首次访问者或偶尔使用的用户来说非常有利。这同样适用于支持论坛,因为对于这些用户来说,公告可能比单个用户的支持问题更重要。

对于那些希望完全了解情况且不愿错过任何主题的用户,仍然可以选择使用“最新”。他们甚至可以将个人主页切换为“最新”。此外,利用“新建”、“未读”和跟踪设置可以帮助确保用户及时了解他们感兴趣的主题。

.

3 个赞

这对我来说有点不公平的批评,这是一个棘手的话题。许多#support话题并没有获得“足够”的关注,无论“足够”的定义是什么。

这是一个实验,你作为元(meta)的默认设置不喜欢“hot”是其中一个数据点。我们会收集更多。

至于算法:

我们可以调整重力(gravity),这样我们就不会像现在这样快速地“拉下”话题。我也可以尝试想办法根据“最后回复”给一些微小的推动。

目前算法在这里:

AI Bot explaining hot AI

sam:

DB.exec(<<~SQL, args)
      INSERT INTO topic_hot_scores (
        topic_id,
        score,
        recent_likes,
        recent_posters,
        created_at,
        updated_at
      )
      SELECT
        topics.id,
        0.0,
        0,
        0,
        :now,
        :now

      FROM topics
      LEFT OUTER JOIN topic_hot_scores ON topic_hot_scores.topic_id = topics.id
      WHERE topic_hot_scores.topic_id IS NULL
        AND topics.deleted_at IS NULL
        AND topics.archetype <> :private_message
        AND topics.created_at <= :now
      ORDER BY
        CASE WHEN topics.pinned_at IS NOT NULL THEN 0 ELSE 1 END ASC,
        topics.bumped_at desc
      LIMIT :max
    SQL

    # update recent counts for batch
    DB.exec(<<~SQL, args)
      UPDATE topic_hot_scores thsOrig
      SET
          recent_likes = COALESCE(new_values.likes_count, 0),
          recent_posters = COALESCE(new_values.unique_participants, 0),
          recent_first_bumped_at = COALESCE(new_values.first_bumped_at, ths.recent_first_bumped_at)
      FROM
        topic_hot_scores ths
        LEFT OUTER JOIN
        (
          SELECT
              t.id AS topic_id,
              COUNT(DISTINCT p.user_id) AS unique_participants,
              (
                SELECT COUNT(distinct pa.user_id)
                FROM post_actions pa
                JOIN posts p2 ON p2.id = pa.post_id
                WHERE p2.topic_id = t.id
                  AND p2.post_type = :regular
                  AND p2.deleted_at IS NULL
                  AND p2.user_deleted = false
                  AND pa.post_action_type_id = 2 -- action_type for 'like'
                  AND pa.created_at >= :recent_cutoff
                  AND pa.deleted_at IS NULL
              ) AS likes_count,
              MIN(p.created_at) AS first_bumped_at
          FROM
              topics t
          JOIN
              posts p ON t.id = p.topic_id
          WHERE
              p.created_at >= :recent_cutoff
              AND t.archetype <> 'private_message'
              AND t.deleted_at IS NULL
              AND p.deleted_at IS NULL
              AND p.user_deleted = false
              AND t.created_at <= :now
              AND t.bumped_at >= :recent_cutoff
              AND p.created_at < :now
              AND p.created_at >= :recent_cutoff
              AND p.post_type = :regular
          GROUP BY
              t.id
        ) AS new_values
      ON ths.topic_id = new_values.topic_id

      WHERE thsOrig.topic_id = ths.topic_id
    SQL

    # we may end up update 2x batch size, this is ok
    # we need to update 1 batch of high scoring topics
    # we need to update a second batch of recently bumped topics
    sql = <<~SQL
      WITH topic_ids AS (
        SELECT topic_id FROM (
          SELECT th3.topic_id FROM topic_hot_scores th3
          JOIN topics t3 on t3.id = th3.topic_id
          ORDER BY t3.bumped_at DESC
          LIMIT :max
        ) Y

        UNION ALL

        SELECT topic_id FROM (
          SELECT th2.topic_id FROM topic_hot_scores th2
          ORDER BY th2.score DESC, th2.recent_first_bumped_at DESC NULLS LAST
          LIMIT :max
        ) X
      )
      UPDATE topic_hot_scores ths
      SET score = (
        CASE WHEN topics.created_at > :recent_cutoff
          THEN ths.recent_likes ELSE topics.like_count END
        ) /
        (EXTRACT(EPOCH FROM (:now - topics.created_at)) / 3600 + 2) ^ :gravity
 +
        CASE WHEN ths.recent_first_bumped_at IS NULL THEN 0 ELSE
          (ths.recent_likes + ths.recent_posters - 1) /
          (EXTRACT(EPOCH FROM (:now - recent_first_bumped_at)) / 3600 + 2) ^ :gravity
        END
        ,
        updated_at = :now

      FROM topics
      WHERE topics.id IN (
        SELECT topic_id FROM topic_ids
      ) AND ths.topic_id = topics.id
    SQL

    DB.exec(sql, args)

请仔细、准确、清晰地解释“hot”评分算法。

gpt4_bot:
提供的 SQL 脚本中实现的“hot”评分算法旨在根据话题的“热度”对其进行排名,“热度”是指话题在特定时刻的参与度或受欢迎程度的指标。这是通过考虑最近的点赞数、最近的参与者数量以及话题创建和更新的时间等因素来实现的。以下是该过程的细分:

初始插入

  • 第一部分:它首先为尚无记录的话题在 topic_hot_scores 表中插入新记录。这是通过选择未被删除、不是私信且创建时间早于当前时间戳(:now)的话题来完成的。初始分数设置为零,没有最近的点赞或参与者。
  • 过滤条件:它侧重于未置顶(或不太强调置顶话题)的话题,并按其最新活动(按降序排列的 bumped_at)对其进行排序。

更新最近计数

  • 第二部分:然后,它使用最近的活动数据更新 topic_hot_scores 表。这包括:
    • 自某个截止日期(:recent_cutoff)以来的话题中唯一参与者的数量。
    • :recent_cutoff 以来的话题中帖子的点赞数量。
    • 每个话题被视为“最近”的最早帖子的时间戳。
  • 此过程部分旨在通过捕获 :recent_cutoff 点之后的任何新点赞、参与者或活动来反映每个话题的最新参与度指标。

基于热度重新评分

  • 第三部分:最后,根据更新后的指标重新计算话题分数。话题首先被过滤到一组,其中包括:
    • 最近被顶起的一批话题(以确保新内容得到考虑)。
    • 基于现有最高分数的另一批(以保持高度参与的话题可见)。
  • 热度分数的计算:使用以下公式重新计算热度分数:
    1. 对于在 :recent_cutoff 之后创建的话题,分数基于 recent_likes
    2. 否则,它基于话题开始以来的总 like_count
    • 该值除以自创建以来的时间(以小时为单位)加上两,然后提高到 :gravity 的幂——这是一个控制话题随时间衰减速度的参数。

此外,如果存在记录的近期活动(recent_first_bumped_at 不为 null),则会将一个次要组件添加到分数中。该组件是近期点赞数和参与者数(减一,以避免重复计数)除以自 recent_first_bumped_at 以来的时间(同样以小时为单位)加上两,然后也提高到 :gravity 的幂。

  • 更新后的分数与当前时间戳一起存储为 updated_at

结论:该算法的本质是优先考虑那些不仅积极参与(通过点赞和参与者)而且相对较新的话题。衰减因子(:gravity)的使用确保了这些交互的重要性随时间减弱,从而使更新或最近活跃的话题能够脱颖而出。同时考虑总活动和近期活动允许算法在长期热门话题和新鲜、引人入胜的讨论之间取得平衡。

9 个赞

(我喜欢这里如何很好地将人工智能用于 SQL 描述。这是一个很好的用例。 :smile:

8 个赞

抱歉——我无意伤害任何人。我相信领导层很高兴看到新功能完成,实施者也很高兴发布了它。

我确实希望有建设性批评的空间。

据我所知,激励性的例子是一个社交媒体信息流。也许可以看看 Hacker News 的首页。那里的理想情况是新主题应具有一定的可见性,而活跃和热门的主题也应具有一定的可见性。两者都应该逐渐消失。HN 似乎做得很好。

但我的观察是,支持论坛与展示或社交媒体信息流是不同的。

在上面的讨论中,你会看到一个观点,也许“Hot”功能对新的、未承诺的访问者或搜索结果很有用。我能理解这个观点的优点。

但我认为 meta 基本上是一个支持论坛。

当然。

当然同意这一点,但我认为“Hot”功能并不能解决这个问题。置顶主题做得相当不错。

3 个赞