在Meta上测试的搜索改进

最近,由于内部反馈,我们决定优先改进搜索算法。

这些更改已作为 Discourse 3.1.0.beta3 的一部分推出到所有站点。更新后,您的站点将自动开始重新索引所有内容以供搜索。

作为此更新的一部分,有两个新的站点设置,但这些设置已设置为我们在 meta 上的测试中发现效果良好的值,因此我们预计大多数站点将无需更改它们。

优先在标题中完全匹配词语,而非部分匹配

Discourse 在搜索时会执行 词干提取 + 前缀匹配。这有时会导致非常意外的结果。

例如:redis 词干提取为 redi,因此搜索 redis 可以找到所有以 redi 开头的词,如 redirect 等。
一个新的隐藏站点设置 prioritize_exact_search_title_match 已添加,现在默认启用。

之前:

之后:

这意味着,如果您记得标题并输入它,您更有可能命中标题。

减少最大索引重复

我们的排名算法将包含一个词语多次的帖子排在只包含该词语一次的帖子之上。这意味着您可以通过简单地重复一个词语来“欺骗”搜索。您输入的词语越多,它在搜索结果中的排名就越高。
一个新的隐藏站点设置 SiteSetting.max_duplicate_search_index_terms,默认为 6。

应用后,这意味着如果您在一个帖子中输入 sam 6 次或 60 次,其排名将保持不变。它为结果的奖励设置了一个上限。
此更改还具有积极的性能影响,因为搜索索引会变小一些。

其他错误修复

部分工作是查看搜索的极端情况。

  • 之前我们降低了已关闭主题的优先级,但忘记了已归档主题。此问题现已修复
  • 之前我们过度依赖“域”搜索的前缀匹配。这意味着单词 happy 无法找到 https://happy.com,因为 happy 的词干是 happi,而前缀匹配失败。此问题已修复

未来工作

  • 我们计划尝试对提及自动完成功能进行“模糊”搜索。(例如,允许您跳过一个字母)
  • 我们计划研究降低标题中重复词语的优先级。目前,已关闭的主题 hello goodbye hello 的排名高于已打开的主题 hello world
  • PageRank……我们目前在排名结果时不考虑传入的内部链接数量。这意味着有时链接非常多的主题的排名可能低于一个很少被链接的稀有主题。在我们的排名算法中考虑这一点会很好。
  • 我们有一个关于 AI 集成的开放性计划,我们可能会从 GPT 类工具中获得一些灵感。

您可以做什么来提供帮助?

您在 meta 上注意到任何不好的搜索结果吗?如果是,请包含您搜索的词语,并解释为什么结果不理想。
您觉得这些更改如何(中性/更好/更糟?)

47 个赞

只是为了确保……如果我更新/升级我的设置,我会找到这两个设置吗?我知道如何找到隐藏的设置,那不是问题——但它们现在是 Meta 专用的吗?对我来说,在我的圈子里测试比在这里测试更容易;)

7 个赞

是的,但您还需要运行 rake search:reindex

7 个赞

您是否考虑过使用 Meilisearch 改进搜索功能?它所需的资源非常少,并且可以包含在 Docker 构建中。

5 个赞

7 篇帖子被拆分为新主题:在搜索中优先显示已关闭或已解决的主题

我们已经开始在这方面进行实验

首次实验仅限于用户/群组搜索,但如果一切顺利,可以进一步扩展。

8 个赞

我们已经考虑了各种集成,包括 sphinx、melli、elastic、solr/lucene,但它们都有成本。托管另一个进程来运行索引、索引过时的风险、复杂性……等等都不是免费的。

我想在探索任何其他选项之前,看看我们能从 PG 中获得多少收益,并将它们作为最后的手段。

一个非常有趣的问题,是的,它们(并且一直以来)都被置于次要优先级。我认为至少我们可以考虑为 discourse-solved 添加一个站点设置,允许管理员决定在这些情况下该怎么做(优先/次优先/中立等)。

16 个赞

不幸的是,PostgreSQL 并不适合作为搜索引擎。而 Meilisearch 拥有极低的内存消耗和无限的搜索可能性。与 Ruby 相比,服务器的开销将微乎其微。

3 个赞

这不是一个微不足道的问题。我们的搜索包含大量的维度和许多参数,它直接连接到 postgres 表。

使用外部搜索提供商,我们需要担心“同步”。

  • Discourse 上的主题被关闭 → 通知引擎
  • 帖子被删除 → 通知引擎
  • 点赞 → 通知引擎
  • 主题被拆分或合并 → 通知引擎

还有很多,包括构建多个索引(用户/帖子/主题/类别)

话虽如此,只要有足够的投入,这并非不可逾越,但这是一项艰巨的任务,而且没有概念验证表明它会好多少。很高兴 melli 有一个 typo ranker 和许多其他功能,这一点无可否认。但集成它并非免费。

粗略估计,我认为需要大约 3 个月的工作才能将 mellisearch 紧密而稳健地集成。如果我们设计 Discourse 使搜索引擎“可插拔”,甚至可能需要 6 个月。

请注意,我们确实支持 Algolia 集成:https://discourse.algolia.com/ 它并不完全可靠,而且你可以看到整个高级搜索都被省略了。

8 个赞

我敢打赌,像 discourse 这样庞大的社区,速度会快得多,不超过三个月。

2 个赞

一段时间后,我询问了我最活跃的用户(:man_facepalming: )对搜索的看法(认为),我从未说过它得到了加强。

每个人都说了同样的话;他们没想过,但因为我问了,他们才意识到现在更容易找到相关内容,大多数情况下是立刻就能找到。

Discourse 的一部分充当 WordPress 的评论系统。不,我没有收到更多评论(没有什么比博客评论更被高估了),但它显示了论坛的存在(这个词拼写对吗?)。如今,我有少数用户将 Discourse 用作搜索引擎。他们不评论,但他们通过 Discourse 主题搜索他们在 WordPress 上要找的内容,然后回到博客。当然,标签系统也很有帮助。而 WordPress 缺少这两者:有效的搜索和工作的标签。

我不知道是否应该将此发布到 Praise,但我只是想说,我对这个新的、改进的搜索工作感到非常满意。

11 个赞

哇,谢谢,这让我感觉好多了!我们现在有一个待处理的拉取请求,很快就会在全球范围内推出这些更改。

11 个赞

抱歉,如果我有点迟钝——这是否应该在托管网站(使用最新部署)上生效?发布公告指向这里,但这里讨论的是一个隐藏设置——那个隐藏设置开启了吗?

6 个赞

您无需执行任何操作:

我将在原帖中添加一个注释。

9 个赞

感谢这次精彩的更新。对我们来说,能够定义搜索同义词将是一个巨大的改进 :pray: 谢谢。

7 个赞

9 篇帖子已拆分为新主题:我能否排除用户名进行搜索

我不确定这之前是不是一个问题,但我注意到搜索结果中出现了许多系统创建的帖子。也许在元(meta)上这种情况更明显,但我并不期望系统消息与搜索相关。

搜索“automatically closed”等词语时的示例结果:

4 个赞

我无法在此处重现。

3 个赞

我可以重现这个问题;如果按最新帖子而不是相关性排序,结果中会有很多系统消息。

4 个赞

啊,是的,我看到了。虽然不是全部,但已经很合理了。这些消息似乎应该从搜索中排除。

3 个赞