[RFC] Нативное отслеживание происхождения данных и сопоставление фактов для Discourse

Привет, сообщество Discourse,

Хочу представиться — я системный дизайнер, который сейчас изучает экосистему Discourse. Хотя я ещё не эксперт во внутренней архитектуре Discourse, я выбрал эту платформу для своего будущего проекта благодаря её мощной модели данных, расширяемости и управлению, основанному на сообществе.

В настоящее время я готовлю предложение для представления своему руководителю для утверждения разработки. Делясь этим здесь, я преследую цель собрать отзывы, идеи и конструктивную критику от тех, кто лучше всего знает Discourse — особенно в вопросах реализуемости, пересечения с основными функциями и соответствия лучшим практикам Discourse.

Примечание: Предложение ниже довольно подробное и техническое.
Я могу не ответить сразу, но я прочитаю и отвечу на каждый комментарий как можно скорее.


Обзор простым языком (краткий контекст)

Проблема:
Во многих обсуждениях сообщества — особенно вокруг новостей, общественной политики, науки или спорных тем — утверждения часто оспариваются, исправляются или уточняются со временем. Хотя Discourse отлично справляется с обсуждением, всё ещё трудно чётко увидеть:

  • откуда изначально взялось утверждение,
  • как оно развивалось через ответы и цитаты,
  • какие посты поддерживают, исправляют или опровергают его,
  • и как меняется уверенность в этом утверждении по мере роста обсуждения.

Идея:
Этот проект исследует плагин, который превращает ветки обсуждений в прозрачные графы доказательств, помогая сообществам проводить коллективную фактчекинг без опоры на единственного авторитета или бинарные метки «истина/ложь».

Вместо объявления фактов система фокусируется на прослеживаемости, структуре и сигналах, позволяя читателям и модераторам оценивать достоверность на основе того, как информация была взята из источников, оспорена и проверена внутри сообщества.

Кому это может быть полезно:

  • Модераторы и администраторы:
    • Поддержка справедливых, основанных на доказательствах решений модерации
    • Быстрое выявление исправлений, споров и нестабильных утверждений
  • Фактчекеры и исследователи:
    • Отслеживание происхождения утверждений и путей проверки внутри обсуждений
  • Участники сообщества:
    • Участие в дебатах с более чётким контекстом и общими ссылками
  • Читатели:
    • Понимание, почему утверждение считается достоверным или оспариваемым, без чтения каждого ответа

[Карта Facto]

Это пример того, как я представляю, как граф может выглядеть на практике.

Он предназначен для специализированных случаев использования или для тем с огромным количеством ответов, где ручное отслеживание, проверка и понимание всех аргументов становится непрактичным.

Карта Facto помогает визуализировать утверждения, доказательства, противоречия и пути проверки, облегчая сообществам фактчекинг, оценку достоверности и проведение структурированных дебатов без потери контекста.

Далее следует техническая спецификация / предложение в стиле RFC, сфокусированное на архитектуре и реализуемости.


Техническая спецификация

Название проекта: Discourse OriginGraph & Facto-Mapper
Подзаголовок: Система отслеживания происхождения данных и анализа надёжности
Версия: 1.0.0 (Предложение)


1. Резюме

В эпоху быстрого распространения информации платформы обсуждений, такие как Discourse, отлично справляются со структурированной аргументацией, но не имеют встроенных инструментов для анализа происхождения данных, отслеживания эволюции утверждений и прозрачных рабочих процессов фактчекинга.

Discourse OriginGraph & Facto-Mapper — это плагин, предназначенный для расширения возможностей Discourse слоем фактчекинга, управляемого сообществом. Вместо навязывания абсолютной истины он предоставляет визуальные и статистические инструменты, которые помогают сообществам доказывать, оспаривать и контекстуализировать утверждения через структурированные обсуждения.

Система делает акцент на:

  • прослеживаемости, а не авторитете,
  • сигналах уверенности, а не вердиктах,
  • и коллективном рассуждении, а не централизованном суждении.

2. Технические цели

  • Прослеживаемость:
    Направленный ациклический граф (DAG) для Источник → Расширение → Проверка → Исправление

  • Поддержка фактчекинга:
    Предоставление структурных доказательств для утверждений, опровержений и исправлений без маркировки контента как истинного или ложного

  • Визуализация:
    Интерактивные «Карты Facto», встроенные непосредственно в представления тем

  • Эвристический анализ:
    Взвешенная оценка на основе уверенности, полученная из структуры обсуждения и паттернов проверки

  • Производительность:
    Асинхронная обработка через Sidekiq

  • Интеграция:
    Строгое соблюдение архитектуры плагинов Discourse (Rails / Ember.js)


3. Объем работ

3.1 Включено в объем

  • Построение графа отношений внутри темы (ответ, цитата, упоминание, исправление, противоречие)
  • Извлечение сигналов из обработанного HTML и метаданных ответов
  • Настраиваемые оценки происхождения / стабильности / споров
  • Управление через уровни доверия Discourse
  • Сигналы фактчекинга, видимые модераторам (не авторитетные)

3.2 Не включено в объем

  • Автоматическая классификация истинности (нет меток истина/ложь)
  • Семантический анализ NLP / LLM (Этап 1)
  • Замена глобального поиска
  • Федерация между экземплярами

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]
       |                                  |
(Интерактивная карта Facto)           (Валидация запроса)
       |                                  |
       v                                  v
[Библиотека визуализатора]             [Пул воркеров Sidekiq]
                                          |
                                 +--------+--------+
                                 |                 |
                          [Графовый движок]     [Движок оценки]
                                 |                 |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (Рёбра / Снимки / Журналы)

5. Модель данных (проектирование схемы)

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 → Ребро цитаты
  • Регулярное выражение @username → Ребро упоминания
  • Аннотации модераторов → Ребра исправления / противоречия

7.2 Алгоритм оценки

Взвешенная центральность (в стиле PageRank):

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

Отрицательные или противоречивые рёбра применяют штрафные множители вместо бинарного отклонения.


8. UX / UI

  • Точка входа: кнопка «Вид графа» в карте темы
  • Полноэкранное модальное окно Карта Facto
  • Наведение на узел: фрагмент поста + автор + сигналы уверенности
  • Клик по узлу: прокрутка к посту
  • Фильтры: показать/скрыть исправления, противоречия или только проверенные пути

9. Безопасность и управление

  • Ограничение частоты запросов через RateLimiter Discourse
  • Санитизация JSONB для предотвращения XSS
  • Частные темы наследуют ACL Discourse
  • Никаких автоматических действий модерации — сигналы носят только рекомендательный характер

10. Дорожная карта разработки

  • Этап 1: Извлечение графа MVP + базовая визуализация
  • Этап 2: Продвинутая оценка уверенности + аннотации модераторов
  • Этап 3: Внешний API фактчекинга и экспорт для исследований
2 лайка

Привет, @Thefacto — вы когда-нибудь начинали это делать? Создавали это?
Я искал по слову «происхождение» (provenance), потому что мне интересно узнать, что у Discourse есть (может, могло или уже делает) в области C2PA или аналогичных технологий.

Важный аспект, который вы, возможно, частично уже реализовали здесь (хотя и с фокусом на вашу карту фактов), — это…

  • генерация манифеста
  • последующее криптографическое подписание
  • какой-то способ встраивания/водяного знака
  • затем распространение (вместе с активом)
  • и, наконец, представление для верификации

Возможно, я до сих пор не до конца понимаю, что именно вы пытаетесь здесь создать. Но тема «происхождения контента» сейчас у меня на первом месте.

Интересно, посмотрит ли автор темы (OP) эту статью и поделится мыслями?

https://www.sciencedirect.com/science/article/pii/S0749597825000172

Если вы считаете, что эта тема слишком не связана с тем, о чём пишет автор (OP), — я вынесу её в отдельный пост.

Удачи.