Контентный граф — методология управления контентом через связи, а не рубрики

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

Целевая архитектура контентного графа

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

1. Узлы — статьи, блог-посты, справочники, услуги и кейсы.
2. Явные связи — внутренние ссылки между страницами.
3. Смысловые связи — вычисленные признаки текстовой близости.
4. Редакционные сигналы — пробелы, мосты, сироты, маршруты и кандидаты на обновление.

graph LR
    A["Опубликованные материалы"] --> B["Узлы и явные ссылки"]
    A --> C["Текстовые признаки"]
    C --> D["Смысловая близость"]
    B --> E["Единый граф"]
    D --> E
    E --> F["Редакционные сигналы"]
    F --> G["Проверенное действие редактора"]
    G --> A

Графовая модель совместима с общим представлением данных через узлы и направленные отношения. Например, RDF описывает граф как набор троек «субъект — предикат — объект». Контентному графу необязательно использовать RDF: для небольшой редакционной системы достаточно собственной схемы узлов и рёбер.

Какие задачи решает граф

Рубрики и обычные теги помогают фильтровать материалы по теме. Граф добавляет сведения о связях и роли публикации:

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

Порог в 50 материалов можно использовать как редакционный ориентир, но это не универсальное правило. Граф полезен раньше, если корпус быстро растёт, поддерживается несколькими авторами или связан с несколькими продуктами.

Пять редакционных сигналов

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

Из чего собирать граф

Узлы

Для каждого материала полезно хранить:

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

Явные и смысловые связи

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

Смысловую связь можно рассчитывать через TF-IDF, взвешивание терминов по частоте в документе и редкости в корпусе: корпус преобразуется в разреженную матрицу признаков, а частые во всём корпусе слова получают меньший вес в компоненте обратной частоты документов. В актуальной документации scikit-learn 1.9.0 TfidfVectorizer объединяет подсчёт токенов и TF-IDF-преобразование.

Близость двух векторов можно оценить через cosine_similarity. Для L2-нормализованных данных она эквивалентна линейному ядру. Результат следует использовать для отбора кандидатов, а не для автоматической публикации ссылок.

Обычные теги и метки роли

В Notion несколько значений можно хранить в свойстве Multi-Select. Если требуется выразить прямую связь между записями, лучше использовать Relation, а не пытаться кодировать каждое ребро тегом.

Чеклист быстрой проверки

Этот проход занимает около пяти минут и помогает понять, нужен ли более глубокий анализ:

Как внедрить методологию

1. Соберите опубликованный корпус

Сформируйте единый список материалов и нормализуйте URL. Черновики, редиректы и дубли лучше учитывать отдельно, чтобы они не искажали структуру.

2. Извлеките явные ссылки

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

3. Постройте смысловой слой

Создайте TF-IDF-матрицу всего корпуса, рассчитайте попарную косинусную близость и оставьте ограниченное число сильнейших кандидатов для каждого узла. Параметры токенизации, стоп-слова, n-граммы и порог нужно проверять на собственном русскоязычном корпусе.

4. Рассчитайте структурные признаки

Степень узла показывает число его связей. Для направленного графа полезно различать входящую и исходящую степень. Понятие центральности шире одной метрики: NetworkX отдельно документирует degree, in-degree, out-degree, closeness, betweenness, eigenvector и другие варианты.

Поэтому поле centrality без названия алгоритма, типа графа, нормализации и версии графа неоднозначно. Для поиска узлов, которые могут служить мостами между частями графа, полезно рассматривать посредническую центральность (betweenness centrality), а для оценки непосредственной связанности — центральность по степени (degree centrality). Итог всё равно требует редакционной проверки.

5. Превратите сигналы в задания

Каждое задание должно содержать:

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

6. Замкните цикл

После добавления ссылок, обновления или публикации пересоберите граф. Новый узел способен закрыть один пробел и одновременно создать новые слабые связи, поэтому старый снимок графа нельзя считать постоянной картиной корпуса.

Эталонный шаблон узла

id: stable-material-id
url: https://example.com/knowledge/material/
title: Название материала
type: knowledge
status: published
published_at: 2026-05-24
reviewed_at: null
topic_tags:
  - content-management
role_tags:
  - reference-node
links:
  - target: related-material-id
    kind: explicit
semantic_candidates:
  - target: another-material-id
    method: tfidf-cosine
    score: 0.42 # Пример значения, не универсальный порог
    reviewed: false
metrics:
  in_degree: 0
  out_degree: 1
  centrality:
    algorithm: betweenness_centrality
    graph_type: directed
    normalized: null # Укажите, применялась ли нормализация
    value: null
    graph_version: null # Заполняется для конкретного снимка корпуса

Значение близости в шаблоне приведено только как пример структуры данных. Универсального порога нет: его выбирают после ручной оценки релевантных и нерелевантных пар.

Контентный граф и ИИ-агенты

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

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

Когда граф оправдан

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

Для лендинга или небольшого стабильного сайта достаточно списка страниц, тегов и ручной перелинковки. Сложность графа должна соответствовать реальной редакционной задаче.

Инструменты и источники

• Graphify — построение графа из папки с файлами.
• Semantic snapshot на основе TF-IDF — отдельное описание смыслового слоя.
• RDF 1.1 Concepts and Abstract Syntax, W3C — официальная модель RDF-графов.
• Feature extraction, scikit-learn 1.9.0 — TF-IDF, токенизация и ограничения bag of words.
• Cosine similarity, scikit-learn 1.9.0 — определение и параметры косинусной близости.
• Centrality, NetworkX 3.6.1 — перечень метрик центральности.
• Database properties, Notion Help — свойства Multi-Select и Relation.

Следующий шаг

Graphify — превращаем папку с файлами в граф знаний для ИИ-агентов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov