AEG for WordPress: пройденные этапы и текущий фокус на Graph Builder

AEG for WordPress: пройденные этапы и текущий фокус на Graph Builder

Дата публикации: 18 августа 2026 года
Рубрика: AEG / Разработка

Две недели назад я объявил о начале работы над AI Entity Graph (AEG). Сегодня — первый технический отчёт: что уже реализовано, какие архитектурные решения приняты и над каким компонентом я работаю сейчас.

Коротко о платформе AEG

AEG — платформа ИИ-графа сущностей. AEG for WordPress — её первая прикладная реализация для WordPress.

Плагин анализирует публикации, выделяет значимые сущности — людей, организации, места и события — и формирует на их основе структурированный граф знаний. В дальнейшем этот граф станет источником для Schema.org JSON-LD, проверок качества контента и других машиночитаемых представлений публикации.

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

Выполненные этапы

За две недели разработки пройдено шесть архитектурных этапов. Сейчас в работе находится седьмой.

ЭтапСтатусРезультат
M1 FoundationЗавершёнСтруктура плагина, константы, Bootstrap, Kernel и начальное логирование
M2 LifecycleЗавершёнАктивация и деактивация, интеграция с WordPress Hooks, обработка события save_post
M3 Entity FoundationЗавершёнМодель Entity, EntityCollection, EntityDetector и первые детекторы Organization, Person, Place
M4 AdminЗавершёнДиагностический слой: проверка окружения WordPress, темы, плагинов, типов записей, таксономий и rewrite-правил
M5 Entity StorageЗавершёнХранение сущностей, связей между сущностями и связей публикаций с сущностями
M6 Entity ManagerЗавершёнИнтерфейс просмотра, редактирования, проверки и объединения сущностей
M7 Graph BuilderВ работеВнутренний граф знаний отдельной публикации

Основание: сущности и детекторы

Этап M3 сформировал базовый доменный слой AEG: модель сущности, коллекцию сущностей и конвейер обнаружения. Первые детекторы уже умеют выделять в тексте организации, персон и географические объекты.

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

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

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

Хранилище сущностей

На этапе M5 создан слой Entity Storage. Он включает три таблицы:

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

Сущность идентифицируется нормализованным именем и типом. Уникальный индекс предотвращает создание повторных записей при повторном обнаружении той же сущности.

Для работы с этим слоем реализованы три репозитория: EntityRepository, RelationRepository и EntityLinkRepository. Они обеспечивают единый API для создания, чтения, обновления и удаления данных.

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

Управление сущностями

Этап M6 добавил административный интерфейс Entity Manager. Он включает три компонента.

Entity Browser показывает таблицу сущностей с фильтрами по типу и статусу, поиском по имени и пагинацией.

Entity Editor позволяет редактировать описание, внешние идентификаторы sameAs, lifecycle-статус сущности, а также просматривать связанные публикации и другие сущности.

Entity Merger предназначен для объединения дубликатов. При слиянии AEG переносит attribution links и relations к канонической сущности и сохраняет аудит операции.

Для сущностей предусмотрен управляемый жизненный цикл:

detected → proposed → verified → merged / deprecated

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

Текущий фокус: Graph Builder

Сейчас разрабатывается M7 Graph Builder — компонент, который строит внутренний граф знаний отдельной публикации.

До этого этапа AEG умеет находить сущности, хранить их в общем реестре, связывать с публикациями и предоставлять инструменты редакторского контроля. Graph Builder собирает эти элементы в целостную модель материала.

Его базовая логика включает:

  • получение сущностей публикации из Entity Storage;
  • определение связей между ними через attribution links и semantic relations;
  • исключение дублей и объединённых сущностей через resolveCanonical();
  • формирование внутренней модели публикации как графа знаний.

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

Базовую реализацию Graph Builder планируется завершить к концу текущей недели.

Следующие этапы

После M7 в дорожной карте остаются следующие крупные работы:

M8 Schema Engine — преобразование графа сущностей в связанный Schema.org JSON-LD;

M9 Validator — развитие валидатора: обязательные свойства, уникальность сущностей, целостность графа и совместимость с правилами Schema.org;

M10 Testing — unit- и интеграционные тесты;

M11 Stable Release — подготовка документации и стабильный релиз после тестирования ядра.

На этапе Schema Engine граф будет использоваться для автоматического формирования свойств about, mentions, mainEntity, sameAs, keywords, spatialCoverage и temporalCoverage — там, где они подтверждены содержанием конкретной публикации и применимы к её типу.

Версия и тестирование

Текущая внутренняя версия платформы — 1.0.0-alpha8. Плагин находится на стадии внутреннего тестирования; публичный релиз будет планироваться только после стабилизации ядра, завершения ключевых этапов и полного тестирования.

Тестовая площадка — сайт SVU.by на WordPress 7.0.4 и PHP 8.4.23. На нём AEG проверяется не на искусственных примерах, а на реальных публикациях с повторяющимися сущностями, разными типами материалов и живой редакционной историей.

Прозрачность разработки

Код и документация проекта доступны в репозитории AEG. Архитектурные решения фиксируются в нормативных документах:

  • ARCHITECTURE.md — общая архитектура платформы;
  • ENTITY-STORAGE-DESIGN.md — устройство слоя хранения сущностей;
  • ENTITY-MANAGER-DESIGN.md — архитектура административного интерфейса;
  • DETECTOR-CONTRACT.md — контракт детекторов сущностей;
  • CHANGELOG.md — история изменений.

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

Следующее обновление

Следующая заметка выйдет после завершения M7 и начала работы над M8. В ней я покажу архитектуру графа публикации и объясню, как AEG будет преобразовывать подтверждённые сущности и связи в единый JSON-LD-граф Schema.org.

***

Связанные материалы:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

16 − 1 =

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.