[RFC] Discourse 的原生数据来源与事实映射

社区
1

Hello Discourse Community,

我希望向大家介绍一下我自己——我是一名系统设计师，目前正在探索 Discourse 生态系统。我承认我还没有成为 Discourse 内部架构的专家，但我选择这个平台来开展我即将到来的项目，是因为它强大的数据管理能力和稳固的社区结构。

我目前正在准备一份提案，将提交给我的主管以获得开发批准。我在这里分享此内容的目的是希望从最了解该平台的人那里收集反馈、见解或建设性的批评。您的输入对于帮助我完善这个概念、确保它符合 Discourse 的最佳实践，并最终提高项目的批准几率将是无价的。

注意： 以下内容相当详细。提前感谢您提供的任何建议。
我可能无法立即回复，但我会尽快阅读并回复每一条评论。

技术规范

项目名称： Discourse OriginGraph & Facto-Mapper
副标题： 原生数据溯源追踪与可靠性分析系统
版本： 1.0.0 (提案)

1. 执行摘要

在信息快速传播的时代，像 Discourse 这样的讨论平台在结构化论证方面表现出色，但在数据溯源分析和结构演变可视化方面缺乏原生工具。

Discourse OriginGraph & Facto-Mapper 是一个插件，旨在将 Discourse 从一个标准的讨论论坛转变为一个系统化的事实核查与情报层。它利用图论来追踪信息来源、可视化关系并计算可靠性指标，而不会干扰核心用户体验。

2. 技术目标

  • 可追溯性： 用于 来源 → 扩展 → 验证 的有向无环图 (DAG)
  • 可视化： Discourse 用户界面中的交互式事实图 (Facto Maps)
  • 启发式分析： 基于置信度的加权评分（非二元真/假）
  • 性能： 通过 Sidekiq 进行异步处理
  • 集成： 严格遵守 Discourse 插件架构

3. 工作范围

3.1 范围内工作

  • 主题内关系图谱（回复、引用、提及）
  • 从已烹饪的 HTML 中提取信号
  • 可配置的溯源/稳定性评分
  • 通过 Discourse 信任等级进行治理

3.2 范围外工作

  • 自然语言处理/大型语言模型语义分析（第一阶段）
  • 全局搜索替换
  • 跨实例联邦

4. 系统架构

4.1 技术栈

  • 后端：Ruby on Rails (Discourse 核心), Sidekiq
  • 前端：Ember.js, D3.js 或 Cytoscape.js
  • 数据库：PostgreSQL 13+, Redis
  • 数据交换：内部 JSON API

4.2 概念架构图

[客户端: Ember.js]  <-- JSON -->  [控制器: Rails]
       |                                  |
(交互式图表)                     (请求验证)
       |                                  |
       v                                  v
[可视化库]                 [Sidekiq 工作池]
                                          |
                                 +--------+--------+
                                 |                 |
                          [图谱引擎]     [评分引擎]
                                 |                 |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (边/快照/日志)

5. 数据模型（Schema 设计）

5.1 表：provenance_edges

字段 类型 索引 描述
id BigInt PK 唯一边 ID
topic_id Integer IDX 主题引用
source_post_id Integer IDX 源节点
target_post_id Integer IDX 目标节点
relation_type Enum reply, quote, ref, correction, contradiction (回复, 引用, 引用, 修正, 矛盾)
weight Float 边强度
metadata JSONB 上下文数据

5.2 表：facto_graph_snapshots

字段 类型 索引 描述
id BigInt PK 快照 ID
topic_id Integer UNIQUE 相关主题
version Integer 图谱版本
graph_payload JSONB 节点和边
computed_at Datetime 生成时间
is_public Boolean 可见性标志

5.3 Redis 键

  • facto:quota:user:{id}:daily
  • facto:job:topic:{id}:status

6. 内部 API 规范

POST /facto/analyze

  • 认证：TL1+
  • 参数：topic_id, force_recalc (强制重新计算)
  • 响应：job_id, status = queued (排队中)

GET /facto/graph/:topic_id

version: 5
nodes:
  - id: 101
    group: source
    score: 0.8
edges:
  - source: 101
    target: 105
    type: verification

7. 算法与逻辑

7.1 信号提取逻辑

  • 迭代主题中的所有帖子
  • reply_to_post_number → 回复边
  • 解析已烹饪的 HTML → 引用边
  • 正则表达式 @usernameusername → 提及边

7.2 评分算法

加权中心性（PageRank 风格）：

Score(P) = (1 - d) + d × Σ((Score(Pi) × Weight(Ei,P)) / OutDegree(Pi))

矛盾边应用惩罚乘数。

8. 用户体验 / 用户界面

  • 入口点：主题地图中的“图表视图”按钮
  • 全屏模态图表
  • 悬停节点：帖子片段 + 作者
  • 点击节点：滚动到帖子
  • 过滤器：切换边类型

9. 安全与治理

  • 通过 Discourse RateLimiter 进行速率限制
  • JSONB 消毒以防止 XSS
  • 私密主题继承 Discourse 访问控制列表 (ACL)

10. 开发路线图

  • 第一阶段：最小可行产品 (MVP) 图谱提取 + 基本渲染
  • 第二阶段：高级评分 + 快照治理
  • 第三阶段：版主注释 + 外部 API
1 个赞