我最近在这里阅读了很多内容,发现“帖子”和“回复”似乎被 somewhat 互换使用。
如果这样做,当有人在提问并创建新主题之前,使用错误的关键词进行搜索时,会减少一些令人困扰的问题(哈哈,这刚刚就发生在我身上,“删除帖子后”和“删除回复后”并没有产生相同的结果……)
因此,我提出了这个主题问题……
我最近在这里阅读了很多内容,发现“帖子”和“回复”似乎被 somewhat 互换使用。
如果这样做,当有人在提问并创建新主题之前,使用错误的关键词进行搜索时,会减少一些令人困扰的问题(哈哈,这刚刚就发生在我身上,“删除帖子后”和“删除回复后”并没有产生相同的结果……)
因此,我提出了这个主题问题……
回复(Reply)和帖子(Post)并不完全可以互换。虽然在我们这里看到的 Meta 大多数情况下它们是可以互换的,但并非总是如此。
但我宁愿找到我在寻找的内容,即使我不知道正确的术语。
对于那些更“内行”的人来说,他们难道仍然可以选择使用引号围绕其感兴趣的明确术语进行显式搜索吗?例如“回复”:question:
谢谢,我会去读一下。但其他人在这里创建新主题之前,有多少人读过这份指南呢?
因此,我阅读了“Discourse 新用户指南”,但未能找到对“回复”的任何明确定义。
但正如我上面引用您的话所说,“回复”必然是一种“帖子”,所以当有人搜索“帖子”时,所有匹配“回复”的结果也应一并呈现……
至于搜索“回复”是否应显示所有“帖子”条目,在阅读该指南后也不得而知。
因此,我仍然希望该主题的标题所提出的请求能得到落实。(当然,这仅是我个人的看法)
回复确实是帖子的一种,但并非所有帖子都是回复。因此,搜索“帖子”时不应自动加入“回复”这一搜索条件。
如果您的偏好得到了满足,那可能会让其他像我这样只搜索“帖子”而不搜索“回复”的用户感到困扰。
但你显然‘消息灵通’,应该会直接使用明确的搜索词,而不会在这里发帖询问为什么在‘回复’搜索中会出现这么多关于‘帖子’的结果,以免打扰大家。
无论帖子/回复的语义如何,Discourse 目前尚不支持通过配置为搜索添加同义词。
好的,那我就不多说了
不过或许应该有个添加它们的途径,我预计这能减轻那些在咱们这个很棒论坛上回复新人的好人们的负担 ![]()
实际上,我会进行一般性搜索,然后跟进那些与我搜索内容有一定关联的相关链接。
搜索引擎会追踪哪些链接被点击,Discourse 也有类似功能。话题末尾的“推荐消息”是发现与具体搜索词不直接相关但高度契合话题的重要来源。
我已将其重新归类为 #feature,因为该功能请求对我来说非常明确。它要求在用户体验中提供一个定义自定义同义词的位置。
根据 PostgreSQL 官方文档,Postgres 在技术上支持同义词:
https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-SYNONYM-DICTIONARY
因此,如果您想亲自动手并深入技术层面,现在就可以实现相关功能。但我同意,未来某个时候添加一个用户界面,允许版主自行定义同义词,可能会很有意义。
我不打算为此添加 pr-welcome 标签,因为该功能较为复杂,需要较长时间才能完善,且潜在收益可能有限。
就时间规划而言,我认为在未来一年内不太可能实现该功能,更有可能在未来五年内完成。
恭喜,Dale ![]()
![]()
我们更新了术语(“用户”现为“会员”),并相应地更新了文档,但我希望任何搜索“用户”的人都能自动看到提及“会员”的结果。有什么简单的方法可以实现这一点吗?
CC:@michellefs
这是一个相当棘手的问题,我们可以创建一个插件来将同义词注入索引数据——但这需要 1 到 5 天的工作时间。
我想这里最大的问题是这对您有多重要?这是可以实现的,但需要我们提供一些定制咨询。
我什么都不知道,但那不只是从自定义方面更改文本的问题吗?或者我又像往常一样完全理解错了?
我認為希望能夠透過類似 標籤同義詞 的工具間接影響搜尋演算法。但這僅適用於貼文中的任何關鍵字(或至少是原始貼文)。
一個使用案例是,社群成員/網站訪客會搜尋他們的慣用語,而不是類似的品牌術語。搜尋演算法會優先處理截然不同的主題。我們網站上的例子是搜尋「desktop app」與「native client」主題。
好奇多年來對錯字的想法是否有改變:
在 Discourse-AI 中,我们开始试验语义搜索。这仍处于早期阶段,我们仍在探索这些系统。
使用 LLM 改进搜索提示也是一种可能的方法(尽管今天很慢):
这项技术在此处有提及:GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels
除了 100% 自动化方法之外
我们在这里的总体策略是迭代。产品中已经有“监视词”,我乐于看到一个添加“搜索同义词”的功能,您可以在其中指定常见的拼写错误和您希望“填充”的常用短语。这并非计划中的工作,但绝对是您可以考虑赞助的内容。
根据:PostgreSQL: Documentation: 18: 12.6. Dictionaries 中已有此确切功能的先例
我愿意探索的另一个领域(但我对此只是不冷不热)是允许在帖子中设置隐藏的“元数据”区域,管理员可以在其中填充搜索词。这非常非常不显眼,通常我建议“正确地”填充内容,以免内容被隐藏,例如:
semantic, related, improving

这真是一个绝妙的主意,它解决了基于嵌入的搜索的主要问题:糟糕的用户输入。
而且它只需要对我们现有的设置进行最小的更改,因为你只需要添加一个“丰富”搜索查询的小步骤 ![]()
关于这个话题,我们还可以做一些事情,那就是进行混合搜索:
我们已经在现有的嵌入 API 中提供了一个功能强大的重新排序器,它位于一个单独的端点下,具备了发生这一切所需的所有必要组件。
示例在此:
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70